DMN extension: Constraint tables
An extension presented in Deryck et al (2019) Adding Constraint Tables to the DMN Standard: Preliminary Results
Properties
- Tables can be translated into first-order logic, and they can be given to a SAT/SMT solver
- Outputs can contain the same FEEL expressions as inputs, including multiple values or negation. This makes sense due to the semantics of constraint tables.
Semantics
| ingredient1 | ingredient2 | dish1 | dish2 |
|---|---|---|---|
| banana | apple | fruitsalad | pie |
| tomato | potato | soup | stew |
Decision table
- row = conjunction of cells
- table = disjunction of rows
(ingredient1=banana ^ ingredient2=apple ^ dish1=fruitsalad ^ dish2=pie)
v
(ingredient1=tomato ^ ingredient2=potato ^ dish1=soup ^ dish2=stew)Constraint table
- row = implication from (conjunction of) inputs to (conjunction of) outputs
- table = conjunction between implications
(ingredient1=banana ^ ingredient2=apple => dish1=fruitsalad ^ dish2=pie)
^
(ingredient1=tomato ^ ingredient2=potato => dish1=soup ^ dish2=stew)Hit policy E*
The authors introduce a new hit policy E* (for ‘Every’).
E* expresses that every row must be satisfied. This makes sense, because the rows are now implications about constraints, not about the concrete state of our pantry.
In traditional DMN, if input, then output translates into “if input satisfies constraints, then output is chosen”. In constraint tables with E* hit policy, if input, then output translates into a literal implication: “if input satisfies constraints, then output must satisfy constraints”.
Questions
Is there a way to compile constraint tables into traditional DMN? Would be useful both for debugging and for ease of implementation
Show in which cases the constraints would be unsolvable.
