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

On 03/09/2011 09:06 PM, Sandro Hawke wrote:
>> If so, I wouldn't necessarily agree with that direction. I think many of
>> the goals that the triple-based camp wants can be accomplished using the
>> object-based approach. I do not think, however, that many of the goals
>> of the object-based approach can be accomplished via the triple-based
>> approach.
> 
> Now I'm confused.   If users have to call .parse() anyway (as I agree
> they should for JSON, but I'm not sure if they do), then why not
> transmit the data in turtle?   We have turtle parsers in JS already,
> etc.  

The reason that TURTLE isn't a good solution is because of the millions
of web developers out there that are not using TURTLE for their
REST-based APIs... they're using JSON. Perhaps TURTLE will replace JSON
in the future, but we're not there yet. If we don't come up with a JSON
serialization that is compatible with the JSON that is out there today,
we are going to give web developers the same mutually exclusive choices
that they've had for the past 7 years.

1. Choose to make your Web Service TURTLE-based.
2. Choose to make your Web Service JSON-based.

In other words, we force them to pick their data model (key value or
triples)... and we already know which one they'll pick because they've
been choosing JSON over TURTLE for the past 7 years. I don't think a
single method in a TURTLE API call is going to change that.

However, that is not to say that we shouldn't support TURTLE parsing via
the RDF API. We /should/ support a .parse() and .toObject() method via
the RDF API and figure out some way of plugging TURTLE in there. We
already have the beginnings of these interfaces in the RDF API:

http://www.w3.org/2010/02/rdfa/sources/rdf-api/#data-parsers

We also have a way of working with "data objects" via Projections and
Property Groups in the RDFa API:

http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#property-groups
http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#projections

I'll cover more about this in the response to Nathan.

> Then the rest of this discussion is just about the API for the
> JS library (which is a subject for your other Working Group.)

Well, not really. For example, how would a developer do cycle-breaking
and object-framing for incoming data?

http://manu.sporny.org/2011/semweb-problems-1/

How would they specify the object-frame in TURTLE? Would they use
SPARQL? If SPARQL, why are they now required to use yet another language
to specify how to frame data in TURTLE?

> The argument that convinced *me* JSON+RDF was important for this WG was
> the idea that an important subset of RDF could be put into JSON in a
> straightforward way that would make sense even if one didn't really
> understand RDF. 

I think that's still true for a few of the serializations that we're
considering.

> I was hoping for a language that could be read and
> generally understood without even reading the spec. 

Again, I think that's still true for a few of the serializations.

> It could be as much
> a teaching tool, a gentle slope to RDF, as a practical format.  That's
> what I was trying to do with JRON.  

... and I think that should be one of our goals. However, I don't think
TURTLE is the path toward that goal for JSON REST Web Apps.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
http://digitalbazaar.com/2011/01/31/web-commerce/

Received on Thursday, 10 March 2011 03:51:33 UTC