W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > December 2014

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

From: Lloyd McKenzie <lloyd@lmckenzie.com>
Date: Tue, 9 Dec 2014 07:36:03 -0700
Message-ID: <CAJ860J+g_UGyU630C4qxDDWiRpFryjf4FLbhQN42VDBmd7xMYg@mail.gmail.com>
To: Grahame Grieve <grahame@healthintersections.com.au>
Cc: David Booth <david@dbooth.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>, "its@lists.hl7.org" <its@lists.hl7.org>
Yes.  On the profile side, I'm certainly expecting that we'll be looking at
adding extensions to profile that allow manifesting relationships between
and abstractions of resources and properties, for a start.

--------------------------------------
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 Tue, Dec 9, 2014 at 3:13 AM, Grahame Grieve <
grahame@healthintersections.com.au> wrote:

> Another option is to add additional information to the definitions so that
> you can generate the RDF you want.
>
> Grahame
>
> On Tuesday, December 9, 2014, Lloyd McKenzie <lloyd@lmckenzie.com> wrote:
>
>> 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 <http://www.HL7.org/listservice> | View the
>> archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
>> <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.healthintersections.com.au / grahame@healthintersections.com.au
> / +61 411 867 065
>
Received on Tuesday, 9 December 2014 14:36:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:21:45 UTC