Thanks to Markus for scribing! The minutes from last week's telecon are
now available.
http://json-ld.org/minutes/2013-03-12/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2013-03-12
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Mar/0012.html
Topics:
1. ISSUE-224: Sandro Hawke's JSON-LD syntax spec review
Chair:
Manu Sporny
Scribe:
Markus Lanthaler
Present:
Manu Sporny, Markus Lanthaler, Gregg Kellogg, Dave Longley
Audio:
http://json-ld.org/minutes/2013-03-12/audio.ogg
Manu Sporny: Any updates or changes to the Agenda? [scribe
assist by Manu Sporny]
Markus Lanthaler is scribing.
Topic: ISSUE-224: Sandro Hawke's JSON-LD syntax spec review
Markus Lanthaler: Most of his feedback was just editorial, but
there were a couple of points that we should discuss before we do
any changes. [scribe assist by Manu Sporny]
Markus Lanthaler: In introduction, we paraphrase linked data
principles to explain what JSON-LD is about. Sandro didn't like
that... maybe we should reference something or rephrase? [scribe
assist by Manu Sporny]
Manu Sporny: Let's rephrase it, we need to summarize what
JSON-LD is about. [scribe assist by Manu Sporny]
Gregg Kellogg: I can see Sandro's perspective, there is no other
serialization that needs to go into that kind of detail. Well,
perhaps HTML+RDFa 1.1 [scribe assist by Manu Sporny]
Manu Sporny: JSON-LD is kind of different because we talk about
Linked Data first instead of RDF first.. otherwise you would have
to read RDF Concepts first
... JSON developers are prob. not familiar with
Gregg Kellogg: my feeling is, if it is non-normative it
shouldn't matter..
Markus Lanthaler: Next point was about design goals section -
Sandro doesn't think the history is important. I changed it to
use present tense. Do we want to keep that section? [scribe
assist by Manu Sporny]
Manu Sporny: I would be worried with removing it
... moving it to the introduction is also problematic because
it makes the intro larger
... I think you did the right thing
Markus Lanthaler: Next up is Example 5 - Linked Header, Sandro
was expecting an early example of it. [scribe assist by Manu
Sporny]
Markus Lanthaler: He thought it should be after remote
contexts... under basic concepts. [scribe assist by Manu Sporny]
Markus Lanthaler: Either we include it there or a subsection
after that section. [scribe assist by Manu Sporny]
Markus Lanthaler: I would like to include it in the beginning,
important feature for adoption... they have JSON that could be
transformed to JSON-LD with just that Link Header. [scribe assist
by Manu Sporny]
Manu Sporny: I'm on the fence about this
... I think not many web devs know about Link headers
Gregg Kellogg: I think we can mention it there without
mentioning HTTP Link headers
... you can apply a context to a JSON document
Manu Sporny: Sandro mentioned explicit. the Link header
... we don't reference the API anywhere else in the document
Gregg Kellogg: we don't need to reference it.. just mention it
Manu Sporny: Perhaps a note explaining how you can assign a link
header or a context via JSON-LD API [scribe assist by Manu
Sporny]
Gregg Kellogg: maybe update the example to show with and w/o a
context. [scribe assist by Manu Sporny]
Markus Lanthaler: Next up - show an example about how a relative
IRI is used. I thought this was trivial at first, but it isn't
actually. We talk about absolute IRIs in the key position and
using it via @id is an "expanded IRI definition". If we put in an
example with relative IRIs, it's a problem. [scribe assist by
Manu Sporny]
Gregg Kellogg: Maybe we can do this after example 9? [scribe
assist by Manu Sporny]
Gregg Kellogg: maybe we could use a relative IRI to specify the
homepage and the person? [scribe assist by Manu Sporny]
Markus Lanthaler: We don't want to give the false impression
that properties would be interpreted as relative IRIs. [scribe
assist by Manu Sporny]
Gregg Kellogg: We can elaborate by providing a link to another
section. [scribe assist by Manu Sporny]
Dave Longley: yeah, we can refer to the relative IRI section.
[scribe assist by Manu Sporny]
Markus Lanthaler: I don't know about referencing from an
introduction to the grammar. [scribe assist by Manu Sporny]
Manu Sporny: I think we need to explain relative IRIs a bit
better somewhere in the document and reference that section.
[scribe assist by Manu Sporny]
Gregg Kellogg: We should elaborate in this section and not refer
to the Grammar. [scribe assist by Manu Sporny]
Markus Lanthaler: ... "this is where we need a clear notion of a
processor that reads JSON-LD and extracts all the triples and
quads from it, it seems to me." [scribe assist by Manu Sporny]
Markus Lanthaler: Sandro wanted to know exactly what results in
triples/quads... what is removed, etc? [scribe assist by Manu
Sporny]
Markus Lanthaler: He seems to be concerned that we say that "in
some cases things are removed", but we don't enumerate those
cases. [scribe assist by Manu Sporny]
Gregg Kellogg: Well, it's any property that is a term that
doesn't expand to an IRI. [scribe assist by Manu Sporny]
Dave Longley: I think we just need to re-order the way this is
in the spec. Certain keys don't expand to unambiguous identifiers
because they don't generate any triples. [scribe assist by Manu
Sporny]
Dave Longley: We say there are keys that don't expand to an IRI
and they're ignored... however they're valid - that's the
problem. [scribe assist by Manu Sporny]
Manu Sporny: Discussion about how to state this more eloquently.
Dave Longley: Can we say that data is ignored like comments are
ignored? [scribe assist by Manu Sporny]
Manu Sporny: Yeah, I think "ignore" is the right word here.
[scribe assist by Manu Sporny]
Markus Lanthaler: What if we say "properties that do not expand
to IRIs are not Linked Data and are ignored when processed."
[scribe assist by Manu Sporny]
Manu Sporny: I like that. [scribe assist by Manu Sporny]
Markus Lanthaler: Section 5.3 intro - drop the paragraph?
[scribe assist by Manu Sporny]
Gregg Kellogg: I think this implies that there is something
wrong with using bnodes. They are externally useful, but only in
reference to something else. [scribe assist by Manu Sporny]
Gregg Kellogg: In Wikia - why can't we use bnodes? Because you
can never get to it. [scribe assist by Manu Sporny]
http://json-ld.org/spec/latest/json-ld-syntax/#node-identifiers
Dave Longley: "IRIs are a fundamental concept of Linked Data, for
nodes to be truly linked, de-referencing the identifier should
result in a representation of that node."
Dave Longley: more problematic is IMO "Associating an IRI with a
node tells an application that it can fetch the resource
associated with the IRI and get back a description of the node."
Markus Lanthaler: What about instead of saying "telling" vs.
"may allowing" [scribe assist by Manu Sporny]
... Associating an IRI with a node may allows an application
to fetch the resource associated with the IRI and get back a
description of the node.
Dave Longley: "may allow"
Markus Lanthaler: Section 5 marked as normative vs.
non-normative - change in respect, this section should be
normative... it just adds labels if the section is non-normative.
[scribe assist by Manu Sporny]
Markus Lanthaler: Sections not marked as 'normative' don't have
anything at the top of the section... respec doesn't generate the
markers anymore. [scribe assist by Manu Sporny]
Markus Lanthaler: We do this - <em>This section is
normative.</em>
Manu Sporny: So, we have to go through to figure out if there is
a bug in ReSpec... if there isn't, we have to label all the
sections as either 'normative' or 'informative'. [scribe assist
by Manu Sporny]
Markus Lanthaler: The only sections that are normative are:
JSON-LD Grammar, interpreting JSON and JSON-LD (Link Header
stuff) - those are the only two normative sections according to
the conformance section. [scribe assist by Manu Sporny]
Manu Sporny: So, all top-level sections should be marked as
informative, including section 6. Section 6.8 should be marked as
normative. [scribe assist by Manu Sporny]
Manu Sporny: The Grammar should be marked as normative as well.
[scribe assist by Manu Sporny]
Manu Sporny: Conformance needs to be normative as well. [scribe
assist by Manu Sporny]
Manu Sporny: Data Model needs to be normative. [scribe assist by
Manu Sporny]
Markus Lanthaler: 6.1 Compact IRIs [scribe assist by Manu
Sporny]
Markus Lanthaler: Sandro thinks detecting "://" is too much
[scribe assist by Manu Sporny]
Gregg Kellogg: I think it's an important safety mechanism - the
suffix can't start with two slashes. [scribe assist by Manu
Sporny]
Dave Longley: This is more about preventing http from being a
prefix. [scribe assist by Manu Sporny]
Gregg Kellogg: somebody had defined 'http' as a prefix, so it
changed. [scribe assist by Manu Sporny]
Manu Sporny: http://prefix.cc/http
Markus Lanthaler: There is only that single case, really.
[scribe assist by Manu Sporny]
Manu Sporny: No, we need this to protect all hierarchical
IRIs... irc:// ftp:// http:// etc [scribe assist by Manu Sporny]
http://example.com/some//path
Manu Sporny: big -1 on removing this protection [scribe assist
by Manu Sporny]
Dave Longley: We need to change the following sentence by saying
there is a restriction on suffixes otherwise it will not cause
the value to be interpreted as a compact IRI. [scribe assist by
Manu Sporny]
http://example.com/some//path
Dave Longley: Yes, you can't do that with this rule, but it's
more important to protect against the common misinterpretation
case. [scribe assist by Manu Sporny]
Markus Lanthaler: Next up, Example 17 - Sandro was wondering if
the order matters, then he realized that it doesn't matter... but
maybe we should cover that in this particular example -
explicitly state that order is not important. [scribe assist by
Manu Sporny]
Markus Lanthaler: "Okay, this overloading of @ keywords goes too
far with @vocab serving a completely different purpose (from
normal @vocab) in this situation." [scribe assist by Manu Sporny]
Markus Lanthaler: he wants a table explaining how where it is
used changes the meaning... there are really just two cases, it's
going to be a pretty small table. [scribe assist by Manu Sporny]
Dave Longley: We should better describe it's use and maybe it
wouldn't seem so foreign at that point. [scribe assist by Manu
Sporny]
Markus Lanthaler: This is about section 6.5 - intro describes
that. [scribe assist by Manu Sporny]
http://json-ld.org/spec/latest/json-ld-syntax/#type-coercion
"@type": "@vocab"
Manu Sporny: That allows one to have a term on the right hand
side and have it interpreted.
Dave Longley: The value in @id can be interepreted as a term.
[scribe assist by Manu Sporny]
Dave Longley: It removed ambiguity in that case... [scribe
assist by Manu Sporny]
Gregg Kellogg: I understand the value, maybe we need an
explanation that @vocab serves two purposes. [scribe assist by
Manu Sporny]
Gregg Kellogg: Maybe we just need an example that uses this.
[scribe assist by Manu Sporny]
Dave Longley: Yes, people need to understand how to use
enumerated types. [scribe assist by Manu Sporny]
Manu Sporny: Agree. [scribe assist by Manu Sporny]
Markus Lanthaler: "It is a best practice to put the context
definition at the top of the JSON-LD document." [scribe assist by
Manu Sporny]
Markus Lanthaler: Sandro disagrees, because it makes it seem
like you shouldn't allow JavaScript to just serialize a JSON-LD
document out - you can't influence the order in which it gets
serialized. [scribe assist by Manu Sporny]
Markus Lanthaler: That's true for some serializers, but
certainly not all. Many JSON-LD documents will be generated by
using templates. I'd like to keep this note, it makes reading the
documents for a human far easier. [scribe assist by Manu Sporny]
Dave Longley: We can explain that some serializers don't allow
you to do that. [scribe assist by Manu Sporny]
Manu Sporny: We can explain that some serializers don't allow
ordering and that's fine, they will still be valid JSON-LD
documents. [scribe assist by Manu Sporny]
Gregg Kellogg: Yes, I had to implement a special hashing class
to order @context at the beginning. [scribe assist by Manu
Sporny]
Gregg Kellogg: Maybe instead of "best practice", we should say
"when possible". [scribe assist by Manu Sporny]
Markus Lanthaler: So, "when possible"? [scribe assist by Manu
Sporny]
Gregg Kellogg: Keywords before properties is a good also [scribe
assist by Manu Sporny]
Dave Longley: We could say "When possible, put the @context
first, other JSON-LD keywords next, then the properties". [scribe
assist by Manu Sporny]
Dave Longley: We should also say that if they don't do that,
it's not a problem - it will still be a valid JSON-LD document.
[scribe assist by Manu Sporny]
Dave Longley: and mention that outputting in another order won't
break conformance
Markus Lanthaler: ".well-known/host-context.jsonld" [scribe
assist by Manu Sporny]
Manu Sporny: let's not do that [scribe assist by Manu Sporny]
Dave Longley: yeah, -1 on that [scribe assist by Manu Sporny]
Markus Lanthaler: Don't like that feature. [scribe assist by
Manu Sporny]
Markus Lanthaler: "To avoid forward-compatibility issues, a term
should not start with an @ character" [scribe assist by Manu
Sporny]
Manu Sporny: I think saying "MUST NOT" goes too far, we want
some flexibility here. [scribe assist by Manu Sporny]
Gregg Kellogg: We could create an extension registry - maybe
someone could request it over JSON-LD mailing list. [scribe
assist by Manu Sporny]
Gregg Kellogg: I'd like to do "@ordered" instead of "@list" -
and have my own note... if MUST NOT is there, I'd be violating
the spec - that's not what we want to do, we don't want to
prevent stuff like that. [scribe assist by Manu Sporny]
Gregg Kellogg: If we provide a keyword registry, we can do that
easily. [scribe assist by Manu Sporny]
Markus Lanthaler: who decides which keywords are allowed?
[scribe assist by Manu Sporny]
Gregg Kellogg: The group decides... [scribe assist by Manu
Sporny]
Gregg Kellogg: There is a process by which we decide to update
it. [scribe assist by Manu Sporny]
Dave Longley: If we were to put MUST NOT in the spec, do we kick
out an error? [scribe assist by Manu Sporny]
Dave Longley: If we put MUST NOT and don't kick out an error,
people are going to put @mykeyword in their documents. [scribe
assist by Manu Sporny]
Gregg Kellogg: Yes, so people will try to work around that.
[scribe assist by Manu Sporny]
Dave Longley: Yeah, so people will "+mykeyword" - which is
worse. [scribe assist by Manu Sporny]
Dave Longley: Two people are probably not going to pick the same
words that do different things. [scribe assist by Manu Sporny]
Gregg Kellogg: I think we need a registry. [scribe assist by
Manu Sporny]
Dave Longley: Can you change prefixes currently registered and
change it to something else... [scribe assist by Manu Sporny]
Dave Longley: I don't understand how this is different from not
having a registry? [scribe assist by Manu Sporny]
Dave Longley: I'm a little against a registry - I'd like the
best feature to win, not the person that claimed the feature name
first. [scribe assist by Manu Sporny]
Markus Lanthaler: +1
Dave Longley: It also avoids the 'domain squatter' issue.
[scribe assist by Manu Sporny]
Dave Longley: I think it makes it more difficult to extend the
language - I think it'll sort itself out. It's better to do that
than restrict it strongly. [scribe assist by Manu Sporny]
Gregg Kellogg: another way would be to have a mechanisms to
claim a keyword in a context
... you should be able to "follow your nose" to find a
specification describing how a keyword is intended to be used
Manu Sporny: another option would be to allow multiple entries
in the registry
Dave Longley: what's the point of the registry then?
Manu Sporny: you could find all ext. in one place
Markus Lanthaler: You could introduce special processing for
terms, but until we update the JSON-LD spec, no compliant
processor would do the same thing. The algorithms are written in
a way that they must drop things that don't expand to an IRI. We
just need to make it clear that it's a bad idea. [scribe assist
by Manu Sporny]
Markus Lanthaler: Terms starting with '@' will be dropped.
[scribe assist by Manu Sporny]
Dave Longley: would processors keeping such keywords instead of
dropping them non-conformant?
Manu Sporny: no.. they might do that.. but processors not
understanding it will ignore
Markus Lanthaler: Yes, this is the same as HTML's extensibility
mechanism - you just ignore things you don't understand. [scribe
assist by Manu Sporny]
Manu Sporny: yeah, exactly.. AngularJS uses this heavily
-- 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/