JSON-LD Telecon Minutes for 2012-11-13

Thanks to Niklas for scribing last week! The minutes from last week's
call are have been available here for the past week (but I failed to
send out this announcement until just now):

http://json-ld.org/minutes/2012-11-13/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2012-11-13

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Nov/0010.html
Topics:
   1. ISSUE-196: Add '@annotation' container type
   2. ISSUE-195: Add '@graph' container type
   3. ISSUE-165: Allow @id: null to decouple a term from @vocab
   4. ISSUE-166: Add a conformance section
   5. ISSUE-169: Clarify the meaning of multiple node definitions
      with the same @id
   6. ISSUE-180: Make link to RDF more apparent in the
      specification
   7. ISSUE-181: Limit divergence between JSON-LD and RDF data
      models
   8. ISSUE-182: Graph vs DataSet
   9. ISSUE-189: Support of {@type:{@id:xxx}} constructs
   10. ISSUE-133: Add '@language' container type (related to
      ISSUE-159)
   11. ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core
      Processing
Resolutions:
   1. If '@container': '@annotation' is added to the JSON-LD
      Syntax, the feature MUST be round-trippable from .compact() to
      .expand() back to .compact()
   2. Add '@container': '@annotation' to the JSON-LD Syntax.
   3. Push the addition of '@container': '@graph' to the JSON-LD
      Syntax specification off to a later version of JSON-LD.
   4. Allow a term to be mapped to null (either directly or by
      setting @id to null). This mapping is stored in the active
      context and also overwrites a @vocab mapping meaning that the
      term does not expand to an IRI and will thus be dropped when
      expanding.
   5. Add a conformance section to the JSON-LD Syntax
      specification by merging pull request 194.
   6. Remove the term node reference as it is not needed; one
      term (currently node definition) is sufficient.
   7. Rename node definition to node object because 1. it doesn't
      actually “define” a node, and 2. to make more explicit that it is
      a kind of JSON object
   8. Add a statement in the introduction of the JSON-LD syntax
      specification saying that JSON-LD is a serialization of the RDF
      data model.
   9. Add the following statements to the specs: a) "Authors
      SHOULD NOT use unconnected nodes (a node definition that does not
      contain any properties) in JSON-LD documents." b) "Authors SHOULD
      NOT use blank nodes as edge labels." c) "JSON-LD processors MUST
      normalize all language tags to lowercase when processing
      documents via the JSON-LD Algorithms." d) "Blank node labels are
      scoped to the JSON-LD document."
   10. Do not support constructs like "@type":{"@id":"A"} in the
      spec as that would suggest to developers that they could include
      other properties of the type there as well.
   11. The values of the key-value pairs of a language map MUST
      be strings or arrays of strings. When expanded, the strings are
      tagged with the language specified by the key. When compacting,
      only language-tagged strings will match a term that has a
      "@container": "@language" mapping. Terms that have a
      "@container": "@language" mapping MUST NOT be type-coerced.
Action Items:
   1. Gregg to create a unified proposal or two for ISSUE-182.
Chair:
   Manu Sporny
Scribe:
   Niklas Lindström
Present:
   Niklas Lindström, Manu Sporny, Gregg Kellogg, Lin Clark, Markus
   Lanthaler, David I. Lehn, François Daoust, Richard Cyganiak
Audio:
   http://json-ld.org/minutes/2012-11-13/audio.ogg

Niklas Lindström is scribing.

Topic: ISSUE-196: Add '@annotation' container type

https://github.com/json-ld/json-ld.org/issues/196
Manu Sporny:  came out of the discussion about the Drupal use
   cases; specifically the thing we've called language maps; which
   is about something else
   … this proposal attempts to solve that, along with other
   aspects of the issues regarding mappings in JSON-LD
Niklas Lindström:  This proposal is sort of a unification of the
   various ideas we've had on how to use 'maps' to map certain keys
   to certain values where the keys do not represent actual
   properties of the object. [scribe assist by Manu Sporny]
Manu Sporny: This is a generalization of the @language map
   proposal - ISSUE-133
Niklas Lindström:  This @annotation suggestion doesn't define the
   meaning of the key and does not bind it to anything - you
   specifically can't map it to RDF. The reason for that is that
   there are JSON "in-the-wild" cases where you index stuff in a
   JSON object in order to have easier access to it. [scribe assist
   by Manu Sporny]
