- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 11 Jun 2004 09:59:54 +0100
- To: kendall@monkeyfist.com
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
-------- Original Message -------- > From: Kendall Clark <> > Date: 10 June 2004 02:11 > > On Wed, Jun 09, 2004 at 04:59:18PM -0700, Rob Shearer wrote: > > > I must admit that upon re-reading the UC&R doc I am a bit surprised > > that disjunction has fallen off the radar. I certainly think users > > like being able to form arbitrary boolean constructions. > > FWIW, I was just thinking this today! Along the lines, "don't we need > disjunction as an explicit requirement?" I don't know how or why > disjunction use cases fell out of the doc; maybe this is one of those > many mistakes I've made, but if so, it was totally unwitting. Why would disjunction be an explicit requirement when so many other things (like conjunction!) are not? The UC&R is neither an exhaustive set of requirements nor a design (well - its exhaustive to Kendall in another sense!). As JimH pointed out, other systems introduce disjunction in various careful ways. I take from this that we may need to take a similar, careful approach. Wording a requirement to allow for this later work would seem to be make the requirement meaningless and very hard to agree what it actually means. For example, if the disjunction is effectively making two independent queries, then a design could say "its two queries". Is that then disjunction? Andy > > In other words, I think that disjunction should be an explicit > requirement about disjunction, and I would be happy to help someone > craft a use case that motivates it. > > > actually getting the benefit of the new system. If features like > > disjunction are so rarely useful, then I fear a lot of us have wasted > > a lot of time defining whole new languages like OWL and SWRL for > > expressing things that are even more esoteric! > > I don't think that's the case at all -- rather, I think that > disjunction just fell off the map. Let's get it back on. > > Best, > Kendall Clark
Received on Friday, 11 June 2004 05:07:34 UTC