W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2011

Re: JSON Emergency Brake

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Wed, 24 Aug 2011 17:50:26 -0400
To: Danny Ayers <danny.ayers@gmail.com>
CC: Gregg Kellogg <gregg@kellogg-assoc.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Message-ID: <48B6A765-0A96-4360-A77B-DD02FA8D2FE2@greggkellogg.net>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:18 UTC