Re: Banishing "bNode"

In short: yes bNode can change, it is just a token.  However...

>>>Pat Hayes said:
> 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.

I think this is way more than a simple terminology change.

I can't find your suggestion in the archives; can you please cite
the URI?

  [Aside: can people do this in general when they refer to previous emails]

10 minutes later I find it
  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0210.html
in the thread "Resolution of: #rdfms-identity-anon-resource"


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

If you remember how much worse the previous token name anonNode and
the "anonymous resource", "anonymous node" terms were ... bNode and
"blank node" has helped a lot.

So I will make this change in the next WD draft. Goodbye bNode token.

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

Let me be clear here: you are changing the RDF model to allow the
graph nodes to be labelled with literals.  Has this been decided?
What is the difference between labelled and "identified with"?  I'm
sure this is a use/mention thing, but I want to be absolutely clear.

This really deserves a thread on its own, with a new subject,
not just Re: Banishing "bNode" 


However, assuming this happens, you therefore require a change in the
N-Triples to handle it.

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

giving examples, you are talking about something like using terms
  _id1:"blah"
  _id2:"blah"
to distinguish two ocurrences of the same literal "blah".

Your 'small' change also allows:
  _id1:<uri>

So unless that is a requirement of the MT, we should stay with just
  <uri>
which works just fine.

So if this literal labelled nodes, literal subject stuff is a
requirement, I propose to make the following changes to the last
public WD http://www.w3.org/TR/2001/WD-rdf-testcases-20010912/#ntriples

  amending:
    subject ::= uriref | nodeID | nodeID":"literal
    object  ::= uriref | nodeID | nodeID":"literal | literal

  deleting;
    bNode

  adding:
    nodeID  ::=  '_:' name

Where the bare literal object is used when the same literal is never
used as a statement subject.  The above changes also mean all
existing N-Triples files remain legal.


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

Sure; I just want a clear and good reason for allowing literals as
subjects, labelling nodes with literals so that once this is done, we
can change the N-Triples software to deal with them.  This means
additional complexity in comparing graphs, as far as I can tell.

Dave

Received on Monday, 15 October 2001 07:38:12 UTC