Comments

1. Michael Lawley
   2018-07-04 12:35

   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:

   xxxxxxx

   20180731

   1

   32506021000036107

   762103008 |OWL ontology reference set|

   734147008 |OWL ontology header|

   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?

   
   

   Reply

   
   Cancel

   1. Kai Kewley
      2018-07-04 09:07

      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!

      Reply

      
      Cancel
2. Yongsheng Gao
   2018-07-04 05:09

   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.

   Reply

   
   Cancel
3. Kai Kewley
   2018-07-06 02:47

   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.)

   Reply

   
   Cancel
4. Michael Lawley
   2018-07-19 04:04

   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?

   
   

   Reply

   
   Cancel

   1. Kai Kewley
      2018-07-30 01:30

      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?

      Reply

      
      Cancel

      1. Michael Lawley
         2018-08-07 05:59

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

         Reply

         
         Cancel
5. Kai Kewley
   2018-07-31 12:21

   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.

   Reply

   
   Cancel

   1. Michael Lawley
      2018-08-07 05:57

      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

      Reply

      
      Cancel

      1. Kai Kewley
         2018-08-07 09:46

         Thanks for confirming.

         Reply

         
         Cancel
6. Yongsheng Gao
   2018-07-31 01:23

   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

   Reply

   
   Cancel
7. Ronald Cornet
   2019-08-29 04:27

   Yongsheng Gao Kai Kewley Peter G. Williams, all.

   I have been constructing an OWL-file from the owl-refset in the July 2019 release, to be consumed by Protege.

   This worked well, with one nasty fix needed:

   OWL Header contains a closing bracket, which needs to be removed, or rather, moved to the end of the ontology.

   The ontology should look like this:

   <begin>

   Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
   Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
   Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
   Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
   Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
   Prefix(:=<http://snomed.info/id/>)
   Ontology(<http://snomed.info/sct/900000000000207008>
   EquivalentClasses(:721657003 ObjectIntersectionOf(:75478009 ObjectSomeValuesFrom (:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:246075003 :36094007) ObjectSomeValuesFrom(:370135005 :441862004))) ObjectSomeValuesFrom(:609096000 ObjectSomeValuesFrom(:42752001 :781249001))))

   ...

   )

   <end>

   
   

   I think it would make sense to change OWL header to remove the closing bracket, and consider having OWL footer, which will likely be just the closing bracket.

   
   

   Happy to hear your thoughts.

   Reply

   
   Cancel
8. Kai Kewley
   2019-08-29 07:39

   Hi Ronald Cornet,

   While I can appreciate your suggestion I think it's good to have well formed axioms in each row of the OWL Expression refset and make tooling understand what needs to be done to combine them. You are right that the closing bracket is the first gotcha people are likely to hit, maybe some guidance notes somewhere would be useful?

   Have you tried using the OWL Toolkit to generate an ontology file?
   See https://github.com/IHTSDO/snomed-owl-toolkit#snomed-rf2-to-owl-file-conversion

   The benefits of this approach include:

   • • Correct formatting of ontology file tested with Protégé.
     • Option to include FSN terms in the ontology as annotations
       • Translated PTs can be included using the feature/feature-language-options branch (waiting for feedback on that feature).
     • Ability to resolve which RF2 rows are effective within an extension when international content is overridden or when content is donated.
     • Ability to combine published (RF2 snapshots) with work in progress (RF2 deltas) to produce an ontology.
       
       

   Kind regards.

   Reply

   
   Cancel
Add new comment

Cancel