Re: JSON Emergency Brake

On 29 August 2011 03:40, Manu Sporny <msporny@digitalbazaar.com> wrote:
 I
>> reckon will just use a bunch of terms from a single namespace and/or a
>> small total number of terms - both adequately (and more simply)
>> available without prefixes.
>
> Danny, this begs the question, doesn't it? That is, if I assume what you say
> above, I come to the same conclusion that you have - we don't need CURIEs.
>
> However, the raw data shows us that there is quite a bit of vocabulary
> mixing that is already happening out there - in TURTLE, in RDFa, etc. It is
> true that these are early days and that practice might change based on
> precedents like schema.org.

Well, most of the Turtle I've seen tends towards the big-mixing side,
but most RDFa (which I reckon is a closer scenario to JSON-LD) tends
to be simpler.
But as you say, it's early days, we don't really know what the future holds.

However, it's much easier to add a feature to a spec than remove one.
Consider the alternatives:

1. CURIES now, popular response -> big win
2. CURIES now, unpopular response because of CURIES -> big fail
3. not CURIES now, popular response -> big win
4. not CURIES now, unpopular response because of lack of CURIES ->
small fail, CURIES can be added

>> [1] http://microformats.org/wiki/namespaces-considered-harmful
>
> Not everyone in the Microformats community (myself included) agrees with
> that position for all languages:

I don't agree with that position even for microformats, but the folks
that hold it do tend to be more vocal.

> Have you had a look at Section 4.1 in the latest (as of 15 minutes ago)
> JSON-LD spec? What do you think of the first 3 paragraphs?

What's changed? (the diffs link is 404ing)

I totally accept the serialized size argument.

But I'm not at all sure about the cognitive load argument -
"It is far easier to remember foaf:name than it is to remember
http://xmlns.com/foaf/0.1/name" - true, but that's only after you've
remembered http://xmlns.com/foaf/0.1/. I for one can't remember any
namespace URIs.

Ok, once you've got the URI it's much less hassle to type foaf:name
than copy & paste the URI every time, but that's hardly a cognitive
thing. In fact prefixing is *adding* the extra cognitive load of
understanding the prefix-URI association.

I'm afraid the future-proofing argument looks spurious to me. "The use
of CURIEs also ensures that a context document does not have to be
updated in lock-step with an externally defined Web Vocabulary".
Ok, what changes can happen?
* different namespace - you have to change your instance data either way
* removed term(s) - you should change your instance data either way
* added term(s) - you may wish to use the new terms, if so you have to
change your instance data either way

Another list - as I see it, these are the arguments in favour of CURIES:
* smaller payloads - a definite plus, but as we're only talking at
maximum a couple of thousand of bytes, not a game-changer
* reduced hassle when typing - amount of benefit is debatable, it
assumes a lot of JSON-LD docs will be hand written, not necessarily
the case
* easier serialization - I could be wrong, but I suspect being able to
push out terms in the same namespace is going to be easier with than
having to do it term-by-term

and against:
* increased cognitive load - one of the anti-namespace brigade's
arguments is that people are more likely to make mistakes. I reckon
they overstate the case, but that still leaves this as a minor
negative
* complexity of parsing - the strongest argument against, IMHO. I'm
pretty sure your typical developer will have less trouble extracting
discrete name-value pairs than extracting discrete name-value pairs
AND extracting name-value pairs by resolving prefixes
* the perception that namespaces are harmful - impossible to quantify,
but then again worth bearing in mind

I'd say that puts the balance slightly against CURIEs, but with a big
margin of error. My conclusion would be to take the safest route and
not include CURIEs in v 1.0, leaving the option open should there be
significant demand.

Cheers,
Danny.


Cheers,
Danny.

-- 
http://dannyayers.com

Received on Monday, 29 August 2011 10:36:10 UTC