A Semantic Web Rule Language Combining OWL and RuleML (original) (raw)

W3C Member Submission 21 May 2004

This version:

http://www.w3.org/submissions/2004/SUBM-SWRL-20040521/

Latest version:

http://www.w3.org/submissions/SWRL/

Authors:

Ian Horrocks, Network Inference
Peter F. Patel-Schneider, Bell Labs Research, Lucent Technologies
Harold Boley, National Research Council of Canada
Said Tabet, Macgregor, Inc.
Benjamin Grosof, Sloan School of Management, MIT
Mike Dean, BBN Technologies

Copyright © 2004 National Research Council of Canada, Network Inference, and Stanford University. All Rights Reserved.
This document is available under the W3C Document License. See the W3C Intellectual Rights Notices and Disclaimers for additional information.

Abstract

This document contains a proposal for a Semantic Web Rule Language (SWRL) based on a combination of the OWL DL and OWL Lite sublanguages of the OWL Web Ontology Language with the Unary/Binary Datalog RuleML sublanguages of the Rule Markup Language. SWRL includes a high-level abstract syntax for Horn-like rules in both the OWL DL and OWL Lite sublanguages of OWL. A model-theoretic semantics is given to provide the formal meaning for OWL ontologies including rules written in this abstract syntax. An XML syntax based on RuleML and the OWL XML Presentation Syntax as well as an RDF concrete syntax based on the OWL RDF/XML exchange syntax are also given, along with several examples.

Status of this document

This is a member submission, offered by the National Research Council of Canada, Network Inference and Stanford University, on behalf of themselves and the authors, in association with the Joint US/EU ad hoc Agent Markup Language Committee (Joint Committee).

The W3C Team Comment discusses this submission in the context of W3C activities. Public comment on this document is invited on the mailing listwww-rdf-rules@w3.org(public archive). Announcements and current information may also be available on the DAML Rules page. A snapshot of the issues list, archived at the time of this submission, is available.

By publishing this document, W3C acknowledges that the National Research Council of Canada, Network Inference and Stanford University have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

Table of contents

• 1. Introduction
• 2. Abstract Syntax
  • 2.1 Rules
  • 2.2 Human Readable Syntax
• 3. Direct Model-Theoretic Semantics
  • 3.1 Interpreting Rules
• 4. Rule Examples
• 5. XML Concrete Syntax
  • 5.1 Rule Examples in XML Concrete Syntax
• 6. RDF Concrete Syntax
  • 6.1 Rule Examples in RDF Concrete Syntax
• 7. Usage Suggestions
  • 7.1 Extensibility and Interoperability Cautions
• 8. Built-Ins
  • 8.1 Built-Ins for Comparisons
  • 8.2 Math Built-Ins
  • 8.3 Built-Ins for Boolean Values
  • 8.4 Built-Ins for Strings
  • 8.5 Built-Ins for Date, Time and Duration
  • 8.6 Built-Ins for URIs
  • 8.7 Built-Ins for Lists
• Acknowledgments
• References

1. Introduction

This document contains a proposal for a Semantic Web Rule Language (SWRL) based on a combination of the OWL DL and OWL Lite sublanguages of theOWL Web Ontology Language with the Unary/Binary Datalog RuleML sublanguages of theRule Markup Language. The proposal extends the set of OWL axioms to include Horn-like rules. It thus enables Horn-like rules to be combined with an OWL knowledge base. A high-level abstract syntax is provided that extends the OWL abstract syntax described in the OWL Semantics and Abstract Syntax document [OWL S&AS]. An extension of the OWL model-theoretic semantics is also given to provide a formal meaning for OWL ontologies including rules written in this abstract syntax.

The proposed rules are of the form of an implication between an antecedent (body) and consequent (head). The intended meaning can be read as: whenever the conditions specified in the antecedent hold, then the conditions specified in the consequent must also hold.

Both the antecedent (body) and consequent (head) consist of zero or more atoms. An empty antecedent is treated as trivially true (i.e. satisfied by every interpretation), so the consequent must also be satisfied by every interpretation; an empty consequent is treated as trivially false (i.e., not satisfied by any interpretation), so the antecedent must also not be satisfied by any interpretation. Multiple atoms are treated as a conjunction. Note that rules with conjunctive consequents could easily be transformed (via the Lloyd-Topor transformations [Lloyd87]) into multiple rules each with an atomic consequent.

Atoms in these rules can be of the form C(x), P(x,y), sameAs(x,y) or differentFrom(x,y), where C is an OWL description, P is an OWL property, and x,y are either variables, OWL individuals or OWL data values. It is easy to see that OWL DL becomes undecidable when extended in this way as rules can be used to simulate role value maps [Schmidt-Schauß89].

An XML syntax is also given for these rules based on RuleML and the OWL XML presentation syntax. Furthermore, an RDF concrete syntax based on the OWL RDF/XML exchange syntax is presented. The rule syntaxes are illustrated with several running examples. Finally, we give usage suggestions and cautions.

2. Abstract Syntax

The syntax for SWRL in this section abstracts from any exchange syntax for OWL and thus facilitates access to and evaluation of the language. This syntax extends the abstract syntax of OWL described in the OWL Semantcs and Abstract Syntax document [OWL S&AS]. Even this abstract syntax is not particularly readable for rules. Examples will thus often be given in an informal syntax. This informal syntax will neither be given an exact syntax nor a mapping to any of the fully-specified syntaxes for SWRL.

The abstract syntax is specified here by means of a version of Extended BNF, very similar to the EBNF notationused for XML [XML]. Terminals are quoted; non-terminals are bold and not quoted. Alternatives are either separated by vertical bars (|) or are given in different productions. Components that can occur at most once are enclosed in square brackets ([…]); components that can occur any number of times (including zero) are enclosed in braces ({…}). Whitespace is ignored in the productions here.

Names in the abstract syntax are RDF URI references [RDF Concepts]. These names may be abbreviated into qualified names, using one of the following namespace names:

The meaning of each construct in the abstract syntax is informally described when it is introduced. The formal meaning of these constructs is given in Section 3 via an extension of the OWL DL model-theoretic semantics [OWL S&AS].

2.1. Rules

An OWL ontology in the abstract syntax contains a sequence of axioms and facts. Axioms may be of various kinds, e.g., subClass axioms and equivalentClass axioms. It is proposed to extend this with rule axioms.

axiom ::= rule

A rule axiom consists of an antecedent (body) and a consequent (head), each of which consists of a (posibly empty) set of atoms. A rule axiom can also be assigned a URI reference, which could serve to identify the rule.

rule ::= 'Implies(' [ URIreference ] { annotation } antecedent consequent ')' antecedent ::= 'Antecedent(' { atom } ')' consequent ::= 'Consequent(' { atom } ')'

