JSON-LD Telecon Minutes for 2013-06-25

The minutes from this week's telecon are now available.

http://json-ld.org/minutes/2013-06-25/

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

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-06-25

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jun/0041.html
Topics:
   1. Peter Patel-Schneider's comments
   2. ISSUE-257: Blank node identifers for data types
   3. ISSUE-264: JsonLdUrlDereferencer option
   4. JSON-LD introduction
Resolutions:
   1. Do not support blank nodes as data types.
   2. Raise an error if a blank-node-typed literal is detected.
   3. Generalize the LoadContextCallback feature into a
      LoadDocumentCallback feature and use it for loading both remote
      contexts and remote documents when necessary.
Chair:
   Manu Sporny
Scribe:
   Manu Sporny
Present:
   Manu Sporny, Peter Patel-Schneider, Clay Wells, Niklas Lindström,
   Gregg Kellogg, Markus Lanthaler, Dave Longley, David Booth,
   David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-06-25/audio.ogg

Manu Sporny is scribing.
Manu Sporny:  Any updates or changes to the agenda?

Topic: Peter Patel-Schneider's comments

http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0126.html
Peter Patel-Schneider:  There are two halves to the changes - a
   very toned down version of feedback from Gregg Reynolds. I agree
   with his comments.
Peter Patel-Schneider:  I agree with his comments, after reading
   json-ld.org, I agree even more. I think there is something that
   is actionable.
Peter Patel-Schneider:  Regarding the "We can't mention RDF
   because it will annoy JSON folks" - that's bogus. There is
   json-ld.org. The tender sensibilities of JSON developers will not
   be harmed by doing the right thing in the W3C spec in the WG.
Peter Patel-Schneider:  That's one side of the comment.
Peter Patel-Schneider:  JSON-LD is supposedly a W3C from the RDF
   WG and it is not related to anything else from W3C.
Peter Patel-Schneider:  That's not appropriate. My modest
   suggestion (truly modest in this case), is to firm up the
   relationship between JSON-LD and the rest of W3C semantic web
   specs and Linked Data specs.
Peter Patel-Schneider:  I think JSON-LD should be firmly placed
   on top of RDF. I think that can be accomplished by modifying
   Appendix A and Appendix C. As far as I can tell, there won't be
   any changes to the other JSON-LD docs.
Peter Patel-Schneider:  Even if those changes are made, we're in
   an unhappy situation, but I'm willing to hold my nose.
Clay Wells: +1
Niklas Lindström:  I agree on the intent.
Gregg Kellogg:  I've supported what Peter wants to do, I want to
   balance that with the direction we've been taking. We wanted to
   de-emphasize RDF, but not for all practical purposes.
Gregg Kellogg:  This is mostly in an effort to get to consensus.
   I don't think using RDF more expicitly early on is going ot push
   people away.
Manu Sporny:  there's a quite bit of history behind the approach
   of JSON-LD ... this is mostly directed at Peter since you've been
   out of the loop w/respect to a lot of the previous discussions on
   this matter, in the very beginning w/JSON-LD, what we did was set
   out to do was create a data exchange format that was compatible
   with RDF but was very easy for web developers to use, we wanted
   round tripability with RDF, not necessarily to be built on top of
   RDF [scribe assist by Dave Longley]
Manu Sporny:  that's where JSON-LD started, and that's why
   certain things are in the spec, as we joined the RDF WG we ...
   [missed] [scribe assist by Dave Longley]
Peter Patel-Schneider:  the idea that RDF was not a central
   pillar to JSON-LD wasn't brought into the RDF WG [scribe assist
   by Dave Longley]
Manu Sporny:  what we wanted to be able to do was be able to
   provide a tool that works for both web developers and the semweb
   community [scribe assist by Dave Longley]
Manu Sporny:  the problem was that those two different
   communities have very different ideas about what an "easy to use"
   app is [scribe assist by Dave Longley]
