JSON-LD Community Group Telecon

Minutes for 2012-07-03

  1. FPWD of JSON-LD Syntax and API
  2. ISSUE-133: Add @container: @language
  1. Support language-maps via the "@container": "@language" pattern in @context.
Manu Sporny
Markus Lanthaler
Markus Lanthaler, Gregg Kellogg, Manu Sporny, Niklas Lindström, Zdenko 'Denny' Vrandečić, David I. Lehn
Audio Log
Markus Lanthaler is scribing.

Topic: FPWD of JSON-LD Syntax and API

Gregg Kellogg: Let's go over IPR status and protocol for editing specs. [scribe assist by Manu Sporny]
Manu Sporny: last week the RDF WG agreed to publish a FPWD.. should be online on July 12th
... we have all the IPR commitments we need except Josh's
Gregg Kellogg: I saw Mark Birbeck commited to syntax but not API
Manu Sporny: that's OK as he didn't contribute to API.. he's listed as author as author on syntax spec
... the protocol for editing the spec now is to not make text changes that are not directly requested
... going forward the only people that should making changes to the spec are Markus, Gregg, Niklas and myself or anyone else from the RDF WG
... what we can do is look at suggestions and come up with our own wording
Gregg Kellogg: dave longley made a change to fix a spec bug but made a mistake.. we should go and change that before FPWD
Manu Sporny: feel free to make that change
Markus Lanthaler: do we continue to use github or do we switch over to W3C's mercurial?
Manu Sporny: we keep on using github
Gregg Kellogg: the issue tracker as well?
Manu Sporny: yes, but once we go to last call we should track them in W3C's issue tracker
... to make sure to track everything..