Informally, a rule may be read as meaning that if the antecedent holds (is "true"), then the consequent must also hold. An empty antecedent is treated as trivially holding (true), and an empty consequent is treated as trivially not holding (false). Rules with an empty antecedent can thus be used to provide unconditional facts; however such unconditional facts are better stated in OWL itself, i.e., without the use of the rule construct. Non-empty antecedents and consequents hold iff all of their constituent atoms hold, i.e., they are treated as conjunctions of their atoms. As mentioned above, rules with conjunctive consequents could easily transformed (via the Lloyd-Topor transformations [Lloyd87]) into multiple rules each with an atomic consequent.

atom ::= description '(' i-object ')' | dataRange '(' d-object ')' | individualvaluedPropertyID '(' i-object i-object ')' | datavaluedPropertyID '(' i-object d-object ')' | sameAs '(' i-object i-object ')' | differentFrom '(' i-object i-object ')' | builtIn '(' builtinID { d-object } ')' builtinID ::= URIreference

Atoms can be of the form C(x), P(x,y), sameAs(x,y) differentFrom(x,y), or builtIn(r,x,...) where C is an OWL description or data range, P is an OWL property, r is a built-in relation, x and y are either variables, OWL individuals or OWL data values, as appropriate. In the context of OWL Lite, descriptions in atoms of the form C(x) may be restricted to class names.

Informally, an atom C(x) holds if x is an instance of the class description or data range C, an atom P(x,y) holds if x is related to y by property P, an atom sameAs(x,y) holds if x is interpreted as the same object as y, an atom differentFrom(x,y) holds if x and y are interpreted as different objects, and builtIn(r,x,...) holds if the built-in relation r (see Sections 3 and8) holds on the interpretations of the arguments. Note that the sameAs and differentFrom two forms can be seen as "syntactic sugar": they are convenient, but do not increase the expressive power of the language (i.e., such (in)equalities can already be expressed using the combined power of OWL and rules without explicit (in)equality atoms).

i-object ::= i-variable | individualID d-object ::= d-variable | dataLiteral

Atoms may refer to individuals, data literals, individual variables or data variables. Variables are treated as universally quantified, with their scope limited to a given rule. As usual, only variables that occur in the antecedent of a rule may occur in the consequent (a condition usually referred to as "safety"). This safety condition does not, in fact, restrict the expressive power of the language (because existentials can already be captured using OWL someValuesFrom restrictions).

i-variable ::= 'I-variable(' URIreference ')' d-variable ::= 'D-variable(' URIreference ')'

2.2. Human Readable Syntax

While the abstract EBNF syntax is consistent with the OWL specification, and is useful for defining XML and RDF serialisations, it is rather verbose and not particularly easy to read. In the following we will, therefore, often use a relatively informal "human readable" form similar to that used in many published works on rules.

In this syntax, a rule has the form:

antecedent ⇒ consequent

where both antecedent and consequent are conjunctions of atoms writtena1 ∧ ... ∧ an. Variables are indicated using the standard convention of prefixing them with a question mark (e.g., ?x). Using this syntax, a rule asserting that the composition of parent and brother properties implies the uncle property would be written:

parent(?x,?y) ∧ brother(?y,?z) ⇒ uncle(?x,?z)

In this syntax, built-in relations that are functional can be written in functional notation, i.e., op:numeric-add(?x,3,?z)can be written instead as

?x = op:numeric-add(3,?z)

3. Direct Model-Theoretic Semantics

The model-theoretic semantics for SWRL is a straightforward extension of the semantics for OWL given in the OWL Semantics and Abstract Syntax document [OWL S&AS]. The basic idea is that we definebindings, extensions of OWL interpretations that also map variables to elements of the domain. A rule is satisfied by an interpretation iff every binding that satisfies the antecedent also satisfies the consequent. The semantic conditions relating to axioms and ontologies are unchanged, e.g., an interpretation satisfies an ontology iff it satisfies every axiom (including rules) and fact in the ontology.

3.1. Interpreting Rules

From the OWL Semantics and Abstract Syntax document we recall that, given a datatype map D, an abstract OWL interpretation is a tuple of the form

I = <R, EC, ER, L, S, LV>

where R is a set of resources, LV ⊆ R is a set of literal values, EC is a mapping from classes and datatypes to subsets of R and LV respectively, ER is a mapping from properties to binary relations on R, L is a mapping from typed literals to elements of LV, and S is a mapping from individual names to elements of EC(owl:Thing). To handle the built-in relations, we augment the datatype map to map the built-in relations to tuples over the appropriate sets. That is, op:numeric-add is mapped into the triples of numeric values that correctly interpret numeric addition.

Note that allowing the datatype map to vary allows different implementations of SWRL to implement different built-in relations. It is suggested that if a SWRL implementation implements a particular datatype, then it implement the built-ins for that datatype from Section 8.

Given an abstract OWL interpretation Ι, a binding B(Ι) is an abstract OWL interpretation that extends Ι such that S maps i-variables to elements of EC(owl:Thing) and L maps d-variables to elements of LV respectively. An atom is satisfied by an interpretation Ι under the conditions given in the Interpretation Conditions Table, where C is an OWL DL description, D is an OWL DL data range, P is an OWL DL individualvalued property, Q is an OWL DL datavalued property, f is a built-in relation, x,y are variables or OWL individuals, and z is a variable or an OWL data value.

Interpretation Conditions Table

Note that this interpretation of the built-in relations is very permissive. It is not necessary for a built-in relation to have a fixed arity, nor is it an error to use a built-in relation with a fixed arity with the wrong number of arguments. For example builtIn(op:numeric-add ?x 5) is simply unsatisfiable, and not a syntax error.

A binding B(Ι) satisfies an antecedent A iff A is empty or B(Ι) satisfies every atom in A. A binding B(Ι) satisfies a consequent C iff C is not empty and B(Ι) satisfies every atom in C. A rule is satisfied by an interpretation Ι iff for every binding B such that B(Ι) satisfies the antecedent, B(Ι) also satisfies the consequent.

Note that rule annotations have no semantic consequences and neither do the URI references associated with rules. This is different from the situation for OWL itself, where annotations do not have semantic consequences.

The semantic conditions relating to axioms and ontologies are unchanged. In particular, an interpretation satisfies an ontology iff it satisfies every axiom (including rules) and fact in the ontology; an ontology is consistent iff it is satisfied by at least one interpretation; an ontology O2 is entailed by an ontology O1 iff every interpretation that satisfies O1 also satisfies O2.

4. Example Rules

Example 4.1-1

A simple use of these rules would be to assert that the combination of the hasParentand hasBrother properties implies the hasUncle property. Informally, this rule could be written as:

hasParent(?x1,?x2) ∧ hasBrother(?x2,?x3) ⇒ hasUncle(?x1,?x3)

In the abstract syntax the rule would be written like:

Implies(Antecedent(hasParent(I-variable(x1) I-variable(x2)) hasBrother(I-variable(x2) I-variable(x3))) Consequent(hasUncle(I-variable(x1) I-variable(x3))))

From this rule, if John has Mary as a parent and Mary has Bill as a brother then John has Bill as an uncle.

