Using ontologies to formalize semantics within decision tables:
1. Decision tables can be validated using semantic constraints defined in ontologies. This allows hidden rules and meta-rules to be specified.
2. An approach is presented that uses the description logic SROIQ to represent ontological commitments in semantic decision tables. This provides formal semantics for validation.
3. Various types of semantic constraints are discussed, including value, cardinality, mandatory conditions, uniqueness, and exclusivity, which can be directly applied to decision tables from ontological axioms.
Using SOIQ(D) to Formalize Semantics within one Semantic Decision Table
1. Using to Formalize Semantics
within a Semantic Decision Table
Yan Tang Demey and Trung-Kien Tran
21/09/2012 | pag. 1
2. Outlines
• Background
• Related Work
• Our approach: use domain semantics to
validate decision tables
• Discussion and Conclusion
21/09/2012 | pag. 2
3. What is a decision table?
• CSA, (1970): Z243.1-1970 for Decision Tables, Canadian Standards
Association Condition
entry
Condition
stub
Condition 1 2 3 4 5 6
Age <18 >=18,<40 >=40 <18 >=18,<40 >=40
Speak required language (s) Yes Yes Yes No No No
Action
Hire *
Train *
Action
Reject * *
entry * *
Action stub
Decision
rule
21/09/2012 | pag. 3
4. Decision tables in IS and
business
• Easily learned, understandable and
readable
• Concise and precise
• Clear relations of decisional alternatives
• Decision rule set
– Completeness
– Correctness
– Exclusivity
21/09/2012 | pag. 4
5. The Group Decision Modelling
Environment
21/09/2012 | pag. 5
McGrath, J. E. (1984): Groups: Integration and Performance, Prentice-Hall, Englewood Cliffs, ISBN 0-13-365700-0
6. Validation and Verification
• In order to make a “good” decision table, it
needs to be validated and verified
consistent
correct
21/09/2012 | pag. 6
7. Semantic Decision Tables
• Allows rule modellers to analyse decision
tables using domain semantics
– Hidden decision rules and meta-rules are
specified in ontologies
– In the activities of grounding ontological
commitments
Instantiations of concepts
Constraints
Grouping contexts
Articulation (mapping to glossary)
Concepts alignment across contexts
21/09/2012 | pag. 7
8. Related Work
• V&V approaches to decision tables
– Combining columns to reduce columns (Shwayder,
1975)
– Conversion and decomposition (Pooch, 1974)
– PROLOGA (discovering intra-inter tabular
anomalies) (Vanthienen et al., 1998)
– Approximate reduction (Qian et al., 2010)
– Others (Hewette et al., 2003; Ibramsha and Rajaraman, 1978; Lew, 1978)
21/09/2012 | pag. 8
9. Compared to their work
• We focus on using ontological axioms to
validate a decision table
– Sharable and community based (and even
standardized)
– Support group decision making in a nature
way
– Misunderstanding is minimized
21/09/2012 | pag. 9
10. What has been done
• How ontological constraints can be directly
applied to decision tables
– (Tang, Y.: Directly Applied ORM Constraints for Validating and Verifying Semantic Decision
Tables. In: Meersman, R., Dillon, T., Herrero, P. (eds.) OTM-WS 2011. LNCS, vol. 7046, pp.
350–359. Springer, Heidelberg (2011))
• What is the mapping between SDRule-ML
and OWL/RDF(s).
– (Tang, Y., Meersman, R.: Towards Directly Applied Ontological Constraints in a Semantic
Decision Table. In: Palmirani, M. (ed.) RuleML - America 2011. LNCS, vol. 7018, pp. 193–
207. Springer, Heidelberg (2011))
21/09/2012 | pag. 10
11. Motivation and Contribution
• Formalization and semantics for
computational properties for validating a
decision table
• More Focus:
– Validation (not verification)
– Within one table (not across table)
21/09/2012 | pag. 11
12. – A dialect of Description Logics
– DL: decidable fragments of FOL
– An extension to (most basic DL language
of interest) by adding syntactic constructors
• Transitivity
• Nominal
• Inverse roles
• Qualified number restriction
• Data types
21/09/2012 | pag. 12
13. • Expressive enough for SDT
• Good balance between expressiveness
and computational complexity
• OWL2 recommended by W3C is based on
. , which includes
21/09/2012 | pag. 13
18. 1. Value Constraint
Condition 1 2 3 4 … n …
Age >=18 >=18 >=18 >=18 … >=100, <=350
Temperature Sensor >=0,<30 >=0,<30 >=0,<30 >=-10,<0 … >=0,<30
Login State Yes No Maybe Yes … Yes …
Action
Accept * * * *
Choose a random value
within the range
21/09/2012 | pag. 18
19. 1. Value Constraint
Condition 1 2 3 4 … n …
Age >=18 >=18 >=18 >=18 … >=100, <=350
Temperature Sensor >=0,<30 >=0,<30 >=0,<30 >=-10,<0 … >=0,<30
Login State Yes No Maybe Yes … Yes …
Action
Accept * * * *
21/09/2012 | pag. 19
20. 2. Cardinality and
Occurrence Frequency
Condition 1 2 3 4 5 6 7 8
X-Box 557 Yes Yes Yes Yes No No No No
X-Box 120 Yes Yes No No Yes Yes No No
MS Xbox 360 Yes No Yes No Yes No Yes No
Action
Actuator x * * * * *
Interpret condition
entries “Yes”, “No” into
true or false in DL
axioms
21/09/2012 | pag. 20
21. 2. Cardinality and
Occurrence Frequency
Condition 1 2 3 4 5 6 7 8
X-Box 557 Yes Yes Yes Yes No No No No
X-Box 120 Yes Yes No No Yes Yes No No
MS Xbox 360 Yes No Yes No Yes No Yes No
Action
Actuator x * * * * *
21/09/2012 | pag. 21
22. 3. Mandatory
• A special case of role cardinality
𝑅𝑜𝑜𝑚 ⊑≥ 1 ℎ𝑎𝑠. 𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟
Or,
𝑅𝑜𝑜𝑚 ⊑ ∃ℎ𝑎𝑠. 𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟
𝑅𝑜𝑜𝑚 ⊑ ∃ℎ𝑎𝑠. 𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟 ⊓ ¬∀ℎ𝑎𝑠𝐶𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝐸𝑛𝑡𝑟𝑦 𝑓𝑎𝑙𝑠𝑒
Condition 1 2 3 4 5 6 7 8
X-Box 557 Yes Yes Yes Yes No No No No
X-Box 120 Yes Yes No No Yes Yes No No
MS Xbox 360 Yes No Yes No Yes No Yes No
Action
Actuator x * * * * *
21/09/2012 | pag. 22
23. 3. Mandatory
Condition 1 2 3 4 5 6 7 8
X-Box 557 Yes Yes Yes Yes No No No No
X-Box 120 Yes Yes No No Yes Yes No No
MS Xbox 360 Yes No Yes No Yes No Yes No
Action
Actuator x * * * * *
21/09/2012 | pag. 23
24. 3. Mandatory
• An example of N/A
Condition 1 2 3
X-Box Humidity {X-Box557, X-Box120} {X-Box557, MS Xbox360} N/A
Sensor
Action
Actuator x * *
𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟I= 𝑥𝐵𝑜𝑥557, 𝑥𝐵𝑜𝑥120, 𝑚𝑆𝑋𝑏𝑜𝑥360
𝑛/𝑎 ⊑ ¬𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟
𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟 𝑛/𝑎
A mapping is needed
21/09/2012 | pag. 24
25. 4. Uniqueness
Condition 1 2 3 4 5 6 7 8
X-Box 557 Yes Yes Yes Yes No No No No
X-Box 120 Yes Yes No No Yes Yes No No
MS Xbox 360 Yes No Yes No Yes No Yes No
Action
Actuator x * * * * *
𝑅𝑜𝑜𝑚 ⊑≤ 1 ℎ𝑎𝑠. 𝑋𝐵𝑜𝑥𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟 ⊓ ∃ℎ𝑎𝑠𝐶𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛𝐸𝑛𝑡𝑟𝑦 𝑡𝑟𝑢𝑒
21/09/2012 | pag. 25
28. 5. Exclusive-Or
Condition 1 2 3 4
Humidity Sensor Yes Yes No No
Light Sensor Yes No Yes No
Action
Actuator x * *
Actuator y *
𝑅𝑜𝑜𝑚 ⊑ ∃ℎ𝑎𝑠. 𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟 ⊔ 𝐿𝑖𝑔ℎ𝑡𝑆𝑒𝑛𝑠𝑜𝑟
𝑅𝑜𝑜𝑚 ⊑ ¬ ∃ℎ𝑎𝑠. 𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟 ⊓ ∃ℎ𝑎𝑠. 𝐿𝑖𝑔ℎ𝑡𝑆𝑒𝑛𝑠𝑜𝑟
𝑅𝑜𝑜𝑚 ⊑ ∃𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒. 𝐴𝑐𝑡𝑢𝑎𝑡𝑜𝑟𝑥 ⊔ 𝐴𝑐𝑡𝑢𝑎𝑡𝑜𝑟𝑦
𝑅𝑜𝑜𝑚 ⊑ ¬ ∃𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒. 𝐴𝑐𝑡𝑢𝑎𝑡𝑜𝑟𝑥 ⊓ ∃𝑎𝑐𝑡𝑖𝑣𝑖𝑎𝑡𝑒. 𝐴𝑐𝑡𝑢𝑎𝑡𝑜𝑟𝑦
21/09/2012 | pag. 28
29. 6. Subtyping
Condition 1 2 3 4
Humidity Yes Yes No No
Sensor
Sensor Yes No Yes No
Action
Actuator x * * *
𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟 ⊑ 𝑆𝑒𝑛𝑠𝑜𝑟
𝑅𝑜𝑜𝑚 ⊑ ∃ℎ𝑎𝑠. 𝐻𝑢𝑚𝑖𝑑𝑖𝑡𝑦𝑆𝑒𝑛𝑠𝑜𝑟
𝑅𝑜𝑜𝑚 ⊑ ∀ℎ𝑎𝑠. ¬𝑆𝑒𝑛𝑠𝑜𝑟
21/09/2012 | pag. 30
30. Discussion
• Business value: to support a decision group to draw decisions
• Advantages:
– Semantics is fully kept
– Existing reasoners to check the consistency -> validation
• Disadvantages:
– The mapping is non-trivial
– Reasoning cost: NEXPTIME
• Future Work
– A supporting tool of the mapping
– Using reasoners to derive semantics within a table, e.g. subclasses
between condition/action stubs
– Validation across tables
21/09/2012 | pag. 31
31. Conclusion
• Using domain semantics to validate decision tables
(within one table)
• Directly applied ontological constraints
– Value
– Cardinality
– Mandatory
– Uniqueness
– Exclusive-or
– Subtyping
• All the examples can be downloaded at
http://starlab.vub.ac.be/website/SDT_SOIQ
21/09/2012 | pag. 32