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 <e...@w3.org
<mailto:e...@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 <grah...@healthintersections.com.au
<mailto:grah...@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
<ja...@snu.ac.kr <mailto:ja...@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 <
> > grah...@healthintersections.com.au
<mailto:grah...@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
<ja...@snu.ac.kr <mailto:ja...@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 <
> >>> grah...@healthintersections.com.au
<mailto:grah...@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
<da...@dbooth.org <mailto:da...@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
> >>>>>
> >>>> > <marty...@graphity.org <mailto:marty...@graphity.org>
<mailto:marty...@graphity.org <mailto:marty...@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
> >>>>> > <grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au>
> >>>>>
> >>>> > <mailto:grah...@healthintersections.com.au
<mailto:grah...@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
<da...@dbooth.org <mailto:da...@dbooth.org>
> >>>>>
> >>>> > <mailto:da...@dbooth.org <mailto:da...@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=grah...@healthintersections.com.au&list=its
> >>>>> > >> Terms of use -
> >>>>> > >>
> >>>>> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
> >>>>> > >
> >>>>> > >
> >>>>> > >
> >>>>> > > --
> >>>>> > > -----
> >>>>> > > http://www.healthintersections.com.au /
> >>>>> > grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au>
> >>>>>
> >>>> > <mailto:grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au>> /
> >>>>> > > +61 411 867 065 <tel:%2B61%20411%20867%20065>
<tel:%2B61%20411%20867%20065>
> >>>>
> >>>>
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > --
> >>>>> > -----
> >>>>> > http://www.healthintersections.com.au /
> >>>>> > grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au>
> >>>>>
> >>>> > <mailto:grah...@healthintersections.com.au
<mailto:grah...@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=grah...@healthintersections.com.au&list=its
> >>>>> Terms of use -
> >>>>> http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> -----
> >>>> http://www.healthintersections.com.au /
> >>>> grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au> / +61 411 867 065
<tel:%2B61%20411%20867%20065>
> >>>>
> >>>
> >>
> >>
> >> --
> >> -----
> >> http://www.healthintersections.com.au /
> >> grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au> / +61 411 867 065
<tel:%2B61%20411%20867%20065>
> >>
> >
>
>
> --
> -----
> http://www.healthintersections.com.au /
grah...@healthintersections.com.au
<mailto:grah...@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>
(e...@w3.org <mailto:e...@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 /
grah...@healthintersections.com.au
<mailto:grah...@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=da...@dbooth.org&list=its>
| Terms of use
<http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
