A scalable ontology reasoner via incrementalmaterialization

Fazle Rabbi 1 Wendy MacCaull 1 Rokan U. Faruqui 2

1St. Francis Xavier University, NS, Canada

2McMaster University, ON, Canada

June, 2013

CBMS’13 Porto, Portugal

1

Building Decision-Support Through Dynamic WorkflowSystems, Academia and Industry Working Together for Better

Healthcare

2

BACKGROUND

I Collaborative Academic/Health Authority/ Industryproject (www.logic.stfx.ca)

I Building Decision Support through Workflow for HealthCare

I Vision: “Put Science into Software”I Formal methods/domain expertise/software

engineering/web-based tools: CfMS

I Working on 2 community-based health care programsI Ensure continuum of careI Compliance with guidelinesI Interface with coming EHR

3

BACKGROUND

I The CfMS is comprised of:I an innovative workflow development workbench, NOVA

Workflow, which can support a broad range ofcollaborations among systems built on heterogeneousplatforms, integrated with

I WebPal Content Server, a mobile document managementsystem deployed on tablet computers.

I The CfMS prototype incorporates:I a graphical language to design, verify and execute

workflow andI domain specific language for writing procedural

statements, for querying the knowledge base, for applyingaccess control policies, and for scheduling tasks viaworklists specific to the user.

4

BACKGROUND

I Health care is data intensiveI Use ontology - a kind of structured knowledge base;

advantages over database systems:I knowledge can be inferred from an ontologyI structure makes it easier to correctly change the knowledge

base and provide adaptability to the workflowI Provide access control, monitor such aspects as referral

times and pain to provides alerts to cliniciansI System must consult (query) ontology at decision points

I Need fast reasoners (inference engines)

5

6

ONTOLOGY AND OWLI A model of a domain

I introduces vocabulary relevant to the domainI specifies semantics of terms

Figure : Anatomy7

ONTOLOGY AND OWL

I The Web Ontology Language OWLI W3C Recommendations

I formal semantics based on Description Logic (DL)I OWL 1 (2004)I OWL 2 (2009)

I Formal properties well understood (complexity,decidability)

I Known reasoning algorithmsI Implemented systems (highly optimized)

8

ONTOLOGY AND OWL

I A Description Logic-based Ontology is modelled using:I Classes: unary predicates (e.g., Patient)I Object Properties: binary predicates (e.g., hasFather )I Data Properties: binary predicates (e.g., hasAge)I Individuals: constants (e.g.,Marry : Patient)I Propositional Connectives: u, t, etc.I Property Restrictions: ∃, ∀, etc.

9

ONTOLOGY AND OWL

I A Description Logic-based ontology has two components:I a TBox: contains vocabulary relevant to the domain and

their semantics.Woman v Person Mother v Parent uWoman

I an ABox: contains assertions about individuals in terms ofthis vocabulary.Class Assertions: Mother(Mary)

Object Property Assertions: hasFather(Mary ,Bob)

Data Property Assertions: hasAge(Mary , “35 ′′)

10

REASONING WITH LARGE ONTOLOGIES

I Reasoners determine class hierarchy and allow domainexperts to check (TBox Reasoning) if, e.g.:

I classes are consistent (no obvious errors)I expected subsumptions hold (consistent with intuitions)I unexpected equivalences hold (unintended synonyms)

I ABox ReasoningI consistency checkingI main reasoning problem is (conjunctive) query answering

Eg:

(x , z )←Wine(x ) ∧ drinkWith(x , y) ∧Dish(y) ∧ fromRegion(y , z )

11

REASONING WITH LARGE ONTOLOGIES

