.. comment all inline tags to start with _how_rd_ .. index:: pair: Reference Data; How to .. _how_rd_top: How to model the Reference Data STEPLIB ######################################## .. include:: /pages/common/pageunderconstruction.txt :start-line: 3 .. seealso:: :doc:`howtoMapDMtoCore` : :ref:`how_dmcore_combined_classification` .. contents:: :local: :depth: 1 :backlinks: top ************* 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 *********** .. contents:: :local: :depth: 1 :backlinks: top ========= RDL files ========= Reference Data Libraries (:term:`RDL` s) are (optionally) developed per |AP|. :numref:`how_rd_arch_fig` 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):: 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\\ | corev1 | http://standards.iso.org | http://standards.iso.org | | | refdata\\core_v1.owl | | /iso/10303/ | /iso/10303/ | | | | | -4000/tech/refdata/ | -4000/tech/refdata/ | | | | | core_v1.owl | core_v1 | +---------------------------+-------------------------+-------------+--------------------------+--------------------------+ | Core RD | STEPlib\\Core_model\\ | corerdv1 | http://standards.iso.org | http://standards.iso.org | | | refdata\\core_rd_v1.owl | | /iso/10303/ | /iso/10303/ | | | | | -4000/tech/refdata/ | -4000/tech/refdata/ | | | | | core_rd_v1.owl | core_rd_v1 | +---------------------------+-------------------------+-------------+--------------------------+--------------------------+ | AP 999 | STEPlib\\ | ap999v1 | http://standards.iso.org | http://standards.iso.org | | | Application_protocols\\ | | /iso/10303/ | /iso/10303/ | | | AP999\\ | | -999/tech/refdata | -999/tech/refdata | | | refdata\\ap999_v1.owl | | /ap999_v1.owl | /ap999_v1 | +---------------------------+-------------------------+-------------+--------------------------+--------------------------+ | AP 999 | STEPlib\\ | ap999frv1 | http://standards.iso.org | http://standards.iso.org | | language extension | Application_protocols\\ | | /iso/10303/ | /iso/10303/ | | | AP999\\refdata\\ | | -999/tech/refdata | -999/tech/refdata | | | ap999_fr_v1.owl | | /ap999_fr_v1.owl | /ap999_fr_v1 | +---------------------------+-------------------------+-------------+--------------------------+--------------------------+ | Other business context | STEPlib\\ | myctxv1 | http://my_org | http://my_org | | | Business_contexts\\ | | /my_context/ | /my_context/ | | | My_Context\\refdata | | refdata/ | refdata/ | | | \\my_context_v1.owl | | my_context_v1.owl | my_context_v1 | +---------------------------+-------------------------+-------------+--------------------------+--------------------------+ | OBC | STEPlib\\ | myctxrdfrv1 | http://my_org | http://my_org | | language extension | Business_contexts | | /my_context/ | /my_context/ | | | \\My_Context\\refdata\\ | | refdata/ | refdata/ | | | my_context_rd_fr_v1.owl | | my_context_fr_v1.owl | my_context_fr_v1 | +---------------------------+-------------------------+-------------+--------------------------+--------------------------+ .. _how_rd_arch_fig: .. figure:: /images/howto/ht_rd_architecture.png :scale: 100% 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. .. contents:: :local: :depth: 2 :backlinks: top -------------- 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:: EXAMPLE:: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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:: {description of the scope of the RDL} EXAMPLE:: The classifiable objects from AP999. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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:: {lang} EXAMPLE:: en .. _how_rd_ont_source: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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:: {source} EXAMPLE:: ISO 10303-4000 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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:: {version} .. note:: This should not be qualified by a language code since this is language independent. EXAMPLE:: v1.0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ontology Status (dc:type) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The publication status of the RDL is represented with the dc:type annotation:: .. 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:: InWork ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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:: EXAMPLE:: Phil Spiby, Eurostep ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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:: 2019-03-29 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ontology Import (owl:imports) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The RDL import another RDL. This is represented using owl:imports annotation on the library.:: EXAMPLE:: Classes and individuals that have meaning in this context shall be declared within this RDL following the rules and guidelines specified below. .. index:: Reference Data; Class .. _how_rd_class: ---------------------- Reference Data Classes ---------------------- .. contents:: The content for owl:class are: :local: :depth: 1 :backlinks: top .. _how_rd_class_about: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: IRI EXAMPLE:: Or Entity EXAMPLE:: .. _how_rd_class_subclassof: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 STEPlib\Core_model\refdata\core_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. :: EXAMPLE:: 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: .. _how_rd_class_preflabel: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Class Preferred label (skos:preflabel) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A preferred label is the label that is favoured and shall be provided. :: {preferred_label} EXAMPLE:: widget .. _how_rd_class_altlabel: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Class Alternative label (skos:altlabel) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ One or more alternative labels can be specified. These are synonyms of the preferred label. :: {alternative_label} EXAMPLE:: gizmo .. _how_rd_class_hiddenlabel: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {hidden_label} EXAMPLE:: thingamabob A class might represent either an information model related concept or a terminological concept, or both. .. _how_rd_class_definition: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Class Definition (skos:definition) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A definition should be added to all classes capturing terminological concepts. :: {formal_definition_or_link_to_definition} EXAMPLE:: http://www.gizmopedia.org/ref=99-123 .. _how_rd_class_comment: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {preferred_label_of_super_class} {preferred_label_of_super_class>that EXAMPLE:: plastic widget widget that is made from a synthetic organic polymer .. _how_rd_class_source: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 :ref:`how_rd_ont_source`? :: {source} EXAMPLE:: ISO 10303-999 Notes and examples may be provided for the class to add further clarity to the descriptions and definitions. .. _how_rd_class_note: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Class Note (skos:note) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Comments augment the information provided in the description or definition of a class. :: {note} EXAMPLE:: Plastic widgets are not suitable for high-temperature environments. .. _how_rd_class_example: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {example} EXAMPLE:: My Pingu egg cup. .. _how_rd_class_creator: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {creator_name_and_affiliation} EXAMPLE:: Phil Spiby, Eurostep .. _how_rd_class_contributor: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {contributor_name_and_affiliation} EXAMPLE:: Mike Ward, Eurostep .. _how_rd_class_date: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Class Creation date (dc:date) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The date when the class was created. :: {date} EXAMPLE:: 2019-03-29 .. _how_rd_class_type: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Class Status (dc:type) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The publication status of the class is represented using the dc:type annotation. :: {status} 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:: InWork .. _how_rd_class_versioninfo: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {version} NOTE: This property should not be qualified by a language code since this is language independent. EXAMPLE:: v1 .. _how_rd_class_changenote: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: :: <[{date{}] {editor_name}, {organization}: {description_of_change} EXAMPLE:: [2019-03-29] Mike Ward, Eurostep: spelling error “widjet” corrected to “widget” in preferredLabel element .. index:: Reference Data; NamedIndividual .. _how_rd_individual: --------------------------- 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. .. _how_rd_individual_about: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: EXAMPLE:: .. _how_rd_individual_subclassof: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 STEPlib\Core_model\refdata\core_v1.owl). It is possible for an individual to belong to more than one class. :: EXAMPLE:: 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: .. _how_rd_individual_preflabel: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Preferred label (skos:preflabel) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A preferred label is the label that is favoured and shall be provided. :: {preferred_label} EXAMPLE:: my widget .. _how_rd_individual_altlabel: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Alternative label (skos:altlabel) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ One or more alternative labels can be specified. These are synonyms of the preferred label. :: {alternative_label} EXAMPLE:: my gizmo .. _how_rd_individual_hiddenlabel: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {hidden_label} EXAMPLE:: thingamabob .. _how_rd_individual_definition: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Definition (skos:definition) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A definition should be added to all individuals that represent terminological concepts. :: {formal_definition_or_link_to_definition} EXAMPLE:: http://www.gizmopedia.org/ref=01-345 .. _how_rd_individual_comment: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Description (rdfs:comment) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A description should be provided for all individuals. :: {preferred_label_of_class} individual of the class (classes) {preferred_label(s)_of_class(classes)}> EXAMPLE:: widget individual of the class widget .. _how_rd_individual_source: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 :ref:`how_rd_ont_source`? :: {source} EXAMPLE:: ISO 10303-999 Notes and examples may be provided for the individual to add further clarity to the descriptions and definitions. .. _how_rd_individual_note: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Note (skos:note) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Comments augment the information provided in the description or definition of an individual. :: {note} EXAMPLE:: My widget is obsolete. .. _how_rd_individual_example: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {example} EXAMPLE:: My Pingu egg cup. .. _how_rd_individual_creator: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {creator_name_and_affiliation} EXAMPLE:: Phil Spiby, Eurostep .. _how_rd_individual_contributor: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {contributor_name, affiliation} EXAMPLE:: Mike Ward, Eurostep .. _how_rd_individual_date: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Creation Date (dc:date) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The date when the individual was created. :: {date} EXAMPLE:: 2019-03-29 .. _how_rd_individual_type: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NamedIndividual Status (dc:type) mandatory property ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The publication status of the individual is represented using the dc:type annotation. :: {status} 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:: InWork .. _how_rd_individual_versioninfo: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. :: {version} NOTE: This property should not be qualified by a language code since this is language independent. EXAMPLE:: v1 .. _how_rd_individual_changenote: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: :: <[{date}] {editor_name}, {organization}: {description_of_change} EXAMPLE:: [2019-03-29] Mike Ward, Eurostep: spelling error “my widjet” corrected to “me widget” in prefLabel element ****************** Step-by-step guide ****************** .. contents:: The modelling steps are: :local: :depth: 2 :backlinks: top .. _how_rd_prereq: ================== Prerequists ================== .. _how_rd_GUIDgen: --------------- GUID Generator --------------- There is a free online GUID generator at: https://www.guidgenerator.com/. This should be employed with the “Hyphens” check box selected: .. figure:: /images/howto/ht_rd_guid_generator.png :scale: 100% .. _how_rd_UUIDMD: ------------------------------ UUID from MagicDraw ------------------------------ There is a macro that will print the UUID of an item selected in the containment tree to the notifications window. .. figure:: /images/howto/ht_dmcore_getUUID.png :scale: 100% For how to load macros see :ref:`gs_md_macros`. .. _how_rd_protege: --------------- 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. .. _how_rd_xmledit: --------------- XML editor --------------- There are many dedicated XML packages or text editors that are can be used for editing XML e.g. * Oxygen : https://www.oxygenxml.com/ * XMLSpy : https://www.altova.com/xmlspy-xml-editor * XML Copy Editor : http://xml-copy-editor.sourceforge.net/ * Notepad++ : https://notepad-plus-plus.org/ ==================================== Browse the Core Reference Data ==================================== #. Launch Protégé, select File > Open…. .. figure:: /images/howto/ht_rd_open_protege.png :scale: 100% Navigate to Core RDL #. Navigate to STEPlib\\Core_model\\refdata, select core_rd_v1.owl, and click Open .. figure:: /images/howto/ht_rd_open_file.png :scale: 100% Open Core Reference Data #. If the following dialogue appears, simply click OK (This is a minor bug in this version of Protégé). .. figure:: /images/howto/ht_rd_ignore_error.png :scale: 100% Error Message .. todo:: other error messages for **resolve missing import** #. 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. .. figure:: /images/howto/ht_rd_core_entities.png :scale: 100% 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:: .. index:: Reference Data; How to - Create AP RDL ========================== 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 ------------------------- #. 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 #. Copy in the text below replacing {ap_number}, {my_date}, and {my_name} with suitable values :: ]> {my_date} en ISO 10303-{ap_number} This ontology is the reference data for ISO 10303-{ap_number}. v1 Reference data relating to a single AP. WD {my_name} #. 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 #. Copy in the text below replacing {ap_number}, {my_drive_letter}, and {my_local_path} with suitable values:: .. todo:: This seems a bit risky, very easy to do a typo. Is there not a way to do it in the UI? #. Launch Protégé. #. Open the new owl file: STEPlib\\Application_protocols\\AP{ap_number}\\refdata\\ap{ap_number}_v1.owl #. Select the Entities tab #. Expand STEPthing .. figure:: /images/howto/ht_rd_entities.png :scale: 100% 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 :ref:`named individuals` depending on whether the entity is mapped to Class/ClassSelect or Proxy/ProxyItemSelect respectively .. figure:: /images/howto/ht_rd_choice.png :scale: 100% Navigate to Core RDL classes .. index:: Reference Data; How to - Create RDL Class .. _how_rd_htclass: ------------------------------------ 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. #. Select class **approving person organization** and click add-subclass: .. figure:: /images/howto/ht_rd_new_class.png :scale: 100% Create new subclass #. A dialogue will appear. Either: * Use a UUID from a suitable object in the SysML model (using the Get UUID macro see :ref:`how_rd_UUIDMD` ), and click OK. This example uses the UUID of the public reference property. .. figure:: /images/howto/ht_rd_guid_md.png :scale: 100% 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. .. figure:: /images/howto/ht_rd_insert_guid.png :scale: 100% Use new GUID #. The new class will appear in Protégé identified by its GUID. #. 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 .. figure:: /images/howto/ht_rd_preflabel.png :scale: 100% Add preferred label #. The class will now be identified by its preferred label. .. figure:: /images/howto/ht_rd_display_preflabel.png :scale: 100% Display preferred label .. tip:: If the preflabel is not displayed, go **View > Render by annotation property** and select **prefLabel**. .. rst-class:: expand ^^^^^^^^^^^^^^^^^^^^^^^^^ Add remaining annotations ^^^^^^^^^^^^^^^^^^^^^^^^^ The remaining class annotations should be added using the same procedure See :ref:`how_rd_class` for details of annotations. Automatically created when class created: * **Identifier**; * see :ref:`how_rd_class_about` * **Subclass** * see :ref:`how_rd_class_subclassof` Mandatory: * **Description** * entered using the **comment** annotation; * see :ref:`how_rd_class_comment` .. figure:: /images/howto/ht_rd_cl_comment.png :scale: 100% Add description (with language) * **Creator** * entered using the **creator** annotation; * see :ref:`how_rd_class_creator` .. figure:: /images/howto/ht_rd_cl_creator.png :scale: 100% Add creator (with language) * **Creation date** * entered using the **date** annotation; * see :ref:`how_rd_class_date` .. figure:: /images/howto/ht_rd_cl_date.png :scale: 100% Add date (no language) * **Status** * entered using the **type** annotation; * see :ref:`how_rd_class_type` .. figure:: /images/howto/ht_rd_cl_type.png :scale: 100% Add status (no language) * **Version** * entered using the **versionInfo** annotation; * see :ref:`how_rd_class_versioninfo` .. figure:: /images/howto/ht_rd_cl_version.png :scale: 100% Add version (no language) * **Change Note** * entered using the **changeNote** annotation; * see :ref:`how_rd_class_changenote` .. figure:: /images/howto/ht_rd_cl_change.png :scale: 100% Add change note (with language) Optional: * Alternative label * entered using the **altLabel** annotation; * see :ref:`how_rd_class_altlabel` * Deprecated label * entered using the **hiddenlabel** annotation; * see :ref:`how_rd_class_hiddenlabel` * Definition * entered using the **definition** annotation; * see :ref:`how_rd_class_definition` * Source * entered using the **source** annotation; * see :ref:`how_rd_class_source` * Note * entered using the **note** annotation; * see :ref:`how_rd_class_note` * Example * entered using the **example** annotation; * see :ref:`how_rd_class_example` * Contributor * entered using the **contributor** annotation. * see :ref:`how_rd_class_contributor` ^^^^^^^^^^^^^^^^^^ RDL Class finished ^^^^^^^^^^^^^^^^^^ The image below shows the RDL Class with all the mandatory annotations populated. .. figure:: /images/howto/ht_rd_cl_finish.png :scale: 100% RDL Class with mandatory annotations .. index:: Reference Data; How to - Create RDL Individual .. _how_rd_htindividual: -------------------------------------- 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. #. Select **Individuals by Class** tab and select the class **state** > **state observed**. #. On the **Individuals** panel, Click on the diamond shape and a dialogue will appear #. 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 :ref:`how_rd_UUIDMD` ), and click OK. This example uses the UUID of the Enumeration Literal. .. figure:: /images/howto/ht_rd_individualMD.png :scale: 100% Add an individual * Or use the GUID generator (see :ref:`how_rd_GUIDgen`) .. figure:: /images/howto/ht_rd_individual.png :scale: 100% Add an individual #. Select my_ap_activity_001 in the list of Individuals and click **Annotations +** #. Select **prefLabel** and type the name of the individual #. Select “en” in the **Lang** field and click OK. .. figure:: /images/howto/ht_rd_individual_preflabel.png :scale: 100% Create preferred label for individual .. rst-class:: expand ^^^^^^^^^^^^^^^^^^^^^^^^^ Add remaining annotations ^^^^^^^^^^^^^^^^^^^^^^^^^ The remaining NamedIndividual annotations should be added using the same procedure See :ref:`how_rd_individual` for details of annotations. Automatically created when class created: * **Identifier**; * see :ref:`how_rd_individual_about` * **Subclass** * see :ref:`how_rd_individual_subclassof` Mandatory: * **Description** * entered using the **comment** annotation; * see :ref:`how_rd_individual_comment` .. figure:: /images/howto/ht_rd_ind_comment.png :scale: 100% Add description (with language) * **Creator** * entered using the **creator** annotation; * see :ref:`how_rd_individual_creator` .. figure:: /images/howto/ht_rd_ind_date.png :scale: 100% Add date (no language) * **Creation date** * entered using the **date** annotation; * see :ref:`how_rd_individual_date` .. figure:: /images/howto/ht_rd_ind_date.png :scale: 100% Add date (no language) * **Status** * entered using the **type** annotation; * see :ref:`how_rd_individual_type` .. figure:: /images/howto/ht_rd_ind_type.png :scale: 100% Add status (no language) * **Version** * entered using the **versionInfo** annotation; * see :ref:`how_rd_individual_versioninfo` .. figure:: /images/howto/ht_rd_ind_version.png :scale: 100% Add version (no language) * **Change Note** * entered using the **changeNote** annotation; * see :ref:`how_rd_individual_changenote` Optional: * Alternative label * entered using the **altLabel** annotation; * see :ref:`how_rd_individual_altlabel` * Deprecated label * entered using the **hiddenlabel** annotation; * see :ref:`how_rd_individual_hiddenlabel` * Definition * entered using the **definition** annotation; * see :ref:`how_rd_individual_definition` * Source * entered using the **source** annotation; * see :ref:`how_rd_individual_source` * Note * entered using the **note** annotation; * see :ref:`how_rd_individual_note` * Example * entered using the **example** annotation; * see :ref:`how_rd_individual_example` * Contributor * entered using the **contributor** annotation. * see :ref:`how_rd_individual_contributor` ^^^^^^^^^^^^^^^^^^^^^^^^ RDL Individual finished ^^^^^^^^^^^^^^^^^^^^^^^^ The image below shows the RDL Individual with all the mandatory annotations populated. .. figure:: /images/howto/ht_rd_ind_finish.png :scale: 100% RDL Individual with mandatory annotations .. index:: Reference Data; How to - Create Non-en AP RDL =============================================== 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 ------------------------- #. 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. #. 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 :: ]> {my_date} {my_comment_text_in_my_language} l'ISO 10303-{ap_number}. {my_language_code} v1 WD ISO 10303-{ap_number} {my_coverage_text_in_my_language} {my_name} #. Open the file named catalog-v001.xml in STEPlib\Application_protocols\AP{ap_number}, where {ap_number} is the number of the AP, e.g. ap243 #. Replace the content with the text below replacing {ap_number}, {my_language_code}, {my_drive_letter}, and {my_local_path} with suitable values:: .. todo:: check the above. .. index:: Reference Data; How to - Ammend RDL class with additional language --------------------------------------------------------- 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”. #. Select the existing **my AP activity** class and select **Annotations +** #. Select **prefLabel** and type the alternative text then select the **correct language code**, and hit OK. .. figure:: /images/howto/ht_rd_language.png :scale: 100% 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”. #. Select the existing **my AP activity 001** individual, select **Annotations +** #. Select **prefLabel**, type the alternative text, select the **correct language code**, and hit OK. .. figure:: /images/howto/ht_rd_language_annotation.png :scale: 100% Navigate to individual to add language annotation #. Select **Annotations +** #. Select **prefLabel**, type the alternative text, select the **correct language code**, and hit OK. .. figure:: /images/howto/ht_rd_language_annotation_individual.png :scale: 100% 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 :ref:`how_scpt_owl_top` 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. .. contents:: The export has the following sections: :local: :depth: 1 :backlinks: top .. 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 .. _how_rd_xsl_templates: ================== 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 |MD| extension tag referenceExtension attribute referentPath * The **comment** is the documentation from the block. Example:: KeyValueType Defines a key piece of information ... ... .. _how_rd_xsl_enums: ================== Enumerations ================== .. contents:: The following Enumeration types have been identified: :local: :depth: 1 :backlinks: top ------------------------------------------------------------ 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 |MD| 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:: StudyTypeEnum This is ... ... studyTypeEnum_design ... --------------------------------------- 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:: VerificationStatusEnum This is the ... ... to_be_verified ... ----------------------------------- Enumerations mapped to other roles ----------------------------------- .. todo:: These are not yet included in the reference data - need to determine how they should be represented .. _how_rd_xsl_associations: ================== 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 |MD| extension). Of these it ignores properties that are: * enumerations (see :ref:`Enumerations`) * named "templateOwlClass" - these are assumed to be templates (see :ref:`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:: ModelType_inheritsFrom ... .. todo:: Association mapped to ExternalOwlObject - need to determine how they should be represented .. sectionauthor:: |Mike Ward| .. include:: /keywords.rst