A Proposal for an
OWL Rules Language

Abstract

Status of this document

1. Introduction

This document contains a proposal for a rules extension to the OWL DL and OWL Lite sublanguages of the OWL Web Ontology Language. The proposal extends the set of OWL axioms to include horn clause rules. 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 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].

2. Abstract Syntax

The syntax for OWL Rules 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].

The abstract syntax is specified here by means of a version of Extended BNF, very similar to the EBNF notation used 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.

rule ::= 'Implies(' { 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). Non-empty atecedents and conseqents 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 ')'
	 | individualvaluedPropertyID '(' i-object i-object ')'
	 | datavaluedPropertyID '(' i-object d-object ')'
	 | sameAs '(' i-object i-object ')'
	 | differentFrom '(' i-object i-object ')'

Atoms 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. 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 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, and an atom differentFrom(x,y) holds if x and y are interpreted as different objects. Note that the latter 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 usualy refered 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 ')'

3. Direct Model-Theoretic Semantics

The model-theoretic semantics for OWL rules is a straightforward extension of the semantics for OWL given in [OWL S&AS]. The basic idea is that we define bindings, 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

Given an abstract OWL interpretation I, a binding B(I) is an abstract OWL interpretation that extends I such that function S maps i-variables to elements of R and d-variables to elements of LV_T respectively.

We recall that an Abstract OWL interpretation is a tuple of the form: I = <R, V, EC, ER, S> [OWL S&AS]. An atom is satisfied by an interpretation I under the conditions given in Interpretation Conditions Table.

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

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 O₂ is entailed by an ontology O₁ iff every interpretation that satisfies O₁ also satisfies O₂.

4. XML Concrete Syntax

