% 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

Benj: 
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

Sandro:  
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

Said:  
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

Said  
there are naming conventions used in XML-Schema community;
we should reuse the existing ones

Benj:  
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:   
yes

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 

Pat:  
the list in Said's message is pretty big.  
What are our criteria for picking?  

Benj:
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 

Benj:
it's useful to have the kind of list Said has prepared, as source
of design requirements

Pat:  
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 
binding
- Benj:  this is made explicit in situated logic programs

Benj: 
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

Sandro:
distinction between sensing of the real world

Benj:
it's more a question of dynamism than "real"-ness,
e.g., 2+2 vs. pulse of a patient
- Sandro:  yes

Pat:
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

Benj:
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

Pat:
there is a fairly old theory of interruptibility

Sandro:
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