JSON-LD Telecon Minutes for 2012-07-24

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

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

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

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

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0040.html
Topics:
   1. ISSUE-120: Expand @type to @id-objects
   2. ISSUE-114: JSON-LD Grammar
   3. ISSUE-142: Allow terms to expand to multiple IRIs
   4. ISSUE-144: @context in coercion rules
   5. ISSUE-146: Support array position to property binding
Resolutions:
   1. When @id is found as a value in an object associated with
      @type, a handler callback is called to handle the issue.
   2. Express the JSON-LD Grammar in prose with supporting
      tables/examples. Clarify that violating the grammar does not
      necessarily mean that a JSON-LD processor will not process the
      document.
   3. Support a single term expanding to multiple IRIs when an
      array of @ids are associated with a single term in the @context.
   4. Do not support embedding @contexts within a @context to
      re-define the IRI that a term maps to.
Action Items:
   1. Gregg and Manu to improve the JSON-LD Grammar section in
      the JSON-LD Syntax specification.
Chair:
   Manu Sporny
Scribe:
   Niklas Lindström
Present:
   Manu Sporny, Markus Lanthaler, Niklas Lindström, Gregg Kellogg,
   Stéphane Corlosquet
Audio:
   http://json-ld.org/minutes/2012-07-24/audio.ogg

Niklas Lindström: Regarding the graphify() mechanism, I've been
   playing around a little with a connect() mechanism here - you
   guys might be interested in that:
Niklas Lindström:
   https://github.com/niklasl/rdfa-lab/blob/gh-pages/test/test_ld.js
Niklas Lindström:
   https://github.com/niklasl/rdfa-lab/blob/gh-pages/test/test_rdf.js
Manu Sporny:  Any discussion items to add to the Agenda? [scribe
   assist by Manu Sporny]
Markus Lanthaler:  Yeah, ISSUE-120 - we need to determine what
   happens when an @id is detected in an object associated with
   @type. [scribe assist by Manu Sporny]
Niklas Lindström is scribing.

Topic: ISSUE-120: Expand @type to @id-objects

Manu Sporny:  we decided we're not expanding @type to @id
   objects. The question is if we allow usage of @id objects for
   @type, or if we should throw exceptions
Gregg Kellogg:  were using callbacks more for error; so if we see
   this usage, we can allow the app to decide what to do.
Gregg Kellogg:  I feel it is important to support that pattern,
   in the case some JSON used the type construct like this, and we
   want to cast it to @type
Manu Sporny:  we should call the callback
Gregg Kellogg:  we need to figure out the callback workings; is
   it an event bubbling kind of mechanism?
Gregg Kellogg:  should they propagate etc.
Manu Sporny:  yes, we should discuss this more
Gregg Kellogg:  also, in a non-programmatic context (distiller
   etc.), we should do the most liberal thing: i.e. use the @id
Manu Sporny:  so we should call the callback (which is it? not
   error handler...)
Gregg Kellogg:  the callback should be able to cancel the use...
Manu Sporny:  there might be three choices: use, ignore or stop
Gregg Kellogg:  use a binary for use/ignore and throw exception
   to stop

PROPOSAL:  When @id is found as a value in an object associated
   with @type, a handler callback is called to handle the issue.

Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1

RESOLUTION: When @id is found as a value in an object associated
   with @type, a handler callback is called to handle the issue.

Markus Lanthaler:  for all cases where there is non-conformant
   data?
Manu Sporny: To clarify - the handler callback is called whenever
   any "non-conforming" data is found.

Topic: ISSUE-114: JSON-LD Grammar

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/114
Manu Sporny:  with this mechanism, a document isn't automatically
   invalid when a document doesn't conform to the grammar. This
   allows for figuring out what the data should mean.
Gregg Kellogg:  if we define what can be handled automatically,
   the document would be conformant still
Markus Lanthaler:  but when is a document clearly non-conformant?
Manu Sporny:  we don't want to make the statement that a JSON-LD
   doc with non-defined terms is non-conformant
Markus Lanthaler:  but that is explicitly ignored
Manu Sporny:  true. we have to be careful about how we define
   this
Gregg Kellogg:  the reason for having a grammar was that before
   we had spread out in various places what forms are allowed where
Niklas Lindström:  I wonder to what extent we need to keep using
   the abstract description? There are only a few cases where we
   need to handle non-canonical expressions. [scribe assist by Manu
   Sporny]
Niklas Lindström:  The specific case is where you are coercing to
   an @id, but you have an object that is a JavaScript object with
   an 'id' keyword. [scribe assist by Manu Sporny]
Niklas Lindström:  There is also value coercion - we need to call
   out for that. Maybe we can just define these specific cases? If
   you coerce to @id and you have an entire object there, the object
   will be thrown away, but the @id will be kept. [scribe assist by
   Manu Sporny]
Niklas Lindström:  If you have coerced to a literal, you have @id
   or @language - you will throw an error. If you use an expanded
   literal for @type, you will throw an error. [scribe assist by
   Manu Sporny]
Manu Sporny:  do we need to express in prose or EBNF?
Gregg Kellogg:  I started on EBNF, but that's difficult, and
   probably not appropriate
Markus Lanthaler:

http://json-ld.org/spec/latest/json-ld-syntax/#json-ld-authoring-guidelines
Niklas Lindström:  EBNF is not applicable [scribe assist by Manu
   Sporny]
Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/114#issuecomment-5820544
Gregg Kellogg:  that's a compact, good start. it needs some more
   work, but it's good and usable
Gregg Kellogg:  just prose, highlighted with examples would be
   good
Manu Sporny:  but don't we have lots of that? we need some kind
   of summary (which Andy looked for)
Gregg Kellogg:  we could repeat what we say above [in the spec],
   but top-down instead of bottom-up
Gregg Kellogg:  I'll add a issue feature to respec.js
Manu Sporny:  so we'll attempt to express the json-ld grammar
   (gregg will start on it)
Markus Lanthaler:  in prose, right?
Manu Sporny:  yes, but possibly with formal tables etc.
Gregg Kellogg:  a processor must note when a document is
   non-conformant, but may still produce data

PROPOSAL:  Express the JSON-LD Grammar in prose with supporting
   tables/examples. Clarify that violating the grammar does not
   necessarily mean that a JSON-LD processor will not process the
   document.

Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1

RESOLUTION: Express the JSON-LD Grammar in prose with supporting
   tables/examples. Clarify that violating the grammar does not
   necessarily mean that a JSON-LD processor will not process the
   document.

Niklas Lindström:  We need to outline all the things that are
   problematic - for example, using @graph in @context. [scribe
   assist by Manu Sporny]
Manu Sporny:  we may have to leave certain deviations undefined

ACTION: Gregg and Manu to improve the JSON-LD Grammar section in the
JSON-LD Syntax specification.

Topic: ISSUE-142: Allow terms to expand to multiple IRIs

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/142
Manu Sporny:  brought up for the drupal use case
Manu Sporny:  the biggest question is do we want to support this?
Niklas Lindström:  I thought about this before this was brought
   up - it's similar to RDFa... I think in our situation, it does
   complicate things. [scribe assist by Manu Sporny]
Niklas Lindström:  It's one thing to use this when you are
   interpreting compact JSON... so that when you're expanding it,
   you have more than one triple for each key. [scribe assist by
   Manu Sporny]
Niklas Lindström:  Compacting data is much harder - if you use a
   context with these kinds of terms, we have to say something more
   specific - it's a sort of inference... data will magically appear
   that doesn't exist in the input. [scribe assist by Manu Sporny]
Niklas Lindström:  Something that would be much more complex, but
   proper - a term should only match when all items are in the
   document. [scribe assist by Manu Sporny]
Gregg Kellogg:  for expressing data, this is quite useful. But my
   opinion is also that we've painted ourselves into a corner when
   it comes to compacting data with contexts using these
Gregg Kellogg:  I can see for expressing data, this is very
   useful. My opinion though, is that we've painted ourselves into a
   corner when we do compaction. There are other examples where we
   output things that are non-intuitive because we are strictly
   adhering to the @context expression. If you have something that's
   not a date that is a term. [scribe assist by Manu Sporny]
Gregg Kellogg:  we may have to separate these concepts from the
   task of compaction
Gregg Kellogg:  so that we can use these forms to *express* data
   but not apply them when compacting
Stéphane Corlosquet: can a feature be supported for one way
   (expansion) and not the other way (compaction)?
Markus Lanthaler:  is that feature really required? in restful
   apis, you can use e.g. content negotiation for different uses
Manu Sporny: scor, that's what we're discussing right now - we
   /could/ do it... but it would be the first time we're doing
   something like that.
Stéphane Corlosquet:  other formats, like RDFa and microdata,
   support this feature.
Stéphane Corlosquet:  and we use this in Drupal, so we'd have to
   do something special for JSON-LD if we don't have this
Stéphane Corlosquet:  it's gonna be more verbose
Gregg Kellogg:  a possible consequence of this would be to allow
   key-object keys to have a space-separated list of terms
Gregg Kellogg: {"schema:name dc:title": "foo"}
Manu Sporny:  I'm concerned that it's too foreign for JSON
   developers. It's a neat trick, but it would be hard to use that
   data
Niklas Lindström:  I probably agree
Gregg Kellogg: {"@context": { "term": {"@id": ["dc:title",
   "schema:name", "foaf:name"]}}}
Markus Lanthaler:  the other question is: who are the clients of
   these documents?
Stéphane Corlosquet:  there is a proposal in the drupal
   community, and to define a local namespace for properties, which
   would be used for sharing data. At the same time, we want to
   support schema.org, DC, etc.
Markus Lanthaler: What about data.jsonld?vocab=foaf vs.
   data.jsonld?vocab=schema
Stéphane Corlosquet:  conneg for this is not a mature pattern
   which is commonly used by clients
Manu Sporny: Markus, I think the issue is that they don't have to
   do that anywhere else in their system.
Stéphane Corlosquet:  different consumers understand different
   parts, and we want to target as many as possible with the same
   data.
Markus Lanthaler:  I see your point
Manu Sporny:  the pattern among linked data publishers right now;
   JSON-LD is used by e.g. VIE in the backend, and the JSON-LD is
   transformed to RDFa, and then lifted out again.
Manu Sporny:  they wanted to use multiple vocabularies, so this
   would be usable. If we can figure out the issue with
   compaction...
Gregg Kellogg:  another approach would be to use vocabulary
   expansion..
Niklas Lindström:  I think that it would be easier to use this
   feature than something like an "RDFa Profile"... this is a more
   raw equivalent of that. [scribe assist by Manu Sporny]
Niklas Lindström:  The more RDF-y the Web gets, the easier all of
   this gets... we would ultimately use our own vocabs w/ mappings.
   [scribe assist by Manu Sporny]
Niklas Lindström:  But that's 5-10 years off. [scribe assist by
   Manu Sporny]
Gregg Kellogg:  we could support this, but not apply it on
   compaction
Manu Sporny:  we should determine if we need this, and then if it
   should or shouldn't apply in compaction
Stéphane Corlosquet: "@context": {
Stéphane Corlosquet: "name": "http://xmlns.com/foaf/0.1/name
   http://schema.org/name",
Gregg Kellogg: {"@context": { "term": {"@id": ["dc:title",
   "schema:name", "foaf:name"]}}}
Gregg Kellogg: {"@context": {"term": ["dc:title",
   "schema:name"]}}

PROPOSAL:  Support a single term expanding to multiple IRIs when
   an array of @ids are associated with a single term in the
   @context.

Manu Sporny: +1
Gregg Kellogg: +1
Stéphane Corlosquet: +1
Markus Lanthaler: +0.5
Niklas Lindström: +1 (provided we can solve how to handle it in
   compaction)

RESOLUTION: Support a single term expanding to multiple IRIs when
   an array of @ids are associated with a single term in the
   @context.

Manu Sporny: What is this compacted to? { "dc:title": "title1",
   "schema:name": "title2" }
Niklas Lindström:  re: compaction w/ single-to-multiple terms -
   three ways to solve this - if any @id matches use that term,
   match only if all items match, only use first term in the list.
   [scribe assist by Manu Sporny]
Markus Lanthaler: What is this compacted to? { "dc:title":
   "sametitle", "schema:name": "sametitle" }
Manu Sporny: mlnt, don't you mean this - { "dc:title":
   "sametitle", "schema:title": "sametitle" } ?
Manu Sporny:  that's the second case, I was also wondering what
   happens if you have two different values [scribe assist by Markus
   Lanthaler]

Topic: ISSUE-144: @context in coercion rules

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/144
Manu Sporny:  I have a severe reaction to this… [ ;) ]
Manu Sporny:  this suggests that a term can mean different things
   depending on where in the data it appears, depending on terms
   referencing the current piece
Manu Sporny:  we already support this by explicitly using
   "@context" at various places
Niklas Lindström:  I have explored this idea before... it's way
   too complex. There is a nice academic idea that you could adapt
   to almost any data... but it gets very complex to process and
   much harder to read the data. [scribe assist by Manu Sporny]
Niklas Lindström:  If you mix-match terms in the same document,
   such that you can't use the same term for the same meaning,
   you're in trouble... it's a bad practice. [scribe assist by Manu
   Sporny]
Niklas Lindström:  We already support this via @context
   embedding... [scribe assist by Manu Sporny]