Niklas Lindström:  This seems to fit the Drupal use case. [scribe
   assist by Manu Sporny]
https://github.com/json-ld/json-ld.org/issues/196#issuecomment-10322466
Niklas Lindström:  There is a part on whether this should survive
   expansion. We could do it unobtrusively. [scribe assist by Manu
   Sporny]
Niklas Lindström:  This proposal does NOT, in the current shape,
   address the Microdata shape - I think we should first discuss the
   proposal, then we could discuss the shape of Microdata
   separately. [scribe assist by Manu Sporny]
Niklas Lindström:  In the Microdata case, the term does not have
   a value... the keys do - it's an inverse of the general mapping
   situation. [scribe assist by Manu Sporny]
Gregg Kellogg:  changing the mechanism to put the annotation key
   in the values of the properties (the latter suggestion) is
   better. It preserves the shape.
   … I'm still concerned about retaining information that does
   not map to RDF
Gregg Kellogg:  Changing the proposal to put the @annotation key
   in the property is much better and helps preserve the shape
   better. I'm still concerned that we're basically retaining
   information - creating a data model that is not an RDF data
   model. This is the shape of language maps, so I could go along
   with doing that. [scribe assist by Manu Sporny]
Gregg Kellogg:  In terms of the last point that Niklas had made
   of applying this to Microdata. I think we could use the same
   mechanism to address the Microdata use case. [scribe assist by
   Manu Sporny]
Lin Clark:  this proposal is actually what we originally
   expected, so it should work for us
   … and it doesn't use any additional blank nodes
Gregg Kellogg:  it requires to add container annotations, but not
   to declare language keys
Manu Sporny:  two parts of this proposal: 1) having the
   annotation properties, 2) making sure that this can round-trip
Niklas Lindström:  I want to emphasize what I think works for the
   round-tripping - it seems to me that if round-tripping would
   work, you could add annotations by post-processing expanded form.
   Then you could use compaction to make sure this mapping just
   "happens". The corner-case with that is that given the example
   has 3 nodes w/ @ids, regular compaction would not frame them in
   any way - you would end... [scribe assist by Manu Sporny]
Manu Sporny: ...up with a @graph keyword with the same nodes,
   unless the @annotation keyword is "scheduled" to be added.
Manu Sporny:  one other corner case: in expanded forms, you have
   three items with annotations and a fourth without: what happens
   then?
Markus Lanthaler:  the term wouldn't match
General discussion on the two proposals
Markus Lanthaler:  if we introduce this, we should make it
   roundtripplable
David I. Lehn: will properties that are duplicated in multile
   annotations override each other or show up as multiple values for
   the same property?

PROPOSAL:  If '@container'; '@annotation' is added to the JSON-LD
   Syntax, the feature MUST be round-trippable from .compact() to
   .expand() back to .compact()

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +0
Lin Clark: +1
François Daoust: 0
Niklas Lindström: +1 (knowing it's not the cleanest thing..)
David I. Lehn: +0
François Daoust: (I like the idea but wouldn't mind if it's not
   round-trippable)

RESOLUTION: If '@container': '@annotation' is added to the
   JSON-LD Syntax, the feature MUST be round-trippable from
   .compact() to .expand() back to .compact()

PROPOSAL:  Add '@container'; '@annotation' to the JSON-LD Syntax.

Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +0.8
François Daoust: +1
Markus Lanthaler: +0.8
Lin Clark: +1
David I. Lehn: +1

RESOLUTION: Add '@container': '@annotation' to the JSON-LD
   Syntax.

Lin Clark:  no outstanding concerns at the moment. Of course,
   need to test the implementation.
Manu Sporny:  any other concerns from Drupal?
Lin Clark:  none at the moment
Markus Lanthaler: Lin, what about ISSUE-195? Still needed?
Lin Clark: Markus, not if this is supported
Markus Lanthaler:  do you still the graph container?
Lin Clark:  not necessary if this is implemented
Markus Lanthaler:  I suggest to put 195 on hold then
General agreement to put issue 195 on hold.

Topic: ISSUE-195: Add '@graph' container type

Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/195

PROPOSAL:  Push the addition of '@container'; '@graph' to the
   JSON-LD Syntax specification off to a later version of JSON-LD.

Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
François Daoust: +1
David I. Lehn: +0
Lin Clark: +1

RESOLUTION: Push the addition of '@container': '@graph' to the
   JSON-LD Syntax specification off to a later version of JSON-LD.

Topic: ISSUE-165: Allow @id: null to decouple a term from @vocab

https://github.com/json-ld/json-ld.org/issues/165
Markus Lanthaler: PROPOSAL 1: Allow a term to be mapped to null
   (either directly or by setting @id to null). This mapping is
   stored in the active context and also overwrites a @vocab mapping
   meaning that the term does not expand to an IRI and will thus be
   dropped when expanding.
Markus Lanthaler: PROPOSAL 2: If a term is mapped to null (either
   directly or by setting @id to null) remove its definition from
   the active context. This means that when a @vocab mapping exists,
   the term is expanded using the @vocab IRI in expansion and will
   thus not be dropped.
Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/165
Gregg Kellogg:  proposal 1 is to explicitly prevent a term from
   being expanded by @vocab by setting it to null
Gregg Kellogg:  some other options: we could use blank nodes as
   terms, since they are not allowed
Niklas Lindström:  There might be a problem with that in the
   future, if RDF 2.0 allows properties to be blank nodes. I've seen
   N3 notation like that - poor mans reification by having a
   property inline as a blank node. [scribe assist by Manu Sporny]
Manu Sporny:  +0.5 (PROPOSAL 1) , + 0.4 (PROPOSAL 2) [scribe
   assist by Manu Sporny]
Gregg Kellogg: +0.1, +0.6
Niklas Lindström: +1 (PROPOSAL 1), -1 (PROPOSAL 2)
Markus Lanthaler: +0 (PROPOSAL 1) , +0 (PROPOSAL 2)
François Daoust: +1 to proposal 1, 0 to proposal 2
Niklas Lindström:  My @rev feature in my compact JSON needs this
   feature, it's based on a real-world use case. [scribe assist by
   Manu Sporny]

