Re: Heads Up: proposal deep linking

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 14:04:12 UTC