- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Thu, 18 Oct 2012 14:35:14 -0400
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- CC: Michael Hausenblas <michael.hausenblas@deri.org>, RDF WG <public-rdf-wg@w3.org>
- Message-ID: <E8819E6A-5697-4217-B4A0-3E7EEBA09D0B@greggkellogg.net>
One more point on this, Manu and I have slightly different perspective on JSON-LD's relationship with RDF. Manu's use case is to work entirely within JSON-LD, without requiring a transformation to the RDF data model. My own use at Wikia also includes this; developers don't actually need to transform the JSON-LD to RDF in order to work with it; that's sort of the whole point! However, this does not mean that JSON-LD is not RDF. Some developers work with RDFa without actually converting it to the RDF data model: * Facebook's OGP model famously abuses property IRIs, and avoided the actual definition of the ogp prefix. This was addressed in RDFa 1.1 by including "ogp" as a prefix in the default context, and ensuring that IRIs containing multiple colon's (":") were legitimate; I think Turtle made the same change. * Niklas Lindström has an RDFa to JSON-LD converter [1], that does not need to go through an intermediate RDF model representation form (AFAIK). I think it's perfectly reasonable for developers to work entirely within the JSON-LD space without requiring a transformation to the RDF data model do do anything. The fact that the data _is_ RDF, and can be converted to the RDF data model is a plus. In my own case, I want to be able to transform the JSON-LD objects to RDF so that I can perform OWL entailments to infer data relationships not necessarily managed directly through the JSON-LD definitions. The fact that I can allow developers to work entirely within JSON, and give them back a representation that includes the entailed relationships is quite important. Also, I can mark-up OWL class definitions with other more explicit subClass/superClass/property-list information to allow for form validation, when using a JSON-LD representation of the vocabulary. All I'm really doing is creating entailment rules that allow me, for example, to determine all of the properties that have an effective domain of a given class, taking into consideration rdfs:subClassOf and owl:unionOf semantics. JSON-LD is solving real-world problems at Wikia, and should lead to a time when hundreds of thousands of wikis are available as linked data, due to the strength and flexibility of the RDF ecosystem. Gregg Kellogg gregg@greggkellogg.net<mailto:gregg@greggkellogg.net> [1] https://github.com/niklasl/rdfa-lab On Oct 18, 2012, at 7:02 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com<mailto:pfpschneider@gmail.com>> wrote: There are two questions that I have continued to have about JSON-LD. 1/ Is JSON-LD a serialization syntax for all RDF graphs? 2/ Is JSON-LD only a serialization syntax for RDF graphs? Could the interested parties state straight up their answers to these questions? The opinions below are mine alone. I have included them here to give some rationale as to why I want answers to the above questions to be on record. If the answer to the second question is true, i.e., every JSON-LD structure corresponds to an RDF graph and there is no more information in the JSON-LD structure, then it is obvious to me that JSON-LD work should go forward in the RDF WG. If the answer to the first question is true, i.e, every RDF graph can be written as a JSON-LD structure and recovered from that structure unchanged, but not the second, then the situation is somewhat murky. It seems to me that there should be some convincing argument why the RDF WG is recommending something larger than RDF, and the more there is in JSON-LD (ordering, etc., etc.) the more convincing this argument has to be. In this case it may be better to have some other status for the JSON-LD documents, or even for the RDF WG to simply point to the JSON-LD documents in one of its documents. If neither are true, then I don't see any reason for the RDF WG be interested in JSON-LD. Peter F. Patel-Schneider
Received on Thursday, 18 October 2012 18:36:44 UTC