RESOLUTION: Allow a term to be mapped to null (either directly or
   by setting @id to null). This mapping is stored in the active
   context and also overwrites a @vocab mapping meaning that the
   term does not expand to an IRI and will thus be dropped when
   expanding.

Topic: ISSUE-166: Add a conformance section

https://github.com/json-ld/json-ld.org/issues/166
François Daoust: Here's the pull request -
   https://github.com/json-ld/json-ld.org/issues/194
Markus Lanthaler: and the diff:
   https://github.com/json-ld/json-ld.org/pull/194/files
Markus Lanthaler:  we should add a conformance section, François
   has already written it (it's in a pull request)
   … richard made a remark about removing one sentence; François
   has removed it, so we can merge it

PROPOSAL:  Add a conformance section to the JSON-LD Syntax
   specification by merging pull request 194.

Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
François Daoust: +1

RESOLUTION: Add a conformance section to the JSON-LD Syntax
   specification by merging pull request 194.

Topic: ISSUE-169: Clarify the meaning of multiple node definitions with
the same @id

https://github.com/json-ld/json-ld.org/issues/169
Markus Lanthaler: PROPOSAL 1: Remove the term node reference as
   it is not needed; one term (currently node definition) is
   sufficient.
Markus Lanthaler: PROPOSAL 2: Rename node definition to node
   object because 1. it doesn't actually “define” a node, and 2. to
   make more explicit that it is a kind of JSON object
Gregg Kellogg:  I hope that removing the notion of a node
   reference won't bite us
Markus Lanthaler:  an object with only an id still defines a node
   I think
Gregg Kellogg:  when flattening, a node with just an id, with no
   references to it, is just saying there is a point, disconnected
   from the rest of the graph
Manu Sporny:  same concerns as gregg. the reason for the
   difference is because the terms are used in the algoritms
Markus Lanthaler:  only 7 occurrences
Markus Lanthaler:  at least 5 of these are used together
Markus Lanthaler:  in the minor cases where it matters we can be
   explicit about there not being any other properties (in a node
   reference)
Gregg Kellogg:  I wonder whether not having a concept for it may
   be a problem
Gregg Kellogg:  sort of like the triple and iri in RDF concepts
Gregg Kellogg:  the iri itself is not in the graph
(by itself)
Manu Sporny:  since this is editorial, we can always fix it if it
   becomes a problem
Manu Sporny:  +0.5 (PROPOSAL 1), +0.5 (PROPOSAL 2) [scribe assist
   by Manu Sporny]
Markus Lanthaler: +1 to both
Gregg Kellogg: +0.5/+0.5
Niklas Lindström:  +0.5/+0.5
François Daoust: +1 to both proposals (but wouldn't mind keeping
   the distinction between "node object" and "node reference"
   either)

RESOLUTION: Remove the term node reference as it is not needed;
   one term (currently node definition) is sufficient.

RESOLUTION: Rename node definition to node object because 1. it
   doesn't actually “define” a node, and 2. to make more explicit
   that it is a kind of JSON object

Topic: ISSUE-180: Make link to RDF more apparent in the specification

Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/180
Markus Lanthaler:  Editorial, mentioning RDF in the introduction
   of the spec: saying JSON-LD is a serialization of RDF

PROPOSAL:  Add a statement in the introduction of the JSON-LD
   syntax specification saying that JSON-LD is a serialization of
   the RDF data model.

Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler: +1
François Daoust: +1

RESOLUTION: Add a statement in the introduction of the JSON-LD
   syntax specification saying that JSON-LD is a serialization of
   the RDF data model.

Topic: ISSUE-181: Limit divergence between JSON-LD and RDF data models

https://github.com/json-ld/json-ld.org/issues/181
Markus Lanthaler:  we diverge where we allow unconnected nodes,
   so they don't form triples in the end
   … proposal is a "SHOULD NOT" about their use
   … and the same for blank nodes as properties; processors must
   lower-case language tags, and that blank nodes id:s are scoped to
   the document
Markus Lanthaler: from richard: With 1 and 2, I am unconvinced
   that having those features (blank edges and unconnected nodes) in
   the JSON-LD data model is actually useful, and would prefer if
   the algorithms would either remove them, or translate them into
   something that can be expressed in the RDF data model.
   … richard also have some modifications (see issue comment
   https://github.com/json-ld/json-ld.org/issues/181#issuecomment-10327459)
Gregg Kellogg:  regarding blank edges, this *may* become part of
   RDF in the future, so I'd prefer the use of SHOULD NOT for those
   … regarding unconnected nodes, it's algorithmically difficult
   to prevent those in expand and compact. It *is* done in the
   toRDF. We could also do the same in flatten, although that
   requires checking every node object to see if a node is used
   ... it is more complex, but allows us to remove these dangling
   references
   … (just a thought)
Manu Sporny:  agrees with the reasoning. but the issue is
   complex; I think the language should address it sufficiently
   (plus making the algorithms explicit about what they support).

PROPOSAL:  Add the following statements to the specs - a)
   "Authors SHOULD NOT use unconnected nodes (a node definition that
   does not contain any properties) in JSON-LD documents." b)
   "Authors SHOULD NOT use blank nodes as edge labels." c) "JSON-LD
   processors MUST normalize all language tags to lowercase when
   processing documents via the JSON-LD Algorithms." d) "Blank node
   labels are scoped to the JSON-LD document."

