Proceedings online at http://ceur-ws.org/Vol-1488/paper-08.pdf Ontologies and reasoning algorithms are considered a promising approach to create decision making applications. Rule-based reasoning systems have the advantage that rule sets can be managed and applied separately, which facilitates the custom configuration of those systems. However, current implementations of rule-based reasoning systems usually introduce a trade-off between expressiveness and performance, which either deteriorates the configurability of the application, or limits its performance in an event-driven system. In this paper, we devise an event-driven rule-based reasoning system that preserves its expressiveness. We devise an automatic nurse call system that is able to handle hard time constraints without limiting the possibilities of the reasoner, and list the encountered problems together with their suggested solutions. We achieve reasonable performance in small-scale environments when evaluating this system using N3 rules and the EYE reasoner. We however observe that a large dynamic database limits the performance of the system, because of the file-based nature of the EYE reasoner. As long as no in-memory reasoning is supported, the performance of the resulting system cannot compete with the state of the art. However, the linear scaling of the proposed expressive solution is promising.

1. Event-Driven Rule-Based Reasoning using EYE
Ben De Meester
Dörthe Arndt, Pieter Bonte, Jabran Bhatti,
Wim Dereuddre, Ruben Verborgh, Femke Ongenae,
Filip De Turck, Erik Mannens, and Rik Van de Walle
University Ghent – iMinds – Multimedia Lab
ben.demeester@ugent.be | @Ben__DM
http://ceur-ws.org/Vol-1488/paper-08.pdf
OrdRing2015@ISWC | October 11th 2015 | Bethlehem, PA

2. We present
A nurse call system via reasoning.
Why via (rule) reasoning?
How is it done?
Where are we now?

3. eHealth Scenario
1. Call launched – select nurse + update call2. Call Redirect – select different nurse3. Call Temp. Accept – Update Call Status4. Corridor – Location update5. Patient location – update location, turn on lights and update nurse6. Presence on – update call, turn on lights & update nurse status7. Presence off – update call, turn off lights & update nurse status7. Presence off – update call, turn off lights & update nurse status8. Corridor – update location, turn off lights & update nurse status

4. A Nurse call system
Hospital, finding the most suitable nurse.
Most suitable?
Trust relationship
Competences
Location
Status
ACCIO
Healthcare ontology (DL)

5. How complex?
Assigning the ‘correct’ nurse can be complex

6. This complex

7. Filters in sequence
Correct competences
Decisions in sequence
Being closer and with a patient is more important than being
far away and free
Configurability
Every hospital is different
So, you want to assign a nurse?

8. Needs
Event-based
Nurses move, calls get made, …
Stateful
Keep current states of the nurses
Scalable
1 – 50 wards
Expressive
DL-ontology + complex decision trees

9. Reasoning techniques
OWL DL-reasoning + SPARQL
Con: Bad performance (e.g., location calculation for SPARQL)
Stream reasoning
Con: not enough expressitivity
OWL-RL + rule reasoning
Con: Not DL (but not necessary for this use case)
Pro: easy mapping from decision trees
Pro: all rules are executed at once
Pro: one system for everything

10. N3
{ this } => { that }
Turtle superset
Very expressive
that can be rules
built-ins (e.g. time predicates)
Datalog is not expressive enough
Forward and backward reasoning

11. EYE Reasoner
Performant
Prolog
EYE supports all built-in Prolog predicates
Rule reasoning
File-based

12. Use case analysis
Small portion dynamic data
Split up static from dynamic
State changes can introduce conflict
Programmatic update

13. Split up dynamic data
Static
Hospital layout (rooms, wards, logistics)
Ontologies
Rules
Dynamic
Nurse’s state
Nurse’s location
Active calls
Static Dynamic

14. Programmatic update
Nurse Erik goes from the hallway to room 1
event:
:nurseErik accio:location :room1
knowledge base
:nurseErik accio:location :hallway
Erik cannot be in two places at the same time
Timestamps are expensive
Fixed set of predicates

15. Architecture
Initializer
Decider
PostUpdater
PreUpdater
EventHandler

16. Architecture
Initializer (0)
(1) (6)
(2)
(3)
(4)
(5)
Decider
PostUpdater
PreUpdater
EventHandler

17. Performance improvements for EYE?
Preload the static data
Room location is known before, and doesn’t change
Nurse competences don’t change very day
Multiple parallel reasoning instances

18. Performance?
0
1000
2000
3000
4000
5000
6000
7000
0 10 20 30 40 50
ExecutionTime(ms)
#wards
Splitting / 1 EYE Splitting / 4 EYEs
No splitting / 1 EYE No splitting / 4 EYEs

19. Preloading improves IO
0
500
1000
1500
2000
2500
Preloading / 1
EYE
No preloading /
1 EYE
Preloading / 4
EYEs
No preloading /
4 EYEs
Reasoningtime(ms),50wards
reasoning reasoningIO

20. More consistent reasoning time with multiple parallel instances
0
5
10
15
20
25
30 0
0
15
15
15
15
40
40
50
50
50
50
65
65
65
65
65
90
90
125
ExecutionTime(s)
Time incoming event (s)
1 EYE 4 EYEs

21. Performance?
0
1000
2000
3000
4000
5000
6000
7000
0 10 20 30 40 50
ExecutionTime(ms)
#wards
Preloading / 1 EYE Preloading / 4 EYEs
No preloading / 1 EYE No preloading / 4 EYEs

22. Future performance?
0
100
200
300
400
500
600
700
800
900
0 10 20 30 40 50
ReasoningTime(ms)
#wards
Preloading / 4 EYEs

23. Conclusions
Expressiveness comes at a cost…
But current system works for the current use case.
File-based reasoning is a bottleneck.
next: in-memory reasoning

24. http://ceur-ws.org/Vol-1488/paper-08.pdf
Our project
ORCA
Our pilot project partners: