% notes from 01/13/04 Joint Committee telecon % by Benjamin Grosof participants: 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 Benj: 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 predicate Mike: we probably want to define actual argument signatures level of detail for these built-ins Sandro: issue: directionality of requiring some arguments to be bound as inputs Benj: yes, we discussed this on previous calls, e.g., in mid-Dec., i.e., binding requirements (cf. situated logic programs): Harold: or sometimes in literature these are called "modes". Ian: 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 Benj: 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 Ian: 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 Benj: 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. Harold: issue: if call to get date/time from the operating systems Mike: XQuery handles this via: yields same result whenever it's called; this has had some success, and seems a nice approach. Peter: I like this approach. Benj: 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 Ian: can view this as an environment variable; what not just assert it as a fact explicitly beforehand into the local rule/knowledge base Benj: 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 Ian: Still it could be convenient to declare some info as imported rather than dynamically/changingly looked-up. Harold: could call this "pragma". Benj: 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?