PLCS DEX:Overview of Procedures for PLCS Reference Data Development Using OWL

Overview of Procedures for PLCS Reference Data Development Using OWL

Introduction

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:

Each developer has control of their own work-space which is an extension to the group work-space.
Each Reference Data item goes through a process of increased consensus, level of stability and control.
There is a defined development process to be followed including tasks such as creation, review, raising issues, agreeing resolutions and incorporating resolutions.
Team members play various roles during the process (e.g. creator, reviewer).
After the team processes are completed, the Reference Data must be agreed within the OASIS PLCS TC based on OASIS guidelines. Once that has occurred, then the OASIS standards-making process takes over.

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 unnessarily 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:

Before the TC can submit its Committee Draft to OASIS membership for review and approval as an OASIS Standard, the TC must conduct a public review of the work. The decision by the TC to submit the work for public review requires a majority vote. The review must be announced by the TC Administrator on the OASIS members mail list and optionally on other public mail lists. Review must take place for a minimum of 30 days, during which time no changes may be made to the document. Comments must be collected via the TC's archived public comment facility. The TC must record the comments received as well as the resolution of those comments.

Types of Reference Data

There are two types of Reference Data applicable to PLCS DEX usage scenarios:

PLCS standard Reference Data published through the OASIS PLCS Technical Committee. This is the Reference Data that all PLCS implementations must be able to support and that is the basis for the second type of Reference Data.
Extensions to the standard Reference Data. These may be shared, and perhaps standardized, across an industry sector, or may be project-, contract- or company-specific.

RD Development process

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.

The concepts

The basic steps involved in developing the PLCS standard Reference Data are as follows:

Once the subset of the PLCS schema to be used for a DEX is defined, then the scope of the required RD is known - the RD will be subclasses of the classifiable entity types included within the DEX. Additionally, the RD must be appropriate to the usage scenario of the DEX.
Once the scope of the RD is identified, existing sources for RD (including the PLCS standard and non-standard RD) that may be adopted or adapted are investigated and the applicable RD is identified. If the existing RD does not satisfy the DEX requirements, then new RD must be created.
For each new or existing Class to be added to the RD, where it fits in the PLCS schema or an existing class of which it is a subclass must be identified. It is possible that a class may have more than one superclass (i.e. multiple inheritance is possible).
Given the superclass(es) and sibling classes of the class in question, the definition of the class is written such that its usage is clear and helps users decide when to use the class and when not to use the class.
The class is added to the developers ontology and the tasks involved in managing the process are applied. Each class must also have the required annotation created at this point in order to support the management of the RD Library as a whole.

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 details

The tasks involved in managing the development process are as follows:

Individual modellers develop reference data as part of the appropriate DEX team but within their own OWL file. This involves developing classes including their definition and relevant annotation properties. (See ??). 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.
The classes developed by the modellers are then reviewed by the team comprising the modeller who developed the reference data, a business user from the DEX team and at least one other modeller not involved in the development of that class; This review involves checking that:
- the required annotation properties are used;
- the class definition is understandable and unambiguous;
- the class is a subclass of the appropriate PLCS schema classes (directly or indirectly through other RD classes);
- the class is a subclass of all appropriate RD classes
- the class does not replicate other classes within the same context. Because of the possibility of PLCS adoption of multiple existing standards covering the same scope, it is possible that the class may overlap with classes defined in other standards. For example, both DEF STAN 00-60 and NATO standards may result in classes that are subclasses of the PLCS entity type "product" and those classes may overlap. However, in that case, the classes that overlap are not considered to be "within the same context". Note that it is possible to classify the same data instance any number of times in a DEX-based data exchange so both the 00-60 and NATO classes might be used at the same time.
The results and the rationale of the review are recorded in an issue log with the classes either deleted, or accepted as PLCS proposed reference data and the class is moved from the modellers OWL file to the plcs-proposed OWL file signifying it has been agreed by the immediate DEX team.
A similar review cycle then occurs but on a wider scale involving the same roles but from other DEX teams. This supports the harmonization of RD across DEXs.
The results and the rationale of the broader review are recorded in an issue log with the classes either deleted, or accepted as PLCS registered reference data and the class is moved from the plcs-proposed OWL file to the plcs-registered OWL file signifying it has been agreed across the DEX teams. This also signifies that the RD will be included in the next publication of the RDL through the OASIS processes.
At some point the plcs-registered RD is frozen, a new version of the plcs-refdata is created into which the registered RD is migrated, and the set of OWL files that make up the PLCS Reference Data Library are published for internal ballot;
The ballot closes and the ballot comment are reviewed and addressed.
Following ballot comment resolution, the set of OWL files that make up the PLCS Reference Data Library are published as an OASIS standard incrementing the Version of the entire RDL as appropriate (either a point release of an existing version or as a new major version).

OWL files

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/plcs_owl/).

Figure 1 — RDL OWL file structure

The PLCS reference data comprises of the following OWL files:

plcs-dcterms.owl (../../data/refdata/plcs_owl/plcs-dcterms.owl)

The Dublin core terms used by PLCS represented as OWL classes.

plcs-dc.owl

(../../data/refdata/plcs_owl/plcs-dc.owl) The Dublin Core elements used by PLCS represented as OWL classes.

plcs-arm-lf-express.owl (../../data/refdata/plcs_owl/plcs-arm-lf-express.owl)

The PLCS EXPRESS represented as OWL classes. The reference data is subclasses of these EXPRESS classes.