Gregg Kellogg: I'm with niklas
Niklas Lindström:  You could take the approach where you bind a
   @context to a type... but I still think it's too much... I'm not
   in support of it at this point. [scribe assist by Manu Sporny]

PROPOSAL:  Do not support embedding @contexts within a @context
   to re-define the IRI that a term maps to.

Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1
Stéphane Corlosquet: +0
Gregg Kellogg: +1

RESOLUTION: Do not support embedding @contexts within a @context
   to re-define the IRI that a term maps to.

Topic: ISSUE-146: Support array position to property binding

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/146
Manu Sporny:  this came about during a discussion with reto.
Manu Sporny: "position": ["18.324235", "-36.4387934"],
Manu Sporny:  Often people have data which expresses data in
   tuples.
Manu Sporny:  A whole bunch of geo-data matches this pattern.
   Even if explicit terms are "better", people are not going do use
   that.
Manu Sporny:  other cases are e.g. vectors, circles, or general
   data pairs
Manu Sporny: "position": {"@id": "geo:position", "@container":
   [{"@id": "geo:latitude"}, {"@id": "geo:longitude"}]}
Manu Sporny: or this: "coordinates": {"@container": "@list",
   "@tuple": [{"@id": "geo:latitude"}, {"@id": "geo:longitude"}]}
Niklas Lindström:  I am in favor of supporting it - I thought of
   it when I saw GeoJSON. I came across it when I worked with
   biographical data at the Royal Library... we're slowly moving
   towards RDF and I'm using JSON-LD as the target there. There are
   many complications on that road, may not be able to achieve
   this... there are certain shapes of data that use this form. I'd
   like to transform those... [scribe assist by Manu Sporny]
Manu Sporny: ...expressions because they're cumbersome.
Niklas Lindström:  However, for GeoJSON, that is a very good use
   case. [scribe assist by Manu Sporny]
Niklas Lindström:  Statistics and measurements as well. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  I see the value of it
Gregg Kellogg:  again, compaction complexity might be a problem.
   But I support it for expressing data
Markus Lanthaler:  I agree with the arguments and see the value
   in it.
Markus Lanthaler:  but I'm concerned about all the various ways
   of expressing data, and the impact of that on understanding data
Manu Sporny:  yes, I agree with marcus
Manu Sporny:  the issue is what happens when you have JSON data
   and need to transfer it to JSON-LD
Manu Sporny:  it would be nice to figure out a way to add
   experimental features but not including it in 1.0 proper
Gregg Kellogg:  I think the complexity really lies in compaction.
   You can use a context to understand a specific form. But the
   general compaction algorithm would suffer if it had to support
   all kinds of "gleaning"
Gregg Kellogg:  we may want to move away from symmetric
   application of context
Manu Sporny:  but that could confuse users
Gregg Kellogg:  but will people use framing, or proprietary
   algorithms?
Manu Sporny:  we often use that approach too
Manu Sporny:  will compaction mostly be the "pretty print" for
   JSON-LD?
.. discussion about framing vs. graphify
Gregg Kellogg:  graphify addresses the shape issue. It ensures
   that you can navigate with dot notation consistently.
Gregg Kellogg:  framing does the query thing, matches and
   extracts data
Niklas Lindström:  I don't know if we've discussed enough for a
   vote? [scribe assist by Manu Sporny]
Gregg Kellogg:  compaction is useful though; for e.g. graphify
Manu Sporny:  even if we break the symmetry between expansion and
   compaction, I'm concerned about the complexity
Gregg Kellogg:  an anecdote: Dave Beckett said about Turtle that
   a feature was only added when there was lots of complaints about
   it missing
Gregg Kellogg:  we may want to look at macros instead...
Niklas Lindström:  Yeah, I'm on the edge for this feature - I
   like many of the suggestions, but I'm also concerned about the
   complexity - we may want a pre-processing language? It would be
   nice to have something declarative in JSON. [scribe assist by
   Manu Sporny]
Niklas Lindström:  We could use IRI templates, etc... so, we
   might want to have a "third" thing, not a part of the 1.0 JSON-LD
   spec - that's some sort of GRDDL for JSON-LD w/ a definined macro
   language for the next version of expansion. [scribe assist by
   Manu Sporny]
Manu Sporny:  we may add a preprocessing step to the JSON-LD API.
Manu Sporny: Discussion about pre-processing step vs. declarative
   form for modifying a document.
Manu Sporny: Okay, out of time for today - thanks for the call -
   we'll have another call next week.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/

Received on Tuesday, 24 July 2012 18:00:27 UTC