- From: Grahame Grieve <grahameg@gmail.com>
- Date: Sat, 21 Mar 2015 10:47:51 +1100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Grahame Grieve <grahame@healthintersections.com.au>, David Booth <david@dbooth.org>, 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: <5F1657FD-A9D0-42AE-BB3E-9145F6D43B96@gmail.com>
Hi Gregg
Thanks for responding. Comments in line
> On 21 Mar 2015, at 9:18 am, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>
> David’s read is correct: it is the use of @context in nesting, particularly to re-define terms to have a different meaning, which is considered not a best-practice, not the nesting of objects.
So go back to my original example:
>>> {
>>> "person" : {
>>> "dob" : "1975-01-01",
>>> "name" : {
>>> "family" : "Smith",
>>> "given" : "Joe"
>>> }
>>> },
>>> "organization" : {
>>> "name" : "Acme"
>>> }
I don't want to use nested @context either. In this example, name is used twice, both times with the same 'meaning', but with different implications about content and detailed semantics. Is this redefining terms to have different meanings?
> Nesting is fundamental to JSON, as it is to XML. The point is, it seems to be common in XML to use different namespaces at different elements, based on the @xmlns attribute.
Nah, I've never liked xml namespaces either. Though json-ld does something functionally the same with prefixes.
>
> If you do want to use different namespaces with terms having different meanings (say schema:name and foaf:name), then consider using prefixed-names.
No, we just want to do what I shopped above
>
> That said, if you have a good reason to embed contexts, it is fully supported and will work across implementations. There is an outstanding feature request for “Scoped contexts” [1] which would allow a single top-level context to define terms which take on a different meaning within a sub-node. This would have the advantage of being (potentially) round-trippable.
That looks pretty much what I'm talking about. From reading the comments, I agree it has complexities, but from where I stand, trying to function without that is being too simple. So I vote for it wherever I can, and I think that would hold for my community too.
What's its path to formal adoption?
Grahame
>
> Gregg Kellogg
> gregg@greggkellogg.net
>
> [1] https://github.com/json-ld/json-ld.org/issues/247
>
>> On Mar 20, 2015, at 1:12 PM, Grahame Grieve <grahame@healthintersections.com.au> wrote:
>>
>> 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 Monday, 23 March 2015 12:21:22 UTC