- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 17 Feb 2016 03:02:49 -0500
- To: Grahame Grieve <grahame@healthintersections.com.au>
- 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>
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.
Received on Wednesday, 17 February 2016 08:03:06 UTC