The 762103008 | OWL ontology reference set (foundation metadata concept)| , in which the OWL expressions represent essential information about an ontology. This information includes, namespaces, ontology URI, ontology version URI, and import statements. The enables the use of prefixes in the ontology
An is structured as shown in the following table.
Field
Data type
Purpose
Mutable
Part of Primary Key
The following metadata supports this reference set:
The reference set example tables on this page have been revised as follows to aid clarity and understanding:
The first four columns which are present in all release files are not shown. The omitted columns ( id, effectiveTime, active) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.
Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.
The table below shows the descriptors that define the structure of the pattern and examples of the descriptors for specific reference sets that follow this pattern.
Table 4-1: Descriptor templates for OWL expression reference rets
refsetId
referencedComponentId
attributeDescription
attributeType
attributeOrder
Table 4-2: OWL ontology reference set example
moduleId
refsetId
referencedComponentId
owlExpression
Table 4-3: OWL axiom reference set example
moduleId
refsetId
referencedComponentId
owlExpression
Explanatory Notes
effectiveTime
Time
The inclusive date or time at which this version of the identified reference set member became the current version.Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .
YES
YES (Full)Optional (Snapshot)
active
Boolean
The state of the identified reference set member as at the specified effectiveTime .If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.
YES
NO
moduleId
SCTID
Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime .The value must be a subtype of 900000000000443000 |Module (core metadata concept)| within the metadta hierarchy.
YES
NO
refsetId
SCTID
Identifies the reference set to which this reference set member belongs. In this case, a subtype descendant of 762676003 |OWL expression type reference set (foundation metadata concept)|
NO
NO
referencedComponentId
SCTID
A reference to the SNOMED CT component to be included in the reference set. The concept to which the OWL expression applies. In the case of the 733073007 |OWL axiom reference set (foundation metadata concept)| , the axiom contributes to the definitions to the defintion of the identified concept.
NO
NO
owlExpression
String
The text of OWL expression to attach to the component identified by referencedComponentId.
YES
NO
1
0
1
0
1
Prefix(owl:=<>)
Prefix(rdf:=<>)
Prefix(xml:=<>)
Prefix(xsd:=<>)
Prefix(rdfs:=<>)
Ontology(<>)
SubObjectPropertyOf(:774081006 :733928003)
Example of SubObjectPropertyOf, which is equivalent to an | Is a| relationship between attributes.
A 128 bit unsigned Integer, uniquely identifying this reference set member.Different versions of a reference set member share the same id but have different effectiveTime. This allows a reference set member to be modified or made inactive (i.e. removed from the active set) at a specified time.
SNOMED CT is a clinical terminology with a comprehensive coverage of wide clinical specialties and requirements. The development and maintenance of SNOMED CT relies on Description Logics (DL) and its reasoning services. The stated relationship file has been used to represent DL definitions. However, it is unable to fully represent semantics of the DL expressivity due to the limitation of its relational structure.
The new OWL refsets are designed to replace the stated relationship file and it represents the DL definitions for SNOMED CT content by following the international standard of OWL 2 Web Ontology Language.
Purpose
The purpose of this document is to define and describe the OWL Reference Set.
Scope
The document presents the specification of OWL refsets. It also documents the background, design considerations, quality assurance, and distribution format of the OWL refsets.
The implementation of the OWL refsets in the applications, and transformation of it to an OWL ontology, are out of the scope.
Audience
The target audiences of this document include:
SNOMED CT national release centers;
SNOMED CT terminology content developers and technical developers;
SNOMED CT implementers, analysts, and developers of electronic health records and information systems.
The OWL Functional Syntax-Style is the recommended default syntax. The generated OWL ontologies of SNOMED CT may be rendered in any compatible OWL syntax and transformed between syntaxes. The specification of syntax including the BNF grammar published by the W3C can be found at https://www.w3.org/TR/owl-syntax/.
Specializations for SNOMED CT
For the benefits of consistent representation and detection of changes to an expression, the style and rules are recommended though they have no semantic significance. The OWL expressions should be rendered in the form specified by the OWL Functional Syntax-Style but a restricted version may be used for creating and updating the OWL refsets. The following rules should be followed.
Whitespace
OWL Functional Syntax-Style defines that whitespace is a nonempty sequence of space (U+20), horizontal tab (U+9), line feed (U+A), or carriage return (U+D) characters.
The whitespace should only be represented as a single space (U+20) in the OWL refsets.
Comments
OWL Functional Syntax-Style defines that a comment is a sequence of characters that starts with the # (U+23) character and does not contain the line feed (U+A) or carriage return (U+D) characters.
Comments could improve the readability. However, comments should not be included to minimize the size of the OWL refsets and reduce the need to maintain the alignment between an axiom and its comments.
Sorting Order
A standard sort order is very useful to enable fast matching of identical expressions though it has no impact to semantics and is not essential for general purpose use.
Each axiom is a serialization of a tree structure that can be traversed by nodes in the following order:
Node that is either a SNOMED CT concept ID or a value of type data property. These nodes are sorted in UTF-8 byte-order (as a sequence of bytes) rather than numbers or strings. The byte-order compares two bytes; one from each sequence, until the values of the bytes are different. Then, the ID or value with the lowest byte value would be sorted as first regardless the length difference of byte arrays;
The composite node ObjectSomeValuesFrom(), sorting order by concept id of attribute and then value;
The composite node DataHasValue(), sorting order by concept id of attribute and then value.
The Functional-Style Syntax determines the general order of most elements within an OWL axiom. In fact, the order can only be applied to the nodes within EquivalentClasses(), DisjointClasses(), EquivalentDataProperties(), and ObjectIntersectionsOf() for the current .
The same semantics can be represented by a single axiom or multiple axioms. When axioms are in the same SNOMED CT module,
Expression in the OWL refset should be presented as an Equivalent Classes axiom instead of two Subclass axioms where both apply, e.g.
EquivalentClasses(A C) is recommended. The following two Subclass axioms are not.
SubClassOf(A C)
SubClassOf(C A)
Expression in the OWL refset should be presented as a single Subclass axiom with intersection of Class expressions instead of multiple Subclass axioms where they apply, e.g.
SubClassOf(A ObjectIntersectionOf(C D)) is recommended. The following two Subclass axioms are not.
The represents components and their associations to OWL expressions, e.g. definitions specified in OWL expressions for concepts, or information about OWL ontologies of SNOMED CT. This new type of reference set follows the pattern for annotation type reference set, but the content are not mixed with other types of annotations. The new refset supports accurate representation for feeding data into Description Logic reasoners, validation of OWL expressions, and creation of OWL ontologies for SNOMED CT.
The OWL ontology refset should represent essential information about an ontology, such as the namespaces, ontology URI, ontology version URI, and import statement.
Apart from the standard information for all OWL ontologies, any specific information of an ontology can be included. The OWL ontology refset enables the use of prefixes in the OWL axiom refset.
Namespaces
The namespace declarations cover the standard and SNOMED CT specific prefix names, for all ontologies. The prefix name "sct:" is for SNOMED CT concept identifiers and the namespace URI is http://snomed.info/id/.
The prefix names are associated with SNOMED CT concept 734146004 | OWL ontology namespace (metadata)| as referencedComponentId and examples can be found in table 4-2 OWL Ontology Reference Set example.
The URIs can be represented in full form or using the prefix names. For example, The URI for 64572001 | Disease (disorder)| can be one of the following format.
It is recommended to use the default prefix ":" to minimize the size and improve readability in the OWL refset. The prefix name "sct:" should be declared and used when is not the default namespace.
The ontology URI and the version URI together identify a particular version of ontology. According to the convention, an ontology document should be accessible via the ontology URI if it is the current version. Since a release edition contains the current version of the ontology, the ontology URI alone is sufficient for the OWL ontology refset. The version should be determined from the SNOMED CT release package. The version URI does not need to be included in the OWL ontology refset. For example:
However, the version URI should always be included for a standalone ontology file of SNOMED CT to provide accurate version information. The describes how to unambiguously reference a particular version of a SNOMED CT edition. It is also a trivial task to generate the Ontology version URI by the transformation process for a standalone ontology file. For example,
Each SNOMED CT Edition should be represented as a separate ontology based on the identifier of the most dependent module. The international release is represented by a single ontology and identified by the SNOMED CT core module id as the ontology URI. It includes two modules for terminology content excluding modules for derivatives:
The module dependency has specified that the SNOMED CT core module depends on the SNOMED CT model component module.
The OWL ontology reference set should only have one single active entry of | for the ontology declaration. This entry represents the identity of an ontology and the identifier for the ontology URI should be the most dependent module for that particular edition.
A new entry for OWL ontology header should be added with the extension module id and effective time for an extension edition of SNOMED CT. The OWL ontology header for SNOMED CT international release should be inactivated.
The OWL ontology header represents the identity of an ontology. It needs to be updated when the OWL expression refeset represents a different ontology, e.g. ontology of a national extension. Note, the changes to the content, version, and module dependency of an ontology do not require to update the ontology header.
It is possible that modules in SNOMED CT can be directly translated into OWL ontologies, with the module dependency reference set describing how these ontologies are imported. Extensions can import the ontology of SNOMED CT core module since the content in the model component module has already been included. The new OWL ontology header should include the extension module identifier and import statement(s). This approach could avoid accidental changes to the imported ontology. However, the implementation could be more complicated than the representation of an entire edition as a single ontology. Therefore, it is not recommended to use an ontology import statement at the current stage. Instead, each edition will be rendered as one OWL ontology, without any ontology import statement.
Axioms are statements or propositions which are regarded as being established, accepted, or self-evidently true in the domain. The OWL axioms are in the scope for the OWL axiom refset if they are allowed in the SNOMED CT Logic Profile Specification. Annotation axioms and Class declarations are generally excluded from the OWL axiom refset to avoid duplication to the RF2 files:
Annotation Axiom - Descriptions can be represented as annotation assertions. They are excluded from the OWL axiom refset to avoid duplication to the RF2 description file.
The transformation from the OWL expression refset to OWL ontology document should process the description file and language refset when descriptions are included. They should be represented by the following annotation properties for a given language refset.
rdfs:label - it is RF2 fully specified name
skos:prefLabel - it is RF2 preferred term
skos:altLabel - if present, it is RF2 acceptable synonym
skos:definition - if present, it is RF2 definition
Declaration
Declarations for the built-in entities, e.g. owl:Thing, owl:Nothing, are excluded from the OWL refsets because they are presented in every OWL 2 ontology.
Class and property declarations are excluded from the OWL axiom refset to avoid duplication to the content that is represented by the RF2 concept file. Note, Class and property declarations should be included in cases where an entity type cannot be derived from the existing axiom.
The OWL Axiom Reference Set is designed to cover all logic definitions in SNOMED CT. A concept can be defined by one or more axioms in the same module or different modules. Each axiom is represented by a string in in the owlExpression field. Each concept is represented by a concept ID in the referencedComponentId in the refset. The referencedComponentId has no impact on the semantics of the axioms and it is not used for any logical reasoning. The following rules should be followed when assigning the referencedComponentId for an axiom:
If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D) where concept C is a precoordinated concept, the concept ID of C should be the referencedComponentId for this axiom.
If an axiom is in the form of SubPropertyOf(r s) or EquivalentProperties(r s) where attribute r is a precoordinated concept, the concept ID of r should be the referencedComponentId for this axiom.
If an axiom is in the form of SubClassOf(C D) where concept C is NOT a precoordinated concept and D is a precoordinated concept. This is a General Concept Inclusion (GCI) axiom. Because concept C is a sufficient but not necessary condition for concept D, the ID of concept D should be the referencedComponentId for this axiom. Note, if C is a precoordinated concept, this SubclassOf axiom is NOT a GCI axiom and the concept D should not be assigned as the referencedComponentId.
The definition status of a concept is if the concept has at least one EquivalentClasses axiom, irrespective of whether other SubClassOf or EquivalentClasses axioms exist.
relationships in SNOMED CT are represented by different axioms, SubClassOf, SubObjectProperty, SubDataPropery, or EquivalentClasses in the OWL axiom refset.
SubClassOf represents the relationship between concepts in SNOMED CT.
SubObjectPropertyOf or SubDataPropertyOf represents the relationship between attributes in SNOMED CT for concept model object attributes and concept model data attributes respectively.
EquivalentClasses means that two concepts are subclass of each other in description logics , e.g. SubClassOf(C D) and SubClassOf(D C). EquivalentClasses are usually used to represent the equivalence between a precoorrdinated concept(a named class) and an expression such as ObjectIntersectionOf() that has one part of a precoordinated superconcept and the other part is an expression that usually refines the superconcept, e.g. ObjectSomeValuesFrom() or intersection of expressions.
Class and property are all uniquely identified by an IRI in OWL 2 Ontology. It is not allowed to represent
relationships between SNOMED CT attributes and concepts in the OWL refset.
should be represented as a class in the OWL axiom refset and SNOMED Ontology.
and its subconcepts should be represented as an object property in the OWL axiom refset and SNOMED Ontology. The relationships among them should be represented as SubObjectProperty();
and its subconcepts should be represented as a data property in the OWL axiom refset and SNOMED Ontology. The relationship among them should be represented as SubDataProperty();
The metamodeling capacities of OWL 2 allow the punning for Classes and Properties. Both attribute concepts, , , and direct subannotation properties can be treated as Classes and Properties at the same time to enable the single root node of SNOMED CT. The following two SubClass axioms have been added in addition to SubProperty axioms in the OWL expression refset. These SubClass axioms represent and infer the relationships to that is a Class.
SubClassOf(:762706009 :410662002)
SubClassOf(:762705008 :410662002)
For inferred relationships in the Necessary Normal Form (NNF), SubClassOf, SubObjectProperty and SubDataProperty in the OWL axiom refset should be represented as relationships. The explanation for the Necessary Normal Form and the rules for calculating the NNF can be found in section .
DataHasValue class expression should be used for a with a particular literal value that is specified in the . The DataSomeValuesFrom and DataAllValuesFrom class expressions should not be used. For example, the value of should be represented as:
DataHasValue(:1142135004 "50"^^xsd:decimal)
Unfortunately, the xsd:boolean data type is out of the scope for the OWL 2 EL profile (). In order to have a consistent representation and clear semantics, the boolean values should be represented by the concept and . The attribute should be a subtype of with a constraint in the SNOMED CT Machine Readable Concept Model that only these two values are in the range and the attribute cardinality is 0..1.
Note, trailing zeros are optional for the decimal data type in SNOMED CT. If the fractional part is zero, the period and following zero(es) can be omitted. For example, 2 is equivalent to 2.0. In particular, trailing zeros are prohibited for medicinal products in SNOMED CT because of clinical safety concerns. This 'trailing zero' policy should be applied in the same subject area of SNOMED CT for consistent classifications because the ELK reasoner has an incomplete implementation of concrete domains. However, it is possible that other subject areas, e.g. clinical findings, could allow for trailing zeros if it is desirable.
SNOMED CT is based on concepts, with attributes also being represented as concepts. However, attributes need to be represented as properties in the OWL axiom refset. The following rules should be followed.
The attribute should be represented as a Class in the OWL axiom refset.
The attribute and should be represented as Classes and Properties as noted above.
All descendants of should be represented as ObjectProperties.
Role groups must be explicitly stated and represented by the concept as an object property in the OWL axiom refset. In the diagram of stated relationships in the OWL axiom refset, the attribute should be represented by a circle rather than an object property. The role group should not be omitted for self-group attributes where there is only a single attribute in a role group.
An example for diagram representation of an OWL axiom
The editing of entries in the OWL refsets can only be performed by the owner of that module. The extensions must not modify the OWL refset entries from the dependent modules, such as . No changes are permitted to the content of the International Edition, except for the addition of new versions of this content in a module owned by the extension producer.
SNOMED CT extensions can add new axioms to the concepts in the international release to support extension content, such as adding an extension concept as an additional parent to a concept in the international release. Each axiom in an extension must have a new UUID, moduleId and effectiveTime from the extension. An international concept may have multiple axioms - one or more axiom from the international edition and zero or more axiom from extension. An axiom addition in an extension can be presented by two alternative forms with the same classification result.
Axiom inclusion - a new axiom with inclusion of the axiom from the international release as part of the extension axiom. For example, an extension concept D can be added as a superconcept by adding a new axiom in the extension.
Axiom without inclusion - a new axiom without inclusion of the axiom from the international release as part of the extension axiom. For example,
It is possible that substantive improvements or corrections to the International Edition can be made through axiom overriding in an extension, if they cannot be achieved by the Axiom addition approach.
Axiom overriding - a new axiom has the same UUID from the international release, but a new effectiveTime, module id and OWL expression from the extension.
This approach is different to the Axiom addition. The extension takes over the ownership of an axiom from the International Edition and overrides the axiom.
Whichever approach is taken by extensions, either Axiom addition or Axiom overriding, it must follow the . Any modifications resulting in changes to the classification of international content must be accompanied by a disclaimer notifying users of the differences between the extension edition and the International Edition. These changes should be forwarded to SNOMED International in a timely fashion to improve the quality of the International Edition for all users. Please note that modifications of this kind pose a risk to the comparability and interoperability of data captured using different SNOMED CT editions.
The versioning is at the axiom level for a concept in the OWL axiom refset. This means that there is only one effectiveTime for each version of an axiom, which may have multiple relationships. The changes to any relationships in the current editing tool will trigger an "update" of the most recent version of the relevant axiom. The versioning at the axiom level, where each axiom may represent multiple relationships, is different from the versioning of each individual relationship in the relationship file.
Any changes to the NNF should have a corresponding history of changes in the OWL axiom refset. This will ensure that all entries in the NNF can be derived from the OWL refset except for those relationships listed in table 2.4-1. The NNF will still have the computed effectiveTime for each inferred relationship. The version of each inferred relationship can be derived from the OWL refset, but it is not true in reverse.
It is permitted to make modifications to a published axiom without inactivation by the owner of the module, by creating a new version of the axiom with the same UUID and a new effectiveTime. Since any modification to an axiom could potentially alter its meaning, it is not necessary to inactivate an axiom and create a new axiom. It is also not necessary to reinstate an inactivated axiom in the previous release when the same axiom is created as a new expression. This approach can simplify the tooling and authoring process and it is a different approach to the history of changes to the individual relationship.
However, an axiom must be inactivated in the following situations:
The concept used as the referenced component is inactivated or changed.
Axiom needs to be inactivated without any replacement.
Any inactive concept or attribute referenced in the axiom will not be replaced by an active component.
During the transitional period from the stated relationship file to the OWL Axiom Refet, there should be only one active axiom in the OWL axiom reference set for each concept. This axiom will represent the set of all active attributes (from the existing stated relationship file) for which the given concept is the source concept. This axiom overriding approach should only be used for the transition once. After the transition period, these axioms will be reviewed, and where appropriate will be split into multiple axioms as described in the Axiom addition approach.
If a dependent module (e.g. an extension module) adds defining relationships to a concept, then this will result in a new version of the axiom (which has the new relationship included) being added to the OWL axiom reference set. A new version of the axiom must be created if any of the concept's defining relationships change, regardless of whether or not that change is in the given module. For example (moduleId, sourceId, destinationId, typeId and referencedComponentId are represented by letters for easier readability):
id
effectiveTime
active
moduleId
sourceId
destinationId
typeId
Results in two versions of a single OWL reference set entry
UUID
effectiveTime
active
moduleId
referencedComponentId
owlExpression
If an axiom is in the form of SubObjectPropertyOf(u t) where attribute u is NOT a precoordinated concept and attribute t is a precoordinated concept. The concept ID of t should be the referencedComponentId for this axiom. e.g. SubObjectPropertyOf(ObjectPropertyChain(:r :s) :t)
If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D) where both C and D are NOT precoordinated concepts, this is a GCI axiom and the referencedComponentId should be 733929006 |General concept inclusion axiom (metadata)|.
If an axiom is in the form of DisjointClasses(C D) where both C and D are precoordinated concepts, the concept ID of C should be the referencedComponentId for this axiom. Then the axiom DisjointClasses(D C) is redundant.
The disjointness in more than two Classes can be represented as DisjointClasses(C D E …) where all classes are precoordinated concepts. The concept 787776007 | Disjoint classes axiom (OWL metadata concept)| should be the referencedComponentId for this axiom.
SubClassOf(A C) is an axiom released in the international release.
SubClassOf(A ObjectIntersectionOf(C D)) is a new axiom in the extension.
SubClassOf(A C) is an axiom released in the international release.
SubClassOf(A D) is a new axiom in the extension.
Generating Necessary Normal Form Relationships from the OWL Refsets
The logic definitions are represented by the OWL axiom refset that is a replacement of the RF2 stated relationship file. As a result, the nature of the inferred relationship file in the distribution normal form (DNF) has changed, because the new DL features are not representable in the current relationships file. The inferred relationship file will maintain the same format and structure, but it is no longer equivalent to the stated form (containing all necessary and sufficient conditions). In fact, it is a collection of all the necessary conditions of precoordinated concepts and represents a subset of the full semantics.
Necessary Normal Form
The Necessary Normal Form (NNF) is a replacement for the Distribution Normal Form for inferred relationships. The NNF is a precalculated distribution form for practical purposes, for example, to support the continuity of existing implementations based on relational databases and queries by the expression constraint language.
The NNF consists of the full set of necessary relationships of precoordinated concepts after removal of redundant relationships within a given concept definition. Within the scope of a SNOMED CT terminology, necessary relationships are defined only for precoordinated concepts (aka OWL’s named classes). Let C be a precoordinated concept and D be either a precoordinated concept or a complex expression. If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D), then all of the derivable and necessary relationships of D are necessary relationships of C.
The NNF does not include class disjointness, transitive properties, reflexive properties and sufficient conditions represented as General Concept Inclusions (GCIs) in the OWL axiom refset.
Inferred relationships for concrete values, e.g. decimal, integer, string, or dateTime, should be included in a separate relationship file.
Given two relationships, A and B, A with r = C and B with s = D, within the same role group, A is redundant if:
r is the same as or a supertype of s, and
C is the same as or a supertype of D
Note, “crossover relationships”, where r is a supertype of s, and C is instead a subtype of D do not result in a redundant relationship.
Stated relationships:
Inferred relationships before the removal of redundant relationships:
Inferred relationships after the reduction:
For , the relationship = is inherited from , which is a redundant relationship because is a subtype of . The relationship = is inherited from , which is a redundant relationship because is a subtype of .
Table 2.5-1: Example in OWL axiom refset and RF2 relationship file (NNF)
referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId
Stated relationships:
Inferred relationships before the removal of redundant relationship:
Inferred relationships after reduction:
For concept , the relationship = is inherited from , which is a redundant relationship to = because is a subtype of . Because is a subtype of and , the inherited relationships for are also redundant.
Table 2.5-2: Example in OWL axiom refset and RF2 relationship file (NNF)
referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId
Given attribute r, s and t with a property chain SubObjectPropertyOf(ObjectPropertyChain(t s) r), and two relationships A and B, A with r = C and B with u = D, within the same role group, A is redundant if:
Attribute u is the same as or a subtype of t, and
D has a relationship to C via attribute s
Note the following:
C does not need to subsume D
Attribute t does not need to be the same as or a subtype of r
Transitive properties are defined by a property chain in the form of
SubObjectPropertyOf(ObjectPropertyChain(r r) r) and thus it is a special case of the above.
Stated relationships of (the other model detail has been omitted):
Stated relationships of :
Inferred relationships before the removal of the redundant relationship:
Inferred relationships after the reduction:
For , the relationship = is inherited from . If rule 1 for class inclusion was applied, the relationships would not be considered redundant because is not a subconcept of . Since and property chain of " o " is a sub-property of , rule 2 actually compares the anonymous concepts for subsumption, i.e. = with = . Therefore, the inherited relationship is redundant and can be removed from the NNF. Their relationships and property chain can be demonstrated in the following diagram.
Table 2.5-3: Example in OWL axiom refset and RF2 relationship file (NNF)
referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId
This fairly complex process uses the stated form and the output of the reasoner to calculate the necessary normal form which is represented in the relationship RF2 file.
The most straightforward way to produce the necessary normal form would be to use the or the which is language agnostic.
Read the Stated Form from RF2 files.
The following files are required: Concept, OWL Ontology Reference Set, OWL Axiom Reference Set.
If the edition has any active stated relationships then the Stated Relationship and MRCM Attribute Domain Reference Set files are also required.
Calculating the necessary normal form happens in two passes of the hierarchy.org.snomed.otf.owltoolkit.normalform
Walk the class hierarchy in a top-down, breadth first, order.
For each class visited gather the stated attributes of this class and each inferred parent.
Compare the attributes and remove those which are found to be redundant because they are less specific in terms of depth in the hierarchy.
For fine level detail the best source of information is the Java class org.snomed.otf.owltoolkit.normalform.RelationshipNormalFormGenerator which performs the Necessary Normal Form calculation.
It is important to clearly indicate if an attribute is grouped or not because has impact to semantics and classification results. is represented by an integer in the field of relationshipGroup in the relationship file. In contrast, is represented by as an object property in the OWL axiom refset. After the stated relationship file is replaced by the OWL expression refset, role group numbers need to be generated for inferred relationships.
The following rules should be followed in the inferred relationship file to provide consistent representation aligned with the concept model diagram and the OWL axiom refset.
All relationships should be assigned in role group 0;
Attribute that is not grouped, not a value of or grouped=0 in MRCM, should be assigned in role group 0;
Attribute that is grouped, value of or grouped=1 in MRCM, should be assigned a role group number that is not 0. Each in the OWL axiom should be presented by a unique role group number. Note, role group merging is not covered here.
is explicitly represented for self-grouped attributes where there is only a single attribute in a role group in an OWL axiom. However, these self-grouped attributes and values are not explicitly represented in the current relationship files. This representation has caused confusion if an attribute in role group 0 is grouped or not. The following example demonstrates the changes to assignment of role group number after the implementation of the complete OWL axiom refset.
An example for the current diagram representation for attribute in role group 0 in the stated relationship file and concept model diagram
Axioms from the OWL Axiom Reference Set, making a note of any Transitive property and Property Chain axioms.
Axioms created by converting Stated Relationships to OWL Axioms using the MRCM Attribute Domain Reference Set for list of attributes which should not be grouped in the given domain.
Use a reasoner to pre-compute the class hierarchy.
During this first pass build a hierarchy for property chains and transitive properties.
Walk the class hierarchy again in the same order reducing the attributes of each class further.
Compare the attributes and remove those which are found to be redundant because they are less specific in terms of depth in one of the alternate hierarchies.
After the complete OWL axiom refset is implemented, [ | Role group|](http://snomed.info/id/609096000 "609096000 | Role group |") in the OWL axiom refset and concept model diagram should be represented as following.
Representation of [ | Role group|](http://snomed.info/id/609096000 "609096000 | Role group |") in the NNF relationship file and concept model diagram
125605004
125605004
125605004
118851004
118851004
27658006
27658006
443820000
SNOMED CT OWL Guide
This document is a guide to the use of the Ontology Web Language (OWL) in SNOMED CT. It includes detailed information about structure, content and use of OWL reference sets. These OWL reference sets are used to distribute ontology reference information and the axioms that represent the formal logical definitions of SNOMED CT concepts.
This document is a publication of International Health Terminology Standards Development Organisation, trading as SNOMED International. SNOMED International owns and maintains SNOMED CT®.
Any modification of this document (including without limitation the removal or modification of this notice) is prohibited without the express written permission of SNOMED International. This document may be subject to updates. Always use the latest version of this document published by SNOMED International. This can be viewed online and downloaded by following the links on the front page or cover of this document.
SNOMED®, SNOMED CT® and IHTSDO® are registered trademarks of International Health Terminology Standards Development Organisation. SNOMED CT® licensing information is available at
