Re: RDF/JSON

Hi Carmen,

Thanks for your feedback.


> no thanks..

Sorry you feel that way.

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

If you're happy with a subset of RDF, then yes, you can get away with a  
simpler structure. However, the goal here is a structure that can  
represent the whole RDF model.

Moreover, JSON doesn't have its own syntax for differentiating between  
URIs, bnode ids and literals, nor a syntax language tagging. These are all  
important things for a lot of uses.

> 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?

The content-type header of the document should be a useful indicator, but  
good question: what do you suggest?

> 4 wheres type: 'resource'?

If you're asking how top level resource identifiers are typed, then they  
aren't; you'd have to pattern match to determine if it was a bnode or a  
URI. Benji also raised the possible case of needing to express subject  
literals, and suggested that they be explicitly typed with rdf:type  
rdfs:Literal .

Or if you're asking how to express that the object's value is the uri of a  
resource, then the answer is, use type: "uri".

> 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' ?

If you have a look at the specification (or the output of the converter),  
you'll see the example uses the '_:bnode1' syntax to represent bnode IDs.

> 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?

There seems to be a common (and, IMO, false) perception that  (perhaps  
because JSON's syntax is relatively simple), any format that uses JSON  
*must* look simple too. JSON is just a way of serialising data structures.  
Of course looking simple  is definitely nice to have, but not (in this  
case) at the expense of information loss, or a structure that is  
complicated to actually use.

Because RDF data has to be extensibly self-describing, I think any JSON  
structure capable of expressing the full RDF model is going to a bit more  
verbose than a domain-specific JSON format.

You can make it easier to write and simpler to look at by putting the  
descriptive bits into a separate part of the structure (which is what  
Exhibit/JSON does) but in doing so you make it more difficult to program  
with if you want to actually use those self-descriptive bits with the data.
For instance, using short aliases for property URIs would make the JSON  
source shorter and more readable. But the aliases are defined by the  
publisher, not the consumer - so the consumer can't safely use those  
aliases directly, and would need to look them up in the aliases section of  
the structure. So full URIs are simpler and more direct.

As Benji said, the aim is something that can be used without parsing or  
processing first.

I do think that looking simple, and perhaps appealing to non-RDF  
developers, are totally valid goals, but there are already formats, such  
as Exhibit/JSON (and perhaps your format), which are, or could be, doing  
that.

The gap in the market place this RDF/JSON is addressing is an established  
structure for representing, eg, the results of a SPARQL DESCRIBE query, in  
which resources and properties can be easily and transparently accessed  
and iterated over.


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

Hopefully the case of bnodes and nesting are adequately answered by the  
specification [1], if not by the previous messages in this thread. In the  
case of identifying RDF/JSON, I'm inclined to think a specific mimetype  
might be sufficient, but would be very interested in hearing objecions and  
other suggestions.


>> Would this be a convenient serialisation for you?

> no

Would you care to elaborate with an example with a use-case where this  
structure would be inconvenient (and where alternatives would not make  
other more common use-cases more difficult)?

Thanks,

Keith .

Received on Thursday, 6 September 2007 11:17:42 UTC