- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 25 Jun 2013 13:40:58 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
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:24 UTC