JSON-LD Telecon Minutes for 2013-01-29

Thanks to Gregg for scribing! The minutes from today's telecon are now
available.

http://json-ld.org/minutes/2013-01-29/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-01-29

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jan/0055.html
Topics:
   1. Remaining Editorial Work for JSON-LD 1.0 Specification
   2. Update to JSON-LD Data Model
   3. Context via HTTP Link Header
   4. IANA parameters
   5. Update on Algorithms
Resolutions:
   1. Remove "Example 51: Data annotations" and provide different
      examples showing how data annotations survive
      expansion/compaction.
   2. Rename @annotation to @index and update the prose in
      section 6.14 to reflect the change.
   3. Remove 'form' from the optional parameters for
      application/ld+json. Add four URL values for 'profile':
      http://www.w3.org/ns/json-ld#expanded
      http://www.w3.org/ns/json-ld#compacted
      http://www.w3.org/ns/json-ld#expanded-flattened
      http://www.w3.org/ns/json-ld#compacted-flattened
Action Items:
   1. Write e-mail to RDF WG asking why blank node identifiers
      can't be used for graph names and predicates.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Gregg Kellogg, Manu Sporny, Markus Lanthaler, Niklas Lindström,
   Lin Clark, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-01-29/audio.ogg

Gregg Kellogg is scribing.
Manu Sporny:  Any additions to the agenda?
Markus Lanthaler:  I raised another issue, but we'll discuss
   along with IANA parameters (ISSUE-214)

Topic: Remaining Editorial Work for JSON-LD 1.0 Specification

Manu Sporny:  I've gone through and done a complete pass over the
   JSON-LD 1.0 spec.
   … I tried to be very thorough about grammar flow, syntax, and
   so forth.
   … As always, we'll need a couple of more people to go over the
   spec and agree to the changes.
   … The major changes we've already discussed last week.
   … There are some other minor changes that could impact other
   things.
   … The biggest changes were moving from beginning to advanced
   sections, to aide flow for people form whom the concepts are new.
Markus Lanthaler:  I had some comments.
Manu Sporny:  In my inbox, haven't gotten to read it yet. We'll
   discuss them on this call.
Manu Sporny:
   http://json-ld.org/spec/latest/json-ld-syntax/#data-annotations
Manu Sporny:  data annotations first.
   … markus, you put in a use of data annotations that I hadn't
   thought about, and we should discuss.
   … For example 51, we have annotations used like a comment,
   which is not what I was thinking they were about, but they can
   certainly be used for that.
   … It was primarily intended as a container type, and not a
   comment. In this case, it looks like it would be lost across
   expansion.
Markus Lanthaler:  the reasoning was to describe it in a simpler
   way without relying on containers.
   … Basically, annotations are data which survive
   expansion/compaction, etc. It would, though, be lost when going
   to RDF.
   … This is the simplest way to describe the keyword.
   … The Annotation Maps (ex 52), is used to show more advanced
   usage.
Niklas Lindström:  I wonder if the choice of the name of the
   keyword is unfortunate. Was @key suggested?
   … I'm not sure if this is helpful, because the primary use
   case was ex 52, and other similar situations when there is a
   corresponding property on the object itself, such asdc:language,
   or the text value of the date or author.
   … It is primarily for artificial index keys which are
   necessary to allow the algorithms to work.
Manu Sporny:  it was @index I had proposed, as I had looked at
   this as a way to allow indexes to survive.
Niklas Lindström:  perhaps @key is even more appropriate; when
   you use @container, you can't hav several keys to confuse the
   mechanism.
   … For one object, you cannot have several keys, otherwise the
   @container annotation would be confused.
   … If a term were aliased to @annotation, and then use
   different terms, also aliased to @annotation, it would confuse
   the algorithms.
   … The keyword @key is more explicit.
Manu Sporny:  two questions, name of the keyword, and do we want
   to support bare string annotations.
Markus Lanthaler:  not a question of support, just documentation.
Manu Sporny:  leaning towards not documenting this usage
   … This was not my intent when agreeing to use this mechanism.
   People could use things other than strings, which is not in the
   grammar, but people might think it follows.
   … now we're describing another usage, as a basic string
   annotation, but not intended for use with the annotation maps.
   … This becomes limiting.
   … I'd rather not have this in there, and have them create a
   new term.
Gregg Kellogg:  I'm inclined to agree - this is promoting using
   JSON-LD markup features when it's more appropriate to use things
   like rdfs:comment. [scribe assist by Manu Sporny]
Gregg Kellogg:  By giving people a feature like this, we're
   giving people an excuse to not mark it up as Linked Data. Also,
   perhaps @annotation isn't a good name. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  I'd be fine with removing the example.
   … Because the keyword is called annotation, the most natural
   thing is to use it for annotations. It's still there, but not
   L.D.
Manu Sporny:  I'd say we could work on the intro, if needed.
Niklas Lindström: Lin, would you mind if the keyword @annotation
   (which is used for the extended language map feature) is renamed?
   Suggested name is @key.
Lin Clark: We haven't implemented that yet, so that's fine
Gregg Kellogg:  Maybe this indicates that the "@annotation" name
   is bad? [scribe assist by Manu Sporny]
Manu Sporny:  we want to show an equivalent of example 51, so
   people know how it round-trips.
   … The section needs a bit more work.

PROPOSAL: "Remove Example 51: Data annotations" and provide
   different examples showing how data annotations survive
   expansion/compaction.

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

RESOLUTION: "Remove Example 51: Data annotations" and provide
   different examples showing how data annotations survive
   expansion/compaction.

Manu Sporny:  other ideas: @index, @map.
Niklas Lindström:  it would look strange if looking at the
   expanded data.
Gregg Kellogg:  @index is pretty descriptive of what's going on
   here. [scribe assist by Manu Sporny]
Gregg Kellogg:  It seems to make sense in expanded form and in
   the context. [scribe assist by Manu Sporny]
Niklas Lindström:  I think of this as the key in the map.
   … I like @key in and of itself, but when looked at along other
   keywords, it looks odd.
Manu Sporny:  I feel strongly about changing it from annotations
   to something else. Maybe we can change to @index, and see how
   people feel about it.
Markus Lanthaler:  the problem I have with @index, that looking
   at an array, all elements are indexed, as in a cardinal location.
Markus Lanthaler: What about something like @marker
Gregg Kellogg:  I agree that data annotations are going in the
   wrong direction, it doesn't matter what we change it to as long
   as it's in a better direction. [scribe assist by Manu Sporny]
Gregg Kellogg:  "index into an object" works for most... I'd go
   w/ either @index or @key... @key is probably the most accurate,
   but @key next to @id and @type makes it not clear what it's used
   for. [scribe assist by Manu Sporny]
Manu Sporny:  Gregg just convinced me that @index is probably the
   best.
Niklas Lindström:  from the thesaurus, it looks like a reasonable
   choice.
Manu Sporny:  also, this is editorial, it doesn't really effect
   the semantics.
Markus Lanthaler:  why change, to prevent the use case or not
   promote it.
Manu Sporny:  to be clearer about what the feature does.
Niklas Lindström: http://thesaurus.com/browse/index: "Definition:
   indication … Synonyms: clue, mark, symbol, token...
Manu Sporny:  The keys in a database don't really have semantic
   meaning, and aren't typically exposed to the application layer.
   … This is effectively a database, and we are creating an
   index. The feature is easily comparable to a database index; not
   really an annotation mechanism.
   … My understanding was that developers needed to access the
   data quickly, which is the definition of what a database index is
   used for.
   … I think it's more accurate to say it's like a database index
   than an annotation.

PROPOSAL: Rename @annotation to @index and update the prose in
   section 6.14 to reflect the change.

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

RESOLUTION: Rename @annotation to @index and update the prose in
   section 6.14 to reflect the change.

Niklas Lindström: Lin, we're going for @index. :)
Lin Clark: Thanks for the heads up :)

Topic: Update to JSON-LD Data Model

Manu Sporny:  I was a bit concerned about these changes.
Markus Lanthaler:

https://github.com/json-ld/json-ld.org/commit/cc034077d5177f85fdccc69a5ac8062e66368e93
Manu Sporny:  I modified what a node was in the JSON-LD data
   model, and Markus and I disagreed.
   … This comes out of something Richard Cyganiak said...
   … "Every node represents a resource or a value. Resources are
   labeled by a bnode or an IRI". Before it said that every node
   _is_ and IRI, etc.
Markus Lanthaler:  Richard said they're not labeled, but they are
   IRIs.
Niklas Lindström: http://www.w3.org/TR/rdf11-concepts/#data-model
Niklas Lindström:  the data model is just the abstract syntax,
   and looking at RDF 1.1 Concepts...
   … (quoting from data-model).
   … What might have through it up was that arcs were IRIs too,
   but in fact arcs are labeled, not nodes.
