W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

RE: Proposal to drop disjunction requirement

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 30 Sep 2004 15:35:42 +0100
Message-ID: <8D5B24B83C6A2E4B9E7EE5FA82627DC9396886@sdcexcea01.emea.cpqcorp.net>
To: "Steve Harris" <S.W.Harris@ecs.soton.ac.uk>, "DAWG public list" <public-rdf-dawg@w3.org>

-------- Original Message --------
> From: Steve Harris <>
> Date: 30 September 2004 14:02
> In order to close the disjunction issue, I propose that we drop any
> requirement for graph disjunction in this version of the query
> For those who we're at the Bristol F2F, a quick summary of why I don't
> like disjunction:
> OR is the only infix operator we have prposed so far, so it
> the syntax from the point of view of learning it, and makes the
> precidence 
> rules more complex and requires logical ()'s to scope expressions.

The issue of grouping isn't just because OR is infix.  It's about saying
something about a query pattern.  We already have it for optionals.  It
is natural for application writers who are likely to use SPARQL as they
are likely to be programming.

The objective to me is to have a useful query language in a reasonable
It's a tradeoff.  Even if, in practice, many of our implementations are
just doing no better than what the app writer can do, there is a case
for a clearly expressed query that can be maintained.  

I don't see the implementation costs as that bad (I agree they are not
zero).  If the app writer has to do this by issuing two queries and
doing the OR themselves, then SPARQL engines (sparklers?) can do the
same.  The engines may do better when there are other parts to the query
(shared expression evaluation).

It actually helps to ship one query with disjunction across the web and
do it (naively) in the query server.  In practice, it saves a

I'm not arguing strongly for disjunction but there needs to be a
stronger reason.  It's a good thing (tm) that the app writer can write
what they want. 

> Disjuntion provides a lot of the same capability as optional matches,
> but 
> as a developer I've only seen feature reqests expressed in terms of
> optional match, no disjunction. Many disjunctive queries can be
> expressed 
> in terms of optionals and value disjunctions, but I have not attempted
> to 
> show wether all can be or not.

I too have seen optional match as a request far more than disjunction.
May be Tucana can comment as they have disjunction.

There is an example, restricted use case of disjunction on predicates:

(?x dc10:title ?t ) OR ( ?x dc11:title ?t)

That can specifically be addressed another way - the point is there is a
use case here.

(?x ?p ?t ) AND ( ?p urieq dc10:title || ?p urieq dc11:title )

does do it but its complicated.


> Getting good coverage for test cases will be hard. Esspecially in
> combination with optional it allows you to write some really complex
> expressions. Testing all combinations will be difficult.
> - Steve
Received on Thursday, 30 September 2004 14:36:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC