W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > November 2009

Re: PROPOSAL: Errata text regarding defining a prefix of '_'

From: Toby Inkster <tai@g5n.co.uk>
Date: Sun, 15 Nov 2009 18:44:23 +0000
To: Shane McCarron <shane@aptest.com>
Cc: Ivan Herman <ivan@w3.org>, "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <1258310663.10171.30.camel@ophelia2.g5n.co.uk>
On Sat, 2009-11-14 at 16:28 -0600, Shane McCarron wrote:
> I agree that the technique described will work. I am surprised that
> you think it ok okay to change the bnode in the emitted triples. While
> you might not think it has a meaning, others may...

The RDF Semantics[1] recommendation says this about identifiers for
blank nodes:

> While node identifiers such as '_:xxx' serve to identify blank nodes
> in the surface syntax, these expressions are not considered to be the
> label of the graph node they identify; they are not names, and do not
> occur in the actual graph.

i.e. node identifiers are syntactic sugar. They're a very useful bit of
syntactic sugar in fact, because without them it would be pretty much
impossible to serialise a graph containing cyclical references between
blank nodes. But they're not a part of the RDF graph itself - so,
assuming that all an RDFa processor is required to output is an RDF
graph, it cannot be a requirement for RDF processors to retain blank
node identifiers.

That said, retaining blank node identifiers when possible is a good
thing - it helps the readability of any resultant serialisation, in much
the same way as retaining CURIE prefixes of the input RDFa does.

The method I outlined does retain blank node identifiers in the vast
majority of cases, and can be guaranteed not to produce collisions, yet
it's still possible to implement as part of a one-pass algorithm.

____
1. http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Received on Sunday, 15 November 2009 18:45:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:33 UTC