my notes from today's JC telecon 1/3/04

From: Benjamin Grosof (bgrosof@MIT.EDU)
Date: 01/13/04

  • Next message: Mike Dean: "Joint Committee telecon today 20 January"
    % notes from 01/13/04 Joint Committee telecon
    % by Benjamin Grosof
    Mike Dean
    Benjamin Grosof
    Peter Patel-Schneider
    Harold Boley
    Said Tabet
    Ian Horrocks
    Deborah McGuinness
    Sandro Hawke
    Said presented list of builtins from the document in his msg of
    earlier today.
    important distinction:  side-effect-free vs. side-effect-ful
    do we want solely to focus in our discussions on side-effect-free?
    declarative vs. programming language uses of rules
    SWRL as it stands (because of existential/disjunctive expressiveness)
    can extend nicely to side-effect-free but not to side-effect-ful
    consensus:  let's focus on side-effect-free for now
    right now, Said's document does not fully partition the particular built-ins
    that way; problematic are  set()   and some of the "other built-ins",
    e.g., stream I/O, etc.
    in group at end of document
    suggestion:  let's modify the list to be all side-effect-free
    concatenate-type built-ins -- view as non-destructive, i.e., pure truth
    we probably want to define actual argument signatures level of detail for these
    directionality of requiring some arguments to be bound as inputs
    yes, we discussed this on previous calls,
    e.g., in mid-Dec., i.e., binding requirements (cf. situated logic programs):
    or sometimes in literature these are called "modes".
    would like this to leave/define/treat this as an implementation level issue;
    let's have a minimal set of builtins required of implementers, with additional
    being optional
    let's factor it from the rest of the language, but provide a standardized
    way to at least declare such restrictions;
    it's very useful and important to do so because of ubiquity of such
    restrictions in practice
    but don't want to build it into the semantics of the language;
    it would be hard to be clean semantically, since would be quite
    dependent on implementation specific details
    agree, that's what I proposed as well in our earlier discussion of this.
    Though with suitable restriction, one can make completeness etc. semantic
    guarantees -- as has been studied in LP and DB literatures.
    if call to get date/time from the operating systems
    XQuery handles this via:  yields same result whenever it's called;
    this has had some success, and seems a nice approach.
    I like this approach.
    I like this approach, it's similar to the explicit assumption in the
    situated LP semantics:
    no changes are made/accepted during the inferencing *episode*
    to the virtual knowledge base that is accessed by the builtins/sensors.
    We could call this "snapshot" or "static at episode grain" property.
    This issue goes far beyond just date/time (which obviously always
    is changing), e.g., whether a lookedup-via-builtin
    phone-number or airline database is updated
    during inferencing episode
    can view this as an environment variable;
    what not just assert it as a fact explicitly beforehand into the local
    rule/knowledge base
    because:  it's impractical and inconvenient, in many cases; rather,
    can have a processing mechanism enforce such static-ness,
    as is done in many distributed processing software applications today;
    in short that seems to me too strong a restriction
    Still it could be convenient to declare some info as imported rather
    than dynamically/changingly looked-up.
    could call this "pragma".
    also we need to beware that can be pretty inefficient
    agenda and actions for next week:
    Said to edit/update the builtins document to identify side-effect-free
    ones, and give more details about datatypes
    - Ian:  we will need to give various properties about including equality
    and less-than and Top, so we can view modularly
    all to look at Sheila's msg querying about how to do situation calculus
    - Benj:  in past, seems nonmon is needed for reasoning about action
        in DAML-S and SWSL (from his discussions with those committees and Sheila)
    Mike:  "operation atom" to go into the SWRL document?
    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 : 01/13/04 EST