Re: [JSON] the simple pivotal choice

Nathan wrote:
> Thomas Steiner wrote:
>> Good morning Nathan,
>>
>>> Glad you replied, as I'd very much like to work out where we agree and
>>> disagree.
>> I think we both agree that there must be something beyond
>>
>> [
>>   {"s": "<http://webr3.org/nathan#>"},
>>   {"p": "foaf:name"},
>>   {"o": "Nathan"}
>> ]
>>
>> I think we both have slightly different opinions with regards to
>> mappings. You seem to say
>>
>> {
>>   "name": "Nathan"
>> }
>>
>> is enough, we simply provide mappings ("RDF goggles") to whom it may
>> concern that "name" actually is "foaf:name".
> 
> yes, to use terms rather than CURIEs essentially, so rather than
> 
> foaf -> http://xmlns.com/foaf/0.1/
> foaf:name = resolve(foaf) + 'name'
> 
> you just have
> name -> http://xmlns.com/foaf/0.1/name
> 
> 
>> I seem to say that I'd rather prefer to see the prefixes somewhere in
>> the serialization, such as
>>
>> {
>>   "foaf_name": "Nathan"
>> }
>>
>> conserving the beloved dot-notation (so that you can write
>> obj.foaf_name rather than obj['foaf:name']). I could imagine a
>> well-known prefixes directory somewhere, according to, e.g., agreed-on
>> link relations in Atom.
> 
> Yes, this is a general question "do we need CURIEs / namespaces in the 
> JSON serialization?"
> 
> If yes, underscore can be a problem, since many properties include it, $ 
> could be used though..
> 
>   obj.foaf$name
> 
> There's also the point that prefixes aren't registered and reliable, 
> "foaf:name" could just as easily be "ns0:name" or "dc:name" all 
> resolving to the same URI - so I guess, if we admit that prefixes are 
> not registered names, and are unreliable when following your nose (that 
> is you'd need to compare full URI equality, not CURIE token equality) 
> why have them there at all?
> 
> This could be seen as a trade off thing, all names we use that are not 
> full URIs will need to be resolved when using the JSON like it's RDF, so 
> why not just keep using simple names ("name") to alias them, preserving 
> the simplicity and beloved . notation?
> 
>> All this might be too much of a simplification, but I guess this is
>> our main point of different opinions. What do you think?
> 
> Well the way I see it, is that with JSON, people are either going to be 
> using data from a single source, or following their nose around the 
> interwebs. So, for a JSON serialization, I feel we should either use 
> simple terms for properties, or full URIs.
> 
> when working with data from a single source, stick to the good old used 
> every format of:
>   obj.name
> 
> and when following our nose around the web considering data as RDF then 
> we can't rely on the lexical form of either simple names or curies in 
> the serialization so we need to do one of the following:
> 
> - use full URIs in the serialization
>   work with the data like: obj[ foaf('name') ]
>   or: obj[ resolve('foaf:name') ]
> 
> - run the JSON through some tooling or API to resolve all terms or 
> prefixes to URIs before using the data
>   work with the data just as above, but requires processing first to
>   expand the shortened URIs in the serialization to full URIs in the
>   data we work with
> 
> - run the JSON through some tooling or API to use our preferred terms 
> and prefixes before using the data.
>   allows us to work with the data how we want, but requires processing
>   first to shrink the URIs down to our preferred terms and curies (and
>   possibly expand those in the data up first).
> 
> After considering this for a long time, and working on the RDF API, I 
> came to the conclusion that APIs account for the latter two options 
> regardless of which serialization, so then looking at JSON specifically, 
> and what we may want to achieve, it may be wise to go with (1) how 
> people are using json already (simple terms), or (2) just use full URIs 
> in the JSON to save on some processing, or (3) introduce prefixes/curies 
> in to the JSON serialization but realize that it's only a way to save 
> bytes on the wire, because data source specific consumers prefer terms, 
> and rdf follow your nose will require the use of an API/tooling to make 
> the terms and curies usable.
> 
> Personal choice being (1) or (2) above.

I should probably note, that (1) doesn't preclude have a colon in a 
simple term (since JSON allows it), it would just be a case that 
"foaf:name" would be a direct alias for 
"http://xmlns.com/foaf/0.1/name", rather than being a namespace.

Probably worth me writing all this up in less all-over-the-place 
informal style, I'll do that later on this evening!

Best,

Nathan

Received on Friday, 11 March 2011 18:49:57 UTC