Post on 18-Nov-2014
description
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OwlOntDB: A Scalable Reasoning System forOWL 2 RL Ontologies
Md Rokan Uddin Faruqui and Wendy MacCaull
St. Francis Xavier UniversityAntigonish, NS, CA
August, 2012
FHIES’12 Paris, France
1
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OUTLINE
Background
Ontology and OWL
Translation
Materialization
Query Processing
Evaluation
Conclusion
2
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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 Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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 Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
BACKGROUND
I CfMS provides care team providers with completeelectronic access to all forms and reference materials,saving time and duplication of effort.
I The prototype is a HTML5 web-based system where nodata is stored on the mobile device; access to the server issecured through a VPN.
I Messages can be exchanged among caregivers and taskscan be monitored with alerts sent for tasks that missdeadlines
I Currently running a second pilot using mobile devices inGASHA (continuing care, rehab clinic, geriatric assessmentclinic, palliative care)
5
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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)
6
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
BACKGROUND
I This talk is based on work by MSc student Rokan Faruqui;I At the end we will discuss some related and future work in
ontology reasoning done by others at the CLI.I Papers in last years’ FHIES describe some details in the
Nova Workflow;I Paper tomorrow with Adrian Rutle is related work using
MDE techniques wherein models are the primary softwareengineering artifacts and as such are used to generate code
I CorrectnessI Fexibility
7
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
ONTOLOGY AND OWLI A model of a domain
I introduces vocabulary relevant to the domainI specifies semantics of terms
Figure: Anatomy8
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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)
9
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
THE WEB ONTOLOGY LANGUAGE (OWL)
From OWL 2-overview (Horrocks)I Motivated by Semantic Web activity
I Add meaning to web content by annotating it with termsdefined in ontologies
I Developed by WebOnt working groupI Based on earlier languages RDF, OIL and DAML+OILI Became a recommendation on 10 Feb 2004
I Supported by tools and infrastructureI APIsI Development environmentsI Reasoners & Information Systems
I Based on a Description Logic (SHOIN )
10
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
DESCRIPTION LOGICS (DLS)
I Fragments of first order logic designed for KRI Desirable computational properties
I Decidable (essential)I Low complexity (desirable)
I Succinct and quantifier free syntax
∀x.[Heart(x) → MuscularOrgan(x) ∧ ∃y.[isPartOf(x, y)
∧CirculatorySystem(y)]]
Heart v MuscularOrgan u ∃ isPartOf .CirculatorySystem
11
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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
Person u ∃isFeeling .Pain v Patient
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 ′′)
12
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
ONTOLOGY AND OWLI OWL playing key role in increasing number & range of
applicationsI eScience, eCommerce, geography, engineering, defence,I E.g., OWL tools used to identify and repair errors in a
medical ontology:
would have led to missed test results if not corrected
I Experience of OWL in use has identified restrictions:I on expressivityI on scalability
I These restrictions are problematic in some applicationsI Research has now shown how some restrictions can be
overcomeI W3COWL WG has updated OWL accordinglyI Result is called OWL 2I OWL 2 is now a Recommendation
13
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OWL 2
I Extends OWL with a small but useful set of featuresI That are needed in applicationsI For which semantics and reasoning techniques are well
understoodI That tool builders are willing and able to support
I Adds profilesI Language subsets with useful computational properties
I Is fully backwards compatible with OWL:I Every OWL ontology is a valid OWL 2 ontologyI Every OWL 2 ontology not using new features is a valid
OWL ontology
I Already supported by popular OWL tools & infrastructure:I Protg, HermiT, Pellet, FaCT++, OWL API
14
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
WHATS NEW IN OWL 2?
Four kinds of new feature:I Increased expressive power
I qualified cardinality restrictions, e.g.:persons having two friends who are republicans
I property chains, e.g.:the brother of your parent is your uncle
I local reflexivity restrictions, e.g.:narcissists love themselves
I reflexive, irreflexive, and asymmetric properties, e.g.:nothing can be a proper part of itself (irreflexive)
I disjoint properties, e.g.:you can’t be both the parent of and child of the same person
I keys, e.g.:country + license plate constitute a unique identifier forvehicles
15
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
WHATS NEW IN OWL 2?
Four kinds of new feature:I Extended Datatypes
I Much wider range of XSD Datatypes supported, e.g.:Integer, string, boolean, real, decimal, float, datatime,...
I User-defined datatypes: max weight of an airmail letter:xsd:integer maxInclusive“20” ˆˆxsd:integer
16
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
WHATS NEW IN OWL 2?
Four kinds of new feature:I Metamodelling and annotationsI Syntactic sugar
I Disjoint unions, e.g.: Element is the DisjointUnion of EarthWind Fire Water
I Negative assertions, e.g.:Mary is not a sister of Ian
17
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OWL 2
I OWL only useful in practice if we can deal with largeontologies and/or large data sets
I Unfortunately, OWL is worst case highly intractableI OWL 2 ontology satisfiability is 2NEXPTIME-complete
I Possible solution is profiles: language subsets with usefulcomputational properties
I OWL defined one such profile: OWL LiteI Unfortunately, it isnt tractable either! (EXPTIME-complete)
18
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OWL 2
I OWL 2 defines three different tractable profiles:I EL: polynomial time reasoning for schema and data
I Useful for ontologies with large conceptual part
I QL: fast (logspace) query answering using RDBMs via SQLI Useful for large datasets already stored in RDBs
I RL: fast (polynomial) query answering using rule-extendedDBs
I Useful for large datasets stored as RDF triples
I OWL 2 RL is A (near maximal) fragment of OWL 2 suchthat
I Can be implemented using standard rule enginesI Closely related to Description Logic Programms (DLP)I No existentials on RHS
19
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OWL 2RLOWL profile that resembles an OWL-based rule language:I Intuition: subclass axioms in OWL RL can be understood as rule-like
implications with head (superclass) and body (subclass)
I Different restrictions on subclasses and superclasses:
I subclasses can only be class names, nominals,conjunctsions, disjunctions, existentials if applied only tosubclass-type expressions
I superclasses can be class names, universals or nominals;also max. cardinalities of 0 or 1 are allowed, all withsuperclass-type filler expressions only
I Property domains and ranges only for subclass-type expressions; propertyhierarchies, disjointness, inverses, (a)symmetry, transitivity, chains,(inverse)functionality, irreflexivity fully supported
I Disjoint classes and classes in keys need subclass-type expressions, equivalenceonly for expressions that are sub- and superclass-type, no restrictions on equality
[P. Hitzler, M. Krotzsch, S. Rudolph: Knowledge Representation for the Semantic
Web, KI 2009 (semantic-web-book.org)]
20
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OWL 2RL EXAMPLES
I ∃parentOf. ∃parentOf.> v Grandfatherrule version: parentOf(x,y) ∧ parentOf(y,z)→ Grandfather(x)
I Orphan v ∀ hasParent.Deadrule version: Orphan(x) ∧ hasParent(x,y)→ Dead(y)
I Monogamous v ≤ 1 married.Aliverule version:Monogamous(x) ∧married(x,y) ∧ Alive(y) ∧married(x,z) ∧ Alive(z)→ y = z
I childOf o childOf v grandchildOfrule version: childOf(x,y) ∧ childOf(y,z)→ grandchildOf(x,z)
[P. Hitzler, M. Krotzsch, S. Rudolph: Knowledge Representation for the Semantic
Web, KI 2009 (semantic-web-book.org)]
21
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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 )
22
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
QUERY ATOMS
q ::= Type(a,C ) | PropertyValue(a, p, v) | SameAs(a, b)| EquivalentClass(C1 ,C2 ) | SubClassOf (C1 ,C2 )| ComplementOf (C1 ,C2 ) | EquivalentProperty(p1 , p2 )| InversOf (p1 , p2 ) | ObjectProperty(p) | DataProperty(p)| InverseFunctional(p) | Transitive(p) | Symmetric(p)| Class(a) | Property(a) | Individual(a) | Irreflexive(a)| StrictSubClass(a) | StrictSubProperty(a) | Reflexive(a)| SubPropertyOf (p1 , p2 ) | DifferentFrom(a, b)| Functional(p) | DisjointWith(C1 ,C2 ) | Irreflexive(a)
23
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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.
24
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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.
25
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
GOAL
I Goal: A scalable reasoner that supports OWL 2 RLprofile.
26
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
OWLONTDB: A SCALABLE REASONING SYSTEM FOR OWL 2 RL ONTOLOGIES
27
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
TRANSLATION: OWL 2 RL – TO – DATALOG
I Express inference tasks for the OWL 2 RL ontology interms of inference tasks for datalog.
I Datalog is a simple rule language stemming from Prolog.
I Extend an existing DLP mapping to accommodate thenew features of OWL 2 RL.
I Translate the inferred ontology to a datalog programsusing the extended DLP mapping.
28
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
TRANSLATION: OWL 2 RL – TO – DATALOG
OWL 2 RL Axioms DL Syntax Datalog RuleClassAssertions a : C C(a)PropertyAssertion 〈a, b〉 : P P (a, b)SubClassOf C v D C(x)→ D(x)ObjectPropertyChain P ◦Q v R P (x, y) ∧Q(y, z)→ R(x, z)EquivalentClasses C ≡ D C(x)→ D(x), D(x)→ C(x)EquivalentProperties P ≡ Q Q(x, y)→ P (x, y)
P (x, y)→ Q(x, y)ObjectInverseOf P ≡ Q− P (x, y)→ Q(y, x)
Q(y, x)→ P (x, y)TransitiveObjectProperty P+ v P P (x, y) ∧ P (y, z)→ P (x, z)SymmetricObjectProperty P ≡ P− P (x, y)→ P (y, x)Object/DataUnionOf C1 t C2 v D C1(x)→ D(x), C2(x)→ D(x)Object/DataIntersectionOf C v D1 uD2 C(x)→ D1(x),C(x)→ D2(x)Object/DataSomeValuesFrom ∃P.C v D P (x, y) ∧ C(y)→ D(x)Object/DataAllValuesFrom C v ∀P.D C(x) ∧ P (x, y)→ D(y)Object/DataPropertyDomain > v ∀P−.C P (y, x)→ C(y)Object/DataPropertyRange > v ∀P.C P (x, y)→ C(y)
29
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
ABOX CONSISTENCY CHECKING
I Restrictions Checker: checks whether the ABox isconsistent with respect to the TBox.
FunctionalProperty InverseFunctionalProperty> v6 1 P > v6 1 P−
FunctionalObjectProperty(P ) InverseFunctionalObjectProperty(P )Irreflexive Asymmetric∃ P.self v ⊥ P v ¬P−IrreflexiveObjectProperty(P ) AsymmetricObjectProperty(P )MinimumCardinality (0/1) MaximumCardinality(0/1)> nP.C 6 nP.CObjectMinCardinality(n P C) ObjectMaxCardinality(n P C)
I Example :I a TBox axiomIrreflexiveObjectProperty(marriedTo)
I an ABox assertion: marriedTo(Bob,Bob)
30
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
ABOX CONSISTENCY CHECKING
I Restrictions Checker: checks whether the ABox isconsistent with respect to the TBox.
FunctionalProperty InverseFunctionalProperty> v6 1 P > v6 1 P−
FunctionalObjectProperty(P ) InverseFunctionalObjectProperty(P )Irreflexive Asymmetric∃ P.self v ⊥ P v ¬P−IrreflexiveObjectProperty(P ) AsymmetricObjectProperty(P )MinimumCardinality (0/1) MaximumCardinality(0/1)> nP.C 6 nP.CObjectMinCardinality(n P C) ObjectMaxCardinality(n P C)
I Example :I a TBox axiomIrreflexiveObjectProperty(marriedTo)
I an ABox assertion: marriedTo(Bob,Bob)
30
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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
I Two approaches to insert facts into relational databasesI Direct Mapping: one table for each predicateI Meta Mapping:
I ClassAssertion − > TypeOf,I ObjectProperty − > RelationshipObj,I DataProperty − > RelationshipData
31
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
DATALOG TO SQL
A datalog rule has one of the following forms
head(h1, . . . hn)
body(b1, . . . , bn)→ head(h1, . . . hn)
body1(b1, . . . , bn) ∧ . . . ∧ bodyN (b1, . . . , bn)→ head(h1, . . . hn)
INSERT INTO <Table1> VALUES( h1, . . . hn)
INSERT INTO <Table1> SELECT<Projectors> FROM <Tables> WHERE <SELECTORS>
INSERT INTO <TableC> SELECT <Projectors>FROM <Table1> JOIN ... JOIN <TableN> WHERE <SELECTORS>
32
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
DATALOG TO SQL – EXAMPLE
Mother(Mary) (1)hasFather(Mary , Bob) (2)
Woman(x ) → Person(x ) (3)hasChild(x , y) ∧ Person(y) → Parent(x ) (4)
(1) INSERT INTO TypeOf(Class, Individual) VALUES(‘‘Mother’’,‘‘Mary’’)
(2) INSERT INTO RelationshipObj(Subject, Predicate, Object)VALUES(‘‘Mary’’, ‘‘hasFather’’, ‘‘Bob’’)
(3) INSERT INTO TypeOf(Class, Individual) SELECT ‘‘Person’’, IndFROM TypeOf WHERE Class == ‘‘Woman’’
(4) INSERT INTO TypeOf(Class, Individual) SELECT ‘‘Parent’’, r.ObjectFROM TypeOf t, RelationshipObj r WHERE r.Predicate == ‘‘hasChild’’
AND t.Class == ‘‘Person’’ AND t.Individual == r.Object
33
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
Given the fact Mother(Mary), the two rulesMother(x )→ Parent(x ) and Parent(x )→ Person(x ) are found.The corresponding SQL statements are:
(1) INSERT INTO Type Of (Class Individual) Values (Mother, Mary)
(2) INSERT INTO TypeOf (Class, Individual)SELECT Parent, Ind FROM TypeOf WHERE Class == Mother
(3) INSERT INTO TypeOf (Class, Individual)SELECT Person, Ind FROM TypeOf WHERE Class == Parent
34
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
I The TypeOf table has two columns: Class and Ind – itstores all the individuals of every class.
I Using the second SQL statement, the algorithm first selectsall the individuals of the class ”Mother”, then it insertsthese individuals as individuals of ”Parent”.
I We provided the class name ”Parent” in the projector list, sothe algorithm will insert all the selected individuals in theTypeOf table, this time as individuals of the Parent class.
I Using the third SQL statement, the algorithm selects allindividuals of the class Parent and inserts theseindividuals as individuals of the class Person.
I Since Mary was in the class Mother, Mary will also be inthe class Parent and Person.
35
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
A FRAGMENT OF THE DATABASE SCHEMA
36
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
QUERY PROCESSINGI The SPARQL-DL API
I is fully aligned with OWL 2.I interacts with main-memory-based reasoners.
I We modified the SPARQL-DL API to extract knowledgefrom the relational database
I We modified following required interfaces:I allC(O), allDP (O), allOP (O), allI(O) return all classes,
data properties, object properties, and individualsrespectively defined in O.
I subC(O, C), supC(O, C), eqC(O, C) return all sub classes,super classes, and equivalent classes respectively of class Cin O.
I subOP (O,P), supOP (O,P), eqOP (O,P), subDP (O,P),supDP (O,P), eq DP (O,P) return all sub object properties,super object properties, equivalent object properties, subdata properties, super data properties, and equivalent dataproperties respectively of properties p in O.
I en(O, q) checks whether O � q for a SPARQL-DLE atom q.37
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
QUERY PROCESSING – BENCHMARK ONTOLOGIES
I The LUBM benchmark ontologyI An ontology about organizational structures of universities.I Developed at the Lehigh University for testing performance
of ontology management and reasoning systemsI Provides a data generator. We use two datasets: lubm1, and
lubm100
I Contains Object and Data property, inverseOf, transitiveproperty and existential quantification
I The wine ontologyI Contains a classification of wine.
I Contains functional roles, disjunctions, and existentialquantifiers.
I We used two datasets :I wine1 - the original wine ontology.I wine5 - which they synthetically generated by replicating 2n
times the ABox of wine1..
38
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
QUERY PROCESSING – LUBM AND WINE ONTOLOGIES
I (LQ1) Find all the students who are employees and returntheir names and designations.
PREFIX ub: <http://www.lehigh.edu/2004/univ-bench.owl#>SELECT * WHERE { Type(?x, ub:Student),Type(?x, ?C), SubClassOf(?C, ub:Employee) }
I (LQ2) Find the names of all students.PREFIX ub: <http://www.lehigh.edu/2004/univ-bench.owl#>SELECT * WHERE { Type(?x, ub:Student) }
I (WQ1) Determine all the instances of “AmericanWine”.
PREFIX wine: <http://www.w3.org/TR/2003/wine#>SELECT ?i WHERE { Type(?i, wine:AmericanWine) }
I (WQ2) Determine all the instances of “Dry” wines.PREFIX wine: <http://www.w3.org/TR/2003/wine#>SELECT ?i WHERE {
Type(?i,?x), SubClassOf(?x, wine:DryWine) }
39
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
RESULTS AND DISCUSSIONS
Ontology C v D Functional Domain Range R v S C(a) P (a, b)
wine1 126 6 6 9 9 247 246wine5 126 6 6 9 9 2717 2706lubm1 36 0 25 18 9 20659 82415lubm100 36 0 25 18 9 5658 11096694
Table: Number of axioms in test ontologies
lubm1 lubm100 wine1 wine5
117.58 s 130.53 s 21.422 s 217.5 s
Table: Time required for materialization
40
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
RESULT AND DISCUSSIONS
Dataset Reasoner LQ1 LQ2
lubm1 Pellet 129.02 s 127.06 slubm1 OwlOntDB 3.43s 0.79 slubm100 Pellet 142.80 s 127.66 slubm100 OwlOntDB 29.07 s 1.0 s
Dataset Reasoner WQ1 WQ2
wine1 Pellet 2.95 s 2.98 swine1 OwlOntDB 0.047 s 0.11 swine5 Pellet 363.089 s 363.59 swine5 OwlOntDB 0.3435 s 1.171 s
Table: A comparison of query answering times.
41
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
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
42
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
THE CANCER PAIN MANAGEMENT (PM) ONTOLOGY
43
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
THE CANCER PAIN MANAGEMENT (PM) ONTOLOGYI We use the pain management ontologythat includes the
terminology and concepts of health and medicineI used in the Guysborough Antigonish Strait Health
Authority (GASHA)I from SNOMED-CT, ICNP, and the guidelines for cancer
pain treatment.
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).
44
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
QUERY PROCESSING – THE PM ONTOLOGY
I Determine the medication information of all the patientswho are feeling “Mucositis” pain.
PREFIX pm: <http://logic.stfx.ca/ontologies/PainOntology.owl#>SELECT ?i ?j WHERE {Type(?i,pm:Patient),PropertyValue(?i, pm:isFeeling, pm:MucositiesPain),
PropertyValue(?i, pm:haMedication, ?j) }
I Find names of the relatives of all the patients who serve asinformal care givers.
PREFIX pm: <http://logic.stfx.ca/ontologies/PainOntology.owl#>SELECT ?i ?j WHERE {Type(?i,pm:Patient), PropertyValue(?i, pm:hasCarer , ?j),SubClassOf(?j, pm:Relative) }
45
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
RESULTS AND DISCUSSIONS
PM250 PM500 PM1000 PM2000 PM3000
No. of Axioms 20344 40396 77600 156308 231555Time (sec.) 20.71 45.94 90.34 263.24 345.28
Table: Time required for materialization
Q1 Q2
Pellet OwlOntDB Pellet OwlOntDBPM250 41.65 7.53 65.85 9.79PM500 91.83 11.71 127.038 14.89PM1000 179.50 16.89 259.678 19.01PM2000 718.18 20.78 959.32 23.21PM3000 - 29.21 - 34.01
Table: A comparison of query answering times (in seconds). “-”means that the reasoner failed to return the result.
46
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
CONCLUSION
I OwlOntDBI 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 less frequent
47
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
LIMITATIONS AND FUTURE DIRECTIONS
I Initial Processing time / Materialization time is very highI Parallel and distributed computing
I Consequence-based classification
I Update Problem: Re-materialize the whole ontologyI Incremental Materialization
I Extend ontology to deal with time and develop efficientreasoners.
48
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
CONTRIBUTIONS
I Developed a translator to generate datalog programs fromOWL 2 RL ontologies by extending the DLP mapping.
I Developed a materialized algorithm that performs aforward chaining over a datalog program, then translatesthe resulting program to a set of SQL statements.
I Modified an existing SPAQRL-DL API
[A. Rakib, R. U. Faruqui, and W. MacCaull, Verifying Resource Requirements forOntology-Driven Rule-Based Agents, Lecture Notes in Computer Science, 2012, Volume7153, Foundations of Information and Knowledge Systems (FoIKS 2012, Kiel,Germany), Pages 312-331.]
49
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
CONTRIBUTIONS
I Developed a translator to generate datalog programs fromOWL 2 RL ontologies by extending the DLP mapping.
I Developed a materialized algorithm that performs aforward chaining over a datalog program, then translatesthe resulting program to a set of SQL statements.
I Modified an existing SPAQRL-DL API
[A. Rakib, R. U. Faruqui, and W. MacCaull, Verifying Resource Requirements forOntology-Driven Rule-Based Agents, Lecture Notes in Computer Science, 2012, Volume7153, Foundations of Information and Knowledge Systems (FoIKS 2012, Kiel,Germany), Pages 312-331.]
49
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
CONTRIBUTIONS
I Developed a translator to generate datalog programs fromOWL 2 RL ontologies by extending the DLP mapping.
I Developed a materialized algorithm that performs aforward chaining over a datalog program, then translatesthe resulting program to a set of SQL statements.
I Modified an existing SPAQRL-DL API
[A. Rakib, R. U. Faruqui, and W. MacCaull, Verifying Resource Requirements forOntology-Driven Rule-Based Agents, Lecture Notes in Computer Science, 2012, Volume7153, Foundations of Information and Knowledge Systems (FoIKS 2012, Kiel,Germany), Pages 312-331.]
49
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
Thanks
50
Background Ontology and OWL Translation Materialization Query Processing Evaluation Conclusion
SYNTAX AND SEMANTICS OF SROIQ CONSTRUCTORS
Constructor Syntax Semantics
Top > ∆I
Bottom ⊥ ∅Conjunction C uD CI ∩DI ALCDisjunction C tD CI ∪DI
Negation ¬C ∆I \DIExist Restriction ∃ R.C {a ∈ ∆I |∃b((a, b) ∈ RI and b ∈ CI)}Value Restriction ∀ R.C {a ∈ ∆I |∀b((a, b) ∈ RI implies b ∈ CI)}Transitive Role R+ (a, b) ∈ RI and (b, c) ∈ RI implies (a, c) ∈ RI R+
ALCR+= S
Role Inclusion R v S RI ⊆ SI HComposite Role R ◦ S {(a, c) ∈ ∆I ×∆I |∃b((a, b) ∈ RI and (b, c) ∈ SI)}Role Chain R1 ◦ . . . ◦Rn v S RI1 ◦ . . . ◦RIn ⊆ SI RNominal {o} {oI} OInverse Role R− {(a, b)|(b, a) ∈ RI} INumber > n R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} > n}Restriction 6 n R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} 6 n} NQualified Number > n R.C {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI and b ∈ CI} > n}Restriction 6 n R.C {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI and b ∈ CI} 6 n} QFunctional > 1 R and {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} > 1} andRole < 2 R {a ∈ ∆I |#{b ∈ ∆I |(a, b) ∈ RI} < 2} FReflexive Role Reflexive(R) a ∈ ∆I implies (a, a) ∈ RI
Irreflexive Role Irreflexive(R) a ∈ ∆I implies (a, a) /∈ RI
Symmetric Role Symmetric(R) (a, b) ∈ RI implies (b, a) ∈ RI
Asymmetric Role Asymmetric(R) (a, b) ∈ RI implies (b, a) /∈ RI
Disjoint Roles Disjoint(R1, . . . Rn) RIj ∩RIk is empty for each i ≤ j, k ≤ n and j 6= k
51