Post on 15-Apr-2017
transcript
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