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

Hi David

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.

I'm not overly fussed on exactly what technologies we use, so long as we
have a mechanism for extracting structures and extension definitions and
defining those as classes and properties and can properly reflect the set
of constraints the profile imposes

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

Well, modifier extensions give grief.  Essentially someone can come along
and define a modifier extension on MedicationAdministration that changes
from "patient swallowed acetaminophen" into "patient has a pathological
fear of swallowing acetaminophen".  And only someone who understands the
modifier extension would recognize that the meaning has changed.  I think
that, in general, this means that there's functionally a separate ontology
for instances with no modifier extensions and for instances that contain
any arbitrary combination of modifier extensions.  It's going to be ugly
and a pain, but I'm not sure there's any way around that.

For #4 and #5, there shouldn't be any change to the RDF representation of a
FHIR instance - all of this will live in the OWL/RDFS/SKOS/whatever.  It
does mean that the RDF instances *will not* declare what vocabularies
they're bound to.  The instances will just declare the code or the code +
code system (or code + system + version).  The linkage of the attribute to
a particular vocabulary will be handled on the profiling side.


>
>
>  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.
>
I think there needs to be only way of representing FHIR instances as RDF.
Implementers will need to count on a single syntax.  Where we have
flexibility is the RDFS/OWL/whatever representation of the meaning of the
FHIR instances.  There we may very well have multiple approaches to satisfy
differing requirements in terms of analysis tooling, performance
requirements, documentation, etc.


>
> Thanks,
> David Booth
>