Manu Sporny:  the semweb community thinks that it's easy to
   understand RDF and the RDF model, etc. and people can just use it
   without any issue [scribe assist by Dave Longley]
Manu Sporny:  the other community, again, this is a general broad
   brush statement, feel that RDF is overly complicated, hard to
   use, can conflate it with RDF/XML and even if they don't they
   feel that RDF has a very steep learning curve and they can't sort
   out what's important and what's not [scribe assist by Dave
   Longley]
Peter Patel-Schneider:  greg reynolds said this directly: as far
   as i can see, JSON-LD is throwing RDF under the bus [scribe
   assist by Dave Longley]
Manu Sporny:  I think that's hyperbolic [scribe assist by Dave
   Longley]
Manu Sporny:  saying that anyone here is trying to throw RDF
   under the bus is hyperbolic, we're both trying to accomplish the
   same thing [scribe assist by Dave Longley]
Peter Patel-Schneider:  I don't think we are. If you look at
   jsonld.org, where is RDF? [scribe assist by Dave Longley]
Manu Sporny:  what benefit is there for putting RDF on the front
   page? [scribe assist by Dave Longley]
Peter Patel-Schneider:  the whole idea behind JSON-LD is to not
   be RDF [scribe assist by Dave Longley]
Manu Sporny:  That assertion is just not true. [scribe assist by
   Dave Longley]
Peter Patel-Schneider:  look at your shiny new car in the show
   case, where is RDF? [scribe assist by Dave Longley]
Gregg Kellogg:  schema.org is also firmly based on RDF, but
   doesn't say anything about RDF...
Peter Patel-Schneider:  They don't talk about RDF, so it's not
   based on RDF. And they're not trying to get a W3C REC through.
Gregg Kellogg:  I think the point that we should be publishing
   something that is closely associated with RDF since we're going
   through the RDF WG is important to note.
Peter Patel-Schneider:  You're completely off the rails - that's
   ridiculous - a spec coming out of W3C should be based upon other
   W3C recs, not closely associated with them.
Gregg Kellogg:  I believe that the JSON-LD spec accomplishes
   that. I think it does that in the appendixes. That's the intent
   that I've understood so far.
Peter Patel-Schneider:  As far as I can see, the JSON-LD
   community has not referenced the W3C specs at all, they've gone
   out of their way to not talk about RDF.
Peter Patel-Schneider:  We have to take the tender sensibilities
   of JSON-LD authors out of the equation.
Peter Patel-Schneider:  I think we have to make the relationship
   crystal clear between JSON-LD and RDF.
Peter Patel-Schneider:  The references are buried, they're hard
   to find out... theyve been denegrated, downplayed, deemphasized,
   they've been de-everythinged.
Markus Lanthaler:  I don't think putting a reference in anywhere
   is a hard requirement.
Manu Sporny:  We have this text in the document in every
   introductory section:
Developers that require any of the facilities listed above or
   need to serialize an RDF graph or dataset [RDF11-CONCEPTS] in a
   JSON-based syntax will find JSON-LD of interest.
Software developers who want to generate or consume Linked Data,
   an RDF graph, or an RDF Dataset in a JSON syntax
Usable as RDF- JSON-LD was designed to be usable by developers as
   idiomatic JSON, with no need to understand RDF [RDF11-CONCEPTS].
   However, JSON-LD was also designed to be usable as RDF, so people
   intending to use JSON-LD with RDF tools will find it can be used
   like any other RDF syntax. Complete details of how JSON-LD
   relates to RDF are in C. Relationship to RDF.
Peter Patel-Schneider:  In every single case, you push RDF under
   the bus.
Dave Longley: "However, JSON-LD was also designed to be usable as
   RDF, so people intending to use JSON-LD with RDF tools will find
   it can be used like any other RDF syntax."
Dave Longley:  You're making empirical claims... we can see text
   in the spec that disproves those claims.
Dave Longley:  Maybe you would like the language to be different,
   do you want to focus on that?