Many possible XML encodings could be imagined (e.g., a RuleML based syntax as proposed in http://www.daml.org/listarchive/joint-committee/1460.html), but the most obvious solution is to extend the existing OWL Web Ontology Language XML Presentation Syntax [OWL XML], which can be straightforwardly modified to deal with OWL Rules. 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 5).

In the first place, the ontology root element is extended to include "Rule" and "Variable" axioms.

<Ontology
  name = xsd:anyURI 
>
  Content: (VersionInfo | PriorVersion | BackwardCompatibleWith | 
            IncompatibleWith | Imports | Annotation | 
            Class[axiom] | EnumeratedClass(D,F) | 
            SubClassOf(D,F) | EquivalentClasses | DisjointClasses(D,F) | 
            DatatypeProperty | ObjectProperty | 
            SubPropertyOf | EquivalentProperties | 
            Individual[axiom] | SameIndividual | DifferentIndividuals |
            Rule[axiom] | Variable[axiom])* 
</Ontology>

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

Variable axioms are statements about variables, indicating that the given URI is to be used as a variable, and adding any annotations.

<Variable
  name = xsd:anyURI

>
  Content: ( Annotation* ) 
</Variable>

A variable axiom simply defines the existence of a variable (with optional annotation). For example:

<owlx:Variable name="x1" /> 

Rule axioms are similar to SubClassOf axioms and can be read as a logical implication between the antecedent and consequent. Like SubClassOf axioms, rules may include annotations.

<Rule>
  Content: ( Annotation*, antecedent, consequent )
</Rule>

Both antecedent and consequent are lists of atoms and are read as the conjunction of the component atoms.

<antecedent>
  Content: ( atom* )
</antecedent>

<consequent>
  Content: ( atom* )
</consequent>

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

  Content: (classAtom | individualPropertyAtom | datavaluedPropertyAtom | 
            sameIndividualAtom | differentIndividualsAtom)

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

<classAtom>
  Content: ( description, iObject )
</classAtom>

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

<owlx:classAtom> 
  <owlx:Class owlx:name="Person" />
  <owlx:Variable owlx:name="x1" />
</owlx:classAtom> 

<owlx:classAtom> 
  <owlx:IntersectionOf>
    <owlx:Class owlx:name="Person" />
    <owlx:ObjectRestriction owlx:property="hasParent"> 
      <owlx:someValuesFrom owlx:class="Physician" />
    </owlx:ObjectRestriction> 
  </owlx:IntersectionOf>
  <owlx:Variable owlx:name="x2" />
</owlx:classAtom> 

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

<individualPropertyAtom
  property = xsd:anyURI {required} 
>
  Content: ( iObject, iObject )
</individualPropertyAtom>

<datavaluedPropertyAtom
  property = xsd:anyURI {required} 
>
  Content: ( iObject, dObject )
</datavaluedPropertyAtom>

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

<owlx:individualPropertyAtom  owlx:property="hasParent"> 
  <owlx:Variable owlx:name="x1" />
  <owlx:Individual owlx:name="John" />
</owlx:individualPropertyAtom> 

<owlx:datavaluedPropertyAtom  owlx:property="grade"> 
  <owlx:Variable owlx:name="x1" />
  <owlx:DataValue owlx:datatype="&xsd;integer">4</owlx:DataValue>
</owlx:datavaluedPropertyAtom> 

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

<sameIndividualAtom>
  Content: ( iObject* )
</sameIndividualAtom>

<differentIndividualsAtom>
  Content: ( iObject* )
</differentIndividualsAtom>

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

<owlx:sameIndividualAtom> 
  <owlx:Variable owlx:name="x1" />
  <owlx:Variable owlx:name="x2" />
  <owlx:Individual owlx:name="Clinton" />
  <owlx:Individual owlx:name="Bill_Clinton" />
</owlx:sameIndividualAtom> 

  Content: ( Individual[ID] | Variable[ID] )

  Content: ( DataValue | Variable[ID] )

<Variable
  name = xsd:anyURI {required} 
>
  Content: (##empty)
</Variable>

4.1. Rule Examples

We can use OWL rules to assert that the combination of the hasParent and hasBrother properties implies the hasUncle property:

<owlx:Rule> 
  <owlx:antecedent> 
    <owlx:individualPropertyAtom  owlx:property="hasParent"> 
      <owlx:Variable owlx:name="x1" />
      <owlx:Variable owlx:name="x2" />
    </owlx:individualPropertyAtom> 
    <owlx:individualPropertyAtom  owlx:property="hasBrother"> 
      <owlx:Variable owlx:name="x2" />
      <owlx:Variable owlx:name="x3" />
    </owlx:individualPropertyAtom> 
  </owlx:antecedent> 
  <owlx:consequent> 
    <owlx:individualPropertyAtom  owlx:property="hasUncle"> 
      <owlx:Variable owlx:name="x1" />
      <owlx:Variable owlx:name="x3" />
    </owlx:individualPropertyAtom> 
  </owlx:consequent> 
</owlx:Rule> 

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

<owlx:Rule> 
  <owlx:antecedent> 
    <owlx:individualPropertyAtom  owlx:property="hasParent"> 
      <owlx:Variable owlx:name="x1" />
      <owlx:Variable owlx:name="x2" />
    </owlx:individualPropertyAtom> 
    <owlx:individualPropertyAtom  owlx:property="hasSibling"> 
      <owlx:Variable owlx:name="x2" />
      <owlx:Variable owlx:name="x3" />
    </owlx:individualPropertyAtom> 
    <owlx:individualPropertyAtom  owlx:property="hasSex"> 
      <owlx:Variable owlx:name="x3" />
      <owlx:Individual owlx:name="#male" />
    </owlx:individualPropertyAtom> 
  </owlx:antecedent> 
  <owlx:consequent> 
    <owlx:individualPropertyAtom  owlx:property="hasUncle"> 
      <owlx:Variable owlx:name="x1" />
      <owlx:Variable owlx:name="x3" />
    </owlx:individualPropertyAtom> 
  </owlx:consequent> 
</owlx:Rule> 

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):

<owlx:Rule> 
  <owlx:antecedent> 
    <owlx:classAtom> 
      <owlx:class="&ulan;Artist" />
      <owlx:Variable owlx:name="_x" />
    </owlx:classAtom> 
    <owlx:classAtom> 
      <owlx:class="&aat;Style" />
      <owlx:Variable owlx:name="_y" />
    </owlx:classAtom> 
    <owlx:individualPropertyAtom  owlx:property="&aatulan;artistStyle"> 
      <owlx:Variable owlx:name="_x" />
      <owlx:Variable owlx:name="_y" />
    </owlx:individualPropertyAtom> 
    <owlx:individualPropertyAtom  owlx:property="&vra;creator"> 
      <owlx:Variable owlx:name="_x" />
      <owlx:Variable owlx:name="_z" />
    </owlx:individualPropertyAtom> 
  </owlx:antecedent> 
  <owlx:consequent> 
    <owlx:individualPropertyAtom  owlx:property="&vra;style/period"> 
      <owlx:Variable owlx:name="_z" />
      <owlx:Variable owlx:name="_y" />
    </owlx:individualPropertyAtom> 
  </owlx:consequent> 
</owlx:Rule> 

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 same location (latitude and longitude) as the Airport and that is an object of "layer" (a map DrawingLayer). Moreover, this map point has the Airport as an underlyingObject and has the Airport name as its Label

Note how the expressive power of OWL Rules 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.

<!--
Background knowledge about airports and maps:
-->

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

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

<owlx:Individual owlx:name="&airport;GEC">
  <owlx:type owlx:name="&airport-ont;Airport" /> 
  <owlx:DataPropertyValue owlx:property="airport-ont:name">
    <owlx:DataValue owlx:datatype="&xsd;string">Spokane Intl</owlx:DataValue> 
  </owlx:DataPropertyValue>
  <owlx:ObjectPropertyValue owlx:property="location">
    <owlx:Individual>
      <owlx:DataPropertyValue owlx:property="latitude">
        <owlx:DataValue>47.6197</owlx:DataValue> 
      </owlx:DataPropertyValue>
      <owlx:DataPropertyValue owlx:property="longitude">
        <owlx:DataValue>-117.5336</owlx:DataValue> 
      </owlx:DataPropertyValue>
    </owlx:Individual>
  </owlx:ObjectPropertyValue>
</owlx:Individual>
 
<owlx:Individual owlx:name="layer">
  <owlx:type owlx:name="&map;DrawingLayer" /> 
</owlx:Individual>
 
<owlx:Individual owlx:name="map">
  <owlx:type owlx:name="&map;Map" /> 
  <owlx:DataPropertyValue owlx:property="&map;name">
    <owlx:DataValue owlx:datatype="&xsd;string">Airports</owlx:DataValue> 
  </owlx:DataPropertyValue>
  <owlx:ObjectPropertyValue owlx:property="map:layer">
    <owlx:Individual owlx:name="layer"/>
  </owlx:ObjectPropertyValue>
</owlx:Individual>

<!--
A map:Location has latitude and longitude, both of which are doubles:
-->

<owlx:SubClassOf> 
  <owlx:sub> 
    <owlx:class="&map;Location" />
  </owlx:sub> 
  <owlx:super> 
    <owlx:IntersectionOf>
      <owlx:ObjectRestriction owlx:property="&map;latitude"> 
        <owlx:someValuesFrom owlx:datatype="&xsd;double"/>
      </owlx:ObjectRestriction> 
      <owlx:ObjectRestriction owlx:property="&map;latitude"> 
        <owlx:allValuesFrom owlx:datatype="&xsd;double"/>
      </owlx:ObjectRestriction> 
      <owlx:ObjectRestriction owlx:property="&map;longitude"> 
        <owlx:someValuesFrom owlx:datatype="&xsd;double"/>
      </owlx:ObjectRestriction> 
      <owlx:ObjectRestriction owlx:property="&map;longitude"> 
        <owlx:allValuesFrom owlx:datatype="&xsd;double"/>
      </owlx:ObjectRestriction> 
    </owlx:IntersectionOf>
  </owlx:super> 
</owlx:SubClassOf> 

<!--
If a map:Location is the sameLocation as another location, 
then it has the same values for latitude and longitude.
-->

<owlx:Rule> 
  <owlx:antecedent> 
    <owlx:classAtom> 
      <owlx:class="&map;Location" />
      <owlx:Variable owlx:name="_maploc" />
    </owlx:classAtom> 
    <owlx:individualPropertyAtom  owlx:property="sameLocation"> 
      <owlx:Variable owlx:name="_loc" />
      <owlx:Variable owlx:name="_maploc" />
    </owlx:individualPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="latitude"> 
      <owlx:Variable owlx:name="_loc" />
      <owlx:Variable owlx:name="_lat" />
    </owlx:datavaluedPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="longitude"> 
      <owlx:Variable owlx:name="_loc" />
      <owlx:Variable owlx:name="_lon" />
    </owlx:datavaluedPropertyAtom> 
  </owlx:antecedent> 
  <owlx:consequent> 
    <owlx:datavaluedPropertyAtom  owlx:property="&map;latitude"> 
      <owlx:Variable owlx:name="_maploc" />
      <owlx:Variable owlx:name="_lat" />
    </owlx:datavaluedPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="&map;longitude"> 
      <owlx:Variable owlx:name="_maploc" />
      <owlx:Variable owlx:name="_lon" />
    </owlx:datavaluedPropertyAtom> 
  </owlx:consequent> 
</owlx:Rule> 

<!--
Wherever an Airport is located, there is some map:Location
that is the sameLocation as the Airport's location, and that
is the location of a map Point that is an object of the
map:DrawingLayer "layer":
-->

<owlx:ObjectProperty owlx:name="&map;location" owlx:inverseOf="&map;isLocationOf" />
<owlx:ObjectProperty owlx:name="&map;object" owlx:inverseOf="&map;isObjectOf" />

<owlx:Rule> 
  <owlx:antecedent> 
    <owlx:classAtom> 
      <owlx:class="&airport-ont;Airport" />
      <owlx:Variable owlx:name="_airport" />
    </owlx:classAtom> 
    <owlx:individualPropertyAtom  owlx:property="location"> 
      <owlx:Variable owlx:name="_airport" />
      <owlx:Variable owlx:name="_loc" />
    </owlx:individualPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="latitude"> 
      <owlx:Variable owlx:name="_loc" />
      <owlx:Variable owlx:name="_lat" />
    </owlx:datavaluedPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="longitude"> 
      <owlx:Variable owlx:name="_loc" />
      <owlx:Variable owlx:name="_lon" />
    </owlx:datavaluedPropertyAtom> 
  </owlx:antecedent> 
  <owlx:consequent> 
    <owlx:classAtom> 
      <owlx:ObjectRestriction owlx:property="sameLocation"> 
        <owlx:someValuesFrom>
          <owlx:IntersectionOf>
            <owlx:class="&map;Location" />
            <owlx:ObjectRestriction owlx:property="&map;isLocationOf"> 
              <owlx:someValuesFrom>
                <owlx:IntersectionOf>
                  <owlx:class="&map;Point" />
                  <owlx:ObjectRestriction owlx:property="&map;isObjectOf"> 
                    <owlx:someValuesFrom>
                      <owlx:OneOf>
                        <owlx:Individual owlx:name="#layer" /> 
                      </owlx:OneOf>
                    </owlx:someValuesFrom>
                  </owlx:ObjectRestriction owlx:property="&map;isObjectOf"> 
                </owlx:IntersectionOf>
              </owlx:someValuesFrom>
            </owlx:ObjectRestriction owlx:property="&map;isLocationOf"> 
          </owlx:IntersectionOf>
        </owlx:someValuesFrom>
      </owlx:ObjectRestriction> 
      <owlx:Variable owlx:name="_loc" />
    </owlx:classAtom> 
  </owlx:consequent> 
</owlx:Rule> 

<!--
The map:Point whose map:location is the map:Location of an Airport 
has the airport as a map:underlyingObject and has a map:label 
which is the name of the Airport.
-->

<owlx:Rule> 
  <owlx:antecedent> 
    <owlx:classAtom> 
      <owlx:class="&airport-ont;Airport" />
      <owlx:Variable owlx:name="_airport" />
    </owlx:classAtom> 
    <owlx:individualPropertyAtom  owlx:property="location"> 
      <owlx:Variable owlx:name="_airport" />
      <owlx:Variable owlx:name="_loc" />
    </owlx:individualPropertyAtom> 
    <owlx:individualPropertyAtom  owlx:property="sameLocation"> 
      <owlx:Variable owlx:name="_loc" />
      <owlx:Variable owlx:name="_maploc" />
    </owlx:individualPropertyAtom> 
    <owlx:individualPropertyAtom  owlx:property="&map;location"> 
      <owlx:Variable owlx:name="_point" />
      <owlx:Variable owlx:name="_maploc" />
    </owlx:individualPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="&airport-ont;name"> 
      <owlx:Variable owlx:name="_airport" />
      <owlx:Variable owlx:name="_name" />
    </owlx:datavaluedPropertyAtom> 
  </owlx:antecedent> 
  <owlx:consequent> 
    <owlx:individualPropertyAtom  owlx:property="&map;underlyingObject"> 
      <owlx:Variable owlx:name="_point" />
      <owlx:Variable owlx:name="_airport" />
    </owlx:individualPropertyAtom> 
    <owlx:datavaluedPropertyAtom  owlx:property="&map;label"> 
      <owlx:Variable owlx:name="_point" />
      <owlx:Variable owlx:name="_name" />
    </owlx:datavaluedPropertyAtom> 
  </owlx:consequent> 
</owlx:Rule> 

5. Mapping to RDF Graphs

Rules have variables, so treating them as a semantic extension of RDF is very difficult. It is, however, still possible to provide an RDF syntax for rules---it is just that the semantics of the resultant RDF graphs will not be an extension of the RDF Semantics. A mapping to RDF/XML is most easily created as an extension to the XSLT transformation for the OWL XML Presentation syntax.

5.1. RDF Syntax Examples

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

<owlr:Variable rdf:ID="_x1"/>
<owlr:Variable rdf:ID="_x2"/>
<owlr:Variable rdf:ID="_x3"/>
<owlr:Rule> 
  <owlr:antecedent rdf:parseType="Collection">
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&eg;hasParent"/> 
      <owlr:argument1 rdf:about="#_x1" />
      <owlr:argument2 rdf:about="#_x2" />
    </owlr:individualPropertyAtom>
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&eg;hasSibling"/> 
      <owlr:argument1 rdf:about="#_x2" />
      <owlr:argument2 rdf:about="#_x3" />
    </owlr:individualPropertyAtom>
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&eg;hasSex"/> 
      <owlr:argument1 rdf:about="#_x3" />
      <owlr:argument2 rdf:about="#male" />
    </owlr:individualPropertyAtom>
  </owlr:antecedent>
  <owlr:consequent rdf:parseType="Collection"> 
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&eg;hasUncle"/> 
      <owlr:argument1 rdf:about="#_x1" />
      <owlr:argument2 rdf:about="#_x3" />
    </owlr:individualPropertyAtom>
  </owlr:consequent> 
</owlr:Rule> 

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

<owlr:Variable rdf:ID="_x"/>
<owlr:Variable rdf:ID="_y"/>
<owlr:Variable rdf:ID="_z"/>
<owlr:Rule> 
  <owlr:antecedent rdf:parseType="Collection">
    <owlr:classAtom> 
      <owlr:classPredicate rdf:about="&ulan;Artist"/> 
      <owlr:argument1 rdf:about="#_x" />
    </owlr:classAtom>
    <owlr:classAtom> 
      <owlr:classPredicate rdf:about="&aat;Style"/> 
      <owlr:argument1 rdf:about="#_y" />
    </owlr:classAtom>
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&aatulan;artistStyle"/> 
      <owlr:argument1 rdf:about="#_x" />
      <owlr:argument2 rdf:about="#_y" />
    </owlr:individualPropertyAtom>
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&vra;creator"/> 
      <owlr:argument1 rdf:about="#_x" />
      <owlr:argument2 rdf:about="#_z" />
    </owlr:individualPropertyAtom>
  </owlr:antecedent>
  <owlr:consequent rdf:parseType="Collection"> 
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="&vra;style/period"/> 
      <owlr:argument1 rdf:about="#_z" />
      <owlr:argument2 rdf:about="#_y" />
    </owlr:individualPropertyAtom>
  </owlr:consequent> 
</owlr:Rule> 

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

<owlr:Variable rdf:ID="_airport"/>
<owlr:Variable rdf:ID="_loc"/>
<owlr:Variable rdf:ID="_name"/>
<owlr:Variable rdf:ID="_lat"/>
<owlr:Variable rdf:ID="_lon"/>
<owlr:Rule> 
  <owlr:antecedent rdf:parseType="Collection">
    <owlr:classAtom> 
      <owlr:classPredicate rdf:about="&airport-ont;Airport"/> 
      <owlr:argument1 rdf:about="#_airport" />
    </owlr:classAtom>
    <owlr:individualPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="#location"/> 
      <owlr:argument1 rdf:about="#_airport" />
      <owlr:argument2 rdf:about="#_loc" />
    </owlr:individualPropertyAtom>
    <owlr:datavaluedPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="#latitude"/> 
      <owlr:argument1 rdf:about="#_loc" />
      <owlr:argument2 rdf:about="#_lat" />
    </owlr:datavaluedPropertyAtom>
    <owlr:datavaluedPropertyAtom> 
      <owlr:propertyPredicate rdf:resource="#longitude"/> 
      <owlr:argument1 rdf:about="#_loc" />
      <owlr:argument2 rdf:about="#_lon" />
    </owlr:datavaluedPropertyAtom>
  </owlr:antecedent>
  <owlr:consequent rdf:parseType="Collection"> 
    <owlr:classAtom> 
      <owlr:classPredicate>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#sameLocation"/>
          <owl:someValuesFrom>
            <owl:intersectionOf rdf:parseType="Collection">
              <owl:Class rdf:about="&map;Location"/>
              <owl:Restriction>
                <owl:onProperty rdf:resource="&map;isLocationOf"/>
                <owl:someValuesFrom>
                  <owl:intersectionOf rdf:parseType="Collection">
                    <owl:Class rdf:about="&map;Point"/>
                    <owl:Restriction>
                      <owl:onProperty rdf:resource="&map;isObjectOf"/>
                      <owl:someValuesFrom>
                        <owl:oneOf rdf:parseType="Collection">
                          <owl:Item rdf:resource="#layer"/>
                        </owl:oneOf>
                      </owl:someValuesFrom>
                    </owl:Restriction>
                  </owl:intersectionOf rdf:parseType="Collection">
                </owl:someValuesFrom>
              </owl:Restriction>
            </owl:intersectionOf rdf:parseType="Collection">
          </owl:someValuesFrom>
        </owl:Restriction>
      </owlr:classPredicate> 
      <owlr:argument1 rdf:about="_airport" />
    </owlr:classAtom>
  </owlr:consequent> 
</owlr:Rule> 

6. Usage Suggestions (Informative)

Extensibility and Interoperability Cautions

Users 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).

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 OWL 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 OWL Rules 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 suggestions is available at http://www.daml.org/listarchive/joint-committee/1491.html.

Acknowledgements

References

[OWL S&AS]

OWL Web Ontology Language Semantics and Abstract Syntax. Peter F. Patel-Schneider, Pat Hayes and Ian Horrocks, eds.

[OWL Reference]

OWL Web Ontology Language 1.0 Reference. Mike Dean, Dan Connolly, Frank van Harmelen, James Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Working Draft 12 November 2002. Latest version is available at http://www.w3.org/TR/owl-ref/.

[OWL XML]

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

[Lloyd87]

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

[Schmidt-Schauß89]

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

[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).

[RuleML]

Rule Markup Language Initiative