W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] the simple pivotal choice

From: Nathan <nathan@webr3.org>
Date: Fri, 11 Mar 2011 18:48:42 +0000
Message-ID: <4D7A6E8A.3030508@webr3.org>
CC: Thomas Steiner <tomac@google.com>, RDF WG <public-rdf-wg@w3.org>, Ivan Herman <ivan@w3.org>
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!


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC