ruleml2015: ontology-based multidimensional contexts with applications to quality data specification...

Ontology-Based Multidimensional Contexts withApplications to Quality Data Specification and

Extraction

Mostafa Milani Leopoldo Bertossi

Carleton UniversitySchool of Computer Science

Ottawa, Canada

(Carleton University) Ontology-Based Multidimensional Contexts 1 / 23

Problem Statement Introduction

Multidimensional Contexts and Data Quality

Measurements tablecontains thetemperatures of patientsat a hospital

MeasurementsTime Patient Value

Sep/5-12:10 Tom Waits 38.2Sep/6-11:50 Tom Waits 37.1Sep/7-12:15 Tom Waits 37.7Sep/9-12:00 Tom Waits 37.0Sep/6-11:05 Lou Reed 37.5Sep/5-12:05 Lou Reed 38.0

A doctor suppose/expects the table to contain:

”The body temperatures of Tom Waits for September 5

taken around noon with a thermometer of brand B1”

But Measurements does not contain the information to make thisassessment

An external context can provide that information, making it possibleto assess the given data

Contex is modeled as relational databases (Bertossi et al., BIRTE 2010)

The database under assessment is mapped into the contextualdatabase for further data quality analysis and cleaning

Context is commonly of a multi-dimensional nature

The dimensional aspects of context are not considered in(Bertossi et al., BIRTE 2010)

Multidimensional Context Extended HM Data Model

Extending Context with Multidimensional Data

We can see the context as an ontology, containing:

A MD data model/instance:

PatientWard: A table containing the location of patients

Hospital dimension: Represents the hierarchy of locations

Information such as a hospital guideline:

”Temperature measurement for patients in standard care unithave to be taken with thermometers of brand B1”

Basis data model: HM model (Hurtado and Mendelzon, 2005)

We extend the HM model (Maleki et al., AMW 2012)

Informally, some of the new ingredients in MD contexts:

Dimensions as in the HM

Categorical relations: Generalize fact tables, not necessarily numericalvalues, linked to different levels of dimensions, possibly incomplete

Dimensional rules: Generate data where missing

Dimensional constraints: Constraints on (combinations of) categoricalrelations, involve values from dimension categories

Dimensional rules and constraints can support and restrictupward/downard navigation

Example

Ward and Unit:

categories of Hospital

dimension

UnitWard(unit,ward): a

parent/child relation

PatientUnit

id Unit Day Patient

1 Standard Sep/5 Tom Waits

3 Intensive Sep/7 Tom Waits

4 Intensive Sep/6 Lou Reed

5 Standard Sep/5 Lou Reed

PatientWard

id Ward Day Patient

1 W1 Sep/5 Tom Waits

4 W3 Sep/6 Lou Reed

5 W2 Sep/5 Lou Reed

AllHospital

Institution

Standard Intensive Terminal

W1 W2 W3 W4

allHospital

AllTime

PatientWard: categorical relation with Ward and Day categoricalattributes taking values from dimension categories

Example

Ward and Unit:

dimension

PatientUnit

id Unit Day Patient

PatientWard

id Ward Day Patient

4 W3 Sep/6 Lou Reed

5 W2 Sep/5 Lou Reed

AllHospital

Institution

W1 W2 W3 W4

allHospital

AllTime

Example

Ward and Unit:

dimension

PatientUnit

id Unit Day Patient

PatientWard

id Ward Day Patient

4 W3 Sep/6 Lou Reed

5 W2 Sep/5 Lou Reed

AllHospital

Institution

W1 W2 W3 W4

allHospital

AllTime

Example

Ward and Unit:

dimension

PatientUnit

id Unit Day Patient

PatientWard

id Ward Day Patient

4 W3 Sep/6 Lou Reed

5 W2 Sep/5 Lou Reed

AllHospital

Institution

W1 W2 W3 W4

allHospital

AllTime

Dimensional Constraints

Example

Categorical relations are subject to dimensional constraints:

A referential constraint restricting units in PatientUnitto elements in the Unit category, as a negative constraint:

⊥ ← PatientUnit(u,d ; p),¬Unit(u)

“All thermometers used in a unit are of the same type”:

t = t ′ ← Thermometer(w , t; n),Thermometer(w ′, t′; n′),

UnitWard(u,w),UnitWard(u,w ′) An EGD

“No patient in intensive care unit on August /2005”:

⊥ ← PatientWard(w ,d ; p),UnitWard(Intensive,w),

MonthDay(August/2005, d)

Example

Dimensional Rules

Example

Data in PatientWard generate data about patients forhigher-level categorical relation PatientUnit:

PatientUnit(u,d ; p) ← PatientWard(w ,d ; p),

UnitWard(u,w)

