- From: Keith Alexander <k.j.w.alexander@gmail.com>
- Date: Thu, 06 Sep 2007 11:40:13 +0100
- To: "c.d.r." <_@whats-your.name>, semantic-web@w3.org
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