- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Mon, 20 Sep 2004 08:54:59 +0100
- To: public-rdf-dawg@w3.org
On Sun, Sep 19, 2004 at 02:04:01 +0100, Andy Seaborne wrote: > > > Steve Harris wrote: > > >On Fri, Sep 17, 2004 at 02:42:37AM -0700, Rob Shearer wrote: > > > >>A user wishes to find all the people who are either of type dog owner or > >>own a > >> pet who is a dog. The common case of no inferencing this is a pretty > >> realistic query.) > > It does seem to be a reasonable query. The contrast we have is between > the implementation view and the application writer view. I'd like to see > queries express what the app writer wants. Yes, I agree in general, but I do have other concerns over disjunction queries. There are other kinds of queries we have disallowed, or agreed to make difficult to express in version 1, so I dont have a big problem with adding another to the list if theres a good reason. OTOH I'm not religious about OR, I am open to being convinced that the implementation burdon is worthwhile. > >> Some sample data: > >> > >>Rob type Person > >>Eddie type Person > >>Eddie type DogOwner > >>Mitch type Person > >>Mitch hasPet Fido > >>Fido type Dog > >> > >>query > >> > >>select $x > >>where ($x type Person) > >> (($x type DogOwner) OR > >> (($x hasPet $y) ($y type Dog)) > >> > >>Is this query correct? > > > > > >Looks good to me, an OPTIONAL equivalent would be: > > > >SELECT $x > >WHERE ($x type Person) > >OPTIONAL ($x type $typeA) > >OPTIONAL ($x hasPet $y) ($y type $typeB) > >AND $typeA = DogOwner || $typeB == Dog > > Steve, > > Would I be right in assuming the AND filters everything from the > WHERE/OPTIONAL/OPTIONAL? > > I'm curious as to what happens when expressions involve unbound variables? > Suppose unbound causes a evaluation error and the query solutiuon is > rejected (this is the usual model for 3-state to 2-state logic - undef > becomes false, any expression involving undef is undefined itself). [I > would strongly prefer the rule here that does depend on evaluation context > wherever possible.] > > If the data is just: > > Rob type Person > Mitch type Person > Mitch hasPet Fido > Fido type Dog > > then one query solution is: > > ?x=Mitch ; ?y=Fido ; ?typeB=Dog // second optional clause > > then the expression > > ?typeA = DogOwner || ?typeB == Dog > > and has ?typeA undefined. > > I think there would need to be a guard function "defined(?x)". The > shortest expression I came up with is: > > AND ( defined($typeA) && $typeA == DogOwner ) > || > ( defined($typeB) && $typeB == Dog ) In this case I take it that defined(x) is equivalent to SQL's "x IS NOT NULL"? I was writing that example from a 2-valued logic p.o.v., but had a question queued at the F2F to mention that we hadn't discussed which way we were going yet. In the 2-value case my expression is fine IIUC (modulo the AND being in the worng place for syntaxes with multiple ANDs), ?typeA = NULL is false, ?typeB = Dog is true, the expression will evaluate as you expect. > This is really testing for which branch the solution when down. > It took a while to work out (maybe my brian isn't in gear) - I wrote out > all the cases and reduced the larger expression. > > And that suggests: > SELECT $x > WHERE ($x type Person) > [ ($x type $typeA) AND $typeA = DogOwner ] > [ ($x hasPet $y) ($y type $typeB) AND $typeB == Dog ] > AND defined($typeA) || defined($typeB) > working by having a test to see that the query went down at least one > branch. That is the sort of thing a query optimizer might do with the > original OR if the language had OR with the implementation changing to > OPTIONAL as a query plan possibility. > > I find the OR query more natural because it was more directly what the > question was. I agree FWIW. However, the action was to find a disjuntion query that could not be expressed with []'s. > >[OT note] I found using $'s for this query quite distracting. > > Certainly a case for one or (as in XOR!) the other Yes, I had though that I would be able to switch easily, but it doesnt appear to be the case - I think the perl part of my brain took over parsing it :) - Steve
Received on Monday, 20 September 2004 07:55:02 UTC