From: Jos De_Roo <jos.deroo@agfa.com>

Date: Fri, 31 Oct 2003 14:59:51 +0100

To: "Graham Klyne <gk" <gk@ninebynine.org>

Cc: www-archive@w3.org

Message-ID: <OF3A133916.2FDE6205-ONC1256DD0.004CD0A9-C1256DD0.004CE7D8@agfa.be>

Date: Fri, 31 Oct 2003 14:59:51 +0100

To: "Graham Klyne <gk" <gk@ninebynine.org>

Cc: www-archive@w3.org

Message-ID: <OF3A133916.2FDE6205-ONC1256DD0.004CD0A9-C1256DD0.004CE7D8@agfa.be>

> 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

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 14:42:32 UTC
*