Markus Lanthaler:  it can still be said that the nodes exist
   (c.f. the open world assumption)
Manu Sporny: +1
Gregg Kellogg: +
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
François Daoust: +1 but note proposal c) is for API doc

RESOLUTION: Add the following statements to the specs: a)
   "Authors SHOULD NOT use unconnected nodes (a node definition that
   does not contain any properties) in JSON-LD documents." b)
   "Authors SHOULD NOT use blank nodes as edge labels." c) "JSON-LD
   processors MUST normalize all language tags to lowercase when
   processing documents via the JSON-LD Algorithms." d) "Blank node
   labels are scoped to the JSON-LD document."

Markus Lanthaler:  could be compared to e.g. rdf:Description
   rdf:about=""/ in RDF/XML.

Topic: ISSUE-182: Graph vs DataSet

https://github.com/json-ld/json-ld.org/issues/182
Markus Lanthaler:  about whether if json-ld is a serialization of
   a graph or a dataset
   … a graph is a set of triples, a dataset is a set of graphs
   … under consideration is if this distinction should be made by
   using different mime-types
   … the proposal is that we should make clear what json-ld
   serializes
Markus Lanthaler: PROPOSAL 1: normatively define the concept of a
   JSON-LD Dataset. In the context of a Dataset, a JSON-LD document
   including only a default graph serializes a Dataset with only a
   default graph. A JSON-LD document describing a default graph
   and/or one or more named graphs serializes a Dataset with default
   and named graphs.
Markus Lanthaler: PROPOSAL 2: define an alternate extension and
   mime-type for describing JSON-LD documents serializing Datasets,
   as distinct from the existing type which serializes a single
   graph. Named graphs used within a graph serialization are
   flattened into a single graph, and produce only a single graph
   when parsed.
