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

On 16/03/11 14:57, Manu Sporny wrote:
> On 03/16/11 10:06, Andy Seaborne wrote:
>> While I can support a data-object style (providing a document is
>> self-contained and matters of coverage), the more important question to
>> me is whether we are designing to API access or direct datastructure
>> access, and within the latter whether there is translation between
>> on-the-wire and applications forms.
>
> 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.

> However, my definition of API might be different from your definition of
> API. I think we need a single API call:
>
> rdfInJson.parse()
>
> That's it.
> We also want to have an RDF in JSON parser that can plug into the RDF
> API, but that is an orthogonal issue. There is the concept of a
> "Projection" in the RDFa API (which we lifted from SPARQL)... that's
> what I think the rdfInJson.parse() method should return - a Projection.
> The projection would allow people to do stuff like:
>
> obj.name
>
  instead of heavy-weight stuff like (in the RDF API):


OK - the bytes sent over the network don't even have to JSON.  The task 
would be defining the in-application JSON datastructure.   A separate 
decision is how that relates to any JSON-on-the-wire.

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

 Andy

Received on Wednesday, 16 March 2011 16:36:42 UTC