notes from today's JC telecon about built-ins in rules language

From: Benjamin Grosof ([email protected])
Date: 06/10/03

  • Next message: Mike Dean: "Joint Committee telecon tomorrow 17 June"
    Hi folks,
    Here are notes from today's JC telecon, about built-ins in our rules 
    language effort.
    (Inline'd and attached too, as usual.)
    % notes from JC telecon 6/10/03
    % by Benjamin Grosof
    agenda  discussion on built-ins
    Benjamin Grosof chairing this week in Mike Dean's absence
    participants:  Said Tabet, Pat Hayes, Sandro Hawke, Benjamin Grosof
    is important practically, e.g., for DAML Rules tools;
    issue of which particular, and which kind of, built-ins should be integrated,
    and how (e.g., as virtual fact base queryable in roughly DQL-ish fashion),
    with the semantics of the rule language V1
    Sandro:  XQuery has an enormous list of built-ins;
    seems there's a lot of overlap with us, incl. wrt
    integration with XML-Schema datatypes;
    there are syntax issues, e.g., they use hyphens in their naming;
    there are lots of them, probably hundreds
    process suggestion:  instead of drafting a list of built-ins, we say how one
    should use externally defined built-ins and suggest that the standard
    one is the standard set for XQuery, e.g., op and fun stuff
    issue:  OWL objects -- what kind of structure do we need to provide URI's for
    each one of classes, properties, and individuals
    - Benj:  and also subsets of a KB's axioms
    there are naming conventions used in XML-Schema community;
    we should reuse the existing ones
    good to have us define standard names for a core set of very useful
    pure-informational built-ins, e.g., addition, greater-than, etc.,
    i.e., arithmetic and string and list and boolean and dates
    Sandro and Said:
    Sandro:  think it would be good to use XQuery, if possible;
    they need looking at in detail, let's figure out if they're not suitable
    why they wouldn't be
    the list in Said's message is pretty big.
    What are our criteria for picking?
    let's support libraries of built-ins;
    define pluggable approach and what kind of semantics is supported in
    the rule language itself (vs. extra-logical), e.g., purely informational
    and not side-effectful or control
    it's useful to have the kind of list Said has prepared, as source
    of design requirements
    SCL has an approach to pluggability
    Pat and Benj:
    an important issue in a built-in is what its binding requirement pattern
    is, e.g., can you hand an addition built-in a variable and ask it to do a
    - Benj:  this is made explicit in situated logic programs
    radical categories of built-ins include
    - purely informational
    - having side-effectful actions
    - control (e.g., reset inference engine to clear out all facts)
    which is brain surgery
    distinction between sensing of the real world
    it's more a question of dynamism than "real"-ness,
    e.g., 2+2 vs. pulse of a patient
    - Sandro:  yes
    a kind of really nasty is where the dynamic state is of the rule system itself,
    e.g., how many or which facts have been inferred;
    we need to classify such, to caution uses rather than to legislate
    - Sandro:  could call these "reflective" sensors
    - Benj:  it's a kind of information-hiding principle
    a useful principle, made explicit in situated logic programs is
    that the results of the sensing do not change during the inferencing
    episode, this helps with declarativeness and inferencing control choices
    as well as with avoiding nasty uses of "reflection" in the above sense
    there is a fairly old theory of interruptibility
    way that N3 and cwm handle built-ins of arity more than 2 is to
    work with rdf:list's;
    issue:  is this the way we want to go;
    it works fairly well, but not totally happy with it -- feels clumsy/messy in
    that there are a lot of low-level triples flying around
    - Pat and Benj:  that feels too implementation level
    - Said:  it may also hurt performance
    there seems to be consensus on:
    - it's most important to define a way for folks to define their own built-ins
    - but it will help implementers a lot to have a basic list of most commonly
    used ones; there are a few
    - a key semantic issue is:  dynamism of sensor results
    Said:  will look at XQuery list and compare that to his draft list,
    aim to have that within 10 days and post it then
    Sandro:  will post URL pointers to relevant parts of XQuery spec
    Prof. Benjamin Grosof
    Web Technologies for E-Commerce, Business Policies, E-Contracting, Rules, 
    XML, Agents, Semantic Web Services
    MIT Sloan School of Management, Information Technology group or

    This archive was generated by hypermail 2.1.4 : 06/10/03 EST