Re: A reason for dropping seperate AND clauses

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,




Received on Thursday, 27 January 2005 07:00:42 UTC