The document is a lecture on ontologies and databases given by Enrico Franconi. Some key points: - An ontology is a formal conceptualization of a domain that specifies a set of constraints that define what must be true in any possible world. - Ontology languages can range from simple to logic-based and are often expressed using diagrams. Conceptual data models like ER diagrams and UML class diagrams can also function as ontology languages. - When querying a database via an ontology, the ontology acts as a mediator between the conceptual schema, logical schema, and data store. Deduction is used to infer additional constraints from what is specified in the ontology. - Query answering over an ontology

1. Ontologies and
Databases
Enrico Franconi
Free University of Bozen-Bolzano, Italy
http://www.inf.unibz.it/∼franconi
Kalamaki, 22 May 2012
KRDB Research Centre
for Knowledge and Data

2. Summary
◮
What is an Ontology
◮
Querying a DB via an ontology
Ontologies and Databases.
E. Franconi.
(2/38)

3. Ontologies and Constraints
◮
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
ontology.
◮
Given an ontology, a legal world description (or legal database
instance) is a finite possible world satisfying the constraints.
Ontologies and Databases.
E. Franconi.
(3/38)

4. Ontologies 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., involving only concepts and
taxonomies), frame-based (e.g., UML, based on concepts, properties,
and binary relationships), or logic-based (e.g. OWL, Description
Logics).
◮
Ontology languages are typically expressed by means of diagrams.
◮
Entity-Relationship schemas and UML class diagrams can be
considered as ontology languages.
Ontologies and Databases.
E. Franconi.
(4/38)

5. UML Class Diagram
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for
1..⋆
Project
Manager
ProjectCode:String
1..1
{disjoint,complete}
AreaManager
Manages
TopManager
1..1
Ontologies and Databases.
E. Franconi.
(5/38)

6. Entity-Relationship Schema
PaySlipNumber(Integer)
Salary(Integer)
Employee
Works-for
(1,n)
Manager
Project
×
AreaManager
ProjectCode(String)
(1,1)
TopManager
(1,1)
Manages
2
Ontologies and Databases.
E. Franconi.
(6/38)

7. The role of an ontology:
an Ontology based application
Conceptual
Schema
Logical
Schema
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

8. The role of an ontology:
an Ontology based application
Constraints
Conceptual
Schema
Logical
Schema
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

9. The role of an ontology:
an Ontology based application
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

10. The role of an ontology:
an Ontology based application
Deduction
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

11. The role of an ontology:
an Ontology based application
Deduction
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

12. The role of an ontology:
an Ontology based application
Deduction
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

13. The role of an ontology:
an Ontology based application
Deduction
Constraints
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

14. The role of an ontology:
an Ontology based application
Deduction
Deduction
Constraints
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

15. The role of an ontology:
an Ontology based application
Deduction
Deduction
Constraints
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

16. The role of an ontology:
an Ontology based application
Mediator
Deduction
Deduction
Constraints
global
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
source
Data Store
Ontologies and Databases.
E. Franconi.
(7/38)

17. The role of an ontology:
an Ontology based application
Mediator
Deduction
Deduction
Constraints
global
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
← Knowledge Level
−
← Information Level
−
source
Data Store
Ontologies and Databases.
← Data Level
−
E. Franconi.
(7/38)

18. Reasoning
Given an ontology – seen as a collection of constraints – it is possible that
additional constraints can be inferred.
◮
A class is inconsistent if it denotes the empty set in any legal world
description.
◮
A class is a subclass of another class if the former denotes a subset of
the set denoted by the latter in any legal world description.
◮
Two classes are equivalent if they denote the same set in any legal
world description.
◮
A stricter constraint is inferred – e.g., a cardinality constraint – if it
holds in in any legal world description.
◮
...
Ontologies and Databases.
E. Franconi.
(8/38)

19. Simple reasoning example
Person
{disjoint}
Italian
English
{disjoint,covering}
Lazy
Ontologies and Databases.
LatinLover
Gentleman
E. Franconi.
Hooligan
(9/38)

20. Simple reasoning example
Person
{disjoint}
Italian
English
{disjoint,covering}
Lazy
LatinLover
Gentleman
Hooligan
LatinLover = ∅
Italian ⊆ Lazy
Italian ≡ Lazy
Ontologies and Databases.
E. Franconi.
(9/38)

21. Reasoning: cute professors
Italian
{disjoint,complete}
Lazy
Mafioso
LatinLover
ItalianProf
{disjoint}
Ontologies and Databases.
E. Franconi.
(10/38)

