Raw notes on Peter Ryall's Ranked List Query presentation at the 2/96 ZIG meeting

Peter: Advanced Search group making the work public now. Good feedback in April Current status: Draft available on the Web on the NIST Web site, including the ASN.1, in several forms. Some copies of the ASN.1, plus the description. Overview: set up presentation ? Yes. later. Brief status report: Intention was that there might be different flavors of the query for different segments of the industry. Broad spectrum of perspectives. Decided to try to craft a single definition. After last ZIG meeting, we worked out some details, and simplified some things. We want this to be a working spec, but think it is ready for experimental implementation, and testing with real search systems and clients. This has a wide range of uses, and can be tuned all the ways from a WAIS-style query to very sophisticated query using all the controls exposed by the query definition. Waiting for an interoperability group to come forward: perhaps 3-4 organizations. Lots of optional features which could be left out Initially. The ASN.1 could be (and may need to be) tweaked further. Would like a critical review of the proposal. Invitation for additional participation to interested parties. There are parties who have expressed interest in implementing this.

Bob: concern re multiple ways of doing things. Some overlap between what can be expressed in Type 1 vs this. Will some of this be brought back into the Type 1 Query eventually? How much do you need to implement to satisfy the minimal level. How much will servers implement? Does this functionality need to be profiled? Bob: some of this can be handled via diagnostics. Kevin: there are some substantial interaction differences with the Type102 query. Modeled as an iteration of Search Requests/Responses.

(handout - page references are to handout)

Kunze interested in a profile of a standard Web form interface to this query type. Restriction of the search scope was strongly driven by Chris Buckley. Q; what is advantage of restriction up front vs doing 2-stage search (type 1 vs type 102). If you only do the restriction part, do you end up with a type 1 query? Yes. This query type encapsulates the Type 1 query. The type 102 query can contain multiple queries within it, and the restriction query can be applied to all or only to one sub-query.

P. 2. The relevancy-based limits control the size of the result set created. Not only the order of the result set, but also the size of the retrievable result set. Mark: Q: can the restriction be used in reverse, eg, loosen the criteria to retrieve the requested number of retrievals. A: No. Possibly add a parameter to be able to express this. Noted.

P. 3 There are different algorithms being discussed in the industry for how to combine results from multiple need statements. Client controls what information is returned from type 102 (reformulated query or final response or...). Bob: Q: what types of overlap are there between type 102 and type 1 queries? A: some of these are kludges defined in profiles like the WAIS profile.

P. 4. Reform-Clause. allows for expansion of a particular operand, method is external definition. fine level of control.

P. 5 All components of the Top-level query are optional. Restriction expression can be either at the query or sub-query level.

P. 6. Attributes are optional. Some implementors will not use attributes at all. Defer to the attribute architecture group the best way to organize, model, define attributes. Attribute discussion is orthogonal to the query definition. Q: fuzzy equality attribute? No implication that only these attributes could be used with this query. Some features of this query type could be used with existing systems. Separate out the attribute set from the RLQ query.

p. 7. If the operator knob is turned all the way one direction, does it becomes truly boolean? Maybe yes, and maybe no. There are some underlying difficulties with this assumption. Mark would like type 102 to subsume type 1. Ray: need for different operators in type 102. Ralph would like the knobs on the terms, combined with the true boolean operators. Why not allow booleans with type 102? Suggestion that type 102 query be re-crafted so that its features can be applied to the type 1 query. 1 problem: the model is different for the two queries. RPN vs Type 102. In type 102, clause level (operator) against all the terms in the operand. There is an interest in adding attributes to operands in type 1. Go ahead and pull back some of these features into type 1, but do not disturb the type 102 work. Mark: re-craft the type 102 such that it can completely contain the type 1 query, so that it can be reduced to type 1. Ray: could describe the type 102 as a sequence of type 101 query and RLQ query, where latter is optional. Could be reduced to a type 1 query in the simplest case. This would provide a migration path for implementors to move toward supporting the type 102. Ralph: how is this useful? Cliff: Mark attacking this at the wrong level. The fact that some of these features are useful in type 1 doesn't mean that we reconstruct type 102. Import the subset of type 102 features which are useful within type 1. Perhaps take 102 and craft it in such a way that it becomes the future single query type. Unresolved.

Ralph's concern re the type 102 query is that is the union of multiple queries requirements. 70-80% of the query represents common usage. Some exotic features in there which might get light usage. Mark: perhaps pursue the 80%, and defer the 20%. Cliff: do this within the construct of the V3 type 1 query (backwards compatibility vs upward compatibility). In this world, we need parameterization of operators as well as attributes. The degree of parameterization within this experimental query is different than that taken by type 1. Ray: define V4 type 1 which is backwards compatibility. Peter: caution: ability to include boolean operators within the type 102 query. We will have a problem with intermixed operators within a given query. cliff: this is a semantic problem rather than a syntactic problem.

Denis: This is not an ASN.1 problem. Peter is explaining the status of this queDenis: This is not an ASN.1 problem. Peter is explaining the status of this query, which is in progress, and ready for experimental usage to explore usefulness of some of the features. Ralph: but the point is that the direction taken is independent of type 1. Ralph and others want to be able to bring some of these back into type 1. If these useful parts are stolen and added to type 1, then type 102 may die. Request that the group reexamine this in light of this concern. Ralph: interested in a sense of commonality of features among implementors.