- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 19 Nov 2012 22:29:09 -0500
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
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:41 UTC