From: pat hayes (phayes@ai.uwf.edu)
Date: 09/23/02
Quick comments on Joe's comments. >FYI -- > >-------- Original Message -------- >Subject: DQL > Date: Thu, 19 Sep 2002 08:06:40 -0700 > From: joe rockmore <rockmore@cyladian.com> > To: fikes@KSL.Stanford.EDU > >richard...i read your recently-released DQL abstract specification with >interest. a few comments that may improve it (i don't have any >substantive comments on the language design, as this is not my >expertise): > > * i think examples throughout would help the explanations. > true, true. > > * i think you need to better introduce your idea of what an answer KB > is. you state "The set of DAML sentences that are used by the > server in answering a query is referred to as the answer KB." which > is clear enough, but i think most people would not think of this > as a knowlege base (although they might think of it as a base of > knowledge from which the answers derive). in particular, many > people will think of a set of DAML sentences as defining the > ontology, since that is the strong focus of OWL. ? I fail to follow the distinctions being made here. An ontology IS a KB, right? Maybe we (ie DAML+OIL+WEBONT+RDFS) ought to agree on some terminology and stick to it carefully when describing this stuff. > i think what you > really mean is that an answer KB is the set of all sentences about > instances (what OWL calls individuals), Nooooo. We need to put in words which firmly suppress this way of reading the document. It isn't enough to not say it, we need to explicitly deny it. >where they are interpreted > according to the ontology (which is comprised of sentences about > classes, properties, etc.). is this correct? No, its not correct. That is, maybe some applications will be like this, but its not a requirement. One can query other things than databases. > if so, i think a bit > more explanation (and some examples) would help clarify this point. Well, something needs to be clarified. > > * i am still bothered by your approach to answer bundles with > continuation (cf our discussions at the last PI meeting). you > address some of my concerns in the paragraph titles '"How Many" > Queries' (although i had a hard time parsing that title, thinking > you meant how many queries, rather than queries about how many > answers). "how many answer?" queries might be a better way of putting it, then. >it seems to me that a server, if it can process a set of > continuations and eventually reach termination, can do so and > return the number of answers that it will provide if the queryer > keeps asking for contiuations. Yes, it *can*. The issue is, how long is it going to take to do that? So heres a way to provide 'how many' answers: write a piece of wrapper code which, given a 'how many answers' query for the pattern P on the KB K, it generates a DQL query to K using P with no bound on the bundle size. It then keeps querying the KB to termination, storing the answers in a list. Then it runs through the list and eliminates redundancy, maybe (depending on what y'all think counts as 'an answer'), and finally it returns the length of the list. Now, this thing USES DQL, but it delivers answers using some other protocol which refers to numbers of answers. > that is, not all servers will reach > termination, but if they do, then they can do so and return the > number of answers before providing any actual answers. i think you > need to somehow include this type of answer, as if it takes, for > example, 100,000 continuations until termination, i might want to > know that before i keep asking for more answers. But if the server has had to generate B* 10|5 answers, where B is the bundle size, in order to find this out, surely all the computational harm has already been done. [Later: see below] > i do understand > the thorniness of this issue, but i think you can under some > circumstances (but not all) provide an answer to "how many" > queries, and DQL should support this. I guess the point is valid under some circumstances, eg when communication bandwidth for answers is much more expensive than compute time on the server. Maybe we should think more about this. It would be OK to allow for 'how many answer?' queries as long as a server could legitimately respond that it was unable or unwilling to give the answer. We could just add it as a special query form. > * i understand that you are not ready for specifying the response to > a justifcation request, but can you tell me what your thinking is > along these lines? i would like to see something here like a > backtrace of any inferences made to provide an answer (assuming its > not explicitly stated in some DAML sentences about the instance), > but other than that i am not sure what should, or could, be > included. please enlighten me. Backtrace = proof, to a first approximation. So Joe is already enlightened. > > * in the discussion on answer bundles, you state, "There is no > provision in DQL for a query to indicate an upper bound on the > total number of answers in a dialog, but a client can terminate a > question-answering dialog at any time by ... simply by not > requesting any further continuations." doesn't this approach > require the server to maintain the state of the continuation, > perhaps forever, in the case that the client later asks for > continuation? The idea of the continuation is that it allows the server to place this burden on the client. The server shouldnt have to remember anything: the continuation should enable it to restore its state in order to carry on with the query. The continuation might for example be an encoding of where in a DB the search had progressed to, which could be encoded as values to be inserted into a hash table, say. >or is there some kind of timeout (that you said you > are not addressing) here that says after some time period the > server can safely drop the state of a query, and the dialog would > have to start from scratch if the client wanted more answers? This is exactly the issue we wanted to avoid, which is why the server even bothers to send the continuation to the client in the first place. If the server had the (impossible) task of caching the states of all its queries, then the continuation could be trivial. Pat Hayes -- --------------------------------------------------------------------- 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 : 09/23/02 EDT