How to model the Reference Data STEPLIB

Warning

../../_images/construction.png

This page is under construction.

To contribute or participate contact support@boost-lab.net

See also

How to model the mapping between the Domain and Core models of STEPLIB : Mapping a combined Classification

Introduction

Reference Data is the mechanism for extending the semantics of the underlying sysML Core Model. This extension mechanism can be used within a within Application Protocols (APs).

This section outlines how to develop reference data for use with an AP, but the approaches defined here could also be applied within projects or organizations extending reference-data for their own specialized exchange requirements.

RDL content

RDL files

Reference Data Libraries (RDL s) are (optionally) developed per Application Protocol.

Figure 36 illustrates the reference data architecture and the relationships between the different libraries. Each ontology shown in the diagram is stored in an OWL file and is identified by an Internationalized Resource Identifier (IRI):

<rdf:RDF xmlns="http://standards.iso.org/{rest_of_IRI_for_this_ontology}

EXAMPLE:

http://standards.iso.org/iso/10303/-999/tech/refdata/ap999_v1

Each OWL file is identified by a Uniform Resource Identifier (URI) that resolves to that file. The URI is used to import that OWL ontology into other OWL ontologies.:

<owl:Ontology rdf:about="http://standards.iso.org/{rest_of_URI_for_this_file}">
  <owl:imports rdf:resource="http://standards.iso.org/{rest_of_URI_for_imported_file}.owl"/>
</owl:Ontology>

EXAMPLE:

http://standards.iso.org/iso/10303/-999/tech/refdata/ap999_v1.owl

The following table sumarizes the naming:

  file name and path ns-prefix URI IRI
Core STEPlib\Core_model\ refdata\core_v1.owl corev1 http://standards.iso.org /iso/10303/ -4000/tech/refdata/ core_v1.owl http://standards.iso.org /iso/10303/ -4000/tech/refdata/ core_v1
Core RD STEPlib\Core_model\ refdata\core_rd_v1.owl corerdv1 http://standards.iso.org /iso/10303/ -4000/tech/refdata/ core_rd_v1.owl http://standards.iso.org /iso/10303/ -4000/tech/refdata/ core_rd_v1
AP 999 STEPlib\ Application_protocols\ AP999\ refdata\ap999_v1.owl ap999v1 http://standards.iso.org /iso/10303/ -999/tech/refdata /ap999_v1.owl http://standards.iso.org /iso/10303/ -999/tech/refdata /ap999_v1
AP 999 language extension STEPlib\ Application_protocols\ AP999\refdata\ ap999_fr_v1.owl ap999frv1 http://standards.iso.org /iso/10303/ -999/tech/refdata /ap999_fr_v1.owl http://standards.iso.org /iso/10303/ -999/tech/refdata /ap999_fr_v1
Other business context STEPlib\ Business_contexts\ My_Context\refdata \my_context_v1.owl myctxv1 http://my_org /my_context/ refdata/ my_context_v1.owl http://my_org /my_context/ refdata/ my_context_v1
OBC language extension STEPlib\ Business_contexts \My_Context\refdata\ my_context_rd_fr_v1.owl myctxrdfrv1 http://my_org /my_context/ refdata/ my_context_fr_v1.owl http://my_org /my_context/ refdata/ my_context_fr_v1
../../_images/ht_rd_architecture.png

Figure 36 Reference Data Library Architecture

A feature of this environment is the support for multiple natural language versions of an RDL. Language specific extension f iles add language tagged annotations but do not add new classes or individuals.

In most cases, developers will only be interested in adding reference data within the context of an AP and so will, therefore, only need to edit the file:

STEPlib\Application_protocols\{Ap_name}\refdata\{ap_name}_v1.owl

RDL file content

Context specific RDLs should be named according to the following naming scheme.

File location

AP specific RDL files shall be created in:

STEPlib\Application_protocols\{Ap_name}\refdata

Where {Ap_name} is the name of the AP for which this RDL is being developed.

Note

The {Ap_name} in this usage can use appropriate capitalization.

EXAMPLE:

AP999

File name

The AP specific reference data file shall be called:

{ap_name}_v{version}.owl

Where {ap_name} is the name of the domain for which this RD is being developed, and {version} is a decimal number in which the decimal point has been replaced by a hyphen.

Note

Here the AP name should be written in all lowercase to be consistent with STEPlib naming conventions.

EXAMPLE:

ap999_v1.owl

IRI

The AP specific ontology identifier (IRI) shall be:

http://standards.iso.org/iso/10303/-{part_number}/tech/refdata/{ap_name}_v{version}

Where {part_number} is the 10303 part number and {ap_name} is the name of the domain for which this RDL is being developed, and {version} is a decimal number in which the decimal point has been replaced by a hyphen.

Note

Here the AP name should be written in all lowercase to be consistent with STEPlib naming conventions.

EXAMPLE:

http://standards.iso.org/iso/10303/-999/tech/refdata/ap999_v1

URI

The AP specific RDL file identifier (URI) shall be:

http://standards.iso.org/iso/10303/-{part_number}/tech/refdata/{ap_name}_v{version}.owl

Where {part_number} is the 10303 part number and {ap_name} is the name of the domain for which this RDL is being developed, and {version} is a decimal number in which the decimal point has been replaced by a hyphen.

Note

Here the AP name should be written in all lowercase to be consistent with the naming conventions.

EXAMPLE:

http://standards.iso.org/iso/10303/-999/tech/refdata/ap999_v1.owl

When creating an AP specific RDL, the RDL (the owl:Ontology) itself shall have the following annotations applied:

Ontology Identifier (rdf:about) mandatory property

The Ontology shall be given an IRI to allow it to be uniquely identified:

<owl:Ontology rdf:about="http://standards.iso.org/iso/10303/-{part_number}/tech/refdata/{ap_name}_v{version}">
</owl: Ontology >

EXAMPLE:

