Contents

Current status

The semantics of SNOMED CT is based on description logic, whereas the syntax emulates a frames-representation:

• All specified relationships are considered as existential restrictions (which is made explicit in RF2)

• Transitive relationships exist (e.g., after , part_of), but these are not explicitly defined as such

• Role chaining exists (in the product / substance domain) , but this is not explicitly defined

• Nesting is not supported by the syntax, although it could be emulated by “anonymous” concepts

• The syntax does not cater for:

  • Negation

  • Disjunction

  • Number restriction

  • Concrete domains

  • Etc.

SNOMED CT is much more than “just” the representation of knowledge. Strengths of the current representation that may not be natively dealt with in a DL-representation include:

• Specification of fully specified names, and acceptable descriptions

• Explicit identification of descriptions, which facilitates specification of language reference sets, including preferred terms and synonyms

• A deactivation mechanism

• Versioning

Foreseen end-stage

When specifying the end-stage of SNOMED CT, not only the formal representation aspect needs to be addressed. It is foreseen that there is a move from “OWL derived from RF2“ to “RF2 derived from OWL”, where there may be differences in the information represented in both syntaxes. For example, negation and disjunction may be ignored in the RF2 syntax, in which only the inferred hierarchy and existential (and possibly universal) restrictions are represented, and fully defined OWL-concepts may be represented as primitive RF2-concepts.

The development path

An evolutionary path is recommended, in which for each DL extension an assessment is performed: type and scale of benefits (e.g., more fully defined concepts), type and scale of costs (e.g., classification performance, reduced number of applicable reasoners, impact for modelers), application domains (e.g., body structure, pharmaceutical products). Meanwhile, the migration process can be initiated, taking into account processing of the maximal set of DL constructs, in order to allow a smooth step-wise approach, without a need for intermediate reconsiderations. So the migration of full expressivity precedes the actual implementation of the full expressivity in the DL-representation.

Expressivity could evolve along these lines:

1. OWL from RF2 (as a seeding version, among others to agree on exact representation / URI specification, etc)

2. OWL-EL (see below for which features are and aren’t included)

3. Addition of Generic Concept Inclusion (GCI, i.e., a definition where the left-hand side is an expression rather than a concept name) and multiple concept definitions (resulting in a t-box which is no longer unfoldable, potentially increasing the worst case complexity)

4. Addition of class negation (ObjectComplementOf) and universal quantification (ObjectAllValuesFrom, DataAllValuesFrom)

In each of the steps, the above-mentioned considerations should be made, also driven by the work done by the Palo Alto Group.

Furthermore, methods remain to be in place to address the non-DL-aspects like synonymy, versioning, and inactivation.

OWL 2 EL Feature Overview

OWL 2 EL places restrictions on the type of class restrictions that can be used in axioms. In particular, the following types of class restrictions are supported (* indicates available in RF2):

• * existential quantification to a class expression (ObjectSomeValuesFrom) or a data range (DataSomeValuesFrom)

• existential quantification to an individual (ObjectHasValue) or a literal (DataHasValue)

• self-restriction (ObjectHasSelf)

• enumerations involving a single individual (ObjectOneOf) or a single literal (DataOneOf)

• intersection of classes (ObjectIntersectionOf) and data ranges (DataIntersectionOf)

OWL 2 EL supports the following axioms, all of which are restricted to the allowed set of class expressions:

• *class inclusion (SubClassOf)

• *class equivalence (EquivalentClasses)

• class disjointness (DisjointClasses)

• *object property inclusion (SubObjectPropertyOf) with or without property chains, and data property inclusion (SubDataPropertyOf)

• property equivalence (EquivalentObjectProperties and EquivalentDataProperties),

• transitive object properties (TransitiveObjectProperty)

• reflexive object properties (ReflexiveObjectProperty)

• domain restrictions (ObjectPropertyDomain and DataPropertyDomain)

• range restrictions (ObjectPropertyRange and DataPropertyRange)

• assertions (SameIndividual, DifferentIndividuals, ClassAssertion, ObjectPropertyAssertion, DataPropertyAssertion, NegativeObjectPropertyAssertion, andNegativeDataPropertyAssertion)

• functional data properties (FunctionalDataProperty)

• keys (HasKey)

The following constructs are not supported in OWL 2 EL:

• universal quantification to a class expression (ObjectAllValuesFrom) or a data range (DataAllValuesFrom)

• cardinality restrictions (ObjectMaxCardinality, ObjectMinCardinality, ObjectExactCardinality, DataMaxCardinality, DataMinCardinality, and DataExactCardinality)

• disjunction (ObjectUnionOf, DisjointUnion, and DataUnionOf)

• class negation (ObjectComplementOf)

• enumerations involving more than one individual (ObjectOneOf and DataOneOf)

• disjoint properties (DisjointObjectProperties and DisjointDataProperties)

• irreflexive object properties (IrreflexiveObjectProperty)

• inverse object properties (InverseObjectProperties)

• functional and inverse-functional object properties (FunctionalObjectProperty and InverseFunctionalObjectProperty)

• symmetric object properties (SymmetricObjectProperty)

• asymmetric object properties (AsymmetricObjectProperty)

The following table is taken from the Palo Alto document section 3.6, repeated here to allow additional information to be captured. It shows an analysis of the OWL 2 EL profile for applicability to SNOMED CT of its feature set. 

Features NOT included in OWL 2 EL