(Description) Logics for Information Modelling and Access - or - - - PowerPoint PPT Presentation

▶
description logics for information modelling and access
SMART_READER_LITE
LIVE PREVIEW

(Description) Logics for Information Modelling and Access - or - - - PowerPoint PPT Presentation

Jan 24, 2024 120 likes •978 views

(Description) Logics for Information Modelling and Access - or - How to Use an Ontology Enrico Franconi franconi@inf.unibz.it http://www.inf.unibz.it/franconi Faculty of Computer Science, Free University of Bozen-Bolzano (1/31) Summary

slide-1
SLIDE 1

(Description) Logics for Information Modelling and Access

  • or -

How to Use an Ontology

Enrico Franconi

franconi@inf.unibz.it http://www.inf.unibz.it/˜franconi

Faculty of Computer Science, Free University of Bozen-Bolzano

(1/31)

slide-2
SLIDE 2

Summary

  • What is an Ontology
  • Description Logics for Conceptual Modelling
  • Queries with an Ontology

(2/31)

slide-3
SLIDE 3

What is an Ontology

  • An ontology is a formal conceptualisation of the world: a conceptual schema.

(3/31)

slide-4
SLIDE 4

What is an Ontology

  • An ontology is a formal conceptualisation of the world: a conceptual schema.
  • An ontology specifies a set of constraints, which declare what should

necessarily hold in any possible world.

(3/31)

slide-5
SLIDE 5

What is an Ontology

  • An ontology is a formal conceptualisation of the world: a conceptual schema.
  • An ontology specifies a set of constraints, which declare what should

necessarily hold in any possible world.

  • Any possible world should conform to the constraints expressed by the
  • ntology.

(3/31)

slide-6
SLIDE 6

What is an Ontology

  • An ontology is a formal conceptualisation of the world: a conceptual schema.
  • An ontology specifies a set of constraints, which declare what should

necessarily hold in any possible world.

  • Any possible world should conform to the constraints expressed by the
  • ntology.
  • Given an ontology, a legal world description is a finite possible world

satisfying the constraints.

(3/31)

slide-7
SLIDE 7

Ontology languages and Conceptual Data Models

  • An ontology language usually introduces concepts (aka classes, entities),

properties of concepts (aka slots, attributes, roles), relationships between concepts (aka associations), and additional constraints.

(4/31)

slide-8
SLIDE 8

Ontology languages and Conceptual Data Models

  • An ontology language usually introduces concepts (aka classes, entities),

properties of concepts (aka slots, attributes, roles), relationships between concepts (aka associations), and additional constraints.

  • Ontology languages may be simple (e.g., having only concepts and

taxonomies), frame-based (having only concepts and properties), or logic-based (e.g. Ontolingua, DAML+OIL, OWL).

(4/31)

slide-9
SLIDE 9

Ontology languages and Conceptual Data Models

  • An ontology language usually introduces concepts (aka classes, entities),

properties of concepts (aka slots, attributes, roles), relationships between concepts (aka associations), and additional constraints.

  • Ontology languages may be simple (e.g., having only concepts and

taxonomies), frame-based (having only concepts and properties), or logic-based (e.g. Ontolingua, DAML+OIL, OWL).

  • Ontology languages are typically expressed by means of diagrams.

(4/31)

slide-10
SLIDE 10

Ontology languages and Conceptual Data Models

  • An ontology language usually introduces concepts (aka classes, entities),

properties of concepts (aka slots, attributes, roles), relationships between concepts (aka associations), and additional constraints.

  • Ontology languages may be simple (e.g., having only concepts and

taxonomies), frame-based (having only concepts and properties), or logic-based (e.g. Ontolingua, DAML+OIL, OWL).

  • Ontology languages are typically expressed by means of diagrams.
  • Entity-Relationship schemas and UML class diagrams can be considered

as ontologies.

(4/31)

slide-11
SLIDE 11

UML Class Diagram

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

(5/31)

slide-12
SLIDE 12

Entity-Relationship Schema

Employee

PaySlipNumber(Integer) Salary(Integer)

Project

ProjectCode(String)

Manager TopManager AreaManager

