datatype comparisons and arithmetic conversions

From: Mike Dean (mdean@bbn.com)
Date: 12/16/03

  • Next message: stabet@comcast.net: "Re: datatype comparisons and arithmetic conversions"
    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