From: pat hayes (phayes@ai.uwf.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. > Also, the 'none' server continuation makes no sense if the KB >is not specified. I agree, but I have trouble with the 'none' in any case. >As far as proprietary information goes, the server could at least >provide the client with a uri-ref for the KB, even if the client could >not get access to the content of the KB. > >> should we allow a *query* to say >> that it will only accept answers with an answer KB specified? I think >> that would be good. > >As per my comment above, I think that is the only case that makes >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. > Certainly, if we allow for the possibility of answers being >returned without a KB (which I don't think we should), then we should >allow the query to specify that a KB must be specified with an answer. > >By the way, I had been assuming that when a query does not specify a KB >that the server selects an answer KB and uses it for all the answers it >generates. I suppose we can allow the server to specify a KB for each >answer and therefore have different KBs for different answers. ... Of course. Servers will be used in all sorts of modes like this. In general, the operation of the server is usually going to be invisible to the client. 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. > > One general way to handle this would be have the query contain a 'KB >> specification' which could be either a list of urirefs (KB names) or >> one of the three kinds of variable. A must-bind variable means, I >> must know the answer KB. A no-bind means I don't care. Bindings to >> these variables are allowed to be arbitrary lists of urirefs, to >> allow for the case where the server uses a lot of KBs in its answer. >> Then Yahoo (say) can just refuse to accept queries with a must-bind >> KB spec, for example. > >That seems like a reasonable mechanism. But I don't think we should >allow those options at all. That is, I think that the server needs to >supply a KB for each answer it produces, where a KB is either a uri-ref >or a set of uri-refs. If those urirefs have to identify sets of DAML assertions, I don't think this is feasible in general. > > Suppose the query specifies the answer KB >> to be used, but the server simply doesn't know the KB uriref? It >> could just hand back 'unknown', but it would be more informative to >> allow a new kind of token, maybe 'unknown-KB'. > >I think this falls into the category of the large number of elaborations >that could be made to the interaction protocol. The stance I had in >mind is that we define what we consider to be the essential protocol >elements and allow servers to add features to the protocol as they >like. I don't think this case is essential OK, fair enough. > > In general, we should >> write the spec so that things like the set of tokens can be extended >> in future, in any case, right? > >Yes. As I said, we specify the essential protocol elements and allow >servers to add features to the protocol as they like. > >> A question about 'none'. Do we want this to mean that there are no >> other answers entailed by the KB > >Yes. > >> or that there are no other answers >> *which fit the specifications of the query* that are entailed, or >> that there are no other answers *of the kind that this server knows >> how to reason about* that are entailed....? Or maybe something else? > >I don't think so. > >> I guess I am suspicious about it being possible for most servers to >> be absolutely certain that there are no other entailed answers *at >> all*. > >I don't think we should care about the difficulty of determining >'none'. The server is not required to provide that information. This >is a case where we are enabling the server to tell the client something >that it may know that is likely to be useful to the client. We are not >requiring the server to do any additional work to determine whether >'none' is true. OK, fair enough. I just wanted to be sure what we meant here. > >> 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. > > Since we don't say what a justification is, and since there isnt >> (yet) any defined notion of 'proof' in DAML, why not just omit this, >> and just say that an answer might contain other stuff to be defined >> in future, and a query might contain other stuff which is relevant to >> said other stuff in the answer (???) > >Well, we could do that, and I don't think we should hold up release of >the DQL spec while we design justifications. However, answer >justification seems like an essential element in query-answering, >particularly for the Semantic Web (as Hendler often insisted), and I >would like to acknowledge that essentialness in our spec. OK, lets leave this the way it is. > >How about if we say that there will be multiple forms of justifications >allowed and specified in later versions of DQL, and that for this first >version we will specify only a justification that is a set of the >sentences from the KB that entail the answer. It seems to me that we >can confidently say that such a "support set" of sentences is going to >be one of the forms of justification that we will want DQL to support. >So, we could start off with just that one. So, a server could provide >other forms of justifications as an ad hoc feature, but must provide the >"support set" form of justification in order to conform. > >> Should we allow a query to specify any (lower or upper) bounds of the >> number of answers it wants per answer bundle? An upper bound seems > > like it might be useful. > >Yes. Does indeed sound useful. > >> 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 Pat -- --------------------------------------------------------------------- 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 : 06/28/02 EDT