Example 4.1-2

An even simpler rule would be to assert that Students arePersons, as in Student(?x1) ⇒ Person(?x1).

Implies(Antecedent(Student(I-variable(x1))) Consequent(Person(I-variable(x1))))

However, this kind of use for rules in OWL just duplicates the OWL subclass facility. It is logically equivalent to write instead

Class(Student partial Person)

or

SubClassOf(Student Person)

which would make the information directly available to an OWL reasoner.

Example 4.1-3

A very common use for rules is to move property values from one individual to a related individual, as in the following example that expresses the fact that the style of an art object is the same as the style of the creator.

Artist(?x) & artistStyle(?x,?y) & Style(?y) & creator(?z,?x) ⇒ style/period(?z,?y)

Implies(Antecedent(Artist(I-variable(x)) artistStyle(I-variable(x) I-variable(y)) Style(I-variable(y)) creator(I-variable(z) I-variable(x))) Consequent(style/period(I-variable(z) I-variable(y))))

Example 4.1-4

It is useful to include OWL descriptions in rules, instead of using named classes. The above rule could be augmented with a separate rule to provide information about exclusivity of style (assuming that style is not always exclusive).

Artist(?x) & (≤1 artistStyle)(?x) & creator(?z,?x) ⇒ (≤1 style/period)(?z)

Implies(Antecedent(Artist(I-variable(x)) (restriction(artistStyle maxCardinality(1)))(I-variable(x)) Style(I-variable(y)) creator(I-variable(z) I-variable(x))) Consequent((restriction(style/period maxCardinality(1)))(I-variable(z))))

5. XML Concrete Syntax

The XML Concrete Syntax is a combination of the OWL Web Ontology Language XML Presentation Syntax [OWL XML] with the RuleML XML syntax [RuleML]. This has several advantages:

• arbitrary OWL classes (e.g., descriptions) can be used as predicates in rules;
• rules and ontology axioms can be freely mixed;
• the existing XSLT stylesheet (owlxml2rdf.xsl) can easily be extended to provide a mapping to RDF graphs that extends the OWL RDF/XML exchange syntax (see Section 6);
• interoperability between OWL and RuleML is simplified, existing RuleML tools can be adapted to SWRL, and an evolutionary extension path to additional rule expressive features cf. RuleML (e.g., n-ary, function-term, etc.) is prepared.

An XML Schema for the SWRL XML Concrete Syntax is<swrlx.xsd>.<swrlx.xsd> currently references a local copy of the XML Schema for the OWL XML Presentation Syntax modified to allow external references to several of its elements and attributes and to define owlx:datarange, which appears to be a missing piece of the OWL XML Presentation Syntax.

The SWRL XML Concrete Syntax uses the namespaceshttp://www.w3.org/2003/11/swrlx,http://www.w3.org/2003/11/ruleml,http://www.w3.org/2003/05/owl-xml (owlx), andhttp://www.w3.org/2001/XMLSchema (xsd).

The Ontology root element of the OWL XML Presentation Syntax is extended to include "imp" (implication rule) and "var" (variable declaration) axioms as found under the rulebase root of RuleML.

We then simply need to add the relevant syntax for variables and rules.

Variable (var) axioms are statements about variables, indicating that the given string is to be used as a variable.

A var axiom simply defines the existence of a variable. This is taken from the RuleML namespace. For example:

Example 5-1

ruleml:varx1

Rule axioms (imp elements) are similar to SubClassOfaxioms. They are taken from the RuleML namespace. A rule axiom can be read as a logical implication between the antecedent (_body) and consequent (_head). Like SubClassOf axioms, rules may include annotations. A rule axiom may optionally be named.

A rule axiom may optionally be named using a URI.

<ruleml:_rlab ruleml:href = xsd:anyURI (required)

Content: ( )

Both _body and _head are lists of atoms and are read as the conjunction of the component atoms.

ruleml:_body Content: ( swrlx:atom* )

ruleml:_head Content: ( swrlx:atom* )

Atoms can be formed from unary predicates (classes), binary predicates (properties), equalities or inequalities.

Class atoms consist of a description and either an individual name or a variable name.

The description in a class atom may be a class name, or may be a complex description using boolean combinations, restrictions, etc. For example:

Example 5-2

swrlx:classAtom <owlx:Class owlx:name="Person" /> ruleml:varx1

swrlx:classAtom owlx:IntersectionOf <owlx:Class owlx:name="Person" /> <owlx:ObjectRestriction owlx:property="hasParent"> <owlx:someValuesFrom owlx:class="Physician" /> ruleml:varx2

Datarange atoms consist of a data range and either a literal or a variable name.

swrlx:datarangeAtom Content: ( owlx:datarange, swrlx:dObject )

The description in a datarange atom may be a datatype ID, or may be a set of literals. For example:

Example 5-3

swrlx:datarangeAtom <owlx:Datatype owlx:name="&xsd;int" /> ruleml:varx1

swrlx:datarangeAtom owlx:OneOf <owlx:DataValue owlx:datatype="&xsd;int">5 <owlx:DataValue owlx:datatype="&xsd;int">10 ruleml:varx2

Property atoms consist of a property name and two elements that can be individual names, variable names or data values.

<swrlx:individualPropertyAtom swrlx:property = xsd:anyURI {required}

Content: ( swrlx:iObject, swrlx:iObject )

<swrlx:datavaluedPropertyAtom swrlx:property = xsd:anyURI {required}

Content: ( swrlx:iObject, swrlx:dObject )

As OWL does not support complex property descriptions, a property atom takes only a property name. For example:

Example 5-4

<swrlx:individualPropertyAtom swrlx:property="hasParent"> ruleml:varx1 <owlx:Individual owlx:name="John" />

<swrlx:datavaluedPropertyAtom swrlx:property="grade"> ruleml:varx1 <owlx:DataValue owlx:datatype="&xsd;int">4

Same (different) individual atoms assert equality (inequality) between sets of individual and variable names.

swrlx:sameIndividualAtom Content: ( swrlx:iObject* )

swrlx:differentIndividualsAtom Content: ( swrlx:iObject* )

Note that (in)equalities can be asserted between arbitrary combinations of variable names and individual names. For example:

Example 5-5

swrlx:sameIndividualAtom ruleml:varx1 ruleml:varx2 <owlx:Individual owlx:name="Clinton" /> <owlx:Individual owlx:name="Bill_Clinton" />

Builtin atoms provide an interface to the built-ins.

<swrlx:builtinAtom swrlx:builtin = xsd:anyURI {required}

Content: ( swrlx:dObject* )

5.1. Rule Examples

We can use SWRL to assert that the combination of the hasParentand hasBrother properties implies the hasUncle property:

Example 5.1-1

ruleml:imp <ruleml:_rlab ruleml:href="#example1"/> ruleml:_body <swrlx:individualPropertyAtom swrlx:property="hasParent"> ruleml:varx1 ruleml:varx2 <swrlx:individualPropertyAtom swrlx:property="hasBrother"> ruleml:varx2 ruleml:varx3 ruleml:_head <swrlx:individualPropertyAtom swrlx:property="hasUncle"> ruleml:varx1 ruleml:varx3

