RE: Another alternative to OR

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.

> 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 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. 

Our common use case for a restricted form of disjunction has been where
the user wishes to write "dc10:title or dc11:title"  Expressing as
constraints is one way but not the only one.  There are others and a
clever optimiser may do different things based on knowledge of the data.

((The use of the Xpath/Xquery F&O equality operator is not necessrily
the same as putting the term in the query unless RDF engines are
*required* to implement datatyping rules.))

	Andy

Received on Monday, 11 October 2004 10:45:20 UTC