W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > January 2005

Re: A reason for dropping seperate AND clauses

From: Phil Dawes <pdawes@users.sourceforge.net>
Date: Wed, 26 Jan 2005 17:23:31 +0000
Message-ID: <16887.53779.820388.698892@gargle.gargle.HOWL>
To: andy.seaborne@hp.com
Cc: public-rdf-dawg-comments@w3.org

Hi Andy,

Seaborne, Andy writes:
 > 
 > Phil Dawes wrote:
 > >
 > > It occured to me that one reason why you might not want to have a
 > > seperate 'AND' clause in sparql query language is that it makes it
 > > more cumbersome to hint an efficient search order to a query processor.
 > 
 > Two points:
 > 
 > First - a query processor is responsible for an efficient order.  There is 
 > always a tension between expressivity for the application writer to clearly say 
 > what they want and an expression of how to do it.

True - I was really suggesting this as a possible implementation-
specific hack to circumvent problems with query optimisers.

 > 
 > Second - in SPARQL the AND keyword isn't a fixed clause (like, say,
 > RDQL).

Ah didn't realise this - that reduces the problem.

 > > 
 > > select ?res, ?label
 > > where (?label LIKE "%foo%")
 > >       (?res, rdfs:label, ?label)
 > >       (?res, rdf:type, ?type)
 > > 
 > > (LIKE is some regex operator - don't know what the appropriate sparql
 > > is for this and I'm not currently on the internet.)
 > 
 > Assuming that the part ''(?label LIKE "%foo%")'' is an expression
 >    AND ?label LIKE %foo%
 > then this query because, if executed in that order there are no results.  ?label 
 > is unbound, only to be bound later.
 > 

I don't understand this - isn't ?label bound to the set of all URIs
and literals that match the regex '*foo*'?

(My understanding is probably crippled by the fact that I'm
approaching this from a relationaldb implementation perspective (my
sparql query processor[1] works similarly to 3store)

Many thanks for your response,

Cheers,

Phil

[1] http://www.sf.net/projects/veudas
Received on Thursday, 27 January 2005 07:00:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:47 GMT