This document describes how a SNOMED CT RF2 distribution should be represented in OWL. It is a generalization of an earlier specification written in Perl, called the "Spackman Perl Script", and will work with any reasonable RF2 content.

For some time now, the SNOMED CT International RF2 distribution has included a Perl script named "tls2_StatedRelationshipsToOwlKRSS_INT_<date>.pl", which can be used to generate an OWL representation of the distribution in RDF XML, Owl Functional or KRSS syntax. This script is the closest that the SNOMED International organization has come to defining an official OWL representation for SNOMED CT. This approach has a number of shortcomings, however, including:

• The transformation only works with the SNOMED CT International release. It cannot be applied unchanged to other distributions.

• The transformation can only emit descriptions in one language

• There are subtle but significant differences between the various output formats

In addition, while this Perl script could be viewed as a formal specification, one has to be a bit of a coding expert to be able to understand the actual transformation rules expressed within the document.
The intent of this specification is to "reverse engineer" the Perl transformation and document the transformation rules in such a way that:

1. They can be consistently applied to any SNOMED CT release or extension

2. They apply to all languages

3. Multiple language descriptions can appear in one OWL rendering

4. They are described in such a way that they can be implemented in any target language

5. The semantics of the output is independent of the format

To the best of the authors' knowledge, this specification describes the intent of the Perl transformation, as it exists today. One of the goals of this specification is that it can serve as a baseline where subsequent changes and enhancements to the OWL representation of SNOMED CT can be clearly identified and where tooling developers can clearly understand the ramifications of the changes to both the output and the transformation tools themselves.

The following list summarizes the intentional differences between this specification and the Spackman transformation:

1. The Spackman transformation wraps all of the rdfs:subClassOf assertions in an owl:intersectionOf wrapper.  This specification does not.

2. The Spackman transformation does not take the language refset into account when emitting text definitions.  This frequently results in the wrong definition(s) being generated.  This specification treats text definitions in the same way as descriptions with the exception that it does not distinguish between preferred and acceptable language refset entries.

3. The Spackman transformation generates ObjectProperty definitions for all active descendants of 410662002 | Concept model attribute |, with the exception of 116680003|is a|.  This specification emits an additional ObjectProperty definition for 410662002 | Concept model attribute | itself and defines all descendants as its direct or indirect subproperty.

4. The Spackman transformation uses the following predicates for descriptions and definitions:

   1. sctf:Description.term.{specific language}.preferred "{text}"@{general language} (e.g  sctf:Description.term.en-us.preferred "Due to"@en)

   2. sctf:Description.term.{specific language}.synonym "{text}"@{general language}

   3. sctf:Description.TextDefinition.term "{text}"@{general language}

This specification describes how to transform the SNOMED CT RF2 distribution content into an OWL equivalent. As part of this process, we need a way to specify which RF2 files are used, which columns are transformed and how they are selected. We have chosen to use the SQL query syntax for this purpose, as its syntax and semantics is well understood and it makes it possible for us to test and verify the correctness of the specification. It should be noted that this specification does not require that SQL be used in an actual implementation. Any implementation that produces the same results as described by the SQL in this document would be considered "conformant".

A second part of the transformation process requires a way to specify the OWL statements that are generated and their relationship to the RF2 tables. We have chosen the Turtle RDF syntax to represent the results, where substitutions are represented with a "$" prefix and italics. As an example, the assertion that the variable named "subject" is declared to be an instance of an OWL Class would be asserted as:

                              sct:$subject rdf:type owl:Class .

This specification does not require that the output of an actual implementation be in the Turtle RDF format, but whatever output format is used, it must be semantically equivalent to the Turtle as specified in this document.
A short synopsis of the subset of the Turtle notation appears in Appendix B: RDF Turtle Notation

RF2 files are represented in bold. Examples: Concept, StatedRelationship

RF2 fields are represented in a monospace font. Examples: id, acceptabilityId

Context variables are represented in bold monospace. Examples: LANGUAGE_MAP, VERSION, RIGHT_IDS

Turtle output is represented in monospace, with substitution variables as monospace italics. Example:
sct:$subject rdfs:subClassOf sct:$destinationId .

SNOMED CT concepts are represented using the conceptReference production as defined in the SNOMED CT Compositional Grammar Specification v2.3.1.  For the sake of brevity, this specification uses the (US) English preferred name rather than the complete FSN.  Example:  74400008 | Appendicitis |

Lists are represented as comma-separated values inside square braces. Example: LANGUAGES:["en-us", "en-gb"]

Maps are represented as comma-separated entries within curly braces, with a colon between the key and value. Example:
LANGUAGE_MAP: {"en-us": 900000000000509007,
                             "en-gb": 900000000000508004}

Map lookup is indicated via "$MAP(key)". Example:
$LANGUAGE_MAP("en-gb") = 900000000000508004

The transformations in the document apply to the Snapshot representation of a SNOMED CT RF2 distribution. Transformations of the Full or Delta representations are not defined in this document.

The table below shows the Release Format 2 (RF2) distribution files and corresponding fields that are used in the RF2 to OWL transformation.  FIelds identified as "FILTER" are used to determine whether a given entry (row) is used to generate output, but are not represented in the output itself.