From: Mike Dean (mdean@bbn.com)
Date: 01/27/04
Ian, Thanks very much for your feedback. > > This assumes that the binding pattern for each "operator" will be > > defined in our documentation - implementations may also allow > > user-defined operators. By convention, the arithmetic operators use > > the first binding for the result of the calculation. > > I would still hesitate to describe this as the result of the > calculation, although I am not able to suggest any better words at > present. Maybe we can just describe each operation in terms of satisfiability, e.g. "numeric-add" is satisfied if the first argument (better word?) is equal to the arithmetic sum of the second and subsequent arguments. > Like other SWRL atoms, swrlx:operationAtom doesn't "return" anything - > it is satisfied by a binding iff the resulting interpretation of the > variables make the predicate true. Point taken. > Implementation > issues such as overflow errors etc would need to be > handled in the same way as any other implementation fault such as a > memory fault due to excessively large/complex ontologies. OK. > > Since swrlx:operationAtom can return false, it should only appear > > within ruleml:_body. > > Such a restriction isn't necessary if you think about the operation > atoms in the way I suggest above. Good. That simplifies things (at least for users). > but the ability to "define" new predicates in this > way might be very useful in general. I'm really excited about this possibility! This ability of users to define new predicates in the rule language may also reduce the need for built-ins or user-defined external procedures. In addition to f2c, I may add a Great Circle Distance rule (lat/lon within a specified distance of another lat/lon) to our test cases, as a good example of atoms that users wouldn't want to duplicate in multiple rules. Thanks again! Mike
This archive was generated by hypermail 2.1.4 : 01/27/04 EST