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