Peter Patel-Schneider:  There is no notion that JSON-LD is based
   on RDF.
Manu Sporny:  There are multiple pieces of normative text in the
   specification that link JSON-LD to RDF.
Peter Patel-Schneider:  It seems like it's incidental.
Gregg Kellogg:  That's a fair criticism.
Manu Sporny:  I don't think it's a fair criticism (it's
   hyperbolic).
Gregg Kellogg:  I think that what Peter is saying is that we need
   to call out the cultural heritage of JSON-LD ... that is RDF.
Peter Patel-Schneider:  I think you should take Gregg Reynolds
   comment... that's the danger... that his comments will prevail.
   To put it in pragmatic terms, the danger to you is that Gregg is
   correct and what he claims will come to pass.
Dave Longley:  I think a lot of his confusion is that a mapping
   to RDF is in a separate document.
Peter Patel-Schneider:  Perhaps one could follow all of the links
   through and come up with all of the links between JSON-LD and
   RDF, but they're well hidden.
Peter Patel-Schneider:  As far as I'm concerned, the only thing
   that's worthwhile talking about is the proposal for Appendix A.
David Booth: Anyone have a link to Peter's comments?
Niklas Lindström:
   http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0126.html
Peter Patel-Schneider:  The technical meat of this proposal is to
   change Appendix A - the data model - to start out by pointing to
   genesis of Linked Data, and talk about the difference between
   syntax of JSON-LD and data model - say bluntly, the data model of
   JSON-LD is RDF datasets as defined by RDF 1.1 concepts.
Peter Patel-Schneider:  You have to talk about JSON data values
   and come up with a story about how they relate to data values.
Peter Patel-Schneider:  The other point of contention is lists -
   say that a list translates into an RDF list, basically.
Peter Patel-Schneider:  If stuff is in a JSON-LD document that
   doesn't translate into an RDF dataset, then it's only meaning is
   to mediate translation.
Manu Sporny:  What do you mean by 'mediate'?
Peter Patel-Schneider:  Things that don't get changed into RDF
   get ignored... a lot of them end up affecting the generation of
   the graph that underlies the JSON-LD document.
Peter Patel-Schneider:  They have meaning, but their meaning is
   to 'mediate the formation of the underlying graph'.
Peter Patel-Schneider:  It's the same disclaimer as there is now
   before.
David Booth: aren't there ways to finesse those spec dependencies
   of one spec on another spec that is not quite finished?
Manu Sporny:  We might be held up due to RDF 1.1 COncepts.
David Booth:  Are you suggesting removing the parallel RDF data
   model? Or are you saying that you want to change how the JSON-LD
   model is described.
Peter Patel-Schneider:  I'm suggesting removing the parallel
   model.
David Booth:  I would be happier with that as well. I had
   resigned myself to assuming that it would be too much work to do.
Dave Longley:  Wouldn't it be sufficient to say that the JSON-LD
   data model is based on the RDF data model. Removing the word
   "JSON-LD data model" wouldn't do much.
Dave Longley:  We need to name the "changes to RDF" as the
   "JSON-LD data model".
Dave Longley:  I think the big problem is that the JSON-LD data
   model doesn't say it's based on the RDF data model.
Manu Sporny:  outlines proposal for RDF data model / JSON-LD data
   model
Peter Patel-Schneider:  There is a taste of bad faith on both
   sides? Maybe naievity on one side.
Peter Patel-Schneider:  One would be complete technical
   alignment... the other would be ...
Manu Sporny:  What about JSON-LD data model is the RDF data
   model.
Peter Patel-Schneider:  No
Gregg Kellogg:  What about 'extension of'? I don't understand how
   we make the JSON data model lines up with the RDF data model?
Peter Patel-Schneider:  What really is JSON? Isn't that the
   issue. There are multiple places where one can come up with what
   the definition of JSON.