<owl:Ontology rdf:about="http://standards.iso.org/iso/10303/-999/tech/refdata/ap999_v1"> </owl:Ontology>
Ontology Scope (dc:coverage)

The RDL for a specific context shall identify the scope or applicability for the context using the 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:

<owl:Ontology rdf:about="{...}">
  <dc:coverage xml:lang="en">{description of the scope of the RDL}</dc:coverage>
</owl:Ontology>

EXAMPLE:

<dc:coverage xml:lang="en">The classifiable objects from AP999.</dc:coverage>
Ontology Language (dc:language)

A language declaration that will be used to verify that all annotations created in this RDL file are valid. This is represented as a dc:language annotation on the library itself:

<owl:Ontology rdf:about="{...}">
  <dc:language>{lang}</dc:language>
</owl:Ontology>

EXAMPLE:

<dc:language>en</dc:language>
Ontology Source (dc:source)

The RDL may identify a source for the reference data specified in this RDL. This is represented using 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:Ontology rdf:about="{...}">
  <dc:source xml:lang="en">{source}</dc:source>
</owl:Ontology>

EXAMPLE:

<dc:source xml:lang="en">ISO 10303-4000</dc:source>
Ontology Version (owl:versionInfo) mandatory property

The RDL version information is to be represented using owl:versionInfo annotation on the library. This shall be set to the value v#.# for use by human users of the RDL:

  <owl:Ontology rdf:about="{...}">
<owl:versionInfo>{version}</owl:versionInfo>
  </owl:Ontology>

Note

This should not be qualified by a language code since this is language independent.

EXAMPLE:

<owl:versionInfo>v1.0</owl:versionInfo>
Ontology Status (dc:type) mandatory property

The publication status of the RDL is represented with the dc:type annotation:

  <owl:Ontology rdf:about="{...}">
<owl:type><status></owl:type>
  </owl:Ontology>

Note

This is not qualified by a language code since this is language independent. It should also not be specified in language extensions since this is a property of the master RDL.

The possible values are: * Created * InWork * ReadyForReview * PassedReview * Approved * InUse * Cancelled

EXAMPLE:

<owl:status>InWork</owl:status>
Ontology Creator (dc:creator) mandatory property

The record of the person creating the RDL shall be specified using the dc:creator annotation. 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:

  <owl:Ontology rdf:about="{...}">
<owl:creator xml:lang="en"><creator></owl:creator>
  </owl:Ontology>

EXAMPLE:

<owl:creator xml:lang="en">Phil Spiby, Eurostep</owl:creator>
Ontology Creation Date (dc:date) mandatory property

A date value for when the file was created using the dc:date annotation. 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.

EXAMPLE:

<owl:date xml:lang="en">2019-03-29</owl:date>
Ontology Import (owl:imports) mandatory property

The RDL import another RDL. This is represented using owl:imports annotation on the library.:

<owl:Ontology rdf:about="{…}">
  <owl:imports rdf:resource="http://standards.iso.org/{rest_of_URI_for_imported_file}.owl"/>
</owl:Ontology>

EXAMPLE:

<owl:imports rdf:resource="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1 "/>

Classes and individuals that have meaning in this context shall be declared within this RDL following the rules and guidelines specified below.

Reference Data Classes

The content for owl:class are:

Class Identifier (rdf:about) mandatory property

The class shall be given an GUID to allow it to be uniquely identified. The identifier for the class is combined with the IRI (or the corresponding DOCTYPE !ENTITY reference) for the RDL in which it is defined to create the identifier for the class.

<owl:Class rdf:about="<IRIorCorrespondingEntity><guid>">

IRI EXAMPLE:

<owl:Class rdf:about="http://standards.iso.org/iso/10303/-999/tech/refdata/ap999_v1#2a69f900-079c-0136-76fe-00ff90f87e13">

Or

Entity EXAMPLE:

<owl:Class rdf:about="&ap999v1;2a69f900-079c-0136-76fe-00ff90f87e13">
Class Subclass (rdfs:subclassof) mandatory property

For each new class added to the RDL the parent class (or superclass) shall be identified. Every class shall be a descendent of one of the core classes (defined in STEPlibCore_modelrefdatacore_v1.owl). It is possible for a class to 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.

NOTE: Members of the new class are, by definition, members of all the identified superclasses.

<owl:Class rdf:about="{...}">
    <rdfs:subClassOf rdf:resource="{IRIorCorrespondingEntityForParentClass}{guid}"/>
</owl:Class>

EXAMPLE:

<rdfs:subClassOf rdf:resource="&corerdv1;2a69f900-079c-0136-76fe-00ff90f87e13">

Labels are used to provide human readable identification in the desired language. The provided label shall be written in lower-case only, and may consist of more than one word separated by spaces. SKOS elements are used to provide this capability and the following are allowed:

Class Preferred label (skos:preflabel) mandatory property

A preferred label is the label that is favoured and shall be provided.

<owl:Class rdf:about="{...}">
    <skos:prefLabel xml:lang="en">{preferred_label}</skos:prefLabel>
</owl:Class>

EXAMPLE:

<skos:prefLabel xml:lang="en">widget</skos:prefLabel>
Class Alternative label (skos:altlabel)

One or more alternative labels can be specified. These are synonyms of the preferred label.

<owl:Class rdf:about="{...}">
    <skos:altlabel xml:lang="en">{alternative_label}</skos:altlabel>
</owl:Class>

EXAMPLE:

<skos:prefLabel xml:lang="en">gizmo</skos:prefLabel>
Class Deprecated label (skos:hiddenlabel)

This element provides the capability of listing labels that for one reason or another should not be used for the class.

NOTE: The use of rdfs:label is not permitted.

<owl:Class rdf:about="{...}">
    <skos:hiddenlabel xml:lang="en">{hidden_label}</skos:hiddenlabel>
</owl:Class>

EXAMPLE:

