JSON-LD Telecon Minutes for 2013-03-12

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/

Received on Tuesday, 19 March 2013 16:06:43 UTC