plcs-refdata.owl (../../data/refdata/plcs_owl/plcs-refdata.owl)

The PLCS reference data that is subclasses of the EXPRESS classes. This file imports the EXPRESS classes from plcs-arm-lf-express.owl.

plcs-rdl.owl (../../data/refdata/plcs_owl/plcs-rdl.owl)

The OWL ontology that is the PLCS reference data. This file imports from:

Issue management

Issue logs

Issues can be raised against classes at any stage during the development of the reference data.

The issues are recorded in the issue log: issue log(../../data/refdata/plcs_owl/dvlp/issues.xml)

Each issue has the following form:

<issue
  id=""
  class=""
  class_file="plcs-rdl.owl"
  status="open"
  category="minor_technical"
  by=""
  date="04-07-19"
  seds="no"
  ballot_comment="no"
  resolution="accept">
  <description>
    
  </description>
<issue>

Where:

id: an identifier of the isssue unique to the issue log
class: the class against which the comment has been made
class_file: minor_technical the owl file in which the class is stored
category: Either: editorial | minor_technical | major_technical | repository
by: person raising the issue
date: date issue raised yy-mm-dd
status: status of issue. Either "open" or "closed"
seds: A formal issue that has been raised after publication. Either "yes" or "no".
ballot_comment: A ballot comment against the class. Either "yes" or "no".
resolution: Indication as to whether the issue has been accepted or rejected. Either "accept" or "reject".

When an issue is addressed, a comment should be added. The form of the comment is:

      <comment
        by="" 
        date="">
        <description>
        </description>
      </comment>

Where:

by: person raising the issue
date: date issue raised yy-mm-dd

Display of Issues

Issues against the class are displayed when displaying the Reference Data.

Managing the development process

Naming classes

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.

It is not recommended to put the word class or category or classification in the name of the class. (e.g. a subclass of "Activity" is not "Maintenance_task_class" but "Maintenance_task").

Class definitions

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.

Who created/defined the class

The Dublin Core term "creator" is the annotation to be used to define the person and organization who added the class to the RD Library. The form of the dc:creator value should be first name, last name, comma, and then organization name (e.g Rob Bodington, Eurostep).

What is the source of the class

The Dublin Core term "source" is the annotation to be used to define any standard or organization that originally created the class and is responsible for publishing it and controlling its development. A unique name for any dc:source must be agreed by the RD developers.

Class status

A class can be in one of the following possible states:

Development: While not really a formal status, the class exists within one of the RD developer OWL files available on DEXLib. For example, the class might be defined in plcs-rdl-rbn.owl(../../data/refdata/plcs_owl/plcs-rdl-rbn.owl).
Proposed: The RD has been reviewed by the DEX team and upgraded to a status of "Proposed". The class will be removed from the RD developer OWL file and moved to the Proposed OWL file (i.e. plcs-rdl-proposed.owl(../../data/refdata/plcs_owl/plcs-proposed.owl))
Registered: The has been RD reviewed by the larger PLCS TC and upgraded to a status of "Registered". The class will be removed from the "Proposed" OWL file and moved to the "Registered" OWL file (i.e. plcs-rdl-registered.owl(../../data/refdata/plcs_owl/plcs-registered.owl))
Published: Once the RD Library as a whole has been through the OASIS standardization process and made available an official OASIS standard, it is made available to the public as an initial, or new, version of the OASIS PLCS TC Reference Data Library (i.e. plcs-refdata.owl(../../data/refdata/plcs_owl/plcs-refdata.owl)). No changes will occur to this RD until the next revision of the RDL is published (i.e. until a version 1.1 is published to address issues raised on a version 1.0).

Versioning Ontologies

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).

Versioning classes

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 annotation property owl:versionInfo will be used to specify the version of the ontoloty and of any RD within the ontology.

RD Publication process

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.

Beginning of Work-in-progress text

The remainder of this section are a mix of requirements and ideas that have not yet been reviewed or agreed.

Equivalent classes

There is a requirement to specify that two classes are equivalent (i.e. contain exactly the same members).

Multi-language class names and definitions

Identifying classes as used in a DEX

Identifying classes as used in a contract

Who uses the class - which organization has contracted against an ontology or a subset of the ontologies?

How to identify classes that are used/required by a capability

We may need to identify the reference data

How does an organization extend/use the ontology.

Are there types of Reference Data classes to be taken into account?

EXPRESS/OWL classes

The PLCS information model is represented by converting the EXPRESS entities to OWL classes - EXPRESS/OWL classes. Reference data is generated by creating sub classes of these OWL classes.

Model classes

There is some reference data that is used to provide additional semantics to the PLCS information model or to clarify the ambiguity of the model. This reference data is typically used where the PLCS model is inadequate, but was not be modified in order to preserve compatibility with existing parts of the STEP standard.

Qualifier classes

Qualifier classes are used to qualify an assignment. For example, a typical or actual date is represented by qualifying a Date_or_date_time_assignment as being typical or actual.

The application of a qualifier class is achieved by making the EXPRESS entity to which the qualifier applies a sub class. An example is shown in Figure 2.

Figure 2 — Qualifier classes

Domain classes

The majority of OWL classes are classes particular to a given domain.

Example classes

During the development of the capabilities, some reference data is used as examples in the text describing the capability. Rather than including this reference data in the standard set of reference data to be published, it is stored in a separate OWL file plcs-rdl-examples.owl(../../data/refdata/plcs_owl/plcs-rdl-examples.owl).