Re: [JSON] Initial comments

On Feb 28, 2011, at 14:41, Nathan wrote:

> David Wood wrote:
>> On Feb 25, 2011, at 03:55, Ivan Herman wrote:
>>> On Feb 25, 2011, at 24:21 , Nathan wrote:
>>> 
>>> [snip]
>>> 
>>>> Does anybody actually want to write RDF, by hand, in JSON? Up till now I'd always seen JSON as something produced by machines (by some data providing process, or by JSON.stringify'ing some object structure) and something which people just JSON.parse'd back in to an object structure to work with that data as simple object/array structure; where the most important aspect for all was always simplicity of the data structure.
>>>> 
>>> The question is: what is the usage of JSON in this respect independently of RDF? Does anybody want to write JSON manually for any purpose?
>>> 
>>> I really do not know, I am not a Javascript/JSON programmer. Ie, I do not know what the practice is. But maybe we should not make this type of decision by looking at RDF only.
>> I think this gets to the heart of the matter.  In my (personal) opinion, we are only discussing a JSON syntax for RDF *at all* because Web authors use and like JSON (Nathan's second use case).
>> Our response to date has been something like, "Well, we can easily serialize triples into the JSON spec.  That lets you use JSON with RDF.  Done."  Unfortunately, that approach doesn't address the way Web authors currently use JSON in the mainstream and therefore completely misses the point.
>> It seems to me that we don't need another efficient|better|more interesting|different serialization format for RDF.  We only need to facilitate the use of RDF data by Web authors for the purpose of allowing them to use the fruits of the SemWeb.
>> So, although RDF serialization in JSON (Nathan's first use case) is easy, I don't see the point.
> 
> would it help if I said that some platforms (like node.js) don't have decent XML support (namespace attribute support missing) and that they do have exceptionally fast json parsing (as do the browsers) so such an rdf in json solution would increase support and improve efficiency on multiple targets? (offset easy hit), if such a thing can be taken to rec track, I'd be interested in hearing reasons why it shouldn't be done.
> 
> However, if it's an OR situation, then certainly the second use case is a greater priority (imho).

Sure, it helps.

Please don't take my comments to suggest that we shouldn't pursue two JSON syntaxes for two different purposes.  I do suggest that we at least need to address the needs of Web authors (your second use case).

Regards,
Dave



> 
> cheers,
> 
> nathan

Received on Monday, 28 February 2011 20:03:38 UTC