From: Pat Hayes (phayes@ai.uwf.edu)
Date: 02/27/02
>I have several comments on the DQL informal description. > >First, I would much prefer to have a definition of what querying is >supposed to be separated from all the interface ``fluff''. I think that your comment reflects a failure to grasp our point. The idea of allowing wrappers is not "interface fluff", but is an integral aspect of the proposal. I know it mixes together procedural and logical matters, but that is a design decision, since the querying process has both procedural and logical aspects, in our view, and it is better to try to keep them separate. >Second, the informal description has a problem with equality. > >I would thus prefer something like > >QUERYING > >* Knowledge Base - A Knowledge Base is .... (I'm actually not sure what to > put here.) > >* Query Pattern - A Query Pattern is > >* Querying Binding - A Query Binding for a query pattern is a partial map > from the distinguished variables of a query pattern to (singleton sets > of) literals or non-empty sets of URIs plus fragments (identifiers). Why the sets? If that is the set of answers, then you should talk of binding a vector of bindings to a vector of variables, and count those. That is our proposal. >* Bound Query - Given a query pattern and query binding, a bound query is > the result of replacing each variable in the query pattern that has a map > in the query binding by an element of the set that is its mapping, and > adding in pairwise equality statements I'd rather not subsume binding as equality. (Not sure if I follow you here.) >for all the elements of each of > the binding sets. > >* Answer - An answer to a query pattern on a knowlege base is a query > binding for the query pattern such that the knowledge base entails the > bound query for that query pattern. Yes, we say that too >* Single Query Binding - A Single Query Binding is a query binding where > all sets are singletons. > >* Query Answer Expansion - The expansion of a query answer is the set of > single query bindings that map each variable into one of the mappings for > that variable from the query answer. > >* Query Answer Specificity - A query Q1 is more specific than another Q2 if > Q1 maps all the variables that are mapped by Q2 and the value of each map > in Q2 is a superset of the corresponding map in Q1. > >* Query Answer Containment - A query answer Q is contained in a set of > query answers S if all the expansions of Q are less specific than some > element of S. > >* Answer Set - An Answer Set for a query pattern on a knowlege base is a > set of query bindings for the query pattern such that > 1/ each element of the answer set is an answer for the query pattern, and > 2/ any other answers for the query pattern are contained in the answer > set. > > >Only then would I go on to define the interface. I think that we in fact did define all the relevant parts of the above, though much more compactly and with less fuss. We did not go into the specificity/expansion issues, but I would prefer to not impose those kind of conditions on the basic idea of a query answer. I think that *belongs* in the interface design, since it depends on comparisons between answers, and so requires the maintenance of a much larger state in order to implement conformance; such processes are conditions on the entire set of answers, not on answers themselves. And in any case, there may well be applications which do not wish to have all redundancies eliminated. >The interface itself needs to talk about completeness and fairness. Why? It is not a spec designed to be able to *prove* that a KB will eventually answer a query. I don't see any reason to impose completeness and fairness as part of the spec.What problems would this avoid? (I suspect you are letting the demands of theory over-ride those of a standard. ) Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST