Linked Data in JSON Telecon

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

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

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

Manu Sporny: denny, what kind of structure would you ideally like to have?

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

... 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

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

... the case where you divide a description of something in parts (categories)

... 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)

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

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

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

Niklas Lindström: +1 (and possibly @id and regular properties)

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"}}

JSON-LD Community Group Telecon

Minutes for 2012-07-03

Topic: FPWD of JSON-LD Syntax and API

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