22. Reasoning: cute professors
Italian
{disjoint,complete}
Lazy
Mafioso
LatinLover
ItalianProf
{disjoint}
implies
ItalianProf ⊆ LatinLover
Ontologies and Databases.
E. Franconi.
(10/38)

23. Reasoning with ontologies
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for
1..⋆
Project
Manager
ProjectCode:String
1..1
{disjoint,complete}
AreaManager
Manages
TopManager
1..1
◮
Managers do not work for a project (she/he just manages it):
∀x. Manager(x) → ¬∃y . WORKS-FOR(x, y )
Manager ⊑ ¬∃WORKS-FOR. ⊤
Manager ⊆ Employee π1 WORKS-FOR
Ontologies and Databases.
E. Franconi.
(11/38)

24. Reasoning with ontologies
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for
1..⋆
1..⋆
Project
Manager
ProjectCode:String
1..1
{disjoint,complete}
AreaManager
Manages
TopManager
1..1
◮
Managers do not work for a project (she/he just manages it):
∀x. Manager(x) → ¬∃y . WORKS-FOR(x, y )
Manager ⊑ ¬∃WORKS-FOR. ⊤
Manager ⊆ Employee π1 WORKS-FOR
◮
If the minimum cardinality for the participation of employees to the
works-for relationship is increased, then . . .
Ontologies and Databases.
E. Franconi.
(11/38)

25. The democratic company
Supervisor
2..2
supervises
Employee
0..1
Ontologies and Databases.
Employee = ∅
E. Franconi.
(12/38)

26. The democratic company
Supervisor
2..2
supervises
Employee
0..1
Employee = ∅
implies
“the classes Employee and Supervisor necessarily contain an infinite
number of instances”.
Since legal world descriptions are finite possible worlds satisfying the
constraints imposed by the ontology, the ontology is inconsistent.
Ontologies and Databases.
E. Franconi.
(12/38)

27. How many numbers?
Natural Number
1..1
rel
Even Number
1..1
Ontologies and Databases.
E. Franconi.
(13/38)

28. How many numbers?
Natural Number
1..1
rel
Even Number
1..1
implies
“the classes Natural Number and Even Number contain the same number
of instances”.
Ontologies and Databases.
E. Franconi.
(13/38)

29. How many numbers?
Natural Number
1..1
rel
Even Number
1..1
implies
“the classes Natural Number and Even Number contain the same number
of instances”.
Only if the domain is finite:
Ontologies and Databases.
Natural Number ≡ Even Number
E. Franconi.
(13/38)

30. Next on “Ontologies and Databases”:
◮
◮
What is an Ontology
Querying a DB via an ontology
◮
◮
◮
◮
◮
◮
We will see how an ontology can play the role of a “mediator”
wrapping a (source) database.
Examples will show how apparently simple cases are not easy.
We will learn about view-based query processing with GAV and LAV
mappings.
We introduce the difference between closed world and open world
semantics in this context.
We will see how only the closed world semantics should be used while
using ontologies to wrap databases, in order for the mediated system to
behave like a database (black-box metaphor)
We will see that the data complexity of query answering can be beyond
the one of SQL.
Ontologies and Databases.
E. Franconi.
(14/38)

31. The role of an ontology
Conceptual
Schema
Logical
Schema
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

32. The role of an ontology
Constraints
Conceptual
Schema
Logical
Schema
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

33. The role of an ontology
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

34. The role of an ontology
Deduction
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

35. The role of an ontology
Deduction
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

36. The role of an ontology
Deduction
Constraints
Conceptual
Schema
Logical
Schema
Query
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

37. The role of an ontology
Deduction
Constraints
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

38. The role of an ontology
Deduction
Deduction
Constraints
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

39. The role of an ontology
Deduction
Deduction
Constraints
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

40. The role of an ontology
Mediator
Deduction
Deduction
Constraints
global
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
source
Data Store
Ontologies and Databases.
E. Franconi.
(15/38)

41. The role of an ontology
Mediator
Deduction
Deduction
Constraints
global
Conceptual
Schema
Query
Logical
Schema
Query
Result
Result
← Knowledge Level
−
← Information Level
−
source
Data Store
Ontologies and Databases.
← Data Level
−
E. Franconi.
(15/38)

42. Querying a Database with Constraints
◮
Basic assumption: consistent information with respect to the
constraints introduced by the ontology
◮
A Database with Constraints: complete information about each term
appearing in the ontology
◮
Problem: answer a query over the ontology vocabulary
Ontologies and Databases.
E. Franconi.
(16/38)