Peter Patel-Schneider:  The one at json.org points to the ECMA
   definition - in that definition, it states bluntly that
   JavaScript has IEEE numbers, if one went that way, JSON numbers
   are compatible with xsd:double - would that work? That's /a/
   spec.
Peter Patel-Schneider:  The one you guys point to is a different
   spec. It also really only mentions syntax.
Peter Patel-Schneider:  In a certain strong sense, JSON numbers
   are IEEE doubles, accept no substitutes. They are completely
   compatible with xsd:double.
Manu Sporny:  no, that's not the reality.
Peter Patel-Schneider:  Implementations deviate from the spec in
   a very weird, implementation dependent way.
Peter Patel-Schneider:  If it's representable as an integer, then
   it's an integer, if not, it's a double.
Peter Patel-Schneider:  The first one allows 1.0 to b e an
   integer... the second is what many languages do... '1' is an
   integer, '1.0' is a double.
Peter Patel-Schneider:  Even if you do this, you can be
   completely compatible with languages and xsd:datatypes.
Peter Patel-Schneider:  Integers are unbounded, etc. etc.
Peter Patel-Schneider:  There is no implementation that can
   implement 'google' as an integer.
Peter Patel-Schneider:  Implementations can't implement these
   things.
Peter Patel-Schneider:  language tag strings are short-hand for
   the longer version.
Dave Longley: xsd:integer is unbounded
Dave Longley:  we can just define "the JSON-LD data model" as an
   extended RDF graph w/1 extension for bnodes as predicates [scribe
   assist by Dave Longley]
Dave Longley: then use that term throughout the document.
Peter Patel-Schneider:  I think bnodes as properties will happen,
   if it doesn't say it's an extension.
Peter Patel-Schneider:  JSON lists are shorthand for the
   appropriate RDF lists.
Gregg Kellogg:  I don't think we have any issues with lists...
   they're identical to RDF lists.
Gregg Kellogg:  I don't think there is a point in suggesting that
   they're different.
David Booth:  I think this set vs. list can be done in RDF as
   well - it's not standardized.
Peter Patel-Schneider:  There is no standard facility to do this
   in RDF.
Gregg Kellogg:  I think what we're doing in JSON-LD is identical
   to what we're doing in RDF. I think the JSON-LD case varies from
   that.
Niklas Lindström:  That's not the intent either... We represent
   RDF lists and we represent repeated statements. That's what
   JSON-LD models.
Manu Sporny:  Ok, so here are the editorial changes we could
   make: We could say explicitly that the model that JSON-LD uses is
   an extensio of RDF Datasets in Appendix A. Just come right out
   and say that. Rename the "JSON-LD Data Model" to just "Data
   Model" in the spec so that there is no confusion that JSON-LD has
   a different data model (even though the devil is in the details).
   We'll work out how to specify JSON numbers, lists, and blank
   nodes as predicates such that they align w/ the RDF data model or
   are extensions of it without calling those extensions the JSON-LD
   data model.
Gregg Kellogg:  I think the text makes it confusing that we don't
   align with RDF data model to the point of not talking about the
   JSON-LD data model. I think the JSON-LD data model might point as
   a way of indirection.
Dave Longley:  I think that we can define the RDF dataset as the
   JSON-LD data model.
Dave Longley:  I think we can be clear about the deifnition -
   it's an extended RDF Dataset...
Niklas Lindström:  I think there is a slight problem - if the
   term becomes so ingrained, it might take on a life on it's own.
Manu Sporny:  Ok, so the plan is for the editors to try to
   implement the changes outlined above. We won't get it right in
   the first pass, it'll need multiple passes and reviews by Peter
   and David Booth. Once we settle on something that all of us are
   happy with, we'll have a proposal to adopt the spec text.
David Booth:  I would like us to take this approach to alignment,
   skolemization might be moot based on this approach.
David Booth:  Blank nodes as predicates - important to outline in
   the spec what happens if the RDF WG doesn't adopt that.
