W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2007

Re: bnodes

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Wed, 03 Oct 2007 10:38:11 +0100
Message-ID: <47036303.3040804@hpl.hp.com>
To: Bijan Parsia <bparsia@cs.man.ac.uk>
CC: Chimezie Ogbuji <chimezie@gmail.com>, Owl Dev <public-owl-dev@w3.org>

I've been staying out of this thread, but have decided to put my usual 
opinion ...

Essentially I defend the current design of URI nodes and b-nodes.

The defence is not that the design is perfect but that the problems 
identified on both sides, are also problems with any solution.

If I understand Bijan correctly, bnodes should be replaced with named 
nodes because various computations that interest Bijan become cheaper.

To some extent this is a red herring in any particular application, 
because it is the choice of the knowledge engineer whether to name nodes 
or not. The option to not name nodes is necessary because many nodes do 
not have any compelling name, they are essentially structural, relating 
one thing with another. Using methods such as skolemization, of course, 
it is possible to gensym up names (there is no name shortage). But then 
if I have skolemized one way, and you have skolemized another (or 
equivalently, we are talking about the same thing, except that we 
gensymmed different names), we still have a lot of work to do, to 
discover that we are talking about the same thing. This, at first blush, 
appears to be where any complexity that Bijan 'saves' by requiring 
names, reappears. The complexity is not a result of naming, but a result 
of application requirements.

To argue the other way, to those who are suggesting dropping named nodes 
- the problems with named nodes, all reemerge with the IFP from 
literals. It's perhaps a more elegant design, but computational it is 
fairly equivalent.

Received on Wednesday, 3 October 2007 09:38:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:15 UTC