From: Mike Dean ([email protected])
Date: 12/16/03
This message extends my previous proposal [1] for datatype comparisons
and arithmetic conversions. It builds off XQuery [2] and XQuery 1.0
and XPath 2.0 Functions and Operators [3], which in turn build off XML
Schema Datatypes.
My current thought is to introduce 2 new atoms
swrlx:comparisonAtom which takes an xs:boolean-returning XQuery
operator or function and 2 ordered arguments, each of which may be a
variable, dataLiteral, or expression. A swrlx:comparisonAtom could
only appear in the head of a rule.
swrlx:bindAtom which takes a d-variable and an expression
and a new element
swrlx:expression which takes an XQuery operator or function and a
variable number of ordered arguments, each of which may be a
variable, dataLiteral, or expression
Here are extended XML Concrete Syntax encodings of the previous
examples:
<!-- free shipping on orders over $50 -->
<ruleml:imp>
<ruleml:_body>
<swrlx:classAtom>
<owlx:Class owlx:name="Order"/>
<ruleml:var>order</ruleml:var>
</swrlx:classAtom>
<swrlx:datavaluedPropertyAtom swrlx:property="cost">
<ruleml:var>order</ruleml:var>
<ruleml:var>cost</ruleml:var>
</swrlx:datavaluedPropertyAtom>
<swrlx:comparisonAtom swrlx:op="&op;numeric-greater-than">
<ruleml:var>cost</ruleml:var>
<owlx:DataValue owlx:datatype="&xsd;integer">50</owlx:DataValue>
</swrlx:comparisonAtom>
</ruleml:_body>
<ruleml:_head>
<swrlx:datavaluedPropertyAtom swrlx:property="shipping">
<ruleml:var>order</ruleml:var>
<owlx:DataValue owlx:datatype="&xsd;integer">0</owlx:DataValue>
</swrlx:datavaluedPropertyAtom>
</ruleml:_head>
</ruleml:imp>
<!-- convert temperature from Fahrenheit to Celsius -->
<ruleml:imp>
<ruleml:_body>
<swrlx:datavaluedPropertyAtom swrlx:property="fahrenheitTemp">
<ruleml:var>x</ruleml:var>
<ruleml:var>f</ruleml:var>
</swrlx:datavaluedPropertyAtom>
<swrlx:bindAtom swrlx:var="c">
<swrlx:expression swrlx:op="&op;numeric-integer-divide">
<swrlx:expression swrlx:op="&op;numeric-multiply">
<swrlx:expression swrlx:op="&op;numeric-subtract">
<ruleml:var>f</ruleml:var>
<owlx:DataValue
owlx:datatype="&xsd;integer">32</owlx:DataValue>
</swrlx:expression>
<owlx:DataValue owlx:datatype="&xsd;integer">5</owlx:DataValue>
</swrlx:expression>
<owlx:DataValue owlx:datatype="&xsd;integer">9</owlx:DataValue>
</swrlx:expression>
</swrlx:bindAtom>
</ruleml:_body>
<ruleml:_head>
<swrlx:datavaluedPropertyAtom swrlx:property="celsiusTemp">
<ruleml:var>x</ruleml:var>
<ruleml:var>c</ruleml:var>
</swrlx:datavaluedPropertyAtom>
</ruleml:_head>
</ruleml:imp>
We would presumably impose some restrictions on variables (e.g. only a
new variable not used in previous atoms within a rule can appear as a
swrlx:bindAtom swrlx:var and only variables used in previous atoms can
appear within swrlx:expression elements) so that SWRL engines wouldn't
have to include an equation solver.
We would presumably require SWRL implementations to support some set
of operators, and could allow implementations to support additional
user-defined operators and functions with their own URIs. I think
we'd want to omit support for the XQuery functions involving nodes and
sequences ([3] sections 14 and 15 and some of 16).
[3] provides URIs for its functions, but unfortunately not for its
operators, expecting XPath, XQuery, and XSLT, to use +, >, *, etc.
I'd suggest that we define our own namespace for op:, but use their
QNames plus possibly some additions like
op:numeric-greater-than-or-equal.
Mike
[1] http://www.daml.org/listarchive/joint-committee/1565.html
[2] http://www.w3.org/TR/xquery/
[3] http://www.w3.org/TR/xquery-operators/
This archive was generated by hypermail 2.1.4 : 12/16/03 EST