Re: [JSON] Tiny Proposal

Hi Andy,

Andy Seaborne wrote:
> On 23/03/11 18:14, Nathan wrote:
>> Hi All,
>>
>> Here's a tiny proposal:
> 
> for presenting RDF information in JSON.

Or for presenting JSON information as RDF, I see this as covering 1&3 in 
Richards "Classifying the use-cases" mail

"1 Add (some of) the benefits of RDF to existing JSON services"
"3 Publish idiomatic, developer-friendly JSON from the RDF data model"

> It's stressing IRIs for things - it's not trying to be a complete 
> serialization.

yes :)

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

I'd be happy with either approach, I opted for nesting because it's 
familiar to JSON/JS users, but it's not something I'd hardline over!

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

Yes, could/would be a useful addition.

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

yes, agree.

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

Agree, drop @base - this also makes it far easier, or should I say 
possible, to support IRIs as value types without confusing iri-ref "foo" 
with string "foo".

> 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).
> 
> ...
>> - 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" }

Can I add in a few more really's above? I'd really prefer not to start 
adding bits like this, one you start, where do you stop? and soon you do 
not have the simplicity any more.

Thanks for the feedback Andy :)

Best, Nathan

Received on Thursday, 24 March 2011 14:09:15 UTC