JSON-LD Telecon Minutes for 2012-06-12

bcc: RDF WG

The minutes from today's call are now available here:

http://json-ld.org/minutes/2012-06-12/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2012-06-12

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0021.html
Topics:
   1. Use of @container to specify language-maps and other useful
      things
   2. Review latest JSON-LD Syntax and API specs
   3. ISSUE-120: Expand @type to @id-objects
Resolutions:
   1. Attempt to add other @container options, such as
      "@container": "@language" to support Wikidata's language-map use
      case.
   2. When operating on @type, the result of the expansion
      algorithm MUST always result in an array of strings that are
      IRIs.
   3. In the expansion algorithm, when expanding a value
      associated with @type that is a JSON object, extract only @id
      from that value. Any value that does not expand to an absolute
      IRI MUST be discarded.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Manu Sporny, Gregg Kellogg, Niklas Lindström, François Daoust,
   David I. Lehn
Audio:
   http://json-ld.org/minutes/2012-06-12/audio.ogg

Manu Sporny: Discussion about Stardog, JSON-LD and the upcoming
   NoSQL conference.
Gregg Kellogg is scribing.
Niklas Lindström:  discussion of @container with @language?

Topic: Use of @container to specify language-maps and other useful things

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/133
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/134
Niklas Lindström:  previously, I had brought up something for if
   the language was a key.
   … we've seen some other cases where we'd like like
Gregg Kellogg:  Yeah, Wikidata is quite interested in using a
   JSON expression for their APIs - Wikidata exists to communicate
   with other Wikis... they're quite interested in JSON-LD [scribe
   assist by Manu Sporny]
Gregg Kellogg:  It would allow them to avoid having a different
   JSON serialization - they presented some use cases - they'd like
   to, for some wiki topic, have a way of expressing that topic in
   JSON-LD. The problem is that they need to be able to express this
   in many different languages/keys - it's the array-as-object
   pattern. [scribe assist by Manu Sporny]
Gregg Kellogg:  So each key is a subject, not a property...
   ISSUE-133 would be contain underneath whatever key references it.
   Wikidata says that they would place the english version or the
   german version of a video in this layout. [scribe assist by Manu
   Sporny]
Niklas Lindström:  if 133 was chosen, if you have objects, it
   could be specified in a way so that the expression used, if the
   object is not a value, the language is set below.
   … but, not sure @language works that way.
Gregg Kellogg:  My original concern was to add a @context that
   defines a particular language... from Denny's perspective, he
   would be perfectly happy if he had to explicitly set a context
   that defines a language - not really a short-cut to avoid extra
   description... it's an index pattern which is important. He wants
   to be able to access this stuff using JavaScript object notation.
   [scribe assist by Manu Sporny]
Niklas Lindström:  we might want to study this pattern for things
   other than @language (such as @id).
   … I have some suspicion that JSON keys are used not as
   properties, but as "index" keys for values.
   … consider RDF/JSON, which has as it's outer container
   something which works like an indexing feature.
   … this pattern is fairly conventional in JSON. I wonder how
   far towards a transformation language we want to go.
   … We can't just do the simplest thing possible, because we
   need to be able to allow for such usage patterns.
   … if we can make it understandable, can we work with
   @container to adopt more conventional forms of JSON.
Manu Sporny:  I have a couple of concerns:
   … 1) is denny modeling his data that makes sense for JSON-LD?
   … we've already said there are patterns we're not going to
   support.
   … I'm concerned about the overhead it adds, not to processing,
   but to the intellectual overhead.
   … Same issue that WHATWG had with RDFa - that there are too
   many ways to say the same thing.
Gregg Kellogg:  Yes, the main reason Denny wants this is that he
   wants to be able to access these values in JavaScript
   dot-notation... [scribe assist by Manu Sporny]
Gregg Kellogg:  regarding intellectual complexity - my philosophy
   on language design is a bit different - simple things should be
   simple, complex things should be possible (not impossible)
   [scribe assist by Manu Sporny]
Gregg Kellogg:  I think we need to consider this as a fairly
   standard usage pattern... I'm not convinced we need to support it
   via compaction/framing, but as a way of being able to express
   JSON where you can derive RDF, it's interesting. [scribe assist
   by Manu Sporny]
