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

Manu Sporny wrote:
> On 03/09/11 15:10, Sandro Hawke wrote:
>> On Wed, 2011-03-09 at 14:44 -0500, Manu Sporny wrote:
>>> 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"
>> [offlist, but feel free to quote and reply on-list if you like.]
> 
> Sandro - responding onlist because you (always?) make good points and I
> want to make sure that I'm being crystal clear and making sense (as I've
> failed to do that several times in these discussions and I don't want
> that to continue to muddy the waters).
> 
>> I disagree with several steps of your argument here, but I agree we
>> should focus on object-based instead of triple-based approaches, so I
>> think I'll just leave it there.
> 
> Don't just leave it there! :) If there are holes in my argumentation, we
> should expose them so that we're sure of the reason(s) we're picking one
> approach over the other.

If I may chip in, "object-based" may not be defined quite right here, 
most people use JSON as "plain old data objects", e.g.

   { name: "nathan", foo: "bar" }

and use it simply with no tooling:

   print( obj.name )

Both JSON-LD and JSN3 are object-based, however they are not just plain 
old data objects, sure they offer features so that (ignoring the maps) 
they can be used as plain old objects, but they are not constrained to 
be plain old objects, which means that when you use it in the wild, you 
require tooling to do so, else developers will need to write code such 
as this:

  for(o in objects) {
   if(o["@"] == "<http://example.org/people#nathan>") {
     print( o["foaf:name"] );
   }
  }

Primary problem being, that code isn't reusable, even if generalized and 
turned in to a function, the properties may be a full URI, might use a 
different prefix, and so forth. [1]

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).

As in, meeting in the middle between RDF and plain old objects, requires 
trading off the simplicity whilst giving the perception that you don't 
need the tooling - which leads to unexpected functionality, confused 
users/developers, and imho, is certainly not a recipe for success at all/

I often miss some vital details though and willing to talk this one out.

Best, Nathan

[1] If you followed the generalization process long enough, you'd end up 
with JSON-RDF specific API/tooling, which begs the question why not just 
use generic RDF tooling from the get go..

Received on Wednesday, 9 March 2011 23:10:06 UTC