×

Works-for Manages (1,n) (1,1) (1,1)

(6/31)

slide-13
SLIDE 13

The role of a Conceptual Schema

Data Store Logical Schema Conceptual Schema

(7/31)

slide-14
SLIDE 14

The role of a Conceptual Schema

Constraints Data Store Logical Schema Conceptual Schema

(7/31)

slide-15
SLIDE 15

The role of a Conceptual Schema

Constraints Query Result Data Store Logical Schema Conceptual Schema

(7/31)

slide-16
SLIDE 16

The role of a Conceptual Schema

Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(7/31)

slide-17
SLIDE 17

The role of a Conceptual Schema

Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(7/31)

slide-18
SLIDE 18

Reasoning with Ontologies

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

  • Managers do not work for a project (she/he just manages it):

∀x. Manager(x) → ∀y. ¬WORKS-FOR(x, y)

(8/31)

slide-19
SLIDE 19

Reasoning with Ontologies

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

1..⋆

Works-for

1..1 1..1

Manages

  • Managers do not work for a project (she/he just manages it):

∀x. Manager(x) → ∀y. ¬WORKS-FOR(x, y)

  • If the minimum cardinality for the participation of employees to the works-for

relationship is increased, then . . .

(8/31)

slide-20
SLIDE 20

Summary

  • Logic and Conceptual Modelling
  • Description Logics for Conceptual Modelling
  • Queries with an Ontology

(9/31)

slide-21
SLIDE 21

Encoding ontologies in Description Logics

  • Object-oriented data models (e.g., UML and ODMG)
  • Semantic data models (e.g., EER and ORM)
  • Frame-based and web ontology languages (e.g., DAML+OIL and OWL)

(10/31)

slide-22
SLIDE 22

Encoding ontologies in Description Logics

  • Object-oriented data models (e.g., UML and ODMG)
  • Semantic data models (e.g., EER and ORM)
  • Frame-based and web ontology languages (e.g., DAML+OIL and OWL)
  • Theorems prove that an ontology and its encoding as DL knowledge bases

constrain every world description in the same way – i.e., the models of the DL theory correspond to the legal world descriptions of the ontology, and vice-versa.

(10/31)

slide-23
SLIDE 23

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

Works-for ⊑ emp/2 : Employee ⊓ act/2 : Project Manages ⊑ man/2 : TopManager ⊓ prj/2 : Project Employee ⊑ ∃=1[worker](PaySlipNumber ⊓ num/2 : Integer)⊓ ∃=1[payee](Salary ⊓ amount/2 : Integer) ⊤ ⊑ ∃≤1[num](PaySlipNumber ⊓ worker/2 : Employee) Manager ⊑ Employee ⊓ (AreaManager ⊔ TopManager) AreaManager ⊑ Manager ⊓ ¬TopManager TopManager ⊑ Manager ⊓ ∃=1[man]Manages Project ⊑ ∃≥1[act]Works-for ⊓ ∃=1[prj]Manages · · ·

(11/31)

slide-24
SLIDE 24

Deducing constraints

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

Managers are employees who do not work for a project (she/he just manages it):

Employee ⊓ ¬(∃≥1[emp]Works-for) ⊑ Manager, Manager ⊑ ¬(∃≥1[emp]Works-for)

(12/31)

slide-25
SLIDE 25

Deducing constraints

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

Managers are employees who do not work for a project (she/he just manages it):

Employee ⊓ ¬(∃≥1[emp]Works-for) ⊑ Manager, Manager ⊑ ¬(∃≥1[emp]Works-for)

| =

For every project, there is at least one employee who is not a manager:

Project ⊑ ∃≥1[act](Works-for ⊓ emp : ¬Manager)

(12/31)

slide-26
SLIDE 26

i•com: Intelligent Conceptual Modelling tool

  • i•com allows for the specification of multiple EER (or UML) diagrams and

inter- and intra-schema constraints;

  • Complete logical reasoning is employed by the tool using a hidden underlying

DLR inference engine;

  • i•com verifies the specification, infers implicit facts and stricter constraints,

and manifests any inconsistencies during the conceptual modelling phase.