Niklas Lindström:  I appreciate manu's concerns about discussing
   the usage pattern in-depth, but I think that what gkellogg said
   may be true, that it is a common usage pattern.
   … It may be more predictable to do this by extending
   @container. Probing makes it more difficult to read the JSON and
   glean the data.
   … Embedding RDF forms in "noisy" JSON may open a can of words.
   … I we us @container for @language (and maybe @id) it will
   make it easier to read.
   … It's true that you can no longer rely on a key being a
   property.
   … But the idea, is to stick to existing usage patterns. Given
   that indexing is a common usage pattern, and is the most
   expressive and useful, JSON-LD may be marginalized if it can't
   support this pattern.
   … I've seen many templating patterns where being able to use
   keys in this manner would simplify things.
   … If we define it as a mechanism of container, anyone knowing
   how JSON-LD @context works, will figure this out quickly.
Manu Sporny:  I hear general agreement that we're going to try to
   make it work.
   … As markus said, there are still some issues about how this
   will work.
Niklas Lindström:  I experimented with language mapping before,
   and it worked okay for compaction.
   … oddly shaped data will highlight the edge-cases.
   … using keys of different types in a language can lead to a
   conflict, but we can provide a mechanism to resolve this, such as
   to skip the @container: @language definition.
Manu Sporny:  we should probably table for now until we have an
   implementation.
   … once we work out the edge-cases, we should come back to it.
   … One concern is that does really affect the syntax, so we
   can't put it off for too long.

PROPOSAL:  Attempt to add other @container options, such as
   "@container"; "@language" to support Wikidata's language-map use
   case.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
François Daoust: +1
David I. Lehn: +1

RESOLUTION: Attempt to add other @container options, such as
   "@container": "@language" to support Wikidata's language-map use
   case.

Topic: Review latest JSON-LD Syntax and API specs

Manu Sporny: http://json-ld.org/spec/latest/json-ld-syntax/
Manu Sporny: http://json-ld.org/spec/latest/json-ld-api/
Manu Sporny:  I sent an email out to the RDF WG indicating that
   we had applied all change requests to the documents, marking it
   up as an FPWD.
Manu Sporny:
   http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jun/0028.html
   … I linked to each commit to make sure that every piece of
   feedback was responded to.
   … the big changes were that the JSON-LD API now has an
   introductory section that is specific to it.
   … We added issue markers to indicate that it's been in
   development for 18 months, and scope, and alignment with RDF
   Concepts.
   … Hopefully, they'll look at it tomorrow, they'll publish as
   an FPWD.
   … Hope for FPWD in the month of July.

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

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/120
Manu Sporny:  this has do do with the expanded form of @type.
   Should it be expanded to {"@id"} form? or should we keep it as
   is, where it can only be a string or an array of strings.