<skos:prefLabel xml:lang="en">thingamabob</skos:prefLabel>

A class might represent either an information model related concept or a terminological concept, or both.

Class Definition (skos:definition)

A definition should be added to all classes capturing terminological concepts.

<owl:Class rdf:about="{...}">
     <skos:definition xml:lang="en">{formal_definition_or_link_to_definition}</skos:definition>
</owl:Class>

EXAMPLE:

<skos:definition xml:lang="en">http://www.gizmopedia.org/ref=99-123</skos:definition>
Class Description (rdfs:comment) mandatory property

A description should be added for all classes.

There can be a maximum of one description and one definition in each class. They should be formatted according to the following rules:

  • if the class has a superclass other than STEPThing, then the text should start with the preferred label of the superclass of the class;
  • the text should be written in all lower case;
  • ideally, none of the (new) text of the preferred label for the class should be used in the text in the description;
  • the text should be written in a single sentence and in a way that it can replace the label in a sentence while keeping the sentence syntactically correct;
  • thus, there should be no full-stop at the end of the description.
<owl:Class rdf:about="{...}">
     <skos:prefLabel xml:lang="en">{preferred_label_of_super_class}</skos:prefLabel>
</owl:Class>

<owl:Class rdf:about="{...}>">
     <skos:comment xml:lang="en">{preferred_label_of_super_class>that<description_of_this_class}</skos:comment>
</owl:Class>

EXAMPLE:

<skos:prefLabel xml:lang="en">plastic widget</skos:prefLabel>
<skos:comment xml:lang="en">widget that is made from a synthetic organic polymer</skos:comment>
Class Source (dc:source)

If the text of a description or definition has been copied from elsewhere, or derived from a definition provided elsewhere, or is a hyperlink to a definition provided elsewhere, the original source should be specified.

Todo

should this have a lang like the Ontology Source (dc:source)?

<owl:Class rdf:about="{...}">
     <dc:source>{source}</dc:source>
</owl:Class>

EXAMPLE:

<dc:source>ISO 10303-999</dc:source>

Notes and examples may be provided for the class to add further clarity to the descriptions and definitions.

Class Note (skos:note)

Comments augment the information provided in the description or definition of a class.

<owl:Class rdf:about="{...}">
    <skos:note xml:lang="en">{note}</skos:note>
</owl:Class>

EXAMPLE:

<skos:note>Plastic widgets are not suitable for high-temperature environments.</skos:note>
Class Example (skos:example)

Examples are valuable for adding clarity to the meaning of the class.

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 full-stop.

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.

<owl:Class rdf:about="{...}">
    <skos:example xml:lang="en">{example}</skos:example>
</owl:Class>

EXAMPLE:

<skos:example xml:lang="en">My Pingu egg cup.</skos:example>
Class Creator (dc:creator) mandatory property

The creator is the person who created the class.

The creator should be specified with theirfull name and company/organization affiliation.

<owl:Class rdf:about="{...}">
    <dc:creator xml:lang="en">{creator_name_and_affiliation}</dc:creator>
</owl:Class>

EXAMPLE:

<dc:creator xml:lang="en">Phil Spiby, Eurostep</dc:creator>
Class Contributor (dc.contributor)

A contributor is anyone who at any time has edited the class. One dc:contributor element is created for each editor.

The contributor should be specified with their full name and company/organization affiliation.

<owl:Class rdf:about="{...}">
    <dc.contributor xml:lang="en">{contributor_name_and_affiliation}</dc.contributor>
</owl:Class>

EXAMPLE:

<dc:contributor xml:lang="en">Mike Ward, Eurostep</dc:contributor>
Class Creation date (dc:date) mandatory property

The date when the class was created.

<owl:Class rdf:about="{...}">
    <dc.date>{date}</dc.date>
</owl:Class>

EXAMPLE:

<dc:date>2019-03-29</dc:date>
Class Status (dc:type) mandatory property

The publication status of the class is represented using the dc:type annotation.

<owl:Class rdf:about="{...}">
    <dc:type>{status}</dc:type>
</owl:Class>

NOTE: This is not qualified by a language code since this is language independent.

NOTE: The possible values are:

  • Created
  • InWork
  • ReadyForReview
  • PassedReview
  • Approved
  • InUse
  • Cancelled

EXAMPLE:

<dc:type>InWork</dc:type>
Class Version (owl:versionInfo) mandatory property

When a class is added to an ontology the version of the ontology at the time that the class was added should be recorded. This allows the tracking of which classes were added from one version to next.

<owl:Class rdf:about="{...}">
    <owl:versionInfo>{version}</owl:versionInfo>
</owl:Class>

NOTE: This property should not be qualified by a language code since this is language independent.

EXAMPLE:

<owl:versionInfo>v1</owl:versionInfo>
Class Change Note (skos:changeNote) mandatory property

Every time a class is edited, the change to the class should be documented as an additional change note using the same format below:

<owl:Class rdf:about="{...}">
    <skos:changeNote xml:lang="en"><[{date{}] {editor_name}, {organization}: {description_of_change}</skos:changeNote>
</owl:Class>

EXAMPLE:

<skos:changeNote xml:lang="en">[2019-03-29] Mike Ward, Eurostep: spelling error “widjet” corrected to “widget” in preferredLabel element</skos:changeNote>

Reference Data individuals

For each new Individual to be added to the RDL, the Class that it is a member of shall 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.

NOTE: Members of a class are, by definition, members of all the superclasses of that class. If this is not the case then the class hierarchy should be re-considered.

NamedIndividual Identifier (rdf:about) mandatory property

The individual shall be given an GUID to allow it to be uniquely identified. The identifier for the individual is combined with the IRI (or the corresponding entity ) for the RDL in which it is defined to create the identifier for the individual.

<owl:NamedIndividual rdf:about="{IRIorCorrespondingEntity}{guid}">

EXAMPLE:

<owl:NamedIndividual rdf:about="&ap999;2a69f900-079c-0136-76fe-00ff90f87e13">
NamedIndividual of Class (rdf:type rdf:resource) mandatory property

For each new individual added to the RDL, the class (or classes) that the individual is a member of shall be identified. Every individual shall be a member of a class descended from one of the core classes (defined in STEPlibCore_modelrefdatacore_v1.owl). It is possible for an individual to belong to more than one class.

<owl:NamedIndividual rdf:about="{...}">
    <rdf:type rdf:resource="{IRIorCorrespondingEntity}{class_guid}"/>
</owl:NamedIndividual>

EXAMPLE:

<rdf:type rdf:resource="&corev1;8659a670-130a-0135-b552-598f1b1392ae">

Labels are used to provide human readable identification in the desired language. The provided label shall be written in lower-case only, and may consist of more than one word separated by spaces. SKOS elements are used to provide this capability and the following are allowed:

NamedIndividual Preferred label (skos:preflabel) mandatory property

A preferred label is the label that is favoured and shall be provided.

<owl:NamedIndividual rdf:about="{...}">
     <skos:prefLabel xml:lang="en">{preferred_label}</skos:prefLabel>
</owl:NamedIndividual>

EXAMPLE:

<skos:prefLabel xml:lang="en">my widget</skos:prefLabel>
NamedIndividual Alternative label (skos:altlabel)

One or more alternative labels can be specified. These are synonyms of the preferred label.

<owl:NamedIndividual rdf:about="{...}">
    <skos:altlabel xml:lang="en">{alternative_label}</skos:altlabel>
</owl:NamedIndividual>

EXAMPLE:

<skos:prefLabel xml:lang="en">my gizmo</skos:prefLabel>
NamedIndividual Deprecated label (skos:hiddenlabel)

This element provides the facility for listing labels that for one reason or another should not be used for the individual.

NOTE: The use of rdfs:label is not permitted.

<owl:NamedIndividual rdf:about="{...}">
    <skos:hiddenlabel xml:lang="en">{hidden_label}</skos:hiddenlabel>
</owl:NamedIndividual>

EXAMPLE:

<skos:prefLabel xml:lang="en">thingamabob</skos:prefLabel>
NamedIndividual Definition (skos:definition)

A definition should be added to all individuals that represent terminological concepts.

<owl:NamedIndividual rdf:about="{...}">
    <skos:definition xml:lang="en">{formal_definition_or_link_to_definition}</skos:definition>
</owl:NamedIndividual>

EXAMPLE:

<skos:definition xml:lang="en">http://www.gizmopedia.org/ref=01-345</skos:definition>
NamedIndividual Description (rdfs:comment) mandatory property

A description should be provided for all individuals.

<owl:NamedIndividual rdf:about="{...}">
    <skos:prefLabel xml:lang="en">{preferred_label_of_class}</skos:prefLabel>
</owl:NamedIndividual>

<owl:NamedIndividual rdf:about="{...}">
    <skos:comment xml:lang="en">individual of the class (classes) {preferred_label(s)_of_class(classes)}></skos:comment>
</owl:NamedIndividual>

EXAMPLE:

<skos:prefLabel xml:lang="en">widget</skos:prefLabel>
<skos:comment xml:lang="en">individual of the class widget</skos:comment>
NamedIndividual Source (dc:source)

If the text of a description or definition has been copied from elsewhere, or derived from a definition provided elsewhere, or is a hyperlink to a definition provided elsewhere, the original source should be specified.

Todo

should this have a lang like the Ontology Source (dc:source)?

<owl:NamedIndividual rdf:about="{...}">
    <dc:source>{source}</dc:source>
</owl:NamedIndividual>

EXAMPLE:

<dc:source>ISO 10303-999</dc:source>

Notes and examples may be provided for the individual to add further clarity to the descriptions and definitions.

NamedIndividual Note (skos:note)

Comments augment the information provided in the description or definition of an individual.

<owl:NamedIndividual rdf:about="{...}">
     <skos:note xml:lang="en">{note}</skos:note>
</owl:NamedIndividual>

EXAMPLE:

<skos:note>My widget is obsolete.</skos:note>
NamedIndividual Example (skos:example)

Examples are valuable for adding clarity to the meaning of the class.

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 full-stop.

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.

<owl:NamedIndividual rdf:about="{...}">
        <skos:example xml:lang="en">{example}</skos:example>
</owl:NamedIndividual>

EXAMPLE:

<skos:example xml:lang="en">My Pingu egg cup.</skos:example>
NamedIndividual Creator (dc:creator) mandatory property

The creator is the person who created the individual.

The creator should be specified with their full name and company/organization affiliation.

<owl:NamedIndividual rdf:about="{...}">
     <dc:creator xml:lang="en">{creator_name_and_affiliation}</dc:creator>
</owl:NamedIndividual>

EXAMPLE:

<dc:creator xml:lang="en">Phil Spiby, Eurostep</dc:creator>
NamedIndividual Contributor (dc.contributor)

A contributor is anyone who at any time has edited the individual. One dc:contributor element is created for each editor.

The contributor should be specified with their full name and company/organization affiliation.

<owl:NamedIndividual rdf:about="{...}">
        <dc.contributor xml:lang="en">{contributor_name, affiliation}</dc.contributor>
</owl:NamedIndividual>

EXAMPLE:

<dc:contributor xml:lang="en">Mike Ward, Eurostep</dc:contributor>
NamedIndividual Creation Date (dc:date) mandatory property

The date when the individual was created.

<owl:NamedIndividual rdf:about="{...}">
    <dc.date xml:lang="en">{date}</dc.date>
</owl:NamedIndividual>

EXAMPLE:

<dc:date>2019-03-29</dc:date>
NamedIndividual Status (dc:type) mandatory property

The publication status of the individual is represented using the dc:type annotation.

<owl:NamedIndividual rdf:about="{...}">
    <dc:type>{status}</dc:type>
</owl:NamedIndividual>

NOTE: This is not qualified by a language code since this is language independent.

NOTE: The possible values are: * Created * InWork * ReadyForReview * PassedReview * Approved * InUse * Cancelled

EXAMPLE:

<dc:type>InWork</dc:type>
NamedIndividual Version (owl:versionInfo) mandatory property

When an individual is added to an ontology the version of the ontology at the time that the individual was added should be recorded. This allows the tracking of which individuals were added from one version of the ontology to the next.

<owl:NamedIndividual rdf:about="{...}">
    <owl:versionInfo>{version}</owl:versionInfo>
</owl:NamedIndividual>

NOTE: This property should not be qualified by a language code since this is language independent.

EXAMPLE:

<owl:versionInfo>v1</owl:versionInfo>
NamedIndividual Change Note (skos:changeNote) mandatory property

Every time an individual is edited, the change to the individual should be documented as an additional change note using the same format below:

<owl:NamedIndividual rdf:about="{...}">
    <skos:changeNote xml:lang="en"><[{date}] {editor_name}, {organization}: {description_of_change}</skos:changeNote>
</owl:NamedIndividual>

EXAMPLE:

<skos:changeNote xml:lang="en">[2019-03-29] Mike Ward, Eurostep: spelling error “my widjet” corrected to “me widget” in prefLabel element</skos:changeNote>

Step-by-step guide

Prerequists

GUID Generator

There is a free online GUID generator at: https://www.guidgenerator.com/.

This should be employed with the “Hyphens” check box selected:

../../_images/ht_rd_guid_generator.png

UUID from MagicDraw

There is a macro that will print the UUID of an item selected in the containment tree to the notifications window.

../../_images/ht_dmcore_getUUID.png

For how to load macros see Load Macros.

Protégé

Protégé can be downloaded freely from https://protege.stanford.edu/. registration is required.

Select “PRODUCTS” and then “Older versions” of go to https://protegewiki.stanford.edu/wiki/Protege_Desktop_Old_Versions.

Version 4.3.0 is known to work with STEPlib and it is recommended to download the version that includes a Java VM.

XML editor

There are many dedicated XML packages or text editors that are can be used for editing XML e.g.

Browse the Core Reference Data

  1. Launch Protégé, select File > Open….

    ../../_images/ht_rd_open_protege.png

    Navigate to Core RDL

  2. Navigate to STEPlib\Core_model\refdata, select core_rd_v1.owl, and click Open

    ../../_images/ht_rd_open_file.png

    Open Core Reference Data

  3. If the following dialogue appears, simply click OK (This is a minor bug in this version of Protégé).

    ../../_images/ht_rd_ignore_error.png

    Error Message

    Todo

    other error messages for resolve missing import

  4. Select the Entities tab in the resulting dialogue and browse the tree of core STEPlib reference data classes.

    • The classes displayed in normal text are from the core_v1.owl file and they correspond to blocks in the Core Model.
    • The classes displayed in bold text are from the core_rd_v1.owl file and are additional RDL classes agreed on for use in the harmonized AP242 and AP239 model. Only these classes are used in classifications.
    ../../_images/ht_rd_core_entities.png

    Explore the Entities in the core_rd_v1

You will note that Protégé has created a STEPlib\Core_model\refdata\catalog-v001.xml file with the following content:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<catalog prefer="public" xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
        <group id="Folder Repository, directory=, recursive=true, Auto-Update=true, version=2" prefer="public" xml:base="">
                <uri id="Automatically generated entry, Timestamp=1566979296562" name="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1" uri="core_rd_v1.owl"/>
                <uri id="Automatically generated entry, Timestamp=1566979296562" name="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1" uri="core_v1.owl"/>
        </group>
</catalog>

Creating AP Reference Data

This section describes how to create a new AP-based English Language RDL using Protégé.

Creating the new OWL file

  1. Create a new file named ap{ap_number}_v1.owl in STEPlib\Application_protocols\AP{ap_number}\refdata\, where {ap_number} is the number of the AP, e.g. ap243
  2. Copy in the text below replacing {ap_number}, {my_date}, and {my_name} with suitable values
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
        <!ENTITY terms "http://purl.org/dc/terms/" >
        <!ENTITY owl "http://www.w3.org/2002/07/owl#" >
        <!ENTITY dc "http://purl.org/dc/elements/1.1/" >
        <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
        <!ENTITY skos "http://www.w3.org/2004/02/skos/core#" >
        <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
        <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
        <!ENTITY corev1 "http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1#" >
        <!ENTITY corerdv1 "http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1#" >
        <!ENTITY ap{ap_number}v1 "http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1" >
]>

