- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 11 Jun 2013 02:34:13 -0500
- To: "Markus Lanthaler" <markus.lanthaler@gmx.net>
- Cc: "'David Booth'" <david@dbooth.org>, "'public-rdf-comments'" <public-rdf-comments@w3.org>
On Jun 8, 2013, at 2:07 PM, Markus Lanthaler wrote: > On Saturday, June 08, 2013 8:28 PM, David Booth wrote: >> Uh . . . did you read that entire document? Please do. Because unless >> one were intentionally exercising selective understanding, I do not see >> how anyone could honestly misread it so badly as to not realize that it >> is specifically talking about RDF and the Semantic Web, making >> reference >> to the way the HTML-based web works, and showing that the same >> principles of linking and dereferencing are needed for RDF and the >> Semantic Web. The very first paragraph says: >> [[ >> The Semantic Web isn't just about putting data on the web. It is about >> making links, so that a person or machine can explore the web of data. >> With linked data, when you have some of it, you can find other, >> related, >> data. >> ]] >> >> And the second paragraph explicitly says: "for data they links between >> arbitrary things described by RDF". I don't know how he could have >> said it more clearly. > > So maybe what he wanted to say after all was that people where using RDF > incorrectly? :-P > > >> Claiming that that document in any way supports the notion that Linked >> Data is not based on RDF would be disingenuous to the point of being >> fraudulent. > > I'm not saying that. I'm saying that it describes a generic concept. That > concept can be realized with RDF. I think we just have to agree to disagree > on this. > > >>> Surprisingly exactly that "(RDF*, SPARQL)" remark was missing when >> the term >>> was coined. >> >> Not surprising at all. That document was clearly a rough draft. It is >> not surprising that TimBL added more clarification as he edited it. > > And apparently it still is. Just the few sentences you quoted are full of > typos. Everything Tim writes is full of typos. >>> We can continue forever to argue about whether it is needed or >>> not. We can also argue whether it is possible to "provide useful >>> information" by using an abstract data model, i.e., RDF. When you >>> dereference a URI, you'll get back a representation which is in a >> concrete >>> syntax. So, it would be more correct to say >>> >>> 3) When someone looks up a URI, provide useful information, >>> using a standard format which can be interpreted as RDF >>> >>> Would that add any value given that you can interpret (convert) every >> format >>> to RDF? I doubt so. This group (myself included) is convinced that >> doing so >>> would scare of a large portion of the target group, i.e., average web >>> developers. >> >> That is your motive, and I have some sympathy for it. But it does not >> justify the attempt to re-define the meaning of such an important and >> well-established term. > > We are certainly not re-defining it. If we are doing something, then we are > generalizing it by omitting a remark. > > >> Claiming or implying that Linked Data is not based on RDF would be >> misleading the public. It is factually untrue. > > We are not claiming that Linked Data is not based on RDF. If so, please > quote the relevant text from the spec. We are just not mentioning that > Linked Data is based on RDF in the intro. That's it. That is called "Economy with the truth". It is classified as a form of deceit, listed in http://en.wikipedia.org/wiki/Lie as one of the many forms of lying. If you ever do it to the police, you can be charged with a felony. So David is perfectly correct: you are lying to the public. >> I do not believe that mentioning that Linked Data is "based on RDF" >> will have a significant impact on the adoption of JSON-LD. > > Other people do; myself included based on first-hand experience. But we here talking about a potential W3C Recommendation. By and large, it is widely expected that documents this "standard" actually tell the full truth, openly and honestly, regardless of the consequences. In particular, they should carefully and unambiguously spell out any relationships to other standards. They are not manifestos or exercises in persuasion or propaganda. > >>> We just try to explain them the underlying principles in simple terms to > get >>> them interested and motivated enough to read the rest. The end of the > spec >>> makes JSON-LD's relationship to RDF crystal clear (IMO at least) and >>> contains a whole lot of examples for people from the semantic web > community >>> already familiar with e.g. Turtle or RDFa. Those people don't need to > read >>> the introduction, they know the basics already. >> >> I think it's good that it starts by explaining the underlying principles >> in simple terms. I do not believe that that objective will be harmed by >> the three words "based on RDF". > > Well, I do. Other people do as well. So the compromise we settled on was to > not mention it. We do not claim that Linked Data is *not* based on RDF, we > neither claim that it is. Which is an elegant form of lying. Particularly as there is an expectation that any Recommendation level document will spell out relationships to other specs objectively and accurately, so an omission is clearly a form of denial. >>> The truth is that people strongly associate RDF with RDF/XML. In >>> fact, it is difficult to have conversations without conflating RDF >>> the data model and its serialization formats. >> >> It would be nice if JSON-LD could help dispell that misconception. But >> to do so, people need to know that JSON-LD *is* a serialization of RDF. > > I see JSON-LD + schema.org as the gateway drug to the semantic web. People > will found out that they are effectively already using RDF when they are > ready for it. No need to scare them away at the first contact. If some people get scared, tough on them (or maybe their employers). Enough of them won't be that the scared ones will soon catch up. (BTW, you must hang out with some very weak characters. An acquaintence of mine is taking an masters in library science, to become a librarian. She is having to learn RDF, which is part of the training of librarians these days. It is explained, in full, from scratch, in about two pages of a textbook, and she found it trivial.) >>>> If the JSON-LD spec were to adopt a definition of "Linked Data" that >>>> differs in such a critical way from the established meaning of this >>>> term, it would be misleading the public and would create confusion >>>> in the community. >>> >>> Sorry, but I just can't see how it is doing that. >> >> Okay, to be very clear: >> >> 1. Telling the public that Linked Data is not based on RDF would be >> misleading the public, because Linked Data -- in the original and >> well-established sense of the term -- very clearly *is* based on RDF. > > OK, we are not doing that. But you are, in fact. >> 2. That would create confusion in the community because people would >> then have differing notions of what is Linked Data. Thus, when people >> talk about Linked Data, there would be confusion about what is meant. >> If the meaning is not kept clear, people may start claiming that >> arbitrary JSON is "Linked Data", or that spreadsheets that contain some >> URLs are "Linked Data", or that database tables that have foreign keys >> are "Linked Data", or HTML pages of census data with links to other >> pages are "Linked Data". > > I never believed, but apparently that Linked DataT Police really exists :-) > http://dret.typepad.com/dretblog/2009/11/the-linked-data-police.html > > So, why is it that people talk about Linked Data then instead of RDF? If the > difference really matters in a conversation, simply talk about Linked Data > based on RDF or HyperRDF to avoid confusion. > > > [...] > >>>>>> 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. >>>>> >>>>> We already do this here: >>>>> >>>>> http://www.w3.org/TR/json-ld/#transformation-from-json-ld-to-rdf >>>> >>>> No, it doesn't. That section explicitly says: "This section is >>>> non-normative". >>> >>> JSON-LD consists of two specs, the syntax spec and the algorithms and API >>> spec. The normative transformation to RDF can be found here: >>> >>> http://www.w3.org/TR/json-ld-api/#convert-to-rdf-algorithm >> >> It needs to be much clearer that the bi-directional mapping to/from the >> RDF abstract syntax is normative. As I said in my last email: >> [[ >>> In discussing this at SemTech with Gregg Kellogg -- BTW, thanks for >>> getting together Gregg! -- he told me that it is the working group's >>> intent that JSON-LD be a *normative* serialization of RDF. So if > that's >>> the case, it sounds like this may be an editorial issue: the document >>> needs to be much clearer about how the relationship is normative. At >>> present, it is not at all clear that it is normative. Maybe what's >>> needed would be something as simple as "This section is non-normative. >>> However, JSON-LD is a normative serialization of RDF: the normative >>> relationship between the JSON-LD syntax and the RDF model is defined in >>> section @@@@." >> ]] > > So, would changing the introduction of section C.1 "Transformation from > JSON-LD to RDF" to the following sentence address your concerns? > > JSON-LD documents can be parsed as RDF and RDF data can be serialized > as JSON-LD. It is beyond the scope of this document to describe the > algorithms in there details, but a summary of the necessary operations > is provided to illustrate the process. The normative algorithms are > can be found in RDF Conversion Algorithms in the JSON-LD Processing > Algorithms and API specification [JSON-LD-API]. This would not address my concerns. FIrst. it still implicitly claims that JSON-LD and RDF are fundamentally different, which is disingenuous and misleading. Second, it is in an appendix rather than the main body of the document. Pat > > > Cheers, > Markus > > > -- > Markus Lanthaler > @markuslanthaler > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Tuesday, 11 June 2013 07:34:41 UTC