Re: How does Euler handle CWM builtins?

> Jos,  thanks for this.
>
> I think I'm getting the picture ... let's see if I get it right:
>
> Built-in functions in a rule antecedent are treated as terms to be
unified
> with the knowledge base, just like any others, except that there is
special
> code to handle the particular features of the built-in properties.  I
judge
> that you take the terms in the antecedent of a rule in the order they are
> given, and unify them one at a time in a new context created for the
> purpose, adding new variable-to-value bindings as you go.  I am guessing
> that ordering is important because unification of terms that appear later
> in the antecedent may depend on bindings created by unification of
> preceding terms.
>
> Am I on the right track?

Yes Graham and w.r.t. ordering, we anticipate already the day
when clause and antecedent reordering will be fully automatic
which will also give a real and tremendous performance boost.
(a while back I did some manual owl-rules reordering and went
from 60 min to 6 min test case manifest execution time)

> It's not so clear whether you allow for some built-in properties that
there
> may be multiple possible unification patterns;  e.g. in the simple case:
>
>    (2 3) math:product _:Y
>
> would be satisfied by binding _:Y to 6.  But in special cases, other
> variable-binding patterns might be allowed, such as:
>
>    (1 _:X) math:product _:Y.
>
> is recognized as a fact by unifying _:X with _:Y, because the built-in
> knows that 1*x == x, forall x.  Similarly:
>
>    (0 _:X) math:product _:Y.
>
> can be allowed by binding _:Y to zero and leaving _:X unbound.
>
> In summary, reverting to a Prolog-ish notation, I would imagine the
> following cases are supportable for math:product (using ? in the
signature
> to indicate unbound variables):
>
>    math:product(1,?x,?y) :- x = y .
>    math:product(?x,1,?y) :- x = y .
>    math:product(0,?x,?y) :- ?y = 0 .
>    math:product(?x,0,?y) :- ?y = 0 .
>    math:product(x,y,?z) :- z = x*y .
>    math:product(?x,y,z) :- x = z/y .
>    math:product(x,?y,z) :- y = z/x .

We don't (yet) handle such cases, but they could be done...

> Looking at your examples and test cases, it looks as if you may allow
only
> more restricted patterns, in which the object must be fully bound and a
new
> binding is created for the subject.  This would seem to be consistent
with
> the way CWM defines these properties.

That's right Graham and the future will learn us more ;-)

--
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Received on Friday, 31 October 2003 09:00:11 UTC