- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 24 Mar 2011 13:43:59 +0000
- To: RDF WG <public-rdf-wg@w3.org>
- CC: Nathan <nathan@webr3.org>
On 23/03/11 18:14, Nathan wrote: > Hi All, > > Here's a tiny proposal: for presenting RDF information in JSON. It's stressing IRIs for things - it's not trying to be a complete serialization. > 1: Constrain JSON [1] to be an (optionally nested) sequence of one or > more objects (where one, no enclosing [] is needed). I'm not convinced nesting is needed. Instead, what about a flat JSON-[] array of data objects with fields. Linking is up to the app. Nesting means there are two ways to write one thing. > 2: constrain object keys to be strings with no white space > > 3: add in IRI recognition as a value type (wrapped in quotes), likewise > dateTime, date and time. > > 4: add recognition for a special "@id" property who's value is an IRI > (sets the subject of the object when present) > > 5: add recognition for a special "@vocab" property who's value is an IRI > (when present, each key in that object is concatenated to the @vocabs > value to form the IRI of the property) key-only is an interesting idea. Allow full IRI as well for other properties but if it's in @vocab, the short form must be used. Only one vocabulary allowed to simplify the resolution. > 6: add recognition for a special "@type" property who's value is simple > string (when present the value is concatenated to the @vocabs value to > form the IRI of the rdf:type) or a full IRI. > 7: add recognition for a special "@base" property who's value is an IRI > (relative IRI-ref resolution) Unconvinced. This is getting into point-wise solutions for things that aren't even clear they are problems. One of the things to add to a JSON app is IRIs to identify things so information can be reused more widely. Not properties - IRIs for subject and objects. I can understand the need for abbreviation for properties/keys. For simplicity, keep an IRIs as full IRIs. The JSON has strings. It's up to the app to decide if a string is treated as an IRI (ditto the rest datatyping). Do define what "looks like an IRI" is -> starts with "http://" or "urn:" -- no other URI schemes. This way, only properties-as-keys would be shortened and they hav eone one form (shortened if in @vocab, or an IRI if not). > > For the Sample Graphs [2] this would produce: > > { > "@vocab": "http://xmlns.com/foaf/0.1/", > "@type": "Person", > "@id": "http://jondoe.example.org/#me", > "nick": "Jonny", > "givenname": "Jon", > "family_name": "Doe", > "depiction": "http://jondoe.example.org/me.jpg", > "homepage": "http://jondoe.example.org/", > "interest": "http://dbpedia.org/resource/Film", > "knows": { > "@type": "Person", > "@id": "http://janedoe.example.org/#me", > "name": "Jane Doe" > } > } ... > > trade-offs and clarifications: > > - multiple values represented by an array This is one way, both RDF lists and multiple values become a JSON array. Preserves order where order was given by an RDF list. > - blank nodes are objects with no "@id" (blank node identifiers not > supported) > - no provision for @language or @datatype Shame about lang tag but for JSON is complicated encoding or omit. If really, really needed, have a complicated value form (using {} because of the "no nesting"). { "@lang": en, "value": "chat" } Andy > - when terms from multiple vocabularies are needed it requires people to > make their own custom vocab which includes aliases to terms in other > vocabularies. (having a single cachable vocab is lighter for network > though and easier to maintain) > > I think that's about it.. > > Best, > > Nathan > > [1] http://json.org/ > [2] http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#Sample_Graphs >
Received on Thursday, 24 March 2011 13:44:38 UTC