Re: datatype comparisons and arithmetic conversions

From: stabet@comcast.net
Date: 12/16/03

  • Next message: Mike Dean: "RE: datatype comparisons and arithmetic conversions"
    Hi Mike,
    
    I like your suggestions. Both atoms are needed in most use cases.
    
    When you said:
    >   A swrlx:comparisonAtom could only appear in the head of a rule.
    
    you menat the body of the rule right?
    
     The swrlx:bindAtom atom could be added in the head or the body of a rule.
    
    
              -Said
    
    
    ----- Original Message ----- 
    From: "Mike Dean" <mdean@bbn.com>
    To: <joint-committee@daml.org>
    Sent: Tuesday, December 16, 2003 1:31 AM
    Subject: 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