From: Benjamin Grosof (bgrosof@MIT.EDU)
Date: 01/13/04
% 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?
________________________________________________________________________________________________
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
http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof
This archive was generated by hypermail 2.1.4 : 01/13/04 EST