Specification of Deliberation RuleML 1.0

From RuleML Wiki
Jump to: navigation, search

Notice of Obsolescence

This specification has been superceded. See Specification of Deliberation RuleML.

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

Compansion Specification: Reaction RuleML 1.0

Quick links:

Overarching : Overarching Specification of Web Rules

Prerequisites: None, Level: Semi-formal

Deliberation RuleML : Specification of Deliberation RuleML

Prerequisites: None, Level: Semi-formal

Primer : Introduction to the RuleML Language

Prerequisites: None, Level: Informative

Content Models : High-level Presentation of the RuleML Serialization Grammar

Prerequisites: EBNF or Relax NG, Level: Semi-formal

XSD Schemas : Machine-readable schemas in XSD

Prerequisites: XSD, Level: Formal

Relax NG Schemas : Machine-readable grammar in the Relax NG language

Prerequisites: Relax NG, Level: Formal

MYNG : Modular sYNtax confiGurator, a GUI for customizing Relax NG schemas

Prerequisites: None, Level: Formal

Normalizer : Stylesheet for transforming into the normal-form serialization

Prerequisites: XSLT, Level: Formal

Upgrader : Stylesheet for transforming from Version 0.91 into Version 1.0

Prerequisites: XSLT, Level: Formal

Examples : Illustrative Instances of the Version 1.0 Language

Prerequisites: Primer, Level: Informative

Glossary : Definitions of Elements and Attributes

Prerequisites: Primer, Level: Semi-formal

Schema Docs : Diagrammatic Presentation of the RuleML Normal-Form Serialization Grammar

Prerequisites: Primer, Level: Semi-formal

OO jDREW : Reference Implementation of RuleML Operational Semantics

Prerequisites: Naf Hornlog RuleML, Level: Formal

Implementations : Implemented RuleML tools

Prerequisites: None, Level: Informative

This version: ruleml.org/1.0

Current version: deliberation.ruleml.org/spec

Development version: deliberation.ruleml.org/1.02



Version history:
Date Version
2001-01-25 -

Version 0.7 HTML

2001-07-11 -

Version 0.8 HTML

2003-12-09 -

Version 0.85 HTML

2004-06-23 -

Version 0.86 HTML

2004-08-12 -

Version 0.87 HTML

2005-03-01 -

Version 0.88 HTML

2005-05-27 -

Version 0.89 HTML

2005-11-09 -

Version 0.9 HTML

2006-08-24 -

Version 0.91 HTML

2011-09-27 -

Version 0.91 Patched HTML

2012-04-03 -

Version 1.0 HTML

2012-04-03 -

Version 1.0 Wiki

2014-07-25 -

Version 1.01 Wiki

2016-0x-yy -

Version 1.02 Wiki-dev


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

  • content models for the named sublanguages, available from the Content Models document (along with a glossary of all elements, available from the Glossary);
  • schemas, including
  • a mapping from the Version 1.0 syntax to the "normalized" Version 1.0 syntax as given in the Normalizer XSLT stylesheet;
  • a mapping from the preceding Version 0.91 XML syntax to Version 1.0 XML syntax as given in the Upgrader XSLT stylesheet.

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.

While the DTD[1] schemas of RuleML have been provided up to and including RuleML 0.85[2] (see archive), for versions later than RuleML 0.85, conversion tools (such as XMLSpy[3] and oXygen[4]) are recommended for obtaining DTDs from the newer RuleML schemas in XSD or Relax NG.

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

  • The terminology "Type" and "role" (when referring to XML tags or elements) has been changed to "Node" and "edge".
  • Schematron dependency has been reduced (as comments in the XSD schema code)
  • Edge elements <head> and <body>, replaced with <then> and <if>, respectively
  • Edge elements <lhs> and <rhs>, replaced with <left> and <right>, respectively
  • Node elements <Hterm> and <Con>, replaced with <Uniterm> and <Const> respectively
  • The attribute @in ="no|semi|yes" with respective values, replaced with @per ="copy|open|value"
  • The attribute @uri, for URIs, replaced with @iri, for IRIs
  • A new edge element <act> introduced as optional wrapper of all performatives (e.g. <Assert>) in the <RuleML> element
  • A new edge element <meta> is introduced as a non-skippable wrapper of a formula expressing meta-knowledge, allowed zero or more times in the header of non-leaf Node elements.
  • A new attribute @node is introduced as an optional IRI identifier of a Node element, useful for referencing the element in external meta-knowledge.
  • The edge element <oid> is no longer allowed on all non-leaf Node elements, but is restricted to <Atom> and <Expr>, for use as an identifier for the object of slotted atoms and expressions.
  • The attributes @xml:base and @xml:id are allowed on all elements.
  • Additional freedom in element order with partial stripe-skipping (see Overarching for an explanation of stripe-skipping and element order in RuleML) has been introduced in the "relaxed-form serialization", as specified in the Relax NG schemas.
  • The Normalizer at http://ruleml.org/1.0/xslt/normalizer/100_normalizer.quarantine.xslt has been deprecated. A refactored Normalizer has been developed at http://www2.unb.ca/~lbidlak1/index2.html.

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

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

  • synohomonyms.ruleml, which clarifies the semantics of the @iri attribute,
  • reify-evaluation-hornlogeq.ruleml, which clarifies the semantics of the "Reify" element;
  • several examples in the MYNG examples directory illustrating the new features introduced in the Relax NG schemas, including greater flexibility in stripe-skipping, decreased dependendence on element order and a fine-grained modularization of features.

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

3 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.

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

  • Reconstruct all skipped or optional edge tags to produce a fully striped form;
  • Perform canonical child ordering of sub-elements;
  • Make all default attributes explicit.

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.

  • <Implies>, <Entails>
    • When <if>-<then> edge elements are both missing, wrap the first "naked Node" (a Node element that has a Node parent element) child within an <if> edge element, and the second naked Node child within a <then> edge element.
    • If exactly one of the <if>-<then> edge elements is missing, wraps the first naked RuleML Node element within the missing edge element.
    • Re-orders the elements as <oid>, then <if>, followed by <then>, followed by any other children.
  • <Expr>
    • Wrap each naked <Fun> child (if any) with an <op> edge element.
    • Add <arg> edge elements (with an index attribute) wrapping each remaining naked RuleML Node (if any). The naked Node children that may occur within this element in a valid Version 1.0 instance include: <Ind>, <Var>, <Fun>, <Plex>, <Reify>, <Data>, or <Skolem>.
    • Re-order the child elements as <oid>, followed by <op>, followed by positional arguments (<arg>, then <repo>) followed by slotted arguments (<slot>, then <resl>), followed by any other children.
  • <Atom>
    • Wrap each naked <Rel> child (if any) with an <op>.
    • Adds <arg> edge elements (with an index attribute) wrapping each naked Node. The naked Node children that may occur within this element in a valid Version 1.0 instance include: <Ind>, <Var>, <Fun>, <Plex>, <Reify>, <Data>, or <Skolem>.
    • Re-order the child elements as <oid>, followed by <degree>, followed by <op>, followed by positional arguemnts (<arg>, then <repo>) followed by slotted arguemnts (<slot>, then <resl>), followed by any other children.
  • <Uniterm>
    • If there is no <op> element, wrap the first child that is not <oid> or <degree> within a <op> element.
    • Add <arg> edge elements (with an index attribute) to each of the remaining naked child Nodes. The naked Node children that may occur within this element in a valid Version 1.0 instance include: <Const>, <Var>, <Reify>, <Uniterm>, <Skolem>.
    • Re-order the child elements as <oid>, followed by <degree>, followed by <op>, followed by positional arguemnts (<arg>, then <repo>, followed by slotted arguemnts (<slot>, then <resl>), followed by any other children.
  • <Assert>, <Retract>, <Query>, <And>, <Or>
    • Wrap each naked child Node (if any) with a <formula> edge element.
  • <Forall>, <Exists>
    • Wrap each naked <Var> child Node (if any) with a <declare> edge element.
    • Wraps any other naked child Nodes with <formula> edge element.
    • Re-order the child elements as <oid>, followed by <declare>, followed by <formula>, followed by any other children.
  • <RuleML>
    • Wraps each naked child Node (if any) with an <act> edge element.
    • Re-order the child elements as <oid>, followed by <act>, followed by any other children.
  • <Neg>
    • Wraps each naked child Node (if any) with a <strong> edge element.
    • Re-order the child elements as <oid>, followed by <strong>, followed by any other children.
  • <Naf>
    • Wraps each naked child Node (if any) with a <weak> edge element.
    • Re-order the child elements as <oid>, followed by <weak>, followed by any other children.
  • <Equivalent>
    • Wraps each naked child Node (if any) with a <torso> edge element.
    • Re-order the child elements as <oid>, followed by <torso>, followed by any other children.
  • <Equal>
    • If there are two naked child Nodes, wraps first naked Node child with a <left> element and second naked Node child with <right> element.
    • Partial completion is also accepted. Example: if the first child has a <left> edge element, and the second child has no <left> or <right> edge element, the XSLT will wrap the second child with the <right> edge element.
    • Re-order the child elements as <oid>, followed by <degree>, followed by <left>, followed by <right>, followed by any other children.

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.

5 Glossary

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

6 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>

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

8 XSD Schemas

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.

9 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.

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

10.1 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>

10.2 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>

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

10.3.1 Schema validating with XSV 3.1-1 of 2007/12/11 16:20:05


10.4 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


10.5 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".

10.6 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:
    • Address - type or past a URL into the adjacent text field;
    • File Upload - use the browse dialog to locate the file on your local hard drive or network;
    • Text Field - type or paste text directly into the text area.
  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.

10.7 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 or more 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.

10.8 Appendix 7: Issues

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

  • <Reify> at Datalog and lower, as this introduces the possibility of nesting reification to an arbitrary level ;
  • the default values of attributes which indicate semantics variants: @direction, @mapDirection, @material, @mapMaterial, @oriented, @val, @per, as it may be more effective to use the absence of the attribute to indicate a "neutral" semantics;
  • the (SWSL) syntax, whose current syntax may be deprecated in favor of better integration with the rest of the RuleML syntax.

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:

  • Reification in Languages Below Datalog: the Binary sublanguages have an overly-permissive schema for reification (<Reify>). For example, in bindatagroundfact, it is valid to reify a universal quantification (<Forall> ), while it is not allowed to construct a universal quantification in the language. It is not possibly to fix this issue without discarding the tree-based modularization approach of the hand-written schemas. Because Version 1.0 is a "Rosetta" release, we have retained the hand-written XSD schemas that contain this issue for consistency with legacy schemas. However, the Relax NG schemas are not affected by this issue, and thus there is a discrepancy between the XSD and Relax NG schemas in these unusual cases.
  • Circular Group Definitions: all schemas that redefine the Datalog XSD schema use circular group definitions, leading to an inability to validate against these schemas using some validators, such as Xerces. Similar to the issue above, it is not possible to fix this issue within the modularization approach of the hand-written XSD schemas. However, XSV and Saxon validators are lax in enforcing Constraints on Model Group Schema Components (§3.8.6) of the XSD specification, Part 1, and are able to work around it. Relax NG schemas and the XSD schemas automatically generated from the Relax NG schemas are not affected by this issue.

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.

11 References

  1. DTD Specification: http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm
  2. RuleML 0.85: http://ruleml.org/0.85
  3. XMLSpy http://www.altova.com/xml-editor/
  4. oXygen http://oxygenxml.com


Site Contact: Tara Athan