(13/31)

slide-27
SLIDE 27

Summary

  • Logic and Conceptual Modelling
  • Description Logics for Conceptual Modelling
  • Queries with an Ontology

(14/31)

slide-28
SLIDE 28

The role of a Conceptual Schema – revisited

Data Store Logical Schema Conceptual Schema

(15/31)

slide-29
SLIDE 29

The role of a Conceptual Schema – revisited

Constraints Data Store Logical Schema Conceptual Schema

(15/31)

slide-30
SLIDE 30

The role of a Conceptual Schema – revisited

Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-31
SLIDE 31

The role of a Conceptual Schema – revisited

Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-32
SLIDE 32

The role of a Conceptual Schema – revisited

Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-33
SLIDE 33

The role of a Conceptual Schema – revisited

Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-34
SLIDE 34

The role of a Conceptual Schema – revisited

Query Result Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-35
SLIDE 35

The role of a Conceptual Schema – revisited

Deduction Query Result Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-36
SLIDE 36

The role of a Conceptual Schema – revisited

Deduction Query Result Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-37
SLIDE 37

The role of a Conceptual Schema – revisited

Mediator Deduction Query Result Deduction Constraints Query Result Data Store Logical Schema Conceptual Schema

(15/31)

slide-38
SLIDE 38

Queries with Ontologies: the DB assumption

  • Basic assumption: consistent information with respect to the constraints

introduced by the ontology

  • DB assumption: complete information about each term appearing in the
  • ntology
  • Problem: answer a query over the ontology vocabulary

(16/31)

slide-39
SLIDE 39

Queries with Ontologies: the DB assumption

  • Basic assumption: consistent information with respect to the constraints

introduced by the ontology

  • DB assumption: complete information about each term appearing in the
  • ntology
  • Problem: answer a query over the ontology vocabulary
  • Solution: use a standard DB technology (e.g., SQL, datalog, etc)

(16/31)

slide-40
SLIDE 40

Example with DB assumption

Manager Employee Project

1..⋆

Works-for

(17/31)

slide-41
SLIDE 41

Example with DB assumption

Manager Employee Project

1..⋆

Works-for

Employee = { John, Mary, Paul } Manager = { John, Paul } Works-for = { (John,Prj-A), (Mary,Prj-B) } Project = { Prj-A, Prj-B }

(17/31)

slide-42
SLIDE 42

Example with DB assumption

Manager Employee Project

1..⋆

Works-for

Employee = { John, Mary, Paul } Manager = { John, Paul } Works-for = { (John,Prj-A), (Mary,Prj-B) } Project = { Prj-A, Prj-B } Q(X) :- Manager(X), Works-for(X,Y), Project(Y) = ⇒ { John }

(17/31)

slide-43
SLIDE 43

Weakening the DB assumption

  • The DB assumption is against the principle that an ontology presents a richer

vocabulary than the data stores.

(18/31)

slide-44
SLIDE 44

Weakening the DB assumption

  • The DB assumption is against the principle that an ontology presents a richer

vocabulary than the data stores.

  • Partial DB assumption: complete information about some term appearing in

the ontology

  • Standard DB technologies do not apply
  • The query answering problem in this context is inherently complex

(18/31)

slide-45
SLIDE 45

Example with partial DB assumption

Manager Employee Project

1..⋆

Works-for

Manager = { John, Paul } Works-for = { (John,Prj-A), (Mary,Prj-B) } Project = { Prj-A, Prj-B }

(19/31)

slide-46
SLIDE 46

Example with partial DB assumption

Manager Employee Project

1..⋆

Works-for

Manager = { John, Paul } Works-for = { (John,Prj-A), (Mary,Prj-B) } Project = { Prj-A, Prj-B } Q(X) :- Employee(X)

(19/31)

slide-47
SLIDE 47

Example with partial DB assumption

Manager Employee Project

1..⋆

Works-for

Manager = { John, Paul } Works-for = { (John,Prj-A), (Mary,Prj-B) } Project = { Prj-A, Prj-B } Q(X) :- Employee(X) = ⇒ { John, Paul, Mary }

(19/31)

