Re: Heads Up: proposal deep linking

Denny, as Markus indicates, issue 133 is where we've been discussing this. At this point, the group has resolved to add something like @container: @language to support this use case, but there are a couple of different proposals for what this might mean. i laid out the two alternatives in my comment:

https://github.com/json-ld/json-ld.org/issues/133#issuecomment-6536114


I think the property-map proposal matches what you've been considering for WikiData. If you can join us on Tuesday's telecon, that would be great!

http://json-ld.org/minutes/


Gregg

On Jun 27, 2012, at 7:03 AM, Denny Vrandečić wrote:

> Hi Gregg, all,
> sorry, I cannot figure out how we have resolved. May I propose an IRC
> chat session for anyone who wants to join to discuss the status and
> what still needs to be done?
> Cheers,
> Denny
> 
> 
> 
> 2012/6/8 Markus Lanthaler <markus.lanthaler@gmx.net>:
>> OK, I've created ISSUE-133 and ISSUE-134 for this, let's continue the
>> discussion there:
>> 
>> https://github.com/json-ld/json-ld.org/issues/133

>> https://github.com/json-ld/json-ld.org/issues/134

>> 
>> 
>> Denny, since you were the one to trigger this discussion, it would be nice
>> if you could give us some more information on how you intend to consume data
>> in WikiData as this directly affects that. Some specific use cases/scenarios
>> would help immensely in designing this.
>> 
>> 
>> Thanks,
>> Markus
>> 
>> 
>> --
>> Markus Lanthaler
>> @markuslanthaler
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Niklas Lindström [mailto:lindstream@gmail.com]
>>> Sent: Friday, June 08, 2012 7:45 AM
>>> To: Gregg Kellogg
>>> Cc: Markus Lanthaler; Linked JSON; Denny Vrandečić
>>> Subject: 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
>> 
> 
> 
> 
> --
> Project director Wikidata
> Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
> Tel. +49-30-219 158 26-0 | http://wikimedia.de

> 
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
> Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Received on Wednesday, 27 June 2012 16:37:54 UTC