W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > February 2016

Re: Media type for FHIR RDF in Turtle

From: David Booth <david@dbooth.org>
Date: Wed, 17 Feb 2016 19:40:16 -0500
To: Grahame Grieve <grahame@healthintersections.com.au>, Eric Prud'hommeaux <eric@w3.org>
Cc: "James G. Boram Kim" <james@snu.ac.kr>, Martynas Jusevičius <martynas@graphity.org>, "its@lists.hl7.org" <its@lists.hl7.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
Message-ID: <56C512F0.7000208@dbooth.org>
Comment below . . .

On 02/17/2016 03:32 AM, Grahame Grieve wrote:
> well, that's one part of it. I suppose you also want to comment on the
> other media types we use:
>
>   * XML: |application/xml+fhir|
>   * JSON: |application/json+fhir|
>
>
> But actually, whether you have to look inside or not is just one
> question. And, in a sense, it's just an efficiency question; it just
> takes longer to find out whether you can read it. David's question about
> how you know that the resource is complete,

I think my comment may have created more concern than is warranted.  RDF 
does have named graphs, which we could use to delineate a certain set of 
triples.  But we haven't been doing that for FHIR RDF and I don't think 
it is needed either.  In practice, the FHIR resource that you get 
contains whatever data it contains, whether it's in XML, JSON or RDF. 
And if it somehow requires anything that isn't there, then it is 
non-conformant, whether it is XML, JSON or RDF.  If something is not 
there but not required, then that just means that the sender didn't 
include that information, whether it is in XML, JSON or RDF.  So I think 
the question of missing data boils down to a question of conformance, 
which would be the same whether it is in XML, JSON or RDF.

RDF could contain extra data that is not representable in FHIR.  But in 
the RDF world that is not generally a problem either -- in fact, it's 
viewed as a feature -- because anything extra that is not needed can be 
safely ignored, because RDF semantics are monotonic.

> and mine about how you know
> where to start are probably more serious

I think we addressed this on yesterday's 5pm call.  We decided to add a 
fhir:resourceType property (analogous to the JSON resourceType 
property), which would identify the starting instance data element (as 
its subject) and its FHIR resource type (as its value):
https://www.w3.org/2016/02/16-hcls-minutes.html#resolution03

David Booth