Since relation schemas ”match”, ∃-variable in the head is not needed

Rule is used to navigate from PatientWard.Ward upwards toPatientUnit.Unit via UnitWard

Once at the level of Unit, it is possible to take advantage of aguideline -in the form of a rule- stating that:

“Temperatures of patients in a standard care unit are taken withthermometers of brand B1”

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

WorkingSchedules id Unit Day Nurse Type

1 Intensive Sep/5 Cathy cert.

2 Standard Sep/5 Helen cert.

4 Terminal Sep/5 Susan non-cert.

5 Standard Sep/9 Mark non-cert.

Shifts id Ward Day Nurse Shift

1 W4 Sep/5 Cathy night

2 W1 Sep/6 Helen morning

3 W4 Sep/5 Susan evening

Institution

W1 W2 W3 W4

AllHospital

allHospital

AllTime

Data in categorical relation WorkingSchedules generates data incategorical relation Shifts

Dimensional Rules

Example

WorkingSchedules id Unit Day Nurse Type

1 Intensive Sep/5 Cathy cert.

4 Terminal Sep/5 Susan non-cert.

5 Standard Sep/9 Mark non-cert.

Shifts id Ward Day Nurse Shift

1 W4 Sep/5 Cathy night

2 W1 Sep/6 Helen morning

3 W4 Sep/5 Susan evening

Institution

W1 W2 W3 W4

AllHospital

allHospital

AllTime

Data in categorical relation WorkingSchedules generates data incategorical relation Shifts

Dimensional Rules

Example

∃z Shifts(w ,d ; n, z) ← WorkingSchedules(u,d ; n, t),

UnitWard(u,w)

Captures a guideline stating that: “If a nurse works in a unit on a

specific day, he/she has shifts in every ward of that unit on the same day”

Head has existential variable z for missing values for shift attribute

Rule can be used for downward navigation

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

UnitWard(u,w)

Dimensional Rules

Example

UnitWard(u,w)

Multidimensional Context Ontological Representation of the Extended MD Model

Datalog± as Representation Language

We use Datalog± as our representation language (Cali et al., 2009)

An extension of Datalog for ontology building with efficientaccess to underlying data sources

Our approach to representation of MD contexts is general andsystematic with the following general forms:

Negative constraints capturing referential constraints from categoricalattributes to categories:

⊥ ← R(e; a),¬K (e)

e, e ∈ e stand for categorical attributes,

R a categorical predicate, and

K a category predicate

⊥ ← R(e; a),¬K (e)

Dimensional constraints as EGDs or negative constraints:

