Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OrdRing2015 - Event-Driven Rule-based Reasoning using EYE

327 views

Published on

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.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

OrdRing2015 - Event-Driven Rule-based Reasoning using EYE

  1. 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. 2. We present A nurse call system via reasoning. Why via (rule) reasoning? How is it done? Where are we now?
  3. 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. 4. A Nurse call system Hospital, finding the most suitable nurse. Most suitable? Trust relationship Competences Location Status ACCIO Healthcare ontology (DL)
  5. 5. How complex? Assigning the ‘correct’ nurse can be complex
  6. 6. This complex
  7. 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. 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. 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. 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. 11. EYE Reasoner Performant Prolog EYE supports all built-in Prolog predicates Rule reasoning File-based
  12. 12. Use case analysis Small portion dynamic data Split up static from dynamic State changes can introduce conflict Programmatic update
  13. 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. 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. 15. Architecture Initializer Decider PostUpdater PreUpdater EventHandler
  16. 16. Architecture Initializer (0) (1) (6) (2) (3) (4) (5) Decider PostUpdater PreUpdater EventHandler
  17. 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. 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. 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. 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. 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. 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. 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. 24. http://ceur-ws.org/Vol-1488/paper-08.pdf Our project ORCA Our pilot project partners:

×