Re: [FHIR JSON-LD] Possible to generate implied triples from @context?

Hi Grahame,

On 03/20/2015 07:17 AM, Grahame Grieve wrote:
> hi
>
> So I've been doing more research on json-ld, and I've come across this
> statement:
>
> In the example above, the |name|term
> <http://www.w3.org/TR/json-ld/#dfn-term> is overridden in the more
> deeply nested |details| structure. Note that this is rarely a good
> authoring practice and is typically used when working with legacy
> applications that depend on a specific structure of the JSON object
> <http://www.w3.org/TR/json-ld/#dfn-json-object>.
>
> That sounds pretty weird to me. Take this json:
>
> {
>    "person" : {
>      "dob" : "1975-01-01",
>      "name" : {
>       "family" : "Smith",
>       "given" : "Joe"
>      }
>    },
>    "organization" : {
>       "name" : "Acme"
>    }
>
> Are you saying that this is not a good authoring practice? Do you need
> to expand the parent name into the child, like person-name, and
> organization-name? That sounds so stupid I can only think I've
> mis-understood

Please, let's not use potentially offensive characterizations.  There 
was a lot of hard work that went into JSON-LD by a number of very smart 
people.  You may have a different view of how things should be done, but 
there's no need for disparaging characterizations.

My reading of that part of the spec is that it's saying that it is not a 
good idea to have a lot of different @contexts, applying at different 
places in the JSON structure.   That advice makes sense to me, because 
doing so is apt to cause a lot of confusion.  The @context essentially 
says how the JSON should be interpreted, so if you're continually 
re-defining how the JSON should be interpreted then that's going to be 
very confusing.  It can be done, but it's really not the usage style 
that's intended.

It sounds like what's coming out is that JSON-LD was not really designed 
to address a style of JSON in which the meaning of a term is very 
context dependent.  That style is more like an XML style, involving lots 
of nesting, with the same term meaning different things in different 
places.  It is more complex to interpret than a flatter style.

One of the things that jumped out at me when I looked at FHIR XML versus 
FHIR JSON was that the XML representation was pretty clearly being 
treated as the primary representation, and the JSON was designed to 
model the XML -- not the other way around.   A consequence of that is 
that the style of the FHIR JSON looks very much like a classic nested 
XML style, with context-dependent terms.

David Booth

>
> Grahame
>
>
> On Wed, Mar 18, 2015 at 10:38 AM, Gregg Kellogg <gregg@greggkellogg.net
> <mailto:gregg@greggkellogg.net>> wrote:
>
>>     On Mar 17, 2015, at 3:11 PM, Grahame Grieve
>>     <grahame@healthintersections.com.au
>>     <mailto:grahame@healthintersections.com.au>> wrote:
>>
>>     but my point was, if you have  "@context" :
>>     "http://hl7.org/fhir/__StructureDefinition/Substance
>>     <http://hl7.org/fhir/StructureDefinition/Substance>"__, you don't
>>     need "resourceType": "Substance"
>>
>>     Presumably the @context information makes it's way into the RDF
>>     somehow?
>
>     Nothing in the @context directly causes any RDF to be generated,
>     only when terms in the context are used within the JSON does it
>     provide the “context” to know how to generate something. Typically,
>     this is confined to turning terms and prefixed names into IRIs, or
>     for knowing if the value of a property has a datatype, language or
>     is an IRI.
>
>     The important thing to remember about the context is that it does
>     not provide any content itself, simply a _context_ for the JSON so
>     that it can be properly interpreted. The complexity of handling a
>     context typically comes from the need to round-trip JSON through
>     expansion and compaction, or even through some other RDF format.
>     Given that multiple terms can resolve to the same IRI but with
>     different container or datatypes, this can be challenging. Adding
>     more information to a term definition which has content associated
>     with it would make it more challenging still.
>
>     There have been previous discussions about doing more in the
>     context, for example providing a sub-context that would take effect
>     for values of a particular term. There also seems to be some thought
>     that a term definition might provide some data which could be
>     emitted, such as an rdf:type triple; this seems less likely for a
>     future group to take up.
>
>     At some point, the different feature requests that would go into a
>     JSON-LD 1.1 or 2.0 would need to be vetted and used to create a
>     charter for a new group. Of course, members with adequate free time
>     to do this also need to be found, and most of the original
>     authors/editors are pretty committed right now typically putting
>     JSON-LD to use for other specifications. But, given popular support,
>     a WG with a charter to advance JSON-LD to address shortcomings
>     and/or features of the current spec seems like it is inevitable.
>
>     A number of features to be considered for the next JSON-LD version
>     are tracked on github [1]. Consider creating a new feature request
>     if it isn’t covered.
>
>     Gregg
>
>     [1] https://github.com/json-ld/json-ld.org/milestones/JSON-LD.next
>
>>     Grahame
>>
>>
>>     On Wed, Mar 18, 2015 at 9:08 AM, David Booth <david@dbooth.org
>>     <mailto:david@dbooth.org>> wrote:
>>
>>         This question came up here:
>>         https://lists.w3.org/Archives/__Public/public-semweb-lifesci/__2015Mar/0065.html
>>         <https://lists.w3.org/Archives/Public/public-semweb-lifesci/2015Mar/0065.html>
>>
>>         Is it possible to generate an RDF triple without an explicit
>>         property in the JSON-LD?  Instead of having to write:
>>
>>         {
>>           "@context" :
>>         "http://hl7.org/fhir/__StructureDefinition/Substance
>>         <http://hl7.org/fhir/StructureDefinition/Substance>"__,
>>           "resourceType": "Substance",
>>           ...
>>         }
>>
>>         it would be nice if we could just write:
>>
>>         {
>>           "@context" :
>>         "http://hl7.org/fhir/__StructureDefinition/Substance
>>         <http://hl7.org/fhir/StructureDefinition/Substance>"__,
>>           ...
>>         }
>>
>>         but still generate an RDF triple like:
>>
>>           _:foo fhir:resourceType fhir:Substance .
>>
>>         Is this possible?
>>
>>         Thanks,
>>         David Booth
>>
>>
>>
>>
>>     --
>>     -----
>>     http://www.healthintersections.com.au
>>     <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

Received on Friday, 20 March 2015 14:08:13 UTC