<rdf:RDF xmlns="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1#"
         xml:base="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:owl="http://www.w3.org/2002/07/owl#"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:corev1="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1#"
         xmlns:skos="http://www.w3.org/2004/02/skos/core#"
         xmlns:corerdv1="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1#"
         xmlns:ap{ap_number}v1="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1">
        <owl:Ontology rdf:about="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1">
                <dc:date xml:lang="en">{my_date}</dc:date>
                <dc:language>en</dc:language>
                <dc:source>ISO 10303-{ap_number}</dc:source>
                <rdfs:comment xml:lang="en">This ontology is the reference data for ISO 10303-{ap_number}.</rdfs:comment>
                <owl:versionInfo>v1</owl:versionInfo>
                <dc:coverage xml:lang="en">Reference data relating to a single AP.</dc:coverage>
                <dc:type>WD</dc:type>
                <dc:creator xml:lang="en">{my_name}</dc:creator>
                <owl:imports rdf:resource="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1"/>
        </owl:Ontology>

</rdf:RDF>

  1. Create a new file named catalog-v001.xml in STEPlib\Application_protocols\AP{ap_number}\refdata\, where {ap_number} is the number of the AP, e.g. ap243

  2. Copy in the text below replacing {ap_number}, {my_drive_letter}, and {my_local_path} with suitable values:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<catalog prefer="public" xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
        <uri id="User Entered Import Resolution" name="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1" uri="file:/{my_drive_letter}:/{my_local_path}/STEPlib/Core_model/refdata/core_v1.owl"/>
        <uri id="User Entered Import Resolution" name="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1" uri="file:/{my_drive_letter}:/{my_local_path}/STEPlib/Core_model/refdata/core_rd_v1.owl"/>
        <group id="Folder Repository, directory=, recursive=true, Auto-Update=true, version=2" prefer="public" xml:base="">
                <uri id="Automatically generated entry, Timestamp=1554323905527" name="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1" uri="ap{ap_number}_v1.owl"/>
        </group>
