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

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

Received on Monday, 8 December 2014 20:51:33 UTC