RE: candidate requirement: boolean query

-------- Original Message --------
> From: Kendall Clark <>
> Date: 18 June 2004 13:01
> 
> Folks,
> 
> I'm not wedded to this wording, but I think it at least hints at an
> important requirement. Ideally I'd like some kind of first class
> syntax for a boolean query -- SELECT BOOL or SELECT ? or ASK -- but
> the requirement isn't as much about syntax as it is about being able
> to query a graph and get back TRUE or FALSE.

An observation: if we have LIMIT and if we have the trailing flag, "there
was more", then "LIMIT 0" is the same as asking "does this graph pattern
match at all?" and it can be optimized as such on the server - it would
depend on the same decisions elsewhere for disjunction.

That is not to say that syntax for it would not be appropriate.

> 
> 3.x Boolean Query
> 
>   It must be possible for queries to return an explicit representation
>   of TRUE if there is at least one way that the query can be satisifed
>   by the queried graph or an explicit representation of FALSE if there
>   is not at least one way that the query can be satisifed by the
>   queried graph.

No objection to the intent - 

> 
> Additionally, I'd like a syntactic variant to distinguish this kind of
> query, but that's not a necessary component of the requirement as
> written.
> 
> In response to Simon's point about variable bindings being a
> degenerate case of boolean result types, I can agree with that point
> and still want *explicit* boolean return and query types. That is,
> people would be perfectly free to implement Boolean Query by returning
> explicit FALSE or explicit TRUE based on Simon's analysis. But his
> analysis, at least as I understand it and these other issues, is
> orthogonal to how we represent boolean query results on the wire.
> 
> Use cases and motivations: policy-driven RSS feed aggregators;
> privacy-respecting FOAF server; efficiency in the absence of streaming
> results; efficiency for some kinds of (mostly DL, tableau driven) DAWG
> processors.

I don't follow the motivations here (I could guess ones that might not be
your intended reasoning): Kendall, could you pick one UC and draw out why it
motivates "Boolean Query"?

I'd like to understand whether it is important enough to be a requirement: a
UC does that and ties to an interested-in-DAWG community; efficiency is not
so clear cut.

> 
> Interactions: I think this requirement interacts with 4.3 Non-existent
> triples. Which is to say 4.3 doesn't specify whether, if you query for
> a triple that is present in the queried graph, what is supposed to
> happen -- return the triple? return a binding? return TRUE? Further, I
> think that 3.x Boolean Query subsumes 4.3 Non-exisent Triples, but is
> more useful. Sometimes a boolean query would just be a query for
> whether a triple exists. Othertimes it will be more complex.

Not sure 3.x Boolean Query subsumes 4.3 Non-existent Triples.  Example:
suppose the existent triples is being used to 

(?x rdf:type :Person)
(?x :location "Area 51")
NOT (?x :job :engineer)
(?x foaf:name ?name)

gets the names of people who are not engineers in Area 51.  Lots of things
to decide on non-existent triples (I'm not saying they are a good idea or a
bad idea BTW - just pointing out a consequence).

	Andy

> 
> Best,
> Kendall Clark

Received on Friday, 18 June 2004 09:52:34 UTC