RE: Heads Up: proposal deep linking

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

Received on Friday, 8 June 2012 07:39:30 UTC