An alternative formulation for the hasUncle rule given in Example 5.1-1 would be to assert that ifx1 hasParent x2, x2 hasSibling x3, and x3 hasSex male, then x1 hasUncle x3:

Example 5.1-2

ruleml:imp <ruleml:_rlab ruleml:href="#example2"/> ruleml:_body <swrlx:individualPropertyAtom swrlx:property="hasParent"> ruleml:varx1 ruleml:varx2 <swrlx:individualPropertyAtom swrlx:property="hasSibling"> ruleml:varx2 ruleml:varx3 <swrlx:individualPropertyAtom swrlx:property="hasSex"> ruleml:varx3 <owlx:Individual owlx:name="#male" /> ruleml:_head <swrlx:individualPropertyAtom swrlx:property="hasUncle"> ruleml:varx1 ruleml:varx3

The following example is due to Guus Schreiber, and is based on ontologies used in an image annotation demo.

The rule expresses the fact that, given knowledge about the AAT style of certain ULAN artists (e.g., van Gogh is an Impressionist painter), we can derive the style of an art object (represented with the VRA element "style/period") from the value of the creator of the art object (represented by the VRA element "creator", a subproperty of dc:creator):

Example 5.1-3

ruleml:imp ruleml:_body swrlx:classAtom <owlx:Class owlx:name="&ulan;Artist" /> ruleml:varx swrlx:classAtom <owlx:Class owlx:name="&aat;Style" /> ruleml:vary <swrlx:individualPropertyAtom swrlx:property="&aatulan;artistStyle"> ruleml:varx ruleml:vary <swrlx:individualPropertyAtom swrlx:property="&vra;creator"> ruleml:varx ruleml:varz ruleml:_head <swrlx:individualPropertyAtom swrlx:property="&vra;style/period"> ruleml:varz ruleml:vary

The following is taken from an extended example due to Mike Dean. It expresses the fact that for every Airport there is a map Point that has the samelocation (latitude and longitude) as the Airport and that is an object of "layer" (a mapDrawingLayer). Moreover, this map point has the Airport as anunderlyingObject and has the Airport name as itsLabel

Note how the expressive power of SWRL allows "existentials" to be expressed in the head of a rule--it is asserted that, for every airport, there must exist such a map point.

Example 5.1-4

<owlx:DatatypeProperty owlx:name="latitude"/> <owlx:DatatypeProperty owlx:name="longitude"/>

owlx:SubClassOf owlx:sub <owlx:Class owlx:name="Location" /> owlx:super owlx:IntersectionOf <owlx:DataRestriction owlx:property="latitude"> <owlx:allValuesFrom owlx:datatype="&xsd;double"/> <owlx:DataRestriction owlx:property="longitude"> <owlx:allValuesFrom owlx:datatype="&xsd;double"/>

<owlx:Individual owlx:name="&airport;GEG"> <owlx:type owlx:name="&airport-ont;Airport" /> <owlx:DataPropertyValue owlx:property="airport-ont:name"> <owlx:DataValue owlx:datatype="&xsd;string">Spokane Intl <owlx:ObjectPropertyValue owlx:property="location"> owlx:Individual <owlx:DataPropertyValue owlx:property="latitude"> owlx:DataValue47.6197 <owlx:DataPropertyValue owlx:property="longitude"> owlx:DataValue-117.5336

<owlx:Individual owlx:name="layer"> <owlx:type owlx:name="↦DrawingLayer" />

<owlx:Individual owlx:name="map"> <owlx:type owlx:name="↦Map" /> <owlx:DataPropertyValue owlx:property="↦name"> <owlx:DataValue owlx:datatype="&xsd;string">Airports <owlx:ObjectPropertyValue owlx:property="map:layer"> <owlx:Individual owlx:name="layer"/>

owlx:SubClassOf owlx:sub <owlx:Class owlx:name="↦Location" /> owlx:super owlx:IntersectionOf <owlx:DataRestriction owlx:property="↦latitude"> <owlx:someValuesFrom owlx:datatype="&xsd;double"/> <owlx:DataRestriction owlx:property="↦latitude"> <owlx:allValuesFrom owlx:datatype="&xsd;double"/> <owlx:DataRestriction owlx:property="↦longitude"> <owlx:someValuesFrom owlx:datatype="&xsd;double"/> <owlx:DataRestriction owlx:property="↦longitude"> <owlx:allValuesFrom owlx:datatype="&xsd;double"/>

ruleml:imp ruleml:_body swrlx:classAtom <owlx:Class owlx:name="↦Location" /> ruleml:varmaploc <swrlx:individualPropertyAtom swrlx:property="sameLocation"> ruleml:varloc ruleml:varmaploc <swrlx:datavaluedPropertyAtom swrlx:property="latitude"> ruleml:varloc ruleml:varlat <swrlx:datavaluedPropertyAtom swrlx:property="longitude"> ruleml:varloc ruleml:varlon ruleml:_head <swrlx:datavaluedPropertyAtom swrlx:property="↦latitude"> ruleml:varmaploc ruleml:varlat <swrlx:datavaluedPropertyAtom swrlx:property="↦longitude"> ruleml:varmaploc ruleml:varlon

<owlx:ObjectProperty owlx:name="↦location" owlx:inverseOf="↦isLocationOf" /> <owlx:ObjectProperty owlx:name="↦object" owlx:inverseOf="↦isObjectOf" />

ruleml:imp ruleml:_body swrlx:classAtom <owlx:Class owlx:name="&airport-ont;Airport" /> ruleml:varairport <swrlx:individualPropertyAtom swrlx:property="location"> ruleml:varairport ruleml:varloc <swrlx:datavaluedPropertyAtom swrlx:property="latitude"> ruleml:varloc ruleml:varlat <swrlx:datavaluedPropertyAtom swrlx:property="longitude"> ruleml:varloc ruleml:varlon ruleml:_head swrlx:classAtom <owlx:ObjectRestriction owlx:property="sameLocation"> owlx:someValuesFrom owlx:IntersectionOf <owlx:Class owlx:name="↦Location" /> <owlx:ObjectRestriction owlx:property="↦isLocationOf"> owlx:someValuesFrom owlx:IntersectionOf <owlx:Class owlx:name="↦Point" /> <owlx:ObjectRestriction owlx:property="↦isObjectOf"> owlx:someValuesFrom owlx:OneOf <owlx:Individual owlx:name="#layer" /> ruleml:varloc