Gregg Kellogg:  As I recall, there were some strong feelings
   about the node is an IRI. I agree with Niklas and Markus. [scribe
   assist by Manu Sporny]
   … We've sometimes conflated the JSON object with the node, and
   the resource the node represents.
Manu Sporny:  we should change it back then, but I'll check with
   cygri.
Niklas Lindström:  we need to check our usage of node, but I
   think we're okay.
   … Just verify we don't use "node" and "resource"
   indistinguishably.
Niklas Lindström: .. possible problems:
   http://json-ld.org/spec/latest/json-ld-syntax/#node-identifiers
   and
   http://json-ld.org/spec/latest/json-ld-syntax/#grammar-node-object
Markus Lanthaler:  it MUST be either an IRI or BNode.
Gregg Kellogg:  In RDF Concepts, it MUST be an IRI. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  but that's where we deviate from it. In SPARQL,
   it's an existential variable. [scribe assist by Manu Sporny]
Niklas Lindström:  There is a difference between an existential
   variable and a bnode. [scribe assist by Manu Sporny]
Gregg Kellogg:  Not really, a bnode is a non-distinguished
   variable. [scribe assist by Manu Sporny]
Gregg Kellogg:  For JSON-LD - we are implicitly allowing bnodes
   to be used as graph labels. [scribe assist by Manu Sporny]
Manu Sporny:  the concern I had was that each named graph is a
   pair, but since an IRI and BNode are nodes, it because something
   more like a "node class" mapped to a graph.
Gregg Kellogg:  From Concepts: "Each named graph is a pair
   consisting of an IRI (the graph name), and an RDF graph"
Niklas Lindström:  I talked with someone who thanked us for
   supporting BNode graph names.
Manu Sporny:  for the spec, change "BNode" to "BNode identifier"
Markus Lanthaler:  I'm worried about being inconsistent with the
   definition of node.
Manu Sporny:  but this is a string to graph mapping. It is a pair
   of name (string) to graph. A node is not a string, but a bnode
   identifier is.
Markus Lanthaler:  there's an issue of scopes then. The
   identifier is scoped to the document.
Niklas Lindström:  in RDF, you can't have graphs within graphs,
   and BNodes only exist within a graph.
Manu Sporny:  We're making use of BNOde identified graph, and
   need this in JSON-LD.
   … It's based on timestampping elements and using them to
   identify graphs, rather than pretending we're creating an IRI of
   the graph.
Niklas Lindström: .. urn:uuid:....
Manu Sporny:  we could use a hash identifier, but we tend to shy
   away from using new URNs when we can use a BNode.
Manu Sporny:  we don't like UUIDs, because they look like
   garbage.
Niklas Lindström:  I find BNodes useful, but BNode ids not so
   much.
   … I only use BNodes for compound values, and occasionally,
   when I _really_ don't know the ID.
Manu Sporny:  if we add them in here, we push the conversation
   forward.
Markus Lanthaler:  we did discuss the differences already.
Niklas Lindström:  if there's a good theoretical issue, it would
   be good to have in an explicit document.
Manu Sporny:  so ask what the theoretical reason to not use BNode
   identifiers for graph names.

ACTION: Write e-mail to RDF WG asking why blank node identifiers can't
be used for graph names and predicates.

Manu Sporny:  the last change is terminology about saying a node
   is either a resource or a value.
Markus Lanthaler:  I think we should remove "resource", as it
   confuses things.

Topic: Context via HTTP Link Header

Manu Sporny:  Let's quickly bike-shed the name of this section.
Markus Lanthaler: Transforming JSON to JSON-LD
Markus Lanthaler: Referencing contexts from JSON documents
Markus Lanthaler:  I think many people have JSON and would like
   to transform to JSON-LD if it doesn't require large changes.
Manu Sporny:  I really like Transforming JSON to JSON-LD [scribe
   assist by Manu Sporny]
Niklas Lindström:  is "transforming" the right idea?
The group decides that "Interpreting JSON as JSON-LD" strikes the
   right balance.

Topic: IANA parameters

Manu Sporny:
   http://json-ld.org/spec/latest/json-ld-syntax/#iana-considerations
Manu Sporny:  The major issues were the optional parameters. We
   had "form" and "profile"
   … We used to have compact, but it was non-deterministic. Now
   it is deterministic.
   … I think "form" needs to have values of "expanded" and
   "compacted".