David Booth:  Two different processors need to be interoperable.
Markus Lanthaler: bnodes-as-predicates are explicitely out of
   scope: http://www.w3.org/2011/01/rdf-wg-charter
David Booth:  If there is a chance that RDF will adopt blank
   nodes as predicates / graphs, then we can align.
David Booth:  We should either say the triple gets dropped or
   gets skolemized.

Topic: ISSUE-257: Blank node identifers for data types

https://github.com/json-ld/json-ld.org/issues/257
Markus Lanthaler:  There is an inconsistency in the spec - you
   can't use a bnode as a datatype if you use it in the document.
   You can do it if you do it in the context.
Markus Lanthaler:  There are two proposals
PROPOSAL 1: Do not support blank nodes as data types.
PROPOSAL 2: Raise an error if a blank-node-typed literal is
   detected.
Manu Sporny:  Any preferences on these proposal.
Gregg Kellogg:  The proposals support each other.
Gregg Kellogg:  this is a consequence of allowing bnodes in that
   position, syntactically.
Dave Longley:  We're deviating from a generalization that we
   could apply everywhere - why not just be general everywhere, why
   make special exceptions?
Dave Longley:  We can revisit this later if there is a use case.
   Let's keep the generalization everywhere.
Gregg Kellogg:  I think this would be a reasonable thing for RDF
   COncepts to do. Otherwise, we're creating differences that no one
   is mandating because it falls out of a consistency of approach in
   transforming documents.
Gregg Kellogg:  I don't think N3 allows blank node datatypes, but
   it does allow blank node properties.
Markus Lanthaler:  I would prefer to keep the generalization,
   doesn't make sense to fight for that now.
Manu Sporny:  Do we have a use case for this? ANyone ever seen
   this sort of markup in the wild?
Markus Lanthaler:  I don't think so.
Dave Longley:  It seems like if you wanted to just have types in
   your local document, that's a use case.
Manu Sporny:  The only use case I can think where that would be
   used is some sort of strange linguistics use case where you want
   to specify datatypes within the document that should not be known
   to the world. It's a starnge use case, nobody is asking for it,
   if we need it we can put it in later, if if put it in, there will
   be a big fight in the RDF WG.

PROPOSAL: Do not support blank nodes as data types.

Gregg Kellogg: +1
Manu Sporny: +1
Clay Wells: +1
Dave Longley: +0.5
Markus Lanthaler: +1

RESOLUTION: Do not support blank nodes as data types.

PROPOSAL: Raise an error if a blank-node-typed literal is
   detected.

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Clay Wells: +1
Dave Longley: +0.5

RESOLUTION: Raise an error if a blank-node-typed literal is
   detected.

Gregg Kellogg:  There is a test case that fails because of this.
Markus Lanthaler:  Spec changes should be minimal.
Gregg Kellogg: expand-0049-in.jsonld will have to be corrected,
   will take that discussion offline and make the change.

Topic: ISSUE-264: JsonLdUrlDereferencer option

https://github.com/json-ld/json-ld.org/issues/264
Manu Sporny:  When we discussed URL dereferencing previously, the
   intent was to have the feature as a generalized solution.
   Unfortunately, the implementation of that intent in the spec made
   it too specific to dereferencing contexts. We should fix that.
Markus Lanthaler:  bug fix?
Dave Longley:  yes.
Group agrees that this was the intent and this is a bug fix.

PROPOSAL: Generalize the LoadContextCallback feature into a
   LoadDocumentCallback feature and use it for loading both remote
   contexts and remote documents when necessary.

Dave Longley: +1
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +1

RESOLUTION: Generalize the LoadContextCallback feature into a
   LoadDocumentCallback feature and use it for loading both remote
   contexts and remote documents when necessary.

Niklas Lindström: +1 for all proposals above
Dave Longley:  We might need to discuss how to prevent endless
   references.
Manu Sporny:  I thought we must not continue to fetch contexts.
Dave Longley:  We might say that you should use
   application/ld+json for the link header.
