SWRL 0.6 suggestions

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

  • Next message: Mike Dean: "Joint Committee telecon today 2 December"
    Here's the input I promised during last week's telecon.
    I think we should continue to take small steps in evolving
    SWRL.  There are 2 related features that I think would give
    users much-needed capabilities and make a nice follow-on
    language increment:  datatype comparisons and arithmetic
    Many rule examples (including the financial examples given
    by Said at the DAML PI Meeting [1]) involving numeric
    comparisons, e.g.
      // free shipping on orders of $50 or more
      if (order.cost < 50)
         order.shipping = 5
         order.shipping = 0
    OWL inherits DAML+OIL's practice of using XML Schema
    Datatypes to define data ranges, e.g. defining a SmallOrder
    to be an Order with cost user:lessThan50.  Even aside from
    uncertainties in URI naming of such user defined types, this
    is awkward and has not been widely implemented.  There's a
    good opportunity for SWRL to solve this problem.
    My preferred solution is to incorporate support for the
    ordered XML Schema datatypes used by OWL directly in SWRL,
    e.g. by introducing a ComparisonAtom that takes 2 d-objects
    and is either "subclassed" (e.g. LessThanAtom) or takes an
    operator named by URI.  While there's a temptation to treat
    such operators as one case of procedural attachments, I
    think that adds complexity and would prolong adoption.
    Primitive datatype comparisons are handled directly by most
    rule systems.
    My second proposed addition is support for arithmetic
    datatype conversions sufficient to write translation rules
    (e.g.  converting ont1:fahrenheitTemperature to
    ont2:celsiusTemperature, or ont1:priceInDollars to
    ont2:priceInEuros based on the current exchange rate).  The
    basic arithmetic operations are the most critical - support
    for a larger set of side-effect free numeric and string
    operators (e.g. cosine, string concatenation, and case
    conversion) such as the XQuery builtins could be desirable
    if it doesn't add significant complexity or delay.  Again,
    such operators could be viewed as part of a more general
    procedural attachment mechanism, but I don't think we're
    ready for that.
    [1] http://www.daml.org/2003/10/pi-meeting/rulemlight-talk_Boley.pdf

    This archive was generated by hypermail 2.1.4 : 12/01/03 EST