I What about scalability?I Reasoning often requires us to deal with large ontologies (#

assertions/#axioms/#classes and properties)I Data/Query intensive applications e.g., Healthcare

systems, use ontologies with large ABoxes.

Figure : DL Reasoners

I Existing DL reasoners perform in-memory reasoning

I Cannot handle ontologies with large ABoxes.

12

SCALABLE APPROACHES

I Database Integration Approach : DL− LiteI Maximal tractable subset of OWL 1 DL that can be handled

using RDBMSI Express ontology as conceptual models such as UML class

diagrams and ER diagramsI Simple rewriting mechanism

I rewriting the query into an SQL query that is then answeredby the RDBMS system

I Logic Programming-based Approach: DLPI Translate ontologies into logic programsI Reuse existing efficient and faster inference algorithmsI We use the forward-chaining method for inferencing.

13

I OwlOntDB: A Scalable Reasoning System for OWL 2 RLOntologies

I TranslationI MaterializationI Query Processing

[R. U. Faruqui, and W. MacCaull, OwlOntDB: A Scalable Reasoning System for OWL 2 RLOntologies, Lecture Notes in Computer Science, 2013, Volume 7789, Foundations ofHealth Information Engineering and Systems (FHIES 2012, Paris, France), Pages312-331.]

14

MATERIALIZATION

I Materialization is an approach of inferring and storingimplicit knowledge from an ontology using adatabase-driven kind of forward chaining rather than anin-memory forward chaining

I Each datalog fact and rule is translated to an SQLstatement

I The asserted and inferred knowledge is stored in arelational database to be used for querying

15

LIMITATIONS OF OWLONTDB

I Initial Processing time / Materialization time is very high

I Update Problem: Re-materialize the whole ontology

16

GOAL: INCRMENTAL MATERIALIZATION

17

DESCRIPTION LOGIC RULES

ClassAssertions SubObjectPropertyOf ObjectPropertyChaina : C P v Q P ◦Q v RC(a) Q(X1, X2)← P (X1, X2) R(X1, X2)← P (X1, X3) ∧Q(X3, X2)

PropertyAssertion ObjectInverseOf EquivalentProperties〈a, b〉 : P P ≡ Q− P ≡ QP (a, b) P (X1, X2)← Q(X2, X1), P (X1, X2)← Q(X1, X2),

Q(X2, X1)← P (X1, X2) Q(X1, X2)← P (X1, X2)

PropertyDomain TransitiveProperty SymmetricObjectPropertyT v ∀P−.C P+ v P P ≡ P−

C(X2)← P (X2, X1) P (X1, X3)← P (X1, X2) ∧ P (X2, X3) P (X1, X2)← P (X2, X1)

PropertyRange ObjectSomeValuesFrom DataSomeValuesFrom,ObjectHasValue, DataHasValueT v ∀P.C ∃P.C v D ∃P.{a} v D

C(X2)← P (X1, X2) D(X1)← P (X1, X2) ∧ C(X2) D(X1)← P (X1, a)

SubClassOf FunctionalProperty InverseFunctionalPropertyC v D > v6 1 P > v6 1 P−

D(X)← C(X) sameAs(X2, X3)← P (X1, X2) ∧ P (X1, X3) sameAs(X1, X2)← P−(X1, X3) ∧ P−(X2, X3)

EquivalentClasses MaxQualifiedCardinality 0 MaxQualifiedCardinality 1C ≡ D D 6 0P.C D 6 1P.C

D(X)← C(X) , Exception← D(X1) ∧ P (X1, X2) ∧ C(X2) sameAs(X2, X3)← D(X1) ∧ P (X1, X2)C(X)← D(X) ∧P (X1, X3) ∧ C(X2) ∧ C(X3)

IntersectionOf Irreflexive AsymmetricC v D1 uD2 ∃ P.self v ⊥ P ≡ ¬P−

D1(X1)← C(X1), Exception← P (X,X) Exception← P (X1, X2) ∧ P (X2, X1)D2(X1)← C(X1)

IntersectionOf ObjectHasValue, DataHasValue AllValuesFromC1 u C2 v D D v ∃P.{a} C v ∀P.D

D(X)← C1(X) ∧ C2(X) P (X, a)← D(X) D(X2)← C(X1) ∧ P (X1, X2)

UnionOf ObjectComplementOf DisjointPropertiesC1 t C2 v D D v ¬C P v ¬Q

D(X1)← C1(X1), Exception← C(X) ∧D(X) Exception← P (X1, X2) ∧Q(X1, X2)D(X1)← C2(X1) Exception← C(X1) ∧ sameAs(X1, X2) ∧D(X2)

18

TBOX

PainIntensity u (∃hasPainLevel.PainLevelZero t ∃hasPainLevel.PainLevelOne) v BackgroundDiscomportPainIntensity u (∃hasPainLevel.PainLevelTwo t ∃hasPainLevel.PainLevelThree) vMildPain

Patient v ∀hasFormalCaregiver.FormalCaregiverMedication u (((∃hasRoute.{IV } t ∃hasRoute.{SC}) u ∃hasDose.{Dose0.25}

u∃hasFrequency.{Q1h} u ∃hasMeasures.{mg} u ∃isMadeOf.{Hydromorphine}) t ...) v StrongOpioidWeakOpioid vMedication u ¬StrongOpioid

Patient u (∃ hasMedication.StrongOpioid) v StrongOpioidRegimenisFeeling ◦ hasSpecialPainProblem ◦ hasSpecialist v hasRefRecommendation

hasAssessment ◦ hasFullHistory v hasFullHistoryhasAssessment ◦ hasAllCausesRecorded v hasAllCausesRecorded

Patient u ∃ hasAllCausesRecorded.{TrueV alue} u ∃ hasFullHistory.{TrueV alue} v CompletedInitialAssessment

19

ABOX

Inpatient(Adam) Inpatient(Bryan) Patient(Adam)

Person(Adam) Patient(Bryan) Person(Bryan)

MalignantBonePain(MalignantBonePain01 ) Location(Elbows)

Physician(Dr .Logan) Person(Dr .Logan)

hasLocation(MalignantBonePain01 ,Elbows)

hasSpecialPainProblem(MalignantBonePain01 ,PostRadiationPain01 )

hasPainSpecialist(PostRadiationPain01 ,Dr .Logan)

20

INCREMENTAL UPDATE: INSERT

I We want to insert the following fact incrementally:isFeeling(Adam,MalignantBonePain01 )

I This fact partially matches with the following datalog rule:isFeeling ◦ hasSpecialPainProblem ◦ hasSpecialist

v hasRefRecommendation

21

INCREMENTAL UPDATE: INSERT

I The incremental materialization algorithm will load thefollowing facts from database:hasSpecialPainProblem(MalignantBonePain01

,PostRadiationPain01 )hasSpecialist(PostRadiationPain01 , Dr .Logan)

I The datalog rule is now instantiable and executes; thisgives us the following inferred fact:hasRefRecommendation(Adam, Dr .Logan)

22

INCREMENTAL UPDATE: DELETE

I Over-estimated approach - removes some items whichmay need to be returned later

hasChild(Brayn,Debi)

hasChild(Brayn,Max )

∃hasChild .Person v Parent

23

CANCER PAIN MANAGEMENT GUIDELINESComplete pain assessment

and care plan

Currently on

regular opioidPain intensityOn weak opioid with

go to Strong Opioid Regimen

moderate-severe pain

Backgound

Discomfort (0− 1)Mild pain

(2− 3)

Moderate

Pain (4− 6)

Severe

Pain (7− 10)

Non Opioid

Regimen

If pain is notstable may startwith weak opioid

If pain is notstable may startwith weak opioid

Weak Opioid

RegimenNo response

Strong Opioid

RegimenNo response

Opioid

MaintenanceResponseYesPain

Intensity

No

Mild pain

(2− 3)

Moderate

Pain (4− 6)

Severe

Pain (7− 10)

Dose titration of opioid

For mild pain: Consider increasing dose by 10% q4h ATCReassess at least every 48− 72 hours

For moderate pain: Increase dose by 10− 25% q4h ATCReassess at least every 24 hours

For severe pain: Increase dose by 25− 50% q4h ATCReassess at least every 12 hours

reassess at

appropriate

intervals

Appropriate

dose and

ResponseSide

effect

Continuedose titration

No

Yes

No

Yes

No

Yes

Management

of side effect

Yes No

24

THE CANCER PAIN MANAGEMENT (PM) ONTOLOGY

25

THE CANCER PAIN MANAGEMENT (PM) ONTOLOGY

I We use the pain management ontologythat includes theterminology and concepts of health and medicine

I used in the Guysborough Antigonish Strait HealthAuthority (GASHA)

I from SNOMED-CT, ICNP, and the guidelines for cancerpain treatment

.

26

THE CANCER PAIN MANAGEMENT (PM) ONTOLOGY

I This ontology includesI several classes including Pain, Person, Patient,PainIntensityType, SpecialPainProblem,SideEffects;

I some object properties including hasPainIntensity,Domain:Pain, Range:PainIntensityType,

I data properties including hasPainLevel, Domain :Pain,Range:xsd:int,

I inverse object properties such as isFeeling andisFeltBy,

I functional object properties including hasPainLevel, i.e.,each pain level belongs to an instance of Pain class.

I We also use propositional connectives to create complexclass expressions (e.g., persons who feel pain are patients,in DL Person u ∃isFeeling .Pain v Patient).

27

RESULTS AND DISCUSSIONS

Figure : Performance Testing

28

RESULTS AND DISCUSSIONS

I ∆10K – average insertion time of a single fact over adatabase where ten thousand facts have already beenmaterialized

I ∆1M – average insertion time of a single fact over adatabase where 1 million facts have already beenmaterialized.

∆i =

∑ij=i−500 δj

500

29

CONCLUSION

I supports OWL 2 RL- an expressive fragment of OWL

I can handle ontologies with a large numbers of instances

I suitable for

I decision support systems that need faster query responsesI query intensive applicationsI applications where updates are more frequent

30

LIMITATIONS AND FUTURE DIRECTIONS

I Parallel and distributed computing

I Consequence-based classification

31

Thanks

32