Re: Another alternative to OR

On Mon, Oct 11, 2004 at 11:44:46 +0100, Andy Seaborne wrote:
> Steve,
> 
> -------- Original Message --------
> > From: Steve Harris <>
> > Date: 11 October 2004 10:03
> > 
> > On Mon, Oct 11, 2004 at 09:44:50AM +0100, Andy Seaborne wrote:
> > > Suppose this is a library with its own accession system and the
> query
> > > is doing the simple thing of accession number to title and author
> > > 
> > > SELECT ?title ?author
> > > WHERE   (?x lib:accession ?n)
> > >         (?n lib:number "123.456.789")
> > >         { (?x dc10:title ?title) OR (?x dc11:title ?title) }
> > >         { (?x dc10:creator ?author) OR (?x dc11:creator ?author) }
> > 
> > Surely you would expand this as:
> > 
> > SELECT ?title ?author
> > WHERE   (?x lib:accession ?n)
> >         (?n lib:number "123.456.789")
> >         (?x ?title ?title)
> >         (?x ?creator ?author)
> > AND ?title == dc10:title || ?title == dc11:title
> >     ?creator == dc10:creator || ?creator == dc11:creator
> > 
> > The point I was making is that union queries offer an additional way
> 
> The message was titled "Another alternative to OR" so I assumed you were
> proposing it be the only way, not an additional way.  My bad.

OK, sorry, the subject wasn't clear.
 
> > of
> > expressing disjunctive expressions without going into territory that
> is
> > unexplored by SQL engines and optimisers.
> 
> I don't see how we resolve this. The SQL engines have subqueries (nested
> queries)including UNION in subqueries,  so I don't understand the
> assertion that this is unexplored.  Kowari does such things for RDF.

I'm not arguing for not allowing the capability, but the syntax is
important. SQL has UNION, and I'm broadly in favour of that, but when a
user issues a UNION queriy they have a pretty clear idea of what is going
to happen, whereas a OR query that is expanded to a UNION to allow
optimisation may present some nasty supprises.

This still feels like research to me, the combination of optional
match and graph disjunction is not widely implemented, and theres no
equivalent experience from the database world.
 
> > I dont buy the argument that its better to let application writers
> > express 
> > the queries in whatever way takes thier fancy (ie. too much rope) and
> > then 
> > optimise it later. I can see a future where I spend a lot of my time
> > explaining to users how to rewrite thier queries to make them perform
> > better.
> > 
> > - Steve
> 
> I can foresee having to explain the "AND ... == ... || ... == ..." form
> as much as any other form if it is not what the user was trying to get
> at. 

But that optimisation is well understood, and in the case of the multiple
predicates I would imagine that the value disjuction is the most obvious
expression, and if its not its clear how you would express that query
using []'s.

There is a big difference between mapping a query with OR in it to an
exact representation with []'s and/or value disjucntions and how a user
will write the query - there not inevitably going to be looking for a
semantically identical result to what we guess a syntax+semantics for
graph disjunction might look like.

For example, you might (very reasonably) be wanting all title values from
any DC schema, but

	{ (?foo dc10:title ?title)
	  OR
	  (?foo dc11:title ?title) }

would not give you that, if the matching rules are what I imagine, whereas

	[ (?foo dc10:title ?title) ]
	[ (?foo dc11:title ?title) ]
	   
does.

- Steve

Received on Monday, 11 October 2004 11:23:34 UTC