Schema Specification of Deliberation RuleML Version 1.0

New Format Notice: MediaWiki (Document Status Update, 15 October 2013)

The RuleML 1.0 Specification in HTML and its XML source are now frozen and will not be updated. The RuleML Wiki contains the latest snapshot of the RuleML 1.0 Specification, which is accessible from the short URL http://ruleml.org/1.0.

Harold Boley, Tara Athan, Adrian Paschke, Said Tabet, Benjamin Grosof,
Nick Bassiliades, Guido Governatori, Frank Olken, David Hirtle

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
2006-08-24 - Version 0.91
2011-09-27 - Version 0.91 Patched

2012-04-03 -

Version 1.0

Latest version: ruleml.org/spec/

Quick links:


RuleML has been designed for the interchange of the major kinds of Web rules in an XML format that is uniform across various rule languages and platforms. It has broad coverage and is defined as an extensible family of languages, whose modular system of schemas permits rule interchange with high precision.

The scope of this specification covers

The scope of this specification does not cover tools that make use of RuleML languages, such as parsers, inference engines or editors. For a listing of such tools, see the RuleML Implementations wiki page.

Version 1.0 is a "Rosetta Stone" release where two schema languages, XSD and Relax NG, are independently employed to formalize the syntax, to the extent possible within each language. See Design and Implementation of Highly Modular Schemas for XML: Customization of RuleML in Relax NG (RuleML in Relax NG) and the RuleML MYNG Wiki page for the details of this re-engineering effort. MYNG is an acronym for "Modular sYNtax confiGurator", or "Modularize Your NG", and may be pronounced either "ming" or "my N G".

The Version 1.0 XSD schemas are a minor modification of the patched XSD schemas of Version 0.91, which follow the tree-based modularization approach. A procedure for validation against the XSD schemas is described in Appendix 3.

The Relax NG schemas are a new component of the Version 1.0 release, and are intended to replace the hand-written XSD schemas in future releases. The Relax NG schemas are available for two serializations, "normal" and "relaxed", and follow a lattice-based modularization (RuleML in Relax NG). The relaxed-form serialization is permissive relative to the grammar given in the Content Models document, i. e. every Version 1.0 instance that is valid with respect to the Content Models document will validate against the relaxed serialization Relax NG schemas. The normal serialization Relax NG schemas validate instances in the normal form, which is described in the Normalizer section. Procedures for validation against the Relax NG schemas is described in Appendix 5.

Note that the 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 Primer. Also, the paper Overarching discusses the upper layer of the RuleML hierarchy of rules. In that terminology, the system of RuleML languages presented here covers derivation rules, which includes Horn Logic, and part of deliberation rules, in particular, First-Order Logic (FOL) with equality and negation-as-failure.

This is because we think it is important to start with a subset of simple rules (derivation rules), test and refine our principal strategy using these, and then proceed to more general categories of rules in the hierarchy (deliberation rules), as well as to other kinds of rules (reaction rules).

A comprehensive Glossary accompanies this specification.

The grammar of Version 1.0 is partially described in the Content Models document, where the content model of each individual element is compared across the named sublanguages, as specified within the XSD Schemas. The RuleML grammar is also partially described by the Relax NG Schemas.

Below is a summary of the changes in Version 1.0:

Readers who already know Version 0.91 may want to refer to the Changes section.

Examples

Numerous sample RuleML documents have been prepared and maintained; some exemplify features of RuleML and are useful didactically while others are mostly for testing puposes. Updated examples (e.g., own.ruleml and reify.ruleml) accompany the Version 1.0 release and can be found with all the others in the Examples directory. The following examples are new:

Examples from previous versions of RuleML are also maintained, e.g. 0.91 examples).

XSLT-Based Upgrader

Continuing the practice begun in 0.86, an XSLT stylesheet named 091-to-100.xslt has been created to automatically update Version 0.91 documents to Version 1.0. For instance, taking the discount example from 0.91 as input, the stylesheet outputs the following: discount_100.ruleml. Additional translation output samples are found in the Upgrader directory.

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

The stylesheet has also been tested using oXygen version 12.2, whereby it was confirmed that all examples in the directory http://ruleml.org/1.0/exa are properly upgraded. However, the upgraded instances documents will have the RuleML namespace as the default namespace, independent of the choice of prefix for the RuleML namespace in the original instance. A similar 091-to-ruleml100.xslt has been developed that uses the prefix "ruleml" for the RuleML namespace.

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 1.0/exa/ 0.91/exa/ 091-to-100.xslt

A use example of the Upgrader is described in the WineOnto migration path documentation.

XSLT-Based Normalizer

RuleML has always allowed abbreviated encoding (skipped edge tags and default attribute values) and some freedom in the ordering of elements. The new Relax NG schemas allows even more freedom in element ordering than the XSD schemas, with all perturbations possible as long as the missing edge tags may be unambiguously reconstructed. An XSLT stylesheet has been developed (see RON, also see the Normalizer directory) for normalizing the syntax used in a given Version 1.0 instance, undoing the abbreviated encoding and re-ordering of elements. An example of the normal form is the expanded version of the compact 'own' example.

The goals of this normalizer include the following:

We say that using this normalizer followed by schema-based RuleML validation performs "normalidation" on RuleML instances. That is to say, not only are missing edge tags and attributes with default values inserted into the Version 1.0 instance in order to normalize it, but the general tree structure of the file is also validated syntactically to ensure that Node and edge elements only appear in correct positions.

The following is a list of the operations the Version 1.0 XSLT Normalizer should perform whenever it is used on an XML instance. Note that the Normalizer is intended to successfully transform XML instances that may not be valid Version 1.0 (validation is the second step of the "Normalidation" process); therefore no assumptions are made about the names or number of child elements in the instance being transformed.

For example, the compact version of the 'own' example:

<RuleML>
  <Assert mapClosure="universal">
    <Implies>
      <And>
        <Atom>
          <Rel>buy</Rel>
          <Var>person</Var>
          <Var>merchant</Var>
          <Var>object</Var>
        </Atom>
        <Atom>
          <Var>person</Var>
          <Rel>keep</Rel>
          <Var>object</Var>
        </Atom>
      </And>
      <Atom>
        <Var>person</Var>
        <Rel>own</Rel>
        <Var>object</Var>
      </Atom>
    </Implies>
    ...
    <Atom>
      <Ind>Mary</Ind>
      <Rel>keep</Rel>
      <Ind>XMLBible</Ind>
    </Atom>
  </Assert>
</RuleML>
  

should be normalized to the expanded version:

<RuleML>
  <act index="1">
  <Assert mapClosure="universal">
      <formula>
        <Implies>
          <if>
            <And>
              <formula>
                <Atom>
                  <op><Rel>buy</Rel></op>
                  <arg index="1"><Var>person</Var></arg>
                  <arg index="2"><Var>merchant</Var>	</arg>
                  <arg index="3"><Var>object</Var></arg>
                </Atom>
              </formula>
              <formula>
                <Atom>
                  <op><Rel>keep</Rel></op>
                  <arg index="1"><Var>person</Var></arg>
                  <arg index="2"><Var>object</Var></arg>
                </Atom>
              </formula>
            </And>
          </if>
          <then>
            <Atom>
              <op><Rel>own</Rel></op>
              <arg index="1"><Var>person</Var></arg>
              <arg index="2"><Var>object</Var></arg>
            </Atom>
          </then>
        </Implies>
      </formula>
      ...
      <formula>
        <Atom>
          <op><Rel>keep</Rel></op>
          <arg index="1"><Ind>Mary</Ind></arg>
          <arg index="2"><Ind>XMLBible</Ind></arg>
        </Atom>
      </formula>
  </Assert>
  </act>
</RuleML>

XSLT processing will be accomplished using procedures identical to those of the XSLT Upgrader. Instructions for the W3C web-based process can be found in Appendix 4.

Glossary

The Glossary for Version 1.0 contains descriptions for every element in Version 1.0.

Attribute Mapping

As in previous versions of RuleML, there are several pairs of attributes in Version 1.0 that have names which differ only by a 'map' prefix: @closure and @mapClosure, @direction and @mapDirection, and @material and @mapMaterial. The naming convention reflects attribute 'mapping' through XML trees, where

<NodeName mapAttribute="..."><C1>. . .</C1>. . .<CN>. . .</CN></NodeName>

basically acts like

<NodeName><NodeChildName1 attribute="...">. . .</NodeChildName1>. . .<NodeChildNameN attribute="...">. . .</NodeChildNameN></NodeName>

or

<NodeName><edgeName1><NodeChildName1 attribute="...">. . .</NodeChildName1></edgeName1>. . .<edgeNameN><NodeChildNameN attribute="...">. . .</NodeChildNameN></edgeNameN></NodeName>

Modularization