ruleml:imp ruleml:_body swrlx:classAtom <owlx:Class owlx:name="&airport-ont;Airport" /> ruleml:varairport <swrlx:individualPropertyAtom swrlx:property="location"> ruleml:varairport ruleml:varloc <swrlx:individualPropertyAtom swrlx:property="sameLocation"> ruleml:varloc ruleml:varmaploc <swrlx:individualPropertyAtom swrlx:property="↦location"> ruleml:varpoint ruleml:varmaploc <swrlx:datavaluedPropertyAtom swrlx:property="&airport-ont;name"> ruleml:varairport ruleml:varname ruleml:_head <swrlx:individualPropertyAtom swrlx:property="↦underlyingObject"> ruleml:varpoint ruleml:varairport <swrlx:datavaluedPropertyAtom swrlx:property="↦label"> ruleml:varpoint ruleml:varname

The following ontology translation example shows the use of built-ins to convert units of measure:

Example 5.1-5

ruleml:imp <ruleml:_rlab ruleml:href="#convertLength"/> owlx:Annotation owlx:Documentationex2:lengthInInches = ex1:lengthInFeet * 12 ruleml:_body <swrlx:datavaluedPropertyAtom swrlx:property="&ex1;#lengthInFeet"> ruleml:varinstance ruleml:varfeet ruleml:_head <swrlx:builtinAtom swrlx:builtin="&swrlb;#multiply"> ruleml:varinches ruleml:varfeet <owlx:DataValue owlx:datatype="&xsd;#int">12 <swrlx:datavaluedPropertyAtom swrlx:property="&ex2;#lengthInInches"> ruleml:varinstance ruleml:varinches

The following example shows the use of built-ins to perform comparisons necessary to compute a discount:

Example 5.1-6

ruleml:imp <ruleml:_rlab ruleml:href="#goldDiscount"/> owlx:Annotation owlx:DocumentationGold customers get a 10% discount on purchases of $500 or more ruleml:_body <swrlx:individualPropertyAtom swrlx:property="&ex;#hasStatus"> ruleml:varcustomer <owlx:Individual owlx:name="&ex;#gold"/> <swrlx:datavaluedPropertyAtom swrlx:property="&ex;#hasTotalPurchase"> ruleml:varcustomer ruleml:vartotal <swrlx:builtinAtom swrlx:builtin="&swrlb;#greaterThanOrEqual"> ruleml:vartotal <owlx:DataValue owlx:datatype="&xsd;#int">500 ruleml:_head <swrlx:datavaluedPropertyAtom swrlx:property="&ex;#hasDiscount"> ruleml:varcustomer <owlx:DataValue owlx:datatype="&xsd;#int">10

These examples are also provided as<example5.1-1.swrlx>,<example5.1-2.swrlx>,<example5.1-3.swrlx>,<example5.1-4.swrlx>,<example5.1-5.swrlx>, and<example5.1-6.swrlx>.

6. RDF Concrete Syntax

In this section we present an RDF concrete syntax for the rules. It is straightforward to provide such an RDF concrete syntax for rules, but the presence of variables in rules goes beyond the RDF Semantics. We do not yet know if the intended semantics of the resultant RDF graphs can be described as a semantic extension of RDF.

An RDF Schema for SWRL is<swrl.rdf>. An OWL ontology for SWRL is <swrl.owl>. Each of these provides only a partial description of the syntax for SWRL; the OWL ontology is more complete than the RDF Schema.

Translation from the XML Concrete Syntax to RDF/XML could be easily accomplished by extending theXSLT transformation for the OWL XML Presentation syntax [OWL XML].

6.1. Rule Examples in RDF Concrete Syntax

These examples illustrate a suitable rules extension of the OWL RDF/XML syntax. The first example is a repetition of Example 5.1-2 using RDF/XML syntax:

Example 6.1-1

<swrl:Variable rdf:ID="x1"/> <swrl:Variable rdf:ID="x2"/> <swrl:Variable rdf:ID="x3"/> ruleml:Imp <ruleml:body rdf:parseType="Collection"> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="⪚hasParent"/> <swrl:argument1 rdf:resource="#x1" /> <swrl:argument2 rdf:resource="#x2" /> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="⪚hasSibling"/> <swrl:argument1 rdf:resource="#x2" /> <swrl:argument2 rdf:resource="#x3" /> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="⪚hasSex"/> <swrl:argument1 rdf:resource="#x3" /> <swrl:argument2 rdf:resource="#male" /> <ruleml:head rdf:parseType="Collection"> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="⪚hasUncle"/> <swrl:argument1 rdf:resource="#x1" /> <swrl:argument2 rdf:resource="#x3" />

This example is a repetition of Example 5.1-3using RDF/XML syntax:

Example 6.1-2

<swrl:Variable rdf:ID="x"/> <swrl:Variable rdf:ID="y"/> <swrl:Variable rdf:ID="z"/> ruleml:Imp <ruleml:body rdf:parseType="Collection"> swrl:ClassAtom <swrl:classPredicate rdf:resource="&ulan;Artist"/> <swrl:argument1 rdf:resource="#x" /> swrl:ClassAtom <swrl:classPredicate rdf:resource="&aat;Style"/> <swrl:argument1 rdf:resource="#y" /> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="&aatulan;artistStyle"/> <swrl:argument1 rdf:resource="#x" /> <swrl:argument2 rdf:resource="#y" /> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="&vra;creator"/> <swrl:argument1 rdf:resource="#x" /> <swrl:argument2 rdf:resource="#z" /> <ruleml:head rdf:parseType="Collection"> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="&vra;style/period"/> <swrl:argument1 rdf:resource="#z" /> <swrl:argument2 rdf:resource="#y" />

This example is a repetition of the complex rule from Example 5.1-4 using RDF/XML syntax:

Example 6.1-3

<swrl:Variable rdf:ID="airport"/> <swrl:Variable rdf:ID="loc"/> <swrl:Variable rdf:ID="name"/> <swrl:Variable rdf:ID="lat"/> <swrl:Variable rdf:ID="lon"/> ruleml:Imp <ruleml:body rdf:parseType="Collection"> swrl:ClassAtom <swrl:classPredicate rdf:resource="&airport-ont;Airport"/> <swrl:argument1 rdf:resource="#airport" /> swrl:IndividualPropertyAtom <swrl:propertyPredicate rdf:resource="#location"/> <swrl:argument1 rdf:resource="#airport" /> <swrl:argument2 rdf:resource="#loc" /> swrl:DatavaluedPropertyAtom <swrl:propertyPredicate rdf:resource="#latitude"/> <swrl:argument1 rdf:resource="#loc" /> <swrl:argument2 rdf:resource="#lat" /> swrl:DatavaluedPropertyAtom <swrl:propertyPredicate rdf:resource="#longitude"/> <swrl:argument1 rdf:resource="#loc" /> <swrl:argument2 rdf:resource="#lon" /> <ruleml:head rdf:parseType="Collection"> swrl:ClassAtom swrl:classPredicate owl:Restriction <owl:onProperty rdf:resource="#sameLocation"/> owl:someValuesFrom owl:Class <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="↦Location"/> owl:Restriction <owl:onProperty rdf:resource="↦isLocationOf"/> owl:someValuesFrom owl:Class <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="↦Point"/> owl:Restriction <owl:onProperty rdf:resource="↦isObjectOf"/> owl:someValuesFrom owl:Class <owl:oneOf rdf:parseType="Collection"> <owl:Item rdf:resource="#layer"/> <swrl:argument1 rdf:resource="#airport" />

These examples are also provided as<example6.1-1.owl>,<example6.1-2.owl>, and<example6.1-3.owl>.

7. Usage Suggestions

The general intent of this proposal is to extend OWL DL, and thus to use OWL constructs wherever possible.

7.1. Extensibility and Interoperability Cautions

If users are making extensive use of rules, they may want to restrict the form or expressiveness of the rules they employ, in order to increase interoperability, reusability, extensibility, computational scaleability, or ease of implementation.

A useful restriction in the form of the rules is to limit antecedent and consequent classAtoms to be named classes, where the classes are defined purely in OWL (in the same document or in external OWL documents). Adhering to this format makes it easier to translate rules to or from existing (or future) rule systems, including:

1. Prolog;
2. production rules (descended from OPS5);
3. event-condition-action rules; and
4. SQL (where views, queries, and facts are all rules).

Adhering to this form also maximises reuse and interoperability of the ontology knowledge in the rules with other OWL-speaking systems that do not necessarily support SWRL.

Users also may want to restrict the expressiveness of the OWL classes and descriptions appearing in rules. One useful restriction on expressivity is Description Logic Programs [Grosof et al 2003] which, e.g., prohibits existentially-quantified knowledge in consequents. Suitably-restricted SWRL rules can be straightforwardly extended to enable procedural attachments and/or nonmonotonic reasoning (negation-as-failure and/or prioritised conflict handling) of the kinds supported in CCI rule systems and in RuleML [RuleML] which facilitates interoperability between those CCI rule systems. Such adherence may thus facilitate combining SWRL knowledge with knowledge from those other rules languages. Suitable restrictions can also improve the empirical tractability of reasoning with rules.

A longer, more detailed version of the above usage suggestions and cautions is available at http://www.daml.org/listarchive/joint-committee/1491.html.

8. Built-Ins

The set of built-ins for SWRL is motivated by a modular approach that will allow further extensions in future releases within a (hierarchical) taxonomy. At the same time, it will provide the flexibility for various implementations to select the modules to be supported with each version of SWRL.

SWRL's built-ins approach is also based on the reuse of existing built-ins in XQuery and XPath, which are themselves based on XML Schema Part 2: Datatypes.

This system of built-ins should also help in the interoperation of SWRL with other Web formalisms by providing an extensible, modular built-ins infrastructure for Semantic Web Languages, Web Services, and Web applications.

SWRL built-ins are used in builtin atoms. For example,swrlx:builtinAtomidentifies a built-in using the swrlx:builtin attribute and lists its arguments as subelements.

Swrl built-ins are identified using the http://www.w3.org/2003/11/swrlbnamespace.

8.1. Built-Ins for Comparisons

• swrlb:equal(from XQuery op:numeric-equal,op:compare,op:boolean-equal op:yearMonthDuration-equal,op:dayTimeDuration-equal,op:dateTime-equal,op:date-equal,op:time-equal,op:gYearMonth-equal,op:gYear-equal,op:gMonthDay-equal,op:gMonth-equal,op:gDay-equal,op:anyURI-equal)
  Satisfied iff the first argument and the second argument are the same.
• swrlb:notEqual(from swrlb:equal)
  The negation of swrlb:equal.
• swrlb:lessThan(from XQuery op:numeric-less-than,op:compare,op:yearMonthDuration-less-than,op:dayTimeDuration-less-than,op:dateTime-less-than,op:date-less-than,op:time-less-than)
  Satisfied iff the first argument and the second argument are both in some implemented type and the first argument is less than the second argument according to a type-specific ordering (partial or total), if there is one defined for the type. The ordering function for the type of untyped literals is the partial order defined as string ordering when the language tags are the same (or both missing) and incomparable otherwise.
• swrlb:lessThanOrEqual(from swrlb:lessThan, swrlb:equal)
  Either less than, as above, or equal, as above.
• swrlb:greaterThan(from XQuery op:numeric-greater-than,op:compare,op:yearMonthDuration-greater-than,op:dayTimeDuration-greater-than,op:dateTime-greater-than,op:date-greater-than,op:time-greater-than)
  Similarly to swrlb:lessThan.
• swrlb:greaterThanOrEqual(from swrlb:greaterThan, swrlb:equal)
  Similarly to swrlb:lessThanOrEqual.

8.2. Math Built-Ins

The following built-ins are defined for various numeric types. For the relation to be satisfied the arguments all have to belong to some numeric type for which the relation is defined.

• swrlb:add(from XQuery op:numeric-add)
  Satisfied iff the first argument is equal to the arithmetic sum of the second argument through the last argument.
• swrlb:subtract(from XQuery op:numeric-subtract)
  Satisfied iff the first argument is equal to the arithmetic difference of the second argument minus the third argument.
• swrlb:multiply(from XQuery op:numeric-multiply)
  Satisfied iff the first argument is equal to the arithmetic product of the second argument through the last argument.
• swrlb:divide(from XQuery op:numeric-divide)
  Satisfied iff the first argument is equal to the arithmetic quotient of the second argument divided by the third argument.
• swrlb:integerDivide(from XQuery op:numeric-integer-divide)
  Satisfied if the first argument is the arithmetic quotient of the second argument idiv the third argument. If the numerator is not evenly divided by the divisor, then the quotient is the xsd:integer value obtained, ignoring any remainder that results from the division (that is, no rounding is performed).
• swrlb:mod(from XQuery op:numeric-mod)
  Satisfied if the first argument represents the remainder resulting from dividing the second argument, the dividend, by the third argument, the divisor. The operation a mod b for operands that are xsd:integer or xsd:decimal, or types derived from them, produces a result such that (a idiv b)*b+(a mod b) is equal to a and the magnitude of the result is always less than the magnitude of b. This identity holds even in the special case that the dividend is the negative integer of largest possible magnitude for its type and the divisor is -1 (the remainder is 0). It follows from this rule that the sign of the result is the sign of the dividend
• swrlb:pow
  Satisfied iff the first argument is equal to the result of the second argument raised to the third argument power.
• swrlb:unaryPlus(from XQuery op:numeric-unary-plus)
  Satisfied iff the first argument is equal to the second argument with its sign unchanged.
• swrlb:unaryMinus(from XQuery op:numeric-unary-minus)
  Satisfied iff the first argument is equal to the second argument with its sign reversed.
• swrlb:abs(from XQuery fn:abs)
  Satisfied iff the first argument is the absolute value of the second argument.
• swrlb:ceiling(from XQuery fn:ceiling)
  Satisfied iff the first argument is the smallest number with no fractional part that is greater than or equal to the second argument.
• swrlb:floor(from XQuery fn:floor)
  Satisfied iff the first argument is the largest number with no fractional part that is less than or equal to the second argument.
