Re: notes from our working meeting today on query and rules stuff

From: Eric Prud'hommeaux (
Date: 03/18/03

  • Next message: Richard Fikes: "Draft Updated DQL Specification"
    This follows a discussion between Benjamin Grosof and Eric
    Prud'hommeaux on the content of a paper [1], potentially for refereed
    publication. I am cc'ing to www-rdf-rules and
    to solicit input from others. In particular, I note parallel taxonomy
    development by Andy Seaborne [2]. We should try to synch up at some
    point; soon? or after poking around in the space for a bit?
    On Thu, Mar 13, 2003 at 02:25:02PM -0500, Benjamin Grosof wrote:
    > % notes on RDF Query vs. Rules with Eric Prud'Hommeaux 3/13/03
    in following reply, "..." means not yet integrated. the "..." may be
    followed by a {name} for grouping the issue.
    > agenda:  
    > refine EricP's doc "RDF Query and Rules Status",
    > esp. to use more standard KR/Querying/Rules vocabulary and concepts 
    > then taxonomize the existing RDF Query systems and extract additional
    > requirements and issues as we go along
    > start with "characteristics"
    > "language" characteristics:  we're renaming to be "message" characteristics
    > within the language
    > "once", "query", ... :  rename as "hypotheticals", i.e., 
    > have a concept of a querying session which may extend over several queries
    > and/or message exchanges, where asserted hypothetical facts or 
    > query-definitions/views or rules will be only perishably kept in the
    > source's knowledgebase, i.e., only for the duration of the session
    kept "once" and "query" as forms of "hypothetical". Let me know if the
    text is sufficient.
    > a new issue:  error checking:  need an exception tree similar to Java,
    > with standardized vocabulary and message types
    > o expressiveness of query exceeds what the source can handle
    changed "expressiveness". the fault arises when both the
    expressiveness of the language exceeds the capabilities of the service
    and the client uses some feature of that extra expressiveness, but i
    think involving the expressiveness leads the reader to think that it
    was the expressiveness of the lang that caused the fault, not the
    client's use thereof.
    > - detailed location and construct and explanation details
    ... {faultExplaination}
    not sure how much detail to go into in what goes into a fault.
    excessive structure definition may make it hard to describe
    existing systems.
    > - want this to rely on meta-knowledge about expressiveness lattice of
    > query / knowledge-base sublanguages, probably best to do similarly to RuleML
    ... {*log expressivity}
    Benjamin, I believe I've seen the datalog..prolog... with/without URIs
    chart in RuleML slides. Do you have a pointer?
    > o timeout 
    > - user limit
    > . possibly with explanation of how to raise it
    > - service limit
    > . always this impatient, vs. 
    > . try again, I'm particularly busy now
    > - network problems apparent
    > - source having its own internal problems, try again another time
    > . e.g., other sources it uses
    > new issue/principle:  meta-knowledge and descriptions in source and query
    > of expressiveness,
    >                    completeness, soundness,
    I made these implementation characteristics.
    Are there ways that the language limits these beyond those described in
    >                                             resource-bounds/scale-limits,
    > other characteristics 
    is that size of integers and that sort of thing?
    > - need standard conceptualization then automated ontology and 
    > messages/portions for these immediately above
    > - can be inspired by RuleML approach in this regard
    ... {*log expressivity}
    > expressiveness of querying:
    > - via hypotheticals can define views/queries/sub-queries
    > - hypotheticals enable one to boost effective expressiveness of querying,
    > e.g., from single-atom to conjunction, or from those to querying a 
    > universal implication (rule) (via skolemization)
    ... {hypoBoost}
    not sure this needs mentioning. It is an interesting fact, but may not
    be relevent as all the langs that allow conjunctive rule bodies also
    allow conjunctive queries.
    > design philosophy:  
    > talk about expressiveness of the source and of the query, then match
    > as a first step in the querying session and indeed selection of the source
    > as well as formulation of the query
    Is this aimed at services that use a language that express some
    queries/rules that it can't execute? If so, I think
        addresses this by listing it as a potential error.
    > streaming characteristics:  at querying session, it it one-shot,
    ... {streaming}
    describes the opposite of this. Editorial work required to express
    that the hypothetical branch
    without any assertions is the standard query case (if it is).
    > a max number of query answers,
    put into context of a table answer
    >                                be ready to give more answers, ...;
    > or forward inferencing with notification upon incremental forward 
    > inferencing triggered by updates at source, subscription and standing
    > queries, 
    i believe this is in, or should go in, the subcatagories of
    > EricP first stab at characteristics:    
    > o language
    > o match
    > o variable
    > o binding
    > o API
    > now we're thinking:
    > o session 
    > - one-shot vs. more extended session
    > - kinds of messages that must/can exchange, e.g., incl. 
    ... didn't get this. is this like SOAP manditory headers?
    > . error checking,
    >                   streaming,
    ... {streaming}
    >                              explanations,
    ... {faultExplaination}
    >                                            hypotheticals
    > o expressiveness meta-knowledge
    > - expressiveness of source KR
    > - expressiveness of what queries source can handle
    ... {sourceKRexpr}
    is there a difference between these two? ie, for our purposes, don't
    we define the expressiveness of source KR by which queries it can
    these are described in terms of the requestor demands
    and what the implementation promises
    > - expressiveness of the query
    > - completeness vs. soundness
    > o error checking capabilities, 
    > - expressiveness problems:  relative to expressiveness of 
    >     query and of source
    > - resource problems in computational cycles or storage
    > - other, e.g., network
    > o streaming mechanics
    > - max number of queries vs. no limit
    > - suggest to source to keep intermediate results/work
    We may wish to describe whether a service has the ability to
    communicate this notion. We aren't, technically speaking, designing
    the protocol, but instead characterizing the existing protocols and
    > o hypotheticals
    > - expressiveness
    > - request to assert
    related to {hypoBoost} ? 
    > o proof and explanations: source capabilities, querier requests
    > - source identification
    > - ditto for any delegated or imported sources
    > - derived vs. directly premised/asserted
    > under expressiveness of the query:
    > we can discuss in terms of issues of:
    > o goal expression (alias "match expression")
    > - single arc/atom vs. subgraph/conjunction
    > - ground vs. open (here "open" means with variables)
    Currently punting this domain of query langs with
    At this point, all single arc query languages are outside the scope of
    this survey.
    > - can arc-label/predicate be a variable
    incidentally, i think this is also a soundness dimension for
    and, consequentially, as a message processing requirement
    > - explicit variable names vs. not (in which case are implicit and distinctly
    > named so that cannot join(/match) on them (to each other)
    > . ex. of subtlety:  tell me if there exists someone who is their own lawyer,
    > but don't return a list of bindings just tell me yes or no; this is hard
    > to represent in a query language that uses the same symbol 
    > (e.g., "NULL" or "?blank")
    > for all anonymous-upon-return variables
    > - disjunction (i.e., disjunctive collection of subgraphs)
    > . enum -ish
    > . more general, e.g., arbitrary and nested
    > . ex.:  (x member_of MIT) and (x has_attraction {smooth | goodlooking})
    > - existential quantifiers
    > - universal quantifiers; vs. not
    > - implications (one- or bi- directional) -- often one can do this only via
    > hypotheticals, e.g., (forall x. friendof(Eric,x) => livesin(x,USA) )
    > - variable binding 
    > . must-bind vs. may-bind vs. don't-bind vs. don't report 
    > roughly cf. DQL; this is related to 
    > existential quantification
    > wrt what is binding:  
    > actually:  
    > . binding of single var, 
    > . binding tuple = binding of (conjunct of) tuple(/collection) of var's
    > . binding tuple list = list of such binding tuples
    ... @@@ meeting with benjamin now. will finish later.
    > observation [EricP]:  the current RDF Query languages seem to cluster such
    > that some of the above dimensions are correlated, e.g., the languages
    > that do not permit existential quantifiers also do not even permit distinct 
    > variable names
    probably covered in spirit in
    not sure of meaning of example. what would 
    > issue:  outer join
    > open problem:
    > need to avoid circularity of dependence of sites in delegated/sub- querying, 
    > despite opaqueness of these sites as services,
    > e.g., in semantics of situated LP
    > - "querylock"
    > maybe SOAP people have dealt with this in a way that will help us,
    > e.g., enveloping and failures (and ? circularity)
    research indicate they have not (research being asking Yves Lafon,
    XMLP team contact). it is the sort of thing that an upcoming
    orchestration group is likely to work on.
    i'll look around some more.
    office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
    cell:   +1.857.222.5741
    Feel free to forward this message to any list for any purpose other than
    email address distribution.

    This archive was generated by hypermail 2.1.4 : 03/18/03 EST