- From: Babich, Alan <ABabich@filenet.com>
- Date: Mon, 14 Jun 1999 14:15:17 -0700
- To: www-webdav-dasl@w3.org
There is something I'm not comfortable with. Suppose that search arbiters tell each other what properties they support on what resources as has been hypothesized. That's an interesting issue in and of itself, but, I assume, a solvable problem. Assuming that, suppose you have a query Author != "Joe" OR Amount != 3 OR XYZ IS NULL. Any given resource can support one, some, or all of these properties. By the rules of standard 3 valued logic, you either retrieve the resource or not, depending upon whether the property is supported and, if so, what it's value for that property is. Fine. Here's what I'm not comfortable with: Suppose a search arbiter does not support the Amount property at all, but supports the Author property on some of its resources. You can get tons of hits for this query on such a search arbiter, even though it doesn't support one of the properties. Even more interesting, suppose the search arbiter does NOT support the XYZ property on any of its resources. Then EVERY resource on that search arbiter would be returned by the above query. Seems like such a search arbiter ought to be included to me. So, the decision of whether to include a search arbiter or not is not as simple as "does the search arbiter support the one and only property of this query" for the one-property simple queries used as examples so far, or even "does the search arbiter support ANY of the properties mentioned in this query" for queries mentioning multiple properties. I don't think going down this path is a good idea. Let's not go down this path. Alan Babich -----Original Message----- From: Yaron Goland [mailto:yarong@microsoft.com] Sent: Friday, June 11, 1999 8:56 PM To: 'ejw@ics.uci.edu'; www-webdav-dasl@w3.org Subject: RE: Issue: JW7 (redirects) The idea is that different search arbiters can provide each other with enough information to let them know what kind of data they possess, not necessarily the entire index of that data (which would probably be too large). For example, the search arbiter might tell other arbiters that it supports the "author" property. Thus when you ask your search arbiter for all documents written by John Doe the arbiter will immediately return all the information it has and point you to other arbiters within your request scope which it knows support the author property. You can then execute your query on those other arbiters. So if the request scope is my entire company then there are a number of arbiters I may need to be talking to. Check out http://search.ietf.org/internet-drafts/draft-ietf-find-cip-arch-02.txt, it talks about these sorts of query routing concepts. BTW, as I said in my original letter, I'm not suggesting that we require redirectable multi-result queries in V1. I'm just saying that the feature is definitely useful and should be kept on the table, potentially for future revisions. In fact an easy way to add this later on would be to return a bunch of extra XML goop in the SEARCH response which specifies which other search arbiters to talk to. The beauty of this is that V1 DASL clients will just see search responses and ignore the extra group. V2 DASL clients will know what to do with the extra goop. Yaron > -----Original Message----- > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > Sent: Thu, June 10, 1999 10:44 AM > To: www-webdav-dasl@w3.org > Subject: RE: Issue: JW7 (redirects) > > > > > 2) Also, I don't quite get how an arbiter could *know* that > it has only > > partial knowledge. Either it recognizes the scope (which > is a URI) or it > > does not. (I suppose you could have very smart arbiters > that recognize > > that they don't index certain properties, but know of > another than does, > > but that seems implausible.) > > I've been thinking about how your would configure a search engine to > properly send you to another arbiter, and I just can't > envision how this > configuration could easily be done. > > So, I'm agreeing with Jim Davis. > > - Jim >
Received on Monday, 14 June 1999 17:15:30 UTC