François Daoust: [I note a missing "API" in the title of the spec
   in the normative reference to JSON-LD API:
   http://json-ld.org/spec/latest/json-ld-syntax/#bib-JSON-LD-API ]
Gregg Kellogg:  There are two things that drive this - one of
   them is the IRI space for @type being different than other keys
   like @id - perhaps it should be kept distinct by not using the
   @id pattern. If we use the @id pattern, you would be in a
   different context when you applied that. If you needed vocab
   expansion, or an absolute IRI vs. relative IRI would need to be
   thought about more deeply. [scribe assist by Manu Sporny]
Gregg Kellogg:  That said, in expansion we should tolerate seeing
   values of this type which are expressed in the @id form... the
   canonical form would be to just be an array of strings. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  So, I'm in support of supporting this feature.
   [scribe assist by Manu Sporny]
Niklas Lindström:  I'm pretty sure that I'm in agreement on Gregg
   on all of this - I have the same perspective. [scribe assist by
   Manu Sporny]
Niklas Lindström:  I'm pretty sure that I agree with Gregg on
   this stuff. I have the same perspective on the items that are
   brought up.
   … with possible exception to the notion of expansion. If this
   is the case, we should also change @type to be like rdf:type.
   … @type is a syntactical expression, and if we expand it, we
   should expand to rdf:type.
Gregg Kellogg:  I'm worried that we push a bit too much RDF onto
   the JSON folks if we do that... I'm not too keen on expanding
   "@type" to "rdf:type" on expansion. [scribe assist by Manu
   Sporny]
Niklas Lindström:  I'm not sure which side I'll end up on.
Manu Sporny:  I'm a bit concerned about expanding to rdf:type
   too. It might be more pure from an RDF standpoint, but we don't
   want to push this on people that aren't interested in RDF.
   … This is a type of confusion we'd like to stay away from.
   … Two different things, what happens on RHS and on LHS.
Niklas Lindström:  on the LHS, we use @type, the value on the RHS
   should never be an object.
   … If you want to do this in the context, you'd need to be sure
   when expanding that this wasn't the case.
   … I feel that we shouldn't expand @type.
Manu Sporny:  I thought we were talking about if the RHS of @type
   to have an object when expanding.
Manu Sporny: In expansion, should we do this: "@type":
   "http://xmlns.com/foaf/0.1/Person" or this: "@type": { "@id":
   "http://xmlns.com/foaf/0.1/Person" }
Gregg Kellogg:  yes, that's what this issue is about - if we have
   foaf:Person - does it expand into the IRI form or the object
   form? [scribe assist by Manu Sporny]
"type": {"@id": "foaf:Person"}
Gregg Kellogg:  There are at least three cases here - what
   happens when "@type" is aliased to "type", what happens if
   somebody does "rdf:type" on the LHS, what happens to { "@id": ...
   } in expanded form [scribe assist by Manu Sporny]
Manu Sporny:  to be consistent, we should always express as a
   string, or expand out into a subject reference.
   … it seems to me that for @type we should expand out to the
   @id form.
   … we do that for everything else.
Niklas Lindström:  then you'd do it for literals too?
Manu Sporny:  if we expanded an object with a label, we'd through
   the label away.
   … we don't do it for @id or @type. If you want to express more
   information, define it elsewhere.
   … @type is no different from @id and the datatype usage. If
   you want to say more, say more somewhere else.
Niklas Lindström: .. [ {"@id": "a", "@type": {"@id":
   "http://example.com/type", "label": "Type name"} } ]
Niklas Lindström:  my problem is that @type is a specific
   syntactic form. That's why I brought up that a consistent form is
   to expand @type tordf:type
Niklas Lindström: [ {"@id": "a" "@type":
   ["http://example.com/type"]}, {"@id": "http://example.com/type",
   "label": "Type name"} ]
Gregg Kellogg:  This is an interesting artifact - in TURTLE you
   can't do chaining for objects that are also subjects. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  Niklas' second form is the only way you can
   express it in TURTLE... [scribe assist by Manu Sporny]
Manu Sporny:  consensus that when we have @type with objects, we
   just take the IRIs and through way the other data when expanding.
Niklas Lindström: .. [ {"@id": "a", "type": {"@id":
   "http://example.com/type", "label": "Type name"} } ]
Niklas Lindström:  want to be sure that in compaction, I can get
   back to that example.
Niklas Lindström: .. "type": "rdf:type"

PROPOSAL:  In expanded form, the value of @type MUST be a string
   or an array of strings that are IRIs. If expanded form is used to
   express one or more object references @type (e.g. "@type"

PROPOSAL:  In expanded form, the value of @type MUST always be an
   array of strings that are IRIs.

PROPOSAL:  When operating on @type, the result of the expansion
   algorithm MUST always result in an array of strings that are
   IRIs.

Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: abstains (proposal sounds good, I just don't
   feel I get the ins and outs correctly on that issue)
David I. Lehn: +0
Niklas Lindström: +1

RESOLUTION: When operating on @type, the result of the expansion
   algorithm MUST always result in an array of strings that are
   IRIs.

Manu Sporny:  A clarification on the resolution above. [scribe
   assist by Manu Sporny]

PROPOSAL:  In the expansion algorithm, when expanding the value
   associated with @type, if a JSON object is detected, only the
   value of @id MUST be used.

PROPOSAL:  when expanding the object value of a key interpreted
   as @type, extract only @id from that value. Discard any value
   that does not expand to an absolute IRI.

PROPOSAL:  In the expansion algorithm, when expanding a value
   associated with @type that is a JSON object, extract only @id
   from that value. Any value that does not expand to an absolute
   IRI MUST be discarded.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
François Daoust: abstains (same comment)
David I. Lehn: +0

RESOLUTION: In the expansion algorithm, when expanding a value
   associated with @type that is a JSON object, extract only @id
   from that value. Any value that does not expand to an absolute
   IRI MUST be discarded.

-- 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, 12 June 2012 15:26:18 UTC