Re: DQL specification --

From: Neil Goldman (
Date: 04/14/03

  • Next message: Ian Horrocks: "regrets"
    I believe these are all straightforward. Except maybe for the last one. :)
    1. The choice of the term process handle is unfortunate. There is nothing
    about processes in this specification, and nothing that even suggests there
    would need to be a direct relationship between one of these handles and a
    process, as the term is used in operating systems. Certainly someone might
    implement a server,or a client,  where such a correspondence existed -- but
    then, I could implement one where a correspondence to a FILE existed and
    that wouldn't justifiy calling them file handles.  The description of a
    process handle in the document is just fine -- why not simply call it a
    query handle and avoid the unhelpful tie-in.
    2. The specification should provide a 3rd reserved termination token,
    QueryError, as the suggested (or better yet, required) response from a
    server when a client fails to meet its obligations in the protocol.   There
    are numerous requirements placed on the client, e.g.
    *	The must/may/dont lists must be disjoint 
    *	Each variable must be used in the query pattern (or answer kb
    *	bundle size, if specified, is a positive integer 
    *	process handle in a server continuation must be the one most
    recently produced by the server
    It's certain that any server implementation is going to have to detect
    client failures to satisfy some, if not all, of the client's obligations.
    We might as well provide a well-defined response from the server to deal
    with it. (most client-server protocols has some sort of "error" response
    from the server)  As an implementer of a client, I would be unhappy if end
    were ambiguous as to whether the server was unable to answer or my request
    was malformed.
    3. In the description of the variable lists, the document says "every query
    variable must be an element of exactly one of these lists". Since membership
    in one of these lists is what defines query-variablehood, I'd suggest
    rephrasing this as
    "these lists must be pairwise disjoint"
    4. The description of a query answer states that
    "Each element of the binding set is a lexical mapping that associates..."
    I can't imagine what the qualifier lexical is adding here.  Perhaps  a
    proposal for an external syntax for this protocol might choose a
    representation that could justifiably be described as lexical, but I don't
    see what it adds in this proposal.
    5. Although this specification does not commit to an external syntax, is it
    the intent that any syntax chosen will be such that it is impossible for a
    VARIABLE (one of the things in the may/must/dont bind lists) to coincide
    with a uri or value that could actually appear in a premise or a KB?
    6. The spec says that an answer includes the query to which it is an answer.
    (as one of 3 required parts)
    Minor nitpick -- Won't all the answers in the answer collection of an answer
    bundle contain the SAME query?  If so, then why not promote it to the anwer
    bundle, rather than make it part of each answer?  The same applies to the
    server reference component of an answer, if it is common to all answers in
    an answer collection.
    That promotion in fact is what was done in the example published in
    although it is not clear whether that example is really meant to comply with
    this spec --e.g., it omits the required server reference component of the
    answer, and it repeats only the query pattern, not the entire query, in the
    Major nitpick -- why should the server be sending the entire query, or even
    the pattern, back to the client?  This is not motivated in the spec -- the
    only thing I can think of is that it allows us to deal with cases where a
    client is interleaving multiple conversations with the same server, and so
    needs to know which query a given bundle pertains to.  But that can be
    handled by simply allowing the client to provide an opaque name --an
    uninerpreted string-- as a component of the query, and requiring the server
    to repeat that name as a component of each response.
    Maybe I'm completely off-base on the motivation?  Because the server doesn't
    always send back an answer bundle. Sometimes it sends back a termination
    token instead.  Since a termination token does not include a query and a
    server reference the way an answer does, there would be no way for the
    client to determine which of multiple outstanding queries was being
    terminated.  Must be something else going on here...
    The document at
    <>  has had its content, but not its HTML
    title, updated:
    <HEAD><TITLE>DQL (August 2002)Abstract Specification</TITLE>
    Neil Goldman              Tel:   (310)578-5350 x204
    Teknowledge Corporation   Fax:   (310)578-5710
    Suite 231
    4640 Admiralty Way
    Marina del Rey, CA 90292

    This archive was generated by hypermail 2.1.4 : 04/14/03 EST