Knowledge Graphs (KGs) have been gaining momentum recently in both academia and industry, due to the flexibility of their data model, allowing one to access and integrate collections of data of diferent forms. Virtual Knowledge Graphs (VKGs), a variant of KGs originating from the field of Ontology-based Data Access (OBDA), are a promising paradigm for integrating and accessing legacy data sources. The main idea of VKGs is that the KG remains virtual: the end-user interacts with a KG, but queries are reformulated on-the-fly as queries over the data source(s). To enable the paradigm, one needs to define declarative mappings specifying the link between the data sources and the elements in the VKG. In this work, we try to investigate common patterns that arise when specifying such mappings, building on well-established methodologies from the area of conceptual modeling and database design.
zations. In the whole spectrum of data integration and access solutions, the approach based on
Virtual Knowledge Graphs (VKGs) is gaining momentum, especially when the underlying data
sources to be integrated come in the form of relational databases (DBs) [
DB Design
Conceptual Model
(E-R) VKG Mappings
OWL Encoding
OWL 2 QL DB Ontology
Alignment Mappings
OWL 2 QL Target Ontology patterns that emerge when linking data to ontologies. Our catalog is based on the (somehow reasonable) assumption that both the ontology and the DB schema are derived from a conceptual analysis of the domain of interest. The resulting knowledge may stay implicit, or may lead to an explicit representation in the form of a structural conceptual model, which can be represented using well-established notations such as UML, ORM, or E-R. On the one hand, this conceptual model provides the basis for creating a corresponding domain ontology through a series of semantic-preserving transformation steps. On the other hand, it can trigger the design process that finally leads to the deployment of an actual DB. The whole view is depicted in Figure 1.
ment (e.g., W3C direct mappings (W3C-DM)1 and extensions), data analysis (e.g., algorithms for discovering dependencies), and conceptual modeling (e.g., relational mapping techniques).
The idea of mapping patterns is not new. For instance, work in [
We argue that this foundational grounding paves the way for a variety of VKG design scenarios,
depending on which information artifacts are available, and which ones must be produced. For
example, our patterns could be used to validate existing mappings, or to automatically generate
(i.e., bootstrap) ontology and mappings when only the DB is available. In fact, specific patterns
have been proposed also in relation to ontology and mapping bootstrapping, for which a variety of
tools and approaches have been developed in the last two decades [
closely follow W3C-DM, deriving ontologies that mirror the structure of the input DB.
basic notions on VKGs, Section 3 presents (an extract of) our catalog of mapping patterns, and
ambiguous, we treat tuples as sets and use set operators on them. We assume familiarity with
standard notions and languages from DBs [
A VKG specification is a triple ⟨ , ℳ, ⟩ where is an ontology (or TBox), ℳ a set of
mappings, and the schema of a DB (with constraints, e.g., primary and foreign keys). In VKGs,
the ontology is formulated in OWL 2 QL 2, but for conciseness we use its Description Logic (DL)
counterpart, DL-Liteℛ [
NC of class names, NP of object property names, and ND of data property names.
An OWL 2 QL TBox is a finite set of inclusion axioms of the form ⊑ , ⊑ , () ⊑ , or ⊑ , where , are classes, , are object properties, is a data property, is a datatype expression, () is a data property range expression, and is a data property expression. These are defined according to the following grammar, where ∈ NC, ∈ ND, ∈ NP, () is a data property domain expression, and 1, . . . , are the RDF datatypes: → → | ∃ | () ⊤ | | ¬ → → | − | ¬ → → ⊤ | 1 | · · · | | ¬ In the rules above, ⊤ denotes the “top” element for concepts and ⊤ the one for data values (called literals in the RDF terminology). An OWL 2 QL ABox is a finite set of assertions of the form (), (, ), or (, ℓ), where ∈ NC, ∈ NP, ∈ ND, and are individuals in NI, and ℓ ∈ NL. We call the pair = ⟨ , ⟩ an OWL 2 QL Knowledge Graph (KG).
Similarly to first-order logic, the semantics of DL-Liteℛ KGs is given through Tarski-style
interpretations ℐ = ⟨Δℐ, Δℐ , · ℐ ⟩, where Δℐ is a non-empty domain of objects, Δℐ is a
nonempty domain of values, and · ℐ is an interpretation function. Table 1 reports the semantics for
the constructs involving datatypes. The other constructs are defined as in standard DL-Liteℛ [
Mappings. Mappings specify how to populate classes and properties of the ontology with
individuals and values constructed from the data in the underlying DB. In other words, mappings
provide the ABox that, together with a given TBox, realizes a KG. In VKGs, the adopted
language for mappings in real-world systems is R2RML3, but for conciseness we use here a more
convenient abstract notation inspired by the literature [
Intuitively, a template t(x) in the target atom of a mapping corresponds to an R2RML string
template4, and is used to generate an IRI (hence, an object identifier) or an RDF literal, starting
from DB values retrieved by the source query in that mapping. For the examples, we use the
concrete syntax from the Ontop VKG system [
In the mapping above, the string ex: denotes a URI prefix, e.g., ex:Person is an abbreviation for the URI http://www.example.com/Person. Such mapping, when applied to a DB instance of , populates the class ex:Person with IRIs constructed by replacing the answer variable ssn occurring in the target atom with the corresponding values assigned to that variable by the answers to the SQL source query evaluated over . For instance, if the source query returns two answers that assign to the answer variable ssn respectively the values 1234 and 5678, then the mapping above produces the following RDF graph (expressed in the Turtle syntax5), stating that individuals ex:pers/1234 and ex:pers/5678 are both instances of class ex:Person: ex:pers/1234 a ex:Person . ex:pers/5678 a ex:Person .
We denote by ℳ() the virtual ABox constructed through mappings ℳ from a DB . Given a VKG specification ⟨ , ℳ, ⟩ and a database instance of , the KG = ⟨ , ℳ()⟩ is called the Virtual Knowledge Graph of ⟨ , ℳ, ⟩ through . The qualifier “virtual” in the 3http://www.w3.org/TR/r2rml/ 4https://www.w3.org/TR/r2rml/#dfn-string-template
name derives from the fact that the virtual ABox ℳ() in a VKG setting is not materialized
and stored somewhere. Query answering in VKGs, in fact, is carried out through query rewriting
and query unfolding techniques [
In its basic form, a mapping pattern is a quadruple ⟨, , ℳ, ⟩, where is a conceptual model, a database schema, ℳ a set of mappings, and an (OWL 2 QL) ontology. In such pattern, the pair ⟨, ⟩ puts into correspondence a conceptual representation with one of its (many) admissible (i.e., formally sound [12, 13]) database schemata, like those prescribed by well-established database modeling methodologies. The pair ⟨ℳ, ⟩, instead, is formed by the DB ontology , which is the OWL 2 QL encoding7 of the conceptual model , and the set ℳ of mappings, providing the link between and . The term “DB ontology” refers to an ontology whose concepts and properties reflect the constructs of the conceptual model, mirroring the structure of the relational database, as displayed in Figure 1.
Some of the more advanced patterns have a more complex structure, where pairs of conceptual models and/or pairs of database schemata are used in place of and , respectively (e.g., the pattern “SHa” falls in this category). These patterns prescribe specific transformations to be applied to an input conceptual (resp., DB) schema, in order to obtain an output conceptual (resp., DB) schema. These output artifacts make explicit the presence of specific structures that are revealed through the application of the pattern itself. These structures can in turn enable further applications of patterns.
by the pattern in E-R notation (adopting the original notation by Chen [14]). To compactly represent sets of attributes, we use a small diamond in place of the small circle used for single attributes in Chen’s notation. For cardinality constraints we follow the “look-here” convention, that is, the cardinality constraint for a role is placed next to the entity participating in that role.
the attributes K, and additional attributes A. Given a set U of attributes in , we denote by key (U) the fact that U form a key for . Referential integrity constraints (like, e.g., foreign keys) are denoted with arcs, pointing from the referencing attribute(s) to the referenced one(s). For conciseness, we denote sets of the form { | condition} as {}condition . In order to express datatypes for data properties, we introduce two auxiliary functions: a function that, given a DB attribute , returns the DB datatype of , and a function that associates, to each DB datatype, a corresponding RDF datatype. For the definition of , we re-use the Natural Mapping8 correspondence provided by the R2RML recommendation. As a final note, following the E-Rdiagrams convention, we assume a default (1, 1) cardinality on attributes. For such a reason, in the DB schema we assume all attributes to be not nullable by default (using the SQL convention,
• In case of cardinality (_, 1) on role (resp., ), the primary key of is restricted to the attributes K (resp., K ). In case both roles have cardinality (_, 1), either choice for the primary key is made, and the remaining attributes form a non-primary key in the logical schema. • In case of cardinality (1, _) on role (resp., ), the inclusion dependency K ⊆ K (resp., K ⊆ K ) holds in the schema, and the first (resp., second) inclusion axiom in the ontology holds in both directions. Note that when the maximum cardinality on role (resp., ) is 1, the corresponding inclusion dependency is actually a foreign key.
Schema Relationship with Identifier Alignment (SRa) KE AE E KE AE E
K A R
R KE AE KE AE E F E F
KF KF
AF AF KF AF F KF UF F AF ∃ ⊑ ∃− ⊑ ∃ ⊑ ∃− ⊑ (K, A) (K , U , A ) (K, U ) key (U ) : ⋊⋉U =U : (t (K), t (K ))
Schema Hierarchy with Identifier Alignment (SHa) (K, A) key (K) (K , K, A ) (K, A) key (K ) (K , K, A ) = : : (t (K )), {(t (K ), )}∈K ∪A ⊑ ⎧ () ⊑ , ⎫ ⎨ () ⊑ ( ()), ⎬ ⎩ ⊑ () ⎭∈K ∪A In this pattern, the “alignment” is meant to align the primary identifier used in the child entity to the primary identifier used in the parent entity. The other two possiblities for applying the pattern are: • the foreign key in the child entity is the primary key of that entity, and references a non-primary key of the parent entity; • the foreign key in the child entity is a non-primary key of that entity, and references a non-primary key of the parent entity. We depict here the most common scenario, where the foreign key points to the primary key of the parent entity.
Observe that this pattern requires a change in the conceptual model (essentially keeping track of the attributes used for identifying the objects of the subclass). declared as “NOT NULL”). An optional attribute is instead denoted by adding opt() to the
Pattern Catalog.
Table 2 shows an excerpt of our patterns, which we discuss in detail here.
with a primary identifier and attributes in the DB schema, and a class and data properties in the ontology. The entity is expressed in the DB schema through a single table with primary key
explains how is mapped into a corresponding class . The primary key of is employed to construct the IRIs of the objects that are instances of , using a template t specific for that entity. Each relevant attribute of is mapped to a data property of , with suitable domain and range axioms. A mandatory participation constraint is added to each data property corresponding to a mandatory attribute.
an additional attribute, is mapped to a Client class using the SSN to construct its objects. In addition, the SSN and name are mapped to two corresponding data properties.
ship without attributes and an OWL 2 QL object property, for the case where such relationship is represented in the DB as a separate (usually, “many-to-many”) table. This pattern considers three tables , , and , for which the set of columns in is partitioned into two parts
on the role cardinalities in the E-R model. The pattern captures how is mapped to an object property , using the two parts KRE and KRF of the partition to construct respectively the subject and the object of the triples in . The templates t and t must be those respectively used for building instances of classes corresponding to and corresponding to .
has a foreign key to a table with locations. The former table is mapped to an address object property, for which the ontology asserts that the domain is the class Person and the range an additional class Location, which corresponds to the latter table.
Schema Relationship with Identifier Alignment ( SRa). This pattern is similar to pattern SR, but it comes with a modifier a, indicating that the pattern can be applied after the identifiers involved in the relationship have been aligned. The alignment is necessary because the foreign key in does not refer to the primary key K of , but to an alternative key U . Since the instances of the class corresponding to are constructed using the primary key K of (cf. pattern
which can only be retrieved via a join between and on the key U .
which are used in the table that relates clients to their addresses, but is given by the latitude and longitude of locations.
Schema Hierarchy with Identifier Alignment ( SHa). This patterns handles the case where a hierarchy is specified and the child entity uses a primary identifier diferent from the one in the parent entity. In this situation, the foreign-key constraint can come in three diferent variants.
have to be built out of KFE , rather than out of the primary key of . For this purpose, the pattern creates a view identical to , except that KFE is the primary key. Also the foreign key relations are preserved. Such view might enable further applications of patterns.
their matriculation number, whereas persons are identified by their SSN.
when linking DBs to ontologies in a typical VKG setting. Our patterns are grounded in wellestablished practices of DB design, and render explicit the connection between the conceptual model, the DB schema, and the ontology. We envision that the organization in patterns can enable a number of relevant tasks, notably mapping bootstrapping for incomplete VKGs.
use. Regarding the former, we are currently extending this initial catalog with more advanced “data-driven” patterns, which are patterns where the data component needs to be taken into account. Regarding the latter, we are investigating solutions to specific problems that need to be addressed when setting-up a VKG scenario, like the problem of mapping bootstrapping.
[12] R. Hull, Relative information capacity of simple relational database schemas, SIAM J. on
Computing 15 (1986) 856–886. [13] R. J. Miller, Y. E. Ioannidis, R. Ramakrishnan, Schema equivalence in heterogeneous systems: Bridging theory and practice, Information Systems 19 (1994) 3–31. [14] P. P. Chen, The Entity-Relationship model: Toward a unified view of data, ACM TODS 1 (1976) 9–36.