Schema Specification of RuleML 0.86

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.

As an XSD-stable release of the transitional RuleML 0.85, version 0.86 adds the same features:

A full discussion of (most of) these additions can be found in the Object-Oriented RuleML section. Further changes include n-tuple (tup) being renamed (com)plex to accomodate unordered complex structures, and role-list (roli) now being simulated by complex structures containing nothing but metaroles (_slot). A presentation summarizing this work (as part of 0.85) entitled Object-Oriented RuleML: Re-Modularized and XML Schematized via Content Models (PDF) is also available.

The only change since 0.85 in this release concerns the (now stable) XSD implementation. To avoid certain limitations in XML Schema, the RuleML sublanguages have been remodularized since version 0.85.

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.

First, two long-planned changes have now been officially incorporated: and/or nesting in the body and two kinds of negation. Also, non-positional user-level roles have been incorporated without duplicating the number of existing sublanguages. Finally, handles for term typing and URI-grounded clauses have been established as a couple of preliminary XML attributes.

Also, a few tags have been renamed: '_r' became '_slot', 'n' has been expanded to 'name', and 'w' is now 'weight'. This deviation from the earlier OO RuleML is the result of an attempt to increase readability.

Some of the OO DTD changes (namely, user-level roles via the metarole '_slot' and role weights via the attribute 'weight') are detailed in the OO RuleML section, but specific implementations are often more complex in order to comply with the XML 1.0 specification which prohibits non-determinististic (i.e. ambiguous) content models.

user level roles:

]]>

URI-grounding:

]]>

term typing:

]]>

weighted extension:

]]>

These modifications can be seen in the 0.85 DTDs, as well as in the XML Schema representation. Validation instructions are included in each directory, as well as in the appendix.

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 now a new model has been devised. 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:

%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 is handled much more elegantly. Every element's content model is explicitly defined by a parameter entity. The metarole '_slot', for example, is declared as follows:

]]>

Since parameter entities can overwrite one another (even across files), this content model is 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:

]]>

(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,

]]>

becomes

]]>

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

%include;]]>

becomes

]]>

A stable XML Schema representation of RuleML version 0.86 has been created with a further improved modularization and implementation approach that is consistent with the (version 0.85) DTDs.

To ensure validation stability, the 0.86 XSDs have been tested (using corresponding instance documents/examples) with various 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.86 XSDs. The "schema" view is preferred for validating RuleML schemas; they validate perfectly with the slight modification of commenting out self-references as follows:

]]>

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

Appended below is the XML Schema (version 0.86) 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.86 XSDs, specified in a modular fashion, are available here: http://www.ruleml.org/0.86/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.86/exa.