From: Deborah McGuinness ([email protected])
Date: 10/25/02
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 > [email protected] 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: [email protected] 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