- From: David Booth <david@dbooth.org>
- Date: Tue, 21 May 2013 09:38:27 -0400
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: public-rdf-comments@w3.org
Hi Manu, What is the status of these comments? I have not received any official response to them and I see nothing listed on the RDF issues list for them -- either open or closed: http://www.w3.org/2011/rdf-wg/track/issues Are these being tracked somewhere else? Are they scheduled to be addressed later? Also, one other point came to my attention since submitting those comments: - I notice that the RDF working group charter specifically *requires* that JSON-LD be a syntax for RDF. Under "Required features", section 2.2 states: http://www.w3.org/2010/09/rdf-wg-charter.html#turtle "Define and standardize a JSON Syntax for RDF". To be blunt, JSON-LD is not a "syntax for RDF" unless it is *normatively* based on the RDF semantics. Otherwise, it has no more official status as a "syntax for RDF" than any other format -- XML, CSV or whatever -- that *could* be mapped to RDF by someone's favorite mapping. So apparently my comments below accord with the charter. Thanks, David On 04/24/2013 10:52 AM, David Booth wrote: > Hi Manu, > > Thanks for your remarks. I don't agree with all of them, and just for > completeness I'll note in-line below which ones and why, but rather than > focus on those details I think it would be better to discuss this at a > higher level, because you brought up a very interest point about > potentially skolemizing blank nodes, and I think that raises the > possibility of a different path for addressing the issue that JSON-LD > should be an RDF syntax. > > To my mind, the central problem that needs to be addressed is that, at > present, the draft of JSON-LD > http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld/index.html > > reads as an attempt to divorce Linked Data (and JSON-LD) from RDF. This > is evidenced in several places throughout the document. For example, > the definition of Linked Data in the introduction fails to mention RDF > at all: > [[ > Linked Data is a technique for creating a network of inter-connected > data across different documents and Web sites. In general, Linked Data > has four properties: 1) it uses IRIs to name things; 2) it uses HTTP > IRIs for those names; 3) the name IRIs, when dereferenced, provide more > information about the thing; and 4) the data expresses links to data on > other Web sites. > ]] > > I suggest fixing that omission by inserting the words "based on RDF" > into the first sentence, to read: "Linked Data is a technique, based on > RDF, for creating a network of inter-connected data across different > documents and Web sites." > > The same sentiment of divorcing JSON-LD from RDF is evidenced in other > places in the document as well, such as in phrases like "converted to > RDF", and in the definition of a JSON-LD data model that is completely > separate from the standard RDF data model, complete with parallel terms > such a "blank node" and "blank node identifier". Left as is, the world > would have parallel and competing standards for Linked Data: those based > on JSON-LD and its data model, blank nodes, etc., and those based on RDF > and its data model, blank nodes, etc., because JSON-LD is *not* RDF. > > One might claim that JSON-LD *can* be used as a serialization of RDF, > and therefore JSON-LD *is* already based on RDF. But that argument does > not hold water, because that same claim can be made of *any* language! > *Any* language can be viewed as a serialization of RDF, given an > appropriate mapping. Indeed, the whole purpose of GRDDL was to enable > such mappings to be easily defined from XML and HTML. Many people have > defined mappings from CSV to RDF, and from many other things to RDF. We > do not need a JSON syntax that *can* be mapped to RDF. We need a JSON > syntax that *is* a standard serialization of RDF, based on the RDF data > model and RDF semantics -- not a parallel (but subtly different) data > model, terminology and semantics. JSON-LD at present defines a > parallel universe that looks confusingly similar to RDF -- even > co-opting terms such as "blank node". > > I am sympathetic to -- and fully support -- the goal of making JSON-LD > easy for people to use, **without knowing anything more about RDF than > what they learn about JSON-LD,**. But I also think it is critical that > JSON-LD still be normatively based on RDF and grounded in the RDF data > model and semantics. And I think it is also pretty clear in the charter > http://www.w3.org/2012/ldp/charter > that the work of the group was intended to be **based on RDF** -- not > "inspired by RDF" or "similar to RDF" or "addressing the same goals as > RDF". In other words, the LD working group should define a JSON-based > "RDF serialization syntax", as the charter calls it. > > Can the group achieve both of these aims? I think so. And I think one > way to achieve it would be to define a normative mapping between the > JSON syntax and the RDF abstract syntax, by using skolemization in > places where prohibited blank nodes would otherwise appear, such as in > the predicate position of an RDF triple. > > Specific suggestions: > > 1. Insert "based on RDF" to the definition of Linked Data, as explained > above. > > 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. > > 3. Use skolemized URIs in the normative mapping to prevent mapping JSON > syntax to illegal RDF. > > 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". > > 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. > > If there is one thing we all should have learned from the Semantic Web, > it is the value of assigning an unambiguous name to every important > concept. A JSON serialization of RDF is a *very* important concept and > deserves its own unambiguous name, distinct from JSON-LD. > > BTW, regarding the name "JSON-RDF", when I first read your response at > http://lists.w3.org/Archives/Public/public-rdf-comments/2013Mar/0036.html > saying "We couldn't use JSON-RDF because a variation on the name was > already taken", I assumed you meant that RDF/JSON was a defunct > proposal, and I was going to suggest that if it is defunct, then there > would be little harm in noting it as defunct, and using the term > "JSON-RDF". But when I view the RDF/JSON document now at > https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html# > I see it is dated "24 April 2013" and it says that is is a product of > the RDF working group. So what's going on? Why is the W3C > standardizing *two* potential JSON serializations of RDF? How are they > related or different? If this is a W3C activity then these activities > should be coordinated, *one* should be picked -- that's what standards > are for -- and the name JSON-RDF can be used for that one. > > 6. Some small editorial fixes: > > "Since JSON-LD is 100% compatible with JSON" would be better phrased as > "Since JSON-LD is a restricted form of JSON", because saying that > JSON-LD is compatible with JSON wrongly suggests that JSON-LD is *not* > JSON, when in fact it is. > > s/secrete agents/secret agents/ > > Thanks, > David Booth > > > On 04/09/2013 09:59 AM, Manu Sporny wrote: >> Apologies for the delayed response David, been slammed, responses to >> your responses below... >> >> On 03/26/2013 04:22 PM, David Booth wrote: >>>> In JSON-LD graph names can be IRIs or blank nodes whereas in RDF >>>> graph names have to be IRIs. >>> >>> Blank nodes already cause more grief than any other RDF feature. I >>> do not think it makes sense to promote or condone the expansion of >>> their use. Where are the compelling use cases for this? >> >> In JSON, there are implicit blank nodes everywhere, both as predicates, >> and as subject identifiers. So, the compelling use case is interpreting >> JSON as RDF. The other major compelling use case is to not require JSON >> developers to change their workflow by forcing them to give everything >> an IRI identifier. >> >> You may not know this, but I took your exact position when designing >> JSON-LD. The first version of JSON-LD did not support blank nodes and I >> took a pretty hard line stance because of the complexity that they >> introduce. However, experience showed us that this was the wrong >> position to take. There are many cases that we've hit during the >> development of JSON-LD where it became pretty obvious that having blank >> nodes would simplify the markup for the vast majority of Web developers. > > I guess I was not clear enough. I was specifically talking about the > use of blank nodes as graph names -- not uses of blank nodes that are > permitted in RDF. > >> >>>> In JSON-LD properties can be IRIs or blank nodes whereas in RDF >>>> properties (predicates) have to be IRIs. >>> >>> Ditto. Blank nodes already cause more grief than any other RDF >>> feature. I do not think it makes sense to promote or condone the >>> expansion of their use. Where are the compelling use cases for >>> this? >> >> See above. > > Again, I guess I was not clear enough. I was specifically talking about > the use of blank nodes as properties -- not uses of blank nodes that are > permitted in RDF. > >> >>>> In JSON-LD lists are part of the data model whereas in RDF they are >>>> part of a vocabulary, namely [RDF-SCHEMA]. >>> >>> That would make JSON-LD *not* be a superset of RDF. While I agree >>> with the goal of making lists easier to use in RDF -- I think that >>> would be great -- I think it is important not to deviate from the RDF >>> model. >> >> JSON-LD is a super-set of RDF You can still express lists as rdf:first / >> rdf:rest statements in JSON-LD. When you convert JSON-LD native lists to >> RDF, the rdf:first / rdf:rest pattern is used. > > Oh, okay. > >> >>>> The JSON-LD CG felt that these features were compelling enough to >>>> keep them in the specification in the hopes that RDF will >>>> eventually align with the data model. We tried to do this in a way >>>> that was acceptable to the RDF community. >>> >>> But failed "due to the colorful variety of opinions on the matter"? >>> How can you have it both ways, except by acknowledging that this >>> splinters the community? >> >> Both the JSON-LD CG and the RDF WG have agreed on a compromise. If there >> is agreement on the path forward, we are not splintering the community. >> >>>> The other reason that we define a data model in JSON-LD is to make >>>> it easier for developers to pick up on Linked Data concepts without >>>> having to climb the very steep learning curve brought about by >>>> having to read the myriad of RDF specifications. >>> >>> That sounds fine and useful *provided* that JSON-LD is consistent >>> with RDF. At present it isn't. >> >> That's an all-or-nothing strategy. We have opted for a strategy of >> logical compromise and consensus. The consensus has led to a very simple >> to understand data model (JSON-LD) that is a gateway into RDF for Web >> developers. It solves a long-standing problem in the RDF community. > > A conformance strategy *should* be all-or-nothing, or at least as close > to it as it can be. (Though I imagine you think it *is* as close as it > can be!) > >> >>>> What we did find consensus around was to allow JSON-LD to deviate >>>> in very specific ways in an attempt to gain some implementation >>>> insight as to whether or not these extensions to RDF were worth >>>> pursuing in RDF 2.0. >>> >>> Field experience can and should be obtained by *vendor* *extensions* >>> -- not by standardizing N competing RDF-like languages (even if N==2) >>> and letting those standards fight it out in the marketplace. I do >>> not believe that it would be in the best interest of the RDF >>> community or the W3C to fracture the market by standardizing multiple >>> competing RDF-like languages. >> >> RDF isn't a language, it's a data model. > > I disagree, but it is probably immaterial to this discussion. Yes, RDF > is a data model, but it is also a language, expressed in an abstract > syntax. > >> As for the languages, RDF >> already has a variety of syntaxes that have different data models - >> Microdata, N3, JSON-LD. That ship has already sailed, the important >> thing is to make sure that these extensions are created and defined in a >> way that can be folded back into the RDF data model if successful. > > I don't know what you're claiming here, but to my mind that ship has > *not* sailed. Microdata was not intended to be an RDF serialization, > though it can transformed into conforming RDF. But the fact that > something can be transformed into RDF is not saying much, because > *anything* can be transformed into RDF. GRDDL provides a convenient way > to transform XML into RDF, for example. > >> >> For example, the native lists datatype in TURTLE and JSON-LD is now a >> strong indicator that the RDF 2.0 data model should probably have a >> native lists type. >> >>>> JSON-LD is about a JSON serialization for Linked Data. Linked Data >>>> typically asks that IRIs are dereferenceable so that more >>>> information can be gleaned from the identifiers. The spec doesn't, >>>> however, require that all IRIs used in JSON-LD are dereferencable. >>> >>> Apologies, I was not clear. The reason I said that a JSON >>> serialization of RDF should not require IRIs to be dereferenceable -- >>> even as a "SHOULD" requirement -- is because I am distinguishing >>> between a serialization of RDF *in* *general* -- not specifically for >>> Linked Data -- and a serialization of RDF that is intended >>> specifically for Linked Data. As my original comment goes on to say, >>> I think it is important to cleanly layer one spec on another, and >>> there are *many* non-LD RDF uses that would benefit from a JSON >>> serialization of RDF. >> >> I don't see how the JSON-LD specification prevents uses? >> >>>> We couldn't use JSON-RDF because a variation on the name was >>>> already taken: >>> >>> Sorry for being unclear. My point was not so much about the name, >>> but about the concept of defining a JSON serialization of RDF *in* >>> *general* -- not just for Linked Data -- and then defining an LD >>> version on top of that. >> >> We had tried this approach at one point, but the "Linked Data" spec >> ended up being so small that we just folded it back into JSON-LD. There >> was no reason to have a tiny 10 page spec that just modified the >> underlying "JSON-RDF" mechanism by effectively re-writing portions of >> the spec. It would confuse Web developers and create much bouncing about >> between the JSON-RDF and JSON-LD specs. > > A JSON-LD spec should not in any way *modify* the underlying JSON-RDF > spec -- just cleanly layer on top of it. > > I'm not convinced that this "bouncing about" issue could not be > addressed in other ways, such as through tutorials or even automatically > transcluding portions of the JSON-RDF spec in the JSON-LD spec. > >> >>>> What prevents these applications from using JSON-LD? >>> >>> If I have an RDF application, and I want it to accept a JSON >>> serialization of RDF, what must I tell my customers? "It accepts >>> JSON-LD *except* that it does not support the following >>> non-standard-RDF features, ... blah blah blah ... and furthermore the >>> application does *not* expect all of your IRIs to be dereferenceable, >>> because this is merely an RDF application -- not a Linked Data >>> application -- but the W3C did not define a JSON serialization of >>> RDF, so we had to use JSON-LD instead." Fail. >> >> That is an especially atrocious way to communicate with your >> customers. :) >> >> You don't have to tell your customers any of this. You just tell them >> that you accept JSON-LD and if you see a blank node in the graph or >> predicate position, you either use a database that supports that, or you >> skolemize if not. >> >>> It would be far better if I could simply say: "the app accepts >>> JSON-RDF" (where I'm using the term JSON-RDF to mean a JSON >>> serialization of RDF, but I don't really care if it is called >>> "JSON-RDF"). And it would be so easy for the working group to >>> instead simply define a JSON serialization *of* *RDF*, and then >>> define a Linked Data serialization on *top* of that. This would >>> provide a clean layering, a clean separation of concerns: plenty of >>> upside, and almost no downside. >> >> I disagree, we tried this and it ended up being a terrible approach. >> >>>> We had explored this idea very early in the JSON-LD days and came >>>> to the conclusion that JSON developers don't work with their data >>>> in this way. That is, for the vast majority of the in-the-wild JSON >>>> markup we looked at, JSON developers did not use any sort of >>>> triple-based mechanism to work with their data. Rather, they used >>>> JSON objects - simple key-value pairs to work with their data. This >>>> design paradigm was the one that was used for JSON-LD because it >>>> was the one that developers were (and still are) using when they >>>> use JSON. >>> >>> The fact that developers don't use triples is completely irrelevant. >> >> If you think this, you are missing one of the core insights that the >> JSON-LD builds upon. >> >>> Developers are free to use any internal data representation they >>> want when they use RDF -- including hash tables, objects, whatever. >> >> Sure, but most of them just want something that works with their >> language of choice. JSON-LD just works with their language of choice. >> >> A common mistake that many smart developers and designers make is >> assuming that since it's fairly obvious what a proper data >> representation should look like that it's going to be just as obvious to >> most Web developers. The reality is that most Web developers just want >> something that works and don't want to think about the solution too >> deeply because they have a thousand other things related to their >> application that they have to think about. >> >> JSON-LD is about reducing the cognitive load placed on developers that >> want to build a Linked Data application (and effectively use RDF). >> Saying that developers are "free to use any internal data representation >> they want" ignores the the fact that it places an unnecessary cognitive >> load on them when the choice doesn't need to be made by developers in >> the vast majority of cases. >> >>> The LDP working group can perfectly well define JSON-LD **in terms >>> of** a JSON serialization of RDF. The difference between the two: >>> The JSON serialization of RDF would be just that -- a serialization >>> of RDF, just as Turtle or NTriples are serializations of RDF. >> >> But TURTLE has it's own native list type, doesn't it? > > Only the surface syntax -- not the model. > >> So, it doesn't >> even fit your definition you use earlier in this e-mail. What about N3, >> which has Formulae and Literal subjects? > > N3 is not a W3C standard. > >> >>> Whereas JSON-LD would place further restrictions on that >>> serialization to specifically support the needs of the Linked Data >>> Platform, such as saying that every IRI SHOULD be de-referenceable to >>> information about the identified resource. >> >> If an application wants to break that suggestion, it can. That's why >> it's a SHOULD and not a MUST. >> >> -- manu >>
Received on Tuesday, 21 May 2013 13:38:59 UTC