Manu Sporny: Any updates or changes to the agenda?

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:

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.

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

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.

Gregg Kellogg: +1

Manu Sporny: +1

Clay Wells: +1

Dave Longley: +0.5

Markus Lanthaler: +1

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

Clay Wells: +1

Dave Longley: +0.5

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.

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.

Dave Longley: +1

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

David I. Lehn: +1

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.

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.