Dave Longley:  If you request application/ld+json - you should
   not follow any links.
Dave Longley:  The callback goes out to the URL and fetches the
   document... if the HTTP Link header in it, it follow the Link
   Header and provides the document and the context that was
   fetched.
Dave Longley:  That's what comes back as the future value...
Dave Longley:  If you encounter a Link Header that is a JSON-LD
   remote context that has application/json - it's invalid.
Dave Longley:
   http://json-ld.org/spec/latest/json-ld/#interpreting-json-as-json-ld
Dave Longley:  if we look up what a Link Header looks like, the
   type parameter
Markus Lanthaler:  That doesn't tell you much, it's just a hint,
   you can ignore that.
Dave Longley:  If you can ignore that, we need to tell
   implementations what to do if you can ignore that.
Markus Lanthaler:  I think the important thing is what the
   content type is... if the content type is [scribe missed]
Markus Lanthaler:  If you get the document, you get the document
   plus the link header. If you're trying to dereference the
   context, you would get back application/ld+json.
Dave Longley:  That's not true, you don't know that for sure.
   Their server might not do application/ld+json.
Markus Lanthaler:  You'd like to interpret it as a context?
Dave Longley:  I don't have a strong preference, we need to tell
   implementations what to do.
Markus Lanthaler:  I agree, wondering how we should do that.
Markus Lanthaler:  Do we need a flag to tell the callback what it
   should look for? We could provide a flag to the callback, the
   callback should follow one link header. That way, the callback
   doesn't have to know anything about it.
Markus Lanthaler:  I don't think the callback does that - it just
   returns the callback?
Dave Longley:  We have to return back the link header information
   in the result of the callback.
Markus Lanthaler:  RIght, isn't that what was proposed?
Dave Longley:  No, I think we need to return back the document
   and the context... we need to separate concerns here. Your
   callback might not go onto the network, it might get something
   from a cache.
Markus Lanthaler:  A remote context dictionary returns the result
   of the context... remote document is the change - doc and
   context.
Dave Longley:  The callback would give you the doc and context...
   the processor decides what it should do.
Markus Lanthaler:  Wouldn't it be simpler if we return the link?
Dave Longley:  That's an option... give back a Context URL
   instead of a context.
Manu Sporny:  Not sure we have a specific proposal yet.
Markus Lanthaler:  Ok, let's go back to the issue tracker and
   figure it out there.

Topic: JSON-LD introduction

Dave Longley:  I'm going to paste some text in here - Peter had
   some complaints about the introduction.
Dave Longley: circling back to Peter's comments, perhaps this fix
   to the intro would help as well - "JSON-LD was designed to be
   usable by developers as idiomatic JSON, with no need to
   understand RDF [RDF11-CONCEPTS]. However, JSON-LD was also
   designed to be usable as RDF, so people intending to use JSON-LD
   with RDF tools will find it can be used like any other RDF
   syntax." to "JSON-LD was designed to be usable as both idiomatic
   JSON and as RDF. Developers have no need to understand RDF to use
   JSON-LD, but those intending to use RDF tools will find that
   JSON-LD is used just like any other RDF syntax."
Gregg Kellogg:  What do we want to communicate in there?
Gregg Kellogg:  We're trying to keep RDF at a distance - don't
   worry about what's behind the curtain.
Gregg Kellogg:  By not saying that JSON-LD is RDF, we're throwing
   RDF under the bus. The point is that we can say "X has a strong
   theoretical basis"... we should be able to say the same about
   RDF.
Gregg Kellogg:  It is built on top of RDF, but it's done in a
   simple way.
Clay Wells: why even mention "there's no need to understand RDF"
   at all.. just something to think about.
Dave Longley: we want people to know there isn't a steep learning
   curve
Clay Wells: couldn't that be implied?
Dave Longley: if we can imply it without saying it, yeah, that
   would be preferable.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 25 June 2013 17:41:22 UTC