Re: Heads Up: proposal deep linking

Hi,

I really think these are important use cases. As you have also
mentioned, it is rather common in "plain" JSON to use objects as maps,
where the keys are either the subject or some property of the value.
This is one of the few things I've felt that compact JSON-LD may be
missing.

On Wed, Jun 6, 2012 at 7:49 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> On Jun 5, 2012, at 10:04 PM, Markus Lanthaler wrote:
[...]
>> {
>>  "queenie": {
>>    "@id": "http://buckingham.uk/queenie",
>>    "label": {
>>      "en": "The Queen",
>>      "de": "Die Koenigin"
>>    }
>> }
>>
>> as otherwise the @value would reset the language. Anyway, this is something
>> Niklas raised before under the term "language map" ISSUE-29 [1]..
>> Unfortunately we didn't discuss that very much and funnily enough you were
>> the only one to -1 it as "too complex" :-)
>
> Yes, it would, and you might think of it as "value", instead of "@value"; but it's really just an example. The idea would be that "en" would basically insert a @context at that level which would set "@language" to "en". But, there might be other things at that level.
>
> AFAIKR, it was a bit complex, but this seems different to me now; perhaps it's just a different way of looking at it. Really, the story is to figure out a way of allowing properties to be used for deep linking without introducing semantic overhead; the @language promotion, as Denny said, might not be as important, but something like that does seem useful.

I think that getting deep linking right may be more complex and
difficult to get right. And the language is there (quite capturable)
in the key, so I was happy to see Markus' suggestion below (which I'll
get to right after the next remark..).


>> The question here is really if this is any easier than
>>
>>    "label_en": "The Queen",
>>    "label_de": "Die Koenigin"
>>
>> or
>>
>>    "label": [
>>      { "@value": "The Queen", "@language": "en" },
>>      { "@value": "Die Koenigin", "@language": "de" }
>>    ]
>>
>> especially considering that we plan to make framing more powerful which
>> would allow you to retrieve just the desired language (see example [2]).
>
> >From Denny's perspective, having a single "label" with properties that can be iterated upon is the key here, not having multiple properties related by naming tricks. Also, assigning a language to label_en, for example, does not actually result in setting @language for other things contained within that property.

I agree that the goal here is for compact JSON to be directly usable,
for a *specific* scenario. If someone has the knowledge and tooling
available to digest JSON-LD, the question is still open whether
framing or objectify/graphify (or actually using a full RDF API) to
process the data is the most effective way to go.

Meanwhile, simple and specific scenarios should have at their disposal
a palatable compact JSON-LD, in order to support things like "look up
title by language" if that is the desired scenario. (Other scenarios
will involve other contexts. Such as a context with a predefined
language -- either by key or a globally applied language --,
effectively filtering out any other language value.)


>> If we are going to support something like this, I think we should leverage
>> our @container mechanism for this. Something like
>>
>> {
>>  "@context": {
>>    "label": {
>>      "@id": "http://example.com/label",
>>      "@container": "@language"
>>    }
>>  },
>>  "@id": "http://buckingham.uk/queenie",
>>  "label": {
>>    "en": "The Queen",
>>    "de": "Die Koenigin"
>>  }
>> }

Yes! This is exactly what I've been thinking about regarding the
possible use of @container.

Think of it this way: @container is already a mechanism for letting
the two currently defined container keywords, @set and @list,
interpret a given array in their own specific way. We can extend the
behaviour of @container to let *all* of @language, @id, @type *and
regular terms* treat an object as a map, in their own, specific ways.

We've just seen the use of @container with @language in Markus' example above.

Here's an example of using @container with @id:

    {
      "@context": {
        "booksByUrl": {"@id": "@graph", "@container": "@id"},
        "isbn": "bibo:isbn"
      },
      "booksByUrl": {
        "http://dbpedia.org/resource/Gödel,_Escher,_Bach": {
          "isbn": "978-0465026562"
        }
      }
    }

And here is one using @container with bibo:isbn:

    {
      "@context": {
        "booksByIsbn": {"@id": "@graph", "@container": "bibo:isbn"},
        "url": "@id"
      },
      "booksByIsbn": {
        "978-0465026562": {
          "url": "http://dbpedia.org/resource/Gödel,_Escher,_Bach"
        }
      }
    }

Granted, I'm not sure that we can use @graph like that today? But I'm
sure you can imagine replacing @graph by some membership property such
as "collection item" or "library holding".

