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