A RuleML - DMN Translator
Adrian Paschke and Simon Könnecke
Freie Universität Berlin, Germany
paschke AT inf.fu-berlin.de, simon.koennecke AT fu-berlin.de
Abstract. Rule markup languages are the vehicle for using rules on the
Web and other distributed systems. They allow deploying, executing, pub-
lishing and communicating rules in a network. The Object Management
Group (OMG) standardized the Decision Modelling and Notation (DMN).
Decision tables describe the business logic of a decision making process.
We form a bridge by providing a translation framework to translate DMN
decision tables to RuleML, a standardized rule interchange language.
1 Introduction
RuleML 1 is an overarching family of Web rule languages [4] which enable stan-
dardized machine-interpretation, automated processing and translation between
various other rule standards [11], e.g. between RuleML and W3C RIF [2] and
rule execution languages [5], as well as theorem provers [16]. RuleML 1.02 spans
complementary rule families [1] such as Deliberation RuleML (e.g. used for
decision rules), Reaction RuleML (e.g. used for reaction rules and production
rules[12,14,9]) and Consumer RuleML (e.g. used for for embedding RuleML into
other host languages).
With its semantic style mechanism2 RuleML supports references to explicitly
(pre-)defined Semantic Profiles [9] specifying the intended semantics and possible
translations of RuleML into other representations.
This paper demonstrates a translator for the OMG Decision Model and
Notation 1.1 (OMG DMN3 into RuleML 1.02. DMN is a standard approach
for describing and modeling repeatable decisions within organizations. Our
contribution enables representation and semantic interpretation of DMN in
RuleML, hence enabling further translations of RuleML DMN representations
into other representation and execution languages using the various translators
available for RuleML. We will demonstrate this by an implemented translator
service4 from DMN to RuleML. Furthermore, the translator service can translate
from RuleML into the executable Prova5 rule language. RuleML translation
1
http://ruleml.org
2
examples can be found in http://de.slideshare.net/swadpasc/paschke-rule-
ml2014keynote
3
http://www.omg.org/spec/DMN/
4
see http://wiki.ruleml.org/index.php/RuleML_Implementations
5
http://www.prova.ws
2 Adrian Paschke and Simon Könnecke
enables, e.g. to use the growing number of DMN modelling tools6 as user interfaces
/ editors for the various RuleML-supported rule engines which can act as platform-
specific execution environments for the DMN models.
The further paper is structured as follows: Section 2 describes the background
for using RuleML’s Semantic Profiles for OMG DMN. DMN decision tables
are introduced in section 3. Section 4 summarizes the DMN profile as basis for
the DMN-RuleML translator. Section 5 describes the implementation of the
translator service. Section 6 demonstrates the translator and finally section 7
concludes this demo paper.
2 Background
Since Reaction RuleML 1.0 so called Semantic Profiles have been introduced
in RuleML and further adopted in the overall RuleML 1.02 family. They are
used to define the intended semantics for knowledge interpretation (typically a
model-theoretic semantics), reasoning (typically entailment regimes and proof-
theoretic semantics), or for execution (e.g., operational semantics such as selection
and consumption policies and windowing techniques in complex event event
processing). Profiles can further detail the syntax and semantics of a RuleML rule
base and provide necessary information about the intended semantics for modular
RuleML knowledge representations [13] as required for interchange, translation,
inference, and verification and validation with test cases [10,7].
Various pre-defined semantic profiles 7 exist, which can be referenced as
semantic styles8 in RuleML, e.g. logical rule semantics [8] such as Herbrand
semantics for first order logic and horn logic as well as Tarski semantics for
horn logic, as used e.g., in PSOA RuleML9 . This also includes semantic profiles
supporting the semantically safe translation of other rule standards into RuleML,
making RuleML an overarching “lingua franca” to interchange rules and integrate
with other markup languages. For instance, the First-Order-Deontic-Alethic
Semantic Profile (FODAL semantic profile)10 defines a two-layered modal Kripke
semantics for deontic and alethic modal first order formulas which can be used
to represent, e.g. business rules as in the OMG standard Semantics of Business
Vocabulary and Rules (OMG SBVR)11 , and to map from the SBVR FODAL
representations into Modal Reaction RuleML via the profile’s translation function.
This profile has been used, e.g., as basis for the mapping from OMG SBVR into
OASIS LegalRuleML 12 with a Reaction RuleML translator [15].
6
http://openjvm.jvmhost.net/DMNtools/
7
see e.g. http://wiki.ruleml.org/index.php/Predefined_Semantic_Styles_of_RuleML_
1.02
8
http://wiki.ruleml.org/index.php/Semantic_Styles_of_RuleML_1.02 (@style at-
tribute)
9
http://ruleml.org/1.02/profiles/HornPSOA-Tarski [3]
10
http://ruleml.org/1.02/profiles/fodal
11
http://www.omg.org/spec/SBVR/
12
https://www.oasis-open.org/committees/legalruleml/
A RuleML - DMN Translator 3
The translator described in this paper is based on a semantic profile for
representing and translating OMG DMN (1.1) in RuleML. DMN 1.1 defines the
simple friendly enough expression language (S-FEEL) for the purpose of giving
standard executable semantics to many kinds of expressions in decision model [6,
p. 92].
3 DMN Decision Table
The purpose of DMN is to provide the constructs that are needed to model
decisions [6, p. 21]. Decision logic can be express in DMN with a decision table. A
decision table is a tabular representation with a name, hit policy, allowed values,
default values and a set of related input and output expressions, organized into
rules indicating which output entry applies to a specific set of input entries. The
decision table contains all (and only) the inputs required to determine the output
[6, p. 72]. Refer to figure 1 for a sample decision table.
Fig. 1. Horizontal decision table example [6, p. 73]
A decision table normally contains several rules. As a default, rules do not
overlap. If rules overlap, meaning that more than one rule may match a given set
of input values, the hit policy determines how the output entries will be chosen
[6, p. 91]. To list possible hit policies: unique, rule order or collection. Unique is
the default hit policy of decision tables and means there are no overlapping rules.
Rule order provide all valid output entries ordered by the defined rule sequence.
Collection returns randomly all valid output entries. Collection can also come
with an aggregation function like min, max, sum or count.
4 Adrian Paschke and Simon Könnecke
4 Semantic Profile for DMN Representation in RuleML
In this section we describe the basics of the RuleML semantic profile13 used for
the RuleML-DMN translator in the demo. As representation language for DMN
we apply a (multi-sorted) logic programming syntax with a horn logic Herbrand
semantics, extended by built-in comparators, arithmetical operations, and (data)
types. [8]
4.1 Syntax and Semantics
The core alphabet Σ is defined as follows:
1. A signature S = (P , F , arity, c).
– P is a finite sequence of predicates symbols (P1 , · · · , Pn ).
– F is a finite sequence of functions symbols (F1 , · · · , Fm ).
– c is a finite sequence of constant symbols.
2. A set of variables V .
3. Connectives / operators: ¬, ∧, ∨, ⇐, :=.
The serialization of the core alphabet Σ in RuleML is stated in table 1.
Table 1. Serialization of Core Logic Programming Syntax in RuleML
Symboles of Σ RuleML Serialization
Variables ti ti
Constant tj tj or
tj
Fi (t1 , · · · , tn ) Fi t1 · · · tn
¬Pi Pi
Pi ∧ Pj Pi Pj
Pi ∨ Pj Pi Pj
Pi ⇐ Pj Pj Pi
ti := tj ti tj
Pi (t1 , · · · , tn ) Pi t1 · · · tn
Note, the equal operation assigns values from tj to ti .
13
Note: a semantic profile is interpreted as a substructure of an expanded profile
semantic multi-structure and hence can be further extended by other semantic profiles,
i.e. additional expressiveness can be added to the core syntax by combinations with
further profiles. For instance, a profile extension with multi-sorted structures, where
the members of the universe of discourse is structured into multiple sort domains.
To support such profile extensions, we deviate in our signature definitions from the
standard definitions in terms of just sets and define them in terms of sequences,
where the members can occur multiple-times, but are assigned with different sorts by
a sort function.
A RuleML - DMN Translator 5
We further extend the alphabet Σ with built-in comparators (=, ! =, <, ≤, >
, ≥), arithmetical operations (+, −, ·, /,mod,ˆ) and (data) types.
For the interpretation of this syntax the existing semantic profiles for horn
logics with Herbrand semantics14 can be used as basis.
Further we extend the basic syntax of Σ to represent DMN S-FEEL expressions
and interpret them as a logic program. In the following we will exemplify this
representation and also show example serializations in RuleML syntax.
Data Types and Built-ins Built-in Operators and Comparators will be serial-
ized as predicates. We use Semantic Web Rule Language built-ins (SWRLB)15
and XML Schema data types16 to extend the alphabet Σ.
Data types are referenced in RuleML in elements using XML Schema
data types. More general types defined in external type systems can be referenced
by the @type attribute and interpreted, e.g. by semantic profiles for sorted logics.
Table 2 gives examples for the serialization of data types into RuleML. The
function ftype (ci ) 7→ d determined the type, where d is a possible data type.
Therefore, the alphabet Σ can differ between types of constant symbols.
Table 2. Translation of S-FEEL data types to RuleML
Data RuleML serialization
Types
boolean ...
number ...
string ...
date not yet supported
Operations The SWRLB provide arithmetical and comparison operation we
simple extend the alphabet Σ by the operation. The predicate’s name is the
name of the operation, the first parameter obtains the result of the operation,
the last two the parameters donate the values of the operands e. g. the listing
1.1 describe a serialization of an arithmetical operation Result := 2 + 3. The
comparison operation will be serialized the same way without result variable.
Listing 1.1. Sample serialization of swrlb:add.
add
R e s u l t
2 . 0
3 . 0
SWRLB extend the Σ with the arithmetical operation +, −, ·, /,mod,ˆ.
14
http://ruleml.org/1.02/profiles/Horn-Herbrand
15
https://www.w3.org/Submission/2004/SUBM-SWRL-20040521/
16
https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html
6 Adrian Paschke and Simon Könnecke
4.2 DMN Representation in Horn Logic
Qualified Name Qualified Names are variables in S-FEEL expression. The
translation function τqn (Exp, Y, τx ) will parse all qualified names qi of Exp
and add a predicate context with qi as individual and a unique variable Zi .
Exp∗ is Exp where all qi will be replaced by Zi . After parsing and replacing
the function τx (Exp∗ , Y ) will be applied, where τx is one of the other defined
translation functions. The qualified name translation function can be described
as τqn (Exp, Y, τx ) = context(q0 , Z0 ) ∧ .. ∧ context(qn , Zn ) ∧ τx (Exp∗ , Y ), where
n is the number of qualified names in the expression Exp.
Interval The translation function of interval expressions to Σ can be defined as
follows:
Exp∗ = [a..b] : a ≥ X ∧ X ≤ b
τinterval (Exp∗ , X) =
Exp∗ = (a..b) : a > X ∧ X < b
Note, for the reason of simplification we only show two of the nine valid
S-FEEL interval mappings. a and b are placeholders for variables or constants
symbols.
Literal expression The translation function for S-FEEL literal expression l
can be defined as τliteral (Exp∗ , X) = X := Exp∗ .
Unary Test S-FEEL unary test expression means the first operand is implicitly
given. The operation and second operand are explicitly defined in unary test
expression for example “< 12”. When an S-FEEL unary test is translated to Σ
there can be determined the following function:
not(Exp∗ ) : ¬(τunary (Exp∗ ))
Exp is a interval : τinterval (Exp∗ , X)
∗
τunary (Exp∗ , X) =
Exp∗ = − : true
: fconcat (X, Exp∗ )
otherwise
The variable X is the implicit operand. The function fconcat (X, Exp∗ ) con-
catenates X and Exp∗ .
Decision Table, Output Expression and Rule The attributes of a decision
table, output expression or rule will be mapped as a fact to the knowledge base.
The first term of fact will be the decision tabel id. The mapping of an decision table
appears as: decisionT able(“tableId”, “tableLabel”, “hitP olicy”, “aggregation”).
Input Expression The input expression has a literal expression l and will
be translated as follows: inputExpression(“tableId”, “ColN o”, Result) ⇐ τqn (l,
Result, τliteral ), where ColN o is the column position at the decision table.
A RuleML - DMN Translator 7
Input Entry The input entry S-FEEL expression can describe multiply unary
tests separated by commas. For each unary test ti will be translated as inputEntry(
“tableId”, “ColN o”, “RuleN o”) ⇐ inputExpression(“tableId”, “ColN o”, V alue)
∧ τqn (ti , V alue, τunary ), where ColN o column position of the related input ex-
pression and RuleN o is the corresponding rule position.
Output Entry Output entry defines the result value via a literal expression l.
The translation can be describe as outputEntry(“tableId”, “label”, · · · , V alue) ⇐
∧ni=0 inputEntry(“tableId”, i, “RuleN o”) ∧ τqn (l, V alue, τliteral ), where n is the
number of input entries of the related rule, dots at outputEntry predicate are
placeholder for the attributes of the output entry and RoleN o the number of the
rule order.
5 RuleML DMN Translator Service
The translation service is split in two Java programs, one called rule translation
service (RTS) and other called rule translation web service (RTWS). RTS runs
by specifying four parameters, input language lin , output language lout , input
data din and output dout . RTS translate always from or to RuleML. The case
where lin or lout not RuleML the service will translate lin to RuleML and than
to lout . Note, the languages l needed to be listed at RTS. RTS provide syntax
mapping between S-FEEL to RuleML, DMN to RuleML and RuleML to Prova.
DMN and RuleML as XML based formatted will by parsed JAXB17 . S-FEEL
will parsed by ANTRL18 . RTWS wrappers RTS to provide an REST API of the
service. RTWS based on Java Spark19 a lightweight web framework to create
microservices.
We explain three ways to translate a DMN file “table.dmn” to a RuleML file
“table.ruleml”. Firstly as command line execution, secondly as Java library call,
thirdly as HTTP call.
Command-Line Interface RTS can be invoked as command on command line.
We will translate the DMN file to RuleML file as follow: java -jar ruletransla-
torservice.jar dmn ruleml table.dmn table.ruleml. The result will printed to file
“table.ruleml”.
Java Library RTS can be used as library in other projects. The input of a trans-
lation can be a File, a InputStream or a String. Here we load the file “table.dmn”,
mark it with input language “DMN”, translate it to “RuleML” and store the result
to “table.ruleml” by calling the function translate of RuleTranslationService.
17
https://jaxb.java.net/
18
http://www.antlr.org/
19
http://sparkjava.com/
8 Adrian Paschke and Simon Könnecke
//...
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
RuleTranslatorService rts = RuleTranslatorServiceFactory .
createTranslatorService () ;
try {
r t s . t r a n s l a t e ( new F i l e ( " t a b l e . dmn" ) , "DMN" , " RuleML " , new
FileOutputStream ( " t a b l e . ruleml " ) ) ;
} c a t c h ( UnknownRulesLanguageException ex ) {
// . . .
} c a t c h ( R u l e T r a n s l a t o r E x c e p t i o n ex ) {
// . . .
}
}
// ...
REST Translation For RTWS the translation languages l needs to be provide
in the URL call, e.g. the URL of the DMN to RuleML translation service is
http://localhost/api/translate/dmn/ruleml/ (We assume that the RTWS runs
on localhost). The body of the HTTP post call contains the raw DMN file
“table.dmn”. Successfully requesting RTWS gives a response with a HTTP status
code 200 and RuleML serialization in the body, otherwise an error has occurred.
REST Execution RTWS also provides an execution method, e.g. a request
with HTTP post message to the URL http://localhost/api/execute/ with the
body:
{ l a n g u a g e : "dmn" , p a r a m e t e r s : { C u s t o m e r : " B u s i n e s s " , " Order ␣ S i z e " : 5 } ,
s o u r c e : , q u e r y : [ " i n p u t E n t r y ( D e c i s i o n T a b l e , ␣Column , ␣Row)
" ]}
The service will translate the DMN file to RuleML and from RuleML to Prova
source code. Parameters of the body get translated to facts like context(“Customer”,
V alue) ⇐ V alue := “Business” and will be translated to Prova source code. Fur-
thermore, Prova source code will extend by “:- solve(inputEntry(DecisionTable,
Column, Row))”. The invocation of Prova source code by RTWS will be a response
as a JSON object with the result of the query.
6 DMN-RuleML Translation Demo
This section demonstrates how a DMN decision table in figure 1 gets serialized in
RuleML. We will examine the decision table “Discount”, the column “Customer”
(DMN input expression), the row starts with 1 (DMN rule), the cell Business at
DMN rule (DMN input entry), column “Discount” (DMN output) and the cell
below with value 0.10 (DMN output entry).
The decision table “Discount” can be defined in DMN as follows:
. . . < !−− a l l i n p u t e x p r e s s i o n s and o u t p u t e x p r e s s i o n s −−>
. . . < !−− a l l r u l e s −−>
A RuleML - DMN Translator 9
RTS translates the decision table “Discount” to RuleML as follows:
. . . < !−− s i g n a t u r e s −−>
D e c i s i o n
d e c i s i o n D i s c o u n t < !−− d e c i s i o n i d −−>
D i s c o u n t < !−− d e c i s i o n l a b e l −−>
d e c i s i o n T a b l e
d e c i s i o n T a b l e < !−− d e c i s i o n t a b l e i d −−>
UNIQUE < !−− H i t P o l i c y −−>
< !−− A g g r e g a t i o n −−>
. . . < !−− a l l i n p u t e x p r e s s i o n s and o u t p u t e x p r e s s i o n s −−>
. . . < !−− R u l e b a s e s f o r each r u l e −−>
We can see that decision and decision table attributes get represented as fact
in knowledge base. All input expressions and output definitions get translated to
the same rulebase. Input expression “Customer” can be defined in DMN as
follows:
i n p u t 1
Translation of the input expression is translated to a Rule inputExpression(· · · ,
V alue) ⇐ context(“input”, S) ∧ V alue := S.
c o n t e x t
i n p u t 1
S t o r a g e 1 0
Value
S t o r a g e 1 0
i n p u t E x p r e s s i o n
d e c i s i o n T a b l e < !−− d e c i s i o n t a b l e i d −−>
0 < !−− column number −−>
Value
Output Expression “Discount” has only attributes. Therefore a fact will
be added to the rulebase.
10 Adrian Paschke and Simon Könnecke
o u t p u t E x p r e s s i o n
R e s u l t
d e c i s i o n T a b l e < !−− d e c i s i o n t a b l e i d −−>
o u t p u t 1 < !−− o u t p u t e x p r e s s i o n i d −−>
o u t p u t 1 < !−− o u t p u t e x p r e s s i o n name −−>
D i s c o u n t < !−− o u t p u t e x p r e s s i o n l a b e l −−>
s t r i n g < !−− o u t p u t e x p r e s s i o n t y p e −−>
Rule 1 contains all cells in the row. Starting by input entries “Business”, < 10
and output entry 0.10. Each rule translated will be translated to new rulebase.
< d e s c r i p t i o n>D i s c o u n t f o r s m a l l b u s i n e s s c u s t o m e r
. . . < !−− i n p u t E n t r y and o u t p u t E n t r y . . . −−>
All attributes of DMN rule and description will translated to a fact.
row −950612891 −1
r u l e
d e c i s i o n T a b l e < !−− d e c i s i o n t a b l e i d −−>
row −950612891 −1 < !−− r u l e i d −−>
< !−− r u l e l a b e l −−>
D i s c o u n t f o r s m a l l b u s i n e s s c u s t o m e r < !−− r u l e
d e s c r i p t i o n −−>
. . . < !−− Here s t a y s I n p u t E n t r y and OutputEntry s e r i a l i z i a t i o n . . . −−>
Input entry and output entry are always related to a rule. Therefore the
translation will be added to the same rulebase as the rule. The input entry has
an ID and a S-FEEL expression. The input entry is related to input expression.
Input expression provides the value that each input entry compares with the
related S-FEEL expression.
< ! [CDATA[ " B u s i n e s s " ] ] >
In this case, the input entry gets compared with the value of input expression
“Customer”. Therefore, inputExpression predicate retrieves the value of input.
This predicate inputEntry(“decision”, 0, 0) get only true, when the input is equal
to “Business”. Note, the S-FEEL serialization is in this case only the atom with
relation “equal”.
i n p u t E x p r e s s i o n
d e c i s i o n T a b l e
0
Value
e q u a l
Value
B u s i n e s s
A RuleML - DMN Translator 11
i n p u t E n t r y
d e c i s i o n T a b l e < !−− d e c i s i o n t a b l e i d −−>
0 < !−− i n p u t column number −−>
0 < !−− r u l e number −−>
Output entry describes the output value of the output expression, when all
input entries turned true. DMN output entry is only a definition of the output
value. Defined in the text tag as S-FEEL expression.
0 . 1 0
The output translation is related to the rule 1, therefore customer need to be a
business customer and the order size should be below 10. If the two constraints are
satisfied then the customer receives a 10% discount; in other words the predicate
outputEntry will be true if the constraints are satisfied. The representation of the
constrains in RuleML in the body of the rule includes all input entries connected
with a logical ∧.
. . . < !−− i n p u t E n t r y ( d e c i s i o n T a b l e , 0 , 0) and
i n p u t E n t r y ( d e c i s i o n T a b l e , 1 , 0) −−>
Value
0 . 1
o u t p u t E n t r y
d e c i s i o n T a b l e < !−− d e c i s i o n t a b l e i d −−>
o u t p u t 1 < !−− o u t p u t e x p r e s s i o n i d −−>
0 < !−− o u t p u t colum number −−>
L i t e r a l E x p r e s s i o n _ 0 6 5 u 3 y m < !−− o u t p u t e n t r y i d −−>
Value
In summary, decision table, output expressions, rules will be serialized as
facts. Input expression, input entry, output expression and output entry will
serialized as horn clauses. The knowledge base is complete, so that queries can be
answered after adding the context predicates. Variables should be defined only
once.
7 Summary
In this paper we have demonstrated a translator service for mapping OMG
DMN (v. 1.1) into RuleML (v. 1.02). This enables the use of the growing set
of modelling tools for OMG DMN as user interfaces together with the rich set
of RuleML-supported rule engines as execution environments. Furthermore, it
adds another standard to the RuleML interchange framework, as a basis for
semantically-safe rule translations by semantically composing the underlying
semantic profiles.
12 Adrian Paschke and Simon Könnecke
Acknowledgement
This work has been partially supported by the “InnoProfile-Transfer Corporate
Smart Content" project funded by the German Federal Ministry of Education
and Research (BMBF) and the BMBF Innovation Initiative for the New German
Länder - Entrepreneurial Regions.
References
1. Athan, T., Boley, H., Paschke, A.: Ruleml 1.02: Deliberation, reaction and consumer
families. In: Proceedings of the RuleML 2015 Challenge, the Special Track on
Rule-based Recommender Systems for the Web of Data, the Special Industry Track
and the RuleML 2015 Doctoral Consortium hosted by the 9th International Web
Rule Symposium (RuleML 2015), Berlin, Germany, August 2-5, 2015. (2015),
http://ceur-ws.org/Vol-1417/paper6.pdf
2. Boley, H.: RIF ruleml rosetta ring: Round-tripping the dlex subset of datalog ruleml
and rif-core. In: Rule Interchange and Applications, International Symposium,
RuleML 2009, Las Vegas, Nevada, USA, November 5-7, 2009. Proceedings. pp.
29–42 (2009), http://dx.doi.org/10.1007/978-3-642-04985-9_6
3. Boley, H.: A rif-style semantics for ruleml-integrated positional-slotted, object-
applicative rules. In: Rule-Based Reasoning, Programming, and Applications - 5th
International Symposium, RuleML 2011 - Europe, Barcelona, Spain, July 19-21, 2011.
Proceedings. pp. 194–211 (2011), http://dx.doi.org/10.1007/978-3-642-22546-8_16
4. Boley, H., Paschke, A., Shafiq, M.O.: Ruleml 1.0: The overarching specification
of web rules. In: Semantic Web Rules - International Symposium, RuleML 2010,
Washington, DC, USA, October 21-23, 2010. Proceedings. pp. 162–178 (2010),
http://dx.doi.org/10.1007/978-3-642-16289-3_15
5. Hallmark, G., de Sainte Marie, C., Fabro, M.D.D., Albert, P., Paschke, A.: Please
pass the rules: A rule interchange demonstration. In: Rule Representation, Inter-
change and Reasoning on the Web, International Symposium, RuleML 2008,
Orlando, FL, USA, October 30-31, 2008. Proceedings. pp. 227–235 (2008),
http://dx.doi.org/10.1007/978-3-540-88808-6_24
6. Object Management Group: Decision model and notation (2014), http://www.omg.
org/spec/DMN/1.1/Beta
7. Paschke, A.: The ContractLog Approach Towards Test-driven Verification and
Validation of Rule Bases - A Homogeneous Integration of Test Cases and Integrity
Constraints into Evolving Logic Programs and Rule Markup Languages (RuleML) .
International Journal of Interoperability in Business Information Systems 10 (2005),
http://ruleml.org/reaction/docs/ContractLog_VVI.pdf
8. Paschke, A.: Reasoning Web. Semantic Technologies for the Web of Data: 7th
International Summer School 2011, Galway, Ireland, August 23-27, 2011, Tutorial
Lectures, chap. Rules and Logic Programming for the Web, pp. 326–381. Springer
Berlin Heidelberg, Berlin, Heidelberg (2011), http://dx.doi.org/10.1007/978-3-642-
23032-5_6
9. Paschke, A.: Reaction ruleml 1.0 for rules, events and actions in semantic complex
event processing. In: Rules on the Web. From Theory to Applications - 8th Interna-
tional Symposium, RuleML 2014, Co-located with the 21st European Conference
on Artificial Intelligence, ECAI 2014, Prague, Czech Republic, August 18-20, 2014.
Proceedings. pp. 1–21 (2014), http://dx.doi.org/10.1007/978-3-319-09870-8_1
A RuleML - DMN Translator 13
10. Paschke, A., Athan, T.: Law test suites for semantically-safe rule interchange. In:
Proceedings of the 16th International Workshop on Non-Monotonic Reasoning
(NMR’16) (2016), http://nmr2016.cs.uct.ac.za/proceedings_nmr2016_online.pdf
11. Paschke, A., Boley, H.: Rule Markup Languages and Semantic Web Rule Languages.
In: Giurca, A., Gasevic, D., Taveter, K. (eds.) Handbook of Research on Emerging
Rule-Based Languages and Technologies: Open Solutions and Approaches, pp. 1–24.
IGI Publishing (May 2009)
12. Paschke, A., Boley, H.: Rules Capturing Events and Reactivity. In: Giurca, A.,
Gasevic, D., Taveter, K. (eds.) Handbook of Research on Emerging Rule-Based
Languages and Technologies: Open Solutions and Approaches, pp. 215–252. IGI
Publishing (May 2009)
13. Paschke, A., Boley, H.: Distributed rule-based agents with rule responder and
reaction ruleml 1.0. In: Proceedings of the RuleML 2014 Challenge and the RuleML
2014 Doctoral Consortium hosted by the 8th International Web Rule Symposium,
Challenge+DC@RuleML 2014, Prague, Czech Republic, August 18-20, 2014. (2014),
http://ceur-ws.org/Vol-1211/paper9.pdf
14. Paschke, A., Boley, H., Zhao, Z., Teymourian, K., Athan, T.: Reaction ruleml 1.0:
Standardized semantic reaction rules. In: Rules on the Web: Research and Applica-
tions - 6th International Symposium, RuleML 2012, Montpellier, France, August
27-29, 2012. Proceedings. pp. 100–119 (2012), http://dx.doi.org/10.1007/978-3-
642-32689-9_9
15. Ramakrishna, S., Paschke, A.: A process for knowledge transformation and
knowledge representation of patent law. In: Rules on the Web. From Theory
to Applications - 8th International Symposium, RuleML 2014, Co-located with
the 21st European Conference on Artificial Intelligence, ECAI 2014, Prague,
Czech Republic, August 18-20, 2014. Proceedings. pp. 311–328 (2014), http:
//dx.doi.org/10.1007/978-3-319-09870-8_23
16. Zou, G., Peter-Paul, R., Boley, H., Riazanov, A.: Psoatransrun: Translating and
running PSOA ruleml via the TPTP interchange language for theorem provers.
In: Proceedings of the RuleML2012@ECAI Challenge, at the 6th International
Symposium on Rules, Montpellier, France, August 27th-29th, 2012 (2012), http:
//ceur-ws.org/Vol-874/paper6.pdf
All links were last followed on June 17, 2016.