JSON-LD Telecon Minutes for 2012-07-31

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

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

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

--------------------
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:
   http://json-ld.org/minutes/2012-07-31/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.

-- 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, 31 July 2012 18:28:10 UTC