-->
R u l e M L

<--


RuleML DTDs

Harold Boley, Benjamin Grosof, Said Tabet

Version History, 2001-01-25: Version 0.7

Latest version: www.ruleml.org/spec

All DTDs: DTD Directory

Some Examples: Examples Directory




This is a preliminary DTD draft for RuleML. Each DTD in the evolving hierarchy corresponds to a specific RuleML sublanguage. The DTDs use a modularization approach similar to the one in XHTML in order to offer appropriate flexibility and accomodate different implementations and approaches. We will write a technical report on this system of RuleML DTDs (see also KR Principles and DTD Modularization).

Contents

Overview

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 DTDs presented here only covers state-preserving rules (declarative, deductive-rewriting rules), not state-changing rules (active, trigger rules); special tags for facts are also omitted.

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 from (equational) Horn logic. We also work upwards from a URL/URI language corresponding to simple objects. The join of both of these branches then permits inferences over RDF-like 'resources' and can be re-specialized to RDF triples.

Regarding the concrete markup syntax, we have been experimenting with several DTDs prior to the current, still preliminary, version. The rationale for our current tags is as follows.

Explanations

Appended below is a preliminary DTD, designated version 0.7, for the Datalog subset of RuleML (Appendix 1). Also appended below is a simple example rulebase that conforms to that DTD, and instructions for how to validate the example against the DTD.

There now also is a family of DTD's, specified in a modular fashion (using parameter ENTITY declarations), also designated vers. 0.7, at this URL: http://www.ruleml.org/0.7/dtd/ . Note that this family of DTD's is, overall, more raw/immature than just the Datalog member of that family. Note that the Datalog DTD on the website is a bit more complex, but equivalent, to the one appended below. The one below is called "stand-alone", because it has stripped out most of the ENTITY declarations that are in the website (non-"stand-alone") version.

To see the DTD's on the website: After you clicked on the *.dtd files, you may have to select View | Page Source. Thus, we provide additional *.dtd.txt links. Downloading should work anyway.

You can try things out "stand-alone", as explained in Appendix 3, using the own.ruleml example of Appendix 2 (Warnings here concern only stylistic matters).

You may also use the non-"stand-alone" modules to study XML's "INCLUDE"/"IGNORE" overriding method for DTDs that are read in via "ENTITY % ... SYSTEM *.dtd" declarations. But you can get the gist of the definitions also when treating most of these house-keeping directives as no-ops.

After some discussions, we found a set of tag names that sound reasonable to us. Feedback is very welcome.

Facts are currently simply rules ("if" elements) that have empty (i.e. 'true') 'and' prems. We'll need an explicit, abbreviating tag. Similarly, perhaps, for trigger rules and integrity constraints.

User comments on all levels are already taken care of by XML; look at the sample datalog document own.ruleml.

More sample files -- each referring to the most specific DTD still validating them -- can be found at: http://www.ruleml.org/0.7/exa/ . See the instructions above (about View | Page Source, etc.) for viewing the content etc.

Appendix 1: DTD for Datalog subset of RuleML

<!-- An XML DTD for a Datalog RuleML Sublanguage: Stand-Alone Version -->
<!-- Last Modification: 2001-01-25 -->



<!-- ENTITY Declarations -->


<!-- a conclusion and premise will be usable within 'if' implications -->
<!-- conc element uses an atomic formula -->
<!-- prem element uses an atomic formula or an 'and' -->

<!ENTITY % conc "atom">
<!ENTITY % prem "(atom | and)">



<!-- ELEMENT and ATTLIST Declarations -->


<!-- 'rulebase' root element uses 'if' implications as top-level rules -->

<!-- label attribute allows naming of an entire individual rulebase; -->
<!-- e.g., this can help enable forward inferencing of selected rulebase(s)  -->

<!-- direction attribute indicates the intended direction of rule inferencing;  -->
<!-- it is a preliminary design choice and has a 'neutral' default value -->

<!ELEMENT rulebase (if*)>
<!ATTLIST rulebase label CDATA #IMPLIED>
<!ATTLIST rulebase direction (forward | backward | bidirectional) "bidirectional">
 
 
<!-- 'if' implications are usable as top-level rules -->
<!-- 'if' element uses a conclusion followed by a premise -->
<!-- "<if>conc prem</if>" stands for "conc if prem", i.e., "conc is true if prem is true" -->
 
<!-- label attribute is a handle for the rule: for various uses, including editing -->
 
<!ELEMENT if (%conc;, %prem;)>
<!ATTLIST if label CDATA #IMPLIED>
 
 
<!-- an 'and' is usable within premises -->
<!-- 'and' uses zero or more atomic formulas -->
<!-- "<and>atom</and>" is equivalent to "atom"-->
<!-- "<and></and>" is equivalent to "true"-->
 
<!ELEMENT and (atom*)>
 
 
<!-- atomic formulas are usable within conc's, prem's, and 'and's -->
<!-- atom element uses rel(ation) symbol followed by a sequence of -->
<!-- zero or more arguments, which may be ind(ividual)s or var(iable)s -->
 
<!ELEMENT atom (rel, (ind | var)*)>
 
 
<!-- there is one kind of fixed argument -->
 
<!-- individual constant, as in predicate logic -->
 
<!ELEMENT ind  (#PCDATA)>
 
 
<!-- there is one kind of variable argument -->
 
<!-- logical variable, as in logic programming -->
 
<!ELEMENT var  (#PCDATA)>
 
 
<!-- there are only fixed (first-order) relations -->
 
<!-- relation or predicate symbol -->
 
<!ELEMENT rel  (#PCDATA)>

Appendix 2: Example RuleML document: a rulebase with filename own.ruleml

<?xml version="1.0" standalone="no"?>
<!DOCTYPE rulebase SYSTEM "http://www.ruleml.org/0.7/dtd/ruleml-datalog-standalone.dtd">



<rulebase>


<!-- This example rulebase contains four rules.  The third and
fourth rules are actually facts.

In English:
The first rule says that a person owns an object if that person buys
the object from a merchant and the person keeps the object. -->


<if>
  <atom>
    <rel>own</rel>
    <var>person</var>
    <var>object</var>
  </atom>
  <!-- explicit 'and' -->
  <and>
    <atom>
      <rel>buy</rel>
      <var>person</var>
      <var>merchant</var>
      <var>object</var>
    </atom>
    <atom>
      <rel>keep</rel>
      <var>person</var>
      <var>object</var>
    </atom>
  </and>
</if>



<!--
In English:
The next rule says that a person buys an object from a merchant
if the merchant sells the object to the person. -->

<if>
  <atom>
    <rel>buy</rel>
    <var>person</var>
    <var>merchant</var>
    <var>object</var>
  </atom>
  <atom>
    <rel>sell</rel>
    <var>merchant</var>
    <var>person</var>
    <var>object</var>
  </atom>
</if>
 
 
<!-- The next rule is a fact that says, in English, that
John sells XMLBible to Mary. -->
 
<if>
  <atom>
    <rel>sell</rel>
    <ind>John</ind>
    <ind>Mary</ind>
    <ind>XMLBible</ind>
  </atom>
  <!-- empty 'and' -->
  <and/>
</if>
 
<!-- The last rule is a fact that says, in English, 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 -->
 
<if>
  <atom>
    <rel>keep</rel>
    <ind>Mary</ind>
    <ind>XMLBible</ind>
  </atom>
  <and/>
</if>
 
 
</rulebase>

Appendix 3: Instructions/Trace on Validating the example against the DTD

Validating a RuleML 0.7 Sample Document: own.ruleml



> Go to
http://www.stg.brown.edu/service/xmlvalid/

> Paste in at

URI:
http://www.ruleml.org/0.7/exa/own.ruleml


> Hit the 'Validate' button
> You should get:


Validation Results for http://www.ruleml.org/0.7/exa/own.ruleml


Warnings:

line 31, http://www.ruleml.org/0.7/dtd/ruleml-datalog-standalone.dtd: 
       warning (652): element has more than one attlist declaration: rulebase 
line 73, http://www.ruleml.org/0.7/exa/own.ruleml: 
       warning (1106): empty-tag syntax used for element not declared with EMPTY content model: and 
line 92, http://www.ruleml.org/0.7/exa/own.ruleml: 
       warning (1106): empty-tag syntax used for element not declared with EMPTY content model: and 


Document validates OK.

Site Contact: Harold Boley. Page Version: 2001-02-14


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