Page tree
Skip to end of metadata
Go to start of metadata

The OWL refsets have been developed for the international release in July 2018. The OWL axiom refset only contains the logic definitions that cannot be represented in the RF2 stated relationship file. Please note, descriptions are included on this Confluence page for readability, but they are not part of the OWL refset files.

USE WITHIN CLINICAL SYSTEMS CANNOT BE SUPPORTED AT THIS TIME.
The Preview represents a proof of concept and is distributed for evaluation purposes only. It is not for use in production clinical systems or in clinical settings.

The limited scope of OWL refsets will allow sufficient time for users to develop and update their tooling and systems. The plan is to have full representation of all definitions in the OWL axiom refset in January 2019 release. The stated relationship file will be deprecated after the January 2019 release. Please provide your feedback as comments on this page. 


OWL Ontology Reference Set in 2018 July International release

IdeffectiveTimeactive

moduleId

refsetId

referencedComponentId

owlExpression

709e618d-9434-4c3b-b437-200e9aa26d59201807311

900000000000012004

Prefix(:=<http://snomed.info/id/>)

ba81d0bf-1703-4edf-a641-4bf7ae336a7c201807311

900000000000012004

Prefix(owl:=<http://www.w3.org/2002/07/owl#>)

2992ad4c-c5f8-4235-8e6b-36be3cacca57201807311

900000000000012004

Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)

beefaa9e-a868-4a36-9ca8-b301cd6ae17f201807311

900000000000012004

Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)

3c566f2c-b38f-40bb-a6cb-7ea114ce8cf9201807311

900000000000012004

Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)

3b0c7f58-388d-4956-84d5-fbff44197018201807311

900000000000012004

Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)

f81c24fb-c40a-4b28-9adb-85f748f71395201807311

900000000000012004

