W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2001

Banishing "bNode"

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Sun, 14 Oct 2001 19:20:45 -0500
Message-Id: <p05101001b7efd44d0675@[]>
To: w3c-rdfcore-wg@w3.org
Before we make N-triples normative, could I reiterate a suggestion I 
made in a recent mailing for serious consideration by the WG? It is 
simply a terminological change, but I think it would be a great help 
in avoiding confusion, and also would pave the way for a slight 
extension to Ntriples which I think we (or someone else who has the 
task of extending RDF) are going to need in the fairly near future.

The actual change is simply to re-christen the syntax class <bNode> 
in the Ntriples syntax to be <nodeID>, and to refer to those names of 
the form '_:name' as  nodeIDs or "node identifiers". The nodes in the 
RDF graph which these things indicate can still be called 'blank 
nodes' in text;  but that technical term 'bNode' is dangerously 
ambiguous between the Ntriples label itself and the blank node in the 
graph that it indicates, and I suspect that the confusion caused by 
this ambiguity would be greatly reduced if we only used "node" 
terminology to refer to nodes, and used some other terminology to 
refer to identifiers in Ntripledocs. So I would suggest avoiding the 
term 'bNode' completely. Wherever it occurs in text, replace it with 
'blank node' if it refers to the node, and by 'node ID' if it refers 
to the '_:name' thingie in an  Ntriples document.

The future extension I think we (or someone) will need, is to allow 
nodeIDs to identify not just blank nodes but also nodes labelled with 
literals, since there may well be a need to have the same literal 
mean different things on two different nodes if we have any kind of 
sophisticated datatyping, and then we will need a way to distinguish 
which one of these literal nodes is being referred to in each triple 
in the Ntriples document. This would be a very small extension to 
Ntriples, in which a node ID could be used to refer to *any* node, 
even if it also had a label.
(Here's a crude BNF for Ntriples++ (this allows literals as subjects, 
but its easy to fix that):

<triple> ::=  <obj> <uriref> <obj> .
<obj> ::= <label>|<nodeID>|nodeID>:<label>
<label> ::= <uriref>|<literal>

This forces every node to have *some* kind of name in the Ntriples 
doc, even if they are blank.  Blank nodes are then nodes which are 
only referred to by a nodeID, ie have no label.  But you can refer to 
other nodes as well, if you want to weave a different graph. It's 
RDF-harmless to allow extra nodeIDs since they don't appear in the 
graph itself. The only real processing difference would be that a 
parser for this would have to check that no node was assigned two 
labels, and barf if it found that. )

The point being that I think this will be needed in RDF2 if not in 
RDF1 (depends on how sexy literal typing is going to be allowed to 
get) , and once it is needed, the "bNode" terminology is going to be 
particularly confusing and unfortunate. We could fix this now pretty 
easily, since Ntriples is still kind of in-house., Once we make it 
normative it will be much harder to change.

Pat Hayes

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Sunday, 14 October 2001 20:20:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:05 UTC