Re: [JSON] the simple pivotal choice

Thomas Steiner wrote:
> 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 :-)

Perhaps that question can be refined, note that I don't use "term" in 
the RDFa sense, where you strap a term on to a defined, in scope @vocab, 
thus:

You can map different terms to different URIs:
   label -> http://www.w3.org/2000/01/rdf-schema#label
   name -> http://xmlns.com/foaf/0.1/name

That said, if you did take the RDFa @vocab approach (where "name" is 
concatenated on to a URI) then:

You can easily make your own vocabulary which combines properties from 
others, and reference that.

My point I guess, is that there are many different ways to mix and match 
vocabs, and indeed to do everything we require.

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

Will start doing that in a mo :)

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

It would be great to have two sets of test data, one simple, one 
complex, then see the different ways we can construct it with JSON. +1

Best,

Nathan

> 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:47:46 UTC