- From: Grahame Grieve <grahame@healthintersections.com.au>
- Date: Sat, 21 Mar 2015 07:12:29 +1100
- To: David Booth <david@dbooth.org>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, Linked JSON <public-linked-json@w3.org>, Jim McCusker <mccusj@rpi.edu>, Markus Lanthaler <markus.lanthaler@gmx.net>, Manu Sporny <msporny@digitalbazaar.com>
- Message-ID: <CAG47hGYhDqDu+uw5fk73wMkCd3e9O8cn35FUpO7ZYBKHvX7oew@mail.gmail.com>
hi David
It wasn't meant to be offensive. Sorry. it's just so foreign to me. As is
this sentence:
> 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.
but XML is just syntax. it's true that the content is hierarchical, but
that has nothing
to do with syntax. Even if we had never used XML, we still would have
something
very similar, because information has context, and that matters. I've tried
using
things that are flat. and they're just really frustrating because they end
up
implying structure in all sorts of variable ways buried in the syntax,
because
hierarchical structure matters.
Take this case
Patient has a name
Patient has multiple contacts
Each Patient contact has a name
That's inherently nested. How is that going to be represented without that?
Well, one answer is that you make a rule for tooling reasons that the
resource
content has to be flat, and therefore at the 2nd or third level, you have to
introduce a new resource, and a new HTTP access, and a new transaction
boundary, and whole lot of costs. The most significant of which is that your
transaction boundary is defined by your tooling choices.
We define our transaction boundaries - they really matter immensely. Then
we figure the rest out. Hence some of our resources are not shallow.
Please explain to me if I am understanding this wrong?
as for this:
> 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.
oh I agree with this - we want only one. But we want it to follow structure
since that's how information works - as we understand it. So to me json-ld
seems unusable in any context I've worked in because it doesn't seem
to support heirarchy.
And, btw, it seems like a very small change to me - in the json fragment
that @context points to (not sure quite what it should be called) you can
assign a type to each 'term' like @id - well, you could assign the @context
there, instead of in the instance - 'this term defines a new name resolution
context'. bingo, we could use json-ld. Unless the intent is that json-ld
stands for a particular kind of information layout, one that we can't
achieve
in healthcare, so far as I can see.
Grahame
On Sat, Mar 21, 2015 at 1:07 AM, David Booth <david@dbooth.org> wrote:
> 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
>>
>
--
-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au
/ +61 411 867 065
Received on Friday, 20 March 2015 20:12:58 UTC