The XSD schemas use a tree-based modularization strategy. The most current model of the XSD modularization of RuleML is always documented at http://ruleml.org/modularization/#Model.

The Relax NG schemas use a different modularization approach based on lattices. The details are given in the publication about the re-engineering of RuleML in Relax NG and the RuleML MYNG Wiki page. MYNG is accessible through a GUI or, for advanced users, a PHP script .

XSDs

The XSD Schemas specification of Version 1.0 has been created using an approach that is consistent with that of all earlier XSDs, and back to that of the (version 0.85) DTDs. The Content Models document should be read in parallel to the XSD schemas, because they give a high-level, complete documentation of the XSDs. Likewise, the Glossary can help to find quick descriptions of, and cross-reference between, the Version 1.0 XML elements.

Acknowledgements

We wish to acknowledge the contributions of: Asaf Adi, Sadnan Al-Manir, Yevgen Biletskiy, Alexander Cameron, Carlos Damasio, Mike Dean, Tshering Dema, Doan Dai Duong, Andreas Eberhart, Michael Kifer, Alex Kozlenkov, Jae Kyu Lee, Monika Machunik, Jeff Z. Pan, Steve Ross-Talbot, Omair Shafiq, Michael Sintek, Bruce Spencer, Giorgos Stamou, Suzette Stoutenburg, Le Thi Thu Thuy, and Gerd Wagner.

Appendices

Appended below is a simple example rulebase (Appendix 1), the XSD Schema for the Datalog sublanguage of RuleML to which the rulebase conforms (Appendix 2), instructions for how to validate instances against the XSD schema (Appendix 3), instructions for how to transform with XSLT stylesheets (Appendix 4), and instructions for how to validate instances against the Relax NG schema (Appendix 5).

Appendix 1: New Example rulebase in RuleML

Source: own-xsd.ruleml



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

<RuleML
xmlns="http://ruleml.org/spec"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ruleml.org/spec http://ruleml.org/1.0/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~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              *                                                                            *                       
           if *                                                                       then * 
              *                                                                            *  
             And~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                 Atom~~~~~~~~~~~~~~~~~~
                   |                                   |                                          *     |     |  
                   |                                   |                                      op  *     |     |  
                   |                                   |                                          *     |     |    
                 Atom~~~~~~~~~~~~~~~~~~~~~~~~~~~     Atom~~~~~~~~~~~~~~~~~~                      Rel   Var   Var
                          *     |      |       |              *     |     |                       .     .     .    
                      op  *     |      |       |          op  *     |     |                       .     .     .    
                          *     |      |       |              *     |     |                       .     .     .
                         Rel   Var    Var     Var            Rel   Var   Var                     own  person object
                          .     .      .       .              .     .     . 
                          .     .      .       .              .     .     .
                          .     .      .       .              .     .     .
                         buy  person merchant object        keep  person object

    ... end XML comment -->

    <Implies>
      <if>
        <!-- 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>
      </if>
      <then>
        <Atom>
          <op><Rel>own</Rel></op>
          <Var>person</Var>
          <Var>object</Var>
        </Atom>
      </then>
    </Implies>

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

    <Implies>
      <if>
        <Atom>
          <op><Rel>sell</Rel></op>
          <Var>merchant</Var>
          <Var>person</Var>
          <Var>object</Var>
        </Atom>
      </if>
      <then>
        <Atom>
          <op><Rel>buy</Rel></op>
          <Var>person</Var>
          <Var>merchant</Var>
          <Var>object</Var>
        </Atom>
      </then>
    </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). -->
 
    <Atom>
      <op><Rel>keep</Rel></op>
      <Ind>Mary</Ind>
      <Ind>XMLBible</Ind>
    </Atom>
  </Assert>
 
</RuleML>

Appendix 2: XSD for the Datalog sublanguage of RuleML

Source: datalog.xsd


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

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

	<xs:annotation>
		<xs:documentation xml:lang="en">
			XML Schema for the RuleML sublanguage "datalog".
			File: datalog.xsd
			Version: 1.0
			Last Modification: 2010-07-16
		</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 3: Instructions on validating the example online with XSD

  1. Direct your browser to http://www.w3.org/2001/03/webdata/xsv
  2. Enter the following URL of our example RuleML file (or any other) into the textfield preceded by "Address(es)": http://ruleml.org/1.0/exa/Datalog-xsd/own-xsd.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 3.1-1 of 2007/12/11 16:20:05


Schema resources involved

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

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

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

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

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

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

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

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

