Re: [JSON] the simple pivotal choice

Nathan,

Part of the question essentially boils down to: "do we need to support
mixing vocabs?". If not, the whole issue of namespacing or not does
not occur. If yes, then we have to choosefrom the options you have
summarized and that have been discussed here and there :-)

+1 for collecting all the opinions centrally. Thanks for doing this!

By the way, would it be helpful having two sets of triples, one more
or less trivial and the other a little more complex, try to encode
this using all existing serializations, and have it somewhere central
on the wiki so that we can compare? Does this maybe even exist
somewhere? If not, I volunteer for an AI with the objective of doing
this. Opinions?

Best,
Tom

Thank God not sent from a BlackBerry, but from my iPhone

On 11.03.2011, at 19:49, Nathan <nathan@webr3.org> wrote:

> 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 20:32:16 UTC