Schema Specification of RuleML 0.87

This is a revised XML Schema specification for RuleML version 0.87. Building upon the validation stable RuleML 0.86, this release incorporates several design changes in preparation for envisioned extensions such as the accommodation of Frame Logic (F-logic) slot-name variables and First-Order-Logic RuleML.

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 will no longer be maintained, but will continue to be available as an archive.

Contents

• Overview
• Changes
• Modularization
• Content Model-Based Approach
• XSDs
• XSLT
• Validation
• Future Work
• Appendix
• Appendix 1: XSD for a Datalog subset of RuleML
• Appendix 2: Example rulebase in RuleML
• Appendix 3: Instructions on validating the example against the XSD

Overview

The upper layer of the RuleML hierarchy of rules is discussed in our main page's design section. In that terminology, the system of RuleML XSDs presented here only covers derivation rules, not reaction rules.

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. We also introduce a URL/URI module corresponding to simple objects. The 'UR'-Datalog join of both of these classes then permits inferences over RDF-like 'resources' and can be re-specialized to RDF triples.

Version 0.87 incorporates the following changes:

• Java-style case-distinguished Type/role tags (instead of an underscore prefix for roles)
• slot name as a subelement instead of an attribute (with slot changed to a type, hence 'Slot')
• variables and complex terms as slot names
• "reconstructable role tags" simultaneously permitting both compact and expansion to RDF-like syntax

For more information, see the Changes section. A presentation summarizing this release is also available: PPT, PDF.

Note that there are currently no plans to continue maintaining a DTD specification of RuleML, and as such the 0.85 DTDs are expected to be the last. As always, the DTDs etc. of previous versions (including 0.85) will remain untouched, and can be considered as languages by themselves. (Tools capable of converting between XML Schema and DTDs such as XMLSpy are always available.)

Changes

Since RuleML 0.8 we have marked up 'role' tags via a "_"-prefix and have left 'type' tags unprefixed. Already at that time we also considered the convention Java uses for a similar distinction: having method-like 'role' tags start with a lower-case letter, and having class-like 'type' tags start with an upper-case letter. Such a Java convention is now proposed for RuleML 0.9 and so is being introduced now in version 0.87.

Specifically, the type/role tag syntax is changed as follows:

Old (Principle)	New (Principle)
type	Type
_role	role
Old (Examples)	New (Examples)
imp	Imp
_head	head
...	...

Another change is that slot names are now subelements instead of attributes to accommodate F-logic. This means that slot is now a type tag (so, with the new naming convention, capitalized 'Slot') to accommodate the alternating type/role "striped syntax" (see below). A non-positional metarole tag, 'role', is introduced as a substitute (see role tag reconstruction discussion below). For example,

<Atom>
   ...
   <slot name="color"><Ind>blue</Ind></slot>
   ...
</Atom>

becomes

<Atom>
   ...
   <role>
      <Slot>
         <name><Ind>color</Ind></name>
         <filler><Ind>blue</Ind></filler>
      </Slot>
   </role>
   ...
</Atom>

where the role tags ('role', 'name' and 'filler') may be omitted, leaving just the type tags:

<Atom>
   ...
   <Slot><Ind>color</Ind><Ind>blue</Ind></Slot>
   ...
</Atom>

Note that these roles can always be reconstructed if the shorter, type-only syntax is used.

In fact, in the spirit of Sandro Hawke's StripeSkipping, such "reconstructable role tags" are now systematically incorporated into the syntax, thus allowing either compact or expanded forms (or any combination thereof) as introduced with Slots above and further exemplified below.

Compact (from own_compact.ruleml):

<Rulebase>
   ...
   <Fact>
     <Atom>
       <Rel>keep</Rel>
       <Ind>Mary</Ind>
       <Ind>XMLBible</Ind>
     </Atom>
   </Fact>
   ...
</Rulebase>

Expanded (from own_expanded.ruleml):

<Rulebase>
   ...
   <clause>
      <Fact>
         <head>
	     <Atom>
	        <opr><Rel>keep</Rel></opr>
	        <arg index="1"><Ind>Mary</Ind></arg>
	        <arg index="2"><Ind>XMLBible</Ind></arg>
	     </Atom>
	  </head>
      </Fact>
   </clause>
   ...
</Rulebase>

Note the introduction of the optional 'clause' role (for Facts, Imps and Queries under a Rulebase) and the optional 'arg' role (for positional arguments within an Atom). Also optionally introduced are 'role', as shown previously for Slots; 'side' for Eqs; 'wff' (well-formed formula) for And and Or; and 'strong' and 'weak' for Neg and Naf, respectively. These additional tags make the striped syntax of RuleML fully consistent (which is important for compatibility with RDF), while maintaining (even increasing) the level of user friendliness of the syntax by encouraging a more compact (type-only) form.