• swrlb:round(from XQuery fn:round)
  Satisfied iff the first argument is equal to the nearest number to the second argument with no fractional part.
• swrlb:roundHalfToEven(from XQuery fn:round-half-to-even)
  Satisfied iff the first argument is equal to the second argument rounded to the given precision. If the fractional part is exactly half, the result is the number whose least significant digit is even.
• swrlb:sin
  Satisfied iff the first argument is equal to the sine of the radian value the second argument.
• swrlb:cos
  Satisfied iff the first argument is equal to the cosine of the radian value the second argument.
• swrlb:tan
  Satisfied iff the first argument is equal to the tangent of the radian value the second argument.

8.3. Built-Ins for Boolean Values

• swrlb:booleanNot(from XQuery fn:not)
  Satisfied iff the first argument is true and the second argument is false, or vice versa.

8.4. Built-Ins for Strings

The following built-ins are defined for strings (only), i.e., not untyped literals with language tags.

• swrlb:stringEqualIgnoreCase
  Satisfied iff the first argument is the same as the second argument (upper/lower case ignored)
• swrlb:stringConcat(from XQuery fn:concat)
  Satisfied iff the first argument is equal to the string resulting from the concatenation of the strings the second argument through the last argument.
• swrlb:substring(from XQuery fn:substring)
  Satisfied iff the first argument is equal to the substring of optional length the fourth argument starting at character offset the third argument in the string the second argument.
• swrlb:stringLength(from XQuery fn:string-length)
  Satisfied iff the first argument is equal to the length of the second argument.
• swrlb:normalizeSpace(from XQuery fn:normalize-space)
  Satisfied iff the first argument is equal to the whitespace-normalized value of the second argument.
• swrlb:upperCase(from XQuery fn:upper-case)
  Satisfied iff the first argument is equal to the upper-cased value of the second argument.
• swrlb:lowerCase(from XQuery fn:lower-case)
  Satisfied iff the first argument is equal to the lower-cased value of the second argument.
• swrlb:translate(from XQuery fn:translate)
  Satisfied iff the first argument is equal to the second argument with occurrences of characters contained in the third argument replaced by the character at the corresponding position in the string the fourth argument.
• swrlb:contains(from XQuery fn:contains)
  Satisfied iff the first argument contains the second argument (case sensitive).
• swrlb:containsIgnoreCase
  Satisfied iff the first argument contains the second argument (case ignored).
• swrlb:startsWith(from XQuery fn:starts-with)
  Satisfied iff the first argument starts with the second argument.
• swrlb:endsWith(from XQuery fn:ends-with)
  Satisfied iff the first argument ends with the second argument.
• swrlb:substringBefore(from XQuery fn:substring-before)
  Satisfied iff the first argument is the characters of the second argument that precede the characters of the third argument.
• swrlb:substringAfter(from XQuery fn:substring-after)
  Satisfied iff the first argument is the characters of the second argument that follow the characters of the third argument.
• swrlb:matches(from XQuery fn:matches)
  Satisfied iff the first argument matches the regular expression the second argument.
• swrlb:replace(from XQuery fn:replace)
  Satisfied iff the first argument is equal to the value of the second argument with every substring matched by the regular expression the third argument replaced by the replacement string the fourth argument.
• swrlb:tokenize(from XQuery fn:tokenize)
  Satisfied iff the first argument is a sequence of one or more strings whose values are substrings of the second argument separated by substrings that match the regular expression the third argument.

8.5. Built-Ins for Date, Time and Duration

The following built-ins are defined for the XML Schema date, time, and duration datatypes, only, as appropriate.

• swrlb:yearMonthDuration (from XQuery xdt:yearMonthDuration)
  Satisfied iff the first argument is the xsd:duration representation consisting of the year the second argument and month the third argument.
• swrlb:dayTimeDuration (from XQuery xdt:dayTimeDuration)
  Satisfied iff the first argument is the xsd:duration representation consisting of the days the second argument, hours the third argument, minutes the fourth argument, and seconds the fifth argument.
• swrlb:dateTime
  Satisfied iff the first argument is the xsd:dateTime representation consisting of the year the second argument, month the third argument, day the fourth argument, hours the fifth argument, minutes the sixth argument, seconds the seventh argument, and timezone the eighth argument.
• swrlb:date
  Satisfied iff the first argument is the xsd:date representation consisting of the year the second argument, month the third argument, day the fourth argument, and timezone the fifth argument.
• swrlb:time
  Satisfied iff the first argument is the xsd:time representation consisting of the hours the second argument, minutes the third argument, seconds the fourth argument, and timezone the fifth argument.
• swrlb:addYearMonthDurations (from XQuery op:add-yearMonthDurations)
  Satisfied iff the yearMonthDuration the first argument is equal to the arithmetic sum of the yearMonthDuration the second argument through the yearMonthDuration the last argument.
• swrlb:subtractYearMonthDurations (from XQuery op:subtract-yearMonthDurations)
  Satisfied iff the yearMonthDuration the first argument is equal to the arithmetic difference of the yearMonthDuration the second argument minus the yearMonthDuration the third argument.
• swrlb:multiplyYearMonthDuration (from XQuery op:multiply-yearMonthDuration)
  Satisfied iff the yearMonthDuration the first argument is equal to the arithmetic product of the yearMonthDuration the second argument multiplied by the third argument.
• swrlb:divideYearMonthDurations (from XQuery op:divide-yearMonthDuration)
  Satisfied iff the yearMonthDuration the first argument is equal to the arithmetic remainder of the yearMonthDuration the second argument divided by the third argument.
• swrlb:addDayTimeDurations (from XQuery op:add-dayTimeDurations)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic sum of the dayTimeDuration the second argument through the dayTimeDuration the last argument.
• swrlb:subtractDayTimeDurations (from XQuery op:subtract-dayTimeDurations)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic difference of the dayTimeDuration the second argument minus the dayTimeDuration the third argument.
• swrlb:multiplyDayTimeDurations (from XQuery op:multiply-dayTimeDuration)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic product of the dayTimeDuration the second argument multiplied by the third argument.
• swrlb:divideDayTimeDuration (from XQuery op:divide-dayTimeDuration)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic remainder of the dayTimeDuration the second argument divided by the third argument.
• swrlb:subtractDates (from XQuery op:subtract-dates)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic difference of the xsd:date the second argument minus the xsd:date the third argument.
• swrlb:subtractTimes (from XQuery op:subtract-times)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic difference of the xsd:time the second argument minus the xsd:time the third argument.
• swrlb:addYearMonthDurationToDateTime (from XQuery op:add-yearMonthDuration-to-dateTime)
  Satisfied iff the xsd:dateTime the first argument is equal to the arithmetic sum of the xsd:dateTime the second argument plus the yearMonthDuration the third argument.
• swrlb:addDayTimeDurationToDateTime (from XQuery op:add-dayTimeDuration-to-dateTime)
  Satisfied iff the xsd:dateTime the first argument is equal to the arithmetic sum of the xsd:dateTime the second argument plus the dayTimeDuration the third argument.
