Stream: terminology
Topic: conventions for representing OWL ontologies as CodeSystems
Michael Lawley (Jul 13 2016 at 03:20):
It is common for an OWL Ontology to import pieces from other OWL Ontologies (eg A imports B).
If I am creating a CodeSystem for A, then what should I do with the concepts defined in B? Must I also have a CodeSystem for B and have the implicit ValueSet for A also import the concepts from B, or do I just include them all in A (in which case, if I do ever have a CodeSystem for B, then I have duplicate codes, or if there's another ontology with C imports B, I also get "duplicates" - "equal" codes).
Grahame Grieve (Jul 13 2016 at 03:22):
I find this question confusing because you haven't started with why a code system includes another code system
Michael Lawley (Jul 13 2016 at 03:33):
OWL has the notion of "import" - it does this because you're actually extending the set of concepts with a) additional concepts, and b) additional axioms ("relationships"). (In theory) this encourages modularity, re-use, etc
We have to work with some of these, eg the Human Phenotype Ontology, which imports, among many things, the Gene Ontology and ChEBI (Chemical Entities)
Grahame Grieve (Jul 13 2016 at 03:52):
ok, so what's the question?
Grahame Grieve (Jul 13 2016 at 03:53):
is it, how do you create those ontologies as code systems? or is it, how do you convert fhir code systems to ontologies?
Michael Lawley (Jul 13 2016 at 04:03):
It's the former - I have the OWL Ontology and I want to represent it as a CodeSystem (or several)
Grahame Grieve (Jul 13 2016 at 04:09):
interesting question, really.
Grahame Grieve (Jul 13 2016 at 04:12):
there's 2 different questions you might be asking:
- I want to make the concepts available on the API
- I want to create a code system resource for the ontology
Grahame Grieve (Jul 13 2016 at 04:12):
different questions....
Rob Hausam (Jul 13 2016 at 04:21):
If you import an ontology in OWL, it's still (in most or all respects) a separate ontology. You can certainly reason across the combination, and that's why you do it, but the individual contributions are still separately identifiable (and separable). I think we can probably take a similar approach with code systems. Define each one individually, and then combine them however you need to in the value set(s) that you want to use.
Grahame Grieve (Jul 13 2016 at 04:22):
there's probably a couple of places where this manifests - properties that come from other code systems (even parents), and some places in the operations where we clearly say, 'one system only', e.g. $subsumes and this might make reasoning difficult
Grahame Grieve (Jul 13 2016 at 04:23):
I guess we can do properties from other code systems - property of type Coding
Grahame Grieve (Jul 13 2016 at 04:23):
so it's in the API where the problems might arise
Rob Hausam (Jul 13 2016 at 04:36):
Yes. OWL is all about reasoning, whereas code systems in general don't have quite the same level and consistency of relationship infrastructure or expectations that they do. I'm not sure if we want to try to replicate capabilities similar to OWL here. If you combine two or more truly distinct code systems, then you may not necessarily be able to expect that subsumption would hold coherently across the combination. However, there are some cases where that should be possible and would be expected - the SNOMED CT - LOINC integration comes to mind. We probably should be able to handle subsumption across that combination, and we can't rely on the value set for that. So I'm not quite sure what we should do with this.
Grahame Grieve (Jul 13 2016 at 04:38):
well, you are allowed to reason across concept maps. and I think that will be appropriate for LOINC/SCT
Grahame Grieve (Jul 13 2016 at 04:38):
Michael's talking about going a step deeper than that
Rob Hausam (Jul 13 2016 at 04:45):
right - the concept map reasoning makes sense for this
and I know Michael is looking at a step deeper - maybe it's a step too far for what we should do here?
Grahame Grieve (Jul 13 2016 at 04:46):
don't know. you do have to call it a day somewhere. but we could look at speciifc examples....
Michael Lawley (Jul 13 2016 at 06:13):
@Grahame Grieve I'm not really sure how you "make the concepts available on the API" without creating a CodeSystem resource. The API requires at least a ValueSet and that references a CodeSystem and these are all now explicit (even for things like SNOMED CT and LOINC).
Michael Lawley (Jul 13 2016 at 06:16):
@Rob Hausam The reason we can't just create two CodeSystems and then combine in a ValueSet is that the combination also brings in axioms (ie the stuff that allows us to reason), and they induce cross-system parent/child relationships. As @Grahame Grieve observes, this breaks in $lookup and other places where a single code system is assumed.
Grahame Grieve (Jul 13 2016 at 06:20):
well,. sure, you need to know how to refer to to in a value set, but you don't need an explicit code system
Grahame Grieve (Jul 13 2016 at 06:20):
like sct and loinc
Michael Lawley (Jul 13 2016 at 06:22):
but you do need to know what the value for system is (and we always have a CodeSystem for a known (supported) system)
Grahame Grieve (Jul 13 2016 at 06:31):
we don't always have a code system for a supported system
Grahame Grieve (Jul 13 2016 at 06:32):
I've never even seen one for SCT LOINC RxNORM UCUM NDFRT UNII BCP13 BCP47
Grahame Grieve (Jul 13 2016 at 06:32):
and those are the most important uses of the API
Michael Lawley (Jul 13 2016 at 22:18):
Is this not a code system for SCT-AU? http://ontoserver.csiro.au/stu3/CodeSystem/32506021000036107-20160630
(and by "we" I meant "Ontoserver")
Grahame Grieve (Jul 13 2016 at 22:27):
well, now I can't claim that I haven't seen an SCT one
Grahame Grieve (Jul 13 2016 at 22:27):
i think it needs more work, but yes, that's what it would look like
Last updated: Apr 12 2022 at 19:14 UTC