43. Querying a Database with Constraints
◮
Basic assumption: consistent information with respect to the
constraints introduced by the ontology
◮
A Database with Constraints: complete information about each term
appearing in the ontology
◮
Problem: answer a query over the ontology vocabulary
◮
Solution: use a standard DB technology (e.g., SQL, datalog, etc)
Ontologies and Databases.
E. Franconi.
(16/38)

44. Querying a Database with Constraints
Employee
Works-for
1..⋆
Project
Manager
Ontologies and Databases.
E. Franconi.
(17/38)

45. Querying a Database with Constraints
Employee
Works-for
1..⋆
Project
Manager
Employee = { John, Mary, Paul }
Manager = { John, Paul }
Works-for = { John,Prj-A , Mary,Prj-B }
Project = { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(17/38)

46. Querying a Database with Constraints
Employee
Works-for
1..⋆
Project
Manager
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 }
Ontologies and Databases.
E. Franconi.
(17/38)

47. Querying a Database with Constraints
over an extended vocabulary (DBox)
◮
Having a classical database with constraints is against the principle
that an ontology presents a richer vocabulary than the data stores
(i.e., it plays the role of an ontology).
Ontologies and Databases.
E. Franconi.
(18/38)

48. Querying a Database with Constraints
over an extended vocabulary (DBox)
◮
Having a classical database with constraints is against the principle
that an ontology presents a richer vocabulary than the data stores
(i.e., it plays the role of an ontology).
◮
A Database with Constraints over an extended vocabulary (or
conceptual schema with exact views, or DBox): 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
Ontologies and Databases.
E. Franconi.
(18/38)

