W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2012

Re: Potential Formal Object from DERI over JSON-LD

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 18 Oct 2012 15:29:32 -0400
Message-ID: <5080589C.4090600@openlinksw.com>
To: David Wood <david@3roundstones.com>
CC: Gregg Kellogg <gregg@greggkellogg.net>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Michael Hausenblas <michael.hausenblas@deri.org>, RDF WG <public-rdf-wg@w3.org>
On 10/18/12 3:21 PM, David Wood wrote:
> On Oct 18, 2012, at 14:35, Gregg Kellogg <gregg@greggkellogg.net 
> <mailto:gregg@greggkellogg.net>> wrote:
>
>> 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.
>
> I do (really) understand what you are saying, but it is a by odd way 
> to say it (according to me).  One does not ever transform a 
> serialization to a data model.  Instead, one thinks of a serialization 
> as being compliant with a data model or not. Alternately, one thinks 
> of a serialization being convertible to another serialization format 
> that shares the same data model.  Right?

+1

>
> So, it makes sense to me that Manu wants to work with JSON-LD without 
> ever converting it to some other RDF representation such as Turtle or 
> storing it in a database. Fine.  However, if his JSON-LD documents 
> *may* (however theoretically) be converted losslessly to Turtle or 
> parsed into an RDF database because they share a data model, then it 
> is an RDF serialization format.

+1
>
> Does that help level set terms for this discussion or just sound like 
> lecturing?  I hope the former.

Important clarification.

Kingsley
>
> Regards,
> Dave
>
>
>> 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
>>>
>>>
>>>
>>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Received on Thursday, 18 October 2012 19:30:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:52 GMT