slide-48
SLIDE 48

Andrea’s Example

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

(20/31)

slide-49
SLIDE 49

Andrea’s Example

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

Employee = { Andrea, Paul, Mary, John } Manager = { Andrea, Paul, Mary} AreaManagerp = { Paul } TopManagerp = { Mary } Supervised = { (John,Andrea), (John,Mary) } OfficeMate = { (Mary,Andrea), (Andrea,Paul) }

(20/31)

slide-50
SLIDE 50

Andrea’s Example

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

Employee = { Andrea, Paul, Mary, John } Manager = { Andrea, Paul, Mary} AreaManagerp = { Paul } TopManagerp = { Mary } Supervised = { (John,Andrea), (John,Mary) } OfficeMate = { (Mary,Andrea), (Andrea,Paul) } Paul: AreaManagerp Andrea: Manager Mary: TopManagerp John

❄ ✛

  • ✠

❅ ❅ ❅ ❅ ❅ ❘

Supervised Supervised OfficeMate OfficeMate

(20/31)

slide-51
SLIDE 51

Andrea’s Example (cont.)

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

(21/31)

slide-52
SLIDE 52

Andrea’s Example (cont.)

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

Paul: AreaManagerp Andrea: Manager Mary: TopManagerp John

❄ ✛

  • ✠

❅ ❅ ❅ ❅ ❅ ❘

Supervised Supervised OfficeMate OfficeMate

(21/31)

slide-53
SLIDE 53

Andrea’s Example (cont.)

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

Paul: AreaManagerp Andrea: Manager Mary: TopManagerp John

❄ ✛

  • ✠

❅ ❅ ❅ ❅ ❅ ❘

Supervised Supervised OfficeMate OfficeMate

Q(X) :- Supervised(X,Y), TopManager(Y), Officemate(Y,Z), AreaManager(Z)

(21/31)

slide-54
SLIDE 54

Andrea’s Example (cont.)

AreaManagerp TopManagerp AreaManager TopManager Manager Employee

{disjoint,complete}

Supervised OfficeMate

Paul: AreaManagerp Andrea: Manager Mary: TopManagerp John

❄ ✛

  • ✠

❅ ❅ ❅ ❅ ❅ ❘

Supervised Supervised OfficeMate OfficeMate

Q(X) :- Supervised(X,Y), TopManager(Y), Officemate(Y,Z), AreaManager(Z) = ⇒ { John }

(21/31)

slide-55
SLIDE 55

The general case: View based Query Processing

In general, the mapping between the ontology and the information source terms can be given in terms of a set of sound or exact views:

(22/31)

slide-56
SLIDE 56

The general case: View based Query Processing

In general, the mapping between the ontology and the information source terms can be given in terms of a set of sound or exact views:

  • GAV (global-as-view): a view over the information source is given for some

term in the ontology

(22/31)

slide-57
SLIDE 57

The general case: View based Query Processing

In general, the mapping between the ontology and the information source terms can be given in terms of a set of sound or exact views:

  • GAV (global-as-view): a view over the information source is given for some

term in the ontology

  • both the DB and the partial DB assumptions are special cases of GAV
  • an ER schema can be easily mapped to its corresponding relational

schema in normal form via a GAV mapping

(22/31)

slide-58
SLIDE 58

The general case: View based Query Processing

In general, the mapping between the ontology and the information source terms can be given in terms of a set of sound or exact views:

  • GAV (global-as-view): a view over the information source is given for some

term in the ontology

  • both the DB and the partial DB assumptions are special cases of GAV
  • an ER schema can be easily mapped to its corresponding relational

schema in normal form via a GAV mapping

  • LAV (local-as-view): a view over the ontology terms is given for each term in

the information source;

  • GLAV: mixed from the above.

(22/31)

slide-59
SLIDE 59

Sound GAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

(23/31)

slide-60
SLIDE 60

Sound GAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode)

(23/31)

slide-61
SLIDE 61

