Re: RDF/JSON

> {
> RESOURCE URI => {
> 		  PROPERTY URI	=>
> 				  [
>                                     {
> 					type: ("literal","uri","bnode"),
> 					value: (the value of the object),
> 					lang: (language code - optional),
> 					datatype: (URI of the datatype - optional)
> 				    },
> 					...
> 				  ],
> 			...
> 		},
>  ...
> }

no thanks..
1 JSON already has a way to express literals in its syntax, and it doesnt involve a wrapping object and a 'datatype' and 'value' field. i'm happy being limited to strings, floats, ints, arrays and tables..
2 this is three levels of nesting instead of one (two in the case a predicate has multiple objects)
3 if youre given a JSON object, how do you determine it is RDF in this format and not just an object with a single arbitrary-string key? (think JSON-literals vs nested graphs patterns, user-agent remixing, development ease, etc)
4 wheres type: 'resource'?
5 since theres a type: 'bnode', how is the bnode expressed, since your format requires a URI key for the top level, youre going to need something different for that: '' is treated as null in json, and you additionally cant use '' or null as an object key. is there a URI out there that says 'this is not a uri' ?

youre welcome to download the carmen platform (tm) [1], to see the JSON format. its very similar to the decisions of Simile and Metaweb, as both achieve a good parity of graph/node/resource object and JSON object. it can be pretty much summarized as just JSON - but use deferencable/commonplace URI strings for the keys

the differences:

1 simple: 3 makes a prettier and simpler literal than {'type': 'literal', 'datatype':'xsd:int', 'value': '3'}. wouldnt you agree? isnt object-literal syntax the point of JSON? why not just use XML for your solution?
2 (1) you can trim off the top level by putting URI as a property of an object that also has other properties (predicates). yes, this makes 'uri' a reserved word for predicate names, but that reserves a lot less than this format, which reserves a specific structure that then requires some kind of external framing and tooling (you can browse Simile/E RDF without expanding the firebug DOM tree inspector 3 times). (2) you can also trim off the innermost level if you dont allow JSON arrays as literals
3 2.1 solves 3, since if you have a uri key you know its a JSONRDF object with much more likelihood than above
4 an object is RDF if it has a uri key. otherwise its a blank node or JSON literal. so you dont need this typetag
5 blank nodes are just normal JSON objects - keep them as RDFey as you like with URI keys, and maybe even give it a URI of its own one day


[1] http://whats-your.name/e/e.tar.gz

> If you publish RDF, would you consider publishing this RDF/JSON 
> serialisation, and is it clear and unambiguous how to do so?
no, yes. except in the case of bnodes, nesting, and JSON objects that may or not be RDF resources
>
> If you read RDF from the web in your applications and scripts, would this 
> be a convenient serialisation for you?
no

>
> Thanks in advance,
>
> Keith Alexander
cheers,

carmen

Received on Thursday, 6 September 2007 01:25:21 UTC