From: Benjamin Grosof (bgrosof@mit.edu)
Date: 12/16/03
Hi folks, Some comments: Mike: On first quick pass: I like all your suggestions. Thanks for getting us rolling so well! Said: what's the current status of the list of arithmetic/comparison/string/list built-ins you (plus I and Harold) have been working on? That included stuff drawn from looking at other systems/standards (like Prolog and Jess) as well as from XML-Schema / XQuery. I think you're the maintainer of that list/document. Most importantly: is there any stuff there we should include that's not in the XML-Schema / XQuery set of stuff? I think maybe not, but we should remember to consider that, don't you think? Benjamin At 10:31 PM 12/15/2003 -0800, you wrote: >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/ ________________________________________________________________________________________________ Prof. Benjamin Grosof Web Technologies for E-Commerce, Business Policies, E-Contracting, Rules, XML, Agents, Semantic Web Services MIT Sloan School of Management, Information Technology group http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof
This archive was generated by hypermail 2.1.4 : 12/16/03 EST