RuleML: Data Model, Language Hierarchy, and Transformations

1
RuleMLData Model, Language Hierarchy,and
Transformations

• Harold Boley, DFKI GmbH,
• Visiting Researcher at NRC
• IIT e-Business, Fredericton

2001 Seminar Series Talk at the Faculty of
Computer Science, University of New
Brunswick, Fredericton, December 3rd, 2001
2
Web-Based Business RulesMerchant-Customer
Exchange Scenario (I)
Introduction
3
Web-Based Business RulesMerchant-Customer
Exchange Scenario (II)
. . .
translate to standard format (e.g., RuleML)
publish rulebase1
publish rulebasem
Introduction
compare, instantiate, and run rulebases
4
Web-Based Business RulesMerchant-Customer
Exchange Scenario (III)
order from Merchanti
Introduction
select best deal (e.g., discount)
5
Web-Based Business RulesFormalize Natural
Language in Horn Logic
Introduction
6
Semantics andPragmatics (Implementation)

• Original Web Distributed development, usage and
  maintenance of HTML-based informal documents
• Semantic Web Employ same infrastructure for
  formal specifications or declarative programs

Introduction
Which Logics/Languages?

• Uniform semantic/pragmatic foundation potential
• Description Logic RDF Schema, DAMLOIL for
  taxonomies
• Horn Logic Prolog, RuleML for axioms

7
Syntax

• Syntactic underpinnings, however, will most
  likely come from Extensible Markup Language (XML)
• Fortunately, translators between Prolog and XML
  syntaxes can be defined
• Can also form basis for semantic/pragmatic
  technology transfers between Prolog and XML
• Current talk will exemplify this using XML syntax
  ofRule Markup Language (RuleML), Version 0.8

Introduction
8
XML-Prolog Initiative RuleML

• The Rule Markup Initiative works towards W3C
  submission representing its various participants
  from industry and academia
• First goal has thus been to provide modular
  system of RuleML sublanguages based on XML and
  RDF (Resource Description Framework)

Introduction

• This led to development of novel
  XML-RDF-integrating Web data model
• On its basis, RuleML initially defined with
  hierarchy of DTDs, gradually redefined with XML
  Schema
• To facilitate rule exchange, XSLT-based
  translators between RuleML and other rule
  languages have been specified

9
Main Structure of the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

Introduction
10
Next in the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

11
XML Elements as Ground Structures The Idea
XML documents consist of (nested) elements

• Each element is a sequence lttaggt. . .lt/taggt,i.e.
  some ordered content ''. . . '' enclosed
  bytag-'colored' start- and end-brackets
• This content may consist of text or again of
  elements

XML as Prolog
Prolog terms can represent XML elements as
variablefree or ground structures tag(. . .)
12
XML Elements as Ground StructuresA Markup
Problem
Example Mark up power formulas, in a typed
manner, as integer bases raised to integer
exponents

• In XML can use a positional representation,where
  a power formula consists of a base followed by an
  exponent
• The base and exponent can each be marked up as an
  integer

XML as Prolog
13
XML Elements as Ground Structures XML and Prolog
Solutions
Thus, power formula 32 marked up asnested
element
ltpowformgt ltintegergt3lt/integergt
ltintegergt2lt/integergt lt/powformgt
XML as Prolog
14
XML Elements as Ground Structures Underlying
Trees
Graph-theoretically, yield a tree with
left-to-right-ordered arcs and two kinds of nodes
labeled by their types, here powform and integer,
where oval nodes are XML-like (sub)elements or
RDF-like resources while rectangular nodes are
XML-like PCDATA or RDF-like literals, here 3 and
2
XML as Prolog
In general, these simple XML elements and Prolog
terms constitute two equivalent ways of
linearizing left-to-right-ordered, node-labeled
trees (with oval inner nodes and rectangular leaf
nodes)
15
XML Attributes as Ground Structures
Besides elements, XML uses attributes

• A start-tag can be enhanced by n non-positional
  attribute-value pairs of the form aivi, where vi
  must be a string (XML's CDATA)
• In general, every element thus has the formlttag
  a1v1...anvngt. . .lt/taggt

XML as Prolog
However, this can be reduced to the attributeless
form lttaggtv1...vn. . .lt/taggt, where n attribute
values become positionalized as first n
subelements Ground structure ?Treat XML
elements, incl. attributes, as Prolog-like terms
Data model that captures XML attributes
non-positionally, as a special case, will be
developed next
16
Next in the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

17
Unify XML and RDF
XML and RDF have different data models

• XML based on, possibly attributed, left-to-right
  ordered, node-labeled trees, reminiscent of parse
  (syntax) trees
• RDF based on directed, arc-labeled (unordered)
  graphs with two kinds of nodes, resources and
  literals, the latter not allowing outgoing arcs

Data Model
With the advent of the Semantic Web a unified
data model would be advantageous
18
Problem with Positional XML Markup

• Our powform's binary-positional
  convention''First child is base, second child is
  exponent'' for 32 markup seems natural and easy
  to memorize
• But without some kind of 'signature
  declaration'this markup could instead mean 23
  according to a''First child is exponent, second
  child is base'' convention
• Analogous conventions for N-ary operators (N gt2)
  need to disambiguate a combinatorially exploding
  number of possible interpretations
• Without extra information the positions of
  'roles' (powform base and exponent) of children
  cannot in general be determined from some such
  markup

Data Model
19
Solution with Non-Positional RDF Markup
In 'object-centered' modeling and
'feature'/'frame' logics the way out is
representing powers and other operators in a
non-positional manner, making them objects with
explicitly indicated roles for their
arguments In Frame/Horn-logic-integrating
F-Logic, developed for RDF in TRIPLE, our example
could thus be represented as a fact
Data Model
powform base -gt 3 integer exponent -gt 2
integer.
20
Non-Positional RuleML Solution
Paralleling this in RuleML, we complement XML
'type tags' by distinguished, RDF-like 'role
tags' Generalizing XML attributes, roles will
allow values that themselves contain markup In
our example we thus use powform with _base and
_exponent subelements, where the leading ''_''
distinguishes roles
Data Model
ltpowformgt lt_basegtltintegergt3lt/integergtlt/_basegt
lt_exponentgtltintegergt2lt/integergtlt/_exponentgt lt/powf
ormgt
21
Role Commutativity
There are two correctly prefixed powform-child
permutations, which we regard as algebraically
equivalent commutative markups
ltpowformgt lt_basegtltintegergt3lt/integergtlt/_basegt
lt_exponentgtltintegergt2lt/integergtlt/_exponentgt lt/powf
ormgt
Data Model

ltpowformgt lt_exponentgtltintegergt2lt/integergtlt/_expon
entgt lt_basegtltintegergt3lt/integergtlt/_basegt lt/powfor
mgt
22
Graph Identity and Markup Equation
Graph-theoretically, our data model permits trees
with unordered arcs labeled by their roles,
herebase and exponent, and nodes as introduced
earlier
Data Model
23
Order-Labeled Combination
RDF-like role-prefixed and XMLs positional
children can be easily combined, obtaining our
basic RDF-XML integration of Order-Labeled
(OrdLab) Trees Example Combine markup of a
power sequence a1,..., an with the marked up
formula of its base a and highest exponent n
(length) For the sequence 3, 9 combined with the
formula 32
Data Model
ltpowseqformgt ltrationalgt3lt/rationalgt
ltrationalgt9lt/rationalgt lt_basegtltintegergt3lt/integer
gtlt/_basegt lt_exponentgtltintegergt2lt/integergtlt/_expon
entgt lt/powseqformgt
24
OrdLab Tree
Graph-theoretically, positional children become
left-to-right-ordered arcs, here targeting the
rationals 3 and 9, while role children become
labels on un-ordered arcs, here targeting the
integers 3 and 2 (different arrows emphasize
ordered vs. labeled arcs)
Data Model
25
Next in the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

26
Prolog Structures in RuleML
While we earlier reduced XML elements to Prolog
ground structures, we now generically encode
Prologs Herbrand terms as XML elements, using
the RuleML data model
Representation of Herbrand terms (individual
constants, logic variables, and structures) in
RuleML XML requires, in essence, use ofind, var,
and cterm elements, where the occurrence of a
structure or complex term distinguishes Prolog
from Datalog
Terms in RuleML
27
A cterm Example Markup
Example Prolog ground structure undersea-connect
ion(britain,france) in RuleML becomes cterm
element withrole (unordered) subelement _opc for
the functor/constructor of type ctor and two
sequential (ordered) subelements for its argument
terms, here two individual constants of type ind
Terms in RuleML
ltctermgt lt_opcgtltctorgtundersea-connectionlt/ctorgtlt/
_opcgt ltindgtbritainlt/indgt ltindgtfrancelt/indgt lt/c
termgt
28
Unification of cterm Example Trees
This RuleML cterm markup as an OrdLab tree (left)
Terms in RuleML
29
Next in the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

30
Relation Applications in RuleML
A predicate or relation symbol will in RuleML be
a rel element. The application of an
_opr-role-embedded relation symbol to a sequence
of terms is marked by an atom element in
RuleML Example travel applicationtravel(john,ch
annel-tunnel)to two individual constants will
thus be
Clauses in RuleML
ltatomgt lt_oprgtltrelgttravellt/relgtlt/_oprgt
ltindgtjohnlt/indgt ltindgtchannel-tunnellt/indgt lt/atom
gt
31
Prolog Facts in RuleML
Horn fact in RuleML is asserted as a fact element
that possesses exactly one subelement -- the
_head-role-embedded atom element Example travel
fact (containing travel application)travel(john,c
hannel-tunnel). becomes
Clauses in RuleML
ltfactgt lt_headgt ltatomgt
lt_oprgtltrelgttravellt/relgtlt/_oprgt
ltindgtjohnlt/indgt ltindgtchannel-tunnellt/indgt
lt/atomgt lt/_headgt lt/factgt
Tree structure?
32
Prolog Rules in RuleML Source
Horn rule in RuleML is asserted as an imp
element that has two subelements -- a _head-role
atom element augmented (either to its right or
left) by a _body-role atom or and
element Example travel rule (Datalog) travel(So
meone,channel-tunnel) - carry(eurostar,Someo
ne). rewritten in RuleML thus
Clauses in RuleML
33
Prolog Rules in RuleML Markup
ltimpgt lt_headgt ltatomgt
lt_oprgtltrelgttravellt/relgtlt/_oprgt
ltvargtsomeonelt/vargt ltindgtchannel-tunnellt/indgt
lt/atomgt lt/_headgt lt_bodygt ltatomgt
lt_oprgtltrelgtcarrylt/relgtlt/_oprgt
ltindgteurostarlt/indgt ltvargtsomeonelt/vargt
lt/atomgt lt/_bodygt lt/impgt
Clauses in RuleML
34
Prolog Rules in RuleML Tree
Graph-theoretically, RuleML clauses are again
OrdLab trees, as illustrated for this rule
Clauses in RuleML
35
Next in the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

36
Prolog in RuleML DTD/Schema Hierarchy
Focus on 12 sublanguages of derivation rule
modules All except the 'UR' (URL/URI) group
correspond to well-known rule systems, with
formal semantics
DTD and Schema
37
Modular Sublanguage Composition
Each node in above hierarchy, e.g. 'hornlog', is
a DTD/Schema that defines syntax of this
sublanguage Knowledge bases can refer to most
specific DTD/Schema to maximize
interoperability Non-leaf nodes are composed of
the -- possibly modified -- node(s) reachable via
outgoing link(s) below plus possibly some extra
definition parts Example 'hornlog' is composed
of a -- slightly modified -- 'datalog' plus
complex terms 'datalog' itself contains
'bin-datalog', etc.
DTD and Schema
38
From DTD to XML Schema rulebases
DTD line (XML in EBNF-like SGML
subset) lt!ELEMENT rulebase ((imp fact))gt
Schema part (official way to define XML in
XML) ltxsdschema xmlnsxsd"http//...w3.org...X
MLSchema"gt ltxsdelement name"rulebase"gt
ltxsdcomplexTypegt ltxsdchoice minOccurs"0"
maxOccurs"unbounded"gt ltxsdelement
name"imp" type"impType"/gt ltxsdelement
name"fact" type"factType"/gt
lt/xsdchoicegt lt/xsdcomplexTypegt
lt/xsdelementgt . . .
DTD and Schema
39
From DTD to XML Schema implications
DTD line (permuted _head / _body
sequences) lt!ELEMENT imp ((_head, _body)
(_body, _head))gt
Schema part (unordered xsdall set) . . .
ltxsdcomplexType name"impType"gt ltxsdallgt
ltxsdelement name"_head" type"_headType"
minOccurs"1" maxOccurs"1"/gt
ltxsdelement name"_body" type"_bodyType"
minOccurs"1" maxOccurs"1"/gt
lt/xsdallgt lt/xsdcomplexTypegt . . .
DTD and Schema
40
Extending Datalog to Full Prolog
Remaining essential lines of 'datalog'
DTD lt!ELEMENT _head (atom)gt lt!ELEMENT _body
(atom and)gt lt!ELEMENT and (atom)gt lt!ELEMENT
atom ((_opr, (ind var)) ((ind var),
_opr))gt
DTD and Schema
We are currently investigating for XML Schema
version the issue of composition mechanisms
better than conditional DTD parts, involving
xsdredefine
41
Next in the Talk

• XML elements and attributes shown to correspond
  to Prolog ground structures
• RuleML data model presented and illustrated via
  Order-Labeled trees
• Permits to generically represent Herbrand terms
  as RuleML XML elements
• Horn clauses similarly represented as XML
  elements
• Prolog defined within the DTD/Schema Hierarchy of
  RuleML sublanguages
• XSLT translators exemplified by bidirectional
  RuleML-RFML transformer and HTML renderer

42
HTML Rendering of Business Rules
Before our XML-to-XML roundtrip RFML version,
via XML-to-HTML stylesheet rfmlsp, will lead to
font-and-color-coded HTML Prolog version,
rendered in a browser (first line is sample rule)
XSLT translators
43
XSL Transformations from and to RuleML
Exemplary pair of 'inverse' translators
('stylesheets') exporting/importing markup
between RuleML and RFML (Relational-Functional
Markup Language), where only the logic part is
needed for Prolog
Export via ruleml2rfml.xsl Stylesheet translates
Hornlog RuleML rulebase to corresponding RFML
program Import via rfml2ruleml.xsl Stylesheet
translates a Hornlog RFML program to
corresponding RuleML rulebase
XSLT translators
44
Bi-Transforming Discount Sample Rule
''The discount for a customer buying a product is
5.0 percent if the customer is premium and the
product is regular.''
ltrulebasegt ltimpgt lt_headgt ltatomgt
lt_oprgtltrelgtdiscountlt/relgtlt/_oprgt
ltvargtcustomerlt/vargt ltvargtproductlt/vargt
ltindgt5.0 percentlt/indgt lt/atomgt
lt/_headgt lt_bodygt ltandgt ltatomgt
lt_oprgtltrelgtpremiumlt/relgtlt/_oprgt
ltvargtcustomerlt/vargt lt/atomgt
ltatomgt lt_oprgtltrelgtregularlt/relgtlt/_oprgt
ltvargtproductlt/vargt lt/atomgt
lt/andgt lt/_bodygt lt/impgt lt/rulebasegt
ltrfmlgt lthngt ltpattopgt
ltcongtdiscountlt/congt ltvargtcustomerlt/vargt
ltvargtproductlt/vargt ltcongt5.0
percentlt/congt lt/pattopgt ltcallopgt
ltcongtpremiumlt/congt ltvargtcustomerlt/vargt
lt/callopgt ltcallopgt ltcongtregularlt/congt
ltvargtproductlt/vargt lt/callopgt
lt/hngt lt/rfmlgt
ruleml2rfml.xsl
XSLT translators
rfml2ruleml.xsl
45
Export from RuleML Tree Rewriting (I)
XSLT translators
What does this XML processing look like in XML?
46
Export from RuleML Implementation (I)
First XSLT rule ('template') matches document
root ''/'' followed by rulebase element it
'recursively' maps ('applies') all matching
templates to all rulebase subelements and
generates rfml element from result
lt!-- process rulebase and position fact/imp
transformers --gt ltxsltemplate match"/rulebase"gt
ltrfmlgt ltxslapply-templates/gt
lt/rfmlgt lt/xsltemplategt
XSLT translators
47
Export from RuleML Tree Rewriting (II)
XSLT translators
hn
Subtree
48
Export from RuleML Implementation (II)
Second template matches fact element, does
apply-templates over its _head in mode pattop
(for RFML's operator patterns), and generates hn
element from result
lt!-- process fact, transforming it to hn
clause without premises --gt ltxsltemplate
match"fact"gt lthngt ltxslapply-templates
select"_head" mode"pattop"/gt
lt/hngt lt/xsltemplategt
XSLT translators
49
Export from RuleML Tree Rewriting (III)
atom
atom
. . .
. . .
_opr
_opr
Argterm
Argterm
Argterm
Argterm
rel
rel
PCDATA
PCDATA
XSLT translators
pattop
. . .
con
PCDATA
Implementation details ruleml2rfml.xsl
50
Import to RuleML Implementation (I)
First template is exact 'inverse' of the first
ruleml2rfml template
lt!-- process rfml program and position hn
transformer --gt ltxsltemplate match"/rfml"gt
ltrulebasegt ltxslapply-templates/gt
lt/rulebasegt lt/xsltemplategt
XSLT translators
51
Import to RuleML Implementation (II)
Second template matches hn element, and, for fact
case, expects one child fact element with _head
role is generated from result of apply-templates
over the pattop
lt!-- process hn clause, that is a fact, ...
--gt ltxsltemplate match"hn"gt ltxslchoosegt
ltxslwhen test"count(child)1"gt ltfactgt
lt_headgt ltxslapply-templates
select"pattop"/gt lt/_headgt lt/factgt
lt/xslwhengt . . . lt/xslchoosegt lt/xslt
emplategt
XSLT translators
52
Web Technology for Prolog

• Prepared semantic-pragmatic XML-Prolog transfers
  using XML syntax http//www.dfki.de/ruleml
• XML-RDF-integrating data model used as basis for
  DTD/Schema definitions of Prolog on the Web
• Started semantic-pragmatic transfers in direction
  XML-to-Prolog by specifying (semantics-preserving)
  XSLT-based translators RuleML ? RFML
• It is now possible to build and exchangeProlog
  knowledge bases over the Web

Conclusions
53
Web Technology for General Use DTDs and XSLT
are Still Most Practical,XML Schema and XQuery
are Promising

• Demonstrated practical use of W3C technologies
  such as DTDs and XML Schema as well as XSLT
• On the other hand hinted at a few problems with
  current version of XML Schema, hoping that more
  expressive version will be available in future
• Functional and logic programmers may also have
  wondered whether XSLT-based translators could be
  specified more concisely in future version of
  XSLT
• Perhaps XQuery can act as incentive towards
  formal semantics of XML queries and
  transformations

Conclusions
54
Prolog Technology for the Web

• Corresponding transfers in Prolog-to-XML
  direction have already started with Mandarax,
  j-DREW, and other RuleML engines based on Prolog
  technology
• It may also be useful to implement
  (orthogonalized versions of) XML Schema, XSLT,
  etc. in (RuleML and) Prolog to explore limits of
  expressiveness that can be realized formally and
  efficiently
• Side-effect of this work could be translators
  between XML syntax and more concise Prolog syntax
  for W3C languages such as XML Schema and XSLT

Conclusions