Schema Specification of RuleML 0.9

David Hirtle, Harold Boley, Benjamin Grosof, Michael Kifer,
Michael Sintek, Said Tabet, Gerd Wagner

Version history:

2001-01-25 - Version 0.7
2001-07-11 - Version 0.8
2003-12-09 - Version 0.85
2004-06-23 - Version 0.86
2004-08-12 - Version 0.87
2005-03-01 - Version 0.88
2005-05-27 - Version 0.89

2005-11-09 -

Version 0.9

Latest version: www.ruleml.org/spec

Quick links:

Content Models, Schemas (Archived DTDs), Examples, Glossary


This is the revised XML Schema specification for RuleML version 0.9.

Each XML Schema Definition (XSD) in the evolving hierarchy corresponds to a specific RuleML sublanguage. The implementation uses a modularization approach similar to the one in XHTML in order to offer appropriate flexibility and accomodate different implementations and approaches. Note that the Document Type Definition (DTD) specification of RuleML is no longer being maintained, but will continue to be available as an archive. Tools capable of converting between XML Schema and DTDs such as XMLSpy are always available.

Contents

Overview

An introduction to RuleML is given in our tutorial. Also, the main page's design section discusses the upper layer of the RuleML hierarchy of rules. In that terminology, the system of RuleML XSDs presented here only covers derivation rules, not reaction rules (see the official model)

This is because we think it is important to start with a subset of simple rules, test and refine our principal strategy using these, and then work 'up' to the more general categories of rules in the hierarchy. For this we choose Datalog, a language corresponding to relational databases (ground facts without complex domains or 'constructors') augmented by views (possibly recursive rules), and work a few steps upwards to further declarative rules as allowed in (equational) Horn logic.

Below is a summary of the changes in version 0.9:

For more information, see the Changes section.

A comprehensive glossary accompanies this specification.

The grammar of RuleML 0.9 (i.e. the content model of each individual tag) is available as a single document called Content Models for RuleML in addition to being encoded within the XML Schemas.

Changes

RuleML 0.9 consists of the following changes relative to the previous version 0.89.

The sublanguage of hornlog with negation-as-failure (nafhornlog), as implemented by OO jDREW, is added to the family of sublanguages (see the Modularization section). The language is analogous to nafdatalog, differing only by the addition of complex terms and rest variables.

Since RuleML 0.8, the <opr>, <opc> and <opf> roles have been substituted (because of technical reasons) for a generic operator of relations, functions and constructors. These are now merged into such a generic operator (<op>) using context-sensitivity (i.e. the allowable content of <op> depends on whether it is within an <Atom>, <Cterm>, etc). This is demonstrated in book.ruleml:

 <Atom>
   <op><Rel>book</Rel></op>
   <Cterm>
     <op><Ctor>parts</Ctor></op>
     <Var>title</Var>
     <Var>autor</Var>
     <Var>toc</Var>
     <Var>chapters</Var>
   </Cterm>
 </Atom>

Mutual exclusion (<Mutex>) is generalized as integrity constraints (<Integrity>). As with the original <Mutex> tag, <Integrity> is allowable within the <Protect> performative (optionally wrapped by a <warden> role). For example, the constraint that the discount offered to the same customer cannot be two distinct values (from the SWSL submission to the W3C) would be marked up as

 <Integrity>
   <Implies>
     <Neg>
       <Equal>
         <Var>Y</Var>
         <Var>Z</Var>
       </Equal>
     </Neg>   
     <Neg>
       <And>
         <Hterm>
           <Con>pricediscount</Con>
           <Var>CUST</Var>
           <Var>Y</Var>
         </Hterm>
         <Hterm>
           <Con>pricediscount</Con>
           <Var>CUST</Var>
           <Var>Z</Var>
         </Hterm>
       </And>
     </Neg>
   </Implies>
 </Integrity>

