Re: candidate requirement: boolean query

On Fri, Jun 18, 2004 at 02:52:10PM +0100, Seaborne, Andy wrote:

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

Yes, I tried to address this implementation/syntax distinction.

> > 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"?

One existing UC? 

I mentioned two at length in my reply to Simon earlier today. A
summary:

1. I'm working on a policy driven RSS aggregator as a bit of research
   infrastructure. Users specify constraints in a policy language;
   things like: "at least n items in the past m days"; "items earlier
   than date d"; "items which contain string s in description".

   Same things go for a FOAF aggregator: "more than n foaf:knows";
   "has mbox"; "school == <uri>".

   I want to turn these policy bits into DAWG queries and only
   aggregate if the constraints are satisifed.

2. A better use case is one in which I don't care or need to know the
   values of variable bindings. In other words, I want to know whether
   a FOAF file has an email address and at least one foaf:knows, but
   for privacy reasons I can't know what those values *are*. I might
   send a boolean query to a DAWG server, and it would answer true or
   false, but not send me any variable bindings.

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

I think it's useful for FOAF work; I would find it useful in
aggregation, too. I'm sure there will be people who oppose this
because they oppose *every* requirement or design objective. But there
you go.

I'm not sure whether it should be a requirement or design objective;
however, some designs that would satisfy it seem pretty simple. That
is, you seem to need an on the wire representation of the boolean
values and a form of query syntax.

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

Good point.

Kendall

Received on Friday, 18 June 2004 10:08:06 UTC