To further accommodate F-Logic, variables and complex terms may now also be used as slot names (in addition to the usual 'ind').

All examples from previous versions of RuleML have been updated to reflect these design changes using Extensible Stylesheet Language Transformations (XSLT). (See the XSLT section for more information.) The XSDs have also been updated based on these changes.

Modularization

The modularization used for Versions 0.7 and 0.8 was inverted in RuleML 0.85 to be more intuitive. The motivating factors behind this switch were simplicity (a single root with two distinct branches), consistency (inheritance in a single direction, for obvious super/subclass relationships) and efficiency (non-redundant implementation).

However, a limitation within XML Schema prevented this approach from being easily implemented (resulting in the unstable XSDs in 0.85), so the modularization was re-analyzed and a new model resulted. This updated model reflects both the -- now fully-validating -- (XSD) implementation and expressiveness layering of RuleML, simultaneously capturing both the abstract and concrete.

Content Model-Based Approach

DTDs have limited support for modularity, but it can be achieved in a roundabout way using macro-like parameter entities. In particular, the contents of an external file can be included using an externally-linked parameter entity. For example, the following includes the contents of datalog.dtd:

<!ENTITY % datalog_include SYSTEM "datalog.dtd">
%datalog_include;

Simple inclusion is not enough, though: overriding is also necessary. Previously, this was managed using INCLUDE/IGNORE sections: the section that declared the element which had to be changed was simply IGNOREd, then the element was re-declared.

In version 0.85, this clumsy method of overriding was replaced with a much more elegent solution wherein every element's content model is explicitly defined by a parameter entity. The metarole '_slot', for example became declared as follows:

<!ENTITY % _slot.content "(ind)"> 
<!ELEMENT _slot %_slot.content;>

Since parameter entities can overwrite one another (even across files), this content model could be easily replaced with another specified in a different DTD altogether, much like re-assigning a global variable in traditional programming languages. For example, the content model of the metarole '_slot' is just "(ind)" in urcbindatagroundfact.dtd (as above), but is extended to permit a variable (thus, becoming "(ind | var)") in urcbindatalog.dtd:

<!ENTITY % _slot.content "(ind | var)">

(Note that this overriding entity must be defined before the inclusion of other files.)

A visual demonstration of this process can be found on slide 25 of the Object-Oriented RuleML: Re-Modularized and XML Schematized via Content Models presentation.

The content model-based approach to modularization also works for XML Schema, using groups (and attributeGroups) instead of parameter entities. For example (now using 0.87 syntax),

<!ENTITY % slot.content "(Ind)"> 
<!ELEMENT slot %slot.content;>

becomes

<xs:attributeGroup name="slot.attlist"/>
<xs:group name="slot.content">
   <xs:sequence>
      <xs:element ref="Ind"/>
   </xs:sequence>
</xs:group>
<xs:complexType name="slot.type" mixed="true">
   <xs:group ref="slot.content"/>
   <xs:attributeGroup ref="slot.attlist"/>
</xs:complexType>
<xs:element name="slot" type="slot.type"/>

There is no need for workarounds in XSD: <redefine> makes the specified changes and includes everything else. For example,

<!ENTITY % slot.content "(Ind | Var)">

<!ENTITY % include SYSTEM "urcbindatagroundlog.dtd">
%include;

becomes

<xs:redefine schemaLocation="urcbindatagroundlog.xsd">
   <xs:group name="slot.content">
      <xs:choice>
         <xs:group ref="slot.content"/>
         <xs:element ref="Var"/>
      </xs:choice>
   </xs:group>
</xs:redefine>

XSDs

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

XSLT

An XSLT stylesheet named 086-to-087.xslt has been created to automatically update RuleML 0.86 documents to 0.87. This stylesheet has already been used to update all examples. For instance, taking the own example from 0.86 as input, the stylesheet outputs the following: own-087.ruleml. (See a comparison of these two files generated using HTML Diff.)

The XSLT processor used to perform these transformations is Saxon version SA 8.0 using the following command (affecting the whole directory at once):

   $ java net.sf.saxon.Transform -o 0.87/exa/ 0.86/exa/ 086-to-0.87.xslt

The stylesheet has also been tested using Xalan-Java (version 2.2).

Validation

To ensure validation stability, the 0.87 XSDs have been tested (using corresponding instance documents/examples) with numerous validators/tools. A summary of these validation results follows:

W3C XML Schema Validator (XSV) v 2.7-1
All examples and schemas validate perfectly. See Appendix 3 for instructions on validating an example against its XML Schema and the corresponding output.

Altova XMLSpy v 2004 rel. 4
XMLSpy actually uses two validators: one available in the text/grid view and another exclusively in the schema view. The two validators currently may produce different results, as happens to be the case with the RuleML 0.87 XSDs. The "schema" view is preferred for validating RuleML schemas; they validate perfectly with the slight modification of commenting out self-references as follows:

   <xs:attributeGroup name="Rel.attlist">
      <!-- <xs:attributeGroup ref="Rel.attlist"/> -->
      <xs:attributeGroup ref="href.attrib"/>
   </xs:attributeGroup>

