Re: [JSON] the simple pivotal choice

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.

Best,

Nathan

Received on Friday, 11 March 2011 18:34:17 UTC