Re: JSON Emergency Brake

On Aug 24, 2011, at 2:21 PM, Danny Ayers wrote:

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

PNAMES are used by SPARQL and the latest Turtle spec. Basically CURIE's without a '/' allowed in the local part.

>>> 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).

Many things lead to fragile copy & paste. Leaving out an @context, for example, would wreck havoc. In Microdata, copying the @itemprop without the containing @itemtype would also lead to a lot of problems. If terms are described in @context and that's missed the terms wouldn't have appropriate definitions. Using a term as a prefix doesn't really change anything.

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

If the consensus of the group is that CURIEs should go, I suppose I'd go along with that, but they serve useful goals (IMHO) and really just fall out of the term support anyway.

> Cheers,
> Danny.
> 
> [1] http://microformats.org/wiki/namespaces-considered-harmful
> 
> 
> -- 
> http://dannyayers.com

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