W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2008

Evidence of user attitudes toward BNodes (was Re: Proposal and Test cases (Re: skolems: visible differences?))

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Sat, 19 Jan 2008 18:48:25 +0000
Message-Id: <E6565DF1-DE42-43E4-85EE-229B9230BABB@cs.man.ac.uk>
Cc: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
To: Bijan Parsia <bparsia@cs.man.ac.uk>

I want to re-emphasize: Handling bnodes as singular terms (i.e.,  
names) is, for me, primarily driven by user considerations. The fact  
that BNodes as variables make reasoning much harder (even in RDFS) is  
a strong consideration, but given that BNodes as variables are not  
what users want or expect *or* what systems (including RDF systems)  
give them, is by far the strongest, and I would say overwhelming,  
reason.

In the last telecon, I said:
	Bijan Parsia: In the sparql working group, people like, Oracles Fred  
Zemke, clearly believed that bnodes were singular terms.

I tracked down the email that I recall backed this up:
	http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/ 
0008.html

To be precise, I think Fred clearly believed that they *should be*  
singular terms.

"""The user is relying on distinct
blank nodes to represent distinct line items.

Of course, from the point of view of "RDF Semantics"
that would be a redundant graph, for example, one that
asserts "There exists a line item whose part is XYZ,
quantity is 1 and price is 10.99" and asserts again
"There exists a line item whose part is XYZ, quantity is 1 and
price is 10.99".  Thus one could say that this is a misuse
of RDF.  This may be technically true, but I wonder if insisting
on this point will really serve the users.  If you read the RDF
Primer, the application design above makes sense. You have a line
item; you don't want to bother creating an IRI for each line
item; so you make a blank node for each line item."""

Cheers,
Bijan.
Received on Saturday, 19 January 2008 18:48:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 19 January 2008 18:48:40 GMT