Re: Comments on DQL from Joe Rockmore

From: pat hayes (
Date: 09/23/02

  • Next message: Richard Fikes: "Proposed XML Syntax for DQL"
    Quick comments on Joe's comments.
    >FYI --
    >-------- Original Message --------
    >Subject: DQL
    >    Date: Thu, 19 Sep 2002 08:06:40 -0700
    >    From: joe rockmore <>
    >      To: fikes@KSL.Stanford.EDU
    >richard...i read your recently-released DQL abstract specification with
    >interest.  a few comments that may improve it (i don't have any
    >substantive comments on the language design, as this is not my
    >    * i think examples throughout would help the explanations.
    true, true.
    >    * i think you need to better introduce your idea of what an answer KB
    >      is.  you state "The set of DAML sentences that are used by the
    >      server in answering a query is referred to as the answer KB." which
    >      is clear enough, but  i think most people would not think of this
    >      as a knowlege base (although they might think of it as a base of
    >      knowledge from which the answers derive).  in particular, many
    >      people will think of a set of DAML sentences as defining the
    >      ontology, since that is the strong focus of OWL.
    ? I fail to follow the distinctions being made here. An ontology IS a 
    KB, right? Maybe we (ie DAML+OIL+WEBONT+RDFS) ought to agree on some 
    terminology and stick to it carefully when describing this stuff.
    >  i think what you
    >      really mean is that an answer KB is the set of all sentences about
    >      instances (what OWL calls individuals),
    Nooooo. We need to put in words which firmly suppress this way of 
    reading the document. It isn't enough to not say it, we need to 
    explicitly deny it.
    >where they are interpreted
    >      according to the ontology (which is comprised of sentences about
    >      classes, properties, etc.).  is this correct?
    No, its not correct. That is, maybe some applications will be like 
    this, but its not a requirement. One can query other things than 
    >  if so, i think a bit
    >      more explanation (and some examples) would help clarify this point.
    Well, something needs to be clarified.
    >    * i am still bothered by your approach to answer bundles with
    >      continuation (cf our discussions at the last PI meeting).  you
    >      address some of my concerns in the paragraph titles '"How Many"
    >      Queries' (although i had a hard time parsing that title, thinking
    >      you meant how many queries, rather than queries about how many
    >      answers).
    "how many answer?" queries might be a better way of putting it, then.
    >it seems to me that a server, if it can process a set of
    >      continuations and eventually reach termination, can do so and
    >      return the number of answers that it will provide if the queryer
    >      keeps asking for contiuations.
    Yes, it *can*. The issue is, how long is it going to take to do that? 
    So heres a way to provide 'how many' answers: write a piece of 
    wrapper code which, given a 'how many answers' query for the pattern 
    P on the KB K, it generates a DQL query to K using P with no bound on 
    the bundle size. It then keeps querying the KB to termination, 
    storing the answers in a list. Then it runs through the list and 
    eliminates redundancy, maybe (depending on what y'all think counts as 
    'an answer'), and finally it returns the length of the list. Now, 
    this thing USES DQL, but it delivers answers using some other 
    protocol which refers to numbers of answers.
    >  that is, not all servers will reach
    >      termination, but if they do, then they can do so and return the
    >      number of answers before providing any actual answers.  i think you
    >      need to somehow include this type of answer, as if it takes, for
    >      example, 100,000 continuations until termination, i might want to
    >      know that before i keep asking for more answers.
    But if the server has had to generate B* 10|5 answers, where B is the 
    bundle size, in order to find this out, surely all the computational 
    harm has already been done. [Later: see below]
    >  i do understand
    >      the thorniness of this issue, but i think you can under some
    >      circumstances (but not all) provide an answer to "how many"
    >      queries, and DQL should support this.
    I guess the point is valid under some circumstances, eg when 
    communication bandwidth for answers is much more expensive than 
    compute time on the server. Maybe we should think more about this. It 
    would be OK to allow for 'how many answer?' queries as long as a 
    server could legitimately respond that it was unable or unwilling to 
    give the answer. We could just add it as a special query form.
    >    * i understand that you are not ready for specifying the response to
    >      a justifcation request, but can you tell me what your thinking is
    >      along these lines?  i would like to see something here like a
    >      backtrace of any inferences made to provide an answer (assuming its
    >      not explicitly stated in some DAML sentences about the instance),
    >      but other than that i am not sure what should, or could, be
    >      included.  please enlighten me.
    Backtrace = proof, to a first approximation. So Joe is already enlightened.
    >    * in the discussion on answer bundles, you state, "There is no
    >      provision in DQL for a query to indicate an upper bound on the
    >      total number of answers in a dialog, but a client can terminate a
    >      question-answering dialog at any time by ... simply by not
    >      requesting any further continuations."  doesn't this approach
    >      require the server to maintain the state of the continuation,
    >      perhaps forever, in the case that the client later asks for
    >      continuation?
    The idea of the continuation is that it allows the server to place 
    this burden on the client. The server shouldnt have to remember 
    anything: the continuation should enable it to restore its state in 
    order to carry on with the query. The continuation might for example 
    be an encoding of where in a DB the search had progressed to, which 
    could be encoded as values to be inserted into a hash table, say.
    >or is there some kind of timeout (that you said you
    >      are not addressing) here that says after some time period the
    >      server can safely drop the state of a query, and the dialog would
    >      have to start from scratch if the client wanted more answers?
    This is exactly the issue we wanted to avoid, which is why the server 
    even bothers to send the continuation to the client in the first 
    place. If the server had the (impossible) task of caching the states 
    of all its queries, then the continuation could be trivial.
    Pat Hayes
    IHMC					(850)434 8903   home
    40 South Alcaniz St.			(850)202 4416   office
    Pensacola,  FL 32501			(850)202 4440   fax

    This archive was generated by hypermail 2.1.4 : 09/23/02 EDT