Re: [JSON] object-based JSON vs. triple-based JSON

On 09/03/11 19:44, Manu Sporny wrote:
> Hi all,
>
> Just wanted to get some thoughts down while they were fresh in my mind
> concerning the two camps issue related to RDF in JSON. Instead of
> defining these two camps as "human-friendly" and "machine-friendly",
> perhaps it would be better to define the two camps as "object-based" and
> "triple-based":

This is confusing the requirements with the implementation.

I read "human-friendly" as code for can use JSON directly.  No RDF 
specific API needed, app writer directly sees the JSON.  It may be lossy 
(not all RDF details can be expressed in JSON-RDF); this is a problem 
when considering writing back to graph stores.

It also seems sometimes to mean "make JSON into RDF" but I have already 
written to that point.  Experience from converting other data to RDf has 
shown me that the underlying data can mean different hting to different 
people already using it.

Machine-friendly is code for via an RDF-specific API, and no need to 
worry about appearance because the app writer does not see the JSON.

It would be nice of The RDF-specific API format were readable (RDF/XML!) 
but it doe snot matter too much (N-triples!).

> object-based
> triple-based

Is Turtle object-based or triple-based?
Is Talis's format object-based or triple-based?

I don't see this defn of object-based as anything more than wanting (1) 
a frame-like structure and (2) properties as keys.

I'm happy with those but it's design style.  We don't seem to have reach 
consensus on the problem space yet.

The impedance mismatch of JSON data types and RDF (XSD) datatypes is a 
worry.


> What is success?
> ----------------
...
> Now, let's define what success is for the RDF in JSON format. As far as
> I see it, success results in RDF in JSON being used as the format used
> for exchange of semantic data between Web Applications and back-end REST
> Web Services. This means that almost every web applications developer
> ends up using RDF in JSON as the serialization format for their semantic
> data. We're talking millions of developers and billions of documents.

For me, this UC matters:

http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#Developing_a_Javascript_application_that_interacts_with_a_graph_store

This is different.

My concern is letting JOSN developers work with data that is in RDF 
(Government data, RDB2RDF).

See http://code.google.com/p/linked-data-api/
There the approach is to create a presentation of the data in JSON 
friendly form.  It is not JSONified-RDF - it is targetted at JSOn apps 
working with RDF data.

> Mistakes of the past
> --------------------

RDF/XML was an attempt to "do" RDF in XML.  The complexity is unhelpful 
and difficult to teach.  Being too complicated is one mistake of the 
past to avoid.

Attempting to mask RDF features in JSON formats have the same issues. 
It becomes difficult to explain - we have to very wary of that mistake 
of the past.

> The path to success
> -------------------
>
> One of the ingredients for success for RDF in JSON is ensuring that we
> don't repeat the RDF/XML data format mandate mistake. If we take the
> triples-based approach, we are making that same mistake.

RDF/XML isn't clearly triples.  That's one of its problems IMHO.

When explaining on Jena support lists, one thing we do when questions 
about RDF/XML come up, especially striped syntax, is say look at in 
triples - Turtle or N-Triples.  It explains why "id=" or about="" isn't 
a property or where the rdf:types and lang tags come from.


	Andy

Received on Thursday, 10 March 2011 08:29:27 UTC