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

On 03/09/2011 09:20 PM, Nathan wrote:
> Manu Sporny wrote:
>> I could go on, but I think you get the idea - having just one .parse()
>> method with a number of arguments can be very powerful and solve a large
>> number of the problems that you're outlining. The above is a
>> straw-proposal and doesn't solve all of the problems but hopefully
>> clarifies that much of the "code isn't re-usable" problem can be
>> addressed pretty simply.
> 
> In all honesty Manu, if this is useful, I don't see why it should be
> bound to or dependant on "RDF in JSON", why not add a .toObject(g,map)
> to the RDF API so that it's available and common for every serialization?

Yes, exactly. That's partly what we're trying to do with
data.rdfa.query() and Projections in the RDFa API (look at the last
example here):

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

And I've tried to finagle this approach from a different angle in the
JSON-LD spec:

http://json-ld.org/spec/ED/20110201/#widl-JSONLDParser-toObject

Both documents are still very much a work in progress... this is one of
those things we're going to have to feel our way through, which will
hopefully be made easier with more eyes on the problem.

>>> Why is that a problem? well, it means that the benefits of RDF are lost
>>> (core data model, use generic tooling for any data from any source) and
>>> the benefits of JSON are lost (simple domain specific k/v objects
>>> requiring no tooling).
>>
>> Hopefully I've shown how this problem can be mitigated to a fairly large
>> degree.
> 
> Yes, with an API, and why have two APIs?

If we can unify the APIs, that would be great.

>> Is this an argument to not try to meet in the middle and go one way or
>> the other?
> 
> Yes, as noted in the other thread, if it requires "tooling" (I used this
> term rather than API) then I'm struggling to see why custom for RDF in
> JSON rather than just normal RDF tooling, it's either RDF or not surely?

Maybe. It could be that the RDF API fails to gain traction, but RDF in
JSON doesn't. If that's the case, we want a good separation between the
RDF "tooling" and the RDF in JSON "tooling".

It would be nice to have the RDF API, RDFa API, and RDF in JSON API work
nicely together, but allowed to be used independently of one another.
That is, one person might want to use the RDFa API and the RDF in JSON
API, another might only want to use the RDF API, and yet another would
want to use the RDF API and RDFa API together.

> Apologies if it seems like I'm hard lining here Manu, as you know I'm
> always open to multiple suggestions / approaches and frequently wrong on
> things, but I am concerned about unexpected functionality for "normal"
> developers - or, perhaps there needs to be some interim bridge between
> the OO and Triple worlds and that is one of the trade offs to be
> considered.

I disagree with the "frequently wrong on things" bit above. :)

I agree that we don't want unexpected functionality for developers. It
would suck to have 3 different ways of doing .toObject() - one in RDF
API, one in RDFa API, another in RDF in JSON API.

>> 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.
> 
> Depends if you throw an API in to the mix I guess, can't see any reason
> why graphs can't be turned in to objects, and likewise the inverse.

As you know, in PaySwarm - we're taking RDFa and turning that into
JSON-LD. We're also turning graphs read from JSON-LD into "data objects"
and taking JSON-LD input into our Web Services and storing them as
graphs/triples. The conversion is loss-less and fairly easy to work
with. Look at the example contract - that's a serialized graph -
object-based JSON in JSON-LD:

http://purl.org/payswarm#Contract

I think that folks that are interested in the full RDF web-based object
life-cycle should also take a look at Nathan's absolutely fantastic JS3
library:

https://github.com/webr3/js3#readme

There's some real eye-opening stuff in there that will force you to
shift how you think about programming with RDF in JavaScript.

-- 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 04:21:42 UTC