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.
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:
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.)
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)|
|Old (Examples)||New (Examples)|
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,
where the role tags ('role', 'name' and 'filler') may be omitted, leaving just the type tags:
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):
Expanded (from own_expanded.ruleml):
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.
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.
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">
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;>
<xs:complexType name="slot.type" mixed="true">
<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">
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.
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).
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 ref="Rel.attlist"/> -->
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
Execution time: 1132 milliseconds
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 (firstname.lastname@example.org).
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.
<?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>
<?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>
Validating a RuleML 0.87 Sample Document: own.ruleml ==================================================== 1. Direct your browser tohttp://www.w3.org/2001/03/webdata/xsv
(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):
Schema validating with XSV 2.7-1 of 2004/04/01 13:40:50
Schema resources involved
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/datalog.xsd (source: schemaLoc) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/toplevel_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/desc_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/clause_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/boole_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/atom_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/role_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
Attempt to load a schema document from http://www.ruleml.org/0.87/xsd/modules/term_module.xsd (source: include) for http://www.ruleml.org/0.87/xsd, succeeded
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)