From: Richard Fikes (fikes@ksl.stanford.edu)
Date: 06/28/02
> > It may not be practical for every answer to specify the answer KB > > used to generate it. For many servers this information may be > > proprietary, in any case. So I don't think we should require this. > > Well, I think specifying the answer KB is necessary for making sense of > the answer(s). We are defining the meaning of an answer in terms of a > KB (i.e., that the answer specifies a set of DAML+OIL sentences that are > entailed by the KB). If the client does not know what the answer KB is, > then it seems to me that any given answer is meaningless. What does an > answer of "17" or "yes" mean without knowing the KB that entails that > answer? > > > Have you ever used Google or Yahoo? The KB is the entire web, or as much of it as the company has managed to archive at any > given moment. I guess it could just use its own URL as the KB identifier: but bear in mind that the actual KB in cases like this is > changing every millisecond, so we can't say with a straight face that is the uri of the answer KB in our sense. > Well no, it makes sense to just ask the server what it can find out by whatever means at its disposal, and not be interested in where > it finds it (maybe you trust the server to only use good sources, say). We do this in real life al the time: if I ask you the time, I don't > expect you to tell me who made your watch. Think of the intelligence people's intranet and a query service on it, for example, which > does its best to use the latest information. The KB is constantly changing in this case, but you still want the latest one at the time > you are making the query. > I guess that I think that the idea of 'selecting' a KB and then 'using' it is a slightly old-fashioned metaphor these days. Its more like: > there is information out there, and you try to use whatever sources you can find, provided you trust them enough. What you can > find might be changing all the time, and if you have some deductive smarts maybe you can put things together from a variety of > sources and answer the question that way. It may well be impossible or impractical to say which KBs you actually used, there may > be too many of them. I think this is a quite interesting and important issue. It focuses (again) on what we are designing a language for doing. I indeed have been thinking in "conventional" terms (at our age, I think we should probably avoid using the term "old-fashioned" <g>) of determining sentences that are entailed by a logical theory expressed as a collection of sentences in a knowledge base. That also is the framework that we have used to formally specify what an answer is and what the full set of answers is to a query. If we allow a server to select the answer KB and to select a different answer KB for each answer it produces, then we have no way of specifying the full set of answers to a query. Moreover, if we allow the server to use some perhaps ephemeral KB and to not tell the client what KB was used, then, as I said earlier, and as Dorothy said to Toto: "I have a feeling we're not in Kansas any more." However, here is a constructive suggestion. In cases where a query does not specify an answer KB, we could require the server to include a "support set" justification for each answer. That is, as you argue, it may not be reasonable to always require a server to specify an answer KB. However, it seems reasonable to require a server to specify for each answer it produces either (1) an answer KB or (2) a set of sentences that entail the answer and some kind of source information for each of those sentences. That requirement allows us to keep in tact our notion of what an answer is (i.e., each answer specifies a set of sentences that are entailed by some other given set of sentences). If we allow the server to specify a different answer KB for each answer, we have already lost any way of saying what all the answers are, but I don't think that is a problem. So, allowing the server to simply provide a support set justification for an answer rather than an answer KB doesn't make that problem any worse. I think that suggestion would enable us to both support the extended "nouveau" query-answering paradigm and to maintain our formal basis. We would need to specify what we mean by the source for each of the sentences in the justification, but we probably need to do that anyway. > > At any rate, we need to be painfully exact about what we do > > mean, and Im not sure that just saying 'no further answers are > > entailed' is exactly what we intend here (?). > > Well, I am not sure what else to say. It seems that whatever we say to > formally define what an answer is applies here. Namely, there provably > aren't any more. > > > Having no more answers to give isn't the same as no other bindings are entailed, that was my point. Somone could argue, for > example: of course its provable that there aren't any more answers: if there were, my server would have delivered them. Our > definition of 'answer' doesn't in itself specify what the set of *all* answers is. Well, 'none' only makes sense when the answer KB is specified, and in that case we know that the bindings must come from the vocabulary of the KB (i.e., the constants that explicitly occur as terms in the KB or are defined in DAML+OIL). So, 'none' means there are no more possible constants that could be bindings for the variables. I suppose, indeed, that will rarely be known, since even though the server might know there are no more objects in the domain of discourse that satisfy the query (e.g., for the value of a property known to have only one value), it would rarely know that no other constant in the KB's vocabulary is equal to the answer(s) it has already returned. So, perhaps we should simply drop that option in the spec. > > do we want to allow the case where a query premis is > > specified, but no other KB is allowed to be used? If so, how does the > > query specify that? > > Yes, I think we want to allow that case. Haven't considered how to > specify it. I guess we need some reserved word like "Empty KB" to use > as the answer KB. > > > The Webbies will want it to be a legal URIref, so maybe we should provide it as part of the daml namespace, like > http://www.daml.org/2001/03/daml+oil/EmptyKB Agreed. Richard
This archive was generated by hypermail 2.1.4 : 06/28/02 EDT