Re: Suggestions for DQL changes made at Portland

From: Deborah McGuinness (dlm@ksl.stanford.edu)
Date: 10/25/02

  • Next message: Richard Fikes: "Re: Suggestions for DQL changes made at Portland"
    Thanks Pat for the email summary.  I agree that the email contains the
    highlights along with some good explanation.
    
    To give some additional background,
    Pat and I chaired the DQL and inference rule break out session at the daml
    PI meeting.[1]
    Before the meeting, I sent out mail to the daml mailing list asking for
    input particularly on what people wanted from a query language in general
    and what modifications/clarifications people were interested in for DQL.
    I had prepopulated a set of powerpoint slides with the input that came in
    and then we updated it in real time from the discussion session.  The
    outbrief is available online[2].
    
    also, incase people are interested, I also ran a breakout session on
    explanation  following the same path - asking for input in advance and
    generating a briefing [3].
    
    
    [1]
    http://www.daml.org/cgi-bin/agenda?http://www.daml.org/meetings/2002/10/pi/pi-2002-10
    
    [2] http://www.daml.org/2002/10/pi-querybof/querybof_files/frame.htm
    [3]http://www.daml.org/2002/10/pi-explanationbof/explanationbof_files/frame.htm
    
    ps.  in case you were wondering, i was looking for owls for owl dialect
    naming when i was generating the viewgraphs....
    
    deborah
    
    pat hayes wrote:
    
    > This message is an attempt to summarize the suggestions made at the
    > PI meeting concerning changes to the DQL spec.  Deb (or anyone) if I
    > have missed anything that you can recall, please say so.
    >
    > 1. Non-fixed bundle size
    >
    > A client can return a revised bundle size bound with each
    > continuation. If this is omitted, the previous bundle size bound is
    > assumed.
    >
    > 2. Number of answers.
    >
    > Optionally, a bundle can begin with a number indicating the number of
    > answers still to be delivered *after* the current bundle. The answer
    > number of any bundle containing a terminator should be zero. There is
    > no default value: if the answer number is omitted, then no
    > information is supplied about the number of answers.
    > (This is to allow large RDBs to supply potentially useful information
    > which they will often have archived in any case. It is optional,
    > since other kinds of server may be unable to supply this information.)
    >
    > 3. Passing answer continuations between clients.
    >
    > A client may pass an answer continuation to another client. If a
    > client C passes a continuation to the server, then the server should
    > send the next answer bundle to C, regardless of the previous client.
    > (This is to allow a client to 'feed' answer bundles to another process.)
    >
    > 4. Answer templates.
    >
    > A query must supply an answer template, which is a character string
    > (?? Piece of DAML?? I prefer the more generous definition) containing
    > some of the variables in the query pattern. If no answer template is
    > explicitly provided, then the query pattern is the default answer
    > template (Sandro's idea).
    >
    > 5. Answers
    >
    > Each answer consists of an instantiation of the answer template in
    > which all variables are replaced by values. A value may be a Uriref,
    > a literal (??) or a bnode (in general, it should be a term in the
    > logical sense.) . "Must-bind"  variables cannot be bound to bnodes.
    > The logical scope of a bnode in an answer is that answer itself. In
    > particular, if two answers use the same bnode, that should not be
    > taken to mean that those bnodes refer to the same entity. (In
    > general, it is recommended that answers in a single answer bundle do
    > not share bnodes. ??)
    >
    > If a bnode given in an answer is used in a subsequent query, no
    > logical connection is assumed between the two occurrences of the
    > bnode.
    >
    > 6. Session ending.
    >
    > A series of transactions between client(s) and server consisting of a
    > query followed by  answer bundles and continuations is an 'answering
    > session'. If such a session is interrupted or terminated by an
    > underlying network control layer, then it is permissible for a server
    > to be unable to continue the answering session even if it is sent a
    > continuation. In such cases the server should respond with an answer
    > bundle containing the terminator 'end'.
    >
    > --------
    >
    > OK, I think that is all. I recommend that we make these changes to
    > the spec, and the obvious ancillary simplifications that they produce.
    >
    > Pat
    >
    > --
    > ---------------------------------------------------------------------
    > IHMC                                    (850)434 8903   home
    > 40 South Alcaniz St.                    (850)202 4416   office
    > Pensacola                                       (850)202 4440   fax
    > FL 32501                                        (850)291 0667    cell
    > phayes@ai.uwf.edu                 http://www.coginst.uwf.edu/~phayes
    
    --
     Deborah L. McGuinness
     Knowledge Systems Laboratory
     Gates Computer Science Building, 2A Room 241
     Stanford University, Stanford, CA 94305-9020
     email: dlm@ksl.stanford.edu
     URL: http://ksl.stanford.edu/people/dlm/index.html
     (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801
    705 0941
    


    This archive was generated by hypermail 2.1.4 : 10/25/02 EDT