instead of this syntax introduced in 0.89:

 <Mutex>
   <oppo>
     <And>
       <Hterm>
         <Con>pricediscount</Con>
         <Var>CUST</Var>
         <Var>Y</Var>
       </Hterm>
       <Hterm>
         <Con>pricediscount</Con>
         <Var>CUST</Var>
         <Var>Z</Var>
       </Hterm>
     </And>
   </oppo>
   <mgiv>
     <Neg>
       <Equal>
         <Var>Y</Var>
         <Var>Z</Var>
       </Equal>
     </Neg>
   </mgiv>
 </Mutex>

The new @kind attribute is optionally added to <Implies> for the purpose of distinguishing between FOL and LP types of implication (as in the Web Rule Language).

An n-ary <RuleML> toplevel element is introduced (formally similar to RDF's <rdf:RDF>), permitting (ordered) transactions of the performatives <Assert>, <Query> and <Protect>. This allows combining, for example, asserted and queried content in the same document, as in discount.ruleml:

 <RuleML>
   <Assert>
     <Implies>
	   <And>
	     <Atom>
		   <op><Rel>premium</Rel></op>
		   <Var>customer</Var>
	     </Atom>
  	     <Atom>
		   <op><Rel>regular</Rel></op>
		   <Var>product</Var>
	     </Atom>
	   </And>
	   <Atom>
  	     <op><Rel>discount</Rel></op>
	     <Var>customer</Var>
	     <Var>product</Var>
	     <Ind>5.0 percent</Ind>
	   </Atom>
     </Implies>
     ...
   </Assert>
   <Query>
     <Atom>
       <op><Rel>discount</Rel></op>
       <Var>customer</Var>
       <Var>product</Var>
       <Var>amount</Var>
     </Atom>
   </Query>
 </RuleML>

The attributes @wlab and @wref are replaced with a single attribute: @uri (deviating from XML's @id vs. @idref and RDF's @about vs. @resource dualisms). This change allows a <Var> to 'read' or 'input' an <Ind uri="..."/> and 'write' or 'output' it as an <Ind uri="..."/>.

Existing performatives (<Assert>, <Query> and <Protect>) now implicitly assume that an <And> surrounds their clauses. For this reason, the @mapClosure and @mapDirection attributes are added to <Assert> and <Protect>, and @closure is added to <Query>. For example, the beginning of factorial.ruleml changes from

 <Assert>
   <And mapClosure="universal">
     <Equal>
       <Nano>
         <Fun>fac</Fun>
         <Ind>0</Ind>
       </Nano>
       <Ind>1</Ind>
     </Equal>
     ...

in 0.89 to the following in 0.9:

 <Assert mapClosure="universal">
   <Equal>
     <Nano>
       <Fun>fac</Fun>
       <Ind>0</Ind>
     </Nano>
     <Ind>1</Ind>
   </Equal>
   ...

(omitting the new <RuleML> root).

In <Assert>, <Query> and <Protect> elements, the <content> element was renamed to <formula>.

A prefix normal form is officially introduced, where certain role tags are 'positionalized', i.e. restricted to certain positions within content models (in this case, the beginning). This has always been the case for the <oid> role, which can only be at the beginning of an <Atom>. Now, however, other role tags are affected: in 0.9, <op> may no longer be postfix. While applying the prefix normal form to other role tags is under consideration (for future versions), some role tags (e.g. <body> and <head>) will not be affected. The prefix normal form greatly reduces the complexity of certain content models, helping avoid issues with current validation tools. Since postfix (and mixed postfix-and-prefix) forms are no longer possible in 0.9, the 0.89-0.9 upgrader also transforms from postfix (and mixed postfix-and-prefix) forms to prefix normal form.

Finally, the optional element <degree> permits the assignment of an uncertainty value (between 0.0 and 1.0) to facts and rules. For example, the following rule (from Fuzzy RuleML) asserts that a person's happiness is more dependent on being healthy than being rich:

<Implies>
  <head>
    <Atom>
      <Rel>Happy</Rel>
      <Var>person</Var>
    </Atom>
  </head>
  <body>
    <And>
      <Atom>
        <degree>
	    <Data xsi:type="xs:float">0.5</Data>
	  </degree>
        <Rel>Rich</Rel>
        <Var>person</Var>
      </Atom>
      <Atom>
        <degree>
	    <Data xsi:type="xs:float">0.9</Data>
	  </degree>
        <Rel>Healthy</Rel>
        <Var>person</Var>
      </Atom>
    </And>
  </body>
</Implies>

Glossary

A glossary for RuleML 0.9 has been created, featuring descriptions for every tag in RuleML 0.9. The intent is to keep it maintained for future releases.

Modularization

The most current model of the modularization of RuleML is always documented at http://www.ruleml.org/modularization/#Model.

XSDs

A stable XML Schema representation of RuleML version 0.9 has been created using an approach that is consistent with that used in the (version 0.85) DTDs.

Validation

To ensure validation stability, the 0.9 XSDs are tested (using corresponding instance documents/examples) with a selection of the most reliable validators. A summary of these validation results follows:

W3C XML Schema Validator (XSV) v 2.10-1
All examples and schemas validate perfectly except for the binary sublanguages. There was a related known bug in XSV 2.7-1 affecting the binary sublanguages that may still be causing problems. See Appendix 3 for instructions on validating an example against its XML Schema and the corresponding output.

Examples

Numerous sample RuleML documents have been prepared and maintained as examples and for testing purposes. They are stored in the Examples directory. (Examples from previous versions of RuleML are also maintained, e.g. 0.89 examples).

XSLT-Based Upgrader

Continuing the practice begun in 0.86, an XSLT stylesheet named 089-to-090.xslt has been created to automatically update RuleML 0.89 documents to 0.9. For instance, taking the discount example from 0.89 as input, the stylesheet outputs the following: discount_90.ruleml. (See a comparison of these two files generated using HTML Diff.) Additional translation output samples are found in the Upgrader directory. In the comparison directory a comparison between manual and automatic updates of a few files from the 0.89 exa directory can be found.

Upgrader transformation can be accomplished using a web-based XSLT transformation tool provided by W3C. Instructions for this process can be found in Appendix 4.

The stylesheet has also been tested using XML Spy.

An XSLT processor which may be used to perform these transformations on a whole directory at once is Saxon, using the following command:

$ java net.sf.saxon.Transform -o 0.90/exa/ 0.89/exa/ 089-to-090.xslt

Striped Syntax

There are two kinds tags in RuleML: method-like 'role' tags and class-like 'type' tags. The two are easily distinguished by their initial letter, much like the convention used in Java: role tags start with a lower-case letter, whereas type tags start with an upper-case letter. For example, <head> is a role tag and <Ind> is a type tag.

Furthermore, type and role tags alternate in RuleML. For example, notice the alternation in this a fact asserting that John sells XMLBible to Mary:

 <Atom>
   <op>
     <Rel>sell</Rel>
   </op>
   <arg index="1">
     <Ind>John</Ind>
   </arg>
   <arg index="2">
     <Ind>Mary</Ind>
   </arg>
   <arg index="3">
     <Ind>XMLBible</Ind>
   </arg>
 </Atom>

This is known as the "striped syntax" of RuleML, and is important for compatibility with RDF. Because this is quite verbose, all role tags can also be skipped (in the spirit of Sandro Hawke's StripeSkipping), leaving a more compact form. For example, the above fact can be shortened to:

 <Atom>
   <Rel>sell</Rel>
   <Ind>John</Ind>
   <Ind>Mary</Ind>
   <Ind>XMLBible</Ind>
 </Atom>

Note that there is no loss of information, because all role tags can be reconstructed based on the remaining type tags. In fact, this reconstruction (from the latter positional form to the former slotted form) can be done automatically via XSLT, as with the Normalizer in 0.89.

This gives the syntax of RuleML a lot of flexibility because it allows either a compact or expanded form (or any combination thereof), where the compact form is more user-friendly and the expanded (normalized) form is more compatible with other languages.

Attribute Mapping

There are two pairs of attributes in RuleML that have names which differ only by a 'map' prefix: closure and mapClosure, and direction and mapDirection. The naming convention reflects attribute 'mapping' through XML trees, where

<TypeTag mapAttribute="..."><c1>. . .</c1>. . .<cN>. . .</cN></TypeTag>

basically acts like

<TypeTag><c1 attribute="...">. . .</c1>. . .<cN attribute="...">. . .</cN></TypeTag>

Appendix

Appended below is the XML Schema (version 0.9) for the Datalog sublanguage of RuleML (Appendix 1). Also appended below is a simple example rulebase that conforms to that XSD (Appendix 2), and instructions for how to validate the example against the schema (Appendix 3).

The entire family of 0.9 XSDs, specified in a modular fashion, are available here: http://www.ruleml.org/0.9/xsd. Additional sample files, each referring to the most specific XSD which validates it, can be found at http://www.ruleml.org/0.9/exa.

Appendix 1: XSD for the Datalog sublanguage of RuleML

Source: datalog.xsd

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema 
xmlns="http://www.ruleml.org/0.9/xsd" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.ruleml.org/0.9/xsd"
>

	<xs:annotation>
		<xs:documentation xml:lang="en">
			XML Schema for a Datalog RuleML sublanguage
			File: datalog.xsd
			Version: 0.9
			Last Modification: 2005-11-09
		</xs:documentation>
	</xs:annotation>

	<!--
		Note that datalog is entirely composed of modules and that all other
		schema drivers rely on it, making it the root of the sublanguage family tree.
	-->

	<!--
		Datalog includes the following modules:
		* performative
		* desc
		* quantifier
		* connective
		* atom
		* slot
		* term
		* uri

		For details on each module, including what element and/or attribute declarations
		they contain, please refer to them individually.
	-->

	<xs:include schemaLocation="modules/performative_module.xsd"/>
	<xs:include schemaLocation="modules/desc_module.xsd"/>
	<xs:include schemaLocation="modules/quantifier_module.xsd"/>
	<xs:include schemaLocation="modules/connective_module.xsd"/>
	<xs:include schemaLocation="modules/atom_module.xsd"/>
	<xs:include schemaLocation="modules/slot_module.xsd"/>
	<xs:include schemaLocation="modules/term_module.xsd"/>
	<xs:include schemaLocation="modules/uri_module.xsd"/>

</xs:schema>

Appendix 2: Example rulebase in RuleML

Source: own.ruleml

<?xml version="1.0" encoding="UTF-8"?>

<RuleML
xmlns="http://www.ruleml.org/0.9/xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ruleml.org/0.9/xsd http://www.ruleml.org/0.9/xsd/datalog.xsd"
>

<Assert mapClosure="universal">

<!-- start XML comment ...

This example rulebase contains four rules.
The first and second rules are implications; the third and fourth ones are facts.

In English:

The first rule implies that a person owns an object
if that person buys the object from a merchant and the person keeps the object.

As an OrdLab Tree:

Implies~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          *                         *
     head *                    body *
          *                         *
        Atom~~~~~~~~~~~~~~~~~~     And~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                 *     |     |           |                                   |
             opr *     |     |           |                                   |
                 *     |     |           |                                   |        
                Rel   Var   Var        Atom~~~~~~~~~~~~~~~~~~~~~~~~~~~     Atom~~~~~~~~~~~~~~~~~~
                 .     .     .                  *     |      |       |              *     |     |
                 .     .     .              opr *     |      |       |          opr *     |     |
                 .     .     .                  *     |      |       |              *     |     |
                own  person object             Rel   Var    Var     Var            Rel   Var   Var
                                                .     .      .       .              .     .     . 
                                                .     .      .       .              .     .     .
                                                .     .      .       .              .     .     .
                                               buy  person merchant object        keep  person object

... end XML comment -->

<Implies>
  <head>
    <Atom>
      <op><Rel>own</Rel></op>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <!-- explicit 'And' -->
    <And>
      <Atom>
        <op><Rel>buy</Rel></op>
        <Var>person</Var>
        <Var>merchant</Var>
        <Var>object</Var>
      </Atom>
      <Atom>
        <op><Rel>keep</Rel></op>
        <Var>person</Var>
        <Var>object</Var>
      </Atom>
    </And>
  </body>
</Implies>

<!-- The second rule implies that a person buys an object from a merchant
if the merchant sells the object to the person. -->

<Implies>
  <head>
    <Atom>
      <op><Rel>buy</Rel></op>
      <Var>person</Var>
      <Var>merchant</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <Atom>
      <op><Rel>sell</Rel></op>
      <Var>merchant</Var>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </body>
</Implies>
 
<!-- The third rule is a fact that asserts that
John sells XMLBible to Mary. -->
 
    <Atom>
      <op><Rel>sell</Rel></op>
      <Ind>John</Ind>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
 
<!-- The fourth rule is a fact that asserts that
Mary keeps XMLBible.
 
Observe that this fact is binary - i.e., there are two arguments
for the relation. RDF viewed as a logical knowledge representation
is, likewise, binary, although its arguments have type restrictions,
e.g., the first must be a resource (basically, a URI). Some of the
DTD's on the RuleML website handle URL's/URI's (UR's); see especially
urc-datalog.dtd for inferencing with RDF-like facts -->
 
    <Atom>
      <op><Rel>keep</Rel></op>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
  
</Assert>

</RuleML>

Appendix 3: Instructions on validating the example against the XSD

Validating a RuleML 0.9 Sample Document: own.ruleml
====================================================

1. Direct your browser to 
http://www.w3.org/2001/03/webdata/xsv
(Validator for XML Schema REC (20010502) version, as amended).

2. Enter the following URL of our example RuleML file (or any other) into the textfield
preceded by "Address(es)": http://www.ruleml.org/0.9/exa/own.ruleml

3. If desired, check the "Show Warnings" box.

4. Click the "Get Results" button.

Note: The validation may take a while, and may require a full
refresh when re-validating to avoid caching.

Also note: Depending on your browser, you may want to select a different
output using the radio buttons just above the "Get Results" button.

***
 
You should get the following output (using the default output):

Schema validating with XSV 2.10-1 of 2005/04/22 13:10:49

  • Target: http://www.ruleml.org/0.9/exa/own.ruleml
       (Real name: http://www.ruleml.org/0.9/exa/own.ruleml
        Length: 3808 bytes
        Last Modified: Thu, 10 Nov 2005 05:56:30 GMT
        Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_fastcgi/2.4.2 mod_ssl/2.8.12 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26)
  • docElt: {http://www.ruleml.org/0.9/xsd}RuleML
  • Validation was strict, starting with type {http://www.ruleml.org/0.9/xsd}:RuleML.type
  • schemaLocs: http://www.ruleml.org/0.9/xsd -> http://www.ruleml.org/0.9/xsd/datalog.xsd
  • The schema(s) used for schema-validation had no errors
  • No schema-validity problems were found in the target

Schema resources involved

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/datalog.xsd (source: schemaLoc) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/performative_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/desc_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/quantifier_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/connective_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/atom_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/slot_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/term_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded

Attempt to load a schema document from http://www.ruleml.org/0.9/xsd/modules/uri_module.xsd (source: include) for http://www.ruleml.org/0.9/xsd, succeeded



Site Contact: Harold Boley. Page Version: 2011-01-31


"Practice what you preach": XML source of this homepage at index.xml (index.xml.txt);
transformed to HTML via the adaptation of Michael Sintek's SliML XSLT stylesheet at homepage.xsl (View | Page Source)