From: Brandon Amundson (bamundson@bbn.com)
Date: 09/26/01
I liked Richard's list of issues not supported and offer a few other issues that I would suggest that we also want to cover. This is from work done on querying and explaining frame systems [1,2,3,4] done first in the context of the CLASSIC description logic-based system and later other DL-based systems. How does the query answerer return portions of the answers (or pruned answers) rather than complete (presumably very complicated) answers? Does the user specify what portions of an answer (or proof) are interesting? or is this previously determined by either the system or a knowledge engineer? Deborah McGuinness dlm@ksl.stanford.edu [1] <A HREF=3D"http://www.cs.rutgers.edu/~borgida/">Alex Borgida</A> and <A=20= HREF=3D"http://www.ksl.stanford.edu/people/dlm ``Asking Queries about Frames.'' In Proceedings of Fifth International Conference on the Principles of Knowledge Representation and Reasoning Cambridge, Massachusetts, November, 1996. Morgan Kaufmann. Also appears in Proceedings of International Workshop on Description Logics, Cambridge, Mass., November 1996. http://www.ksl.stanford.edu/people/dlm/papers/kr96-abstract.html [2] http://www.ksl.stanford.edu/people/dlm" ``Explaining Reasoning in Description Logics'' Ph.D. Thesis, Rutgers University, 1996. Technical Report LCSR-TR-277. http://www.research.att.com/~dlm/papers/thesis-abstract.html [3] Franz Baader, http://www.cs.rutgers.edu/~borgida and http://www.ksl.stanford.edu/people/dlm ``Matching in Description Logics: Preliminary Results,'' In Proceedings of the 1998 International Workshop on Description Logics, Trento, Italy. June, 1998. An updated version appears in Proceedings of the Sixth International Conference on Conceptual Structures (ICCS'98), M.-L. Mugnier, M. Chein (editors), Lecture Notes in Artificial Intelligence, Springer, 1998. [4] http://www.cs.rutgers.edu/~borgida Enrico Franconi, http://www.cs.man.ac.uk/~horrocks http://www.ksl.stanford.edu/people/dlm and http://www.bell-labs.com/user/pfps http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-22/borgida .ps ``Explaining ALC subsumption'' Proceedings of the International Workshop on Description Logics - DL-99, pp 33-36, Sweden, July 1999.=20 In a message dated 9/24/2001 12:21:54 PM Pacific Daylight Time,=20 fikes@KSL.Stanford.EDU writes: > DQL 0.1 provides a language for expressing a query to a DAML+OIL > knowledge base and a language for expressing an answer to such a query. > Although languages for expressing a query and an answer are clearly > needed, they support only a subset of the essential information that > needs to be exchanged during query-answering. Specifically, they do not > support the following: > > * How many answers to a query does the query asking agent (which we > will refer to as the client) want? All of them? At most n? All that > can be found in k seconds? =E2=80=A6 > > * What does the query answering agent (which we will refer to as the > server) return when it has been asked for all answers and it concludes > that there are an infinite number of answers > * What does the server return when it has found all the answers it can > (or has the resources to find), but doesn't know whether it has found > all possible answers? > > * What does the server return when it knows how many answers there are > (e.g., from a cardinality restriction), but has no object names from the > knowledge base for those answers? (I.e., is the server to return > anonymous objects as answers to a query?) > > * How does the client ask for the answers "a batch at a time" so that > it can dynamically decide whether it wants the server to produce more > answers. > > * How does the client ask for proofs (or other explanatory information) > of the answers provided by the server? > > Such requirements would lead us to expand DQL to include what might be > considered to be a set of commands (e.g., "Ask"), each with a set of > arguments and expected return values. For example, we might posit an > "Ask" command as follows: > > Ask Command > > * Arguments: kb, query premise, query pattern, answers needed > (either a positive integer or "All") > > * Results: answer collection, answer status > > where the answer status has one of three values indicating: > > * The answer collection is all possible answers; > > * There are infinitely many answers and if n answers=20 > were requested the answer collection contains as many=20 > of the n answers as the server could produce or if all=20 > answers were requested the answer collection contains=20 > a sampling of answers; > > * The answer collection contains all the answers the server can > produce and there may be more. > > We may also want to posit a collection of commands that enables the > client to pose a query and get back a process handle (aka, a > continuation) that can be sent to the server in subsequent commands to > incrementally request answers to the query. > > Yulin Li and I have been developing a design for such expansions to DQL > 0.1, but rather than send out that design at this point, I propose that > the committee consider the need for such an expansion. When we reach a > consensus on whether and in what form to address the issues raised in > this message, we can then consider specific design proposals for doing > so. > > Richard > I liked Richard's list of issues not supported and offer a few other issues that I would suggest that we also want to cover. This is from work done on querying and explaining frame systems [1,2,3,4 done first in the context of the CLASSIC description logic-based system and later other DL-based systems. How does the query answerer return portions of the answers (or pruned an= swers) rather than complete (presumably very complicated) answers? Does the user specify what portions of an answer (or proof) are interesting? or is this previously determined by either the system or a knowledge engineer? Deborah McGuinness dlm@ksl.stanford.edu [1] http://www.cs.rutgers.edu/~borgida Alex Borgida and http://www.ksl.stanford.edu/people/dlm Deborah L. McGuinness. ``Asking Queries about Frames.'' In Proceedings of Fifth International Co= nference on the Principles of Knowledge Representation and Reasoning Cambrid= ge, Massachusetts, November, 1996. Morgan Kaufmann. Also appears in Proceedi= ngs of International Workshop on Description Logics, Cambridge, Mass., Novem= ber 1996. http://www.ksl.stanford.edu/people/dlm/papers/kr96-abstract= .html http://www.ksl.stanford.edu/people/dlm" Deborah L.McGuinness. ``Explaining Reasoning in Description Logics''. Ph.D. Thesis , Rutgers University, 1996. Technical Report LCSR-TR-277. http://www.research.att.com/~dlm/papers/thesis-abstract.html Alex Borgida, http://www.ksl.stanford.edu/people/dlm">L Deborah L. McGuinness. ``Matching in Description Logics: Preliminary Results,'' In Proceedings of the 1998 International Workshop on Description Logics, Trento, Italy. June, 1998. An updated version appears in Proceedings of the Sixth International Conference on Conceptual Structures (ICCS'98), M.-L. Mugnier, M. Chein (editors), Lecture Notes in Artificial Intelligence, Springer, In a message dated 9/24/2001 12:21:54 PM Pacific Daylight Time, fikes@KS= L.Stanford.EDU writes: DQL 0.1 provides a language for expressing a query to a DAML+OIL knowledge base and a language for expressing an answer to such a query. Although languages for expressing a query and an answer are clearly needed, they support only a subset of the essential information that needs to be exchanged during query-answering. Specifically, they do not support the following: How many answers to a query does the query asking agent (which we will refer to as the client) want? All of them? At most n? All that can be found in k seconds? What does the query answering agent (which we will refer to as the server) return when it has been asked for all answers and it concludes that there are an infinite number of answers? What does the server return when it has found all the answers it can (or has the resources to find), but doesn't know whether it has found all possible answers? What does the server return when it knows how many answers there are (e.g., from a cardinality restriction), but has no object names from the knowledge base for those answers? (I.e., is the server to return anonymous objects as answers to a query?) How does the client ask for the answers "a batch at a time" so that it can dynamically decide whether it wants the server to produce more answers. How does the client ask for proofs (or other explanatory information) of the answers provided by the server? Such requirements would lead us to expand DQL to include what might be considered to be a set of commands (e.g., "Ask"), each with a set of arguments and expected return values. For example, we might posit an "Ask" command as follows: Ask Command Arguments: kb, query premise, query pattern, answers needed (either a positive integer or "All") Results: answer collection, answer status where the answer status has one of three values indicating: The answer collection is all possible answers; There are infinitely many answers and if n answers were requested the answer collection contains as many of the n answers as the server could produce or if all answers were requested the answer collection contains a sampling of answers; The answer collection contains all the answers the server can produce and there may be more. We may also want to posit a collection of commands that enables the client to pose a query and get back a process handle (aka, a continuation) that can be sent to the server in subsequent commands to incrementally request answers to the query. Yulin Li and I have been developing a design for such expansions to DQL 0.1, but rather than send out that design at this point, I propose that the committee consider the need for such an expansion. When we rea= ch a consensus on whether and in what form to address the issues raised in this message, we can then consider specific design proposals for doing so. Richard
This archive was generated by hypermail 2.1.4 : 04/02/02 EST