(The use of @type is more esoteric, although I could imagine e.g.
someone wanting to consume an RDFS/OWL vocabulary with classes and
properties divided into subsets. Or subsets of persons/organisations,
books/paintings/songs by artist, etc.)


> It's a pretty confusing use of @container, and the other example shows folding without actually introducing a language, so it's not quite that simple.

In the case of 'queenie', I think that can either represent a relative
IRI, or a literal token (e.g. foaf:nick).


> Perhaps Denny can chime in on some more of his specifics, but I've had a couple of interactions that wanted to have a means of grouping language-variations of property values under a common key, which is certainly a reasonable way to want to structure JSON.

Indeed.


> The issue of having some subject-like key is something we've seen in other JSON representations, and it could be considered to be a weakness of JSON-LD that we can't adapt to take such input. Being able to associate some deep linking behavior with such keys at least allows them to not be ignored. Requiring that the keys actually are used to create triples seems like it's adding an unnecessary burden, if it is indeed a common use case. I faced similar issues myself when constructing the RDFa Earl Report [6], where I needed to add keys just to create the JSON geometry I needed to work with, and I just needed to live with the junk triples they created (notice how "http://code.google.com/p/green-turtle/" is used as a property, only to create the desired linking).

I actually think that using the keys as values for properties is a
tremendous opportunity to capture a common JSON pattern succinctly and
uniformly. In fact, in your (our) specific use case of EARL, the RDF
gets a bit strange in these places, with some odd properties that
would really work better as objects in triple form. Following the
examples from above, I'd imagine a context containing definitions like
these could be useful:

    "@context": {
      "version": {"@id": "rdfatest:version", "@container":
"rdfatest:versionNumber"},
      "hostLanguage": {"@id": "rdfatest:hostLanguage", "@container":
"rdfs:label"},
      "testCases":  {"@id": "rdfatest:testCases", "@container": "@list"},
      "subject": {"@id": "rdfatest:version", "@container": "@id"}
    }

Just a quick sketch, but I hope you see my point. That said, I'm open
to discuss either extending @container *or* revisiting deep linking.
At this stage though, I suspect that a more powerful @container will
make things more uniform, and provided that a consumer understands the
context, easier to work with the data exploratively.

I believe that compact JSON-LD should be something to aspire to as a
way of understanding (and documenting the nature of) quite
context-specific data, often designed for fairly narrow use-cases and
APIs. At the same time though, JSON-LD should constrain more
extravagant and odd forms of JSON, since we shouldn't define an entire
transformation language. Given a @context, uniformity in the data is
certainly a goal.

(I also believe a @rev mechanism would be beneficial here. But that's
another topic which we've discussed elsewhere.)

Best regards,
Niklas

[PS. I've encountered more use cases for these things, not the least
lately while I've worked with JSON data for the Swedish Royal Library.
We currently work very "tactically" with existing data in real editing
scenarios, and do not have the time nor resources at this stage to
reshape that into proper JSON-LD. Also, various shapes in the data are
just "odd" as is, and merely designing a JSON-LD context for that
wouldn't be useful. For those in the library business, I'm taking
about MARC here. ;) But in certain places there *is* uniformity to be
gleaned, where it'd *still* be useful to keep some property values or
URLs as keys. This is especially true for certain "mapping" data (e.g.
descriptions of various keys and their meanings). Alas, all of this is
too multifaceted to go into here, but suffice to say I see potential
in this more powerful @container also here. And I see this *after* the
various transforms initially needed to shape and lift certain odd data
into more uniformity. The verdict on the final form is still out
though; this will be a long process. I merely suspect that in certain
cases here, this extended @container mechanism just might be what
sells using JSON-LD contexts to lift various instrumental pieces into
RDF.]


> If we're not willing to listen to considered feedback from the community and consider changes to the spec to meet their requirements, then I'm not sure we're being good advocates for the community.
>
> Gregg
>
>> [1] https://github.com/json-ld/json-ld.org/issues/29
>> [2] http://bit.ly/KNOK2X
>> [3] https://github.com/json-ld/json-ld.org/issues/56
>> [4] https://github.com/json-ld/json-ld.org/issues/84
>> [5] http://bit.ly/JKxbwN
> [6] http://rdfa.info/earl-reports/earl.jsonld
>
>> --
>> Markus Lanthaler
>> @markuslanthaler

Received on Thursday, 7 June 2012 23:46:04 UTC