Re: RDF information content and FHIR RDF requirement #14

Well, there's 2 kinds of rdf representation. One is a statement of instance
structure in rdf, and one is a statement of instance meaning. I'm not sure
how to best describe the difference. Actually. I'm not sure whether there's
only one of the latter either. And I'm not sure if a single rdf type is
needed for the former, but I do think we need to distinguish them

Grahame
On Wednesday, March 25, 2015, Claude Nanjo <cnanjo.mailinglist@gmail.com>
wrote:

> Hi Grahame,
>
> Could it not be as simple as:
>
>  GET [base]/[type]/[id], mime type : *some rdf mime type or non-rdf mime
> type*
>
> where the rdf mime type could be
> application/rdf+json
> application/rdf+xml
> application/x-turtle
> ...
> with the supported mime types being specified in the conformance profile
> for that server?
>
> Why would we need 'Application/fhir+rdf'? Are you thinking of a new
> representation unique to FHIR?
>
> Claude.
>
> On Tue, Mar 24, 2015 at 1:21 PM, Grahame Grieve <
> grahame@healthintersections.com.au
> <javascript:_e(%7B%7D,'cvml','grahame@healthintersections.com.au');>>
> wrote:
>
>> I don't think that we could decide that servers SHALL do RDF
>> I had expected that we'd define an RDF format directly rather making it a
>> transform from one of the existing formats - but, in fact, if we have a
>> transform from one of the existing formats, it's just a question of who
>> runs the transform?
>>
>> OTOH, I had naively expected that you would request RDF by it's mime
>> type.... only, it's not so simple as that is it?
>>
>> I think that this is what we should do:
>>  GET [base]/[type]/[id], mime type : Application/fhir+rdf - the near form
>> of RDF, a statement of structure of a resource.
>>  GET [base]/[type]/[id]/$rdf, mimetype = x - the far form, a statement of
>> the known meaning of the content of the resource in some triple format
>>
>> Grahame
>>
>>
>> On Wed, Mar 25, 2015 at 6:44 AM, David Booth <david@dbooth.org
>> <javascript:_e(%7B%7D,'cvml','david@dbooth.org');>> wrote:
>>
>>> On today's teleconference some discussion arose around the intent behind
>>> requirement 14 as it pertains to our FHIR RDF work:
>>> http://wiki.hl7.org/index.php?title=FHIR_Ontology_
>>> Requirements#14._RDF_Quality
>>> [[
>>> 14. RDF Quality
>>> (MUST) Transformations into RDF must meet software quality checks
>>> including ontological closure. The RDF instance which is transformed from
>>> FHIR XML or FHIR JSON must be capable of being opened without further
>>> modification by widely available tools including Protégé and the RDF must
>>> meet quality checks including successful closure of graphs - all the links
>>> are understood by the tool.
>>> ]]
>>>
>>> Apparently different people on the call interpreted this requirement
>>> differently.  Some interpreted it as applying to FHIR serializations that
>>> are transmitted on the wire; others interpreted it as applying to the
>>> underlying RDF that the transmitted data represents, independent of
>>> serialization.  The difference shows up when we consider different
>>> strategies for mapping FHIR instance data to RDF.
>>>
>>> If we use a custom RDF mapping (Option 1 at
>>> http://wiki.hl7.org/index.php?title=FHIR_RDF_Mapping_-_
>>> Potential_Strategies )
>>> then the FHIR group might adopt an RDF serialization as a third format
>>> (in addition to XML and JSON).  This means that FHIR servers may send RDF
>>> serializations on the wire, and that RDF may be opened directly by standard
>>> RDF tools.
>>>
>>> OTOH, if we use JSON-LD (such as Option 2 at the above URL) then FHIR
>>> servers would be sending either XML or JSON-LD.  Those who receive FHIR
>>> instance data in JSON-LD and want to interpret it as RDF might need to
>>> convert that JSON-LD to a different RDF serialization to open it in their
>>> favorite RDF tools if their favorite RDF tools do not already understand
>>> JSON-LD.  (JSON-LD is the newest of W3C standard RDF serializations, and is
>>> not yet understood by all RDF tools.)   The concern -- if I've understood
>>> correctly -- is that this would force the *recipients* to do this
>>> translation, instead of having the server sending a format that could be
>>> opened by all RDF tools directly.
>>>
>>> My own view is that, although I think there would be some benefit to
>>> encouraging the use of RDF serializations on the wire, I doubt that the
>>> FHIR group would agree to *requiring* FHIR servers to support an RDF
>>> serialization.  It might be nice if they would, but I don't think it is
>>> important to our efforts.  The goal of this sub-group is to facilitate the
>>> use of RDF as a common semantic model for interpreting instance data that
>>> may originate in any format, data model or vocabulary.  The purpose is to
>>> enable data to be computable and semantically interoperable. Therefore
>>> what's important is just that we define a standard RDF *interpretation* for
>>> FHIR instance data, regardless of the serialization that is used on the
>>> wire.  This standard RDF *interpretation* of FHIR instance data must meet
>>> requirement #14, but a transformation may still be needed in order to
>>> compute this RDF interpretation from a piece of FHIR XML, JSON or other
>>> instance data.
>>>
>>> What do others think?
>>>
>>> BTW, one of the key strengths of RDF is that it is independent of data
>>> formats or serializations.  *Any* data can be viewed as an RDF
>>> serialization provided that a mapping has been defined from that data
>>> format into RDF.  That mapping can even be defined after the fact: the
>>> original data format does not even need to have been designed with RDF in
>>> mind.  This is one of the key features that enables RDF to act as a
>>> universal information representation.
>>>
>>> David Booth
>>>
>>> ************************************************************
>>> ***********************
>>> Manage subscriptions - http://www.HL7.org/listservice
>>> View 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
>> <javascript:_e(%7B%7D,'cvml','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=cnanjo.mailinglist@gmail.com&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