Saxon v SA 8.0
All examples and schemas validate perfectly (see Michael Kay's confirmation). Sample output:

   $ java com.saxonica.Validate -t http://www.ruleml.org/0.87/exa/own.ruleml
   Saxon-SA 8.0 from Saxonica
   Java version 1.4.1_02
   Processing http://www.ruleml.org/0.87/exa/own.ruleml
   Execution time: 1132 milliseconds

MSXML v 4.0 DOM & SAX via Stylus Studio 5.3
All examples validate perfectly.

Xerces-J v 2.5.1 via Stylus Studio 5.3
All examples validate perfectly with the exception of the binary sublanguages. This is believed to be a bug -- an inquiry has been sent to the developer mailing list (xerces-j-dev@xml.apache.org).

Future Work

• fully compact and fully expanded role tag normal forms (possibly XSLTs between these and earlier "mixed" form)
• normal form of Slots used after positional arguments in Atoms
• first-order logic extensions
• reaction rules, transformation rules, ... (see the Design section)
• abstract syntax
• glossary of terms
• possibly merge UR and non-UR sublanguages and omit certain ones
• CLP (Corteous Logic Programs) overrides facts (work by Benjamin Grosof, MIT)
• guarded Horn Logic (suggestion of Wolfgang Nejdl, U Hannover)

Appendix

Appended below is the XML Schema (version 0.87) for a Datalog subset 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.87 XSDs, specified in a modular fashion, are available here: http://www.ruleml.org/0.87/xsd. The XSD files in the main directory represent actual sublanguages of RuleML, whereas those in the modules subdirectory are elementary components included in the main XSDs. For more information, see the Modularization section.

More sample files -- each referring to the most specific XSD which validates it -- can be found at http://www.ruleml.org/0.87/exa.

Appendix 1: XSD for a Datalog subset of RuleML

Source: datalog.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
targetNamespace="http://www.ruleml.org/0.87/xsd" 
xmlns="http://www.ruleml.org/0.87/xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>

	<xs:annotation>
		<xs:documentation xml:lang="en">
			XML Schema for a Datalog RuleML sublanguage
			File: datalog.xsd
			Version: 0.87
			Last Modification: 2004-07-23
		</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:
		* toplevel
		* desc
		* clause
		* boole
		* atom
		* role
		* term

		For details on each module, including what element and/or attribute declarations
		they contain, please refer to them individually.
	-->
	<xs:include schemaLocation="modules/toplevel_module.xsd"/>

	<xs:include schemaLocation="modules/desc_module.xsd"/>

	<xs:include schemaLocation="modules/clause_module.xsd"/>

	<xs:include schemaLocation="modules/boole_module.xsd"/>

	<xs:include schemaLocation="modules/atom_module.xsd"/>

	<xs:include schemaLocation="modules/role_module.xsd"/>

	<xs:include schemaLocation="modules/term_module.xsd"/>
	
</xs:schema>

Appendix 2: Example rulebase in RuleML

Source: own.ruleml

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

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

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

 imp~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          *                         *
     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 -->

<Imp>
  <head>
    <Atom>
      <opr><Rel>own</Rel></opr>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <!-- explicit 'and' -->
    <And>
      <Atom>
        <opr><Rel>buy</Rel></opr>
        <Var>person</Var>
        <Var>merchant</Var>
        <Var>object</Var>
      </Atom>
      <Atom>
        <opr><Rel>keep</Rel></opr>
        <Var>person</Var>
        <Var>object</Var>
      </Atom>
    </And>
  </body>
</Imp>

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

<Imp>
  <head>
    <Atom>
      <opr><Rel>buy</Rel></opr>
      <Var>person</Var>
      <Var>merchant</Var>
      <Var>object</Var>
    </Atom>
  </head>
  <body>
    <Atom>
      <opr><Rel>sell</Rel></opr>
      <Var>merchant</Var>
      <Var>person</Var>
      <Var>object</Var>
    </Atom>
  </body>
</Imp> 
 
<!-- The third rule is a fact that asserts that
John sells XMLBible to Mary. -->
 
<Fact>
  <head>
    <Atom>
      <opr><Rel>sell</Rel></opr>
      <Ind>John</Ind>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
  </head>
</Fact>
 
<!-- 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 -->
 
<Fact>
  <head>
    <Atom>
      <opr><Rel>keep</Rel></opr>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
  </head>
</Fact>
  
</Rulebase>

Appendix 3: Instructions on validating the example against the XSD

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

1. Direct your browser to 

(Validator for XML Schema REC 20010502 version).

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.87/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):

Site Contact: Harold Boley. Page Version: 2004-08-12


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