|
Developers Information - Developing PLCS Reference data
|
The creation of Reference Data is very similar to any other modelling exercise. The procedures to be used are therefore similar to those for the collaborative development of information models. The basic concepts are:
The purpose of the PLCS DEX Reference Data is to add semantics to an already existing model, the AP239 Product Life Cycle Support schema. At the end of the day, adding semantics to that schema is the goal, not creating an isolated, green field ontology covering the scope of PLCS. It is also the case that some of the Reference Data is to be adopted and adapted from existing standards. Therefore, allowing different viewpoints on the same concepts in the AP239 schema needs to be taken into account. For these reasons, the RD development process defines the RD development steps within the context of DEX development. It is possible to define RD outside the scope of a DEX, however that task is expected to be more difficult until the point in time when the framework within which the RD must be created is mature and stable.
The guidelines spelled out in this document are not frozen. Continuous improvement in the Reference Data development process is expected as experience is gained. If at any point, the guidelines make the process unnecessarily cumbersome, they should be reviewed and modified accordingly.
These guidelines do not include those steps required by OASIS define a standard. The OASIS standards process states that the following:
In this section, the concept of the steps involved is described first. Once the concepts are understood, then the specifics of managing the process and the OWL files involved are described. The tasks involved in the managing process should always be considered with the more conceptual step in mind.
To facillitate the development of Reference data, the Protégé Ontology Editor software is used. Learn about the installation and usage of Protégé in the Software area of DEXlib.
The basic steps involved in developing the PLCS standard Reference Data are as follows:
It is often the case that the above steps are performed in a workshop. A process of recording the results of the above steps should be adopted for the workshop so that decisions are not lost. Unless a minor change is made, these should be recorded outside the RD itself, or at least only on a local copy of the RD used only for the workshop. Trying to apply change to an ontology during the workshop may affect other issues and decisions in a workshop are often overturned upon deeper review.
The tasks involved in managing the development process are as follows:
In order to manage this process, the OWL files have been structured as shown in Figure 1. The green boxes show OWL files that have been agreed at some level of consensus. The yellow boxes show the OWL files that are being developed be the individual modellers.
All of the OWL files are developed as part of the Sourceforge DEXLIB project: (http://sourceforge.net/projects/dexlib) and managed under CVS control: (http://cvs.sourceforge.net/viewcvs.py/dexlib/dexlib/data/refdata/).
The PLCS reference data comprises the following OWL files:
NOTE In order for DEXlib to recognize and process the individual modellers OWL file, they must be registered in: (../../data/refdata/rdl_index.xml)
Each developer will have their own developer file, as shown in Figure 1.
The following stages are required to add a new developer files:
Create the developer files and store it in: dexlib/data/refdata/plcs-rdl-XYZ.owl where by convention X is the first character of the developers's first name, Y is the first character of developer's surname, and Z is the last character of developer's surname.
The file should contain the following. Note the XYZ should be replaced accordingly.
<?xml version="1.0"?>
<rdf:RDF
xmlns="http://www.plcs.org/plcs-rdl-XYZ#"
xmlns:rd-ext="http://www.plcs.org/plcs-existing#"
xmlns:rd-prp="http://www.plcs.org/plcs-proposed#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdl="http://www.plcs.org/plcs-rdl#"
xmlns:schema="http://www.plcs.org/plcs-arm-lf-express#"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rd-reg="http://www.plcs.org/plcs-registered#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xml:base="http://www.plcs.org/plcs-rdl-XYZ">
<owl:Ontology rdf:about="">
<dc:source>OASIS Product Life Cycle TC</dc:source>
<owl:imports rdf:resource="http://www.plcs.org/plcs-proposed"/>
<owl:versionInfo>$Id: dvlp_refdata.xml,v 1.4 2007/03/07 08:48:46 mikeward Exp $</owl:versionInfo>
</owl:Ontology>
</rdf:RDF>
Update the ont_policy file (dexlib/data/refdata/ont_policy.rdf) with a reference to the new OWL file. This is necessary in order to enable Protégé to use the versions of the OWL file from your machine as opposed to trying to import them from the internet.
<OntologySpec>
<!-- PLCS local version of the individual developers PLCS Ref Data Library (including Properties) -->
<publicURI rdf:resource="http://www.plcs.org/plcs-rdl-15288" />
<altURL rdf:resource="&plcs-rdl-15288.owl" />
<language rdf:resource="http://www.w3.org/2002/07/owl" />
<prefix rdf:datatype="&xsd;string">rdl-bhs</prefix>
</OntologySpec>
NOTE To see the file in Protégé don't forget to copy the dexlib/data/refdata/ont-policy.rdf to wherever you have installed Protégé (e.g: Protege_3.0_beta/plugins/edu.stanford.smi.protegex.owl/ont-policy.rdf)
Issues can be raised against classes at any stage during the development of the reference data and recorded in an issue log. Details are provided in a separate section.
When the set of OWL files that make up the PLCS reference data are published, each file will have a version number associated with it that is incremented. The first version will be "1.0" and minor revisions will follow as "1.1", "1.2", etc. until such a point as a major release of the RDL is planned. At that point, the RDL "2.0" will be released. Note that the version of a particular class within the RDL is independent of the version of the entire RDL as a whole (i.e. RDL 1.1 may contain classes that are unchanged and therefore are at Class version 1.0).
The OWL files developed as PLCS reference data are placed under configuration management using CVS. Consequently, CVS will manage the versioning of a file every time it is committed to CVS.
This is done by setting the annotation property owl:versionInfo on the ontology to be: $Id: dvlp_refdata.xml,v 1.4 2007/03/07 08:48:46 mikeward Exp $ which will be automatically updated by CVS when the file is checked in. E.g.
<owl:Ontology rdf:about="">
<owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
$Id: dvlp_refdata.xml,v 1.4 2007/03/07 08:48:46 mikeward Exp $
</owl:versionInfo>
</owl:Ontology>
Each class will have a version number associated with it. The form of the version will be "n.n" and for the initial release of the RDL all classes will be version "1.0". Following updates that do not change the fundamental nature of the class will cause in increment in the second level of the version (i.e. "1.0" to "1.1", etc.).
The version of the class is set by the class annotation property owl:versionInfo. E.g.
<owl:Class rdf:ID="picometre">
<owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string">
1.0
</owl:versionInfo>
</owl:Ontology>
The class names must be unique within the context of the entire Reference Data Library. Given that the practice in the ontology community is to give meaningful names (i.e. URI fragment identifiers) for classes, the PLCS RD class names follow that practice.
As the class names are also part of a URI in the OWL language, they may not contain spaces or special characters. The convention for the name is that the first character of the first word is upper case and all other characters are lower case. Words in the class name are separated by the underscore character.
Other general guidelines/practices include the following.
The name of the class is set by the OWL rdf:ID construct. E.g.
<owl:Class rdf:ID="activity"/>
Alternative labels can be provided for the OWL rdfs:label construct. These labels can be used to provide a name for the class in multiple languages. E.g.
<owl:Class rdf:ID="Activity">
<rdfs:label xml:lang="fr">Activité</rdfs:label>
</owl:Class>
From a user viewpoint, a good definition is straightforward to understand from the text of the definition, does not use any specialist terminology, nor require any specialist knowledge.
The definition associated with an RD class may be seen by PLCS application users and therefore should take into account the DEX(s) and PLCS entity type(s) that are its context.
The definitions are set by the OWL rdfs:comment construct. E.g.
<rdfs:comment xml:lang="en">
A Qualified_property is property whose values are described rather than being numerically quantified.
For example the property of a traffic light may be Red, Amber or Green.
</rdfs:comment>
<rdfs:comment xml:lang="en">
A property whose values are described rather than being numerically quantified.
For example the property of a traffic light may be Red, Amber or Green.
</rdfs:comment>
A class can be in one of the following possible states:
In conjunction with the OWL language itself, PLCS Reference Data is annotated and managed using another Web standard called The Dublin Core. The use of the Dublin Core in PLCS RD is as OWL annotation properties. Annotation properties are like comments in programming source code in that they have no effect on the technical content of the OWL ontology.
Detailed guidance on the appropriate and required use of the Dublin Core as annotation of the ontology definition is found in a separate section of this help documentation.
The standard set of PLCS reference data has been balloted and the issues addressed, it is published as an OASIS standard. This is achieved by making the set of OWL files that make up the reference data available at a specified URL (e.g. http://www.plcsorg.inc). The final URL has not yet been determined. The change to all URIs within the RDL will be automated at the time of publication.