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

Re: bnodes

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 2 Oct 2007 23:40:08 +0100
Message-Id: <2FB2A409-3C8B-4FC3-948B-B54F5328761C@cs.man.ac.uk>
Cc: Owl Dev <public-owl-dev@w3.org>
To: "Chimezie Ogbuji" <chimezie@gmail.com>

On Oct 2, 2007, at 11:28 PM, Chimezie Ogbuji wrote:

>> Because they cause lots of problems and their semantics offer no
>> gains. For example, with existential Bnodes sparql query answering
>> for RDFS
Please read what I wrote a bit more carefully and interpret it a bit  
more charitably.

>> is *NP-Complete* in *DATA COMPLEXITY*.
>> That should be a scarey fact for anyone interested in scalability.
> But Bijan, this is only true if you have a requirement for RDFS
> entailment as part of your matching mechanism.

Yes. This is my point. A problem with BNodes semantics is that they  
are relatively harmless in inexpressive languages, but then kill you  
later. All of the stuff at inexpressive levels can, more or less, be  
accomplished in other ways (or are, IMHO, not a good idea).

> There is nothing scary
> about basic term-structure matching at *very* large volumes.

So this is an argument against existential semantics. thanks. Oh  
wait, it's *my* argument :)

In any case, it's a bit of a leap to go from "dodged one bullet" to  
"dodged all bullets". The Chileans have shown that SPARQL query  
answering is logspace  (thus relational database like) in data  
complexity for matching against "abstract graphs". But that doesn't  
mean that it will be particularly easy to implement well. (Relational  
databases aren't particularly easy to implement well or scalably.)

Received on Tuesday, 2 October 2007 23:07:00 UTC

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