Re: Postscript on Today's DQL Discussion

From: Richard Fikes (
Date: 06/27/02

  • Next message: pat hayes: "Re: Postscript on Today's DQL Discussion"
    > 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
    > 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.

    This archive was generated by hypermail 2.1.4 : 06/27/02 EDT