Re: RDF information content and FHIR RDF requirement #14

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> 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
/ +61 411 867 065