Sound GAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) Employee(X) :- 1-Employee(X,Y,Z) Employee(X) :- 2-Works-for(X,Y) Manager(X) :- 1-Employee(X,Y, true) Project(Y) :- 2-Works-for(X,Y) Works-for(X,Y) :- 2-Works-for(X,Y) Salary(X,Y) :- 1-Employee(X,Y,Z)

(23/31)

slide-62
SLIDE 62

Queries with Sound GAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) Employee(X) :- 1-Employee(X,Y,Z) Employee(X) :- 2-Works-for(X,Y) Manager(X) :- 1-Employee(X,Y, true) Project(Y) :- 2-Works-for(X,Y) Works-for(X,Y) :- 2-Works-for(X,Y) Salary(X,Y) :- 1-Employee(X,Y,Z)

(24/31)

slide-63
SLIDE 63

Queries with Sound GAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) Employee(X) :- 1-Employee(X,Y,Z) Employee(X) :- 2-Works-for(X,Y) Manager(X) :- 1-Employee(X,Y, true) Project(Y) :- 2-Works-for(X,Y) Works-for(X,Y) :- 2-Works-for(X,Y) Salary(X,Y) :- 1-Employee(X,Y,Z) Q(X) :- Employee(X)

(24/31)

slide-64
SLIDE 64

Queries with Sound GAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) Employee(X) :- 1-Employee(X,Y,Z) Employee(X) :- 2-Works-for(X,Y) Manager(X) :- 1-Employee(X,Y, true) Project(Y) :- 2-Works-for(X,Y) Works-for(X,Y) :- 2-Works-for(X,Y) Salary(X,Y) :- 1-Employee(X,Y,Z) Q(X) :- Employee(X) = ⇒ Q’(X) :- 1-Employee(X,Y,Z) ∪ 2-Works-for(X,W)

(24/31)

slide-65
SLIDE 65

Sound LAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

(25/31)

slide-66
SLIDE 66

Sound LAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode)

(25/31)

slide-67
SLIDE 67

Sound LAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) 1-Employee(X,Y,Z) :- Manager(X), Salary(X,Y), Z=true 1-Employee(X,Y,Z) :- Employee(X), ¬Manager(X), Salary(X,Y), Z=false 2-Works-for(X,Y) :- Works-for(X,Y)

(25/31)

slide-68
SLIDE 68

Queries with Sound LAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) 1-Employee(X,Y,Z) :- Manager(X), Salary(X,Y), Z=true 1-Employee(X,Y,Z) :- Employee(X), ¬Manager(X), Salary(X,Y), Z=false 2-Works-for(X,Y) :- Works-for(X,Y)

(26/31)

slide-69
SLIDE 69

Queries with Sound LAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) 1-Employee(X,Y,Z) :- Manager(X), Salary(X,Y), Z=true 1-Employee(X,Y,Z) :- Employee(X), ¬Manager(X), Salary(X,Y), Z=false 2-Works-for(X,Y) :- Works-for(X,Y) Q(X) :- Manager(X), Works-for(X,Y), Project(Y)

(26/31)

slide-70
SLIDE 70

Queries with Sound LAV mapping

Manager Employee

PaySlipNumber:Integer Salary:Integer

Project

ProjectCode:String 1..⋆

Works-for

1-Employee(PaySlipNumber,Salary,ManagerP) 2-Works-for(PaySlipNumber,ProjectCode) 1-Employee(X,Y,Z) :- Manager(X), Salary(X,Y), Z=true 1-Employee(X,Y,Z) :- Employee(X), ¬Manager(X), Salary(X,Y), Z=false 2-Works-for(X,Y) :- Works-for(X,Y) Q(X) :- Manager(X), Works-for(X,Y), Project(Y) = ⇒ Q’(X) :- 1-Employee(X,Y,true), 2-Works-for(X,Z)

(26/31)

slide-71
SLIDE 71

Reasoning over queries

Q(X,Y) :- Employee(X), Works-for(X,Y), Manages(X,Y)

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

∀x. Manager(x) → ∀y. ¬WORKS-FOR(x, y)

(27/31)

slide-72
SLIDE 72

Reasoning over queries

Q(X,Y) :- Employee(X), Works-for(X,Y), Manages(X,Y)

AreaManager TopManager Manager Project

