|Help TOC > Developing Reference Data|
|Developing 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.
While any conforming OWL software tool can be used to create Reference Data, to facilitate development within the PLCS TC, guidelines for the use of the Protégé Ontology Editor and its OWL plug-in software are described. 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.
Figure 1 shows the normal life cycle for an RD class going through development in DEXlib.
The tasks involved in managing the development process are as follows:
plcs-rdl-dpe.rdf-xml.owlfor example. This involves developing classes including their definition and relevant annotation properties. The class needs to be placed in the correct place in the RD class hierarchy. This involves making classes subclasses of the EXPRESS OWL classes or of an existing RD class. (See Issue 1 above for other possible kinds of Reference Data)
plcs-std-rdl.rdf-xml.owlOWL file in the "developer-draft" folder. The following annotations properties for the class are set at this point to help manage the process: OASIS_stage = "DeveloperDraft", owl:versionInfo = "1" and OASIS_revision = "0". It is possible that the new RD is actually a repair being made to an existing class that was published as a Version 1 , in which case the owl:versionInfo is set as appropriate (e.g. owl:versionInfo = "2").
plcs-std-rdl.rdf-xml.owlfile the OASIS_revision annotation is incremented (e.g. OASIS_revision = "1"). Figure 2 shows that revisions can occur within a development stage.
plcs-std-rdl.rdf-xml.owlOWL file in the "developer-draft" folder has reached that state the following happens:
plcs-std-rdl.rdf-xml.owlfile is copied over to the "committee-draft" folder.
plcs-std-rdl.rdf-xml.owlin the "developer-draft" folder can now be used for new developments but the RD that is at the OASIS_stage = "CommitteeDraft" should not be edited.
plcs-std-rdl.rdf-xml.owlOWL file in the "committee-draft" folder might be considered for ballot, the following happens:
plcs-std-rdl.rdf-xml.owlfile is copied over to the "public-review-draft" folder and the
plcs-std-rdl.rdf-xml.owlin the "committee-draft" folder is emptied (i.e. all classes are deleted from it) to ensure confusion does not exist with respect to the state of the RD.
plcs-std-rdl.rdf-xml.owlin the "developer-draft" folder to be OASIS_stage = "PublicReviewDraft", owl:versionInfo = "1" and OASIS_revision = "0".
plcs-std-rdl.rdf-xml.owlOWL file in the "public-review-draft" folder might be considered complete and ready for publication, the following happens:
plcs-std-rdl.rdf-xml.owlfile is copied over to the "committee-specification" folder and the
plcs-std-rdl.rdf-xml.owlin the "public-review-draft" folder is emptied (i.e. all classes are deleted from it) to ensure confusion does not exist with respect to the state of the RD.
plcs-std-rdl.rdf-xml.owlin any of the other folders are reset to be OASIS_stage = "CommitteeSpecification", owl:versionInfo = "1" and OASIS_revision = "0".
For the purposes of PLCS RD development, the unabbreviated RDF-XML format of OWL file has been chosen. It is more regular and enables simpler processing by the DEXlib infrastructure. The OWL files involved in RD development are as follows:
Only a single copy of the one EXPRESS and two Dublin Core OWL files is required, and that is placed in the "committee-specification" folder. Once finalized for OASIS publication, these OWL files can appear directly on the OASIS Web site for use by anyone.
Multiple copies of the PLCS Reference Data OWL file are used during the development of RD. At any one time, there may be up to five copies in the process: one OASIS standard on the Web, one in the "committee-specification" folder, one in the "public-review-draft" folder, one in the "committee-draft" folder and one in the "developer-draft" folder. Each file that is in an earlier stage in the development contains a superset of the content of the RD files in the later stages of the process. For example, the file in the "committee-specification" folder would contain all RD that has reached the Committee Specification stage while the file in the the "public-review-draft" folder would contain the RD that had reach the Committee Specification stage plus the RD that had reached the Public Review Draft stage.
Only a single copy of the one <developer> file for each RD developer is used and it always resides in the "developer-draft" folder.
Although the approach assumes that each developer only shares their in-process RD when it is ready for broader review by moving it into the "developer-draft" plcs-std-rdl.rdf-xml.owl file, it is of course possible for developers to directly import other files from "developer-draft" folder to view in-process RD from anyone. Each user has control of the imports within their <developer> file. Figure 3 shows the simplest case where a developer file does not import another developer file (note that the rdf-xml.owl extension is omitted to simplify the figure).
Figure 4 shows where one developer imports another developers RD file too (note that the rdf-xml.owl extension is omitted to simplify the figure).
Figure 3 shows that a developer has control over which of the Standard RD files they want to import. The dashed line indicates that any one of the plcs-std-rdl files can be chosen as the basis for the developer at any point in time. This capability is available by treating each of the folders as an "Ontology Repository" and changing the order in which the repositories are searched. Once the first set of RD has become an OASIS standard, the option of importing directly from the OASIS Web site becomes possible as well - although that option is not shown in Figure 5. (note that the rdf-xml.owl extension is omitted to simplify the figure).
Issues can be raised and recorded in the 'Reference Data issues log' against classes at any stage during the development of the Reference Data. Details on issue management are provided in the Raising issues against Reference Data section of the 'Instructions for DEX developers - Developing PLCS Reference Data' chapter.
In addition to issues being raised against classes, a less formal capability for commenting is supported. The Protege tool has a capability to add TODO comments as part of the OWL:versionInfo annotation property. DEXlib RDL Viewing includes support for that TODO capability in the OWL itself. A versionInfo that begins with the string "TODO" is shown as a Protege TODO, not a Version.
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" and each following version will increment that value by 1 (e.g. version "1" to "2").
NOTE: At one point minor releases (e.g "1.1") were considered but there seems to be little rationale for not just using "1", "2", etc.
The version of a particular class within the RDL is independent of the version of the entire RDL as a whole (i.e. RDL version 2 may contain classes that are unchanged and therefore are at Class version 1).
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.20 2010/02/10 16:56:25 annmeads 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.20 2010/02/10 16:56:25 annmeads Exp $ </owl:versionInfo> </owl:Ontology>
At certain points in the standardization process, the owl:versionInfo value is reset to be managed manually for the Ontology and for the individual RD Classes.
Versioning classes is actually the versioning of the definition of the classes. Versions of classes is not a well-accepted concept. If a version of a class has different membership, then it is a new class, not a version of an existing class. Versions of classes are acceptable when repairing an error in the definition, adding example and similar changes that do not change the intended membership of the class. If a change in intended membership is desired, then a new class should be created that may be a superclass or subclass of the existing class.
Each class will have a version number associated with it. The form of the version will be "n" and for the initial release of the RDL all classes will be version "1". Updates cause in increment in the value (i.e. "1" to "2", 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 </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.
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. the definition for 'Qualified_property';
<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 annotation properties available in 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. A few OASIS-specific additional annotation properties are also defined for use (e.g. OASIS_stage).
Detailed guidance on the appropriate and required use of the Dublin Core as annotation of the ontology definition is found in the Reference Data - Annotation properties chapter.
The standard set of PLCS Reference Data has been balloted and the issues addressed, it is published as an OASIS Committee Specification, or if the relevant criteria are met as an OASIS Standard. This is achieved by making the set of OWL files that make up the Reference Data available at the OASIS-specified Web addresses as follows.
for the most recently approved
OASIS PLCS Reference Data Library, where <file name> is plcs-rdl-std.rdf-xml.owl, etc.
http://docs.oasis-open.org/plcs/v<version number>/<file name>
version-specific OASIS PLCS Reference Data Library,
where <file name> is plcs-rdl-std.rdf-xml.owl, etc.
and where <version number> is "1", "2", etc. as appropriate to the release of the
Reference Data. This allows users and implementors to continue to use earlier versions of the
OASIS PLCS Reference Data if they have issues with the latest-and-greatest version or want more
control of available Reference Data within their organization, for a specific contract, etc.