Re: Heads Up: proposal deep linking

On Jun 5, 2012, at 10:04 PM, Markus Lanthaler wrote:

> Hi,
> 
>> {
>>  "queenie": {
>>    "@id": "http://buckingham.uk/queenie",
>>    "label": {
>>      "en": { "@value": "The Queen" },
>>      "de": { "@value": "Die Königin"}
>>    }
>> }
> 
> I think what you really mean here is 
> 
> {
>  "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.

> 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.

> 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"
>  }
> }

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.

>> Two things going on here, one would be to allow for a property to be
>> defined for both "en" and "de" (and other languages) which would have
>> the effect of applying a @context to set the @language for the sub-tree
>> rooted by the property, and remove the extra layer of object/property.
>> In essence, "en" would be defined within a context as something such as
>> {"@id": "null", "@language": "en"}, but with some other suggar that
>> indicated that it was to allow deep linking so that the contents would
>> be  processed, yielding something like the following:
>> 
>> [...]
>> 
>> We could potentially have some @context syntax such as the following:
>> 
>> "@context": {
>>  "en": {"@id": null", "@language": "en", "@fold": true},
>>  "de": {"@id": null", "@language": "de", "@fold": true},
>>  "queenie": {"@id": null", "@fold": true}
>> }
> 
> This is something I raised before as part of ISSUE-56 [3] and was raised
> again by Niklas in ISSUE-84 [4]. We came to the conclusion that this would
> be too uncontrollable and decided to not support it.
> 
> How would you see @fold work when "queenie" is a property of another valid
> subject, something like
> 
> {
>  "@id": "http://example.com/parent",
>  "queenie": {
>    "@id": "http://buckingham.uk/queenie",
>    "label": [
>     { "@value": "The Queen", "@language": "en },
>     { "@value": "Die Königin", "@language": "de" }
>    ]
> }
> 
> The only way I could see that it works is to restart processing by creating
> a disjoint graph.. I see the value of being able to directly access
> "quennie" but with framing you could achieve more or less the same, i.e.,
> making sure "queenie" is the only result at the top-level by filtering by
> @id (see [5]).

In this case, I don't think folding would apply; it's more similar to the case where we now use @graph to contain a list of properties; this would use a different name, and not have the named-graph consequence. The original use of @graph was to be able to list several subject definitions at the same level where we needed a key; the named-graph sense was added later.

I didn't mean to indicate that this was a fully baked concept, but that it was the result of some discussions where there are some common issues that are raised. In WikiData's case, a desire to separate sections of the JSON by language without imposing semantic overhead, and to be able to effectively use subjects are keys, also without the semantic overhead.

>> This wouldn't have to survive expansion, but should probably work with
>> framing, so that you could re-create this structure.
> 
> If it doesn't survive expansion, it wouldn't work with framing as expansion
> is the first step in framing for both the input document as well as the
> frame itself.

It could still work if the frame could be specified and applied to the graph.

> So, summarized, I'm -1 for the controlled probing (@fold) stuff, and +0 for
> the language map container. What I would like to hear is how the documents
> are going to be used, i.e., consumed. For the publisher almost every option
> is fine and doesn't create much (any?) overhead. It really boils down to who
> is using it how for what and that's not clear to me.

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.

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).

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 Wednesday, 6 June 2012 05:50:00 UTC