• swrlb:subtractYearMonthDurationFromDateTime (from XQuery op:subtract-yearMonthDuration-from-dateTime)
  Satisfied iff the xsd:dateTime the first argument is equal to the arithmetic difference of the xsd:dateTime the second argument minus the yearMonthDuration the third argument.
• swrlb:subtractDayTimeDurationFromDateTime (from XQuery op:subtract-dayTimeDuration-from-dateTime)
  Satisfied iff the xsd:dateTime the first argument is equal to the arithmetic difference of the xsd:dateTime the second argument minus the dayTimeDuration the third argument.
• swrlb:addYearMonthDurationToDate (from XQuery op:add-yearMonthDuration-to-date)
  Satisfied iff the xsd:date the first argument is equal to the arithmetic sum of the xsd:date the second argument plus the yearMonthDuration the third argument.
• swrlb:addDayTimeDurationToDate (from XQuery op:add-dayTimeDuration-to-date)
  Satisfied iff the xsd:date the first argument is equal to the arithmetic sum of the xsd:date the second argument plus the dayTimeDuration the third argument.
• swrlb:subtractYearMonthDurationFromDate (from XQuery op:subtract-yearMonthDuration-from-date)
  Satisfied iff the xsd:date the first argument is equal to the arithmetic difference of the xsd:date the second argument minus the yearMonthDuration the third argument.
• swrlb:subtractDayTimeDurationFromDate (from XQuery op:subtract-dayTimeDuration-from-date)
  Satisfied iff the xsd:date the first argument is equal to the arithmetic difference of the xsd:date the second argument minus the yearMonthDuration the third argument.
• swrlb:addDayTimeDurationToTime (from XQuery op:add-dayTimeDuration-to-time)
  Satisfied iff the xsd:time the first argument is equal to the arithmetic sum of the xsd:time the second argument plus the dayTimeDuration the third argument.
• swrlb:subtractDayTimeDurationFromTime (from XQuery op:subtract-dayTimeDuration-from-time)
  Satisfied iff the xsd:time the first argument is equal to the arithmetic difference of the xsd:time the second argument minus the dayTimeDuration the third argument.
• swrlb:subtractDateTimesYieldingYearMonthDuration (from XQuery fn:subtract-dateTimes-yielding-yearMonthDuration)
  Satisfied iff the yearMonthDuration the first argument is equal to the arithmetic difference of the xsd:dateTime the second argument minus the xsd:dateTime the third argument.
• swrlb:subtractDateTimesYieldingDayTimeDuration (from XQuery fn:subtract-dateTimes-yielding-dayTimeDuration)
  Satisfied iff the dayTimeDuration the first argument is equal to the arithmetic difference of the xsd:dateTime the second argument minus the xsd:dateTime the third argument.

8.6. Built-Ins for URIs

The following built-ins are defined for the XML Schema datatypes related to URIs.

• swrlb:resolveURI(from XQuery op:resolve-uri)
  Satisfied iff the URI reference the first argument is equal to the value of the URI reference the second argument resolved relative to the base URI the third argument.
• swrlb:anyURI
  Satisfied iff the first argument is a URI reference consisting of the scheme the second argument, host the third argument, port the fourth argument, path the fifth argument, query the sixth argument, and fragment the seventh argument.

8.7. Built-Ins for Lists

The following built-ins are defined for RDF-style lists. (Note that these built-ins are not usable in OWL DL or OWL Lite as RDF-style lists can only be used as OWL data in OWL Full.)

• swrlb:listConcat (from Common Lisp append)
  Satisfied iff the first argument is a list representing the concatenation of the lists the second argument through the last argument.
• swrlb:listIntersection
  Satisfied iff the first argument is a list containing elements found in both the list the second argument and the list the third argument.
• swrlb:listSubtraction
  Satisfied iff the first argument is a list containing the elements of the list the second argument that are not members of the list the third argument.
• swrlb:member
  Satisfied iff the first argument is a member of the list the second argument.
• swrlb:length (from Common Lisp list-length)
  Satisfied iff the first argument is the length of the list the second argument (number of members of the list).
• swrlb:first (from rdf:first)
  Satisfied iff the first argument is the first member of the list the second argument.
• swrlb:rest (from rdf:rest)
  Satisfied iff the first argument is a list containing all members of the list the second argument except the first member (the head).
• swrlb:sublist
  Satisfied iff the list the first argument contains the list the second argument.
• swrlb:empty (from rdf:nil)
  Satisfied iff the list the first argument is an empty list.

Acknowledgments

This document was produced as part of the DARPA DAML Program, and has benefited from extensive discussion in the Joint US/EU ad hoc Agent Markup Language Committee, with contributions from Sandro Hawke and Pat Hayes being worthy of particular mention. It has also benefited from the close cooperation of the RuleML initiative, and input from the Semantic Web Services Initiative (SWSI).

References

[Grosof et al 2003]

Description Logic Programs: Combining Logic Programs with Description Logic. Benjamin Grosof, Ian Horrocks, Raphael Volz, Stefan Decker. Proc. WWW2003, Budapest, May 2003. http://www2003.org/cdrom/papers/refereed/p117/p117-grosof.html(also http://ebusiness.mit.edu/bgrosof/#DLP).

[Lloyd87]

Foundations of logic programming (second, extended edition). J. W. Lloyd. Springer series in symbolic computation. Springer-Verlag, New York, 1987.

[OWL Reference]

OWL Web Ontology Language Reference. Mike Dean, Guus Schreiber, Sean Bechhofer, Frank van Harmelen, James Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Recommendation 10 February 2004. Latest version is available at http://www.w3.org/TR/owl-ref/.

[OWL S&AS]

OWL Web Ontology Language Semantics and Abstract Syntax. Peter F. Patel-Schneider, Pat Hayes and Ian Horrocks, eds. W3C Recommendation 10 February 2004. Latest version is available athttp://www.w3.org/TR/owl-semantics/.

[OWL XML]

OWL Web Ontology Language XML Presentation Syntax. Masahiro Hori, J�r�me Euzenat, Peter F. Patel-Schneider. W3C Note 11 June 2003

[RDF Concepts]

Resource Description Framework (RDF) Concepts and Abstract Syntax. Graham Klyne, Jeremy J. Carroll, and Brian McBride, eds. W3C Recommendation 10 February 2004. Latest version is available at http://www.w3.org/TR/rdf-concepts/.

[RuleML]

Rule Markup Language Initiative.

[Schmidt-Schauß89]

Subsumption in KL-ONE is Undecidable. M. Schmidt-Schauß. Proc. of KR'89, pages 421-431, Morgan Kaufmann.

[XML]

Extensible Markup Language (XML) 1.0 (Second Edition). Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, and Eve Maler, eds. W3C Recommendation 6 October 2000. Latest version is available at http://www.w3.org/TR/REC-xml/.