- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Fri, 18 Jun 2004 10:06:01 -0400
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: public-rdf-dawg@w3.org
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