• Coverpage
• Indexs
  ContextsContext IndexModel Usage GuidesModel Usage Guide IndexTemplatesTemplate IndexReference DataReference Data Index
• PLCS
  IntroductionConcept ModelConcept IndexActivity ModelActivity IndexPLCS PSM ModelPLCS PSM Index
• Help
  Help IndexPLCSlib overviewPLCSlib introductionDictionary of Terms

In order for the PLCS PSM PLCS information model to be usable in many different Contexts, it is deliberately generic. In other words, PLCS PSM SysML blocks are provided for representing constructs such as parts and dates and their relationships. More specialized semantic definitions of constructs such as a "safety critical part", or a "creation date" are not represented directly in the ISO 10303-239 PLCS standard. Instead provision is made to enable the same semantic precision by adding a classification scheme to the basic constructs using Reference Data, thus refining or augmenting the meaning of the entity.

For example, there are many different types of properties associated with components that are relevant to product life cycle support. The information model defines the basic representation of a property on a part and enables the properties to be classified. The classification mechanism is then used to define the specific type of property. The reason for using classification in this way is that any set of specific property types, such as "mean time to failure" that could have been provided by explicit modelling in the standard is likely to be incomplete. Furthermore, as business practices change, different properties are likely to be required over time and these can be introduced by means of a new class, without having to re-issue the standard.

Classification of PLCS PSM SysML blocks allows for the semantic refinement of the ISO 10303-239 PLCS information model. It is vital to ensure that all partners in a data exchange have a shared understanding of what each classification means. The classifiers used are referred as "Reference Data" and are held in a shared class libraries referred to as "Reference Data Librarys" (RDLs). These are available to all parties in a data exchange and hold definitions and sources for the classifiers or reference data items.

The relationship between the PLCS PSM based file exchanges and reference data is shown in Figure 1. This shows that the data exchange file makes reference to the RDL. The way in which the Reference Data is referenced from within a data exchange file is described in Classes and Individuals.

The principal concepts used by PLCS to enable the semantic extension of the PLCS PSM are Classes and Individuals.

An example of Classes and individuals is shown in Figure 2. This shows the classes and individuals as a Venn diagram:

• Class: Units
  The set or class of all units
• Class: LengthUnits
  The set or class of all units that are length unit.
• Individual: m
  Metre - an individual unit that is a member of the set of LengthUnits.
• Individual: ft
  Foot - an individual unit that is a member of the set of LengthUnits.
• Class: MassUnits
  The set or class of all units that are mass unit.
• Individual: kg
  Kilogram - an individual unit that is a member of the set of MassUnits.
• Individual: lb
  Pound - an individual unit that is a member of the set of MassUnits.

Classes and Individuals are used to extend the semantics of PLCS PSM. This achieved by stating in a data exchange file that something is classified as being a member of a class or that something is an individual that is a member of a class.

The example in given in Figure 2 showed RDL of units. Figure 3 shows how data in a data exchange is related to the Reference Data

The PLCS PSM Blocks used to represent Classes and Individuals are shown in Figure 4.

The constructs used for classification are:

• Classification: represents a membership relationship between a class and a member of that class. Any Block that can be classified will have an explicit part property classifiedAs of type Classification. The class that the Block is a member of is represented by either a ExternalOwlClass or ExternalClass.
• ExternalOwlClass: represents a reference to an OWL Class.
• ExternalClass: represents a reference to a Class whose definition is external to the data exchange file, but is not an OWL Class.
  NOTE    It is recommended that classes are represented in OWL ontologies and referenced by ExternalOwlClass. This enables automated quality checks to be performed on the use of the classes in the data exchange file. In particular, a check that the Class referenced exists in the OWL ontology and that it is a valid classification, that is the Block being classified is a valid classification according to the OWl ontology.

The templates used to represent classification are:

• Classifier.

An example of classification is given in Figure 5. This shows a TaskMethod that is classified as being a Maintenance task. In other words a TaskMethod a member of the class http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Maintenance_task.

Figure 6 shows an instantiation diagram of the Blocks used to represent the example in Figure 5.

A fragment of the XML used to represent the example in Figure 5 is shown below.

<ExternalOwlClass uid="oid1">
            <Class>http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Maintenance_task</Class>
</ExternalOwlClass>
            
<TaskMethod>
   <ClassifiedAs>
      <Classification classRef="oid1"/>
   </ClassifiedAs>
   </TaskMethod>

The constructs used for individuals are:

• Proxy: represents a relationship between a subject and something for which the subject is a proxy, typically an Individual. Proxy enables the representation of a statement that something in a data exchange file is the same thing as as something defined in an RDL. For example a statement that an ExternalUnit instantiated in a data exchange file is a proxy for, or is the same as the Unit defined in an RDL. Any Block that can have a proxy will have an explicit part property sameAs of type Proxy. The Individual that the Block is a proxy for is represented by either a ExternalOwlObject or ExternalItem.
• ExternalOwlObject: represents a reference or proxy to an OWL Individual.
• ExternalItem: represents a reference to or proxy to an Individual whose definition is external to the data exchange file, but is not an OWL Individual.
  NOTE    It is recommended that Individuals are represented in OWL ontologies and referenced by ExternalOwlObject. This enables automated quality checks to be performed on the use of the individuals in the data exchange file. In particular, a check that the Individuals referenced exists in the OWL ontology and that it is a valid member, that is the Block for which the proxy is stated is a valid individual according to the OWl ontology.

The templates used to represent proxies and individuals are:

• ProxyItem.

There are a number of PLCS PSM Blocks that are deliberately defined to refer to a definition in reference data. In these cases the Block will have an explicit reference property definition of type ProxyItemSelect. These Blocks include:

• ExternalUnit: a reference to a unit defined in reference data;
• ExternalPropertyDefinition: a reference to a property defined in reference data;
• StateDefinition: a reference to a state definition in reference data.

An example of individuals is given in Figure 7. This shows an ExternalUnit that is a Man_hour. In other words an ExternalUnit that is the same as or a proxy for the OWL Individual http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Man_hour.

Figure 8 shows an instantiation diagram of the Blocks used to represent the example in Figure 7.

A fragment of the XML used to represent the example in Figure 5 is shown below.

<ExternalOwlObject uid="oid2">
               <Individual>http://docs.oasis-open.org/plcs/ns/plcslib/v1.0/data/contexts/OASIS/refdata/plcs-rdl#Man_hour</Individual>
           </ExternalOwlObject>
               
               <ExternalUnit>
                   <Definition uidRef="oid2"/>
               </ExternalUnit>

Within the context of this discussion, the concept of a "code" is one where a, usually short, identifier is used to refer to something. For example, organizations are often identified using a Commercial and Government Entity (CAGE) Code as defined by United States Federal Government. Codes are also defined in numerous specifications, including standards and organization- and application-specific documents, as tables of short identifiers for things such as kinds of tasks, countries, kinds of business transactions, etc. Complex semantics are also often written into the codes by the use of controlled coding schemes and conventions.

For the purpose of support in PLCS Reference Data, a code is an identifier for something. However, the kind of thing being identified, and how many there are of that kind of thing, are often important considerations when organizations are deciding how to manage these identifiers. Care must also be taken to distinguish between cases where an identifier is a representation of an actual thing for use in Reference Data, and cases where an identifier is a name assigned to the thing. This section describes the following different approaches to managing codes as identifiers for PLCS Reference Data.

In cases where a code is the identifier for a real-world thing and the identifiers are not recorded as Reference Data, the resulting guidelines for the usage of the PLCS PSM schema are that:

• The code appears in a data exchange file as the value of the idString property of an Identifier instance.
• An OWL Class that is a subclass of the PLCS Identifier OWL class must appear in the RDL representing the type of the identifier.
• The Identifier is classified to identify the type of code represented using the OWL class that is a subclass of Identifier in the Reference Data.
• That OWL Class must have related annotations stating what document, Web site or other source is available that defines the meaning of each code. For example, the OWL Class CAGECode would have annotation stating that its source is at available at http://www.dlis.dla.mil/cage_welcome.asp.
• In most cases, an organization that is responsible for the identifier is also assigned to the Identifier.

In cases where it is appropriate to maintain the identifier for a real-world thing in the Reference Data, the idea of a code as a normal name or identifier breaks down. In Reference Data, items already have a Web-wide unique identifier – the HTTP URI of the item. In cases where a code is part of the HTTP URI in the Reference Data and is therefore representing the real-world thing itself, the resulting guidelines for the usage of the PLCS PSM schema are that:

• An individual in the Reference Data represents the real-world thing.
• The code is part of the derivation of the HTTP URI for that item in the Reference Data.
• That OWL Individual must have related annotations stating what document, Web site or other source is available that defines the meaning of each code. For example, the OWL individual representing the UK in the Reference Data would specify that the code 'uk', used as part of its HTTP URI, is from "ISO 3166-1 alpha-2 — two-letter country codes" would have annotation stating that its source is at available at http://www.iso.org/iso/country_codes.html.
• The HTTP URI that includes the code appears as the Same_as_external_item.identifier value in an exchange file.

There are cases where it is not appropriate to include Reference Data items for everything that is semantically a class – codes for kinds of tasks defined in a process standard, for example. In these cases, the code that is the identifier of the class appears in a data exchange file.

In cases where a code is an identifier for an instance of PLCS PSM Class that appears in an exchange file, the resulting guidelines for the usage of the PLCS PSM are that:

• An instance of the PLCS PSM ExternalClass Block appears in the exchange file to represent the class not defined in reference data, referred to here as the "code class"
• That instance of ExternalClass, the code class, is identified by a code.
• An instance of the PLCS PSM Block (e.g Task_method) representing an item that is a member of the ExternalClass, the code class, appears in the exchange file.
• An instance of Classification_assignment assigns the instance of Class, the code class, to the instance of the entity type representing the item that is a member of the Class.
• An OWL Class that is a subclass of the PLCS Identifier OWL class must appear in the Reference Data representing the type of the code that identifies the code class.
• An instance of Classification_assignment references both the instance of Identification_assignment being classified, the code identifying the code class, and an instance of External_class referencing that OWL Class in the Reference Data that is the type of the code class.

All of the above are specified in detail in the PLCS template ClassCode.

PLCS Reference Data is standardized using the W3C Web Ontology Language (OWL). OWL is one of a series of standards produced by the W3C in support of their vision of a Semantic Web. The OWL language was chosen for Reference Data for reasons that include the following:

• An OWL ontology and the elements within an ontology are identified using URIs, giving them a Web-wide unique identifier.
• The HTTP protocol is installed on just about every computer on the planet and this allows ubiquitous access to Reference Data as OWL.
• Due to its basis in support for the Semantic Web, organizations using standard Reference Data as OWL have very powerful extension mechanisms available to them.

In order to make all the capabilities of the OWL language available for PLCS Reference Data developers and users, care must be taken in specifying Reference Data usage in the AP239 schema, DEXs and other usage guides. Two critical concepts for the usage of Reference Data as OWL are:

• that an OWL Reference Data item is identified using a full and complete HTTP URI; and
• that organization-specific extensions to Reference Data need to be catered for in the exchange because OWL provides many capabilities for extending concepts from imported ontologies.

The result of applying these principles is that every reference to any Reference Data item must always use the full HTTP URI of the item from the original ontology in which it was defined.