ProjectCode:String

Employee

PaySlipNumber:Integer Salary:Integer

{disjoint,complete}

1..⋆

Works-for

1..1 1..1

Manages

∀x. Manager(x) → ∀y. ¬WORKS-FOR(x, y)

  • INCONSISTENT QUERY!

(27/31)

slide-73
SLIDE 73

Local-as-view vs. Global-as-view

Local-as-view

  • High modularity and reusability (when a source changes, only its view definition is changed).
  • Relationships between sources can be inferred.
  • Computationally more difficult (query reformulation).

Global-as-view

  • Whenever the source changes or a new one is added, the view needs to be reconsidered.
  • Needs to understand the relationships between the sources.
  • Query processing sometimes easy (unfolding), when the ontology is very simple. Otherwise it

requires sophisticated query evaluation procedures.

(28/31)

slide-74
SLIDE 74

Possible scenarios

  • Empty ontology / very simple Ontology
  • Global-as-view
  • Local-as-view
  • Full Ontology / Integrity Constraints
  • Global-as-view
  • Local-as-view

(29/31)

slide-75
SLIDE 75

Possible scenarios

  • Empty ontology / very simple Ontology
  • Global-as-view
  • The problem reduces to standard DB technology.
  • Can not express Ontology Integration needs.
  • Not modular.
  • Local-as-view
  • Full Ontology / Integrity Constraints
  • Global-as-view
  • Local-as-view

(29/31)

slide-76
SLIDE 76

Possible scenarios

  • Empty ontology / very simple Ontology
  • Global-as-view
  • The problem reduces to standard DB technology.
  • Can not express Ontology Integration needs.
  • Not modular.
  • Local-as-view
  • “Standard” view-based query processing.
  • Can express only few Ontology Integration needs.
  • Modular.
  • Full Ontology / Integrity Constraints
  • Global-as-view
  • Local-as-view

(29/31)

slide-77
SLIDE 77

Possible scenarios

  • Empty ontology / very simple Ontology
  • Global-as-view
  • The problem reduces to standard DB technology.
  • Can not express Ontology Integration needs.
  • Not modular.
  • Local-as-view
  • “Standard” view-based query processing.
  • Can express only few Ontology Integration needs.
  • Modular.
  • Full Ontology / Integrity Constraints
  • Global-as-view
  • Requires sophisticated query evaluation procedures (involving deduction).
  • Can express Ontology Integration needs.
  • Not modular.
  • Local-as-view

(29/31)

slide-78
SLIDE 78

Possible scenarios

  • Empty ontology / very simple Ontology
  • Global-as-view
  • The problem reduces to standard DB technology.
  • Can not express Ontology Integration needs.
  • Not modular.
  • Local-as-view
  • “Standard” view-based query processing.
  • Can express only few Ontology Integration needs.
  • Modular.
  • Full Ontology / Integrity Constraints
  • Global-as-view
  • Requires sophisticated query evaluation procedures (involving deduction).
  • Can express Ontology Integration needs.
  • Not modular.
  • Local-as-view
  • View-based query processing under constraints.
  • Can express Ontology Integration needs.
  • Modular.

(29/31)

slide-79
SLIDE 79

Current Practice

  • Most implemented ontology based systems:

(30/31)

slide-80
SLIDE 80

Current Practice

  • Most implemented ontology based systems:
  • either assume no Ontology or a very simple Ontology with a

global-as-view approach,

(30/31)

slide-81
SLIDE 81

Current Practice

  • Most implemented ontology based systems:
  • either assume no Ontology or a very simple Ontology with a

global-as-view approach,

  • or include an Ontology or Integrity Constraints in their framework, but

adopt a naive query evaluation procedure, based on query unfolding: no correctness of the query answering can be proved.

(30/31)

slide-82
SLIDE 82

Conclusions

Made with L

AT

EX

(31/31)

slide-83
SLIDE 83

Conclusions

Do you have an ontology in your application?

Made with L

AT

EX

(31/31)

slide-84
SLIDE 84

Conclusions

Do you have an ontology in your application? Pay attention!

Made with L

AT

EX

(31/31)