x = x ′ ← R1(e1; a1), ...,Rn(en; an),D1(e1, e′1), ...,Dm(em, e

⊥ ← R1(e1; a1), ...,Rn(en; an),D1(e1, e′1), ...,Dm(em, e

Di are parent-child predicates and Ri are categorical predicates

Dimensional rules as TGDs:

∃az Rk(ek ; ak)← R1(e1; a1), ...,Rn(en; an),D1(e1, e′1), ...,Dm(em, e

Existential quantifiers (possibly not needed) over non-categoricalattributes, which may get labeled nulls as values

Repeated variables in bodies of TGDs only for categorical attributes

”Upward or downward navigation captured by joins betweencategorical predicates and parent-child predicates in bodies”

Properties of MD Ontologies

Datalog± is a family of languages with different syntactic restrictionson rules and their interaction to guarantee tractability

Our Datalog± MD ontologies become weakly-sticky Datalog±programs (Cali et al., 2012)

It is crucial that repeated variables in TGDs are for categoricalattributes (a finite number of values can be taken by them, thecategory members)

The chase (that propagates data forward through rules) may notterminate

Weak-stickiness guarantees tractability of conjunctive queryanswering (QA): only an initial portion of the chase has to beinspected

The separability condition on the (good) interaction between TGDsand EGDs becomes application dependent (Cali et al., 2011)

However, if EGDs have categorical head variables, separability holds

Separability implies decidability of conjunctive query answering

Boolean conjunctive QA is tractable for weakly-sticky Datalog±ontologies (the same applies to open conjunctive QA)

As opposed to sticky Datalog±, for weakly-sticky Datalog± there isno general first-order query rewriting methodology

That is, rewriting of conjunctive queries into FO queries in terms ofunderlying DB predicates

Query Answering on MD Ontology

A non-deterministic algorithm WeaklySticky-QAns for weakly-stickyDatalog± (Cali et al., 2012)

WeaklyStickyQAns builds an accepting resolution proof schema, atree-like structure

It shows how query atoms are entailed from extensional data

The algorithm runs in polynomial time in the size of the extensionaldatabase

We proposed a deterministic version of the algorithm forweakly-sticky programs (Milani and Bertossi, AMW 2015)

The new algorithm uses a modified parsimonious chase procedure(parsimonious chase for shy programs) (Leone et al., KR 2012)

It takes advantage of information about the positions with finite ranks(Fagin et al., 2005)

The algorithm explores only a sufficiently large initial portion of thechase with respect to the query

We also studied the magic-sets rewriting technique in combinationwith this QA algorithm (Milani and Bertossi, AMW 2015)

Multidimensional Context MD Context for Quality Data Assessment

MD Contexts and Quality Query Answering: The Gist

The MD ontology M becomes part of the context for data qualityassessment

The original instance D of schema S is to be assessed or cleanedthrough the context

By mapping D into the contextual schema/instance C

In the context:

• Nickname predicates R ′i ∈ S ′

• The core MD ontology M• A set of quality predicates P

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

In the context:

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

In the context:

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

In the context:

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

In the context:

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

In the context:

• The core MD ontology M

• A set of quality predicates P

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

In the context:

schema C

quality predicates

categorical

relations

dimensions

nicknames

quality version

under asessment

Quality predicates are defined with non-recursive Datalog rules interms of categorical predicates and built-ins

Outside context there are Rq1 , ...,R

qn as quality versions

They are defined by quality data extraction rules written innon-recursive Datalog in terms of S ′, P, and built-ins

Quality query answering for Q imposed on S:

1 Replace predicates in Q with their quality versions obtaining Qq

2 Rewrite Qq into QC by applying the quality data extraction rules

3 Unfold the definition of quality predicates P, that results into QM interms of categorical relations and nicknames

4 Answer QM by QA on M

Example

Dimensional rules in M:

WorkingTimes(u, t; n, y)←WorkingSchedules(u, d ; n, y),DayTime(d , t)

PatientUnit(u, t; p)← PatientWard(w , d ; p),DayTime(d , t),

UnitWard(u,w)

Quality predicates in P:

TakenByNurse(t, p, n, y)←WorkingTimes(u, t; n, y),PatientUnit(u, t; p)

TakenWithTherm(t, p, b)← PatientUnit(u, t; p), u = Standard, b = B1

Example

UnitWard(u,w)

Example

UnitWard(u,w)

Example

UnitWard(u,w)

Example

UnitWard(u,w)

Example

UnitWard(u,w)

Example

Quality version Measurementsq:

Measurementsq(t, p, v)← Measurements ′(t, p, v),TakenByNurse(t, p, n, y),

TakenWithTherm(t, p, b), b = B1, y = certified

A doctor asks the body temperatures of Tom Waits for September 5taken around noon:

Q(t, v) : Measurements(t, Tom Waits, v) ∧ Sep5-11:45 ≤ t ≤ Sep5-12:15

He expects that the measurements are taken by a certified nurse andwith a thermometer of brand B1

Example

Replacing predicates of S in Q with their quality versions in Sq:

Qq(t, v) :Measurementsq(t, Tom Waits, v)∧Sep5-11:45 ≤ t ≤ Sep5-12:15

Applying the definition of quality versions:

QC(t, v) : Measurements ′(t, p, v) ∧ TakenByNurse(t, p, n, certified) ∧TakenWithTherm(t, p, B1) ∧ p = Tom Waits ∧Sep/5-11:45 ≤ t ≤ Sep/5-12:15

Unfolding the definition of quality predicates in P:

QM(t, v) :Measurements ′(t, p, v) ∧WorkingTimes(u, t; n, y) ∧PatientUnit(u, t; p) ∧ u=Standard ∧ y =certified ∧p = Tom Waits ∧ Sep/5-11:45 ≤ t ≤ Sep/5-12:15

Example

Measurements ′ has the same extension of Measurements

WorkingTimes and PatientUnit are computed by QA on M

The first second and lastmeasurements have theexpected quality

The first measurement is aclean answer to Q:t = Sep/5-12:10 and v=38.2

Example

Conclusions

Multidimensional contexts are represented as Datalog± ontologies

They allow us to specify data quality conditions, and to retrievequality data

Development, implementation of the query answering algorithms isongoing work

Several extensions:

Uncertain downward-navigation in dimensional rules

Checking dimensional constraints not only on the result of the chasebut while data generation

Relaxing the assumption of complete categorical data, and studying itseffect on dimensions

Conclusions

Several extensions:

Conclusions

Several extensions:

Conclusions

Several extensions:

Conclusions

Several extensions:

Conclusions

Several extensions:

Conclusions

Several extensions:

ruleml2015: ontology-based multidimensional contexts with applications to quality data specification...

Science

body temperatures of

lou reed

quality data specication

data quality analysis

given data contex

cleaning carleton university

temperatures of patients

external context