Topic: ISSUE-133: Add @container: @language

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/133
... this issue was triggered by the wikidata people
... they need to express data in different languages
Gregg Kellogg: the observation was that maintaining information in multiple languages simultaneously would be more convenient by using language keys instead of language tagging literals
... wikidata would also find it convenient to group other things (whole subtrees) under a language tag
... think videos etc. in a specific language
... in the issue there are two approaches
... here's the summary:
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/133#issuecomment-6536114
... value-map vs. property-map
Manu Sporny: denny, what kind of structure would you ideally like to have?
Difficulty hearing Denny... he's dialing back in.
Markus Lanthaler: My concern is that on one hand, it feels a bit confusing for me to understand what's going on... from where Gregg is coming from with his proposal. [scribe assist by Manu Sporny]
Markus Lanthaler: Perhaps we could have different sub-graphs for each language... we specify default language in a context and do that instead. [scribe assist by Manu Sporny]
Niklas Lindström: I think at this time I agree mostly with markus
Zdenko 'Denny' Vrandečić: i hear you well on the call
... only because I have a fear that it might be difficult to understand data like this
... it should be clear by looking at the data what the subject etc. is
... of course there are places where we can't do this as JSON is quite terse
... but if we start to change the general entity-value shape I have concerns that that kind of JSON is difficult to understand
... I saw data modelled that way in RDF/XML
... but I think we shouldn't go down that way with JSON-LD
Markus Lanthaler: correction: in XML (RDF/XML can't really be reshaped like that) [scribe assist by Niklas Lindström]
Manu Sporny: it might be that wikidata found a use case for which JSON-LD isn't a good match and it would be quite difficult to support it... which would be a shame, because it seems like a pretty important use case.
Zdenko 'Denny' Vrandečić: the use case is to express labels in different languages
... the thing is that we don't want to have an array of objects but an associative map
... we don't wanna to iterate over the objects but rather have a key to directly access it
... this is a pattern used when writing JavaScript
Gregg Kellogg: denny, by that logic it seems that both approaches serve your needs?
Gregg Kellogg: the first option is value-map the second one would be the property-map in the issue
Zdenko 'Denny' Vrandečić: the thing is that we might wanna add more information to a label, e.g., the pronunciation
... without thinking at RDF in JSON I would just use an object with further keys
... keeping a link to a video, the pronunciation, etc.
... but I'm not sure if it's out of scope for JSON-LD
... alternative would be instead of using a single string as value I would use a object as value
Niklas Lindström: I think we have two quite distinct things here
... we have the map (language or IRI as the key)
... the other situation, the property-map
... the case where you divide a description of something in parts (categories)
... we might be able to support both
... the value-map by using @container
... and the property-map by leveraging as suggested by markus
... we could define a context modifier for @graph similar to something gregg proposed
Gregg Kellogg: we could extend @container: @graph
Niklas Lindström: we could also use content negotiation for different languages
Manu Sporny: let's summarize
... we have multiple graphs, each with a different language
... we have gregg's two proposals (value- and property-map)
... and markus' @container: @language proposal
Gregg Kellogg: I just wanted to throw in something denny considered: using an unlabeled node
Zdenko 'Denny' Vrandečić: I have problems following the discussion...
Manu Sporny: You're not the only one, Denny - this is a difficult discussion to follow.
Manu Sporny: out of gregg's proposals I would prefer this - "rdfs:label" : {"en": "Foo", ...}
Niklas Lindström: I would be careful with using rdf:value
Niklas Lindström: Denny, have you considered skosxl? http://www.w3.org/TR/skos-reference/skos-xl.html
Niklas Lindström: using different graphs would be reflect the fact that documents in different languages are expressed
Niklas Lindström: There are two things that Gregg mentioned - one of which is deep probing. [scribe assist by Manu Sporny]
Niklas Lindström: we might combine markus' proposal with using disjoint graphs and combine that with controlled probing
Niklas Lindström: We could use "@container": "@graph" - each key representing the specific graph... you could also bind the language 'en' - the IRI for the named graph. [scribe assist by Manu Sporny]
Manu Sporny: Denny, what would the ideal shape of the data would be for you?
Manu Sporny: What are we looking for here - foo.bar.en or en.foo.bar or foo.en.bar ?
Zdenko 'Denny' Vrandečić: label.en.value = "San Francisco"
... my understanding would be that the first one would be ideal
Zdenko 'Denny' Vrandečić: population.value = "300000"
Zdenko 'Denny' Vrandečić: capital.value = IRI
Zdenko 'Denny' Vrandečić: label.en.pronounciation = IRI
Manu Sporny: another thing denny mentioned was to associated the pronunciation with a specific language
Zdenko 'Denny' Vrandečić: but this really is outside of the scope of RDF, right?
Manu Sporny: denny you can express label.en.pronunciation in JSON-LD today, but it wouldn't transform over to RDF
Manu Sporny: label.en: { "value": "Foo", "pronunciation": "Feu" }
Zdenko 'Denny' Vrandečić: +1
Manu Sporny: assuming value is aliased to @value
... it wouldn't come accross to RDF
Niklas Lindström: in skosxl there are concepts for this
Zdenko 'Denny' Vrandečić: i think the issue with the skosxl solution is that for every sense of the word you need an IRI
Niklas Lindström: @context: { "label": {"@id": "skosxl:prefLabel", "@container": "dc:language"} }
Markus Lanthaler: Wondering if it's important to Denny to keep everything language-related in the same subtree? [scribe assist by Manu Sporny]
Markus Lanthaler: Could you have label/pronunciation in the same subtree? [scribe assist by Manu Sporny]
Markus Lanthaler: label.en and pronuncation.en vs. en.label and en.pronuncation
Zdenko 'Denny' Vrandečić: No, not important to have everything in same subtree - important to connect pronunciation w/ the label. [scribe assist by Manu Sporny]
Zdenko 'Denny' Vrandečić: so it is not important to have them in one tree
Gregg Kellogg: label: {en: {rdf:value: "Foo", pronunciation: "F-o-o"}}
Zdenko 'Denny' Vrandečić: but it is important to connect the pronounciation with the label
Zdenko 'Denny' Vrandečić: skos-xl does cover that, though, iirc
Niklas Lindström: .. gregg: skosxl:literalForm should be suitable
Zdenko 'Denny' Vrandečić: if something has two labels - like "USA" and "United States" - there would be distinct pronounciation URLs pointing to files
Niklas Lindström: for literals RDF has taken a simple path, we have to pay the price when we have to link resources to them (reification)
Manu Sporny: is it important that the RDF contains things like pronunciation?
Zdenko 'Denny' Vrandečić: it is not immediately important
Zdenko 'Denny' Vrandečić: it will be later
Zdenko 'Denny' Vrandečić: it would be a pity if the RDF representation would not be complete
... what I'm saying is you have it in JSON-LD but you loose it when converting to RDF
Zdenko 'Denny' Vrandečić: but not a catastrophe
Manu Sporny: so I think what we are talking about here is a simple macro that makes it easy to express it in JSON-LD and allows it to transform it to RDF
Niklas Lindström: today in RDF you would use structured labels such as used in skosxl
Manu Sporny: we are coming close to the end of the call
Zdenko 'Denny' Vrandečić: in an ideal world i would see the following: label.en = { value = "USA", pronouncation = "..:" } and have that translated to both w:USArdf:label "USA"^en and w:USA skos-xl:label _:1 . _:1 prefLabel "USA"^en ; pronouncation "…" .
Zdenko 'Denny' Vrandečić: yes, i agree
Niklas Lindström: this might be a bit too advanced for JSON-LD
Zdenko 'Denny' Vrandečić: understood and agreed. just saying :)
Niklas Lindström: we would have to make @value to be dualistic
... we are getting close to quantum-theory :-)
Zdenko 'Denny' Vrandečić: so we would simply have label.en = "USA" and label-xl.en = { value = "USA", pronouncation = "…" }
Zdenko 'Denny' Vrandečić: and that would be translated to both then
Niklas Lindström: +1 for that
Gregg Kellogg: the last example denny typed looks like a good way forward
Manu Sporny: niklas, are you saying you agree with this being a good way forward
Markus Lanthaler: niklas, could you type an expanded example?
Zdenko 'Denny' Vrandečić: -> _:1 dc:langauge "en"
Zdenko 'Denny' Vrandečić: Thanks for having me on the telco. I didn't intend to hijack it. I will have a draft of our planned rdf export soon, and then i would be glad to see further if we can go together
Manu Sporny: Not at all - this is an important use case and your need for it gives us clarity when attempting to find a solution to the issue.
Zdenko 'Denny' Vrandečić: ok, thanks
Manu Sporny: Denny, is JSON-LD a no-go for Wikidata if you don't have this feature?
Zdenko 'Denny' Vrandečić: hard to say
Zdenko 'Denny' Vrandečić: i would prefer to use json-ld
PROPOSAL: Support language-maps via the "@container"; "@language" pattern in @context.
Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1 (and possibly @id and regular properties)
Gregg Kellogg: +1
David I. Lehn: +0
RESOLUTION: Support language-maps via the "@container": "@language" pattern in @context.
Niklas Lindström: Another option is this - @context: { "label": {"@container": "@language"}, "label-xl": {"@id": "skosxl:prefLabel", "@container": "dc:language"} }
Niklas Lindström: which would produce this - {"label-xl": {"en": {"value": "stuff"}}} => {"label-xl": {"dc:language": "en", "value": "stuff"}}