JSON-LD Telecon Minutes for 2012-06-26

Thanks to Markus for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-07-03/

Full text of the discussion follows including a link to the audio
transcript:

--------------------

JSON-LD Community Group Telecon Minutes for 2012-07-03

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0091.html
Topics:
   1. FPWD of JSON-LD Syntax and API
   2. ISSUE-133: Add @container: @language
Resolutions:
   1. Support language-maps via the "@container": "@language"
      pattern in @context.
Chair:
   Manu Sporny
Scribe:
   Markus Lanthaler
Present:
   Markus Lanthaler, Gregg Kellogg, Manu Sporny, Niklas Lindström,
   Zdenko 'Denny' Vrandečić, David I. Lehn
Audio:
   http://json-ld.org/minutes/2012-07-03/audio.ogg

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]
https://github.com/json-ld/json-ld.org/issues/133#issuecomment-6548061
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"}}

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Tuesday, 3 July 2012 18:58:54 UTC