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

Re: Media type for FHIR RDF in Turtle

From: Grahame Grieve <grahame@healthintersections.com.au>
Date: Wed, 17 Feb 2016 19:32:26 +1100
Message-ID: <CAG47hGbjV5A6B-wWoOth=ruEK2=TdvCDoKnMTX_pS903ZnX75g@mail.gmail.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: "James G. Boram Kim" <james@snu.ac.kr>, David Booth <david@dbooth.org>, Martynas Jusevičius <martynas@graphity.org>, "its@lists.hl7.org" <its@lists.hl7.org>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
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, and mine about how you know where to start are
probably more serious

Grahame



On Wed, Feb 17, 2016 at 7:02 PM, Eric Prud'hommeaux <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> [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>
> > 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> 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
> >
> > >> 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> 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>
> 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>> 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>> 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>> 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> /
> > >>>>> >      > +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
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ***********************************************************************************
> > >>>>> 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
> > >>>>
> > >>>
> > >>
> > >>
> > >> --
> > >> -----
> > >> http://www.healthintersections.com.au /
> > >> grahame@healthintersections.com.au / +61 411 867 065
> > >>
> > >
> >
> >
> > --
> > -----
> > http://www.healthintersections.com.au /
> grahame@healthintersections.com.au
> > / +61 411 867 065
>
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> (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
/ +61 411 867 065
Received on Wednesday, 17 February 2016 08:32:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 17 February 2016 08:32:56 UTC