>
> Grahame
>
>
>
> On Wed, Feb 17, 2016 at 7:02 PM, Eric Prud'hommeaux <eric@w3.org
> <mailto:eric@w3.org>> wrote:
>
>     What we're wrestling here is of course the usual tension between the
>     cost of deploying a new identifier that won't initially be recognized
>     vs. the cost of reusing an existing, less specific identifier. For
>     media types, this is a ameliorated a bit by self-describing documents,
>     but as Grahame, points out, you still have to root aruond in it to
>     know what is is and where to route it. The IETF conneg group has
>     wanted to develop a more expressive form of media type for a couple
>     decades now.
>
>     A "+" precedent was established by the (XML-centric) work-around
>     introduced in the XML media type registraion (RFC3023):
>
>     [[
>         When a new media type is introduced for an XML-based format, the
>     name
>         of the media type SHOULD end with '+xml' unless generic XML
>         processing is in some way inappropriate for documents of the new
>         type.
>     ]] — https://tools.ietf.org/html/rfc7303#section-4.2
>
>     Of the current tree/foo+bar registrants (see
>     <http://www.iana.org/assignments/media-types/media-types.xhtml>), we
>     have
>       XML related (xml, wbxml, fastinfoset)  381
>       +json                                  51
>       +zip                                   6
>       +der (???)                             1
>
>     We can certainly argue for text/fhir+turtle; It's a precedent I'd like
>     to set. We'll have to compare
>
>       f1 A GETs U.
>       f2 U arrives with specific media type text/fhir+turtle.
>       f3 A usefully routes or processes U without parsing it.
>
>     against a null proposition of
>
>       t1 A GETs U.
>       t2 U arrives with a generic media type text/turtle.
>       t3 A needs to parse U to perform the action in f3.
>
>     What sorts of decoupled systems will recieve U without knowing they'd
>     dereferenced a link to a FHIR resource?
>
>
>     In principle, we also have to convince ourselves that the benefit of
>     f3 exceeds the deployment pain teaching existing RDF tools about a new
>     "+turtle" convention. There are a good many turtle files served as
>     text/plain so I imagine that the current practices of content-sniffing
>     and optimsitic-parsing will make this more of a theoretical pain.
>
>
>     * Grahame Grieve <grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>> [2016-02-17 11:48+1100]
>      > but that is not the only way to get to a resource. There are many
>     ways you
>      > might get to something that might be a resource. A file, for
>     instance. or
>      > an attachment. Media types are used more widely than just in http
>     headers
>      >
>      > Grahame
>      >
>      >
>      > On Wed, Feb 17, 2016 at 11:35 AM, James G. Boram Kim
>     <james@snu.ac.kr <mailto:james@snu.ac.kr>>
>      > wrote:
>      >
>      > > Yes, there is no explicit way to tell whether a URI itself
>     represents a
>      > > FHIR resource. However, the way you get the URI tells what the
>     URI you're
>      > > about to request is for.
>      > >
>      > > Regards,
>      > > James
>      > >
>      > > On Wed, Feb 17, 2016 at 9:30 AM Grahame Grieve <
>      > > grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>> wrote:
>      > >
>      > >> umm, there's no way to tell whether a URI represents a FHIR
>     resource
>      > >>
>      > >> Grahame
>      > >>
>      > >>
>      > >> On Wed, Feb 17, 2016 at 11:26 AM, James G. Boram Kim
>     <james@snu.ac.kr <mailto:james@snu.ac.kr>>
>      > >> wrote:
>      > >>
>      > >>> Hello all,
>      > >>>
>      > >>> Even though I don't have enough knowledge about FHIR RDF, I think
>      > >>> sticking with the general media type is a better way than
>     inventing
>      > >>> something new.
>      > >>>
>      > >>> FHIR resources should be identified by their URIs not media
>     types so the
>      > >>> first thing that needs to be given is a URI not "some RDF".
>     It totally
>      > >>> depends on how we get the URI to find out whether the URI is
>     about a FHIR
>      > >>> resource.
>      > >>>
>      > >>> As Martynas wrote, "with RDF, you retrieve it and make rules
>     that apply
>      > >>> to the vocabularies used in it (properties, types etc)." But
>     before
>      > >>> requesting it, you should first know the URI by searching it
>     or by just
>      > >>> following it from another resource. In either case, you can
>     easily figure
>      > >>> out what the URI represents. Your search criteria or a
>     property that links
>      > >>> one resource to another says what the URI is for.
>      > >>>
>      > >>> Best regards,
>      > >>> James
>      > >>>
>      > >>> On Wed, Feb 17, 2016 at 9:08 AM Grahame Grieve <
>      > >>> grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>> wrote:
>      > >>>
>      > >>>> hi David
>      > >>>>
>      > >>>> So there's a few issues. The first is, given some rdf, is
>     the only way
>      > >>>> to
>      > >>>> find out whether it represents something worth treating as a
>     FHIR
>      > >>>> resource
>      > >>>> to actually parse it, and search it for FHIR resources? You
>     seem to
>      > >>>> think that the answer is yes
>      > >>>>
>      > >>>> The second is, given some resources that do contain at least one
>      > >>>> fhir resource, how to you determine whether there's a single
>      > >>>> nominated 'this is the resource' in the way that XML and JSON
>      > >>>> do it. Do you have to get a list of all the uris that represent
>      > >>>> resources, and try to figure out their relationships to
>     determine
>      > >>>> if there is one primary (that won't work...)
>      > >>>>
>      > >>>> And finally, given that you can even figure out that there
>     is a single
>      > >>>> resource, how do you know that it's represented completely?
>      > >>>>
>      > >>>> it seems to me that there's an inherent statement about the
>      > >>>> package itself here - this package represents a single, whole,
>      > >>>> FHIR resource that is equivalent to what you would get in XML
>      > >>>> or JSON.
>      > >>>>
>      > >>>> (because there's lots of usages for RDF graphs that include
>      > >>>> a set of sibling resources that have no equivalent XML/json
>      > >>>> representation, though we could choose to prohibit that, I
>     suppose)
>      > >>>>
>      > >>>> Grahame
>      > >>>>
>      > >>>> On Wed, Feb 17, 2016 at 9:02 AM, David Booth
>     <david@dbooth.org <mailto:david@dbooth.org>> wrote:
>      > >>>>
>      > >>>>> However, one thing the RDF does not do: it does not tell
>     you the
>      > >>>>> boundary of what is included in a document.  If a FHIR
>     resource is
>      > >>>>> represented in RDF, there is nothing explicit in it to
>     indicate that
>      > >>>>> the
>      > >>>>> document contains all and only the RDF triples for that
>     FHIR resource.
>      > >>>>> This is a little different from the XML and JSON worlds, in
>     which there
>      > >>>>> is an explicit top element, with everything else nested
>     inside.  But
>      > >>>>> aside from that caveat, one should be able to look at the
>     RDF triples
>      > >>>>> to
>      > >>>>> see that it contains a fhir:AllergyInterance resource, for
>     example.
>      > >>>>>
>      > >>>>> Actually, I'm noticing that our current example is lacking
>     the explicit
>      > >>>>> mention of fhir:AllergyIntolerance, so I've raise an issue
>     about that:
>      > >>>>> https://github.com/w3c/hcls-fhir-rdf/issues/8
>      > >>>>>
>      > >>>>> David
>      > >>>>>
>      > >>>>> On 02/16/2016 03:11 PM, Grahame Grieve wrote:
>      > >>>>>
>      > >>>> > On Wed, Feb 17, 2016 at 6:27 AM, Martynas Jusevičius
>      > >>>>>
>      > >>>> > <martynas@graphity.org <mailto:martynas@graphity.org>
>     <mailto:martynas@graphity.org <mailto:martynas@graphity.org>>> wrote:
>      > >>>>> >
>      > >>>>> >     In what way can a piece of Turtle be a resource?
>      > >>>>> >
>      > >>>>> >
>      > >>>>> > it represents a statement of the content of a fhir resource
>      > >>>>> >
>      > >>>>> > btw, I am presently using 'text/turtle; x-dialect=fhir',
>     but I have
>      > >>>>> no
>      > >>>>> > particular feeling for this
>      > >>>>> >
>      > >>>>> > Grahame
>      > >>>>> >
>      > >>>>> >
>      > >>>>> >     With RDF, you retrieve it and make rules that apply
>     to the
>      > >>>>> >     vocabularies used in it (properties, types etc).
>      > >>>>> >
>      > >>>>> >     On Tue, Feb 16, 2016 at 8:10 PM, Grahame Grieve
>      > >>>>> >     <grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      > >>>>>
>      > >>>> >     <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>> wrote:
>      > >>>>> >      > So how do you know that a piece of turtle is a
>     resource? The
>      > >>>>> >     theory of a
>      > >>>>> >      > restful interface is that you make rules that
>     apply to a mime
>      > >>>>> >     type, but
>      > >>>>> >      > evidently not in the case of rdf...
>      > >>>>> >      >
>      > >>>>> >      > Grahame
>      > >>>>> >      >
>      > >>>>> >      >
>      > >>>>> >      > On Wednesday, 17 February 2016, David Booth
>     <david@dbooth.org <mailto:david@dbooth.org>
>      > >>>>>
>      > >>>> >     <mailto:david@dbooth.org <mailto:david@dbooth.org>>>
>     wrote:
>      > >>>>> >      >>
>      > >>>>> >      >> Hi Grahame,
>      > >>>>> >      >>
>      > >>>>> >      >> On today's call
>      > >>>>> >      >>
>     http://www.w3.org/2016/02/16-hcls-minutes.html#action02
>      > >>>>> >      >> we discussed what media type we should use for
>     FHIR RDF
>      > >>>>> >     serialized in
>      > >>>>> >      >> Turtle.  The existing (generic) Turtle media type is
>      > >>>>> text/turtle
>      > >>>>> >     .  The
>      > >>>>> >      >> consensus is that we should stick with that for
>     FHIR in
>      > >>>>> Turtle.
>      > >>>>> >     Do you (or
>      > >>>>> >      >> anyone else) see any problem in using that?  (And
>     if so, what
>      > >>>>> >     media type do
>      > >>>>> >      >> you think we should use for FHIR in Turtle?)
>      > >>>>> >      >>
>      > >>>>> >      >> thanks,
>      > >>>>> >      >> 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
>     <mailto:grahame@healthintersections.com.au>
>      > >>>>>
>      > >>>> >     <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>> /
>      > >>>>> >      > +61 411 867 065 <tel:%2B61%20411%20867%20065>
>     <tel:%2B61%20411%20867%20065>
>      > >>>>
>      > >>>>
>      > >>>>> >
>      > >>>>> >
>      > >>>>> >
>      > >>>>> >
>      > >>>>> > --
>      > >>>>> > -----
>      > >>>>> > http://www.healthintersections.com.au /
>      > >>>>> > grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      > >>>>>
>      > >>>> > <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>      > >>>>
>      > >>>>
>      > >>>>>
>      > >>>>>
>      > >>>>>
>     ***********************************************************************************
>      > >>>>> 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
>     <mailto:grahame@healthintersections.com.au> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>      > >>>>
>      > >>>
>      > >>
>      > >>
>      > >> --
>      > >> -----
>      > >> http://www.healthintersections.com.au /
>      > >> grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>      > >>
>      > >
>      >
>      >
>      > --
>      > -----
>      > http://www.healthintersections.com.au /
>     grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      > / +61 411 867 065 <tel:%2B61%20411%20867%20065>
>
>     --
>     -ericP
>
>     office: +1.617.599.3509 <tel:%2B1.617.599.3509>
>     mobile: +33.6.80.80.35.59 <tel:%2B33.6.80.80.35.59>
>
>     (eric@w3.org <mailto:eric@w3.org>)
>     Feel free to forward this message to any list for any purpose other than
>     email address distribution.
>
>     There are subtle nuances encoded in font variation and clever layout
>     which can only be seen by printing this message on high-clay paper.
>
>
>
>
> --
> -----
> 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 Thursday, 18 February 2016 00:40:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 18 February 2016 00:40:54 UTC