JSON-LD Community Group Telecon

Minutes for 2012-07-31

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0054.html
Topics
  1. Feature freeze of JSON-LD
  2. Lin Clark public domain dedication
  3. Drupal Language-Map requirement discussion
  4. JSON-LD issues reflected in W3C Tracker
Resolutions
  1. Add support for language maps via the "@container": "@language" annotation in @context. For example: "tags": { "@id": "http://example.com/vocab#tags", "@container": "@language"}. The value of the term MUST be an associative array. All associative array keys MUST be BCP47 language strings.
Chair
Manu Sporny
Scribe
Markus Lanthaler
Present
Markus Lanthaler, Manu Sporny, Niklas Lindström, Lin Clark, Gregg Kellogg, David I. Lehn
Audio Log
audio.ogg
Markus Lanthaler is scribing.
Manu Sporny: Any changes to the Agenda?
Markus Lanthaler: Ivan sent an e-mail earlier today, propose to feature freeze JSON-LD: http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jul/0068.html [scribe assist by Manu Sporny]

Topic: Feature freeze of JSON-LD

Manu Sporny: I'm a bit worried about doing a feature freeze
... while there are still folks like Lin out there who have certain needs that we don't address yet
Markus Lanthaler: At some point we need to feature freeze but I think we should at least carefully look at the container stuff
Niklas Lindström: We all want to make things easier but often to make things usable you have to compromise simplicity
Manu Sporny: OK, I think we have to push this request from Ivan back a bit
... on the same time we have that unspoken agreement to keep it simple and try to avoid adding features
... that's why we are talking about the pre-processing step e.g.
Niklas Lindström: in going forward when discussing the container stuff we have to keep in mind that the data shape gets distorted
... this makes it e.g. difficult for some tools to extract the id as it is no longer in the object itself

Topic: Lin Clark public domain dedication

Manu Sporny: It's important for Lin to declare that she doesn't own any intellectual property that she is going to discuss today (such as patents or copyright), that she is not going to propose solutions for which she knows patents exist (or that she will tell us if there are any patents that cover ideas being discussed), and that she is granting a license to the W3C to publish anything she says today in a future specification.
Lin Clark: I agree to all of those terms.

Topic: Drupal Language-Map requirement discussion

