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

Re: Media type for FHIR RDF in Turtle

From: James G. Boram Kim <james@snu.ac.kr>
Date: Wed, 17 Feb 2016 00:35:48 +0000
Message-ID: <CAB7sJFWG8xO2XK173c4F3_0Uj5KkzDe+aQrNnQLDDM7RWdt8ig@mail.gmail.com>
To: Grahame Grieve <grahame@healthintersections.com.au>, "James G. Boram Kim" <james@snu.ac.kr>
Cc: 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>
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
>
Received on Friday, 19 February 2016 14:02:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:21:56 UTC