Ontology(<http://snomed.info/sct/900000000000207008>)


OWL Axiom Reference Set in 2018 July International release

IdeffectiveTimeactive

moduleId

refsetId

referencedComponentId

owlExpression

bcc83805-c402-4c02-ac6b-4ce8efd47773201807311900000000000012004
TransitiveObjectProperty(:733930001)

fb90eade-26b7-4747-bf6a-c9c235c1802d

201807311900000000000012004
TransitiveObjectProperty(:738774007)
8164a2fc-cac3-4b54-9d9e-f9c597a115ea201807311900000000000012004
TransitiveObjectProperty(:123005000)
c1200e3f-c808-4dc8-8904-fec1c7b26280201807311900000000000012004
SubObjectPropertyOf(ObjectPropertyChain(:363701004 :738774007) :363701004)
0a4047c5-0d6b-4e71-a786-21658377eecf201807311900000000000012004
SubObjectPropertyOf(ObjectPropertyChain(:424361007 :738774007) :424361007)
37c61ae4-e371-4d90-b635-5934c0777890201807311900000000000012004
TransitiveObjectProperty(:733928003)
bcba6a63-15c7-4109-930d-bf561d98321d201807311900000000000012004
SubObjectPropertyOf(ObjectPropertyChain(:246075003 :738774007) :246075003)
b8074e53-7157-4f2c-826f-c9019afbff88201807311900000000000012004
SubObjectPropertyOf(ObjectPropertyChain(:246093002 :738774007) :246093002)
b4b8c410-13af-46cc-b238-d132b7a79f1c201807311900000000000012004
ReflexiveObjectProperty(:738774007)
34a2b4fd-093f-41c0-81c9-c68f3dc76bec201807311900000000000012004
ReflexiveObjectProperty(:733928003)
70c580eb-e0b2-4ac3-815f-8a9b1be45bb3201807311900000000000012004
SubObjectPropertyOf(ObjectPropertyChain(:127489000 :738774007) :127489000)

The content of OWL Axiom refset will be updated according to the requirement from content projects. For the 2018 July release, we anticipate the property chains, property axioms (transitive and reflxive) for the drug and substance projects.

The files can be downloaded at the following links

The linkes to specifications and related documents




  • No labels

11 Comments

  1. It is not clear to me how the OWLOntology and OWLAxiom reference sets are supposed to be combined to produce the resulting OWL Functional Syntax rendering.

    Specifically, the OWLOntology reference set contains an entry like: Ontology(<http://snomed.info/sct/900000000000207008>) but the axioms themselves need to be syntactically embedded inside this giving something like the following (only some data from above included for brevity):

      Prefix(:=<http://snomed.info/id/>)
    Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
    Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
    Ontology(<http://snomed.info/sct/900000000000207008>
    TransitiveObjectProperty(:733930001)
    SubObjectPropertyOf(ObjectPropertyChain(:363701004 :738774007) :363701004)
    )

    Looking at the snomed-owl-toolkit code it seems that it hacks around this issue and loads/parses every axiom separately and independently of the actually-supplied OWLOntology content.

    To make matters more complicated, it's not clear what should happen with extensions. I think (based on OWL Reference Set Specification (draft)) that the expectation is that the OWLOntology reference set would contain an additional entry:

    xxxxxxx201807311

    32506021000036107

    Ontology(<http://snomed.info/sct/32506021000036107>)

    But now there are two Ontology declarations - how do the axioms get handled; how do we know which Ontology declaration to use in the rendering(s) (there can only be one per file)?  Should there also be an Imports entry?


    1. Michael Lawley You are right that the Snomed OWL Toolkit is not currently using the OWLOntology reference set and it should.

      I will update the toolkit in the develop branch and ask for your feedback in the next few days.

      Thank you for your feedback!

  2. Many thanks Michael Lawley, I had a discussion with Kai and updated the OWL refset specification to clarify it further.

    The OWL ontology refset should only have a single active entry for OWL ontology header. Extension will need to add a new OWL ontology header and inactivate the one from the international release. 

    It is possible that modules in SNOMED CT can be directly translated into OWL ontologies. 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 extension module identifier and import statement(s). This approach could avoid accidental changes to the imported ontology, however, it also won’t allow extensions to fix critical errors in the imported ontology. The implementation could be more complicated than the representation of an edition as a single ontology. Therefore, ontology import is not recommended at the current stage.

    Please let us know your feedback.

  3. Michael Lawley I've updated the RF2 to OWL implementation in the develop branch of the Snomed OWL Toolkit to take the information from the OWL Ontology reference sets.

    The URI is extracted from the ontology header reference set member and used in the owl output file.

    Any prefixes in addition to the standard ones will be added to the owl output file however these are not used in any useful way.

    There is a unit test and RF2 file showing how an extension should make the International ontology header inactive and provide their own.

    I welcome your feedback on this Snomed OWL Toolkit implementation before it is released. (This functionality is not yet available in the executable jar on the release pages.)

  4. Thanks Kai, I've had a look at the new changes.  I note that to generate the OWL file, each axiom is still parsed separately, and again only with a single Prefix in play.  This is used to build up the OWL-API objects before serialising them all to the output file.

    I presume this is being done to perform some level of syntactic validation of each axiom?

    For completeness I would expect that it should use all the Prefixes from the OWLOntology reference set, not just a single hard-coded one.

    Otherwise, it would seem simpler & quicker to just copy all the axioms through to the output stream rather than loading the whole Ontology into memory and then writing it out?


    1. Hi Michael. Thank you for reviewing this.

      Yes, the an OWL API Ontology is built and then that is serialised to disk. The advantages of this approach include:

      • Some syntax validation by parsing of the owlExpressions
      • Ability to include axioms converted from stated relationships
      • Ability to add FSN annotations to be included in OWL file output
      • Consistent approach when building Ontology for OWL file output or for classification

      I will consider adding support for additional prefixes. Do we have a use case for this?

      1. I only raid the prefixes business because they are included in the reference set, but a subset (one) is hard-coded in this code.

  5. Michael Lawley I believe it was you who suggested using UTF-8 byte order when sorting SCTIDs during axiom serialisation to ensure a deterministic order. I am writing unit tests for this in the Snomed OWL Toolkit but I am not sure what to expect. The bytes representing single digit numbers 0 to 9 in UTF-8 are '48' to '57'. These are sequential so easy to sort.

    My uncertainty is question is about sorting SCTIDs of different lengths. It seems there are two possible sort orders for numbers of different lengths e.g. 100 and 99. Either the number with the lowest first byte is recognised as the lowest value for sorting or the number with the lowest number of characters and therefore a shorter series of bytes is recognised as the lowest value for sorting.

    For example: 

    405813007 is represented in UTF-8 by bytes 52,48,53,56,49,51,48,48,55

    84301002 is represented in UTF-8 by bytes 56,52,51,48,49,48,48,50

    The second identifier is a lower number and a shorter series of bytes so could come first. However the first byte of the first identifier is lower so this could come first if that is what we care about.

    I don't mind which strategy we use here so long as we all agree, it gets documented and we all implement the same functionality!

    Cheers.

    1. Just as you wouldn't expect "zoo" to sort before "leet", "200" does not sort before "1337"

      i.e., string length is irrelevant, you just compare the bytes as they come and stop as soon as one string ends or you get a mismatch.

      405813007 < 84301002

      1. Thanks for confirming.

  6. Hi Kai Kewley, my testing application would place 405813007 in the first place. The lowest first byte is recognised as the lowest value for sorting. I think this would be more efficient than counting the length. The following are some output exmaples.

    // 2 -> 3
    // 12 -> 21
    // 12345 -> 5432
    // 12345 -> 23456
    // a c -> ab
    // 100 -> 99
    // Sjogren -> Sjögren

    // 405813007 -> 84301002

    // 71388002 -> 900000000000073002
    // 116676008 -> 363698007