Attempt to load a schema document from http://ruleml.org/1.0/xsd/modules/iri_module.xsd (source: include) for http://ruleml.org/spec, succeeded


Appendix 4: Normalizing or Upgrading RuleML files with XSLT

  1. Go to the W3C XSLT Service at http://www.w3.org/2005/08/online_xslt/
  2. For the xsl resource insert the URL for either the Version 1.0 Normalizer XSLT (http://ruleml.org/1.0/xslt/normalizer/100_normalizer.xslt) or the RuleML 0.91-1.0 Upgrader XSLT (http://ruleml.org/1.0/xslt/upgrader/091-to-100.xslt).
  3. For the xml resource use a file that is either considered compact RuleML (for the normalizer) or a RuleML file using an older version of RuleML (for the upgrader). Compact examples for the normalizer can be found in the Normalizer directory, while old version examples for the upgrader can be found in the Upgrader directory.
  4. Once both URL's have been entered, click transform. To see the result, in some browsers you need to do "View | Page Source".

Appendix 5: Validating an Instance against a Relax NG schema

Validator.nu is an easy-to-use online tool for validating an XML instance against a Relax NG schema. A basic procedure for using this tool is as follows:
  1. Open the Validator.nu webpage in your browser.
  2. Choose how you want to enter the instance:
  3. Skip the Encoding field
  4. Type or paste a URL to the schema you wish to validate against. Only schemas available from the internet can be used. For example, the URL http://ruleml.org/1.0/relaxng/schema_rnc.php may be used to validate all Version 1.0 instances.
  5. Skip the rest of the fields, and click Validate.
  6. The result will appear below, followed by a copy of the instance source.
An online demo of validation using the RuleML Relax NG schemas with Validator.nu, including more advanced options, is available at the Demo section of the MYNG Wiki. Other tools that may be used for validation against Relax NG schemas are described in the Tools section of the MYNG Wiki.

Appendix 6: Changes

Changes in the Version 1.0 XSD release relative to the previous XSD version 0.91 are detailed below, including examples where appropriate.

The terminology "Type" and "role" (when referring to XML tags or elements) has been changed to "Node" and "edge", in order to avoid the confusion caused by simultaneous usage of multiple meanings of these words, as well as to emphasize the connection to graphs, especially the RDF graph model.

Schematron dependency has been reduced (as comments in the code). For example, the following code provides annotation related to restrictions on the interpretation attribute of nested functions.

<xs:annotation>
  <xs:appinfo>
    <sch:pattern name="Uninterpreted functions">
      <sch:rule context="r:Expr/r:Fun[@per='no']">
        <sch:assert test=
          "not(../r:Expr/r:Fun[@per='yes'] or
           ../r:arg/r:Expr/r:Fun[@per='yes'] or
           ../r:Expr/r:op/r:Fun[@per='yes'] or 
           ../r:arg/r:Expr/r:op/r:Fun[@per='yes'])">
          Functions nested within an uninterpreted function must also be uninterpreted.
        </sch:assert>
      </sch:rule>
    </sch:pattern>
  </xs:appinfo>
</xs:annotation>

Edge elements <head> and <body> are replaced with <then> and <if>, respectively. These elements appear as children of <Implies> and <Entails>. For example, the following implication:

<Implies>
  <if>
    <And>
      <Atom>
        <Rel>premium</Rel>
        <Var>cust</Var>
      </Atom>
      <Atom>
        <Rel>regular</Rel>
        <Var>prod</Var>
      </Atom>
    </And>
  </if>
  <then>
    <Atom>
      <Rel>discount</Rel>
      <Var>cust</Var>
      <Var>prod</Var>
      <Data>5.0 percent</Data>
    </Atom>
  </then>
</Implies>

expresses the statement "A premium customer recieves a 5% discount on regular products."

Edge elements <lhs> and <rhs> are replaced with <left> and <right>, respectively. These elements appear as children of <Equal>. As an example consider the statement:

<Equal>    
  <left>
    <Ind>Lady Gaga</Ind>
  </left>
  <right>
    <Ind>Stefani Joanne Angelina Germanotta</Ind>
  </right>
</Equal>

which expresses that the individuals named "Lady Gaga" and "Stefani Joanne Angelina Germanotta" are the same.

In the SWSL languages, which are implemented only in the XSDs, Node elements <Hterm> and <Con> are replaced with <Uniterm> and <Const> respectively.

Attribute @in="no|semi|yes" with respective values are replaced with @per="copy|open|value". For example, the following functional expression uses the default value ("copy") of the attribute "per"

