Re: Media type for FHIR RDF in Turtle

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

Received on Wednesday, 17 February 2016 00:49:12 UTC