- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 6 Jun 2012 13:04:28 +0800
- To: "'Linked JSON'" <public-linked-json@w3.org>
- Cc: 'Denny Vrandeèiĉ' <denny.vrandecic@wikimedia.de>
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" :-) 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]). 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" } } > 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]). > 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. 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. [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 -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 6 June 2012 05:05:05 UTC