49. Querying a Database with Constraints
over an extended vocabulary (DBox)
Employee
Works-for
1..⋆
Project
Manager
Manager = { John, Paul }
Works-for = { John,Prj-A , Mary,Prj-B }
Project = { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(19/38)

50. Querying a Database with Constraints
over an extended vocabulary (DBox)
Employee
Works-for
1..⋆
Project
Manager
Manager = { John, Paul }
Works-for = { John,Prj-A , Mary,Prj-B }
Project = { Prj-A, Prj-B }
Q(X) :- Employee(X)
Ontologies and Databases.
E. Franconi.
(19/38)

51. Querying a Database with Constraints
over an extended vocabulary (DBox)
Employee
Works-for
1..⋆
Project
Manager
Manager = { John, Paul }
Works-for = { John,Prj-A , Mary,Prj-B }
Project = { Prj-A, Prj-B }
Q(X) :- Employee(X)
=⇒ { John, Paul, Mary }
Ontologies and Databases.
E. Franconi.
(19/38)

52. Querying a Database with Constraints
over an extended vocabulary (DBox)
Employee
Works-for
1..⋆
Project
Manager
Manager = { John, Paul }
Works-for = { John,Prj-A , Mary,Prj-B }
Project = { Prj-A, Prj-B }
Q(X) :- Employee(X)
=⇒ { John, Paul, Mary }
=⇒
Q’(X) :- Manager(X) ∪ Works-for(X,Y)
Ontologies and Databases.
E. Franconi.
(19/38)

53. Andrea’s Example
Friend
Employee
Supervised
Manager
{disjoint,complete}
AreaManager
TopManager
AreaManagerp
TopManagerp
Ontologies and Databases.
E. Franconi.
(20/38)

54. Andrea’s Example
Friend
Employee
Supervised
Employee = { Andrea, Paul, Mary, John }
Manager = { Andrea, Paul, Mary}
AreaManagerp = { Paul }
TopManagerp = { Mary }
Supervised = { John,Andrea , John,Mary }
Friend = { Mary,Andrea , Andrea,Paul }
Manager
{disjoint,complete}
AreaManager
TopManager
AreaManagerp
TopManagerp
Ontologies and Databases.
E. Franconi.
(20/38)

55. Andrea’s Example
Friend
Employee
Supervised
Employee = { Andrea, Paul, Mary, John }
Manager = { Andrea, Paul, Mary}
AreaManagerp = { Paul }
TopManagerp = { Mary }
Supervised = { John,Andrea , John,Mary }
Friend = { Mary,Andrea , Andrea,Paul }
Manager
John
{disjoint,complete}
Supervised
✠
AreaManager
TopManager
Andrea:Manager
❅
❅ Supervised
❅
❘
❅
✛Friend Mary:TopManagerp
Friend
❄
Paul:AreaManagerp
AreaManagerp
Ontologies and Databases.
TopManagerp
E. Franconi.
(20/38)

56. Andrea’s Example (cont.)
Friend
Employee
Supervised
Manager
{disjoint,complete}
AreaManager
TopManager
AreaManagerp
TopManagerp
Ontologies and Databases.
E. Franconi.
(21/38)

57. Andrea’s Example (cont.)
Friend
John
Employee
Supervised
✠
Supervised
Manager
Andrea:Manager
❅
❅ Supervised
❅
❘
❅
✛Friend Mary:TopManagerp
Friend
❄
{disjoint,complete}
AreaManager
TopManager
AreaManagerp
Paul:AreaManagerp
TopManagerp
Ontologies and Databases.
E. Franconi.
(21/38)

58. Andrea’s Example (cont.)
Friend
John
Employee
Supervised
✠
Supervised
Manager
Andrea:Manager
❅
❅ Supervised
❅
❘
❅
✛Friend Mary:TopManagerp
Friend
❄
{disjoint,complete}
AreaManager
TopManager
AreaManagerp
Paul:AreaManagerp
Q :- Supervised(John,Y), TopManager(Y),
Friend(Y,Z), AreaManager(Z)
TopManagerp
Ontologies and Databases.
E. Franconi.
(21/38)

59. Andrea’s Example (cont.)
Friend
John
Employee
Supervised
✠
Supervised
Manager
Andrea:Manager
❅
❅ Supervised
❅
❘
❅
✛Friend Mary:TopManagerp
Friend
❄
{disjoint,complete}
AreaManager
TopManager
Paul:AreaManagerp
Q :- Supervised(John,Y), TopManager(Y),
Friend(Y,Z), AreaManager(Z)
=⇒ YES
AreaManagerp
Ontologies and Databases.
TopManagerp
E. Franconi.
(21/38)

60. Querying a sound DB with Constraints
over an extended vocabulary (ABox)
1. Classical DB with constraints: complete information about all terms
appearing in the ontology
2. DB with constraints over an extended vocabulary (i.e., conceptual
schema with exact views, or DBox): complete information about
some term appearing in the ontology
3. Sound DB with constraints over an extended vocabulary (aka
conceptual schema with sound views, or ABox): incomplete
information about some term appearing in the ontology
◮
Sound databases with constraints over an extended vocabulary are
crucial in data integration scenarios.
Ontologies and Databases.
E. Franconi.
(22/38)

61. Exact vs Sound views
Employee
Ontologies and Databases.
Works-for
1..⋆
Project
E. Franconi.
(23/38)

62. Exact vs Sound views
Employee
Works-for
1..⋆
Project
Exact views (DBox):
Works-for = { John,Prj-A , Mary,Prj-A }
Project = { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(23/38)

63. Exact vs Sound views
Employee
Works-for
1..⋆
Project
Exact views (DBox):
Works-for = { John,Prj-A , Mary,Prj-A }
Project = { Prj-A, Prj-B }
=⇒
INCONSISTENT
Ontologies and Databases.
E. Franconi.
(23/38)

64. Exact vs Sound views
Employee
Works-for
1..⋆
Project
Exact views (DBox):
Works-for = { John,Prj-A , Mary,Prj-A }
Project = { Prj-A, Prj-B }
=⇒
INCONSISTENT
Sound views (ABox):
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(23/38)

65. Querying a sound DB with Constraints
over an extended vocabulary (ABox)
Employee
Works-for
1..⋆
Project
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(24/38)

66. Querying a sound DB with Constraints
over an extended vocabulary (ABox)
Employee
Works-for
1..⋆
Project
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Q(X) :- Works-for(Y,X)
Ontologies and Databases.
E. Franconi.
(24/38)

67. Querying a sound DB with Constraints
over an extended vocabulary (ABox)
Employee
Works-for
1..⋆
Project
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Q(X) :- Works-for(Y,X)
=⇒ { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(24/38)

68. Querying a sound DB with Constraints
over an extended vocabulary (ABox)
Employee
Works-for
1..⋆
Project
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Q(X) :- Works-for(Y,X)
=⇒ { Prj-A, Prj-B }
=⇒
Q’(X) :- Project(X) ∪ Works-for(Y,X)
Ontologies and Databases.
E. Franconi.
(24/38)

69. DBox vs ABox
Employee
◮
Works-for
Project
Additional constraint as a standard view over the data:
Bad-Project = Project π2 Works-for
∀x. Bad-Project(x)↔ Project(x)∧¬∃y.Works-for(y,x)
Bad-Project = Project⊓¬∃Works-for−.⊤
Ontologies and Databases.
E. Franconi.
(25/38)

70. DBox vs ABox
Employee
◮
◮
◮
◮
◮
Works-for
Project
Additional constraint as a standard view over the data:
Bad-Project = Project π2 Works-for
∀x. Bad-Project(x)↔ Project(x)∧¬∃y.Works-for(y,x)
Bad-Project = Project⊓¬∃Works-for−.⊤
DBox:
Works-for = { John,Prj-A , Mary,Prj-A }
Project = { Prj-A, Prj-B }
Q(X) :- Bad-Project(X)
ABox:
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Q(X) :- Bad-Project(X)
Ontologies and Databases.
E. Franconi.
(25/38)

71. DBox vs ABox
Employee
◮
◮
◮
◮
◮
Works-for
Project
Additional constraint as a standard view over the data:
Bad-Project = Project π2 Works-for
∀x. Bad-Project(x)↔ Project(x)∧¬∃y.Works-for(y,x)
Bad-Project = Project⊓¬∃Works-for−.⊤
DBox:
Works-for = { John,Prj-A , Mary,Prj-A }
Project = { Prj-A, Prj-B }
Q(X) :- Bad-Project(X)
=⇒ { Prj-B }
ABox:
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Q(X) :- Bad-Project(X)
Ontologies and Databases.
E. Franconi.
(25/38)

72. DBox vs ABox
Employee
◮
◮
◮
◮
◮
Works-for
Project
Additional constraint as a standard view over the data:
Bad-Project = Project π2 Works-for
∀x. Bad-Project(x)↔ Project(x)∧¬∃y.Works-for(y,x)
Bad-Project = Project⊓¬∃Works-for−.⊤
DBox:
Works-for = { John,Prj-A , Mary,Prj-A }
Project = { Prj-A, Prj-B }
Q(X) :- Bad-Project(X)
=⇒ { Prj-B }
ABox:
Works-for ⊇ { John,Prj-A , Mary,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Q(X) :- Bad-Project(X)
=⇒ { }
does not scale down to standard DB answer!
Ontologies and Databases.
E. Franconi.
(25/38)

73. Compositionality of Queries
Employee
◮
Works-for
1..⋆
Project
ABox:
Works-for ⊇ { John,Prj-A }
Project ⊇ { Prj-A, Prj-B }
Ontologies and Databases.
E. Franconi.
(26/38)

74. Compositionality of Queries
Employee
Works-for
1..⋆
Project
◮
ABox:
Works-for ⊇ { John,Prj-A }
Project ⊇ { Prj-A, Prj-B }
◮
Query as a standard view over the data:
Q(X) :- Works-for(Y,X)
Ontologies and Databases.
Q =
π Works-for
2
E. Franconi.
(26/38)

75. Compositionality of Queries
Employee
Works-for
1..⋆
Project
◮
ABox:
Works-for ⊇ { John,Prj-A }
Project ⊇ { Prj-A, Prj-B }
◮
Query as a standard view over the data:
Q(X) :- Works-for(Y,X)
Q =
π Works-for
2
π Works-for)
◮
Q = EVAL(
◮
Q =
Ontologies and Databases.
2
π (EVAL(Works-for))
2
E. Franconi.
(26/38)

76. Compositionality of Queries
Employee
Works-for
1..⋆
Project
◮
ABox:
Works-for ⊇ { John,Prj-A }
Project ⊇ { Prj-A, Prj-B }
◮
Query as a standard view over the data:
Q(X) :- Works-for(Y,X)
Q =
π Works-for
2
π
◮
Q = EVAL( 2 Works-for)
=⇒ { Prj-A, Prj-B }
◮
Q =
Ontologies and Databases.
π (EVAL(Works-for))
2
E. Franconi.
(26/38)

77. Compositionality of Queries
Employee
Works-for
1..⋆
Project
◮
ABox:
Works-for ⊇ { John,Prj-A }
Project ⊇ { Prj-A, Prj-B }
◮
Query as a standard view over the data:
Q(X) :- Works-for(Y,X)
Q =
π Works-for
2
π
◮
Q = EVAL( 2 Works-for)
=⇒ { Prj-A, Prj-B }
◮
Q = 2 (EVAL(Works-for))
=⇒ { Prj-A }
π
Queries are not compositional wrt certain answer semantics!
Ontologies and Databases.
E. Franconi.
(26/38)

78. Complexity of Query answering
has-border
Region
◮
1..⋆
has-colour
Colour
DBox:
Region = {Italy,France,. . .}; has-border = { Italy,France ,. . .};
Colour = { Red, Green, Blue }
Ontologies and Databases.
E. Franconi.
(27/38)

79. Complexity of Query answering
has-border
Region
◮
◮
1..⋆
has-colour
Colour
DBox:
Region = {Italy,France,. . .}; has-border = { Italy,France ,. . .};
Colour = { Red, Green, Blue }
Q :- has-colour(R1,C), has-colour(R2,C), has-border(R1,R2)
Is it unavoidable that there are two adjacent regions with the same colour?
Ontologies and Databases.
E. Franconi.
(27/38)

80. Complexity of Query answering
has-border
Region
◮
◮
1..⋆
has-colour
Colour
DBox:
Region = {Italy,France,. . .}; has-border = { Italy,France ,. . .};
Colour = { Red, Green, Blue }
Q :- has-colour(R1,C), has-colour(R2,C), has-border(R1,R2)
Is it unavoidable that there are two adjacent regions with the same colour?
◮ YES: in any legal database (i.e., an assignment of colours to regions)
there are at least two adjacent regions with the same colour.
Ontologies and Databases.
E. Franconi.
(27/38)

81. Complexity of Query answering
has-border
Region
◮
◮
1..⋆
has-colour
Colour
DBox:
Region = {Italy,France,. . .}; has-border = { Italy,France ,. . .};
Colour = { Red, Green, Blue }
Q :- has-colour(R1,C), has-colour(R2,C), has-border(R1,R2)
Is it unavoidable that there are two adjacent regions with the same colour?
◮ YES: in any legal database (i.e., an assignment of colours to regions)
there are at least two adjacent regions with the same colour.
◮ NO: there is at least a legal database (i.e., an assignment of colours to
regions) in which no two adjacent regions have the same colour.
Ontologies and Databases.
E. Franconi.
(27/38)

82. Complexity of Query answering
has-border
Region
◮
◮
1..⋆
has-colour
Colour
DBox:
Region = {Italy,France,. . .}; has-border = { Italy,France ,. . .};
Colour = { Red, Green, Blue }
Q :- has-colour(R1,C), has-colour(R2,C), has-border(R1,R2)
Is it unavoidable that there are two adjacent regions with the same colour?
◮ YES: in any legal database (i.e., an assignment of colours to regions)
there are at least two adjacent regions with the same colour.
◮ NO: there is at least a legal database (i.e., an assignment of colours to
regions) in which no two adjacent regions have the same colour.
◮ With ABox semantics the answer is always NO, since there is at least a
legal database (i.e., an assignment of colours to regions) with enough
distinct colours so that no two adjacent regions have the same colour.
Ontologies and Databases.
E. Franconi.
(27/38)

83. Complexity of Query answering
has-border
Region
◮
◮
1..⋆
has-colour
Colour
DBox:
Region = {Italy,France,. . .}; has-border = { Italy,France ,. . .};
Colour = { Red, Green, Blue }
Q :- has-colour(R1,C), has-colour(R2,C), has-border(R1,R2)
Is it unavoidable that there are two adjacent regions with the same colour?
◮ YES: in any legal database (i.e., an assignment of colours to regions)
there are at least two adjacent regions with the same colour.
◮ NO: there is at least a legal database (i.e., an assignment of colours to
regions) in which no two adjacent regions have the same colour.
◮ With ABox semantics the answer is always NO, since there is at least a
legal database (i.e., an assignment of colours to regions) with enough
distinct colours so that no two adjacent regions have the same colour.
Query answering with DBoxes is co-np-hard in data complexity (3-col),
and it is strictly harder than with ABoxes!
Ontologies and Databases.
E. Franconi.
(27/38)

84. View based Query Processing
◮
Mappings between the ontology terms and the information source
terms are not necessarily atomic.
◮
Mappings can be given in terms of a set of sound (or exact) views:
◮
GAV (global-as-view ): sound (or exact) views over the information
source vocabulary are associated to terms 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 some normal form via a GAV mapping
LAV (local-as-view ): a sound or exact view over the ontology
vocabulary is associated to each term in the information source;
GLAV: mix of the above.
◮
It is non-trivial, even in the pure GAV setting - which is wrongly
believed to be computable by simple view unfolding.
◮
It is mostly studied with sound views, due to the negative complexity
results with exact views discussed before.
Ontologies and Databases.
E. Franconi.
(28/38)

85. Sound GAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
Ontologies and Databases.
E. Franconi.
(29/38)

86. Sound GAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
Ontologies and Databases.
E. Franconi.
(29/38)

87. Sound GAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
Employee(X)
:-
1-Employee(X,Y,false)
Works-for(X,Y)
:-
2-Works-for(X,Y)
Manager(X)
:-
1-Employee(X,Y,true)
Salary(X,Y)
:-
1-Employee(X,Y,Z)
Project(Y)
:-
2-Works-for(X,Y)
Ontologies and Databases.
E. Franconi.
(29/38)

88. Sound GAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
Employee(X)
:-
1-Employee(X,Y,false)
Works-for(X,Y)
:-
2-Works-for(X,Y)
Manager(X)
:-
1-Employee(X,Y,true)
Salary(X,Y)
:-
1-Employee(X,Y,Z)
Project(Y)
:-
2-Works-for(X,Y)
Q(X) :- Employee(X)
Ontologies and Databases.
E. Franconi.
(29/38)

89. Sound GAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
Employee(X)
:-
1-Employee(X,Y,false)
Works-for(X,Y)
:-
2-Works-for(X,Y)
Manager(X)
:-
1-Employee(X,Y,true)
Salary(X,Y)
:-
1-Employee(X,Y,Z)
Project(Y)
:-
2-Works-for(X,Y)
Q(X) :- Employee(X)
Q’(X) :- 1-Employee(X,Y,Z) ∪ 2-Works-for(X,W)
=⇒
Ontologies and Databases.
E. Franconi.
(29/38)

90. Sound GAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
Employee(X)
:-
1-Employee(X,Y,false)
Works-for(X,Y)
:-
2-Works-for(X,Y)
Manager(X)
:-
1-Employee(X,Y,true)
Salary(X,Y)
:-
1-Employee(X,Y,Z)
Project(Y)
:-
2-Works-for(X,Y)
Q(X) :- Employee(X)
Q’(X) :- 1-Employee(X,Y,Z) ∪ 2-Works-for(X,W)
=⇒
Ontologies and Databases.
← not coming from
unfolding!
E. Franconi.
(29/38)

91. Sound LAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
Ontologies and Databases.
E. Franconi.
(30/38)

92. Sound LAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
Ontologies and Databases.
E. Franconi.
(30/38)

93. Sound LAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
1-Employee(X,Y,Z)
:-
1-Employee(X,Y,Z)
:-
Employee(X), ¬Manager(X), Salary(X,Y), Z=false
2-Works-for(X,Y)
:-
Works-for(X,Y)
Ontologies and Databases.
Manager(X), Salary(X,Y), Z=true
E. Franconi.
(30/38)

94. Sound LAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
1-Employee(X,Y,Z)
:-
1-Employee(X,Y,Z)
:-
Manager(X), Salary(X,Y), Z=true
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)
Ontologies and Databases.
E. Franconi.
(30/38)

95. Sound LAV mapping
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for 1..⋆
Project
ProjectCode:String
Manager
1-Employee(PaySlipNumber ,Salary,ManagerP)
2-Works-for(PaySlipNumber,ProjectCode)
1-Employee(X,Y,Z)
:-
1-Employee(X,Y,Z)
:-
Manager(X), Salary(X,Y), Z=true
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)
Ontologies and Databases.
E. Franconi.
(30/38)

96. Reasoning over queries
Q(X,Y) :- Employee(X), Works-for(X,Y), Manages(X,Y)
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for
∀x. Manager(x) → ¬∃y . WORKS-FOR(x, y )
1..⋆
Project
Manager
ProjectCode:String
π1 WORKS-FOR
1..1
{disjoint,complete}
AreaManager
Manager ⊑ ¬∃WORKS-FOR. ⊤
Manager ⊆ Employee
Manages
TopManager
1..1
Ontologies and Databases.
E. Franconi.
(31/38)

97. Reasoning over queries
Q(X,Y) :- Employee(X), Works-for(X,Y), Manages(X,Y)
Employee
PaySlipNumber:Integer
Salary:Integer
Works-for
∀x. Manager(x) → ¬∃y . WORKS-FOR(x, y )
1..⋆
Project
Manager
ProjectCode:String
π1 WORKS-FOR
1..1
{disjoint,complete}
AreaManager
Manager ⊑ ¬∃WORKS-FOR. ⊤
Manager ⊆ Employee
Manages
TopManager
1..1
INCONSISTENT QUERY!
Ontologies and Databases.
E. Franconi.
(31/38)

98. Summary
◮
Logic and Conceptual Modelling
◮
Queries with an Ontology
◮
Determinacy
Ontologies and Databases.
E. Franconi.
(32/38)

99. Determinacy (implicit definability)
A query Q over a DBox is implicitly definable under constraints if its
extension is fully determined by the extension of the DBox relations, and it
does not depend on the non-DBox relations appearing in the constraints.
Checking implicit definability under first-order logic constraints of a query
over a DBox can be reduced to classical entailment.
Ontologies and Databases.
E. Franconi.
(33/38)

100. Determinacy (implicit definability)
A query Q over a DBox is implicitly definable under constraints if its
extension is fully determined by the extension of the DBox relations, and it
does not depend on the non-DBox relations appearing in the constraints.
Checking implicit definability under first-order logic constraints of a query
over a DBox can be reduced to classical entailment.
Definition (Implicit definability)
Let DBi and DBj be any two legal databases of the constraints T which
agree on the extension of the DBox relations.
A query Q is implicitly definable from the DBox relations under the
constraints T iff the answer of Q over DBi is the same as the answer of
Q over DBj .
Ontologies and Databases.
E. Franconi.
(33/38)

101. Rewriting - or explicit definability
◮
If a query is implicitly definable, it is possible to find an equivalent
reformulation of the query using only relations in the DBox. This is
its explicit definition.
◮
It has been shown that under general first-order logic constraints,
whenever a query is implicitly definable then it is explicitly definable
in a constructive way as a first-order query.
Ontologies and Databases.
E. Franconi.
(34/38)

102. Example
Employee
{disjoint,complete}
Manager
Ontologies and Databases.
Clerk
E. Franconi.
(35/38)

103. Example
Employee
{disjoint,complete}
Manager
◮
Clerk
Q(x) :- Clerk(x)
Ontologies and Databases.
is determined by the extension of the DBox
relations under the constraints
E. Franconi.
(35/38)

104. Example
Employee
{disjoint,complete}
Manager
Clerk
◮
Q(x) :- Clerk(x)
is determined by the extension of the DBox
relations under the constraints
◮
Q(x) :- Clerk(x)
is equivalent to
Q ′ (x) :- Employee(x) ∧ ¬Manager(x)
Ontologies and Databases.
E. Franconi.
(35/38)

105. The query rewriting under constraints
process
1. Check whether the database is consistent with respect to the
constraints and, if so,
2. check whether the answer to the original query under first-order
constraints is solely determined by the extension of the DBox
relations and, if so,
3. find an equivalent (first-order) rewriting of the query in terms of the
DBox relation.
4. It is possible to pre-compute all the rewritings of all the determined
relations as SQL relational views, and to allow arbitrary SQL queries
on top of them: the whole system is deployed at run time as a
standard SQL relational database.
Ontologies and Databases.
E. Franconi.
(36/38)

106. Domain independence & range-restricted
rewritings
I cheated so far!
Ontologies and Databases.
E. Franconi.
(37/38)

107. Domain independence & range-restricted
rewritings
I cheated so far!
Unless the rewriting is a domain independent (e.g., a range-restricted)
first-order logic formula, it can not be expressed in relational algebra or
SQL!
Ontologies and Databases.
E. Franconi.
(37/38)

108. Domain independence & range-restricted
rewritings
I cheated so far!
Unless the rewriting is a domain independent (e.g., a range-restricted)
first-order logic formula, it can not be expressed in relational algebra or
SQL!
◮
We prove general conditions on the constraints and the query in order
to guarantee that the rewriting is domain independent
◮
All the typical database constraints (e.g., TGDs and EGDs) satisfy
those conditions
◮
All the ontology languages in the guarded fragment satisfy those
conditions
Ontologies and Databases.
E. Franconi.
(37/38)

109. Conclusions
Ontologies and Databases.
E. Franconi.
(38/38)

110. Conclusions
Do you want to exploit ontology knowledge
(i.e., constraints or an ontology)
in your data intensive application?
Ontologies and Databases.
E. Franconi.
(38/38)

111. Conclusions
Do you want to exploit ontology knowledge
(i.e., constraints or an ontology)
in your data intensive application?
Pay attention!
TURGIA
Ontologies and Databases.
A
Made with L TEX2e
E. Franconi.
(38/38)