Manu Sporny: http://groups.drupal.org/node/244158#comment-793008
Lin Clark: basically the problem is that we language tagged literals as well as language-specific entity references
... as Markus pointed out these are really different entities
... but we are going to move to a single entity in Drupal
... we have to do this as the property level and not at the entity level
Manu Sporny: what's the ideal way a developer would access the data?
Manu Sporny: Would it be something like data.en.value?
Lin Clark: Could you type an example in IRC?
Manu Sporny: field_name.en = [{'@id': 'http://example.com/node/en/foo', 'value': 'foo'}, {'@id': 'http://example.com/node/en/blah', 'value': 'blah', 'formattedValue': 'Blah\nBlah'}]
Manu Sporny: is this the type of structure you are looking for?
Lin Clark: yes
Manu Sporny: to access, the developer would do: field_name.en[0].value ?
Niklas Lindström: an option would be to use @container: @id
... but you wouldn't have language tagged literals then
... I think for raw literals you would probably like to use the container language feature as well
Lin Clark: I think we would like to use the same structure/feature everywhere.. even if that makes it more verbose
Manu Sporny: two options: [{}, {}, {}] vs. [”, ”, ”], which one would developers use?
Lin Clark: we would probably use the first option as we probably need to store more attributes not just plain values (literals)
... if we were going to translate it to a different RDF serialization we would probably apply transformations anyway
... we would probably use framing for this
Manu Sporny: framing wasn't really designed for this
... it was more to transform incoming data to a form more suitable for consumption as JSON-LD
Lin Clark: in the Drupal community we do not have RDF knowledge, so we don't really need to worry about this
Manu Sporny: people would normally just use JSON-LD's toRDF() and put the output in a triple store
Lin Clark: this was more related to accessing the language information e.g.
... but this is not a high priority
... discussion about how to get RDF in a "nice" shape out of Drupal ...
Manu Sporny: What I see here is that the .en in the example is basically doing a context modification
... what we could do is to interpret that as a modification of the context (changing the default language)
Manu Sporny: '@context': {'@modifyLanguage': ['en', 'es', 'ja']}
Gregg Kellogg: isn't that what I originally proposed?
Manu Sporny: anytime you did foo.ja.bar
Manu Sporny: If it is, I didn't understand it
Manu Sporny: '@context': { '@language': '@ja' }
... it would inject this
Gregg Kellogg: "es": {"@container": "@language"},
Manu Sporny: is this what you proposed Gregg?
... this would mean that everytime you see the key "es" it injects a context and sets default language to "es"
Niklas Lindström: .. "@language" as shorthand for {"@context": "@language"}
Manu Sporny: 'en': '@language' ?
Niklas Lindström: … "tags": {"@container": "@language"}
Markus Lanthaler: this is what gregg originally proposed: "en": {"@id": null", "@language": "en", "@fold": true},
Niklas Lindström: .. {"@context": "@language"}
Niklas Lindström: .. "@language" as shorthand for {"@context": "@language"}
Niklas Lindström: .. "@language" as shorthand for {"@context": {"@language": <key>}}
Niklas Lindström: the difference is whether we have to create a term for every language vs. a term which then contains a language map
Gregg Kellogg: Well, this wouldn't give you a very usable RDF signature.
Lin Clark: I don't think we really have to have a nice RDF signature.. despite all the buzz about RDFa support in Drupal we haven't seen big adoption of it
Niklas Lindström: … "tags": {"@container": "@language"}
Niklas Lindström: "tags": {"en": {"value": "Hi"}}
Gregg Kellogg: niklas, I have "tags": {"@container": "@language"} you have "es": {"@container": "@language"}
Manu Sporny: I'm lost. Are these the two options you guys were discussing? "field_name": {"@container": "@language"} vs. "en": {"@container": "@language"}
Niklas Lindström: … "tags": {"@container": "@language"}
Niklas Lindström: "tags": {"en": [{"@id": "a", "value": "Hi"}]}
Gregg Kellogg: I think Niklas' approach is more concise
Manu Sporny: "tags": {"@id": "http://example.com/vocab#tags", "@container": "@language"}
... and it also allows other things such as the skosxl example
Manu Sporny: This is what the Drupal folks would use: tags.en[0].value
Manu Sporny: This is what the Wikidata folks would use: tags.en
Niklas Lindström: The effect of "tags": {"@id": "…#tags", "@container": "@language"}
Niklas Lindström: ... equivalent to "tags": [{"@context": {"@language": "en"}, "@id": "a", "value": "Hi"}]
Niklas Lindström: ... equivalent to (perhaps in the future) "tags": [{"@language": "en", "@id": "a", "value": "Hi"}]
Niklas Lindström: I would also propose to allow to set the default language outside of @context
... this would make it simpler to understand the container feature
Manu Sporny: Is this the proposal: "tags": {"@id": "http://example.com/vocab#tags", "@container": "@language"}
Manu Sporny: the way you access this form of data is: tags.LANGUAGE.ANY_PROPERTY
Markus Lanthaler: this data "tags": { "en": { "value": "ok" } } with container language would be equivalent to "tags": { { "@context": { "@language": "en" }, "value": "ok" } }
Niklas Lindström: the upside is that this works for Drupal/Wikidata use cases, the downside of all of the proposals is that you probably can't use them for simple compaction algorithms - round-tripping is affected as you would have to partition the data per language
Lin Clark: I'm a little concerned... Are you saying that when you compact all data is combined into one property
Niklas Lindström: no, it wouldn't combine them but it would be difficult for a processor to create a language map in compaction
Gregg Kellogg: my feeling is that compaction is already too complex
Markus Lanthaler: Question for Lin? If we are going to support the language map stuff, you'd still have the issue with references - you have references to terms which are then translated. [scribe assist by Manu Sporny]
Markus Lanthaler: You have different terms for english vs. german version. I don't see how this proposal would solve that issue. [scribe assist by Manu Sporny]
Lin Clark: This would give us what we need in JSON-LD... as long as expansion/compaction work... if we can say object.field_name.language and then get an array of nodes - that's fine. [scribe assist by Manu Sporny]
Markus Lanthaler: You'd lose the form if you do .compact()/.expand() [scribe assist by Manu Sporny]
Lin Clark: This is the problem that I'm trying to understand... going back/forth between compaction/expansion - the shape was maintained. [scribe assist by Manu Sporny]
Lin Clark: Having dc:language as a part of the node could make it so that we could use framing... by relying on dc:language. [scribe assist by Manu Sporny]
Manu Sporny: this is something we have been discussing in the last weeks
... every feature we add makes compaction more complicated, at a geometric rate, to a point where it gets impossible
... I don't think that the Drupal use case needs round-tripping
... more then likely the consuming system will use the data directly, they won't need to compact/frame/etc. the data
... just systems using RDF triple stores or other technologies would need to do that
... Lin, do you think round-tripping is required?
Lin Clark: we are publishing a compact form, then when people wanna merge two sites that use different terms.. what would be the easiest way to do that if you can't use expansion?
Gregg Kellogg: you probably want to flatten in that case as otherwise you would probably have multiple definitions for the same subject
Lin Clark: what does JSON-LD buy us then when we can't use the general tool for merging?
Gregg Kellogg: it allows you to explicitely define what terms mean etc.
Manu Sporny: the other thing it gives you is that it allows you to merge the data easily without worrying about conflicts.
Niklas Lindström: a possible way to approach the non-orthogonality of compaction/expansion would be to move all container mapping features to framing and just leave @set and @list in the syntax spec.
Markus Lanthaler: article.en - tagA, tagB, article.de - tagB, tagC
Markus Lanthaler: It's still the same problem - you can't merge the data anymore... you can't even expand it. [scribe assist by Manu Sporny]
Markus Lanthaler: You'd lose the language information. [scribe assist by Manu Sporny]
Markus Lanthaler: How do you get back to this? "article": { "en": { "@id": "tagA" } }
Manu Sporny: Expanded form would be: "article": { "@context": {"@language": "en"}, "@id": "tagA"}
Markus Lanthaler: Maybe we could do this? "article": { "@language": "en",, "@id": "tagA"}
Manu Sporny: Add the following ability to the @context - "tags": { "@id": "http://example.com/vocab#tags", "@container": "@language"}
Markus Lanthaler: we decided that already: http://json-ld.org/minutes/2012-07-03/ "Support language-maps via the "@container": "@language" pattern in @context."
Manu Sporny: Yes, but we didn't explain exactly /how/ we would accomplish this. The proposal on the table right now states how we would accomplish this.
PROPOSAL: Add support for language maps via the "@container"; "@language" annotation in @context. For example - "tags"; { "@id"; "http;//example.com/vocab#tags", "@container"; "@language"}. The child property of the term MUST be an associative array. All associative array keys MUST be BCP47 language strings.
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1 ... nitpick: the value of the term MUST be an associative array
Niklas Lindström: +1
David I. Lehn: +0
Lin Clark: abstain... waiting to see compaction/expansion example
RESOLUTION: Add support for language maps via the "@container": "@language" annotation in @context. For example: "tags": { "@id": "http://example.com/vocab#tags", "@container": "@language"}. The value of the term MUST be an associative array. All associative array keys MUST be BCP47 language strings.
Niklas Lindström: How do you expect the Drupal community to use the JSON-LD? As JSON, or as RDF data?
Lin Clark: I think the primary use is as JSON data, but it would be nice if we could use the JSON-LD API to merge data between websites.
Manu Sporny: I would be wary of telling Drupal developers that they should use the API... it leaves some folks without implementations out in the cold, which is not good for adoption.
Lin Clark: Merging isn't the primary use case, but it would be nice if the API allowed full round-tripping between compact and expanded form.
Manu Sporny: Yes, we are going to try to accomplish that. I think we have a proposal that does that, the only question is whether or not we're going to allow the added complexity to the compaction algorithm.

Topic: JSON-LD issues reflected in W3C Tracker

Gregg Kellogg: Guus asked us to reflect issues in the issue tracker... [scribe assist by Manu Sporny]
Manu Sporny: We discussed this in the RDF WG and agreed that we'd continue to track issues in github's issue tracker. [scribe assist by Manu Sporny]
Manu Sporny: My understanding is that it's fine as long as we track the issues on github, cc the RDF WG on all telecon minutes, and summarize changes to the spec to the RDF WG. [scribe assist by Manu Sporny]
Manu Sporny: I don't think Guus was on the call when we decided that this was the best course of action. [scribe assist by Manu Sporny]
Markus Lanthaler: We could make it so that we cc the RDF WG on all new issues by placing rdf-comments as a receiver of new issue submissions. [scribe assist by Manu Sporny]
Manu Sporny: the issue is finding somebody that has the time to write the code to do that - we're all over-worked as it is, the github issue tracker is working for us just fine, and there is no requirement per W3C process that says that we have to use the W3C issue tracker before Last Call. I think we're good, I'll double-check with Guus to make sure. [scribe assist by Manu Sporny]
Manu Sporny: Thanks for the call everyone. Thanks especially to Lin for joining us on the call and helping us understand the Drupal use case in more depth. The next call is next week and will be 90 minutes long.