Rule markup languages are the vehicle for using rules on the Web and other distributed systems. They allow deploying, executing, publishing 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.
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 platformspecific 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
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
prooftheoretic 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 [
Various pre-defined semantic profiles 7 exist, which can be referenced as
semantic styles8 in RuleML, e.g. logical rule semantics [
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
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.
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.
In this section we describe the basics of the RuleML semantic profile 13 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. [
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.
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 diferent sorts by a sort function.
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 serialized 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 <Data> 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 difer between types of constant symbols. 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. <Atom> <Rel i r i =" s w r l b : a d d ">add</ Rel> <Var>R e s u l t</Var> <Data . . . >2 . 0</Data> <Data . . . >3.0</Data> </Atom>
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
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: τinterval(Exp∗, X) =
Exp∗ = [a..b] : a ≥ X ∧ X ≤ b
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∗)) τunary(Exp∗, X) = Exp∗ is a interval : τinterval(Exp∗, X) Exp∗ = − : true otherwise : fconcat(X, Exp∗)
The variable X is the implicit operand. The function fconcat(X, Exp∗) concatenates 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. 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 expression 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) ⇐ n ∧i=0inputEntry(“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
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 ruletranslatorservice.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 translation 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/ / / . . . p u b l i c s t a t i c void main ( S t r i n g [ ] a r g s ) {
R u l e T r a n s l a t o r S e r v i c e r t s = R u l e T r a n s l a t o r S e r v i c e F a c t o r y .
c r e a t e T r a n s l a t o r S e r v i c e ( ) ; t r y { 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 " ) ) ; } catch ( UnknownRulesLanguageException ex ) {
// . . . } catch ( RuleTranslatorException 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 : { Customer: " Busi ness " , " Order ␣ S i z e " : 5} , s o u r c e : <t a b l e . dmn> , q u e r y : [ " inputEntry ( DecisionTable , ␣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. Furthermore, 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
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: <d e c i s i o n i d=" d e c i s i o n D i s c o u n t " name=" Discount "> <d e c i s i o n T a b l e i d=" d e c i s i o n T a b l e " h i t P o l i c y="UNIQUE"> . . . <!−− a l l input e x p r e s s i o n s and output e x p r e s s i o n s −−> . . . <!−− a l l r u l e s −−> </ d e c i s i o n T a b l e> </ d e c i s i o n>
RTS translates the decision table “Discount” to RuleML as follows:
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: <input i d=" i n p u t 1 " l a b e l=" Customer "> <i n p u t E x p r e s s i o n i d=" i n p u t E x p r e s s i o n 1 " typeRef=" s t r i n g ">
<t e x t>i n p u t 1</ t e x t> </ i n p u t E x p r e s s i o n> </ input>
Translation of the input expression is translated to a Rule inputExpression(· · · , V alue) ⇐ context(“input”, S) ∧ V alue := S. <I m p l i e s> <And> <Atom> <Rel>context</ Rel> <Ind>i n p u t 1</ Ind> <Var>Storage10</Var> </Atom> <Equal> <Var>Value</Var> <Var>Storage10</Var> </ Equal> </And> <Atom k e y r e f=" i n p u t E x p r e s s i o n "> <Rel>i n p u t E x p r e s s i o n</ Rel> <Ind>d e c i s i o n T a b l e</ Ind> <!−− d e c i s i o n t a b l e id −−> <Ind>0</ Ind> <!−− column number −−> <Var>Value</Var> </Atom> </ I m p l i e s>
Output Expression “Discount” has only attributes. Therefore a fact will be added to the rulebase. <output i d=" output1 " l a b e l=" Discount " name=" output1 " typeRef=" s t r i n g " /> <Atom k e y r e f=" outputExpression "> <Rel>outputExpression</ Rel> <Var>Result</Var> <Ind>d e c i s i o n T a b l e</ Ind> <!−− d e c i s i o n t a b l e id −−> <Ind>output1</ Ind> <!−− output expression id −−> <Ind>output1</ Ind> <!−− output expression name −−> <Ind>Discount</ Ind> <!−− output expression l a b e l −−> <Ind>s t r i n g</ Ind> <!−− output expression type −−> </Atom>
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. <r u l e i d=" row −950612891−1 "> <d e s c r i p t i o n>Discount f o r small b u s i n e s s customer</ d e s c r i p t i o n> . . . <!−− inputEntry and outputEntry . . . −−> </ r u l e>
All attributes of DMN rule and description will translated to a fact. <Rulebase> <oid><Ind>row −950612891−1</ Ind></ oid> <Atom k e y r e f=" r u l e "> <Rel>r u l e</ Rel> <Ind>d e c i s i o n T a b l e</ Ind> <!−− d e c i s i o n t a b l e id −−> <Ind>row −950612891−1</ Ind> <!−− r u l e id −−> <Ind /> <!−− r u l e l a b e l −−> <Ind>Discount f o r small b u s i n e s s customer</ Ind> <!−− r u l e
d e s c r i p t i o n −−> </Atom> . . . <!−− Here s t a y s InputEntry and OutputEntry s e r i a l i z i a t i o n . . . −−> </ Rulebase>
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. <inputEntry i d=" UnaryTests_0c1o054 "> <t e x t><! [CDATA[ " Business " ] ]></ t e x t> </ inputEntry>
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 m p l i e s> <And> <Atom k e y r e f=" i n p u t E x p r e s s i o n "> <Rel>i n p u t E x p r e s s i o n</ Rel> <Ind>d e c i s i o n T a b l e</ Ind> <Ind>0</ Ind> <Var>Value</Var> </Atom> <Atom> <Rel i r i =" s w r l b : e q u a l ">equal</ Rel> <Var>Value</Var> <Data x s i : t y p e=" x s : s t r i n g ">Business</Data> </Atom> </And> <Atom k e y r e f=" inputEntry "> <Rel>inputEntry</ Rel> <Ind>d e c i s i o n T a b l e</ Ind> <!−− d e c i s i o n t a b l e id −−> <Ind>0</ Ind> <!−− input column number −−> <Ind>0</ Ind> <!−− r u l e number −−> </Atom> </ I m p l i e s>
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. <outputEntry i d=" LiteralExpression_065u3ym "> <t e x t>0 . 1 0</ t e x t> </ outputEntry>
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 m p l i e s> <And> . . . <!−− inputEntry ( decisionTable , 0 , 0) and
inputEntry ( decisionTable , 1 , 0) −−> <Equal> <Var>Value</Var> <Data x s i : t y p e=" x s : d o u b l e ">0 . 1</Data> </ Equal> </And> <Atom k e y r e f=" outputEntry "> <Rel>outputEntry</ Rel> <Ind>d e c i s i o n T a b l e</ Ind> <!−− d e c i s i o n t a b l e id −−> <Ind>output1</ Ind> <!−− output e xp r e s si o n id −−> <Ind>0</ Ind> <!−− output colum number −−> <Ind>LiteralExpression_065u3ym</ Ind> <!−− output entry id −−> <Var>Value</Var> </Atom> </ I m p l i e s>
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.
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.
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. All links were last followed on June 17, 2016.