<Expr per="copy">
  <op><Fun>MultiplyFn</Fun></op>
  <arg index="1"><Data xsi:type="xs:integer">3</Data></arg>
  <arg index="2"><Var>X</Var></arg>
</Expr>

to generate an algebraic expression that may be evaluated after the variable X is bound to a numerical value. In contrast, the expression

<Expr per="value">
  <op><Fun>MultiplyFn</Fun></op>
  <arg index="1"><Data xsi:type="xs:integer">3</Data></arg>
  <arg index="2"><Data xsi:type="xs:integer">4</Data></arg>
</Expr>

will be evaluated (to <Data xsi:type="xs:integer">12</Data>) before inference is performed.

Attribute @uri is replaced with @iri. This attribute is used to identify, by Internationalized Resource Identifier (IRI), the elements <Ind>, <Rel> and <Fun> as individuals, relations and functions, respectively. For example:

<Atom>
  <op>
    <Rel iri="http://dublincore.org/documents/dces/index.shtml.rdf#Creator"/>
  </op>
  <Ind iri="http://www.w3.org/Home/Lassila"/>
  <Data xsi:type="xs:string">Ora Lassila</Data>
</Atom>

expresses a fact equivalent to the RDF triple:

<rdf:RDF xmlns:s="http://dublincore.org/documents/dces/index.shtml.rdf">
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>Ora Lassila</s:Creator>
  </rdf:Description>
</rdf:RDF>

A new edge element <act>, with a required @index attribute, is introduced as an optional wrapper for all performatives of the <RuleML> element, as shown here:

<RuleML>
  <act index="1">
    <Assert/>
  </act>
</RuleML>

A new attribute @node is introduced as an optional IRI identifier of a Node element, useful for referencing the element in external meta-knowledge. It is allowed on all Nodes, including leaf Nodes such as <Data>, <Reify> and <Rel>.

<Implies node = "#rule1">
  <if>...</if><then>...</then>
</Implies>

A new edge element <meta> is introduced as a non-skippable wrapper of a formula expressing meta-knowledge, allowed zero to many times in the header of non-leaf Node elements. When a slotted <Atom> is wrapped in <meta>, the object of the slotted frame is assumed (unless specified otherwise) to be the reification of the parent Node, which may be specified with the @node attribute, or may be anonymous.

<Implies node="rule2">
  <meta>
    <Atom>
      <oid><Ind iri="#rule2"/></oid>
      <Rel iri="&ruleml;Override"/>
      <Ind iri="#rule1"/>
    </Atom>  
  </meta>
  <if>...</if><then>...</then>
</Implies>

The edge element <oid> is no longer allowed on all non-leaf Node elements, but is restricted to <Atom> and <Expr> (and <Uniterm> in the SWSL branch,) for use as an identifier for the object of slotted atoms and expressions. The functionality of providing an identifier for attaching meta-knowledge, such as the defeasible priority of rules, is transferred to the @node attribute.

The attributes @xml:base and @xml:id are allowed on all elements. The base for resolving relative IRI references is explicitly declared with @xml:base. The attribute @xml:id provides an alternate means of identifying elements, and is applicable to edges as well as nodes. The semantics of the @xml:id identifier, which denotes the information resource fragment that is the element and is referentially opaque, differs from that of the @node identifier, which denotes a reification of the logical or extra-logical entity associated with the element and is referentially transparent.

<Atom>
  <op xml:base="http://example.org" xml:id = "op1">
    <Rel iri="#rel2"/>
  </op>
</Atom>

Additional freedom in element order with partial stripe-skipping has been introduced in the "relaxed form serialization", as specified in the Relax NG schemas. In particular, infix and postfix operator notation is now allowed in the relaxed form serialization as long as the <op> element is not skipped.

Appendix 7: Issues

Features that are "deprecation candidates", i.e. that may be deprecated in future releases, include:

During the review of the Version 0.91 XSD schemas that was conducted in conjunction with the re-engineering of RuleML in Relax NG, a number of shortcomings and defects were identified. A number of these issues were patched in the Version 0.91 Patched release, and these patched XSDs form the basis of the hand-written XSDs for Version 1.0. There are several issues that could not be resolved in the handwritten XSDs, including:

The latter two issues will be resolved in Version 1.1 by discontinuing support of the handwritten XSDs, relying instead on XSD schemas automatically generated from the Relax NG schemas.


Site Contact: Tara Athan. Page Version: 2012-10-08


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