Markus Lanthaler: PROPOSAL 3: Normatively define the concept of a
   "JSON-LD document".
Markus Lanthaler: PROPOSAL 4: Add in the RDF-mapping section
   Richard is writing a statement that JSON-LD documents serialize
   datasets (which may contain only a default graph)
Markus Lanthaler: PROPOSAL 5: Do not introduce additional mime
   types or file extensions to distinguish between JSON-LD documents
   containing only a default graph from documents containing
   multiple graphs.
Markus Lanthaler: PROPOSAL 6: A JSON-LD document which does no
   @graph, or containing @graph only as part of the top-level node
   definition without an @id property serializes a an RDF Graph.
Markus Lanthaler: PROPOSAL 7: A JSON-LD document containing any
   node definition having both @graph and @id serializes an RDF
   Dataset.
Markus Lanthaler: PROPOSAL 8: The @graph keyword may only be used
   in top-level node definitions, i.e., node definitions which are
   not the value of a property of another node definition.
Niklas Lindström:  Every other RDF format in use, apart from
   TRiG, only represent graphs... my concern is how this will be
   treated by SPARQL Read/Write APIs and perhaps other RW RDF
   approaches by Linked Data Platform. [scribe assist by Manu
   Sporny]
Markus Lanthaler: Richard's votes:
Markus Lanthaler: PROPOSAL 1: +1
Markus Lanthaler: PROPOSAL 2: -1
Markus Lanthaler: PROPOSAL 3: +1
Markus Lanthaler: PROPOSAL 4: +1
Markus Lanthaler: PROPOSAL 5: +1
Markus Lanthaler: PROPOSAL 6: -1 because a dataset without named
   graphs is not an RDF graph.
Markus Lanthaler: PROPOSAL 7: a fact
Markus Lanthaler: PROPOSAL 8: no opinion
Niklas Lindström:  For instance, in SPARQL, you can put a
   document to a specific IRI, the Quad-store uses the IRI that the
   POST went to as the graph name. There are parts of this that I'm
   concerned about because we don't know how Datasets will be used
   in the future. [scribe assist by Manu Sporny]
Gregg Kellogg:  my implementation deals with this by depending on
   the user
   … if I put a JSON-LD document into a graph container (into a
   named graph), it is turned into a set of triples which are put
   into the destination graph
   … the resolution is to let the behavior depend on this
   … the container determines what happens: if it takes graphs,
   the graphs in the dataset are preserved, otherwise they are
   merged
Manu Sporny:  the web payments only use named graphs for digital
   signatures
Manu Sporny:  we don't use sparql or similar which cares about
   quads/datasets
Markus Lanthaler: my votes
Markus Lanthaler: PROPOSAL 1: -1, PROPOSAL 2: -1, PROPOSAL 3: +1,
   PROPOSAL 4: +1, PROPOSAL 5: +1, PROPOSAL 6: n/a, PROPOSAL 7: a
   fact, PROPOSAL 8: -1
Manu Sporny:  can we consolidate this proposal and defer for now?

ACTION: Gregg to create a unified proposal or two for ISSUE-182.

François Daoust: [OK to defer. Overall, I would prefer to stick
   to something as simple as "a JSON-LD document serializes a
   dataset" without exceptions based on the presence/absence of
   "@graph" at key positions in the document]

Topic: ISSUE-189: Support of {@type:{@id:xxx}} constructs

https://github.com/json-ld/json-ld.org/issues/189
Markus Lanthaler: Do we allow this? "@type":{"@id":"A"}
Markus Lanthaler:  The proposal is to disallow it

PROPOSAL:  Do not support constructs like "@type";{"@id";"A"} in
   the spec as that would suggest to developers that they could
   include other properties of the type there as well.

Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Richard Cyganiak:  +1 to proposal [scribe assist by Markus
   Lanthaler]
