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

Re: JSON-LD bnode canonical naming algorithm

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Tue, 31 May 2011 11:53:53 -0400
To: Dan Brickley <danbri@danbri.org>
CC: glenn mcdonald <glenn@furia.com>, Dave Longley <dlongley@digitalbazaar.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Message-ID: <BDA18482-4828-43C1-86DC-869C98F49F57@kellogg-assoc.com>
On May 31, 2011, at 3:02 AM, Dan Brickley wrote:

> On 30 May 2011 23:57, glenn mcdonald <glenn@furia.com> wrote:
>>> or simply author using URIs for nodes having multiple references.
>> +1
>> The idea that there even needs to be a "bnode canonical naming algorithm"
>> seems to me close to proof that blank nodes should be dropped from JSON-LD.
>> And from LD, period. And from RDF...
> My understanding is that one of the core values being explored on
> public-linked-json is something like "accessibility of this stuff to
> ordinary developers.". This includes concise, readable,
> mainstream-style markup.
> It might be hard to balance that with a rigid rule "whenever you
> mention any thing apart from basic strings and datatypes you MUST also
> always supply a full URI in RFC2396 notation".

Not necessary to supply a full URI. Note that "_:a" and "#a" look pretty similar, but given a @base, the later is a URI.

Also, anonymous BNodes might still have a place, as they don't pose the same problem for normalization.

My assertion on restricting named BNode use was really directed to normalized representations, not necessarily arbitrary graphs.

> We have a classic design tradeoff here. There are costs associated
> with not identifying things unambiguously. And there are costs
> associated with being forced to supply Web identifiers for every
> passing mention of any object. We annoy some developers by having
> verbose URIs everywhere; we annoy others by not. That suggests to me
> that this is not a decision that should be made at the core spec
> level, but one that ought to be left to evolving deployment practice
> instead.
> cheers,
> Dan
Received on Tuesday, 31 May 2011 15:55:19 UTC

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