From: Richard Fikes ([email protected])
Date: 11/07/01
> >First of all, I am trying to be careful with terminology and to leave > >design choices open. As I have described it, a "query" has multiple > >components (e.g., a knowledge base, a premise, a query pattern, etc.), > >one of which is a "query pattern". Without committing to the form of > >the query pattern, I am only saying that it is a specification of > >relationships among sets of objects and that a "query pattern instance" > >specifies a sentence that is entailed by the query KB. So, I am not > >saying "that the query is entailed by the KB". I am saying that a query > >instance specifies a sentence that is entailed by the query KB conjoined > >with the query premise. (That is being picky, but I think is worth > >pointing out.) > > OK, sorry I was careless. However, I am finding it hard to follow > these distinctions. You have a query pattern instance which > *specifies* a sentence that is entailed by the KB. So are the > QPinstance and the entailed sentence distinct things? What is the > relationship between them? (How does one specify the other?) And can > you motivate all these distinctions, or give an example to show why > they are needed? We have not yet decided what the syntax is for a query or a query result, and so I used the phrase "a query pattern instance ... specifies a sentence" to leave open the syntactic form of the query pattern. I don't see how a query pattern can be a DAML+OIL sentence because we don't have the needed existential quantifiers and logical connectives. Actually, I am still confused as to whether or not we have existential quantifiers in the language. For example, how would you represent in DAML+OIL the query pattern "Find x such that x is a parent of Joe and a resident of California"?. And then how would you represent the query pattern instance corresponding to the answer "Bill is a parent of Joe and a resident of California"? I had proposed earlier that a query pattern be a collection of triples each of which can have variables as any of its elements and each of which corresponds to (specifies?) an RDF statement. The entire pattern would be considered to be a conjunction of RDF statements. A query pattern instance would then be a collection of RDF statements considered to be a conjunction of those statements. That all seems to work. However, in that proposal neither the query pattern nor a query pattern instance is a sentence in DAML+OIL. Hence, the use of the term "specifies". Regarding the distinctions being made. It seems to me that a query has multiple components or properties (e.g., a query pattern, a knowledge base, a premise, specification of how many pattern instances are being requested, etc.). Similarly, a query result has multiple components (e.g., sets of bindings, justifications, information about the number of query pattern instances, etc.) So, I am identifying, describing, and naming those components. > >> ?? What is a query answer, exactly? (I thought that bindings to query > >> variables *were* query answers (??)) > > Any response to that one? I said: >my recommendation is that for >now we consider a query answer to consist of a set of bindings for a >subset of the query variables > >I am calling all of the variables that occur in the query pattern query > >variables. > > Oh. I wish you would not do that, as it is likely to be very > misleading. What about bound variables in the pattern, for example? I > would strongly suggest distinguishing query variables as those > variables whose binding is considered part of the answer, and leave > questions of what other variables are in the pattern entirely alone. I am open to changing the terminology I have been using. However, as I said above, I am unclear as to what variables can occur in DAML+OIL and hence what variables can occur in a query pattern other than those that make it a pattern and therefore need to be instantiated in the query-answering process. Perhaps an example of a DAML+OIL query containing a bound variable would help. > >Does your statement "an anonymous node is not a constant, so the > >question doesn't even arise" mean you agree that a binding will be a > >constant? > > I was going on your assumptions, is all. (I would like it to be an > arbitrary term, myself. ) But what would such an arbitrary term be in DAML+OIL? > > If not, what else would it be? > > > >> HOWEVER, what this does raise as an issue is, is such a binding > >> considered to be to a *node* or to the label on the node? Its not > >> easy to see how to transfer a node as a binding, but maybe we need to > >> take that idea more seriously (?) > > > >I am assuming bindings to be to constants. > > So not nodes, right? Right. Bindings would be labels of nodes. More later. Richard
This archive was generated by hypermail 2.1.4 : 04/02/02 EST