Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / W3C HCLS COI call -- Review of FHIR ontology approaches (cont.)

Question - are we talking about a structual ontology (analogous to various 
structural codesystems/tables like ActStatus or Acknowledgment in v2/v3), 
or a domain ontology such as Administrative Sex or one derived from 
domain-specific codesystems such as RxNorm/LOINC/SNOMED CT?

If it's a structural terminology, it's easy to see how it can be 
automatically derived from FHIR artifacts. If it's a domain terminology, 
it would be rather uncontrolled if it's derived from any inline 
definitions in FHIR artifacts. Note that I refrain from the word ontology 
here, because I use "ontology" to mean one with formal computable 
definitions (like FMA or SNOMED CT) and amenable to description logics, 
not one with just a collection of terms/concepts.

If it's a formal ontology, OWL would be useful. If it's a (controlled) 
terminology, we can use SKOS. RDF/RDFS are more generic than SKOS and OWL, 
and so would be applicable in both cases.
Thanks,

Senthil. 

PS. cross posting to vocab list for comments.



Senthil K. Nachimuthu, MD, PhD | Medical Informaticist
3M Health Information Systems, Inc.
575 W Murray Blvd, Murray, UT 84123, USA
Office: +1 801 265 4636
snachimuthu@mmm.com | www.3mtcs.com




From:   Lloyd McKenzie <lloyd@lmckenzie.com>
To:     David Booth <david@dbooth.org>
Cc:     Grahame Grieve <grahame@healthintersections.com.au>, w3c semweb 
HCLS <public-semweb-lifesci@w3.org>, "its@lists.hl7.org" 
<its@lists.hl7.org>
Date:   12/08/2014 04:13 PM
Subject:        Re: Minutes of last week's (Dec 2) HL7 ITS RDF Subgroup / 
W3C HCLS COI call -- Review of FHIR ontology approaches (cont.)
Sent by:        owner-its@lists.hl7.org



I think that any ontology we create will have to be produceable in an 
automated fashion from the FHIR artifacts.  Any introduction of 
hand-editing would be unacceptable from a maintainability and consistency 
perspective.  So we're looking at mechanical, no matter what.  The 
question is what the mechanical outputs would be.

--------------------------------------
Lloyd McKenzie

+1-780-993-9501

 

Note: Unless explicitly stated otherwise, the opinions and positions 
expressed in this e-mail do not necessarily reflect those of my clients 
nor those of the organizations with whom I hold governance positions.

On Mon, Dec 8, 2014 at 1:51 PM, David Booth <david@dbooth.org> wrote:
Possibly a dream ontology would link to more other ontologies, such as 
upper level ontologies, but other than that I view it as more of a 
stylistic difference: more oriented toward a human conceptualization that 
is natural to express in RDF (i.e., reflecting RDF's natural style).

But one problem is that the whole notion of a dream ontology is very 
subjective, and this means that it is apt to take a lot more work to reach 
convergence on it.  That is why I think it is important to prioritize a 
mechanical ontology first, so that we can progress as rapidly.  If at some 
later point we wish -- and we are able -- to converge on a dream ontology 
then that's great, and it could complement the mechanical ontology for 
those who wish to use it.  But I think it would be a big mistake to try 
for that at the outset.

Again, the distinction between mechanical ontology and dream ontology is 
qualitative, fuzzy and subjective: to the extent that we can make a 
mechanical ontology that is human friendly and natural to RDF, that would 
of course be ideal.   I just want to guard against going down a potential 
rat hole from the start.  :)

David

On 12/08/2014 02:24 PM, Grahame Grieve wrote:
can you explain your dream ontology more? what sort of things does it do?

Grahame


On Tue, Dec 9, 2014 at 6:01 AM, David Booth <david@dbooth.org
<mailto:david@dbooth.org>> wrote:

    Hi Lloyd,

    On 12/08/2014 01:35 PM, Lloyd McKenzie wrote:

        I think we need to define our objectives for the RDF 
representation.
        Mine are as follows:


    Great list!  My comments . . .


        1. It must be possible to round-trip from XML/JSON through RDF
        representation


    +1

        * This includes retaining information about order of repeating
        elements


    Is the order of repeating elements semantically significant in FHIR?
    I.e., would it affect or use of the interpretation of the
    information?  If not, then why do you view this as important?
    (Playing devil's advocate here, to elicit the rationale.)

        * Needs to allow for extensions where-ever they can appear,
        including
        simple types (date, boolean, etc.)


    +1

        2. We want to be able to represent instances as RDF


    +1

    and Profiles as OWL/RDFS

    +0.9.  I think the profiles MUST be represented in some form of RDF,
    but whether it is done using OWL, RDFS or some combination of OWL,
    RDFS and something else (SKOS?) I think should be a judgement call
    that is made as we go along.

        3. Syntax needs to be "safe" when dealing with modifier extensions
        4. Syntax should support vocabulary bindings to code, Coding and
        CodeableConcept - including dealing with extensible value sets and
        multi-code system value sets
        5. Syntax should enforce constraints that are representable in
        RDF (i.e.
        schema constraints, regular expressions, etc.)


    Can you explain what you mean by syntax in the above?  For example,
    if Turtle is used to serialize the RDF, what would the above points
    mean?

        6. In the RDFS/OWL, should expose at least minimal annotation
        information for display


    +1

    BTW, there's another distinction that Eric Prud'hommeaux used to
    distinguish between different ontology styles or goals.  I think he
    referred to one style as a "mechanical" ontology, which might be
    fairly directly derived from the FHIR spec and is oriented mainly
    toward ease of round tripping between RDF and XML or JSON.  The
    other style is a "dream" ontology, which is friendlier and more
    natural for humans to view and may take more work to converge upon.
      The two are not mutually exclusive, of course, but in prioritizing
    our work effort I'm of the opinion that we should FIRST go for the
    mechanical ontology, and once we've got that sufficiently nailed
    down, we could try to figure out a dream ontology, with the ability
    to automatically translate instance data between the two.

    Thanks,
    David Booth

    
******************************__******************************__***********************
    Manage subscriptions - http://www.HL7.org/listservice
    View archives - http://lists.HL7.org/read/?__forum=its
    <http://lists.HL7.org/read/?forum=its>
    Unsubscribe -
    
http://www.HL7.org/tools/__unsubscribe.cfm?email=grahame@__healthintersections.com.au&__list=its

    <
http://www.HL7.org/tools/unsubscribe.cfm?email=grahame@healthintersections.com.au&list=its
>

    Terms of use -
    http://www.HL7.org/myhl7/__managelistservs.cfm?ref=nav#__listrules
    <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>




--
-----
http://www.healthintersections.com.au /
grahame@healthintersections.com.au
<mailto:grahame@healthintersections.com.au> / +61 411 867 065

***********************************************************************************
Manage your subscriptions <http://www.HL7.org/listservice> | View the
archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
<http://www.HL7.org/tools/unsubscribe.cfm?email=david@dbooth.org&list=its>
| Terms of use
<http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>


***********************************************************************************

Manage your subscriptions | View the archives | Unsubscribe | Terms of use