From: pat hayes (phayes@ai.uwf.edu)
Date: 10/24/02
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
This archive was generated by hypermail 2.1.4 : 10/24/02 EDT