Gregg Kellogg: I think he's not entirely satisfied to define JSON-LD as an RDF syntax. In particular, we were going to normatively reference RDF Concepts.
Gregg Kellogg: I think he was looking for something like that, and a series of other suggestions, including referencing RDF when we're describing Linked Data.
Manu Sporny: It's been difficult for me to understand what he wants, exactly. Many of his points are philosophical vs. technical. In general, I don't see what technical problems we address by making the changes he is requesting.
Gregg Kellogg: He's got some very specific changes in the e-mail. Some of his concerns I don't quite understand.
Dave Longley: yeah, let's go down the list he has, maybe that will help.
1. Insert "based on RDF" to the definition of Linked Data, as explained above.
Dave Longley: This is at odds with all of the other discussions we've had. Maybe there is another way to satisfy #1 w/o deviating with all of the other fixes we've had to do w/ that definition.
Manu Sporny: Yeah, we have a problem with #1 - we've worked on that definition a lot. We have considered the text he wants before. If we add it, they'll be backlash from the folks that didn't want to conflate Linked Data with RDF.
Manu Sporny: Making a normative reference to RDF Concepts would be problematic - going to REC at a different time than JSON-LD.
Gregg Kellogg: I thought we had agreed to do that?
Manu Sporny: I don't think we agreed to do that - we don't want to be blocked by RDF Concepts.
Manu Sporny: My general concern with david booth's comments are that he's taking a hard line stance with JSON-LD having to fall in line with RDF ... in that his arguments seem to be philosophical arguments, not technical, it's more about messaging. I don't want to get this group stuck in the mud when the changes to the spec that are mostly philosophical, not technical, in nature. [scribe assist by Dave Longley]
Gregg Kellogg: What about the skolemization concerns? Those are technical, right?
Gregg Kellogg: The other place would be bnodes as properties.
Manu Sporny: I thought those issues were things that processors need to deal with those sorts of things when translating to RDF.
Gregg Kellogg: I think David Wood wants this to be a WG resolution.
Manu Sporny: So, JSON-LD CG has made these resolutions, we need RDF WG to do the same.
Manu Sporny: I'm concerned that we are going to work on these secondary issues, thinking that it's what David Booth wants, and they're not going to resolve David Booth's concerns.
Gregg Kellogg: Then we should point to the decision on the Linked Data definition. If he still doesn't agree, we need a papertrail to validate the decision that we've made in the event that there is a Formal Objection to the definition of Linked Data.
Manu Sporny: Does anybody want to include RDF language in the introduction?
Luca Matteis: Why not have intro on RDF? Seem the lingua franca of Linked Data. Yes, I think there should.
Dave Longley: We already had this discussion - let's point to it.
Dave Longley: Luca, we already had a long discussion about this a while back... we're going to link to that discussion
Gregg Kellogg: The issue of whether RDF Concepts is normative/informative was something that I thought we had resolved to do that.
Luca Matteis: ok but what's the outcome of that discussion?
Dave Longley: Luca, the outcome of that discussion was to mention RDF a little as possible to avoid bringing in baggage/false equivalency/conflation of RDF w/Linked Data
Luca Matteis: If you're calling it Linked Data, seems weird not to have RDF - since LD is strictly about RDF
Gregg Kellogg: Regarding our use of bnodes - which could have been resolved w/ the RDF WG to have bnodes in graphs, we need a resolution on this as well from the RDF WG.
Dave Longley: Luca, that's just it, it's not strictly about RDF, we'll link to the discussion.
Dave Longley: Luca, no, but we do think it's important to mention JSON-LD is a syntax for RDF
2. Define a *normative* bi-directional mapping of a JSON profile to and from the RDF abstract syntax, so that the JSON profile *is* a serialization of RDF, and is fully grounded in the RDF data model and semantics.
Dave Longley: Luca, Linked Data is just URI/URLs for identifiers that can be dereferenced to get more data, etc.
Gregg Kellogg: The only issue there is the ability to create things that are not RDF, for which these are at-risk issues.
Luca Matteis: Yikes. Dave, that's just the Web.
Dave Longley: Luca, it's a bit "higher level" than RDF
Manu Sporny: We have a normative mapping, does he want something more?
Gregg Kellogg: We do have a mapping, but it allows graphs that are not RDF to be created. These features are at-risk that relates to that, and the RDF WG needs to resolve those at-risk features.
Gregg Kellogg: It leaves open the resolution of those at risk features.
Dave Longley: i doubt that it's "high level". the Linked Data Platform strictly mentions RDF. [scribe assist by Luca Matteis]
3. Use skolemized URIs in the normative mapping to prevent mapping JSON syntax to illegal RDF.
Luca Matteis: alright well i don't wanna jump into the argument
Luca Matteis: but it seems like a rash decision to not mention RDF - the foundation of LD
Gregg Kellogg: My concern with this is that skolemized URIs are for a server to do - it's not meant for encoding/transport bnodes between two different systems. I don't see skolemn IDs as being appropriate for doing that.
Manu Sporny: I agree.
4. Make editorial changes to avoid implying that JSON-LD is not RDF. For example, change "Convert to RDF" to "Convert to Turtle" or perhaps "Convert to RDF Abstract Syntax".
Dave Longley: Luca, we had a very detailed debate about this a while back... we'll have to link to it, there were objections over what "LD" means/should mean/how it shouldn't be conflated with RDF itself but how RDF relates to it, etc.
Dave Longley: Luca, can't rehash right now.
Luca Matteis: hrm ok
Gregg Kellogg: I think this is reasonable since it implies it's not already RDF, that's not intended to be the case.
Luca Matteis: would be nice to share the outcomes with a larger audience though before making a decision that could impact this formats future, such as public-lod@w3.org
Manu Sporny: yeah, change to "Convert to RDF Abstract Syntax"?
Dave Longley: Yeah, let's do that.
Dave Longley: Luca, it shouldn't technically have any impact.
Gregg Kellogg: Luca, typically, rdf-concepts is used for communicating discussions within the RDF WG to the outside community.
5. Define normative names for, and clearly differentiate between, the JSON serialization of RDF and JSON-LD, such that JSON-LD *is* a JSON serialization of RDF, with additional constraints for Linked Data (such as URIs use "http:" prefix, etc.). They do not necessarily have to be defined in two separate documents. They could be defined in a single document called "JSON-RDF and JSON-LD", for example. People that use the JSON RDF serialization for purposes other than Linked Data need to be able to easily and clearly talk about that serialization *without* wrongly implying adherence to the additional Linked Data requirements imposed by JSON-LD, and *without* having to explain that those requirements can be ignored in this case.
Dave Longley: Luca, it's all about messaging/philosophy/etc. (or rather, the actual technical impact is meant to be minimal)
Luca Matteis: the initial question was whether to have intro text about RDF.
Luca Matteis: it's not technical i know
Luca Matteis: but why not?
Luca Matteis: why not have intro about RDF?
Luca Matteis: or just mention RDF
Luca Matteis: it's RDF compatible... it's only positive!
Manu Sporny: Luca, You are distracting the group from talking about the things on the Agenda. We have already talked this issue to death. Telecon time is precious, please take this up after the telecon, and after reading about the previous discussions we've had on the topic.
Luca Matteis: I can't join the conversation anymore. guess I was banened? ;)
Manu Sporny: Luca, no, you're not banned. You're free to participate at any time, you just have to be respectful to the time of the group and not re-raise issues that have been resolved without providing new arguments that we had not previously considered.
Dave Longley: I think he's taking issue w/ the SHOULDs
Dave Longley: I don't see why this doesn't cover his issue...
Clay Wells: yes, what you just said
Dave Longley: I think he means that there should be some basic serialization of RDF in JSON - pure RDF in JSON.
Clay Wells: makes sense from my perspective
Gregg Kellogg: This doesn't accomplish anything, it's busy work.
Dave Longley: We don't prohibit people from using the subset, we don't do that anywhere in the spec, so it already exists. It's easier for people to consume/understand than if there are two different formats. Which format are you supposed to use as a newbie?
Dave Longley: Is the JSON-LD format always JSON-RDF, what's the subset? It would be more confusing to publish two different syntaxes.
Manu Sporny: Agreed.
Dave Longley: Someone was worried about having to ask for a specific kind of data that is serialized. So the client would have to say "I want JSON-LD, but with particular restraints."
Dave Longley: I don't even know if this would solve this problem if JSON-RDF is a subset of JSON-LD.
Dave Longley: I don't understand how David Booth's #5 proposal solves any technical issue.
Gregg Kellogg: There is a big problem with bifurcation of the spec as well. Some processors may decide to do one and not the other.
Gregg Kellogg: If we did that for RDFa 1.1 Lite, it would've been a big problem.
Dave Longley: Do we want to create another mimetype? I don't see how what David Booth's proposing is a better solution.
Manu Sporny: What about his editorial changes?
Dave Longley: We want to get the concept across that any JSON document can be Linked Data via JSON-LD... but you don't need to move all your data over all at once.
Dave Longley: maybe we need to change that entire sentence... something like "JSON-LD allows you to mark parts of your JSON as Linked Data"... or something like that.
ACTION: Manu to officially respond to David Booth.
Gregg Kellogg: Markus' response was that we were using SHOULD language, requests are advisory to the server. If the server doesn't have it, it could return a "similar" format.
HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent capabilities and user preferences: Accept (section 14.1), Accept- Charset (section 14.2), Accept-Encoding (section 14.3), Accept- Language (section 14.4), and User-Agent (section 14.43). However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including ...
Stian Soiland-Reyes: ... information outside the request-header fields or within extension header fields not defined by this specification.
Group discusses modifying the text in the JSON-LD spec to: "The profile parameter MAY be used by clients to express their preferences in the content negotiation process. If the profile parameter is given a server SHOULD return a document that is structured based on the profiles in the list which are recognized by the server."
Dave Longley: "If the profile parameter is given, " <-- insert comma
PROPOSAL: Adopt the language for content negotiation above where the server should try to comply with the request MIME type and profile from the client.
Manu Sporny: +1
Dave Longley: +1
Paul Kuykendall: +1
Gregg Kellogg: +1
Stian Soiland-Reyes: +1
RESOLUTION: Adopt the language for content negotiation above where the server should try to comply with the request MIME type and profile from the client.
Topic: Gmail JSON-LD Implementation Concerns
Manu Sporny: Google has added JSON-LD support to Gmail, Search, and Google Now. I blogged about it here:
Gregg Kellogg: The main issue is that that they've used 'schema.org' instead of a valid @context. We could support it, but it's not clear why they chose to do that as adding http:// to the front of schema.org seems like a fairly easy thing to do.
Stian Soiland-Reyes: they manage http:// in the microdata-version
Gregg Kellogg: It's often difficult for them to be consistent with marking things up - they're used to using heuristics for data that's provided for them. Maybe that's why they did this?
Gregg Kellogg: We could hack in the same sort of heuristics to the spec... if you type see "schema.org" - the developer probably meant http://schema.org/
Gregg Kellogg: Then there is this relative URI concern, how do we support this?
Manu Sporny: We could do something like the RDFa initial context for the @context keyword, but again, it's a big hack. This is pretty typical of Google - launch first, ask questions later. It would have been nice if they had run this by us before releasing this sort of thing on developers. It's going to be a decent bit of work for us to clean this up.
Dave Longley: What about the actual JSON-LD context? Do they serve one?
Manu Sporny: Nope. There are plans to do it, but they don't have a timeframe... which is bad, because that means that developers are going to do their own thing in the meantime, leading to incompatabilities.
Dave Longley: The fear is that some people are going to create their own context... we need to talk them and make sure they realize the downsides to what they're doing.
Gregg Kellogg: The fact that Google is adopting this so broadly, alleviates some of the concerns we had about turning developers off from JSON-LD being too much like RDF. Developers will be interested in it because Google is using it.
Manu Sporny: We hope to have someone from Google on the call next week to discuss these issues.
Topic: RDF WG resolutions
Gregg Kellogg: What do we want to accomplish there?
Manu Sporny: Anything that has an issue marker in the JSON-LD specs needs to have a final resolution in the RDF WG. Do you mind taking that work on, Gregg?
Gregg Kellogg: Sure.
ACTION: Gregg to convert all issue markers in the JSON-LD specs into RDF WG issues and request that the RDF WG resolves the issues so that we can go to CR/PR/REC.