Schema Specification of RuleML 0.87

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)
type	Type
_role	role
Old (Examples)	New (Examples)
imp	Imp
_head	head
...	...

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

... blue ... ]]>

becomes

... color blue ... ]]>

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

... colorblue ... ]]>

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

... keep Mary XMLBible ... ]]>

Expanded (from own_expanded.ruleml):

... keep Mary XMLBible ... ]]>

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:

%datalog_include;]]>

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

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

]]>

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:

]]>

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

]]>

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

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:

]]>

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

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

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

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.

Source: datalog.xsd

Source: own.ruleml