Suggestions for DQL changes made at Portland

From: pat hayes (
Date: 10/24/02

  • Next message: pat hayes: "request for feedback on domain and range semantics."
    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 
    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 
    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.
    IHMC					(850)434 8903   home
    40 South Alcaniz St.			(850)202 4416   office
    Pensacola               			(850)202 4440   fax
    FL 32501            				(850)291 0667    cell	

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