</catalog>

Todo

This seems a bit risky, very easy to do a typo. Is there not a way to do it in the UI?

  1. Launch Protégé.

  2. Open the new owl file: STEPlib\Application_protocols\AP{ap_number}\refdata\ap{ap_number}_v1.owl

  3. Select the Entities tab

  4. Expand STEPthing

    ../../_images/ht_rd_entities.png

    Navigate to Core RDL classes

Decide if Class or Individual

Reference data representing a block uses RDL Class. Otherwise Reference data can be either classes or named individuals depending on whether the entity is mapped to Class/ClassSelect or Proxy/ProxyItemSelect respectively

../../_images/ht_rd_choice.png

Figure 37 Navigate to Core RDL classes

Creating RDL classes

This section describes how to create a new RDL Class using Protégé.

Classes should only be created below sub-classes of STEPthing. This example shows how to create a new AP RDL class under the existing approving person organization class.

  1. Select class approving person organization and click add-subclass:

    ../../_images/ht_rd_new_class.png

    Create new subclass

  2. A dialogue will appear. Either:

    • Use a UUID from a suitable object in the SysML model (using the Get UUID macro see UUID from MagicDraw ), and click OK. This example uses the UUID of the public reference property.

      ../../_images/ht_rd_guid_md.png

      Use UUID from a SysML object

    • Generate a GUID, paste it into the Name field, and click OK. Note: if this metho is used then the GUID will need to be copied into the mapping.

      ../../_images/ht_rd_insert_guid.png

      Use new GUID

  3. The new class will appear in Protégé identified by its GUID.

  4. Select Annotations; Expand label; Select prefLabel;

    • Type the preferred label in the Value field.
    • Select “en” (or other language) in the Lang field.
    • Click OK
    ../../_images/ht_rd_preflabel.png

    Add preferred label

  5. The class will now be identified by its preferred label.

    ../../_images/ht_rd_display_preflabel.png

    Display preferred label

Tip

If the preflabel is not displayed, go View > Render by annotation property and select prefLabel.

Add remaining annotations

The remaining class annotations should be added using the same procedure

See Reference Data Classes for details of annotations.

Automatically created when class created:

Mandatory:

Optional:

RDL Class finished

The image below shows the RDL Class with all the mandatory annotations populated.

../../_images/ht_rd_cl_finish.png

Figure 38 RDL Class with mandatory annotations

Creating RDL individuals

This section describes how to create a new RDL individuals using Protégé.

Individuals should only be created below sub-classes of STEPthing. This example shows how to create a new AP RDL class called “approval status failed” under the “State” class.

  1. Select Individuals by Class tab and select the class state > state observed.

  2. On the Individuals panel, Click on the diamond shape and a dialogue will appear

  3. Enter a GUID for the individual, and click OK. Either:

    • Use a UUID from a suitable object in the SysML model (using the Get UUID macro see UUID from MagicDraw ), and click OK. This example uses the UUID of the Enumeration Literal.

      ../../_images/ht_rd_individualMD.png

      Add an individual

    • Or use the GUID generator (see GUID Generator)

      ../../_images/ht_rd_individual.png

      Add an individual

  4. Select my_ap_activity_001 in the list of Individuals and click Annotations +

  5. Select prefLabel and type the name of the individual

  6. Select “en” in the Lang field and click OK.

    ../../_images/ht_rd_individual_preflabel.png

    Create preferred label for individual

Add remaining annotations

The remaining NamedIndividual annotations should be added using the same procedure

See Reference Data individuals for details of annotations.

Automatically created when class created:

Mandatory:

Optional:

RDL Individual finished

The image below shows the RDL Individual with all the mandatory annotations populated.

../../_images/ht_rd_ind_finish.png

Figure 39 RDL Individual with mandatory annotations

Creating alternative language AP Reference Data

This section describes how to create a new AP-based alternative Language RDL using Protégé.

Creating the new OWL file

  1. Create a new file named ap{ap_number}_{my_language_code}_v1.owl in STEPlib\Application_protocols\AP{ap_number}\refdata, where {ap_number} is the number of the AP, e.g. ap243 and {my_language_code} is a language code e.g. sv.
  2. Copy in the text below replacing {ap_number}, {my_date}, {my_name}, {my_comment_text_in_my_language}, and {my_coverage_text_in_my_language} with suitable values
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
        <!ENTITY owl "http://www.w3.org/2002/07/owl#" >
        <!ENTITY dc "http://purl.org/dc/elements/1.1/" >
        <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
        <!ENTITY skos "http://www.w3.org/2004/02/skos/core#" >
        <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
        <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
        <!ENTITY ap{ap_number}v1 "http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1#" >
        <!ENTITY ap{ap_number}{my_language_code}v1 "http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_{my_language_code}_v1#" >
        <!ENTITY corev1 "http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1#" >
        <!ENTITY corerdv1 "http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1#" >
]>