Markus Lanthaler:  we didn't have it, as it didn't really mean
   anything.
   … This is related to the issue I raised. Do we really need to
   parameter, or can we embed within the document.
Niklas Lindström:  or for content negotiation.
Markus Lanthaler:  you can do the same with profile, buy just
   minting a new IRI.
Niklas Lindström:  should we then mint some IRIs for the forms
   we've mentioned?
Gregg Kellogg:  The purpose for 'form' is so that people can know
   the format of the document w/o processing it. [scribe assist by
   Manu Sporny]
Markus Lanthaler: We minted http://www.w3.org/ns/json-ld#context
   to reference a context
Niklas Lindström: .. e.g.
   profile=http://json-ld.org/profile/expanded+flattened ...
Manu Sporny:  proposal to get rid of form and encode within
   profile.
   … But, I think the prose around profile is confusing. I
   thought it was in case we had a schema which restricted the data.
Markus Lanthaler:  the profile uses an identifier to describe
   some constraints or conventions used within the document, and
   mark the document with those conventions.
Manu Sporny:  what about a link to a JSON schema?
Markus Lanthaler:  the consumer must understand what the IRI
   means, so if the consumer knows about schemas, it could use it.
Niklas Lindström:  I'm mostly thinking about content negotiation
   scenarios.
Manu Sporny:  So get rid of form? Then we'd need the following
   two IRIs: http://www.w3.org/ns/json-ld#expanded
   http://www.w3.org/ns/json-ld#expanded-flattened ? [scribe assist
   by Manu Sporny]
Markus Lanthaler:  you could specify in profile that you wanted a
   specific vocabulary.
Niklas Lindström:  shouldn't the IRI be opaque?
   … You need to link to it or have it in another link header.
   … I wonder if it's good to define form to use the tokens
   "expand, compact", with or without "flattened".
   … Gives four variations.
Manu Sporny: okay, proposals then -
   http://www.w3.org/ns/json-ld#expanded
   http://www.w3.org/ns/json-ld#compacted
   http://www.w3.org/ns/json-ld#expanded-flattened
   http://www.w3.org/ns/json-ld#expanded-compacted
Manu Sporny:  those four, with either using "-" or "+" as
   separators.
Niklas Lindström:  they might not need to be IRIs.
Manu Sporny:  using IRIs allows other people to add their own
   profiles. Otherwise, we'd need a registry.
   … The profile mechanism allows anyone to define their own.
   … If they want to add a JSON schema, they can mint a new IRI
   for every one they expose.

PROPOSAL: Remove 'form' from the optional parameters for
   application/ld+json. Add four URL values for 'profile':
   http://www.w3.org/ns/json-ld#expanded
   http://www.w3.org/ns/json-ld#compacted
   http://www.w3.org/ns/json-ld#expanded-flattened
   http://www.w3.org/ns/json-ld#compacted-flattened

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +0 (probably +1 but I haven't really considered
   the uses so)
David I. Lehn: +0

RESOLUTION: Remove 'form' from the optional parameters for
   application/ld+json. Add four URL values for 'profile':
   http://www.w3.org/ns/json-ld#expanded
   http://www.w3.org/ns/json-ld#compacted
   http://www.w3.org/ns/json-ld#expanded-flattened
   http://www.w3.org/ns/json-ld#compacted-flattened

Topic: Update on Algorithms

Manu Sporny:  Dave Longley been working on his implementation,
   which is now complete. He is currently combining the text that
   Markus and Gregg wrote and expanding on the problem and general
   solution statements for each algorithm. Some of the algorithms
   are being re-written, but in a way that flows better and in a way
   that matches his implementation. So, once he's done, we should
   have a good middle-ground between what Markus and Gregg had,
   better prose outlining the algorithms, and some simpler
   algorithms. [scribe assist by Manu Sporny]
Niklas Lindström: .. "When @graph is used in a document's
   top-level object which has no other properties that are mapped to
   an IRI or a keyword it is considered to express the otherwise
   implicit default graph."
Niklas Lindström:  my friend had a problem with this wording.
   … If I understand him, he wasn't sure it was enough to add
   @id; he wanted to make sure he had a named graph.
Manu Sporny:  The text is wrong, but let's try to fix it now.
   I'll make a change right after the call.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 29 January 2013 21:10:18 UTC