From: Richard Fikes ([email protected])
Date: 06/27/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? Also, the 'none' server continuation makes no sense if the KB is not specified. 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. 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. ... > 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. > 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 > 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. > 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. > 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. 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. Cheers, Richard
This archive was generated by hypermail 2.1.4 : 06/27/02 EDT