Markus Lanthaler: +1
François Daoust: +1 (I don't think that converts into any change
   in the syntax spec, as it's already forbidden by the grammar)

RESOLUTION: Do not support constructs like "@type":{"@id":"A"} in
   the spec as that would suggest to developers that they could
   include other properties of the type there as well.

Topic: ISSUE-133: Add '@language' container type (related to ISSUE-159)

https://github.com/json-ld/json-ld.org/issues/133
Gregg Kellogg: PROPOSAL 3: The values of the key-value pairs of a
   language map MUST be strings or arrays of strings. When expanded,
   the strings are tagged with the language specified by the key.
   When compacting, only language-tagged strings will match a term
   that has a "@container": "@language" mapping. Terms that have a
   "@container": "@language" mapping MUST NOT be type-coerced.
Markus Lanthaler:  given that we have annotation, we can restrict
   to language-tagged strings
Manu Sporny:  one question: this decisions makes it so that only
   plain text strings can be used in language maps?
Gregg Kellogg: For expansion, I would say that non-string (or
   array of string) values of a property with language maps are
   expanded to use the property, but loose the language association.
   That is, they don't round-trip.
François Daoust:  now with container: annotation, the container:
   language seems unneeded
Gregg Kellogg:  this does address the issue that values in
   different languages become convenient to reach; for instance in
   wikipedia, 10 different languages for a title become easy to
   access
Markus Lanthaler: "title" : { "en": 1 } doesn't round-trip since
   the value is not a string
   … for consistency's sake, if we get data with bad shape, where
   non-regular strings aren't discarded, but not interpreted as
   having the language of the key

PROPOSAL:  The values of the key-value pairs of a language map
   MUST be strings or arrays of strings. When expanded, the strings
   are tagged with the language specified by the key. When
   compacting, only language-tagged strings will match a term that
   has a "@container"

Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
François Daoust: +1 (it's a bit confusing as similar to but less
   flexible than "@annotation" but I understand the need to support
   language in a special way)

RESOLUTION: The values of the key-value pairs of a language map
   MUST be strings or arrays of strings. When expanded, the strings
   are tagged with the language specified by the key. When
   compacting, only language-tagged strings will match a term that
   has a "@container": "@language" mapping. Terms that have a
   "@container": "@language" mapping MUST NOT be type-coerced.

Topic: ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core Processing

https://github.com/json-ld/json-ld.org/issues/178
Markus Lanthaler: PROPOSAL 1: Do not rename the JSON-LD API spec
Markus Lanthaler: PROPOSAL 2: Rename the JSON-LD API spec to
   "JSON-LD Core Processing"
Markus Lanthaler: PROPOSAL 3: Rename the JSON-LD API spec to
   "JSON-LD Algorithms and API"
Markus Lanthaler: PROPOSAL 4: Move Data Model and Grammar to the
   JSON-LD API spec, and rename it to "JSON-LD: Definitions,
   Processing and API".
Markus Lanthaler: PROPOSAL 4b: Move Data Model and Grammar to the
   JSON-LD API spec, and rename it to "JSON-LD: Definitions,
   Processing and API". Rename "JSON-LD Syntax" to something generic
   like "JSON-LD: JSON for Linked Data".
Markus Lanthaler: Richard's votes:
Markus Lanthaler: PROPOSAL 1: -0.7 (The meat of the spec is not
   the API, so the current title is false advertising.)
Markus Lanthaler: PROPOSAL 2: -0.2 (Why “Core”? Seems to be
   brainless and inappropriate copying of the RDFa spec name.)
Markus Lanthaler: PROPOSAL 3: -0.2 (“Algorithms” is just the
   style used to define the processing. If the processing was
   spelled out in prose, you wouldn't call the spec “API and Prose”.
   Or “API and Diagrams”. What's the purpose of the algorithms? That
   needs to go into the title.)
Markus Lanthaler: PROPOSAL 4: +0.99
Markus Lanthaler: PROPOSAL 4b: +1
Manu Sporny:  web developers tend to go to the source - the core
   spec. not the primer
   … primers tend to be fairly high-level [not containing all the
   needed details]
   … what document will they naturally hit (from e.g. google)
Manu Sporny:  what ever title is picked, has to convey the
   relevant message to the intended reader in a google hit
   … for instance: "Introduction to JSON-LD" is better than 4b
Niklas Lindström:  I think that the titles should convey to the
   audience that we want something that tells them to read the
   document. [scribe assist by Manu Sporny]
Gregg Kellogg:  best title aside, richard's intent is valuable
   … regarding the case of someone getting to the wrong document,
   a good introduction should send them to the right place
   … so one normative document and one more informative note(?)
   sounds good
Manu Sporny:  this seems like bike shedding though
Manu Sporny:  thanks all for the fantastic session and for all of
   the hard work to close these issues! Great job everyone!

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/

Received on Tuesday, 20 November 2012 03:29:45 UTC