Hi Tony,
On 03/24/2015 04:53 PM, Anthony Mallia wrote:
David,
Obviously this is an important discussion.
Requirement 14 says the RDF instance (not FHIR XML or
FHIR JSON) must be capable of being opened without further
modification. When the instance is opened it is expected
to form closure with the "Model" or Ontology of FHIR which
is exchanged previously. Thus the RDF wire formats for
passing both the Resource Instance and the FHIR Model must
support the loading into a tool which must be able to infer
or calculate the type assignments between the instances and
the model classes.
It sounds like we were not clear in Requirement #14 whether
we were talking about RDF *serializations* or the RDF
*information* content (which is independent of serialization).
It sounds like you interpreted "RDF instance" as referring
to the *serialization*, whereas I interpreted it as referring
to the RDF *information* content.
I think we need to keep in mind here that the goal is not
to get standard RDF *serializations* sent over the wire, but
as the group's charter says:
http://wiki.hl7.org/index.php?title=File:Rdf-semantic-interop-subgroup-v9.docx
[[
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.
]]
One way that goal can be met is to define a third FHIR
serialization format based on a standard RDF *serialization*
format. Parties exchanging FHIR data could then directly
exchange the data in an RDF serialization if they chose.
In making it a standard FHIR format, a standard bidirectional
mapping would also be defined between FHIR XML or JSON
and this RDF serialization format, and that mapping would
also enable any FHIR XML or JSON to be interpreted as
RDF by applying that mapping.
However, that goal can also be met without *any* additional FHIR
serialization being defined, as long as we define a standard
*mapping* between FHIR XML or JSON and the RDF information
content. Parties don't need to exchange data that *looks* like
RDF; what matters is that the data can somehow be *interpreted*
as RDF information content, and this only requires a mapping
from that data format to RDF.
This is explained in the Yosemite Project slides 12-14 on
"RDF as a Universal Healthcare Exchange Language":
http://dbooth.org/2014/rdf-as-univ/rdf-as-univ-slides.pdf
David Booth
We need to get to the short list of recommended RDF serializations which need
to be supported.
Protégé currently supports:
RDF/XML
OWL/XML
OWL Functional Syntax
Manchester OWL Syntax
OBO
KRSS2
Latex
Turtle (no Turtle viewer in Protégé desktop)
JSON-LD is not an option right now.
Folks will have their favorites - I work mainly in Manchester Syntax since it
is the native language for expressions in Protégé.
RDF/XML is probably the widest supported format. OWL Functional Syntax has some
logical grouping readability advantages.
Others are keen on Turtle.
In most cases it does not matter because the underlying RDF/RDFS/OWL gets
constructed regardless. However if we change the sample format every time it is
very confusing and requires some learn time to figure out.
It would be good to narrow the list.
Tony Mallia
-----Original Message-----
From: David Booth [mailto:[email protected]]
Sent: Tuesday, March 24, 2015 3:49 PM
To: [email protected]; w3c semweb HCLS
Subject: 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
