Creating task specific configuration files

If you publish from a task within Knowledge Model Management an extra directory will be created under the config/<<Model Name>> directory with the normalized name of that task. No data will be put into that directory at this point.

If you manually add configuration files here, then they will only be available to people working within that task.

If you want to make files only available to people working on the master version of the model, then put them into a sub-directory called “master”.

Creating task specific configurations

Within the configuration files, a number of special variables are populated and are therefore available for use:

• ${model.name} - the URI encoded version of the model name. In the default configuration, this will be used to determine the name of the SES index and the Publish Set used in classification server.

• ${task.name} - the URI encoded version of the task name. In the default configuration, this is not used. However, it could, for example, be used to create task specific SES indexes or publish sets. Note, that when publishing from the Master version of the ontology this will have the value “Master”

• ${model.profile} - this will have value “Master” if publishing from the master version of the model, or “Task” if publishing from any task. This can therefore be used to distinguish task publishing from master publishing when you are not interested in from which particular task you are publishing.

• ${start.date} - the date at which the Publishing started formatted as yyyy-MM-dd-HH-mm-ss. This is used primarily for creating log and temporary directories, but might be useful to distinguish output artifacts.

• ${sparql.endpoint} - this is the SPARQL endpoint that Publisher will use to access Knowledge Model Management to obtain the model (only applicable for running Publisher standalone)

• ${named.graph} - the named graph as presented to the Publisher

As an example of how to use these settings, if you have a Classification Server running in production (at production.mycompany.com:5058) and another running in development (at development.mycompany.com:5058) then you can define two PakFilePulisher beans:

    <bean id="rulebasePublisher-Master" class="com.smartlogic.publisher.pak.PakFilePublisher">
        <property name="classificationServerHost" value="production.mycompany.com" />
        <property name="classificationServerPort" value="5058" />
        <property name="publishSetName" value="${model.name}" />
    </bean>
    <bean id="rulebasePublisher-Task" class="com.smartlogic.publisher.pak.PakFilePublisher">
        <property name="classificationServerHost" value="development.mycompany.com" />
        <property name="classificationServerPort" value="5058" />
        <property name="publishSetName" value="${model.name}" />
    </bean>

If you define one of your output processors as

    <ref bean="rulebasePublisher-${model.profile}" />

then publishing any task will take place to the development classification server, but publishing of master will take place to the production classification server. Otherwise, the configurations will be identical.