Re: JSON Emergency Brake

On 24 August 2011 22:14, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:

> Currently, round-tripping is supported; my own implementation actually relies on this. I parse data into a graph and use that graph for subsequent serialization, rather than sticking within the JSON space.

That's good to hear!

> CURIEs have been moved to an advanced section, and really just fall out of term support. There are use cases where prefixed URIs are quite useful. However, I could consider changing to PNAMES if that had enough support, but I don't think the processing rules really demand that restriction.

Sorry, PNAMES??

>> Yes, it will get verbose if a large number
>> of terms is needed in a single document, but I doubt very much that
>> would be the norm among the target audience. (An @vocab mechanism is
>> also mentioned in the spec, though I'm not sure if that's current or
>> orphaned artifacts of a previous draft).
>
> @vocab is still intended to be in there, but we may have lost some text along the way.

Ah, ok, thanks.

> CURIEs, PNAMEs and QNAMEs all have a fairly long history in RDF, and thinking of a first-class RDF serialization without some support for prefixing seems out of step with the goal of having JSON-LD be such a language. Given that prefix support pretty much falls out of having terms already, I don't think it should be removed.

Generally I really like namespace prefixing, but if possible I think
it should be avoided in JSON-LD as there's a perception that it's a
bad idea, e.g. see [1]. I don't agree with the blanket argument
(prefixes work a treat in Turtle), though there is certainly plenty of
anecdotal evidence that it can confuse developers, and there are one
or two valid problems (e.g. fragile copy & paste).

Whatever, it only serves to abbreviate URIs, and there are other
options for that such as are already in JSON-LD : providing a
document-wide (base/racine) URI for terms and the simpleName-URI
mapping in @context.

Prefixing is a good choice when there are likely to be lots of terms
from multiple namespaces, but I think that's likely to be the
exception than the rule in applications using JSON. We're not really
talking general-purpose interchange here, more like Web 2.0 API-style
data provisioning. In this context, by far the most common scenarios 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.

Cheers,
Danny.

[1] http://microformats.org/wiki/namespaces-considered-harmful


-- 
http://dannyayers.com

Received on Wednesday, 24 August 2011 21:22:02 UTC