Reference Data is the PLCSlib mechanism for extending the semantics of the underlying PLCS PSM. This extension mechanism can be used within a particular business context in which case it is documented within the PLCSlib environment and is available for use within DEXs defined in that context. In addition a project or organization may want to further extend the context specific reference data.
An overview of Reference data and its use within PLCSlib is provided in Reference Data overview.
This section outlines how to develop reference data for use within a context. However, the approaches defined here can also be applied within projects or organizations extending PLCSlib reference data for their own particular exchange requirements.
PLCSlib Reference Data Librarys (RDLs) are developed at the Context level. This significantly reduces the number of RDLs required to support DEXs whilst ensuring the compatibility of the reference data between DEXs in the same context.
Figure 1 shows the architecture of the different Reference Data Libraries.
Each ontology shown in the diagram is stored in an OWL file. The file is identified by a URI that resolves the OWL file. This URI is used to import the OWL ontology into other ontologies.
The ontology itself is identified by an IRI.
<owl:Ontology rdf:about="http://www.plcs.org/Exemplar/Exemplar-rdl"> <owl:imports rdf:resource="http://docs.oasis-open.org/plcs/oasis-rdl-en.owl"/> </owl:Ontology>
A major feature of this environment is the clear support for multiple natural language versions of an RDL. Language specific extension files just add language tagged annotations and do not add new classes or individuals. Notice the language specific files do not declare a new namespace for the concepts.
In many cases developers will only be interested in adding Reference data within a context, and so will only need to edit the file:
plcslib/data/contexts/<Cntx>/refdata/<cntx>-rdl-en.owl
This assumes the context specific extensions are developed using English as the default language. This situation is not always correct, for example in the context of Swedish Defence the default language will be Swedish. The new approach can handle this situation as shown in Figure 2. Here we can see the RDL master in this context is defined using a non-English language extending the same natural language version of the Standard PLCS Reference Data. If an English version of the RDL is required, for wider compatibility, this can be specified as a language extension of the master and only has to import the master RDL and provide English annotations.
The only new Referencs Data Libraries (RDLs) to be developed are context specific RDLs, since the core RDLs (i.e. the PSM RDL and the PLCS RDL) have already been developed. Context specific RDLs should be named according to the following naming scheme:
plcslib/data/contexts/<Cntx>/refdata/
<cntx>-rdl-<lang>.owl
http://www.plcs.org/<Cntx>/<cntx>-rdl
When creating a context specific RDL the RDL (the owl:Ontology
) itself shall have the following annotations applied:
dc:coverage
)
dc:coverage
annotation applied to the ontology itself.
This shall be further qualified by a language code to allow other language extensions
of this library to
declare language specific translations of the scope statement.
dc:language
)
dc:language
annotation on the library itself.
dc:source
)
dc:source
annotation on the library.
This shall be further qualified by a language code to allow other language extensions
of this library to
declare language specific sources.
owl:versionInfo
) mandatory propertyowl:versionInfo
annotation on the library.
This shall be set to the value v#.## for use by human users of the RDL.
owl:versionInfo
) mandatory propertyowl:versionInfo
annotation on the library.
This shall be set to the value $Revision: $ for use by the CVS system.
This shall be further qualified by a language code to allow it to be identified with
the language
specification and not the RDL as a whole.
dc:type
) mandatory propertydc:type
annotation.
dc:creator
) mandatory propertydc:creator
annotation on the library.
This shall be set to the value $Author: $ for use by the CVS system.
This shall be further qualified by a language code to allow it to be identified with
the language
specification and not the RDL as a whole.
dc:date
) mandatory propertydc:date
annotation on the library.
This shall be set to the value $Date: $ for use by the CVS system.
This shall be further qualified by a language code to allow it to be identified with
the language
specification and not the RDL as a whole.
Classes and individuals that have meaning in this context shall be declared within this RDL following the rules and guidelines identified below.
The development of Reference Data classes follows the process described in Figure 3
When creating a context specific RD class (the owl:class
), each class shall have the following elements and annotations applied:
rdf:about
) mandatory propertyrdfs:subclassof
) mandatory propertyhttp://docs.oasis-open.org/ns/plcs/plcs
) or their subclasses.
It is possible that a class may have more than one superclass, in other words multiple
inheritance is allowed.
The new class is added as a subclass of the appropriate superclass and other superclasses
added as necessary.
Labels are used to provide human readable identification in the desired language. The provided label shall be written all lower case, and may consist of more than one word separated by spaces. SKOS elements are used to provide this capability and the following are allowed:
skos:preflabel
) mandatory propertyskos:altlabel
)
skos:hiddenlabel
)
rdfs:label
is not permitted.
All chosen SKOS label related elements should be attributed with a language identifier using the ISO 639-1 language codes.
A class might represent either an information model related concept or a terminological concept, or both.
skos:definition
)
rdfs:comment
) mandatory propertyIf both a description and a definition is provided, which then should be equal, this then means that the class represents both an information model related concept, as well as a terminological concept. There can be a maximum of one description and one definition in each class. They should be formatted according to the following rules:
PlcsThing
, then the text should start with the preferred label
of the superclass of the class;
when referring to an OWL class, either a PLCS class or a PLCS term, within the text, links should be enabled in order to enhance the semantics of the text. Encapsulate the preferred label and the the URI of the owl class in braces i.e. {}. If the plural is required append a "s" after the braces.
E.g. for an OWL class:
{activity http://docs.oasis-open.org/ns/plcs/plcs.owl#Activity}
{activity http://docs.oasis-open.org/ns/plcs/plcs.owl#Activity}s
E.g. for a PLCS term:
{action http://docs.oasis-open.org/ns/plcs/plcs-terms-en.owl#action}
{action http://docs.oasis-open.org/ns/plcs/plcs-terms-en.owl#action}s
When referring to the class being defined within a note or example, it is not necessary to provide the URI.
dc:source
)
Comments and examples may be provided for the class to add further clarity to the descriptions and definitions.
skos:note)
skos:example)
There may be multiple comments and examples provided for each class. Both comments and examples should preferably only be single sentences, starting with capital letters and ending with a punctuation.
Both the comments and examples, as well as the descriptions and the definitions should be attributed with a language identifier using the ISO 639-1 language codes specifying the language used in the text.
In addition to providing information about the class/term, meta-data regarding the class should be entered as follows:
dc:creator
) mandatory propertydc.contributor
)
The creator and editor should both be specified with the full name and Company affiliation.
dc:date
) mandatory propertyYYYY-MM-DD
when the last edit was made.
dc:type
) mandatory propertyThe status of the class, described in Figure 3, being one of:
created
in_work
ready_for_review
passed_review
approved
in_use
cancelled
owl:versionInfo
) mandatory propertyskos:changeNote
) mandatory property
When a class is added to the ontology, it should be recorded in a change note.
using the format:
[YYYY-MM-DD] <editor name>, <organization>: Initial definition
E.g.
[2012-05-15] Mats Nilsson, FMV: Initial definition
Every time a class is subsequently changed the change to the class should be documented as an additional change note using the same format.
Figure 4 shows an example of the annotation properties for a class shown in Protege.
For each new Individual to be added to the RDL the Class that it is a member of must be identified. It is possible that an individual may be a member of more than one Class. The new individual is added as a member of the appropriate class and other classes that it is a member of are added as necessary.
The individual must be given an identifier to allow it to be identified within the context of the RDL (this includes the context of any imported RDL). The identifier for the individual is used as part of the URI for the individual. Most OWL tools will raise an error if this identification is not unique in the current context. This identifier has no language interpretation and could be an arbitrary string value, including a globally unique identification code (GUID). Given that the practice in the ontology community is to give meaningful identifiers (i.e. URI fragment identifiers) for classes, the PLCS community follow that practice. It is therefore recommended that the identifier used shall be a meaningful name in the default language of the RDL being defined. Identifiers shall contain no spaces or other special characters.
Labels are used to provide human readable identification, possibly in multiple languages. The SKOS annotations identified below are allowed:
In all cases the skos label should be attributed with a language identification using the ISO 639-1 Language Code identified for the RDL.
A description of the individual should be given using the rdfs:comment annotation. This should be attributed with the language code for the RDL.
Comments and examples may be provided for the individual using the skos:note and skos:example annotations respectively, again these should be attributed with the RDL language code.
If the individual represents a terminological entry (i.e. is a formally defined term that would appear in a dictionary etc.) then the definition of the term may be provided using the skos:definition annotation.
In addition to providing information about the individual the developer should also provide meta-data as follows:
Each of these annotations shall include the default language identification to allow search and display using local languages.
The approach in PLCSlib to support different languages is to create separate RDL files for the different languages. This implies that the different languages are defined within different namespaces. Although this is true from a syntactic point of view there shall be no new classes or individuals declared within these namespaces. The RDL files shall only include new language specific annotation for classes or individuals declared in the RDL being extended. To support this concept quality checks will be written to enforce these rules.
The language extension should only provide annotations that are language qualified except the dc:language annotation on the RDL itself. This is used to validate all other annotations in the language specific RDL file.
Classes and individuals imported from the master RDL file may have language specific annotations added. This should result in usage of rdfs:about that refers to the original class/individual and applies additional language annotations.
The following links provide detailed information on how to develop and extend the OASIS PLCS RDL using specific tools: