Skip to content

Latest commit

 

History

History
57 lines (37 loc) · 2.37 KB

dmn_constraint_tables_extension.md

File metadata and controls

57 lines (37 loc) · 2.37 KB
Raw
date
2020-06-24

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.