Re: [JSON] Tiny Proposal

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