Re: RDF information content and FHIR RDF requirement #14

On 03/24/2015 06:01 PM, Grahame Grieve wrote:
> 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.

Do you mean the difference between the RDF serialization and the 
abstract RDF information content (a/k/a RDF model)?  (The word "model" 
in "RDF model" may be a bit misleading because it is not being used in 
the same sense as "data model".)  For example, Turtle, N-Triples and 
RDF/XML are all RDF serialization formats, and any of them can be used 
to serialize the exact same RDF information content.

> Actually. I'm not sure
> whether there's only one of the latter either.

The point of the FHIR RDF effort is to *standardize* the RDF information 
content, so that for any given piece of FHIR instance data (in any 
standard FHIR format), two parties acting independently would get the 
exact same RDF information content by following the standard RDF mapping.

David Booth

> 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
> <mailto: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
>             <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
>             <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
>             <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
>         <javascript:_e(%7B%7D,'cvml','grahame@healthintersections.com.au');>
>         / +61 411 867 065 <tel:%2B61%20411%20867%20065>
>
>         ***********************************************************************************
>         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
> <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 Tuesday, 24 March 2015 23:28:30 UTC