RDF information content and FHIR RDF requirement #14

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

Received on Tuesday, 24 March 2015 19:45:14 UTC