Re: [JSON] PROPOSAL: Syntax structure should be object-based

On 03/16/2011 12:35 PM, Andy Seaborne wrote:
>> We (our company) found that it is nearly impossible to generically
>> address these two approaches at the same time without an API:
>>
>> 1. Use JSON as-is but translate it to RDF.
>> 2. Support terms, CURIEs, datatypes or languages.
>>
>> I think we need a minimum API... and really, nobody uses eval() these
>> days - they use jQuery, which uses the JSON API ->  JSON.parse()
> 
> Yes, I know direct eval() is not often done.  The point stands though -
> is it a call that is specific RDF of a call that any JS app might make.
>  You are describing a non-generic call in which case the relationship
> between javascript objects and serialization is open.

Yes, it's open - but the relationship still matters.

What I'm attempting to express is that it would be nice if the
serialization that is coming in could be used as-is in certain
scenarios. That is, the developer should be able to print out the
serialized object coming in (it'll look like JSON), and then turn it
into an object via JSON.parse() and use it directly like that. Or, they
could use RdfInJson.parse() to translate it into an object that they define.

To give an extreme example, if something comes in as N3 (a list of
triples), but you access it via obj.name, then there is a disconnect
from what came into the parse method (N3) and what is being used by the
developer (a JavaScript object that was magically created from the N3).

To provide a more concrete example, if this comes in:

[
   {
      "s": "http://example.org/foo#bar",
      "p": "http://example.org/foo#name",
      "o": {"_value": "Roo"}
   }
]

but they access it like this:

   obj.name == "Roo"

That would be confusing to a JSON developer. How did the "_value" get
re-mapped to obj.name? That would be not as good as this:

{
   "#": { "name": "http://example.org/foo#name" },
   "@": "http://example.org/foo#bar",
   "name": "Roo"
}

   obj.name == "Roo"

At least in this case, they know that they can access each of those
items using obj["#"], obj["@"], or obj["name"]/obj.name.

We want to get as close to a 1-to-1 mapping in the default case as we
can, such that JSON.parse() and RdfInJson.parse() produce the same
structured output.

> OK - the bytes sent over the network don't even have to be JSON.

No, they don't - but it sure would be nice if they were. It would be
even nicer if the data structure on the wire looked very much like the
data structure you'd use in JavaScript or Python or Ruby or C++. :)

> The task
> would be defining the in-application JSON datastructure.   A separate
> decision is how that relates to any JSON-on-the-wire.

It's a separate decision yes, but hopefully they'd look the same. We
know that they can look the same and produce a working system (JSON-LD).

> This matters when writing RDF back to the web, not just JSON-emitted
> data viewed as RDF.

It does, very much so - but I still don't understand the problem that
you keep alluding to. Do you have an example?

-- 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, 17 March 2011 00:51:16 UTC