From: Richard Fikes (fikes@ksl.stanford.edu)
Date: 09/19/02
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. * 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 think what you really mean is that an answer KB is the set of all sentences about instances (what OWL calls individuals), where they are interpreted according to the ontology (which is comprised of sentences about classes, properties, etc.). is this correct? if so, i think a bit more explanation (and some examples) would help clarify this point. * 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). 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. 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. 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 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. * 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? 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? thx for helping me understand this important aspect of DAML. i expect that Horus will migrate to DQL as soon as practical, and it is important that we understand what is going on, as well as have confidence that it is stable in its basic form. -- ...joe +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=+ a. joseph rockmore, phd -|- cyladian technology consulting 873 santa cruz avenue, suite 204, menlo park, ca 94025-4629 voice 650/614-3791 -|- fax 650/326-1699 -|- cell/pager 650/714-5696 short email to cell/pager -|- <16507145696@pacbellpcs.net> web site url -|- http://www.cyladian.com+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
This archive was generated by hypermail 2.1.4 : 09/19/02 EDT