<rdf:RDF xmlns="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_{my_language_code}_v1#"
         xml:base="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_{my_language_code}_v1"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:owl="http://www.w3.org/2002/07/owl#"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ap{ap_number}{my_language_code}v1="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_{my_language_code}_v1#"
         xmlns:ap{ap_number}v1="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1#"
         xmlns:corev1="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1#"
         xmlns:skos="http://www.w3.org/2004/02/skos/core#"
         xmlns:corerdv1="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1#">
        <owl:Ontology rdf:about="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_{my_language_code}_v1">
                <dc:date xml:lang="{my_language_code}">{my_date}</dc:date>
                <rdfs:comment xml:lang="{my_language_code}">{my_comment_text_in_my_language} l&apos;ISO 10303-{ap_number}.</rdfs:comment>
                <dc:language>{my_language_code}</dc:language>
                <owl:versionInfo>v1</owl:versionInfo>
                <dc:type>WD</dc:type>
                <dc:source>ISO 10303-{ap_number}</dc:source>
                <dc:coverage xml:lang="{my_language_code}">{my_coverage_text_in_my_language}</dc:coverage>
                <dc:creator xml:lang="en">{my_name}</dc:creator>
                <owl:imports rdf:resource="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1"/>
        </owl:Ontology>
</rdf:RDF>

  1. Open the file named catalog-v001.xml in STEPlibApplication_protocolsAP{ap_number}, where {ap_number} is the number of the AP, e.g. ap243

  2. Replace the content with the text below replacing {ap_number}, {my_language_code}, {my_drive_letter}, and {my_local_path} with suitable values:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<catalog prefer="public" xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
        <uri id="User Entered Import Resolution" name="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_v1" uri="file:/{my_drive_letter}:/{my_local_path}/STEPlib/Core_model/refdata/core_v1.owl"/>
        <uri id="User Entered Import Resolution" name="http://standards.iso.org/iso/10303/-4000/tech/refdata/core_rd_v1" uri="file:/{my_drive_letter}:/{my_local_path}/STEPlib/Core_model/refdata/core_rd_v1.owl"/>
         <uri id="User Entered Import Resolution" name="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_v1" uri="file:/{my_drive_letter}:/{my_local_path}/Application_protocols/AP{ap_number}/refdata/ap{ap_number}_v1.owl"/>

        <group id="Folder Repository, directory=, recursive=true, Auto-Update=true, version=2" prefer="public" xml:base="">
                <uri id="Automatically generated entry, Timestamp=1554323905527" name="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap{ap_number}_{my_language_code}_v1" uri="ap{ap_number}_{my_language_code}_v1.owl"/>
<uri id="Automatically generated entry, Timestamp=1554473746619" name="http://standards.iso.org/iso/10303/-{ap_number}/tech/refdata/ap999_{my_language_code}_v1" uri="ap{ap_number}_{my_language_code}_v1.owl"/>
        </group>
</catalog>

Todo

check the above.

Amending RDL classes with additional language

This section describes how to amend RDL classes with additional language annotations using Protégé

Todo

check en in filename

Annotations should only be added to sub-classes of STEPthing that exist in the file /STEPlib/Application_protocols/AP{ap_number}/refdata/ap{ap_number}_v1.owl

This example shows how to create an alternative language annotation for AP RDL class called “My AP activity”.

  1. Select the existing my AP activity class and select Annotations +

  2. Select prefLabel and type the alternative text then select the correct language code, and hit OK.

    ../../_images/ht_rd_language.png

    Add an alternative language annotation to an RDL class

Tip

Other non-English language annotations can be added in a similar fashion.

Amending RDL individuals with additional language

This section describes how to amend RDL individuals with additional language annotations using Protégé

Todo

check en in filename

Annotations should only be added to individuals of sub-classes of STEPthing that exist in the file /STEPlib/Application_protocols/AP{ap_number}/refdata/ap{ap_number}_v1.owl

This example shows how to create an alternative language annotation for AP RDL individual called “my AP activity 001”.

  1. Select the existing my AP activity 001 individual, select Annotations +

  2. Select prefLabel, type the alternative text, select the correct language code, and hit OK.

    ../../_images/ht_rd_language_annotation.png

    Navigate to individual to add language annotation

  3. Select Annotations +

  4. Select prefLabel, type the alternative text, select the correct language code, and hit OK.

    ../../_images/ht_rd_language_annotation_individual.png

    Add an alternative language annotation to an RDL individual

Tip

Other non-English language annotations can be added to RDL individuals in a similar fashion.

Auto Generation of Reference Data as OWL for AP243

see also STEPlib SysML: How To use the Reference Data (OWL) Scripts

The following explains how the stylesheet extracts the reference data from the AP243 domain model and saves it as OWL. It has also explains the assumptions about the structure and naming convension used.

The export has the following sections:

Tip

The stylesheet starts from a packagedElement that has an attribute name=’Domain_model’

The following mapping rules are assumed by the extraction stylesheet:

  • All reference data uses either ExternalOwlClass or ExternalOwlObject from the core model as the type

    • search string is set as the “ExternalOwlName” param at the start of the stylesheet

  • The same constraint block is used for all combined classifications constraint properties, and the same (out) flow port is bound (using a binding connector) to the core model object to be used as the subClassOf

    • the xmi:id of this flow port is set as the param “combinedId” at the start of the stylesheet

  • The same (inherited) private part property (named “classifiedAs”) is used for all single classifications, and this is bound (using a binding connector) to the core model object to be used as the subClassOf

    • the xmi:id of this private part property is set as the “classifiedAsId” param at the start of the stylesheet

  • The name of the template reference properrty for classification is “templateOwlClass” (this is used to exclude the template classification from the association classification)

  • Enumerations have a property named “value” that is of core model type ExternalOwlClass or ExternalOwlObject

  • Where the mapping of status Enumerations is to StateDefinition, a common block is used rather than replicating the mapping for each template. The stateSelect property of this is used to identify the status Enumerations

    • the xmi:id of this stateSelect property is set as the “StateSelectId” param at the start of the stylesheet

  • For Classification Enumerations, their “value” property is mapped to the property “Class” of the core object “Classification”.

    • the string “Classification::Class” is set as the “classificationClassName” param at the start of the stylesheet

  • All Enumeration Literals have a slot for the “value” that is set to an Instance Specification

Templates

In AP243 all templates have the ClassifiedAs property. In the mapping to the Core Model this is bound to the ClassifiedAs of the most significant Core model template either directly or via the “CombinedClassification” constraint block. This is used to identify reference data for the template owl.Class.

The following are extracted from the SysML for the owl:Class:

  • The prefLabel (and rdf:about) is the name of the template block.
  • The subClassOf is identified by the object connected to either the “combined” port of the CombinedClassification constraint block, or connected to the inherited “classifiedAs” property. The connected object name is found using the MagicDraw extension tag referenceExtension attribute referentPath
  • The comment is the documentation from the block.

Example:

<owl:Class rdf:about="&AP243-rdl;KeyValueType">
        <skos:prefLabel xml:lang="en">KeyValueType</skos:prefLabel>
        <rdfs:subClassOf rdf:resource="&corev1;Part"/>
        <rdfs:comment xml:lang="en">Defines a key piece of information ...</rdfs:comment>
        ...
</owl:Class>

Enumerations

Enumerations mapped to Classification using ExternalOwlClass

Enumerations used as classification have their “value” property bound (using a binding connector) to the property “Class” of the core object “Classification”. This is identified using the MagicDraw extension tag referenceExtension attribute referentPath. The Literals for the status are also owl:Class.

The following are extracted from the SysML for the Enumeration owl:Class:

  • The prefLabel (and rdf:about) is the name of the Enumeration.
  • The subClassOf is identified by locating the objects that have properties that are of the Enumeration type. These are all listed as subClassOf.
  • The comment is the documentation from the Enumeration.

The following are extracted from the SysML for the Enumeration Literals owl:Class:

  • The prefLabel (and rdf:about) is the name of the Instance Specification used as the slot for “value”. (This assumes use of the naming convention of enumName_literal_name)
  • The subClassOf is the Enumeration
  • The comment is the documentation from the Enumeration Literal.

Example:

<owl:Class rdf:about="&AP243-rdl;StudyTypeEnum">
        <skos:prefLabel xml:lang="en">StudyTypeEnum</skos:prefLabel>
        <rdfs:subClassOf rdf:resource="&AP243-rdl;Study"/>
        <rdfs:comment xml:lang="en">This is ...</rdfs:comment>
        ...
</owl:Class>
<!--Enumeration Literal: StudyTypeEnum Literal design InstanceSpecification: studyTypeEnum_design-->
<owl:Class rdf:about="&AP243-rdl;studyTypeEnum_design">
        <skos:prefLabel xml:lang="en">studyTypeEnum_design</skos:prefLabel>
        <rdfs:subClassOf rdf:resource="StudyTypeEnum"/>
        ...
</owl:Class>

Enumerations mapped to State Definition

Enumerations mapped to StateDefinition are identifed as those bound (using a binding connector) to the stateStelect property of a common block. The Literals for the status are owl:NamedIndividual.

The following are extracted from the SysML for the Enumeration owl:Class:

  • The prefLabel (and rdf:about) is the name of the Enumeration.
  • The subClassOf is hardcoded to AP243-rdl;StatusDefinition which is included at the start of the file.
  • The comment is the documentation from the Enumeration.

The following are extracted from the SysML for the Enumeration Literals owl:NamedIndividual:

  • The rdf:about is the name of the Instance Specification used as the slot for “value”. (This assumes use of the naming convention of enumName_literal_name)
  • The prefLabel is the name of the Enumeration Literal
  • The rdf:type rdf:resource is the Enumeration
  • The comment is the documentation from the Enumeration Literal.

Example:

<owl:Class rdf:about="&AP243-rdl;VerificationStatusEnum">
        <skos:prefLabel xml:lang="en">VerificationStatusEnum</skos:prefLabel>
        <rdfs:subClassOf rdf:resource="&AP243-rdl;StatusDefinition"/>
        <rdfs:comment xml:lang="en">This is the ...</rdfs:comment>
        ...
</owl:Class>
<!-- VerificationStatusEnum Literal to_be_verified InstanceSpecification: verificationStatusEnum_to_be_verified-->
<owl:NamedIndividual rdf:about="&AP243-rdl;verificationStatusEnum_to_be_verified">
        <rdf:type rdf:resource="&AP243-rdl;VerificationStatusEnum"/>
        <skos:prefLabel xml:lang="en">to_be_verified</skos:prefLabel>
        ...
</owl:NamedIndividual>

Enumerations mapped to other roles

Todo

These are not yet included in the reference data - need to determine how they should be represented

Associations

This looks for block properties that are mapped to something outside of this model - this is done by selecting those that have a descendent with a tag of referenceExtension (which is a MagicDraw extension).

Of these it ignores properties that are:

  • enumerations (see Enumerations)
  • named “templateOwlClass” - these are assumed to be templates (see Templates)
  • named ‘classifiedAs’ (this is a domain level property)
  • mapped to ExternalOwlObject (these are to do).

For those that are mapped to ExternalOwlClass (anything else ignored) it then generates the owl:Class with the following:

  • prefLabel (and rdf:about): this assumes that the name of the attibute is follows the convention of the xxxOwlClass where xxx is the name of the association. It then appends this (without the OwlClass) to the name of the template. e.g. ModelType_inheritsFrom
  • subClassOf: works out which element they are mapped to uses this as the subClassOf

Example:

<owl:Class rdf:about="&AP243-rdl;ModelType_inheritsFrom">
        <skos:prefLabel xml:lang="en">ModelType_inheritsFrom</skos:prefLabel>
        <rdfs:subClassOf rdf:resource="&corev1;PartVersionRelationship"/>
        ...
</owl:Class>

Todo

Association mapped to ExternalOwlObject - need to determine how they should be represented

Section author: Mike Ward