Keywords: Data Exchange, Shapes Schema, Certain Query Answering, Consistency, Visual Mapping Language, Schema Elicitation

Resource Description Framework (RDF) is a graph data model which has recently found the use of publishing on the web data from relational databases. We investigate data exchange from relational databases to RDF graphs with target shapes schemas. Essentially, data exchange models a process of transforming an instance of a relational schema, called the source schema, to a RDF graph constrained by a target schema, according to a set of rules, called source-to-target tuple generating dependencies. The output RDF graph is called a solution. Because the tuple generating dependencies define this process in a declarative fashion, there might be many possible solutions or no solution at all. We study constructive relational to RDF data exchange setting with target shapes schemas, which is composed of a relational source schema, a shapes schema for the target schema, a set of mappings that uses IRI constructors. Furthermore, we assume that any two IRI constructors are non-overlapping.

We propose a visual mapping language (VML) that helps non-expert users to specify mappings in this setting. Moreover, we develop a tool called ShERML that performs data exchange with the use of VML and for users that want to understand the model behind VML mappings, we define R2VML, a text-based mapping language, that captures VML and presents a succinct syntax for defining mappings.

We investigate the problem of checking consistency: a data exchange setting is con-target schema, which are soundness i.e., every produced RDF graph is accepted by the target schema; and completeness i.e., every RDF graph accepted by the target schema can be produced. We propose an elicitation algorithm that is sound for any schema-less data exchange setting, but also that is complete for a large practical class of schema-less settings.

sistent if for every input source instance, there is at least one solution. We show that the consistency problem is coNP-complete and provide a static analysis algorithm of the setting that allows to decide if the setting is consistent or not.

We study the problem of computing certain answers. An answer is certain if the answer holds in every solution. Typically, certain answers are computed using a universal solution. However, in our setting a universal solution might not exist. Thus, we introduce the notion of universal simulation solution, which always exists and allows to compute certain answers to any class of queries that is robust under simulation. One such class is nested regular expressions (NREs) that are forward i.e., do not use the inverse operation. Using universal simulation solution renders tractable the computation of certain answers to forward NREs (data-complexity).

Finally, we investigate the shapes schema elicitation problem that consists of constructing a target shapes schema from a constructive relational to RDF data exchange setting without the target shapes schema. We identity two desirable properties of a good R ésum é: Resource Description Framework (RDF) est un modèle de graphe utilisé pour publier des données sur le Web à partir de bases de données relationnelles. Nous étudions l'échange de données depuis des bases de données relationnelles vers des graphes RDF avec des schémas de formes cibles. Essentiellement, échange de données modélise un processus de transformation d'une instance d'un schéma relationnel, appelé schéma source, en un graphe RDF contraint par un schéma cible, selon un ensemble de règles, appelé tuple source-cible générant des dépendances. Le graphe RDF obtenu est appelé une solution. Étant donné que les dépendances générant des tuple définissent ce processus de manière déclarative, il peut y avoir de nombreuses solutions possibles ou aucune solution du tout. Nous étudions le système d'échange de données relationnel avec RDF constructive avec des schémas de formes cibles, qui est composé d'un schéma source relationnel, un schéma de formes pour le schéma cible, un ensemble de mappages utilisant des constructeurs IRI. De plus, nous supposons que deux constructeurs IRI ne se chevauchent pas.

Nous proposons un langage visuel pour l'spécification des correspondances (VML) qui aide les utilisateurs non experts à spécifier des mappages dans ce système. De plus, nous développons un outil appelé ShERML qui effectue l'échange de données avec l'utilisation de VML et pour les utilisateurs qui souhaitent comprendre le modèle derrière les mappages VML, nous définissons R2VML, un langage texte, qui capture VML et présente une syntaxe succincte pour définition des mappages.

Nous étudions le problème de la vérification de la consistance: un système d'échange de données est consistent si pour chaque instance de source d'entrée, il existe au moins une solution. Nous montrons que le problème de consistance est coNP-complet et fournissons un algorithme d'analyse statique du système qui permet de décider si le système est consistent ou non. Mots-clés: Échange de données, schéma de formes, calcul des réponses certaines, consistance, langage visuel pour la spécification des correspondances, extraction de schéma

Introduction Motivation

Resource Description Framework (RDF) [START_REF] Lassila | Resource Description Framework (RDF) Model and Syntax Specification[END_REF]] is a well-established format that finds usage as data exchange language between web applications [Baker et al. 2012]. In many of these web applications, the data is exported from relational databases as evidenced by the proliferation of languages for mapping relational databases to RDF, such as R2RML [START_REF] Das | Souripriya Das, Seema Sundara and Richard Cyganiak[END_REF], direct mapping (DM) [START_REF] Arenas | [END_REF] or YARRRML [Heyvaert et al. 2018] .

Take for instance R2RML [START_REF] Das | Souripriya Das, Seema Sundara and Richard Cyganiak[END_REF], which is a declarative mapping language recommended by W3C that allows the customization of what information from a relational database is relevant to be exported to RDF. As an example, consider the two following R2RML mappings, themselves in RDF format presented in Turtle syntax, exporting data about employees and departments from a relational database to RDF.

CONTENTS

In general, R2RML maps data from relational tables or query outputs and produces set of triples using templates for subjects, explicitly stated predicate names, and for objects either literal values coming from columns or templates. Additionally, a type for the subject can be declared. For instance, the first mapping maps data from relation Dept(did , name) into a set of triples with predicate :name. For every department, it creates a dedicated Internationalized Resource Identifier (IRI) and the class (rr:class) of each department IRI is declared as :TDept.

RDF has been originally proposed schema-less to promote its adoption but the need for schema languages for RDF has been since identified and deemed particularly important in the context of exchange of data between applications [START_REF] Gayo | [END_REF][Gayo et al. , W3C 2013]]. Having schema allows to validate RDF graphs and one of the benefits of working with data conforming to a schema is an increased execution safety: applications need not to worry about handling malformed or invalid data that could otherwise cause undesirable and difficult to predict side-effects.

One family of proposed schema formalisms for RDF is based on shape constraints.

This class includes shape constraint language (SHACL) [START_REF] Knublauch | Holger Knublauch and Dimitris Kontokostas[END_REF], Corman et al. 2018] and shape expressions schemas (ShEx) [Prud'hommeaux et al. 2018, Boneva et al. 2017, Staworko et al. 2015]. The two languages allow to define a set of types that impose structural constraints on nodes and their immediate neighborhood in an RDF graph. For instance, the types :TEmp and :TDept have the following ShEx definition :TDept { :name xsd:Literal; :address xsd:Literal} :TEmp { :name xsd:Literal; :email xsd:Literal?; :works @:TDept+ } (where xsd:Literal is a new datatype that we introduce to XSD vocabulary). Essentially, every department IRI must have exactly one :name and :address property; and every employee IRI must have a single :name property, an optional :email property, and at least one :works property each leading to a department IRI (satisfying type :TDept).

We are considering the task of converting databases to RDF graphs. It is typically accomplished by a declarative formalism such as R2RML, DM, or YARRRML. Because of the importance of schema for RDF, we also require a target schema in any of the declarative formalisms. As a consequence of this lastly consideration, the following concerns arise:

1. Conceptual complexity of designing mappings in particular when schemas are large can become easily an error-prone process. Can we offer static analysis tools for identification of design errors.

2. The existence of a schema and the fact that mappings are expressed in a declarative way makes possible existence of different solutions to a given input. Which solution is most suitable and if it exists, can it be constructed, what can be said about querying such a solution.

3. The mapping needs to be specified using a formal language which can be challenging to a non-expert user. Can we render this process more accessible while maintaining expressivity.

4. Many already existing solutions of exporting relational to RDF data only consider relational schema and mappings with no target schema. Can we propose a way to construct a schema and what is the good schema to the output graphs.

Formalization

We approach the above concerns by first formalizing the export of relational data to RDF as a data exchange problem. Data exchange has been mainly studied in the context of relational databases [Kolaitis 2005, Arenas et al. 2010, Barceló 2009]. Data exchange from relational databases to RDF has been studied recently [Sequeda et al. 2012,Boneva et al. 2015], but with little to no schema information for the output RDF graph. None of these previous works can be used to address precisely the setting we have at hand.

In this manuscript, we formalize the process of exporting a relational database to RDF with target schema as a constructive data exchange setting where we use sourceto-target generating dependencies as mappings. These mappings use an abstraction of IRI templates which we call IRI constructors to map entities from the relational database to IRIs in the RDF.

CONTENTS

R2RML mappings presented at the beginning of this section can be expressed with the following logical formalism Dept(did , name) ⇒ Triple(dep2iri (did),:name, name) ∧ TDept(dep2iri (did)),

Emp(eid , name, did ) ∧ Email (eid , email ) ⇒

Triple(emp2iri (eid),:name, name) ∧ Triple(emp2iri (eid),:email, email ) ∧

Triple(emp2iri (eid),:works, dep2iri (did )) ∧ TEmp(emp2iri (eid)),

where dep2iri (did) = "dept:{did }" constructs an IRI for each department and the other IRI constructor emp2iri (eid) = "emp:{eid }" generates an IRI for each employee.

This formalization trivially captures direct mapping (DM) [START_REF] Arenas | [END_REF], large fragment of R2RML, and YARRRML since it is a succinct syntax for R2RML. Indeed, this formalization can express all four uses cases of R2RML [Auer et al. 2010] and it can cover 38 out of 54 test cases for R2RML implementations [Villazón & Hausenblas 2012]. The test cases that we do not cover are those that use pattern-based function to transform data values and we do not cover those that use SQL statements with aggregation functions. With this formalization, we address 8 out of the 11 core function requirements for R2RML [Auer et al. 2010]. A relatively straightforward extension of this formalization to node datatypes can cover 10 out of the 11 core function requirements. However, for relative simplicity, we do not study our formalization with datatypes.

Problems of interest

In this manuscript, we employ the above formalization and address the previously identified concerns by studying the following problems of interest.

Checking Consistency. A classical static analysis problem is testing consistency: checking whether for a given source instance of a relational schema there will be always a well-defined target instance. If the setting is inconsistent then there is possible error in the designing of mapping. Then, the static analysis allows to find errors and if it identi-fies conditions that generate inconsistency then it is conceivable to extend to other kind of static analysis. This problem is complex because the source and target languages express constraints differently in an incompatible way. Additionally the mappings can add new constraints. In fact, we can view the problem of checking consistency as a variant of the problem of language containment i.e., does the language of the shapes schema contains the language of graphs produced from the source schema by applying the mappings.

Certain query answering and universal solutions. Certain answers allow to identify the important answers because they are present in every solution. As such, we are interested in finding a good solution that has the property of allowing to easily compute certain answers. Thus, we study the problem of certain query answering where certain answers typically are computed on a universal solution because it preserves information [Fagin et al. 2005a]. However, in the context of relational to RDF data exchange, a finite universal solution might not exist even if the setting is consistent and admits solutions.

Thus, an interesting problem is to check if it is possible to construct a finite solution that has similar properties to a universal solution and to identify the family of queries for which it can be used to compute certain query answers. Also, we are interesting in a low complexity for the construction of this finite solution.

Visual mapping language. It has been argued [Shneiderman 1983] that a simple graphical interface facilitates the specification of mappings by the direct manipulation with drag-and-drop techniques and a visual language. Those kind of visual mapping languages are known to be easy for non-expert users as evidenced by Clio system [Fagin et al. 2009]. The challenge in this problem comes in identifying the trade-off between simplicity and expressivisity. The goal is to provide an interface based on a visual mapping language that is easy to use but does not hinder users with unnecessary details while allows to cover the most possible number of use cases or it is expressible as possible.

Schema elicitation. Shapes schema elicitation aims at constructing a target schema from a set of mappings and a relational schema. An important issue in this construction is to define the properties of the desired target schema because there can be trivial solutions that produce a schema. For instance, solutions that produce universal schemas that accept any graph and not only graphs produced by the mapping. We want an algorithm CONTENTS that makes an honest effort in capturing the structure of the graphs produced.

Contributions

In this section, we describe the contributions presented to solve the problems above.

Consistency. We have solved the problem of consistency by identifying a set of necessary and sufficient conditions that guarantees the consistency. This characterization aims at constructing an inconsistent instance. One such condition is value consistency that guarantees that no two different values are equated to satisfy the shapes schema.

For instance, in the previous example, an employee that has two different names is an example of value inconsistency. On the other hand, a mapping rule may declare the type of nodes it constructs as IRI or literal. A malformed set of rules may inconspicuously produce a graph with a node whose declared type is both IRI node and literal node. The condition of node kind consistency guarantees the no co-occurrence of literal and non literal types for a node. We have developed an static analysis tool that allows to decided if a setting is consistent. The complexity of checking those conditions is coNP-complete. Initial findings have been published in AMW [Boneva et al. 2018] and further developed in ADBIS [Boneva et al. 2020].

Certain query answering. We have proposed a novel notion of universal simulation solution, which is an adaptation of universal solution by replacing homomomorphisms with a weaker notion of simulation. A universal simulation solution always exists and it allows to compute certain answers to classes of queries that are robust under simulation.

Intuitively, a robust query class is when a query is evaluated on a node, the query will behave in a same way under any node that is simulated. We can construct a minimalsize universal simulation solution to a given instance of the relational schema w.r.t. a constructive setting is exponential in the size of the shapes schema. If we consider the class of nested regular expressions, which are used as a navigational query language by SPARQL [Pérez et al. 2010] to query RDF, then the forward fragment is robust under simulation. The data complexity of computing certain answers for nested regular expressions and any constructive data exchange setting is PTIME. We have published this result in ADBIS [Boneva et al. 2020].

Visual mapping language. We have proposed a visual mapping language (VML) that covers a large fragment of constructive relational to RDF data exchange setting. Also, we have developed ShERML, a tool that guides a user through interactive functionalities in the process of exporting relational data to RDF. In addition, we have proposed R2VML, a declarative mapping language that captures VML mappings and presents a user-friendly and succinct syntax for defining mappings. We have published the result related to the visual mapping language in ISWC [Boneva et al. 2019].

Shapes schema elicitation. We have investigated the problem of shapes schema elicitation and we have identified two desirable properties of the target schema, which are soundness i.e., every produced RDF graph is accepted by the target schema; and completeness i.e., every RDF graph accepted by the target schema can be produced. We have proposed an algorithm called M3, based on a method of minimal and maximal models, that produces a sound schema for any relational schema and set of mappings. We have shown that for relational schemas and mappings that are the result of the straightforward translation of a class of ER diagrams, the schema produced by M3 is also complete.

Finally, we have presented two inherent limitations of the task at hand: a sound and complete schema might be of exponential size or worst even it might not exist. We are currently preparing for publication.

Organization

In this section, we describe briefly the content of each chapter of the manuscript.

Preliminaries. Chapter 1 provides the basic definitions and notations used throughout this manuscript. First, we recall the notions of signatures, models, semantics and classes of formulas. Second, relational databases and dependencies are introduced with the definition and formalization of them. Third, we describe the concepts that are related to relational data exchange setting, which are chase, universal solution, certain query answering and consistency. Fourth, RDF is presented and formalized. Finally, we present the shapes constraints language and show how these constraints can be expressed with dependencies.

Relational to RDF data exchange. Chapter 2 illustrates a relational to RDF data ex-CONTENTS change setting. We present its formalization and define what is a solution to our setting.

Also, we present R2RML and show which part of it is captured by our setting, and how this is captured. We end with an introductory presentation of the problems of interest.

Consistency. Chapter 3 provides the study of consistency problem. First, we identify the sources of inconsistency by an example. Then, we present two conditions that will guarantee the absence of the source of inconsistency. Each condition is shown to be necessary for deciding consistency and an algorithm is presented for each condition to identify if the setting satisfies it. At the end of the chapter, we show that consistency is decidable.

Certain query answering.

Chapter 4 provides the study of certain query answering problem. We start with an adaptation of two existing approaches to the problem of certain query answering. Then, we present our approach that investigates forward nested regular expressions and introduces the notion of a universal simulation solution that allows to compute certain answers efficiently. We present the construction of a size-minimal universal simulation solution and show that its size is polynomial in the size of the source instance, but might be exponential in the size of the constraints.

Visual mapping language. Chapter 5 provides a tool that defines visual mappings. The notions of human-computer interaction used to develop the tool are described at the beginning. Then, a text-based mapping language is defined and on top of this language is defined a visual mapping language. Based on these languages, we describe the tool developed for facilitating the definition of mappings in a relational to RDF data exchange context. We do an evaluation of the tool and present its results.

Shapes schema elicitation. Chapter 6 defines the shapes schema elicitation problem where the notions of soundness and completeness of a desirable target schema are defined. An elicitation algorithm is proposed based on minimal and maximal models described in the same section. Then, we show the soundness of the algorithm. We identify a class where the proposed algorithm is complete. Finally, we present inherent limitations of the task of producing sound and complete schema.

Chapter 1

Preliminaries

In this chapter, we recall the basic concepts and introduce the notation that will be used throughout this manuscript. We start in Section 1.1 by recapping fundamentals of logic. In Section 1.2, we recall basic notions of relational databases. Next, we describe a general notion of relational data exchange in Section 1.3. Then we describe RDF graphs and their formalization in Section 1.4. Finally, in Section 1.5, we discuss the notion of schemas for RDF graphs and introduce an abstraction formalism that captures a common fragment of two well-known schemas ShEx and SHACL.

Logic

We fix an enumerable set Dom of constant values. Because we deal with relational databases and RDF graphs in this manuscript, we need to distinguish for RDF, nodes and literals where nodes and literals can have null values; and we need to distinguish for relational databases, constants and null values. Thus, we specify the domain to be partitioned into three infinite subsets Dom = Iri ∪ Lit ∪ Blank, of IRIs, literals, and blank node identifiers respectively. Because relational databases deal with null values that are not blank nodes, we assume an infinite set of null literals NullLit ⊆ Lit for relational databases; and the set of all null values Null = NullLit ∪ Blank. We refer to the remaining elements as constants Const = Dom \ Null, and additionally, because relational databases use constants that are neither IRIs nor null literals, we identify non-

null literals ConstLit = Lit \ NullLit = Const ∩ Lit.
The relational vocabulary is an enumerable set of symbols V = V a ∪ V R ∪ V f 10 CHAPTER 1. PRELIMINARIES partitioned into three pair-wise disjoint subsets: the set of first-order names V a , the set of relation names V R , and the set of function names V f . In our formulas, we are going to use names of the constant values of Dom. So, we specify the set of first-order names,

V a = V V ∪ Dom as a set of variable names V V and a set of names of the domain corresponding to IRIs, literals and blank nodes.

For a function name or relational name, the number of inputs is called the arity of the function or relational name. We assume that each relation and function name come with a fixed arity. In the sequel, by

V (m) R
we denote the set of relation names of arity m, and analogously, by

V (n) f
we denote the set of function names of arity n. Every element of the vocabulary has its domain, the set of compatible values:

dom(v) = Dom, dom(R) = 2 Dom m , dom(f ) = Dom Dom n , dom(c) = {c}
for any v ∈ V V , c ∈ Dom, R ∈ V R with arity m, and for any f ∈ V f with arity n. We point out that the domain of a constant symbol is the same constant value.

Syntax. A term is defined by the following recursive syntax:

t ::= a | f (t, . . . , t)

where a ∈ V a , and f ∈ V f . A formula is defined with the following syntax:

ϕ ::= R(t, . . . , t) | ¬ϕ | ϕ ∧ ϕ | ∃v. ϕ | t = t
where R ∈ V R , t is a term, and v ranges over V \ V f . We use the following syntacticsugar:

∀v. ϕ ::= ¬∃v. ¬ϕ, ϕ ∨ ψ ::= ¬(¬ϕ ∧ ¬ψ), ϕ ⇒ ψ ::= ¬ϕ ∨ ψ.

Signatures and models.

A relational signature R ⊆ V is a finite set of symbols. A relational structure of R, or a model of R, is a function M that assigns to every symbol v ∈ R a compatible value v M ∈ dom(v). In essence, relational signature identifies a set of names whose interpretation is provided by a model. The size of a signature R, denoted by |R|, is the number of symbols in the signature.

The union of two models M 1 of R 1 and M 2 of R 2 , whose signatures are disjoint R 1 ∩R 2 = ∅, is a model M 1 ∪M 2 of R 1 ∪R 2 defined as follows (for any v ∈ R 1 ∪R 2 ):

v M 1 ∪M 2 =      v M 1 if v ∈ R 1 , v M 2 if v ∈ R 2 .
Given two models M 1 of R 1 and

M 2 of R 2 , M 1 is compatible with M 2 if for all v ∈ R 1 ∩ R 2 , v M 1 = v M 2 . The merge of two compatible models M 1 of R 1 and M 2 of R 2 is a model M 1 M 2 of R 1 ∪ R 2 defined as follows (for any v ∈ R 1 ∪ R 2 ): v M 1 M 2 =      v M 1 if v ∈ R 1 , v M 2 if v ∈ R 2 \ R 1 .
A term over a signature R is defined with

t ::= a | f (t, . . . , t)
where a ∈ V a ∩ R, and f ∈ V f ∩ R. A formula over a signature R is defined with:

ϕ ::= R(t, . . . , t) | ¬ϕ | ϕ ∧ ϕ | ∃v. ϕ | t = t
where R ∈ V R ∩R, t is a term over R, and v ∈ V V ∪(V a ∩R). Implicitly, all signatures will allow to use equality symbol =.

Classes of formulas. We point out that any symbol in V can serve the purpose of a variable, in particular the symbol present in a relational signature R can also be bound with a quantifier (overriding whatever interpretation the structure assigns to this symbol). We identify the set of symbols used in a term as follows:

Vocab(a) = {a} Vocab(f (t 1 , . . . , t n )) = {f } ∪ n i=1 Vocab(t i ),
and the set of symbols used in a formula, Vocab(R(t 1 , . . . , t m )) = {R} ∪ m i=1 Vocab(t i ), Vocab(¬ϕ) = Vocab(ϕ), Vocab(ϕ 1 ∧ ϕ 2 ) = Vocab(ϕ 1 ) ∪ Vocab(ϕ 2 ), Vocab(∃v. ϕ) = Vocab(ϕ), Vocab(t 1 = t 2 ) = Vocab(t 1 ) ∪ Vocab(t 2 ).

Similarly, we can identify the set of unbound symbols used in a formula

Unbd (R(t 1 , . . . , t m )) = {R} ∪ m i=1 Vocab(t i ), Unbd (¬ϕ) = Unbd (ϕ),

Unbd (ϕ 1 ∧ ϕ 2 ) = Unbd (ϕ 1 ) ∪ Unbd (ϕ 2 ), Unbd (∃v. ϕ) = Unbd (ϕ) \ {v}, Unbd (t 1 = t 2 ) = Vocab(t 1 ) ∪ Vocab(t 2 )
Now, let R be a relational signature and ϕ a formula over R. The set of variables used in ϕ is vars R (ϕ) = Vocab(ϕ) \ R. The set of free variables of a formula ϕ is fvars R (ϕ) = Unbd (ϕ) \ R. The formula ϕ is closed iff it has no free variable i.e., fvars R (ϕ) = ∅. An atomic formula has the form R(t, . . . , t), where R ∈ V R . A formula is ground if it uses no variables whatsoever. A relational atom does not use any function symbols. A fact is a ground relational atom. A first-order (FO) formula over R uses only first-order variables i.e., vars R (ϕ) ⊆ V a . A second-order (SO) formula over R uses second-order variables in addition to first-order variables i.e., vars R (ϕ) ⊆

V a ∪ V R ∪ V f . A monadic SO logic (MSO) formula over R uses no second-order functional variable and no second-order relational variable of arity higher than 1 i.e., vars R (ϕ) ⊆ V

(1) R ∪V a . An existential second-order (∃SO) formula over R has the form ϕ = ∃X 1 , . . . , X n . ϕ, where X 1 , . . . , X n ∈ V R ∪ V f , and ϕ does not have a quantifier with a second-order variable in V R ∪ V f . If furthermore, all X 1 , . . . , X n ∈ V

(1) R , then ϕ is an existential monadic SO (∃MSO) formula.

Semantics. We define the entailment relation between a relational structure M of R and a formula ϕ over R. First, we define an expression E over R as any term, variable name, function name or relation name. We identify the free variables V ⊆ fvars R (E) of an expression. A valuation of V is a function θ that takes a symbol v ∈ V and yields a value in dom (v). By ∅ we denote the empty valuation of the empty set of symbols.

Given a valuation θ of V , a symbol v ∈ V \ R, and a value w ∈ dom(v), θ[v/w] is valuation θ of V ∪{v} such that θ (v) = w and θ (z) = θ(z) for any z ∈ V \{v}. Given a relational signature R, a model M of R, an expression E over R and a valuation θ of V such that fvars R (E) ⊆ dom(θ) where dom returns the domain of θ, the interpretation of E w.r.t. θ and M is defined as follows:

v (M,θ) =      v M if v ∈ Dom θ(v) Otherwise.
for any v ∈ V,

R (M,θ) =      R M if R ∈ dom(θ) θ(R) Otherwise.
for any R ∈ V ,

f (M,θ) =      f M if f ∈ dom(θ) θ(f ) Otherwise.
for any f ∈ V , ,θ) Otherwise.

f (t 1 , . . . , t n ) (M,θ) = f (M,θ) (t (M,θ) 1 , . . . , t (M,θ) n ) t (M,θ) =      v (M,θ) if t = v, f (t 1 , . . . , t n ) (M
for any term t.

Below, we define the entailment relation (M, θ) |= ϕ of a formula ϕ over R w.r.t. a model M of R and a valuation such that dom(θ) ⊆ fvars R (ϕ) is defined as follows:

(M, θ) |= R(t 1 , . . . , t n ) iff (t (M,θ) 1 , . . . , t (M,θ) n ) ∈ R (M,θ) , (M, θ) |= ¬ϕ iff it is not true that (M, θ) |= ϕ, (M, θ) |= (ϕ 1 ∧ ϕ 2 ) iff (M, θ) |= ϕ 1 and (M, θ) |= ϕ 2 , (M, θ) |= ∃v. ϕ iff (M, θ[v/w]) |= ϕ for some w ∈ dom(v). (M, θ) |= t 1 = t 2 iff (M, θ) |= t (M,θ) 1 = t (M,θ) 2
.

Finally, we say that ϕ is satisfied in M , in symbols M |= ϕ iff (M, ∅) |= ϕ.

Relational databases

We recall the basic notions of relational databases [START_REF] Garcia-Molina | [END_REF]. A relational database is a collection of tables where each table has a name and each column of a table also has a name called attribute. From the modeling point of view, a table is seen as a relation. Each table gives some structural information on the relation, and the whole structural information of all relations is called the schema. Each row of the table is called a tuple and stores the attribute values. The set of tuples is the content of a table

and the content of the whole database is called an instance. The schema also includes a set of constraints, which defines consistency of the instance. Here, we focus only on functional dependencies and inclusion dependencies. We illustrate the above notions with the following example.

Example 1.2.1. Consider the database in Figure 1.1 of an academic institute that organizes conferences. Figure 1.1 shows an instance together with a schema including primary keys which are the attributes that are underlined and foreign keys which are represented with arrows. This database stores information structured in a set of tables about researchers that have attended conferences, presented talks and for each talk stores the collaborators. This information is structured in the following tables:

• Table Researcher stores researchers with their name, email, expertise and team.

• Table UniTeam stores teams associated to a university and located in a place.

• Table Conference stores conferences with their name, year and place.

• Table Registration stores the date when a researcher is registered in a conference.

• Table Talk stores the title of a researcher talk done in a conference;

• The schema of the conference database is composed of the relations that are the tables presented above and defines the following set of constraints:

(R1) every researcher and every conference have a unique identifier;

(R2) every team of a university is identified by a unique name;

(R3) every collaborator is identified by a unique research ID, conference (R6) every talk has a reference to the relation Registration;

(R7) every collaborator has a reference to the relation Talk and a reference to the relation Researcher; and

(R8) every researcher has a reference to the relation UniTeam.

We can create the schema of the conference database in RDBMS using SQL syntax as shown in Figure 1.2. The primary keys in RDBMS are rules from R1 to R4, and the foreign keys are rules from R5 to R8.

• R is a finite set of relation names, each relation name with a given arity;

• attrs is a function attrs:R → P(A) that assigns to each relation name R ∈ R a finite set of attribute names whose cardinality is equal to the arity of R;

• Σ fd is a set of functional dependencies (fds) of the form R : X → Y , where R ∈ R is a relation name, and X, Y ⊆ attrs(R), and Also, we assume that the set of attribute names of every relation have a fixed order.

• Σ ind is a set of inclusion dependencies of the form R[X] ⊆ P [Y ],
Intuitively, a fd R : X → Y means that values of attribute names in X determine the values of attribute names in Y in every tuple; and an inclusion dependency between two relations R and P , R[X] ⊆ P [Y ], means that every value of an attribute in X is the same value of an attribute in Y . We point out that key dependencies (kds) are a special case of functional dependencies where Y = attrs(R). Also, foreign key constraints are a special case of inclusion dependencies where Y is a primary key in P .

Given a finite set A ⊆ A of attribute names, a tuple over A is a function that maps from an attribute name to a value, i.e., t : A → Dom. We view a tuple as a record, consequently we write t.a for t(a). Let X ⊆ A be a set of attributes, by t.X we denote a tuple over X that consists of precisely the value of t on attributes in X, i.e., An instance I of a relational schema R satisfies a fd R : X → Y , denoted by

I |= R : X → Y , if
for any pair of tuples in I(R) that agree on X also agree on Y .

Formally,

I |= R : X → Y iff ∀t 1 , t 2 ∈ I(R). t 1 .X = t 2 .X ⇒ t 1 .Y = t 2 .Y . An instance I of a relational schema R satisfies an inclusion dependency R[X] ⊆ P [Y ], denoted by I |= R[X] ⊆ P [Y ],
if for any tuple t ∈ I(R), there is a tuple t ∈ I(P )

such that the tuple t over X agrees with t over Y . Formally,

I |= R[X] ⊆ P [Y ] iff ∀t ∈ I(R). ∃t ∈ I(P ). ran(t) ⊆ ran(t ) ∧ t.X = t .
Y where ran returns the range of t. Finally, we say that an instance I is consistent if I satisfies the set of dependencies Σ fd ∪ Σ ind . The active domain adom(I) of the instance I is the set of values from Dom used in I. For ease of use, when writing a functional dependency or inclusion dependency, we write a set of attributes A = {a 1 , . . . , a n } as A = a 1 . . . a n . We denote the set of instances of a relational schema R by Inst(R).

Example 1.2.2 (cont. Example 1.2.1). Take the conference database, the relational schema R 0 = (R 0 , attrs, Σ fd , Σ ind ) has the following relation names

R 0 = {Researcher, UniTeam, Conference, Registration, Talk, Collaborator},
and we express the set of constraints with the following dependencies Σ fd ∪ Σ ind :

Researcher : Idr → Idr Name Email Expertise Team (R1)

Conference : Idc → Idc Name Year Place (R1)

UniTeam : Team University → Team University Place (R2)

Collaborator : Idr Idc Title Idrc → Idr Idc Title Idrc (R3)

Registration : Idr Idc → Idr Idc Date (R4)
Talk : Idr Idc Title → Idr Idc Title (R4)

Registration[Idc] ⊆ Conference[Idc] (R5) Registration[Idr ] ⊆ Researcher[Idr ] (R5) Talk[Idr Idc] ⊆ Registration[Idr Idc] (R6) Collaborator[Idr Idc Title] ⊆ Talk[Idr Idc Title] (R7) Collaborator[Idrc] ⊆ Researcher[Id ] (R7) Researcher[Team] ⊆ UniTeam[Team] (R8)
We recall that the set of functional dependencies in this example are primary keys and the inclusion dependencies are foreign key constraints.

Logic formalization

The relational signature of the relational schema R = (R, attrs, Σ fd , Σ ind ) is the set of relation names R. For a given relational schema R and a database instance I of R, by M I we define the relational structure over R corresponding to I with R M I = I(R) for all R ∈ R. In the sequel, we treat database instances interchangeably with their relational structures, and unless we state otherwise, we work only with instances that use literal constants from ConstLit.

In general, given a relational schema R = (R, attrs, Σ fd , Σ ind ), a database constraint either functional or inclusion dependency is modeled by a dependency, which is any closed formula σ over R of the form ∀x, y. ϕ(x, y) ⇒ ∃z. ψ(y, z) where • x, y and z are sequences of variables,

• ϕ(x, y) is a conjunction of atomic formulas over R and is called the body of σ, denoted as body(σ); and

• ψ(y, z) is called the head of σ, denoted as head (σ), and is either a conjunction of equality terms or a conjunction of atomic formulas over R.

We distinguish two types of dependencies by the form of head (σ):

• equality generating dependency (egd) if the dependency is a conjunction of equality terms; and

• tuple generating dependency (tgd) if the dependency is a conjunction of atomic formulas.

In the sequel, we write x to denote a sequence of variables and for writing dependencies, we often drop the universal quantifier and write simply ϕ(x, y) ⇒ ∃z. ψ(y, z); and we assume that implicitly all free variables are universally quantified.

Any inclusion dependency can be expressed with tgds and any fd is in fact an egd.

For instance, the following example illustrates how fds and inclusion dependencies can be expressed with tgds and egds.

Example 1.2.3 (cont. Example 1.2.2). We express the functional dependencies with the following formulas over R 0 :

Researcher(x 1 , y 2 , y 3 , y 4 , y 5 ) ∧ Researcher(x 1 , z 2 , z 3 , z 4 , z 5 ) ⇒ 5 i=2 y i = z i , Registration(x 1 , x 2 , x 3 ) ∧ Registration(x 1 , x 2 , y 3 ) ⇒ x 3 = y 3 , Conference(x 1 , y 2 , y 3 , y 4 ) ∧ Conference(x 1 , z 2 , z 3 , z 4 ) ⇒ y 2 = z 2 ∧ y 3 = z 3 ∧ y 4 = z 4 , Talk(x 1 , x 2 , x 3 ) ∧ Talk(x 1 , x 2 , x 3 ) ⇒ x 1 = x 1 ∧ x 2 = x 2 ∧ x 3 = x 3 .
We omit the key dependencies for UniTeam and Collaborator since there are similar to Talk because they do not imply other attributes. Now, we express the inclusion dependencies with the following formulas over R 0 :

Registration(x 1 , x 2 , x 3 ) ⇒ ∃y. Conference(x 1 , y), Registration(x 1 , x 2 , x 3 ) ⇒ ∃y 1 , y 2 , y 3 , y 4 . Researcher(x 1 , y 1 , y 2 , y 3 , y 4 ), Talk(x 1 , x 2 , x 3 ) ⇒ ∃y. Registration(x 1 , x 2 , y), Collaborator(x 1 , x 2 , x 3 , x 4 ) ⇒ ∃y. Talk(x 1 , x 2 , x 3 ), Researcher(x 1 , x 2 , x 3 , x 4 , x 5 ) ⇒ ∃y 1 , y 2 . UniTeam(x 5 , y 1 , y 2 ).
Finally, an instance I of R satisfies a dependency σ if I |= σ.

Database queries

A database query extracts data from an instance of a relational schema. Such extracted data is called an answer. Typically, a query is modeled by a first-order formula. Here we also treat Boolean queries where the answers are true or false.

We illustrate an answer to a query in the next example.

Example 1.2.4 (cont. Example 1.2.2). Recall the conference database in Example 1.2.2.

Consider the query ϕ 1 which asks the talks of Steve on the ISWC conference in the year 2019:

ϕ 1 (y) = ∃x 1 , x 2 , x 3 , x 4 , x 5 , x 6 . Researcher(x 1 , Steve, x 2 , x 3 , x 4 )∧ Conference(x 5 , ISWC, 2019, x 6 ) ∧ Talk(x 1 , x 5 , y). (1.1)
The set of answers to ϕ 1 is {(Skolemization of prenex formulas)}.

Now, consider a Boolean query ϕ 2 which asks if Steve has presented a talk on a

ICDT conference in the year 2019:

ϕ 2 () = ∃x 1 , x 2 , x 3 , x 4 , x 5 , x 6 , x 7 . Researcher(x 1 , Steve, x 2 , x 3 , x 4 )∧ Conference(x 5 , ICDT, 2019, x 6 ) ∧ Talk(x 1 , x 5 , x 7 ). (1.
2)

The answer to this query is false.

We define queries using formulas. Let R = (R, attrs, Σ fd , Σ ind ) be a relational schema. Let I be a database instance of R and let ϕ be a first-order formula. A valuation A conjunctive query ϕ is acyclic if it has a join-tree, otherwise is cyclic. A join-tree is a tree T such that nodes are the relational atoms of the conjunctive query ϕ and for every variable x of ϕ the set of relational atoms with x forms a subtree of T .

val of fvars R (ϕ) is
Example 1.2.5. Consider a query ϕ(x, y) = ∃z, w. E(x, z) ∧ E(z, w) ∧ E(y, z). This query is acyclic because it has a join tree as seen in Figure 1.3.

E(x,z)

E(y,z) E(z,w)

Figure 1.3: Join tree of a conjunctive query.

Relational data exchange

We recall the classical data management problem called data exchange. Relational data exchange is the transformation from a source relational database to a target relational database. Such a transformation is defined by a set of mappings from the source relational schema to the target schema. These elements constitute the data exchange setting.

The result of a transformation of a source instance is an instance of the target schema, and if it satisfies the constraints (of target schema), it is called a solution. We illustrate the above notions with the help of the following example. The relation Author stores the names of authors and their countries. The relation Conference stores conference names, the year of realization, the booktitle and the place. The relation Publication stores publications, the authors of each publication and the booktitle. Now, the following rules for transforming the conference database into the new schema are listed. We also give the logical definition that we explain latter.

• A talk presented by a researcher is mapped to a publication and the researcher who authors such a talk is mapped to an author. Formally,

Researcher(x 1 , x 2 , x 3 , x 4 , x 5 )∧Talk(x 1 , x 6 , x 7 ) ⇒ ∃y 1 , y 2 . Author(x 1 , x 2 , y 1 )∧ Publication(x 1 , x 6 , y 2 ). (1.3)
• A paper presented in a talk that was written by collaborator researcher is mapped to a publication and the collaborator researcher is mapped to an author. Formally,

Collaborator(x 1 , x 2 , x 3 , x 4 ) ∧ Researcher(x 4 , x 5 , x 6 , x 7 , x 8 ) ⇒ ∃y 1 , y 2 .
Author(x 4 , x 5 , y 1 ) ∧ Publication(x 1 , x 3 , y 2 ). (1.4)

• Every conference is mapped to a conference in the new schema. Formally,

Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ ∃y 1 . Conference(x 2 , x 3 , y 1 , x 4 ).
(1.5)

Figure 1.4 shows a target instance of the target schema obtained from the application of the set of rules to the source instance (conference database). This target instance includes null values (⊥ 1 , ⊥ 2 , ⊥ 3 ) to fill those attribute values that were not extracted from the source instance. We see that this target instance is a solution because the set of functional and inclusion dependencies are satisfied. We denote this data exchange setting by E 0 that is composed of the source relational schema of the conference database, the target relational schema and the set of rules specified before.

In the data exchange setting of Example 1.3, the existential variables represent the new fresh values that will be introduced in a tuple. • id is a number generated by a function whose parameters are name and year of conference;

• title is the booktitle;

• ck is the value that depends on the transformation of place; and

• editor is an invented value that depends on all attributes of conference.

Formally,

∃f ed . Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ Book(f id (x 3 , x 4 ), x 3 , f ck (x 4 ), f ed (x 1 , x 2 , x 3 , x 4 )), (1.6)
where f ed is a Skolem function, f id and f ck are function names whose interpretations are as follows.

• f id performs the hash of the concatenation of name with year; and

• f ck assigns an international country code by the value of the place.

A solution for this new data exchange setting is shown in Figure 1.5.

Book

Data exchange setting

A data exchange setting is a tuple E = (R, S, Σ st , F), where

• R = (R R , attrs R , Σ R fd , Σ R ind ) is a source relational schema, • S = (R S , attrs S , Σ S fd , Σ S ind ) is a target relational schema, • F ⊆ V f is a set of function names and
• Σ st is a set of source-to-target tuple generating dependencies (st-tgds) where each st-tgd σ is of the form ∀x. ϕ(x) ⇒ ∃y. ψ(x, y).

We distinguish two sub-classes:

• when F = ∅, we call it first-order data exchange and we write w.l.o.g. E = (R, S, Σ st )

• otherwise, we call it Skolemized data exchange.

Usually, the set of inclusion dependencies in the target schema are called target tuple generating dependencies (t-tgds) because the dependencies are expressed as tgds.

We recall that the set of functional dependencies are expressed as egds. Given a data exchange setting E = (R, S, Σ st ) and a consistent instance I of relational schema R, a solution to I w.r.t. E is any instance J of S such that I ∪J satisfy the set of dependencies Σ st . By sol E (I), we denote the set of all solutions to I w.r.t. E.

Chase procedure

The chase algorithm was originally used to decide logical implication of first-order constraints [Maier et al. 1979]. Here, we use the chase to construct solutions to data exchange. The chase procedure begins with a given source instance and iteratively constructs the solution by applying the given set of dependencies, which can be tgds and egds. At each step the chase identifies a dependency that is triggered i.e., the body of the dependency is satisfied and the head is not, and then applies it, i.e., if the dependency is a tgd, then its application generates new tuples, and if the dependency is an egd, then its application attempts an equation of values, which may result in a failure if the values are different constants. In general, the chase sequence might be infinite, but if it terminates, then it can end with a failure or give a consistent solution. This chase variant is called restricted chase. We recall the notion of chase with the help of the following example. • Dependency (1.3) is triggered by two tuples

Researcher(1, Jose Lozano, j@s.fr, Math, ALG) and Talk(1, 1, Tutor. . . )

and applying this dependency results in adding the tuples

Author(1, Jose Lozano, ⊥ 4 ), Publication(1, Tutor. . . , ⊥ 5 ).

Researcher(x 1 , x 2 , x 3 , x 4 , x 5 ) ∧ Talk(x 1 , x 6 , x 7 ) ⇒ ∃y 1 , y 2 . Author(x 1 , x 2 , y 1 )∧ x 2 x 3 x 4 x 5

x 1 x 6

x 7 1 Jose Lozano j@s.fr Math ALG 1 1 Tutor. . .

Author x 1 x 2 y 1 1 Jose Lozano ⊥ 4 Publication x 1
x 6 y 2 1 Tutor. . . ⊥ 5 Figure 1.6: Matching of the body and the application of the head of the st-tgd 1.3.

• Dependency (1.3) is triggered by two tuples

Researcher(1, Jose Lozano, j@s.fr, Math, ALG) and Talk(1, 1, Skol. . . ) and applying this dependency results in adding only the tuple Publication(1, Skol. . . , ⊥ 6 ).

Recall that Author(1, Jose Lozano, ⊥ 4 ) is already there. We observe that the application of a tgd not always generates the whole head.

• Analogously, other dependencies are triggered and applied until there is no de-pendency that is triggered. Those dependencies are (1.3), which is triggered one more time, (1.4), which is triggered twice, and (1.5), which is triggered twice.

At the end of the chase sequence, we have the target instance, which we denote by J 0 , seen in Figure 1.7. This instance is called a pre-solution. We point out that the chase with the set of st-tgds always terminates. Now, we proceed with the set of target constraints where the chase is used to enforce the satisfaction of these constraints on the instance J 0 . We take those constraints as set of dependencies (tgds and egds).

Author

Author(x 1 , x 2 , x 3 ) ∧ Author(x 1 , y 2 , y 3 ) ⇒ x 2 = y 2 ∧ x 3 = y 3 , (1.7) Conference(x 1 , x 2 , x 3 , x 4 ) ∧ Conference(x 1 , x 2 , y 3 , y 4 ) ⇒ x 3 = y 3 ∧ x 4 = y 4 , (1.8) Publication(x 1 , x 2 , x 3 ) ∧ Publication(x 1 , x 2 , y 3 ) ⇒ x 3 = y 3 , (1.9) Publication(x 1 , x 2 , x 3 ) ∧ Publication(x 4 , x 2 , y 3 ) ⇒ x 3 = y 3 , (1.10) Publication(x 1 , x 2 , x 3 ) ⇒ ∃y 1 , y 2 , y 3 . Conference(y 1 , y 2 , x 3 , y 3 ), (1.11) Publication(x 1 , x 2 , x 3 ) ⇒ ∃y 1 , y 2 . Author(x 1 , y 1 , y 2 ).
(1.12)

The chase sequence is as follows.

• Dependency (1.10) is triggered by two tuples

Publication(1, Tutor. . . , ⊥ 5 ) and Publication(4, Tutor. . . , ⊥ 9 )

and applying this dependency results in equating the values

⊥ 9 = ⊥ 5 .
• This dependency also triggers for publication of title On alg. . . and equates

⊥ 7 = ⊥ 8 .
• Dependency (1.11) is triggered three times adding new tuples.

The chase sequence ends with the following solution seen in Figure 1.9.

The chase sequence with these target dependencies and the rules of Example 1.3.1 is finite. However, the chase sequence can finish with a failure or even be infinite. A failure is when in the application of the egd, the two values to be equated are constants and not equal. In the following example, we illustrate the notion of failure.

But the application cannot equate

Peru = Chile.

Thus, the chase ends with a failure.

A chase sequence is infinite when the application of a tgd always triggers another tgd. In the following example, we illustrate an infinite chase.

Example 1.3.5. Consider the source schema R 1 with relation Worker(id , name, age), and the target schema R 2 with two relations Emp(id , name) and Sup(super id , emp id ).

The target schema also contains the following tgd constraints.

Sup(x 1 , x 2 ) ⇒ ∃y. Emp(x 1 , y), Sup(x 1 , x 2 ) ⇒ ∃y. Emp(x 2 , y), (1.13)
Emp(x 1 , x 2 ) ⇒ ∃y. Sup(x 1 , y).

(1.14)

These constraints impose that every employee has a supervisor and the value of emp id needs to exist in the database as an employee and the supervisor also is an employee.

The st-tgd for exchanging data is

Worker(x 1 , x 2 , x 3 ) ⇒ Emp(x 1 , x 2 ).
Take the following source instance Worker(1, Jose, 30). After applying the st-tgd we have an instance J 1 with only one tuple Emp(1, Jose) and we observe that the tgd (1.14) is triggered which results in adding the tuple Sup(⊥ 1 , 1). Then this triggers the tgd (1.13) which results in adding Emp(⊥ 1 , ⊥ 2 ). Then, the tgd (1.14) is triggered again, which results in adding the tuple Sup(⊥ 3 , ⊥ 1 ) that causes tgd (1.13) to be triggered again adding the tuple Emp(⊥ 3 , ⊥ 4 ). Such result triggers the tgd (1.14) already triggered before adding Sup(⊥ 5 , ⊥ 3 ). Tutoring Web math platform ⊥ 5

Figure 1.9: A Universal Solution.

Homomorphism

We define triggering of a dependency with the classical notion of homomorphism. First, we define a function called substitution as follows h : V a ∪ Dom → V a ∪ Dom. This function is different from the identity function on the set of null values and variables, which we denote by adom(h). Furthermore, h assigns a value in Dom to every element in adom(h).

Now, a homomorphism h : I 1 → I 2 between two relational structures I 1 , I 2 of the same relational signature R is a substitution from adom(I 1 ) to adom(I 2 ) that

• preserves the constant values i.e., h(a) = a whenever a ∈ Const, and

• for every R ∈ R and every (a 1 , . . . , a n ) ∈ I 1 (R) we have (h(a 1 ), . . . , h(a n )) ∈ I 2 (R)
and n is the arity of R.

A homomorphism h extends a homomorphism h, written h ⊆ h , if adom(h) ⊆ adom(h ) and h (x) = h(x) for all x ∈ adom(h).

We define a mapping h F that will be used to define the notion of homomorphism from a formula into an instance. We use the notion of this homomorphism for chase purposes. Let F be a function signature and F be an interpretation of F. For a term t over F and a substitution h : V a ∪ Dom → V a ∪ Dom, we define h F (t) as:

h F (t) =              h(x) if t = x ∈ V a a if t = a ∈ Dom f (h F (t )) if t = f (t ) is a function term.
The mapping h F is extended on atoms and conjunctions of atoms as expected:

h F (R(t, . . . , t)) = R(h F (t, . . . , t)) and h F ( i∈1..k R i (t i , . . . , t i )) = i∈1..k h F (R i (t i , . . . , t i )).
Note that if the argument of h F does not contain function terms, the interpretation F is irrelevant so we allow to omit the F superscript and write e.g.

Chase

We define formally the chase procedure for tgds and egds. Let I be a database instance of a relational schema R = (R, attrs, Σ fd , Σ ind ). Let σ be a tgd of the form ∀x. ϕ ⇒ ∃y. ψ where ϕ and ψ are over R. We say that σ is triggered in I by h if

• adom(h) = x,
• h(ϕ) ⊆ I, and

• there is no extension h of h such that h (ψ) ⊆ I.

It has a successful execution h yielding I , in symbols

I σ,h --→ I , if h is an extension of h such that adom(h ) = x ∪ y and I = I ∪ h (ψ).
Next, let σ be an egd of the form

∀x. ϕ ⇒ x i = x j
where {x i , x j } ⊆ x. We say that σ is triggered in I by h if

• adom(h) = x,
• h(ϕ) ⊆ I, and

• h(x i ) = h(x j ).
It has a successful execution h yielding I , in symbols Now, we define the chase for a st-tgd. Let E = (R, S, Σ) be a data exchange setting.

I σ,h --→ I , if there is a homomor- phism h such that adom(h ) = h(adom(h)) ∩ Null i.e.,
A st-tgd σ ∈ Σ is a tgd with the difference that ϕ is over the source signature R R and ψ is over the target signature R S . Here the chase takes an instance I = I R ∪ I S , where I R is the source instance and I S is the target instance. We say that σ is triggered in I by

h if • adom(h) = x,
• h(ϕ) ⊆ I R , and

• there is no extension h of h such that h (ψ) ⊆ I S .
It has a successful execution h yielding I , in symbols

I σ,h --→ I , if h is an extension of h such that adom(h ) = x ∪ y and I = I ∪ h (ψ).
Each time a dependency σ is triggered in I by a homomorphism h is called a chase step. Now, given an instance I and a set Σ st of st-tgds together with a set of t-tgds Σ ind and egds Σ fd , a chase sequence of I with Σ st ∪ Σ ind ∪ Σ fd is a possibly infinite sequence of chase steps I 0

σ 0 ,h 0 ---→ I 1 σ 1 ,h 1 ---→ I 2 . . ., where I 0 = I and σ i ∈ Σ st ∪ Σ fd ∪ Σ ind for all i.
A terminating chase sequence ends with a failure or an instance that triggers no dependency in Σ st ∪ Σ ind ∪ Σ fd . Since at each step we non deterministically trigger a tgd and egd, then the chase returns different instances. In general, given a relational schema R, a set of set of tgds and egds Σ, and a target schema S, a chase is a relation

chase ⊆ Inst(R) × 2 Σ × Inst(S).
But, if Σ is composed only of egds or tgds that do not have existential quantifiers then the chase is a function because returns only one target instance such that J = chase(I, Σ).

Universal solution

Given a data exchange setting and a source instance, there might be no solution or possibly infinite number of solutions, and a considerable amount of work has focused on finding universal solutions that represent the entire space of solutions. Intuitively, a universal solution is the most general solution that is included in all specific solutions.

As we shall see later on, universal solutions are useful for computing answers to a given query over all solutions. We illustrate the significance of being a particular and general solution by their comparison in the following example.

Example 1.3.6. Recall the solution in Figure 1.9 denoted by J and the solution in Figure 1.4 denoted by J 1 . We make the following observations.

• J 1 contains data values not present in the source instance e.g., author Lucia and the conference name AMW. Also this solution contains facts that cannot be derived from source instance using st-tgds. For instance, the publication with title

On algebraic connectivity of graphs is in the conference ISWC.

• In J 1 , all authors are from the same country.

• On the other hand, J contains only data values that are present in the source instance and null values invented to satisfy target constraints. Also, J contains only facts that are derived from source instance.

Comparing these two solutions, we observe that J 1 has been constructed with some additional information that makes it more specific solution than J. Furthermore, we see all the information of J can be found in J 1 , but not all the information of J 1 can be found in J.

We use homomorphisms to compare solutions: we say that J subsumes J if there is a homomorphism from J to J .

Example 1.3.7. We define a homomorphism h from J to J 1 such that h(J) ⊆ J 1 as follows.

h(⊥ 4 ) = ⊥ 1 h(⊥ 10 ) = ⊥ 1 h(⊥ 11 ) = ⊥ 1 h(⊥ 12 ) = ⊥ 1 h(⊥ 15 ) = ICDT h(⊥ 18 ) = ICDT h(⊥ 21 ) = ISWC h(⊥ 16 ) = 2019 h(⊥ 19 ) = 2019 h(⊥ 22 ) = 2019 h(⊥ 5 ) = ⊥ 2 h(⊥ 6 ) = ⊥ 2 h(⊥ 13 ) = ⊥ 2 h(⊥ 7 ) = ⊥ 3 h(⊥ 14 ) = ⊥ 3 h(⊥ 17 ) = Peru h(⊥ 20 ) = Peru h(⊥ 23 ) = Chile
We start by mapping all tuples of Conference from J to J 1 using h previously defined such that the image of every tuple of J can be found in J 1 . For instance, the tuple Finally all tuples of Publication from J are mapped to J 1 . For instance, the tuple Publication(1, Tutoring. . . , ⊥ 5 ) is mapped to Publication(1, Tutoring. . . , ⊥ 2 ) by applying h(⊥ 5 ) = ⊥ 2 . These mappings seen in Figure 1.10 prove that J 1 is subsumed by

J.
A universal solution subsumes every solution from the set of solutions for a given instance w.r.t. a data exchange setting. Formally, we define a universal solution as follows.

Definition

Existence of universal solution

As we have mentioned before, there are cases where chase sequence is infinite for a given instance and a data exchange setting. However in such cases, a solution may still exist. In the Example 1.3.5 we have presented an infinite chase sequence for a setting and a source instance, yet in Figure 1.11 we present a number of solutions. It has proven in [Fagin et al. 2005a] that infinite chase implies there is no finite universal solution. In solution is seen in Figure 1.12. In general, for any i ∈ N, we can construct J i that corresponds to a cycle of length i and uses 2 * i -2 null values. We observe that if a solution J exists and there is a homomorphism from J to J i then J needs 2 * i -2 different null values. So if a universal solution exists then a homomorpshim exists from J to J i for any i that belongs that set of natural numbers, which is an infinite set.

J 1 Emp Sup id name super id emp id 1 Jose 1 1 J 2 Emp Sup id name super id emp id 1 Jose ⊥ 1 1 ⊥ 1 ⊥ 2 1 ⊥ 1 J 3 Emp Sup id name super id emp id 1 Jose ⊥ 1 1 ⊥ 1 ⊥ 2 ⊥ 3 ⊥ 1 ⊥ 3 ⊥ 4 1 ⊥ 1
Therefore, J would have infinite null values. In fact, chase is attempting to construct an instance that is a path that never ends.

Certain query answering

Next, we consider the problem of query answering. We know the definition of an answer to a query over a single database. Here the challenge is to define what is an answer to a query over a set of instances. The framework possible-world semantics allows to answer this question.

Jose This framework serves as inspiration for defining certain answers to a query over a set of solutions. Formally, we define certain answers as follows.

1 Emp S u p Jose 1 Emp ⊥ 1 S u p S u p ⊥ 2 Emp Jose 1 Emp ⊥ 1 ⊥ 2 Emp ⊥ 3 S u p Sup S u p ⊥ 4 Emp J 1 J 2 J 3 • • •
Definition 1.3.9. Given a data exchange setting E = (R, S, Σ st ), a source instance I and a query Q over the target schema S, an answer to query Q with respect to I is

certain if this answer is an answer to query Q in every solution to I w.r.t. E.

In case of Boolean queries, true is the certain answer to Boolean query Q if true is the answer to query Q in every solution to I w.r.t. E. We illustrate answers that are certain and not certain to a query in the following example.

Example 1.3.10. Recall the solution J in Figure 1.9 and the solution J 1 in Figure 1.4

for the source instance I in Figure 1 A straightforward attempt at computing certain answers is to evaluate the query in all solutions and to return the intersection of all answers corresponding to each solution. However this attempt is not feasible when the number of solutions is infinite. An alternative solution, which is proposed by Fagin et.al [Fagin et al. 2005a], is the evaluation of the query over a universal solution.

J 1 J Q 2 true false Q 3 true true
Example 1.3.11. Consider the source instance I in Figure 1.1 and the data exchange setting E 0 in Example 1.3.1. Take J that is a universal solution and the set of answers to Q 1 . Tuples that contain null values are dropped from the result obtaining that (ICDT) and (ISWC) are certain answers. Also for the Boolean query Q 3 take J and true is the certain answer.

Computing certain answers is defined as follows. We fix a source instance I, data exchange setting E and a query Q, we denote the set of certain answers for a query ϕ of I w.r.t. E by cert E (Q, I). Formally, certain answers is defined by the intersection of the set of answers to query Q over each solution of the set of solutions to I w.r.t. E, in symbols

cert E (Q, I) = {QA(Q, J) | J ∈ sol E (I)}.

Consistency

A data exchange setting is inconsistent if there is a source relational instance for which the set of solutions is empty. If a data exchange setting admits solutions for every source instance then it is called consistent. We illustrate a setting that is not consistent and how it becomes consistent with another set of source constraints.

Example 1.3.12. Recall the data exchange setting in Example 1.3.1. This setting is not consistent because there is no solution for the source instance in Figure 1 This fd fails because in the source instance of conference database the schema allows to have conferences with the same name but different places. We can prevent it by making the set of attributes Name, Year a secondary key, i.e, adding the following functional dependency in the source schema:

Conference : Name Year → Place.

Source instances that contain same conference name and different places will be removed for consideration, and in fact there is a solution for every consistent source instance.

Checking consistency is defined as a decision problem that takes as input a data exchange setting and outputs if the setting is consistent or not. Formally, we define consistency as follows.

Definition 1.3.13. A data exchange setting E is consistent if every consistent source instance admits a solution.

Resource description framework

We present the well-known framework for publishing data on the web that is called • object that identifies the value of the property being another resource or literal value such as "29".

RDF specifies restrictions on the subject and predicate of a triple: the subject cannot be a literal, and the predicate must be an IRI.

As we have seen in format N-Triples, the writing of triples is too verbose. Due to this fact, a set of prefixes is used to shorten the writing of IRIs. A prefix is a short name concatenated with the symbol ":". Every prefix is associated to a unique IRI called namespace. A namespace is contained in a full IRI and it is usually shorten than the full IRI. A set of IRIs can share the same namespace. For instance, one namespace in the RDF model of math researchers is https://www.univ-lille.fr. We define the prefix ulille:

to be associated to this namespace. Then, the writing of IRIs are shortened as seen in Turtle format (Figure 1.18). For instance, the full IRI https://www.univ-lille.fr/jlozano is rewritten as ulille:jlozano. The set of prefixes used in this manuscript is shown in Now, we consider an RDF graph in Figure 1.17 that describes the same researcher "Jose Lozano" with the same information in Figure 1.16 and also describes his colleague "Edith Tupac" with the following information: she works also in the "University of Lille" and has authored two papers: "Tree automata for infinite trees" and "Containment problem for Register Automata". The IRI node is shown with an oval and the literal value within quotes. We point out that :b 1 is a blank node shown with an oval although is not an IRI.

ulille:etupac foaf:name "Edith Tupac"; ex:masters dbp:Logic; ex:worksIn ulille:; ex:authors "Tree automata for infinite trees" , "Containment problem for Register Automata". The outgoing edges of the IRI node ulille:etupac is serialized in Turtle format in Figure 1.19 where we make the following observations:

• when the subject is the same, the set of predicate-object is grouped into a list separating each of them by ";" such as for the subject ulille:etupac; and

• when the subject and predicate are the same, the objects are grouped into a list separating each of them by "," such as for ex:authors.

Given a blank node that has one or more outgoing edges, Turtle simplifies the seri-

RDF graph

An RDF graph (or simply a graph) is a finite set G of triples such that

G ⊆ (Iri ∪ Blank) × Iri × (Iri ∪ Blank ∪ Lit).
We view G as an edge labeled graph by interpreting a triple (s, p, o) as a p-labeled edge from the node s to the node o. The set of nodes of G, denoted nodes(G), is the set of elements that appear on first or third position of a triple in G.

Logic formalization

The relational signature for a graph is G = {Triple} where Triple a relation name of arity three. For a given graph G, we define the relational structure M G over G as

Triple M G = G.

Schemas for RDF graphs

We present the notion of schema based on shapes for RDF graphs used throughout this manuscript. A schema for RDF graph, like a schema for a relational database, defines a structure that a graph should follow and establishes a set of constraints that ensure the integrity of its data. The structure of a graph is given by a set of types that are associated with a node and each type of node comes with a set of constraints. These constraints defined in a type ensure that the number of outgoing edges of a node assigned to the given type is within bounds defined in the constraint. An important use of the schema in RDF is the validation whether those constraints are satisfied over the graph verifying that a node assigned to a given type satisfies the constraints defined in the type. Among the different schemas for RDF graph that have been defined we focus on two of them:

Shape Constraint Language and Shape Expression Schema. Both schema languages are based on the notion of shapes that is analogy to DTD [START_REF] Bray | [END_REF]] and XML Schema (XSD) [START_REF] Thompson | XML Schema Definition Language (XSD)[END_REF]]. SHACL syntax is RDF while ShEx syntax follows a more human-readable grammar defined in [START_REF] Staworko | [END_REF]].

Example 1.5.1. Consider the following shape constraints that capture the structure of the graph G 1 in Figure 1.17. We define four shapes ShTopic, ShAddress, ShUniversity and ShResearcher. We present the set of shape definitions using an abstract syntax as follows:

ShTopic → ex:name :: A shape definition describes a set of triple constraints that restricts the neighborhood with a specific label, the type of the target node and a cardinality that limits the number of outgoing edges with such label. We point out that the labels used in each definition are IRIs and the set of prefixes are defined in Table 1.1. Now, we describe how graph G 1 satisfies the shapes schema presented above by describing each shape definition and how G 1 satisfies it.

The shape ShTopic requires:

• exactly one edge labeled with ex:name to a literal node.

In G 1 , the nodes dbp:Mathematics and dbp:Logic satisfy the shape constraint ShTopic because for each node there is only one outgoing edge labeled with ex:name.

The shape ShAddress requires:

• exactly one edge labeled with ex:city to a literal node; and

• exactly one edge labeled with ex:zip to a literal node.

In G 1 , the node :b 1 satisfies the shape constraint ShAddress because there are only two outgoing edges with labels ex:city and ex:zip.

The shape ShUniversity requires:

• exactly one edge labeled with ex:name to a literal node; and

• exactly one edge labeled with ex:address to node of type ShAddress.

In G 1 , the node ulille: satisfies ShUniversity because there is only one outgoing edge with label ex:name and one outgoing edge with label ex:address.

The shape ShResearcher requires:

• exactly one edge labeled with foaf:name to a literal node;

• zero or more edges labeled with foaf:knows to nodes that satisfy shape ShResearcher;

• one or more edges labeled with ex:masters to nodes that satisfy shape ShTopic;

• zero or more edges labeled with ex:authors to literal nodes;

• exactly one edge labeled with ex:worksIn to a node that satisfies shape ShUniversity; and

• zero or one edges labeled with foaf:mbox to a literal node.

The node ulille:jlozano satisfies the triple constraints of ShResearcher on the labels foaf:name, foaf:knows, ex:masters, ex:worksIn and foaf:mbox because the number of outgoing edges with these labels is within the bounds of the interval defined by each triple constraint. The constraint with label ex:authors also is satisfied even if there is no outgoing edge with this label since the minimum number of outgoing edges is zero. For the node ulille:etupac, it is easy to see that the triple constraints of ShResearcher on the labels foaf:name, ex:masters, ex:authors, ex:worksIn are satisfied. The triple constraints with labels foaf:knows and foaf:mbox are satisfied even if there are no outgoing edges because the minimum number of outgoing edges is zero.

We point out the fact that there is an outgoing edge with ex:age from ulille:jlozano does not make that this node not to satisfy ShResearcher since there is no constraint with label ex:age in this shape. Finally, the literal nodes of G 1 are assigned to a shape called Lit that does not constraint the neighbors of literal nodes. We say that the graph G 1 satisfies the shapes schema because for every shape and every node associated with a shape, the set of constraints is satisfied on the outgoing edges of the node.

In the above exampe, if we define in XSD the type Lit then these shape definitions can be written in SHACL as shown in Figure 1.21 and ShEx as shown in Figure 1.22.

As we see in these figures, the shape names are IRIs where ex is the prefix defined in Now, we describe differences between SHACL and ShEx. We point out that in SHACL we have to declare which nodes are going to be validated in the shape. For instance the triple (ex:ShTopic, sh:targetNode, dbp:Mathematics) specifies that the node dbp:Mathematics must be validated with respect to the shape ShTopic. Also, a triple constraint in SHACL is called a property shape. Compared to SHACL, ShEx does not require the nodes to be specified in the definition while SHACL does. Also, ShEx does not use too many words to express a triple constraint. This makes an easy comprehension of the constraint language. Also, another difference is that ShEx defines a validation method that associates a shape to a node when the node satisfies the constraints imposed by the shape while SHACL validates a graph from the target nodes declared for a shape.

Typed RDF graph

Validation of graphs requires assigning type names to nodes, in particular, with a typing function. Together the graph and the typing function is called a typed RDF graph. We illustrate the notion of typed RDF graph with the following example.

Example 1.5.2. Consider the RDF graph G 0 in Figure 1.17 and the set of type names T 0 = {ShResearcher, ShTopic, ShUniversity, ShAddress}.

We define a typing 0 function for the nodes of G 0 . Let T ⊆ V

(1) R be a finite set of type names. A T-typed graph is a pair (G, typing), where G is a graph and typing : nodes(G) → 2 (T∪{Lit}) is a function that assigns to every node of the graph G a (possibly empty) set of types, where Lit is the special type for literal nodes.

Shape constraints language

We now introduce the abstract Shape Constraint Language. Its syntax is very similar to ShEx compact syntax. We fix a finite set of shape names T ⊆ V

(1) R . A triple constraint over T ∪ {Lit} is a tuple (p, T, µ) ∈ Iri × (T ∪ {Lit}) × {1, ?, *, +}, where

• p is referred to as a property label,

• T is referred to as a target shape

• µ is referred to as a multiplicity that constraints the number of occurrences of outgoing edges. We interpret multiplicities with intervals as follows (an interval

[n; m] is a finite representation of the set {k | n ≤ k ≤ m}).
-1 is exactly one and its corresponding interval is [1; 1],

-? is at most one and its corresponding interval is [0; 1], -* is any and its corresponding interval is [0; ∞], and -+ is at least one and its corresponding interval is

[1; ∞].
The intervals 1, ?, *, + are called basic intervals.

We often write a triple constraint (p, T, µ) as p :: T µ . We denote the set of triple constraints over a set of types T ∪ {Lit} by triConstr .

In this manuscript (except for Chapter 6), shapes schemas are interpreted under open interpretation, which means that a graph satisfies a shapes schema even if there is a triple that is not constrained by the shapes schema. Now, a shapes schema is a pair S = (T, δ), where

• T is a finite set of shapes, and

• δ : T → P(triConstr T∪{Lit} ) is a function called shape definition that maps every symbol T ∈ T to a finite set of triple constraints over T ∪ {Lit}.

In this manuscript, we focus on deterministic shapes schemas, i.e. for every type name T and for every property label p ∈ Iri there is at most one triple constraint using p. Now, we define the semantics of shapes schema. Given a graph G, the outbound neighborhood of a node n ∈ nodes(G) with respect to an edge label p ∈ Iri is

out G (n, p) = {o | (n, p, o) ∈ G}.
Take a T-typed graph (G, typing), a node n, and a triple constraint p :: T µ . The node n satisfies the triple constraint p :: T µ if

• every neighbor node of n with edge label p has type T , i.e., for any m ∈ out G (n, p) it holds that T ∈ typing(m); and

• the cardinality of out G (n, p) is within the interval of µ.

A T-typed graph (G, typing) satisfies a shapes schema S = (T, δ) if for any n ∈ nodes(G) and any T ∈ typing(n) the node n satisfies every triple constraint in δ(T ). Also, we define the language of a shapes schema as the set L(S) = {(G, typing) | (G, typing) |= S}.

We define a graphical representation of shapes schema called shape graph, denoted by G S . A shape graph of a shapes schema S = (T, δ) over T is a pair G S = (T ∪ {Lit}, E S ) where T ∪ {Lit} is the set nodes and E S is the set of edges with two labels defined as follows.

E S = {(T, p, µ, S) ∈ T × Iri × {0, 1, ?, *, +} × (T ∪ {Lit}) | p :: S µ ∈ δ(T )},

Logic formalization

The relational signature of a shapes schema S and a typing graph (G, typing) over a set of types T is R S = T ∪ {Lit}. We observe that any T-typed graph (G, typing) can be easily converted to a relational structure over the relational signature G T = {Triple} ∪ T ∪ {Lit}. Consequently, in the sequel, we may view a T-typed graph (G, typing) as the corresponding relational structure over G T . For a given shapes schema S and a typed graph (G, typing), we define the relational structure M S over R S ∪ G T corresponding to (G, typing) with

T M S = {n ∈ nodes(G) | T ∈ typing(n)} for any T ∈ T, Lit M S = {n ∈ nodes(G) ∩ Lit | Lit ∈ typing(n)}.
Additionally, we define a function called types over the relational structure of a typed RDF graph G where its input is a node and outputs the types associated in the graph, in symbols

types G (n) = {T | T (n) ∈ G}.

Shape constraints as dependencies

A deterministic shapes schema S over a set of types T can be captured with a set Σ S of dependencies. Next, we define the following rules that are used to capture a triple constraint p :: S µ that is in the definition of a type T :

• the type propagation rule:

TP(T, p, S) = ∀x, y. T (x) ∧ Triple(x, p, y) ⇒ S(y),

• the predicate existence rule:

PE(T, p) = ∀x. T (x) ⇒ ∃y. Triple(x, p, y),
• the predicate functionality rule:

PF(T, p) = ∀x, y, z. T (x) ∧ Triple(x, p, y) ∧ Triple(x, p, z) ⇒ y = z .
We point out that in terms of the classical relational data exchange, TP and PE are target tuple generating dependencies (t-tgds), and PF is an equality generating dependency (egd). We capture the shapes schema S with the following set of dependencies:

Σ S = {TP(T, p, S) | T ∈ T, p :: S µ ∈ δ(T )} ∪ {PE(T, p) | T ∈ T, p :: S µ ∈ δ(T ), µ ∈ {1, +}} ∪ {PF(T, p) | T ∈ T, p :: S µ ∈ δ(T ), µ ∈ {1, ?}}.
In the sequel, the set of TP-dependencies of S is denoted by Σ TP S , the set of PEdependencies of S by Σ PE S and the set of PF-dependencies of S by Σ PF S . We state the following lemma to prove that a given shapes schema is equivalent to a set of TP, PF, and PE dependencies.

Lemma 1.5.1. For every shapes schema S = (T, δ) and every T-typed RDF graph

(G, typing), (G, typing) satisfies S iff (G, typing) |= Σ S .
Proof. We fix a T-typed graph (G, typing) and shapes schema S = (T, δ).

For the ⇒ direction, we prove by contraposition. Assume that (G, typing) |= Σ S .

Our goal is to prove (G, typing) does not satisfies S. By definition of entailment, there is a dependency σ ∈ Σ S that is not satisfied. The dependency σ can be of the following forms:

• TP(T s , p, T o ). By construction of Σ S , the dependency σ occurs when a triple constraint is of the form p :: T µ o where µ ∈ {1, ?, *, +}. Since σ is not satisfied, (s, p, o) ∈ G and T s ∈ typing(s). Because the node o ∈ nodes(G), it must hold T o ∈ typing(o). But this fact is not, then the T-typed graph (G, typing) does not satisfy S.

• PE(T s , p). By construction of Σ S , the dependency σ occurs when a triple constraint is of the form p :: T µ o for some µ ∈ {1, +} and some T o ∈ T. Since σ is not satisfied, then T s ∈ typing(n) for some node n ∈ nodes(G). Because the cardinality of outbound neighborhood of n w.r.t. an edge label p is 0, the T-typed graph (G, typing) does not satisfy S.

• PF(T s , p). By construction of Σ S , the dependency σ occurs when a triple constraint is of the form p :: T µ o for some µ ∈ {1, ?} and some T o ∈ T. Since σ is not satisfied, we have that (s, p, o 1 ) ∈ G and (s, p, o 2 ) ∈ G and T s ∈ typing(s), which makes the T-typed graph (G, typing) to not satisfy S.

For the ⇐ direction, assume that (G, typing) |= Σ S . Our goal is to prove (G, typing)

satisfies S. We prove by contradiction. Suppose that (G, typing) does not satisfy S.

Then there is a node n ∈ nodes(G) and T ∈ typing(n) for which there is a triple constraint p :: S µ ∈ δ(T ) that is not satisfied. This can occur because of the following two cases:

• There is a triple (n, p, m) ∈ G such that S ∈ typing(m). Since T (n) and

Triple(n, p, m) are facts in (G, typing) and (G, typing) |= TP(T, p, S), then S(m) is a fact in (G, typing). Thus, S ∈ typing(m); a contradiction.

• The cardinality of the outbound neighborhood of n w.r.t. p is not in the interval of µ.

-

When µ = 1 and |out G (n, p)| = 1. It follows that PF(T, p) ∈ Σ S and PE(T, p) ∈ Σ S . Since (G, typing) |= Σ S , then |out G (n, p)| = 1; a contra- diction. -When µ = ? and |out G (n, p)| > 1. It follows that PF(T, p) ∈ Σ S . Since (G, typing) |= Σ S , then |out G (n, p)| ≤ 1; a contradiction. -When µ = + and |out G (n, p)| < 1. It follows that PE(T, p) ∈ Σ S . Since (G, typing) |= Σ S , then |out G (n, p)| ≥ 1; a contradiction.
Chapter 2

Relational to RDF data exchange

In this chapter, we present the framework for relational to RDF data exchange and the problems that we address in this manuscript.

Relational to RDF data exchange setting

In this section, we formalize the relational database to RDF graph data exchange problem and, compare to relational data exchange, we identify two new challenges: converting data values from databases to IRIs and associating the shapes schema for constraining the RDF graph. For the first challenge, we use IRI constructors. An IRI constructor is a function that takes a data value and converts it to a IRI. For the second challenge, we use the signature of shapes schema in the rule specification. We illustrate our approach with the following example. and the set of inclusion dependencies:

Registration[Idc] ⊆ Conference[Idc] Registration[Idp] ⊆ Researcher[Idr ] Talk[Idp Idc] ⊆ Registration[Idr Idc] Collaborator[Idr Idc Title] ⊆ Talk[Idr Idc Title] Researcher[Team] ⊆ UniTeam[Team]
ShUniversity → ex:name :: We show how to define mappings between a database schema and a shapes schema.

We want to export this database to an RDF, where we want to export universities, researchers, papers and conferences. For each university, we want to export its researchers and for each researcher their papers. Also we want to map the experience of a researcher on a topic, we want to export the information on conferences where the paper was published and the fact that a researcher knows other researcher when they wrote the same paper. The graph must follow the structure that is described in Figure 2.1.

We recall that RDF requires IRIs as their nodes and the information stored in the database are data values. IRI constructors solve the problem of mapping data values to IRIs. We can define a range of IRI constructors according to the needs. The IRI constructors are used for the task of specifying mappings from a relational schema to a shapes schema.

Example 2.1.2 (cont. Example 2.1.1). We define the following IRI constructors and we point out that each constructor is associated to a shape name:

• f uni2iri takes the name of the university and replaces blank spaces with character "-". Then the function adds with the prefix univ:. For instance, f uni2iri (University of Lille) = univ:university-of-lille;

• f top2iri adds the prefix dbp: with the name of the topic. For instance, f top2iri (Maths) = dbp:maths;

• f res2iri takes the id of the researcher and retrieves from the academic institute database the name associated to the id. Then, this function generates a shorten identifier for this name. Finally, the function adds the prefix ulille:res/. For instance for id with value 1, the name is jose lozano and the function returning: f pap2iri (icdt, 2019, Skolemization of prenex formulas) = dblp:paper#2; f pap2iri (iswc, 2019, On algebraic connectivity of graphs) = dblp:paper#3.

f res2iri (
• f con2iri takes the name and year of the conference and adds the prefix dblp:. For instance,

f con2iri (ICDT, 2019) = dblp:icdt2019.
Now, we introduce nodes with IRI constructors in the mapping definition. We also need to associate types to the nodes in the transformation rules.

Example 2.1.3 (cont. Example 2.1.2). In this case, the set of transformation rules are specified as follows:

• a university is mapped to a node of shape ShUniversity. Formally,

UniTeam(x 1 , x 2 , x 3 ) ⇒ Triple(f uni2iri (x 2 ), ex:name, x 2 ) ∧ ShUniversity(f uni2iri (x 2 )); (2.1)
• the expertise of researcher is mapped to a node of shape ShTopic. Formally,

Researcher(x 1 , x 2 , x 3 , x 4 , x 5 ) ⇒ Triple(f top2iri (x 4 ), ex:name, x 4 ) ∧ ShTopic(f top2iri (x 4 )); (2.2)
• a researcher is mapped to a node of shape ShResearcher with the outgoing edges that identify name (foaf:name), mail (foaf:mbox), and a topic where the researcher is an expert (ex:masters). Formally,

Researcher(x 1 , x 2 , x 3 , x 4 , x 5 ) ⇒ Triple(f res2iri (x 1 ), foaf:name, x 2 ) ∧ Triple(f res2iri (x 1 ), ex:masters, f top2iri (x 4 )) ∧ Triple(f res2iri (x 1 ), foaf:mbox, x 3 ) ∧ ShResearcher(f res2iri (x 1 )); (2.3)
• a talk is mapped to a node of shape ShPaper with an outgoing edge ex:in that identify the name of the paper (ex:name) and the conference where talk is presented (ex:in). Formally,

Talk(x 1 , x 2 , x 3 ) ∧ Conference(x 2 , x 4 , x 5 , x 6 ) ⇒ Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:name, x 3 ) ∧ Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:in, f con2iri (x 4 , x 5 )) ∧ ShPaper(f pap2iri (x 4 , x 5 , x 3 )) (2.4)
• a conference is mapped to a node of shape ShConference with its name, year and place. Formally,

Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ Triple(f con2iri (x 2 , x 3 ), ex:name, x 2 ) ∧ Triple(f con2iri (x 2 , x 3 ), ex:year, x 3 ) ∧ Triple(f con2iri (x 2 , x 3 ), ex:place, x 4 ) ∧ ShConference(f con2iri (x 2 , x 3 )); (2.5)
• whenever a researcher is part of a team that corresponds to a university, there is an edge ex:worksIn between a node corresponding to the researcher and a node corresponding to the university. Formally,

Researcher(x 1 , x 2 , x 3 , x 4 , x 5 ) ∧ UniTeam(x 5 , x 6 , x 7 ) ⇒ Triple(f res2iri (x 1 ), ex:worksIn, f uni2iri (x 6 )); (2.6)
• for any talk presented or collaborated on by a researcher there is an edge from node corresponding to this researcher to the node corresponding to the talk. Formally, this involves two st-tgds respectively

Researcher(x 1 , x 2 , x 3 , x 4 , x 5 )∧Talk(x 1 , x 6 , x 7 )∧Conference(x 6 , x 8 , x 9 , x 10 ) ⇒ Triple(f res2iri (x 1 ), ex:authors, f pap2iri (x 8 , x 9 , x 7 )) (2.7) Researcher(x 1 , x 2 , x 3 , x 4 , x 5 ) ∧ Collaborator(x 6 , x 7 , x 8 , x 1 ) ∧ Conference(x 7 , x 9 , x 10 , x 11 ) ⇒ Triple(f res2iri (x 1 ), ex:authors, f pap2iri (x 9 , x 10 , x 8 )); (2.8)
• and whenever a researcher and an other researcher authored a talk, there is an edge foaf:knows from the node corresponding to the former researcher to the node corresponding the later researcher. Formally,

Collaborator(x 1 , x 2 , x 3 , x 4 ) ⇒ Triple(f res2iri (x 1 ), foaf:knows, f res2iri (x 4 )).
(2.9) ulille:res/jlozano "Jose Lozano" Formalization. We now formalize the data exchange setting that we work throughout this manuscript. We define a library of IRI constructors as a pair F = (F, F ), where F is a set of function names, and F is their interpretation i.e., a mapping that assigns to

every IRI constructor name f ∈ F a function f F : ConstLit k ⇒ Iri,
where k is the arity of f . A library F is non-overlapping if F assigns to elements of F injective functions with pairwise disjoint ranges. In the sequel, we consider settings where the library is non-overlapping.

We adapt the definition of relational data exchange to treat graphs and define the setting as follows.

Definition 2.1.4. A constructive relational to RDF data exchange setting is a tuple

E = (R, S, Σ st , F), where • R = (R, attrs, Σ fd , Σ ind ) is a source relational schema, • S = (T, δ) is a target shapes schema, • F = (F, F ) is a library of non-overlapping IRI constructors,
• Σ st is a set of source-to-target tuple generating dependencies (st-tgds) whose bodies are conjunction of atomic formulas over R and whose heads are conjunction of atomic formulas over G T ∪ F where G T = {Triple, Lit} ∪ T and these formulas do not contain existential variables and use IRI constructors.

Moreover, for any st-tgd σ ∈ Σ st , we assume there is no monadic atom of the following form:

• T (x) with sequence of variables of length one x ⊆ vars(σ) and T ∈ T in the head of σ and

• Lit(f (x)) with some IRI constructor f ∈ F and some sequence of variables

x ⊆ vars(σ).

In the sequel, we adapt the definition of solution of relational data exchange as follows.

Definition 2.1.5 (Solution). Take a data exchange setting E = (R, S, Σ st , F), and let I be a consistent instance of R. Then, a solution to I w.r.t. E is any T-typed graph J such that I ∪ J ∪ F |= Σ st and J satisfies the shapes schema S. The set of solutions to

I w.r.t. E is denoted as sol E (I).
Additionally, we consider the notion of core pre-solution, which is the result of exporting the relational data to triples with Σ st and then propagating types with Σ TP S (without creating any new nodes). We define the core pre-solution as follows.

Definition 2.1.6 (Core pre-solution). The core pre-solution for I to E is the unique minimal graph J 0 that satisfies J 0 ∪I |= Σ st ∪Σ TP S , where Σ TP S is the set of TP-dependencies generated by the shapes schema S.

We observe that given a consistent instance I of R and constructive data exchange setting E, the core pre-solution J 0 to I w.r.t. E always exists because there is always a finite chase sequence on I with Σ st and Σ TP S . We have a finite chase sequence because the chase does not introduce any null values and there is no equality dependencies. By property of the chase with these kind of dependencies [Fagin et al. 2005a], the result is unique and minimal because no new null values are added.

R2RML: proof of concept

In this section, we describe the core definitions and assumptions of R2RML that provide rationale for using constructive data exchange to model the process of exporting The logical table of a triple map is a SQL query and its result is mapped to RDF triples. It may be either (i) a table, (ii) or a complex SQL query. A table is represented by a resource that has exactly one rr:tableName property with the string denoting the table. A SQL query is represented by a resource with exactly one rr:sqlQuery property whose value is a SQL query string. A logical table row is a tuple obtained from the execution of the SQL query in the input database. Each row in the logical table entails a triple for every predicate object. Given a row, all triples generated from it share the same subject. Predicate, object and subject maps are constructed using term maps.

A term map specifies what is the RDF term used for a subject, predicate, or object.

For a subject, the RDF term is always an IRI template, for the predicate the RDF term is an IRI value, for an object the RDF term is either an IRI template or RDF constant (literal or IRI value). An IRI template indicates how to construct an IRI using an IRI and attribute values from rows. These elements are represented as follows:

• If the element is an IRI template then it is represented by rr:template property whose value is an IRI that includes the name of attributes that come from the SQL query or table result. An IRI template generates a unique IRI.

• If the element is an attribute name then it is represented by rr:column whose value is an attribute name.

• If the element is an RDF constant then it is represented by rr:constant whose value is an IRI or literal value.

A subject map may specify zero or more class IRI's represented by the rr:class property.

The value of the property must be a valid IRI. A term map when is used in an object map optionally allows to specify the datatype (rr:datatype) in case of an attribute name and RDF constant. A predicate map is specified with rr:predicate property. Finally, the object map is specified with rr:objectMap.

Talk(x 1 , x 2 , x 3 ) ∧ Conference(x 2 , x 4 , x 5 , x 6 ) Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:name, x 3 ) Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:in, f con2iri (x 4 , x 5 )) ex:ShPaper(f pap2iri (x 4 , x 5 , x 3 ))
Figure 2.5: A R2RML mapping captured by a constructive st-tgd. Now, we argue that constructive st-tgds are suitable for modeling a large fragment of R2RML. We show a translation of R2RML to constructive st-tgds.

Talk(x 1 , x 2 , x 3 ) ∧ Conference(x 2 , x 4 , x 5 , x 6 ) ⇒ Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:name, x 3 ) ∧ Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:in, f con2iri (x 4 , x 5 )) ∧ ex:ShPaper(f pap2iri (x 4 , x 5 , x 3 ))
Every triple map gives one constructive st-tgd. For instance, we consider the R2RML mapping shown in Figure 2.5 that exports contents of relational database presented in Example 1.1. This mapping takes the result of executing the query specified in rr:sqlQuery and generates triples with subject nodes of class ex:ShPaper and two outgoing edges with labels ex:name and ex:in. The construction of a constructive st-tgd is as follows. We take the SQL query of rr:sqlQuery and convert to a conjunction of relational atoms where the shared variables are in the positions corresponding to the attributes used in the join or cross product with equality of attributes and the other positions are filled with fresh variables. If no join or cross product with equality of attributes is present in the query, then there are no shared variables. We only support natural, inner joins and cross product with equality of attributes. As a result, we have the following conjunction of atoms for the body of the constructive st-tgd

Talk(x 1 , x 2 , x 3 ) ∧ Conference(x 2 , x 4 , x 5 , x 6 )
where x 2 corresponds to the position of the attribute Idc used to do the natural join. We observe that the interpretation of this body of a st-tgd is different from the interpretation of the SQL query. However, if no attributes are specified in the projection, but it is used the symbol * , then the interpretation of the body of a st-tgd is the same as the interpretation of the query. We point out that SQL projections, where not all attributes are specified, are not captured by the body of a st-tgd, but the interpretation of a R2RML mapping generates the same result that the interpretation of a st-tgd generates. Now, we take the subject map and assume it is represented by an IRI template. We create a function term with a function symbol where the arguments are the variables that appeared in the position of the attributes name, year and title. In our mapping, we construct the following function term

f pap2iri (x 4 , x 5 , x 3 )
where x 4 , x 5 corresponds to the attributes name and year of Conference, and x 3 corresponds to the attribute title of Talk. Then, for each predicate object map, we create a triple atom where a function term is created for the subject map. We dedicate a unique function symbol to each IRI template and assign the IRI template as the interpretation of the function symbol. This function term is placed in the subject position of the triple atom. The value of the term map of the predicate map is placed in the predicate position of the triple atom. Finally, we take the object map. If the term map is an IRI template, we create a function term as done for the subject map. If the term map is a value, then we place the value directly in the st-tgd. If the value is an attribute name, then we put the variable that appears in the position of the attribute of some relation being in the query.

If the rr:class property is specified, then we create a monadic relational atom where the name of this relational atom is the name specified with rr:class and the argument of this monadic relational atom is the function term created for the subject map. Following this process, we obtain that the head of the constructive st-tgd is as follows:

ex:ShPaper(f pap2iri (x 4 , x 5 , x 3 )) ∧ Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:name, x 3 ) ∧ Triple(f pap2iri (x 4 , x 5 , x 3 ), ex:in, f con2iri (x 4 , x 5 )).
We make several assumptions in the process above and not all R2RML follow those assumptions. Still we cover a large fragment of R2RML where no aggregate functions are present and no RDF data types are declared in the R2RML mappings. We discuss the limitations of our framework to capture R2RML: not every R2RML mapping has an equivalent constructive st-tgd interpretation. Concerning the SQL query, aggregate queries are not convertible to constructive st-tgds. For the object map, we do not capture the optional property that specifies the type of literal values because we do not have in the shapes schema. However, we can extend the framework by adding types to relational database and types to shapes schema but will require to lead with all the interoperability issues because XSD datatypes are not the same as SQL datatypes. Also this extension will arise technical complications in the study of consistency problem, but the complexity of the theoretical model of constructive st-tgds is the same. Therefore, for simplicity we abstract RDF datatypes for our consideration. Aggregation queries can not be handled in any extension of our framework.

Problems of interest

In this manuscript, we study several problems related to relational to RDF data exchange described below.

Checking consistency

The ability to issue warnings that a data exchange setting does not admit solutions for some source instance would be the most welcome feature for a data administrator. A relational to RDF data exchange setting is consistent if for every source instance, there is a graph that satisfies the shapes schema.

Example and different places in the conference table. These tuples make the graph in Figure 2.6b contain two outgoing edges with the same label from node dblp:icdt. However, our shapes schema requires every conference to have precisely one place.

We study techniques to identify if a relational to RDF data exchange setting is consistent in Chapter 3.

Computing certain answers

Given a relational to RDF data exchange setting, certain answers to query Q w.r.t. a source instance I are answers present in every solution for I and the data exchange setting. We distinguish two types of shapes schemas: non-recursive and recursive. Relational data exchange framework can be used to compute certain answers for nonrecursive shapes schema. Indeed, non-recursive shapes schema can be expressed with super-weakly acyclic tgds, which are known to have chase termination. This guarantees the existence of universal solution, which can be used to compute certain answers for a given query. On the other hand, recursive shapes schema are not equivalent to super-weakly acyclic tgds. Furthermore, a universal solution needs not to exist.

Example 2.3.2 (cont. Example 2.1.1). The shapes schema of this Example 2.1.1 is recursive and, in fact, a finite universal solution for this source database instance I and data exchange setting E 1 does not exist. The chase procedure for this setting will not terminate because node dblp:2019 requires to have a chair, which is not provided by the database. Thus a fresh node is created and associated to a type ShResearcher, which requires to be an author of at least one paper. Again, a fresh node is created and associated to a type ShPaper, which needs to be in a conference. Thus, a fresh node is created and associated to a type ShConference, and so on resulting in an infinite chase sequence as seen in Figure 2.7. In Chapter 4, we propose an alternative notion of universal simulation solution that is suitable for computing certain answers to a subclass of nested regular expressions [Pérez et al. 2010]. We study the complexity of computing certain answers and investigate a minimal-size universal simulation solution whose construction is in low complexity.

dblp:icdt2019 ⊥ 1 ex:chair ⊥ 2 ex:authors ⊥ 3 ex:in ⊥ 4 ex:chair ⊥ 5 ex:authors • • • ex:in

Visual mapping language

Non-expert users may have difficulty to learn mapping languages such the one presented in our framework. We propose a visual mapping language (VML) and an editor that allows to define VML mappings without using formal mapping language. We point out that VML captures a rich and expressive subset of our constructive data exchange setting proposed in Definition 2.1.4.

The specification starts with the tool visualizing in the left side the relational schema and in the right side the shapes schema and the users draw arrows that map objects and attributes from one schema to another as needed. The arrow colors correspond to its role, which are explored in detail in Section 5.4.

Example 2.3.3. Consider a source schema R 1 with three relations Product(pid , name), Supplier(sid , name), and ProdSup(pid , sid ); and a target shapes schema defined as follows.

ShProd → ex:descr :: Lit 1 ; ex:supplied :: ShSupp + ShSupp → ex:name :: Lit 1 In Chapter 5, we describe ShERML, a tool that facilitates the specification of mappings with the use of a visual mapping language.

Schema elicitation

Relational to RDF data exchange setting is defined with the relational schema, set of mappings, and shapes schema. Since RDF is schema-less and R2RML has been introduced recently, then it is conceivable that many mappings have been written without schema. For a legacy reason, numerous settings have no target shapes schema provided.

It is useful to have the shapes schema because it permits to understand the structure of the graph and to check if mappings are well-defined to obtain the desired graph.

Example 2.3.4. We are provided with a relational schema that has the following relations Book(isbn, title, auth id ), Author(auth id , name) and Bio(auth id , bio). The schema also has the following dependencies.

Bio[auth id] ⊆ Author[auth id ] Book[auth id] ⊆ Author[auth id ]
Also, we are given a set of mappings.

Book(x 1 , x 2 , x 3 ) ⇒Triple(f book2iri (x 1 ), ex:isbn, x 1 ) ∧ Triple(f book2iri (x 1 ), ex:title, x 2 ) ∧ Triple(f book2iri (x 1 ), ex:author, f aut2iri (x 3 ); Author(x 1 , x 2 ) ⇒Triple(f aut2iri (x 1 ), ex:name, x 2 ); Author(x 1 , x 2 ) ∧ Book(x 3 , x 4 , x 1 ) ⇒Triple(f aut2iri (x 1 ), ex:book, f book2iri (x 3 )); Author(x 1 , x 2 ) ∧ Bio(x 1 , x 3 ) ⇒Triple(f aut2iri (x 1 ), ex:bio, x 3 ).
The following schema characterizes possible output RDF graphs produced by the mappings.

ShBook → ex:isbn :: Lit 1 ; ex:title :: Lit 1 ; ex:author :: ShAuth 1 ShAuth → ex:name :: Lit 1 ; ex:bio :: Lit ? ; ex:book :: ShBook * Indeed, this schema describes that for a book there might be precisely one isbn, title and it might be written by precisely one author who might have precisely one name, might have or not a biographical information and might have a collection of books potentially empty. This follows from mappings and relational schema.

In Chapter 6, we investigate the problem of generating shapes schemas and identify two desirable properties for the output target schema. We propose an elicitation algorithm.

Related work

Here, we only describe related works on formalizing data exchange applications as data exchange frameworks. For every problem of interest, we will present related work independently in the corresponding sections.

Data exchange problem is studied in different contexts such as graph to graph [START_REF] Barceló | [END_REF] or relational to graph [Boneva et al. 2015]. The frameworks proposed in each context varies according to the type of data that is treated. For our context of relational to RDF, none of the existent frameworks addresses relational to RDF with shapes schemas. We present a list of frameworks and the relation of each framework with our proposal.

The classical relational to relational data exchange framework, which is proposed by Fagin et al. [Fagin et al. 2005a], is composed of a relational source and target schema, source-to-target tuple generating dependencies and target dependencies. et al. 2005]. Solutions are defined as in the relational case. Since DTDs define the structure of trees, we cannot use DTDs as a schema for graphs. Another approach of exchanging hierarchical data is with the use of nested dependencies [Fuxman et al. 2006] as mappings proposed by Fuxman et al. We took from nested dependencies the idea of using function symbols, but not Skolem functions because we fix the functions that are used in the constructive st-tgds.

Direct mapping (DM) [START_REF] Arenas | [END_REF], proposed by W3C, is also a subclass of relational to relational data exchange that exchanges relational data to RDF. DM defines simple transformation rules to generate RDF from relational data such as a rule to generate the subject IRI or a rule to generate triples. The data exchange setting is a tuple composed of the relational source schema that contains the relational signature, primary keys and foreign keys, and a set of st-tgds where the head of each st-tgd is over the triple signature. Authors define properties that the set of st-tgds must satisfied such that the graph contains all the information of the relational database. This setting does not address our problem because we treat target constraints, we do not limit the interpretation of IRI constructors to only concatenation and DM is fixed i.e., the user cannot define it.

Relational to graph data exchange [Boneva et al. 2015] is studied by Boneva et al. and they proposed a setting composed of a relational schema, target constraints and the set of st-tgds expressed with nested regular expressions. Also, the authors proposed a representation of a universal solution that is not a graph but a graph pattern with regular expressions as edge labels. This is a limitation for data exchange where we want to materialize the solution. On the other hand, st-tgds and target tgds from [Boneva et al. 2015] are more expressive than constructive st-tgds.

Finally, graph data exchange is studied by [START_REF] Barceló | [END_REF]] and consists of transforming source edge labeled graph to target edge labeled graph. The authors proposed a setting composed of a set of source and target labels; and the set of st-tgds are expressed as conjunctive nested regular expressions over the set of source and target labels. Similar to Boneva et al., the authors proposed a universal solution that is not a graph but a graph pattern. This setting is not applicable to our case because authors did not consider either source or target constraints.

Chapter 3 Consistency 3.1 The opposite side of consistency: inconsistency

In this section, we define an inconsistent data exchange setting and show the necessary sufficient conditions for inconsistency. Also, we present the properties of a core pre-solution related to identifying sufficient conditions for inconsistency. In the sequel of this chapter, we fix a constructive relational to RDF data exchange setting E = (R, S, Σ st , F), and we consider that the set of st-tgds Σ st is normalized so that for every st-tgd in Σ st , its right-hand side uses exactly one atom. We precise that an instance I of R refers to an instance of the relational schema R where the set of dependencies is empty. Also, we assume a fixed library of IRI constructors F and we define a set of properties w.r.t. a shapes schema S = (T, δ). We denoted this set by Prop S ⊂ Iri, and it is defined as follows:

Prop S = {p | ∃T ∈ T. ∃S ∈ T ∪ {Lit}. ∃µ ∈ {*, 1, +, ?}. p :: S µ ∈ δ(T )}.
We recall that a data exchange setting is consistent if every consistent source instance admits a solution. Since inconsistency is the opposite of consistency, we define it as follows: Definition 3.1.1. A data exchange setting is inconsistent if there is a source instance that does not admit a solution.

We illustrate with the following example an inconsistent setting.

Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ Triple(f con2iri (x 2 , x 3 ), ex:name, x 2 ), (σ 1 ) Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ Triple(f con2iri (x 2 , x 3 ), ex:year, x 3 ), (σ 2 ) Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ Triple(f con2iri (x 2 , x 3 ), ex:place, x 4 ) (σ 3 ) Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ ShConference(f con2iri (x 2 , x 3 )), (σ 4 ) Conference(x 1 , x 2 , x 3 , x 4 ) ∧ Sponsor(x 1 , x 5 ) ⇒ Triple(f con2iri (x 2 , x 3 ), ex:sponsor, f uni2iri (x 5 )), (σ 5 ) Sponsor(x 1 , x 2 ) ⇒ ShUniversity(f uni2iri (x 2 )), (σ 6 ) Sponsor(x 1 , x 2 ) ∧ Conference(x 1 , x 3 , x 4 , x 5 ) ⇒ Triple(f uni2iri (x 2 ), ex:address, x 5 ). (σ 7 )
The function interpretations of the IRI constructors f con2iri and f uni2iri are as follows.

The first one concatenates name and year of conference and adds the prefix dblp:. The other one replaces blank spaces with character "-" of the sponsors name.

Let J 0 be the core pre-solution to I w.r.t. the data exchange setting seen in Fig-

ure 3.1b. We observe that J 0 has the following facts:

• ShConference(dblp:icdt2019),

• Triple(dblp:icdt2019, ex:place, Chile), and

• Triple(dblp:icdt2019, ex:place, Peru).

and in the shapes schema we see the triple constraint ex:place :: Lit 1 is in the definition of ShConference. This set of facts mentioned above is called a violation in J 0 because these facts violate the triple constraint with property ex:place. In fact, this is a source of inconsistency.

Assume that the triple constraint with property label ex:place admits having more than one edge. Thus, the above set of facts is not a violation in J 0 . Now remark, that the node univ:university-of-lille is also of type ShInstitute. Therefore, the node should have an edge with ex:address and the target node be of type ShAddress, which is an IRI.

This target node also should have an edge with ex:name. We observe that the literal node "Peru" is not an IRI. Thus, we add a blank node of type ShAddress and a null literal node. Also, we add an edge with label ex:address from univ:university-of-lille to the blank node and we add an edge with label ex:name from the blank node to the null literal node. These nodes and edges require to be added to J 0 because we want to extend J 0 to be a solution to I w.r.t. E. But it is impossible to fuse the blank node of type ShAddress and the null node of type literal. We call these types conflicting types.

In fact, this is another source of inconsistency. Based on the inconsistency definition, checking inconsistency consists of searching a source instance for which there is no solution w.r.t. the setting. We recall that a typed graph G is a solution to an instance of R w.r.t. E, if G satisfies the shapes schema S and the set of st-tgds Σ st . Also, we recall that a typed graph G is a pre-solution to an instance of R w.r.t. E, if G satisfies the set of st-tgds Σ st . A graph that together with the source instance of the relational schema satisfies the set of st-tgds is not the source for not obtaining a solution because this graph replicates or transforms the relational data and fits the triple model. But concerning the shapes schema, there are two cases where a graph that together with a source instance I of the relational schema satisfies the set of st-tgds is not a solution to I w.r.t. E:

Conference

• If there is a node in the graph for which its outgoing edges with the same predicate are more than one and the shapes schema constraints to be at most one edge.

• If there is a node in the graph for which its outgoing edges with the same predicate are more than one and one of the target nodes is literal and the other is non-literal.

Sources of inconsistency

Now, we define the notion of violation and conflicting types seen in Example 3.1.2 as the sources of inconsistency.

Violation

We define a violation as the property of a graph G. • There is a type T ∈ T for which there is a triple constraint p :: S µ in its definition for some S ∈ T ∪ {Lit} and some µ ∈ {1, ?}

• There are two triples with p where the source node is the same for both triples and T ∈ typing(n) where n is the source node; and the target nodes are two different constants.

Conflicting types

We define conflicting types as the property of a graph G. Definition 3.1.4. A typed graph G has conflicting types w.r.t. a shapes schema S if the following conditions are satisfied:

• there is a type S ∈ T ∪ {Lit}, a property label p ∈ Prop S , a triple constraint p :: S µ for some µ ∈ {1, ?} that is in the shape definition of some type T ∈ T;

• there are two triples with predicate p in G where the source node n is the same for both triples, T ∈ typing(n) and one of the target nodes is a null node; and

• if one of the target nodes is typed with S, the other is a literal if S is in T or not a literal if S is Lit.

Importance of core pre-solution

In Sections 3.2 and 3.3, we are going to focus on core pre-solutions because there are necessary and sufficient conditions that are computed over core pre-solutions. First, we are going to see in Section 3.2 and 3.3 that for a given instance I of R, we can detect sources of inconsistency in the set of pre-solutions to I w.r.t. E, with the help of core pre-solution. Then, we are going to show in Sections 3.2 and 3.3 that this detection of sources of inconsistency are necessary and sufficient conditions for a given instance to not admit a solution. Finally, we do not consider all the instances of R to verify the consistency of E, but only a finite number of instances whose core pre-solutions present the sources of inconsistency.

Value consistency

In this section, we define value consistency of the setting E and we present an analysis of testing value consistency. To define value consistency of E, we start presenting for any instance I of R, the definition of value consistency of a graph w.r.t. I and E as follows.

A graph G is value consistent w.r.t. E and

I if I ∪ G |= Σ st and G |= Σ TP S ∪ Σ PF S .
Let I be a consistent instance of R. We show that a violation in a core pre-solution to I w.r.t. E is a sufficient condition to claim that there is no solution to I w.r.t. E. Lemma 3.2.1. For any instance I of R, if the core pre-solution to I w.r.t. E is not value consistent, then I does not admit a solution to E.

Proof. Take an instance I of R. We compute its core pre-solution J 0 . Assume J 0 is not value consistent. By Definition 2.1.6 of core pre-solution being the unique minimal graph, every solution to I w.r.t. E contains J 0 . Therefore, I does not admit a solution to E. Now, we formalize the value consistency of the setting E as follows.

Definition 3.2.1 (Value consistency). The relational to RDF data exchange setting E is value consistent if for every I instance of R, the core pre-solution to I w.r.t. E is value consistent.

Testing value consistency

Now, we present an analysis and an algorithm for testing value consistency of E. The analysis consists of 1. preliminary notions that are used to define a finite set of contentious-based instances of the signature R, 2. the construction of this finite set denoted by CInst(Σ st ), and 3. the proof that if there is an instance I of CInst(Σ st ) that satisfies functional dependencies of R then there is a violation in the core pre-solution to I w.r.t. E. This inspection will show that value inconsistency is a sufficient condition for inconsistency of E.

Preliminary notions

Here, we introduce three notions called violation sort, accessibility and contentious sttgds. We illustrate them with the following example.

Example 3.2.2. Consider the data exchange setting E of Example 3.1.2. We analyze how do we get the violation W of Example 3.1.2. By definition of violation in a graph, there is a triple constraint with property p ∈ Prop S associated to some type T ∈ T definition that forbids two different objects for the same subject typed with T . Since the subject is an IRI and any two IRI constructors have disjoint ranges, then there is only one IRI constructor f ∈ F that produces the subject. Thus, every violation is associated with at least one sort (T, f, p). We call the tuple (T, f, p) a violation sort.

Consequently, we start computing the set of violation sorts w.r.t. E by combining the shapes ShConference, ShInstitute and ShAddress, with each IRI constructor f con2iri and f uni2iri and with each property p ∈ Prop S such that there is a triple constraint with p and multiplicity 1 or ?. We obtain the following result.

V s = {(ShConference, f con2iri , ex:name), (ShConference, f con2iri , ex:year), (ShConference, f con2iri , ex:place), (ShConference, f con2iri , ex:sponsor), (ShInstitute, f uni2iri , ex:address), (ShInstitute, f con2iri , ex:address) (ShConference, f uni2iri , ex:name), (ShConference, f uni2iri , ex:year), (ShConference, f uni2iri , ex:place), (ShConference, f uni2iri , ex:sponsor) (ShAddress, f uni2iri , ex:name), (ShAddress, f con2iri , ex:name)}
We observe that the violation sort of W is (ShConference, f con2iri , ex:place). Now in Figure 3.1b, we observe that nodes in the core pre-solution to I w.r.t. E are generated by the application of rules in Σ st . Also, we observe that the set of st-tgds is normalized, so the head of a rule in Σ st is either a typed atom or a triple atom. We inspect the first two elements of this violation sort (ShConference, f con2iri ) by tracing the rules, which are in Σ st , that were triggered such that we can find a node that is the root of a path in the core pre-solution whose last node is constructed by f con2iri and typed with ShConference. Such a sequence of rules is called a path in E. The rules of the path are required to be triggered for the existence of the subject node that causes a violation. In our case, the sequence is composed of σ 4 because the triggering of this rule will create a node of typed ShConference produced by the IRI constructor f con2iri . We say that the pair (ShConference, f con2iri ) is accessible in E. We note that a pair can be accessible and not be related to a violation sort. For instance, the pair (ShUniversity, f uni2iri ) is accessible in E but it is not present as part of a violation sort.

Since a rule in Σ TP

S does not produce a node, then the rule σ 3 is triggered twice and produces two different objects. Because we assume the instance does not contain null values, then the triggering two times rule σ 3 will always produce two different objects.

Therefore, if (ShConference, f con2iri ) is accessible then rules σ 3 and σ 3 are contentious with (ShConference, f con2iri , ex:place).

Violation sorts. We define the set of violation sorts V s w.r.t. E as the set of triples (T, f, p) w.r.t. E such that p is a property label for some triple constraint in the definition of T , and f is any function name. Formally,

V s = {(T, f, p) ∈ T × F × Prop S | ∃S ∈ T ∪ {Lit}. ∃µ ∈ {1, ?}. p :: S µ ∈ δ(T )}.
In the sequel, we say that G has violation with (T, f, p) if the following set of facts are in G:

{T (f (a)), Triple(f (a), p, b), Triple(f (a), p, b )}
for some tuple of constants a and some b, b ∈ Lit ∪ Iri. Thus, every violation in the core pre-solution has a violation sort.

Accessibility in core pre-solution. We define accessibility, and show that (T, f ) is accessible in E if and only if there is an instance I of the signature R such that the fact

T (f (a)
) is in the core pre-solution to I w.r.t. E.

Definition 3.2.3. The pair (T, f ) ∈ T × F is called accessible in E with sequence σ 0 , σ 1 , . . . , σ n of st-tgds in Σ st if:
• the head of σ 0 is of the form T 0 (f 0 (x 0 )), and

• the head of σ i is of the form Triple(f i-1 (x i ), p i , f i (y i ))
for every 1 ≤ i ≤ n, and

• p i :: T µ i i ∈ δ(T i-1 )
for every 1 ≤ i ≤ n, and

• T = T n and f = f n .
for some type symbols T i , function symbols f i , predicates p i , multiplicities µ i and sequences of variables x i and y i .

We call a sequence of rules σ 0 , . . . , σ n for n been less or equal than number of rules in Σ st , where each rule is in Σ st , a path in E, denoted by π. We point out that π is elementary i.e., in the sequence there are no repetitions of rules. Now, we claim the following lemma.

Lemma 3.2.2. For any (T, f ) ∈ T × F, it holds that (T, f ) is accessible in E if and only if there exists an instance I of R and a tuple of constants a in the domain of I s.t.

the core pre-solution to I w.r.t. E contains the fact T (f (a)).

Proof. Take (T, f ) ∈ T × F. For the ⇒ direction. Assume (T, f ) is accessible. By definition, there is a path π = σ 0 , . . . , σ n in E s.t.:

• head (σ 0 ) = T 0 (f 0 (x 0 )), and

• head (σ i ) = Triple(f i-1 (x i-1 ), p i , f i (y i ))
for any 1 ≤ i ≤ n, and

• p :: T µ i ∈ δ(T i-1
) for some multiplicity µ, and

• (T, f, p) = (T n , f n , p n ) for some type symbols {T i | 0 ≤ i ≤ n} ⊆ T, function symbols {f i | 0 ≤ i ≤ n} ⊆ F, IRIs {p i | 1 ≤ i ≤ n} ⊆ Prop S
and some sequence of variables x i and y i . We construct an instance I of R such that adom(I) = {b} for some b ∈ Const. We chase I with the sequence σ 0 , . . . , σ n and Σ TP S . This chase sequence of st-tgds and Σ TP S is finite because each rule is applied once. As a result of the chase sequence, there is b i for i ∈ {0, . . . , n} composed of b ∈ adom(I) such that we have the following result:

A = {T 0 (f 0 (b 0 )), Triple(f 0 (b 0 ), p 1 , f 1 (b 1 )), T 1 (f 1 (b 1 )), Triple(f 1 (b 1 ), p 2 , f 2 (b 2 )), . . . , Triple(f n-1 (b n-1 ), p n , f n (b n )), T n (f n (b n ))}.
By chase sequence definition, A is a universal solution to Σ st ∪ Σ TP S . By definition of universal solution, there is a homomorphism h : A → J such that h(c) = c for every c ∈ adom(A) and J a solution to Σ st ∪ Σ TP S . Since in A there are no nulls, then A ⊆ J. A solution to I w.r.t. Σ st ∪ Σ TP S is the core pre-solution to I w.r.t. E. Thus, J contains the fact

T n (f n (b n )). Because T = T n and f = f n , it holds that J contains T (f (b n )).
For the ⇐ direction. Assume there exist an instance I of R and a tuple of constants a in the domain of I s.t. the core pre-solution to I contains T (f (a)). Since the core presolution to I w.r.t. E can be computed using the chase, then there is a chase sequence of I with Σ st ∪ Σ TP S such that T (f (a)) is present in the result of the chase sequence. To prove that (T, f ) is accessible in E we require the following claims.

Claim 3.2.2.1. For any I of R, for any finite chase sequence w of I for dependencies

Σ st ∪ Σ TP
S , any a ∈ Iri, any S ∈ T, any k ∈ {2, . . . , |w|}, if J k a result of k chase step in w contains the fact S(a) and for any k < k, there is not S ∈ T, p ∈ Prop S and a ∈ Iri such that J k a result of k chase step contains the facts S (a ),Triple(a , p, a) then there is k < k ≤ k, a rule σ ∈ Σ st and a homomorphism h : σ → J k such that head (σ) = S(f (x)) and h F (f (x)) = a for some f ∈ F and some sequence of variables x.

Proof. Assume the premises of the claim. We recall that Σ st is normalized. Because a ∈ Iri, there is an IRI constructor f ∈ F that has generate a. Because a TP rule in its terms does not contain an IRI constructor, the generation of a node is done by the application of a rule σ is in Σ st . We recall (1) the restriction of data exchange setting definition in Section 2.1: there is not T (x) or Lit(f (x)) for some T ∈ T and some sequence of variable x in a st-tgd. By σ is in Σ st , by condition that there is not a ∈ Iri, p ∈ Prop S and S ∈ T such that {S (a ),Triple(a , p, a)} ⊆ J k , by definition of a chase step that only one rule is triggered and (1), then the head σ if of the form S(f (x))

for some x ⊆ vars(σ) and there is k < k ≤ k and a homomorphism h

F : σ → J k such that h F (f (x)) = a. Claim 3.2.2.2. For any finite chase sequence w for Σ st ∪Σ TP S , any k ∈ {3, . . . , |w|}, any b, b ∈ Iri and any q ∈ Prop S if J k a result of k chase step contains the fact Triple(b, q, b ) then there is a k ≤ k, a rule σ ∈ Σ st such that head (σ) = Triple(f (y 1 ), q, g(y 2 ))
for some f, g ∈ F and y 1 and y 2 subsets of vars(σ); and there is a homomorphism

h F : σ → J k such that h F (y 1 ) = b and h F (y 2 ) = b .
Proof. Assume J k contains the fact Triple(b, q, b ). Because a triple in a graph is not generated by a TP rule and the set of st-tgds Σ st is normalized, then there is a k ≤ k for which a rule σ ∈ Σ st has a homomorphism h F : σ → J k . The application of a rule in Σ st that generates a triple is of form ϕ ⇒ Triple(f (y 1 ), q, g(y 2 )) for some y 1 and y 2 subsets of vars(ϕ). Thus, h F is defined with h F (f (y 1 )) = b and h F (f (y 2 )) = b . Now, we fix a chase sequence s such that J m is the core pre-solution starting at the source instance as follows.

I = J 0 σ 1 ,h 1 ---→ J 1 σ 2 ,h 2 ---→ . . . J m-1 σm,hm ----→ J m
where σ i a dependency in Σ st ∪ Σ TP S and h F i : σ i → J i a homomorphism for any i ∈ {1, . . . , m}.

Let b = f (a). In consequence, the fact T (b) ∈ J m has been generated by the application of a rule σ either in Σ st or in Σ TP S in a instance before J m . If (a) for any k < m, there is not

S ∈ T, p ∈ Prop S , b ∈ Iri such that J k contains the set of facts {S(b ), Triple(b , p, b)} then by Claim 3.2.2.1, there is k < k ≤ m, σ ∈ Σ st , a homomorphism h F k : σ → J k such that head (σ) = T (f (x))
where f is defined at the beginning and h S is because there is a triple constraint p :: T µ ∈ δ(S) for some multiplicity µ. By Claim 3.2.2.2 on (b), there is a k ≤ k , rule σ 1 ∈ Σ st such that its head is of the form head (σ 1 ) = Triple(f (x 1 ), p, f (x)) for some f ∈ F and sequence of variables x 1 and x and there is a homomorphism h

F k : σ 1 → J k such that h F k (f (x 1 )) = b and h F k (f (x)) = b. Now, we observe the fact S(b ) in J k . As done with T (b) in J m , if condition (a)
and because of existence of rule in Σ TP S , then (T, f ) is accessible with sequence of rules σ 0 , σ 1 where σ 0 is the rule triggered by condition (a). Otherwise condition (b). Since there is a start in J 0 and by Claim 3.2.2.1, then the last condition is always (a).

Therefore, (T, f ) is accessible in E.

Contentious st-tgds. We define contentious st-tgds as follows.

Definition 3.2.4. Let (T, f, p) be a violation sort. Two st-tgds σ, σ ∈ Σ st are contentious with sort (T, f, p) if

• the head of σ is Triple(f (z), p, t),
• the head of σ is Triple(f (z ), p, t ), and

• (T, f ) is accessible in E
for some sequence of variables z, z and terms t, t .

Contentious-based instances

Now, we specify the construction of a finite set of contentious-based instances based on the set of violation sorts, accessibility and contentious st-tgds.

Let (T, f, p) be a violation sort, σ, σ ∈ Σ st with sort (T, f, p) be two contentious st-tgds. Let π = σ 0 , . . . , σ n be a path from which (T, f ) is accessible in E, we define B π,σ,σ as the union of the bodies of the rules that are in the path π together with σ and σ . We assume that each two rules σ, σ in π uses mutually disjoint set of variables.

For ease of use, we rename σ and σ with σ n+1 and σ n+2 . In symbols, the union of the bodies of the rules is B π,σ,σ = n+2 i=0 body(σ i ). Then, we define the sequence of mappings h 0 , . . . , h n+2 inductively as follows:

• for any 0 ≤ i ≤ n + 2, h i : i j=0 vars R (σ j ) → NullLit is a mapping that is injective when restricted on vars R (σ i ); • for any 1 ≤ i ≤ n + 2, h i coincides with h i-1 on the domain of h i-1 ; • for any 1 ≤ i ≤ n, for any head of σ i of the form Triple(f i-1 (x i ), p i , f i (y i )) for some function symbols f i , predicate p i and sequence of variables x i , y i , h i (x i ) = h i-1 (y i-1 ) and h i (z) is fresh w.r.t. the image of h n-1 for any z ∈ x i . That is, z ∈ x i implies h(z) is not in the image of h i-1 ;
• for head of rule σ n+1 of the form Triple(f n (z), p, t) for some function symbol f n , sequence of variables z and some term t, h n+1 (z) = h n (y n ) and h n+1 (z) is fresh w.r.t. the image of h n for any z ∈ z;

• for head of rule σ n+2 of the form Triple(f n (z ), p, t ) for some function symbol f n , sequence of variables z and some term t , h n+2 (z ) = h n (y n ) and h n+2 (z) is fresh w.r.t. the image of h n+1 for any z ∈ z Now, we define a contentious-based instance denoted by I π,σ,σ as

I π,σ,σ = h π,σ,σ (B π,σ,σ ) where h π,σ,σ is a homomorphism h π,σ,σ : B π,σ,σ → I π,σ,σ defined as h π,σ,σ = h n+2 .
We illustrate the construction of a contentious-based instance in Example 3.2.5.

Example 3.2.5 (cont. Example 3.1.2 and 3.2.2). We take the following violation sort (ShInstitute, f uni2iri , ex:address) in V s of E. We recall that a rule can be contentious with itself. Thus, we take the rule σ 7 and repeat this rule changing its variables. We observe that (ShInstitute, f uni2iri ) is accessible with rules σ 4 and σ 5 . We rename the variables of rules σ 4 , σ 5 and σ 7 and the repeated rule such that two rules use mutually disjoint set of variables.

Conference(x 1 , x 2 , x 3 , x 4 ) ⇒ ShConference(f con2iri (x 2 , x 3 ))
Conference(x 5 , x 6 , x 7 , x 8 ) ∧ Sponsor(x 5 , x 9 ) ⇒ Triple(f con2iri (x 6 , x 7 ), ex:sponsor, f uni2iri (x 9 )) Sponsor(y 1 , y 2 ) ∧ Conference(y 1 , y 3 , y 4 , y 5 ) ⇒ Triple(f uni2iri (y 2 ), ex:address, y 5 ) Sponsor(y 6 , y 7 ) ∧ Conference(y 6 , y 8 , y 9 , z) ⇒ Triple(f uni2iri (y 7 ), ex:address, z)

The first step in the construction of contentious-based instances is the union of bodies having as a result:

B π,σ,σ = {Conference(x 1 , x 2 , x 3 , x 4 ), Conference(x 5 , x 6 , x 7 , x 8 ),
Sponsor(x 5 , x 9 ), Sponsor(y 1 , y 2 ), Conference(y 1 , y 3 , y 4 , y 5 ), Sponsor(y 6 , y 7 ), Conference(y 6 , y 8 , y 9 , z)}.

From these atoms in B π,σ,σ , we unify some of the values that is assigned to the variables of B π,σ,σ in order to get rules σ 4 , σ 5 , σ 7 and σ 7 been triggered one after the other. For instance, we unify values for variables x 2 and x 6 , with distinct value for variables x 3 and x 7 , then variables x 9 , y 2 and y 7 . Based on these unifications, we define the sequence of homomorphisms h 1 , h 2 , h 3 and h 4 , which are applied to rules above such that h i coincides in the domain of h i-1 for i ∈ {2, 3, 4}, as follows.

h 1 (x 2 ) = h 2 (x 6 ) = ⊥ 1 h 1 (x 3 ) = h 2 (x 7 ) = ⊥ 2 h 2 (x 9 ) = h 3 (y 2 ) = h 4 (y 7 ) = ⊥ 3 h 3 (y 5 ) = ⊥ 4 h 4 (z) = ⊥ 5
The rest of variables that occur in rules above are mapped to fresh values. Finally, we apply the homomorphism h 4 to B π,σ,σ obtaining the contentious-based instance:

I π,σ,σ = {Conference(⊥ 6 , ⊥ 1 , ⊥ 2 , ⊥ 7 ), Conference(⊥ 8 , ⊥ 1 , ⊥ 2 , ⊥ 9 ), Sponsor(⊥ 8 , ⊥ 3 ), Sponsor(⊥ 10 , ⊥ 3 ), Conference(⊥ 10 , ⊥ 11 , ⊥ 12 , ⊥ 4 ), Sponsor(⊥ 13 , ⊥ 3 ), Conference(⊥ 13 , ⊥ 14 , ⊥ 15 , ⊥ 5 )}
It remains to prove that this instance is unique.

Lemma 3.2.3. I π,σ,σ is unique up to isomorphism.

Proof. By construction of I π,σ,σ there is a homomorphism h π,σ,σ defined from B π,σ,σ to I π,σ,σ . The values of I π,σ,σ depend on the actual values given by h π,σ,σ . If we choose different values by a bijective renaming function except for values that are equated in the sequence of mappings defined in the construction, then we obtain an instance that is

isomorphic to I π,σ,σ .
We define a bijective rename function for null literal names. Take (T, f, p) ∈ V s .

To prove that I π,σ,σ is unique, we assume that there is other contentious-based instance I π,σ,σ for contentious rules σ and σ with sort (T, f, p) such that I π,σ,σ ⊂ I π,σ,σ . By semantics of ⊂, I π,σ,σ contains less facts i.e., there is one rule σ i for some i ∈ {0, . . . , n} from the path π = σ 0 , . . . , σ n in E. But, by definition of contentious, (T, f ) is accessible with π and not with π where π is the path without the rule σ i . Thus σ and σ are not contentious with (T, f, p). Contradiction.

In the sequel, by I π,σ,σ we mean an arbitrary instance isomorphic to the one defined above. Finally, we define the set of contentious-based instances as follows:

CInst(Σ st ) = {I π,σ,σ | σ, σ ∈ Σ st , ∃(T, f, p) ∈ V s . (T, f ) is accessible in E
with π and σ, σ are contentious with (T, f, p)}.

We show with the following proposition that for any instance Iof R, there is a homo- π is a path for (T, f ), then the sequence of st-tgds σ 0 , . . . , σ n that composes π is as in Definition 3.2.3 and T n = T and f n = f . Thus, σ 0 contains a typed atom and for σ 1 , . . . , σ n there are triple constraints such that p i ::

morphism from I π,σ,σ to I if
T µ i i ∈ δ(T i-1 ) for every 1 ≤ i ≤ n.
Because of existence of these triple constraints, then we have Σ TP S contains the rules TP(T i-1 , p i , T i ) for any 0 < i ≤ n. By construction of I π,σ,σ , rules in π and σ, σ are rewritten by renaming the variables such that two rules use mutually disjoint set of variables and there is a homomorphism h π,σ,σ : B π,σ,σ → I π,σ,σ . For the purpose of defining a sequence of mappings such that the nodes generated by the application of rules of π, σ, σ are typed following the TP rules, we define that each variable has to be distinct in TP rules and be distinct from those used in B π,σ,σ as follows. Let

TP(T

i-1 , p i , T i ) = T i-1 (u i ) ∧ Triple(u i , p i , v i ) ⇒ T i (v i ) for any 0 < i ≤ n,
where w.l.o.g. u i , v i are fresh w.r.t. the variables used in σ 0 , . . . , σ n , σ, σ and {u i , v i } is disjoint from {u j , v j } whenever i = j. Now we define a mapping h from B π,σ,σ to I as h = h • h π,σ,σ . It follows by definition of I π,σ,σ and h that I is the disjoint union of h (B π,σ,σ ) and I , the latter containing the facts of I that are not images by h of some fact in I π,σ,σ . Next, we define a chase sequence s starting at I with π, σ, σ and TP rules; note that in the sequel we abuse the notation and use h as its restriction on any subset of variables in its domain.

The first chase step of s is with rule σ 0 i.e., I σ 0 , h ---→ I 0 , whose head of σ 0 is a typed atom. Let head (σ 0 ) = T 0 (f 0 (x 0 )). For the following chase steps, we intercalate a rule of π and a rule of TP. We recall that by renaming of variables done before, the head of σ i in π is of the form Triple(f i-1 (x i ), p i , f i (y i )), the head of σ is of the form Triple(f n (x n+1 ), p, t) and the head of σ is of the form Triple(f n (x n+2 ), p, t ) for some terms t, t . We define subsequent chase steps inductively by adding the following two chase steps for all 0 < i ≤ n:

I i-1 σ i , h ---→ I i TP(T i-1 ,p i ,T i ), h i ----------→ I i , where h i is defined by h i (u i ) = h (f i-1 (x i )) and h i (v i ) = h (f i (y i )).
Thus s is of the form:

I σ 0 , h ---→ I 0 σ 1 , h ---→ I 1 TP(T 0 ,p 1 ,T 1 ), h 1 ---------→ I 1 → • • • → I n-1 σn, h ---→ I n TP(T n-1 ,pn,Tn), hn -----------→ I n .
We now show that s is indeed a chase sequence. That is, we need to show that the homomorphism of each step above is indeed a homomorphism from the body of the dependency being applied to the instance to which the step is applied. It immediately follows from the definitions and hypotheses that (1)

I 0 = I ∪ h (B π,σ,σ ) ∪ T 0 (h(f 0 (x 0 )))
where I contains the facts of I that are not images of some fact of I π,σ,σ by h. For any 1 ≤ i ≤ n we show the following by induction on i:

(2)

I i = I i-1 ∪ h (head (σ 0 ) ∪ • • • ∪ head (σ i ));
(3)

I i = I i ∪ T i (h (f i (y i ))).
For the base case i = 1. From (1) it follows that h : σ 1 → I 0 is a homomorphism, and by definition of the chase, applying h on I 0 yields I 1 = I 0 ∪ h (head (σ 1 )), thus (2) holds. Now from (1) and (2) we know that I 1 contains the facts T 0 (h (f 0 (x 0 ))) and Triple(h (f 0 (x 1 )), p 1 , f 1 (y 1 )) = h (head (σ 1 )).

Recall that by definition, h π,σ,σ (x 0 ) = h π,σ,σ (x 1 ), so also h

(x 0 ) = h (x 1 ), thus h 1 is indeed a homomorphism from T i-1 (u i ) ∧ Triple(u i , p i , v i ) into I i and the resulting instance is indeed I i ∪ T i (h (f i (y i ))).
The same arguments apply for the induction step for showing that h : σ i → I i-1 and h i : TP(T i-1 , p i , T i ) → I i are homomorphisms with h(y i-1 ) = h(x i ) and h (y i-1 ) = h (x i ), and their application yields the instances described in (2) and (3).

Consider now the chase sequence

s = I n σ, h --→ I σ σ , h --→ I σ .
It immediately follows from the definition of h, from (3) and from the definition of a chase step that

• I σ = I n ∪ {Triple(h(f n (x n+1 )), p, h(t))} and • I σ = I σ ∪ {T riple(h(f n (x n+2 )), p, h(t ))}, where h(x n+1 ) = h(x n+2 ) = h(y n ).
Finally, we consider the core pre-solution computed using chase. Thus, any chase sequence with Σ st ∪ Σ TP S is finite because rules in Σ st does not contain existential variables so there is no fresh values and the nodes are created from constants in the domain of I; and rules in Σ TP S only type the nodes. Since rules in π are in Σ st and the TP rules used for obtaining I σ are part of Σ TP S , then the core pre-solution to I w.r.t. E contains I σ . Therefore, we conclude

{T n (h (f n (y n ))), Triple(h (f n (x n+1 )), p, h (t)), Triple(h (f n (x n+2 )), p, h (t ))} ⊆ J 0 .
Because of violation sort definition on (T n , f n , p), there is a triple constraint p :: S µ ∈ δ(T n ) for some S ∈ T ∪ {Lit} and some µ ∈ {1, ?}. Now, we construct a contentious-based instance I π,σ,σ from the contentious st-tgds σ,σ and the path π and define an injective function h : I π,σ,σ → I. We show that h is a homomorphism. Because every node in J 0 is generated by the application of a sttgd, and J 0 contains the violation with sort (T, f, p), then there is a homomorphism from h : B π,σ,σ → I. By construction of I π,σ,σ , there is a homomorphism h π,σ,σ : B π,σ,σ → I π,σ,σ . The function h is defined as follows: for any ⊥ ∈ adom(I π,σ,σ ) there is a ∈ adom(I) such that h(⊥) = a if there is x ∈ adom(B π,σ,σ ) and h π,σ,σ (x) = ⊥ and h (x) = a. It is easy to see that for any R ∈ R, every R(⊥ 1 , . . . , ⊥ n ) ∈ I π,σ,σ where n is arity of R, there is R(h(⊥ 1 ), . . . , h(⊥ n )) ∈ I. Thus, h is a homomorphism.

Necessary condition

Now, we show that value consistency of E is a sufficient condition for consistency by verifying that contentious-based instances are properly consistent instances of R. We express this with the following theorem.

Theorem 3.2.7. E is not value consistent if and only if there is an instance I π,σ,σ in CInst(Σ st ) such that there is a solution I for I π,σ,σ to the set of functional dependencies

Σ fd of R for which h • h π,σ,σ (t) = h • h π,σ,σ (t )
where h is the unique homomorphism from I π,σ,σ to I and t, t are two different terms such that head of σ is Triple(f (x), p, t) and the head of σ is Triple(f (x), p, t ) where σ, σ are used in the construction of

I π,σ,σ .
Proof. For the ⇒ direction. Assume E is not value consistent. By negation of definition of value consistency of E, there is an instance I of R such that the core pre-solution J 0 to I w.r.t. E is not value consistent. By negation of definition of value consistent of graph and definition of core pre-solution, the core pre-solution does not satisfy the Σ PF S rules. This means the core pre-solution J 0 has a violation with some sort (T, f, p) in the set of violations sorts w.r. and some µ ∈ {1, ?}. Since J 0 is the core pre-solution to I, then there is a function h 1 that maps values from I to J 0 . Because of the existence of violation with sort (T, f, p), σ, σ are contentious with (T, f, p) in Σ st by Proposition 3.2.6 and J 0 is the result of application Σ st , then h 1 (t) = b and h 1 (t ) = b where t and t are two different terms such that the head of σ is Triple(f (x), p, t) and the head of σ is Triple(f (x), p, t ).

By Proposition 3.2.6, we can construct I π,σ,σ and there is a homomorphism h from I π,σ,σ to I. By construction of I π,σ,σ , we know there is a homomorphism h π,σ,σ : B π,σ,σ → I π,σ,σ . We chase I π,σ,σ with Σ fd obtaining the instance I such that there is a homomorphism h : I π,σ,σ → I . By property of the chase, I is a universal solution to I π,σ,σ w.r.t. Σ fd . This means that there is a h u : I → I. Now, we apply h to I obtaining an instance I and define a function g over the domain of I as follows:

g(d) = h (h(⊥)) such that h (⊥) = d with ⊥ ∈ adom(I π,σ,σ ) for every d ∈ adom(I).
This function is well-defined because given two ⊥ 1 , ⊥ 2 either they are fused or they are identities. This means that h (⊥ 1 ) = d and h

(⊥ 2 ) = d so h (h(⊥ 1 )) = h (h(⊥ 2 )).
Then g is a homomorphism from I to I . We chase I with the same chase sequence used for I obtaining the core pre-solution J to I w.r.t. E. Since J is the core presolution to I , then there is a function h 2 that maps values from I to J . Since we have used the same chase sequence for I and g maps from

I to I , then h 2 = g • h 1 .
We assume by contradiction that h 2 (b) = h 2 (b ). Here, we have that b, b are the mapped values from terms t and t in the head of the contentious st-tgds σ and σ . Since a term can be either a variable or a function term, then we have two cases:

• Let t = y and t = y . Since h 2 = g•h 1 and by definition of g, then h •h π,σ,σ (y) = h • h π,σ,σ (y ). This means that h(y) = h(y ). Because I is a universal solution to I π,σ,σ w.r.t. Σ fd and h u : I → I, then it is not possible to equate in I and be different in I. Thus, I |= Σ fd ; a contradiction.

• Let t = f (y) and t = f (y ). Since the IRI constructors are non-overlapping and in J 0 every IRI comes from an IRI constructor and h 2 = g • h 1 and by definition of g, then h

• h π,σ,σ (f (y)) = h • h π,σ,σ (f (y )). Simplifying, h • h π,σ,σ (y) = h •h π,σ,σ (
y ) for every y ∈ y and y ∈ y . This means that h(y) = h(y ) for every y ∈ y and y ∈ y . Because I is a universal solution, I |= Σ fd ; a contradiction.

For the ⇐ direction. Assume there is an instance I π,σ,σ ∈ CInst(Σ st ) such that there is a solution

I to I π,σ,σ w.r.t. Σ fd for which h • h π,σ,σ (t) = h • h π,σ,σ (t )
h • h π,σ,σ (x) = a, b = h • h π,σ,σ (t) and b = h • h π,σ,σ (t ). By hypothesis, b = b . Thus,
J 0 has a violation with this set of facts, and consequently, J 0 is not value consistent. By Lemma 3.2.1, I does not admit a solution to E.

Algorithm

Now, we summarize the previous analysis for testing value consistency in the Algorithm 1. The argument of this algorithm is a constructive data exchange setting and the result is a Boolean value. The output is true if the data exchange setting is value consistent. The Algorithm 1 starts computing the set of contentious-based instances V R . Then we compute a set of consistent contentious-based instances V R by removing from V R inconsistent instances. Finally, the algorithm outputs false if V R is not empty, otherwise true.

Algorithm 1: CVC: check value consistency.

Input: a data exchange setting E = (R, S, Σ st , F) Output: true if E is value consistent,false otherwise.

1 V R = {I π,σ,σ | σ, σ are contentious with (T, f, p) and (T, f ) is accessible with π} ; 2 V R = {I ∈ V R | I |= Σ fd }; 3 if V R = ∅ then

Node kind consistency

In this section, we define node kind consistency and provide a procedure for deciding if a data exchange setting is node kind consistent. To define node kind consistency, we require two auxiliary functions co-typing of a data exchange setting and co-typing of a graph. In both cases, the function defines a set of set of types. In the case of a data exchange setting E, for a set of types X in the co-typing result it would be possible to have an instance I in which the types of X co-occurs in the typing of a node of every solution to I w.r.t. E. In the case of a graph G, for a set of types X in the co-typing result there is a graph G ⊃ G such that G satisfies a shapes schema and there is a node n ∈ nodes(G ) such that all types of X co-occur in the typing of n. We illustrate co-typing and node kind inconsistency with the following example.

Example 3.3.1. We consider the data exchange setting E of Example 3.1.2. We are interested in detecting if the setting is node kind inconsistent. For this purpose, we compute the co-typing graph of E shown in Figure 3.2. A node of this graph is a set of types A ⊆ T and an edge with label p between a source node and target node represents that there is a type T in the source node such that there is a triple constraint in the shape definition of T with property p and multiplicity in {1, +} for which the target type of this triple constraint is in the target node. A co-typing graph provides the following information. Given a node A ∈ nodes(G E ), it would be possible that there is an instance I of R such that for any solution J to I w.r.t. E there is a node n ∈ nodes(J) for which two or more types contained in A cooccurs in the typing of n. For instance, in the co-typing graph seen in Figure 3.2, we take the node {ShInstitute, ShUniversity}. Indeed, for the instance in Figure 3.1a, the core pre-solution seen in Figure 3.1b, which is in every solution to I w.r.t. E, has in its nodes the node univ:university-of-Lille where ShInstitute and ShUniversity co-occurs.

With the information of a co-typing graph, we can compute the co-typing of a graph G that defines a set of set of types where each set of types will probably co-occur in any graph that includes G and satisfies the shapes schema. For instance, the co-typing graph in Figure 3.2 shows that there might exist a node where ShInstitute and ShUniversity will co-occur and this node will need to have an outgoing edge with ex:address and the target node will have types Lit and ShAddress. Indeed, even if we have an edge with ex:address in the core pre-solution we have to add a fresh node of typed ShAddress because according to the co-typing graph there must be an outgoing edge with ex:name from this fresh node to a node of type Lit. This outgoing edge with ex:name cannot be from "Peru" node because it is literal. Here, we observe that the fresh node of type ShAddress needs to be fused with the node "Peru" because the shapes schema constraints to have at most one edge with ex:address from type ShInstitute. Thus, with the help of co-typing of the core pre-solution, we can identify if there is a conflicting type in any graph that includes the core pre-solution and satisfies shapes schema. Indeed, it will be enough to check if there is a literal and non literal type in a node of the nodes of the co-typing graph.

Co-typing of a data exchange setting and co-typing graph

Here, we define the co-typing of a data exchange setting and the co-typing graph. To define the co-typing of a data exchange setting, we require two auxiliary functions called type reachability and obligatory property label. We fix a set of types T. The type reachability function over a T-based shapes schema S = (T, δ) denoted by

∆ : 2 T × Prop S → 2 T
defines a set of types reachable by p-labeled edge from a node that satisfies the set of types X, as follows.

∆(X, p) = {S | p :: S µ ∈ δ(T ) for some T ∈ X and µ ∈ {?, 1, +, *}}.

The obligatory property label function over a T-based shapes schema S = (T, δ) denoted by Req : 2 T → 2 Prop S defines a set of property labels that are required by a set of types X, as follows.

Req(X) = {p | ∃T ∈ X. ∃S ∈ T. ∃µ ∈ {1, +}. p :: S µ ∈ δ(T ) }.

The type accessibility function defines a set of types that are accessible with an IRI constructor f ∈ F as follows:

Acc(f ) = {T | (T, f ) accessible in E}.
Based on these two auxiliary functions, we define co-typing of E as follows:

CoTypes(E) = ∞ i=0 N i , where N 0 = {Acc(f ) | f ∈ F}, and N i = {∆(X, p) | X ∈ N i-1 , p ∈ Req(X)} for any i ≥ 1.
We call N 0 the co-base set of a setting. We claim the following property of the set N 0 as follows.

Lemma 3.3.1. For any X ⊆ T, X ∈ N 0 iff there is an instance I of R such that for the core pre-solution J 0 to I w.r.t. E, there is a node n ∈ nodes(J 0 ) such that n is typed with all types of X.

Proof. Take X ⊆ T. For the ⇒ direction. We assume X ∈ N 0 . Then by definition of N 0 , X = Acc(f ) for some f ∈ F. By definition of type accessibility, for any T ∈ X, (T, f ) is accessible in E. Take T ∈ X. By Lemma 3.2.2, there is an instance I of R and tuple of constants a in the domain of I s.t. the core pre-solution J 0 to I w.r.t. E contains the fact T (f (a)). Let the domain of I be adom(I) = {a}. Since the active domain of I is composed of one constant, J 0 |= Σ TP S and for any T ∈ X, (T, f ) is accessible in E, then for all types T ∈ X, we have T (n) ∈ J 0 such that n = f (a) in nodes(J 0 ). Thus,

types J 0 (n) = X.
For the ⇐ direction. We assume there is an instance I of R such that for the core pre-solution J 0 to I w.r.t. E there is a node n ∈ nodes(J 0 ) s.t. types J 0 (n) = X.

Since J 0 |= Σ st , then there is an IRI constructor f ∈ F such that f (a) = n for some vector of constants a. Since types J 0 (n) = X and f is used to generate n, then for any

T ∈ X, (T, f ) is accessible in E. Then X = Acc(f ) which fulfills definition of N 0 . Consequently X ∈ N 0 .
We point out that this function defines a finite set of set of types because each N i construct subsets of a finite set of types T and this process eventually reaches a fix point.

Finally, we construct the co-typing graph of E as follows G

E = {Triple(X, p, Y ) | X ∈ CoTypes(E) ∧ p ∈ Req(X) ∧ Y = ∆(X, p)}.

Co-typing of a graph

We define an auxiliary function called frontier that defines a set of pairs node property where types of the node requires outgoing edges that are missing w.r.t. a shapes schema S. Formally, the frontier function of a graph G w.r.t. a shapes schema S is as follows:

F S (G) = {(n, p) | n ∈ nodes(G), p ∈ Req(types G (n)), m ∈ nodes(G). Triple(n, p, m) ∈ G}
In the following, we introduce the set M 0 called co-base set of a graph defined as

M 0 = {X | ∃n ∈ nodes(G). types(n) = X}.
Now, the co-typing of a graph G w.r.t. a shapes schema S is defined as follows.

CoTypes(G) = M 0 ∪ i∈N N G i where N G i = {∆(X, p) | X ∈ N G i-1 , p ∈ Req(X)} for any i ≥ 1 and N G 0 = {X ∈ M 0 | ∃(n, p) ∈ F S (G), types(n) = X}.
Now, we show that co-typing of a setting is included in the union, for every instance I of R, of the co-typing of the core pre-solution to I w.r.t. E. Lemma 3.3.2. For any relational to RDF data exchange setting E = (R, S, Σ st , F), it holds that CoTypes(E) ⊆ I instance of R CoTypes(J 0 ) where J 0 is the core pre-solution to I w.r.t. E.

Proof. Take a set X ∈ CoTypes(E). We prove that there is an instance I of R for which the co-typing of the core pre-solution to I w.r.t. E contains X. We construct an instance I where the active domain is composed of only one constant i.e., adom(I) = {a}. We compute the core pre-solution J 0 to I w.r.t. E. Since J 0 |= Σ TP S , then a node n in J 0 has all the accessible types with the IRI constructor used to generate n i.e., types J 0 (n) = Acc(f ) where f ∈ F. Based on this fact and that the active domain is only one constant for every node m ∈ nodes(J 0 ), types J 0 (m) = Acc(g) such that g is used to generate m.

If we compute M 0 , we obtain the same result. Then

N 0 = {Acc(f ) | f ∈ F} = M 0 .
Since the definition of N J 0 0 takes an element of M 0 and because N 0 = M 0 , then N J 0 i = N i for every i ≥ 1. Then, we conclude that X ∈ CoTypes(J 0 ). Also, given an instance I of R, we show a property of an element of the co-typing of the core pre-solution to I w.r.t. E.

Lemma 3.3.3. Let I be an instance of R. Let J 0 be the core pre-solution to I w.r.t.

E such J 0 |= Σ PF S . If X ∈ CoTypes(J 0 ) then there is a set of types Y ∈ CoTypes(E) such that X ⊆ Y .
Proof. Let I be an instance of R. Let J 0 be the core pre-solution to I w.r.t. E such

J 0 |= Σ PF S . Assume X ∈ CoTypes(J 0 )
. By definition of co-typing of a graph, (a) X ∈ M 0 or (b) X ∈ i∈N N J 0 i . For case (a), we know that M 0 is the set of set of types that co-occur in J 0 and by property of J 0 that every IRI node n ∈ nodes(J 0 ) is produced by an IRI constructor i.e., there is f ∈ F such that n = f (a) for some vector of constants a. Let Y = Acc(f ). By definition of co-typing of setting, we know Y ∈

CoTypes(E). Since the IRI constructors are non-overlapping and types J 0 (n) = X, then X ⊆ Y . For case (b), the proof goes by induction. For i = 0, X ∈ N J 0 0 . By definition of N G 0 , there is (n, p) ∈ F S (J 0 ) such that X = types J 0 (n). Since n ∈ nodes(J 0 ), there is f ∈ F such that f (a) = n for some vector of constants a. As case (a), there is Y ∈ CoTypes(E) such that X ⊆ Y . Now we assume that the hypothesis holds for i = k

for some k > 1 such that if X ∈ N J 0 i then there is Y ∈ CoTypes(E) such that X ⊆ Y . Assume X ∈ N G k+1
. By definition of co-typing of setting, there is X ∈ N J 0 k such that X = ∆(X , p) and p ∈ Req(X ). By induction hypothesis, there is Y ∈ CoTypes(E) such that X ⊆ Y . Since p ∈ Req(X ) and the co-typing graph of the setting must have an edge with p, then there is Y ∈ CoTypes(E) such that Y = ∆(Y , p).

We claim that for any Z, Z ⊆ T, and for any p ∈ Req(Z), if Z ⊆ Z then ∆(Z, p) ⊆ ∆(Z , p). The proof of this claim is as follows. Assume that Z ⊆ Z . Take p ∈ Req(Z) and take T ∈ ∆(Z, p). By definition type reachability, there is some type S ∈ Z such that p :: T µ ∈ δ(S) for some µ ∈ {?, 1, +, *}. Since Z ⊆ Z , then S ∈ Z . Since p :: T µ ∈ δ(S) and S ∈ Z , then T ∈ ∆(Z , p). By this claim, we know that ∆(X , p) ⊆ ∆(Y , p). Then X ⊆ Y . Now, given an instance I of R, we define a T-typed graph called completed w.r.t.

I and E using the co-typing of the core pre-solution J 0 to I w.r.t. E. We denote the completed graph w.r.t. I and E by G E (I). Let CoT J 0 = CoTypes(J 0 ) \ M 0 ∪ N J 0 0 be the difference of co-typing of J 0 with the co-base set of J 0 . For any X ∈ CoT J 0 s.t. X ⊆ T, let n X be a fresh blank node, i.e. n X ∈ Blank\adom(J 0 ). For any X ∈ CoT J 0 and p ∈ Req(X), let n X,p be a fresh null literal, i.e. n X,p ∈ NullLit \ adom(J). We define G E (I) as follows: Proof. Let J = J 0 ∪ G E (I). We prove that J is a solution to I w.r.t. E. Since J 0 is included in J , then J ∪ I satisfies Σ st . By construction of the completed graph w.r.t.

G E (I) ={Triple(n, p, n X ) | (n, p) ∈ F S (J 0 ) ∧ X = ∆(types J 0 (n), p) ⊆ T} ∪ {Triple(n, p, n X,p ) | (n, p) ∈ F S (J 0 ) ∧ ∆(types J 0 (n), p) = {Lit}} ∪ {Triple(n X , p, n X ) | X ∈ CoT J 0 ∧ p ∈ Req(X) ∧ X = ∆(X, p) ⊆ T} ∪ {Triple(n X , p, n X,p ) | X ∈ CoT J 0 ∧ p ∈ Req(X) ∧ ∆(X, p) = {Lit}} ∪ {T (n X ) | X ∈ CoT J 0 ∧ T ∈ X}.
I and E, the shapes schema S is satisfied i.e., G E (I) |= Σ S . Since G E (I) completes J 0 with nodes and edges that are required by the shapes schema and G E (I) satisfies S, then J 0 ∪ G E (I) satisfies S. Therefore, J is a solution to I w.r.t. E.

Formalization

Given an instance I of R, a graph G is node kind consistent w.r.t. E and I if G is the core pre-solution to I w.r.t. E and CoTypes(G) does not contain a set X s.t. {T, Lit} ⊆ X for some T ∈ T. Now, we formalize the node kind consistency of the setting E as follows:

Definition 3.3.2 (Node kind consistency). The data exchange setting E is node kind consistent if for every I instance of R, the core pre-solution to I w.r.t. E is node kind consistent.

Necessary condition

Now, we show that co-typing of the setting E is a necessary and sufficient condition for testing node kind consistency of the setting E.

Theorem 3.3.3. E is not node kind consistent if and only if CoTypes(E) contains a set X such that {Lit, T } ⊆ X for some type T in T.

Proof. For the ⇒ direction. We assume E is not node kind consistent. By the opposite of definition of node kind consistency of a setting, there is an instance I of R for which the co-typing of the core pre-solution to I w.r.t. E is not node kind consistent. By the opposite of definition of node kind consistency of a graph, the co-types of J 0 contains a set X such that {Lit, T } ⊆ X for some T in T. By Lemma 3.3.3, there is Y ∈

CoTypes(E) such that X ⊆ Y . Therefore, we conclude that CoTypes(E) contains a set Y such that {Lit, T } ⊆ Y .
For the ⇐ direction. We assume CoTypes(E) contains a set X such that {Lit, T } ⊆ X for some type T in T. By Lemma 3.3.2, there is an instance I of R such that the core pre-solution to I w.r.t. E contains X. By negation of definition of node kind consistency of a setting, we conclude that E is not node kind consistent.

Algorithm for testing node kind consistency

Here, we present an algorithm for testing node kind consistency. This algorithm has as input a constructive data exchange setting E and as output a Boolean value. True if E is node kind consistent, otherwise false. We recall the definition of path in a graph. For any graph G, a path π in G is defined by a sequence of labels p 1 • . . . • p k for k ≥ 0 such that for every two consecutive labels there are two edges in G with these labels such that target node for the first label is the source node for the second label. If k = 0, we denote by symbol ε, the empty path. We extend the reachability function over a graph G to defines a set of nodes that are reachable with a path in a graph G from a set of nodes in G as follows.

∇ G (N, ε) = N, ∇ G (N, π • p) = {n | ∃n ∈ ∇ G (N, π). Triple(n , p, n) ∈ G}.
First, we describe the Algorithm 2 that constructs the co-typing of E. For every function symbol f in the set F, we use the type accessibility function (line 3) and store the result in the set N 0 . We assign N 0 to N and initialize the set N T that will store the result of the co-typing of E. Then, we repeat the following process until there is no element of X such that Req(X) = ∅ and there is no new element to be added in N T .

For every element X ∈ N and for every property label p ∈ Req(X), we compute the type reachability with X and p. Then, we store the result of type reachability in set N s .

At the end of this process, we update the set N with N s . If there is no element of N with a literal and non-literal type, the algorithm returns N T .

Algorithm 2: Cotypes(E)

Input: a data exchange setting Finally, we describe the Algorithm 3 that decides if a data exchange setting E is node kind consistent. We construct the co-typing graph of E where CoTypes(E) is defined in Algorithm 2. Then we compute all paths with the function allpaths that returns all possible paths in G E that are not cycles. Then, for every function symbol f in the set F and for all ternary combinations of types (T, S, S ), we verify if (S, f ) and (S , f ) are accessible. If so, we verify that S and S are in nodes of G E . If so, for every path π in P , we use twice the function reachability with π, one with N and the other with N .

E = (R, S, Σ st , F) Output: true if E is node kind consistent, or (false) if E is not 1 N 0 = ∅; 2 for f ∈ F do 3 N 0 = N 0 ∪ {Acc(f )}; 4 end 5 N = N 0 ; 6 N T = ∅; 7 while ∃X ∈ N. Req(X) = ∅ and N ⊆ N T do 8 N T = N T ∪ N ; 9 N s = ∅;
Then, we compare if they are the same and if they contain the type T and Lit. If so, the algorithm returns false. Otherwise, the algorithm returns true.

Algorithm 3: CKC: Check Node Kind Consistency

Input: a data exchange setting E = (R, S, Σ st , F)

Output: true if E is node kind consistent, or (false) if E is not 1 G E = {(X, p, Y ) | X ∈ CoTypes(E), p ∈ Req(X), Y = ∆(X, p)}; 2 P = allpaths(G E ); 3 for f ∈ F do 4 for (T, S, S ) ∈ T × T ∪ {Lit} × T ∪ {Lit} do 5 if (S, f ) is accessible in E and (S , f ) is accessible in E then 6 if ∃N ∈ nodes(G E ). S ∈ N and ∃N ∈ nodes(G E ). S ∈ N then 7 use N and N ; 8 for π ∈ P do 9 X = ∇ G E (N, π); 10 Y = ∇ G E (N , π); 11 if X = Y and

Deciding consistency

In this section, we show that the two conditions of value consistency and node kind consistency are necessary and sufficient conditions for testing consistency. Then, we show these conditions are decidable, and finally, that the problem of consistency for relational to RDF data exchange setting is decidable. The next lemma establishes that for E being value consistent and node kind consistent is a sufficient condition for E to be consistent. Lemma 3.4.1. Let I be an instance of R. If the core pre-solution to I w.r.t. E is value consistent and node kind consistent, then I admits a solution to E.

Proof. Take an instance I of R. Assume the core pre-solution J 0 to I w.r.t. E is value consistent and node kind consistent. We prove that there is a typed graph U ⊇ J 0 that is a solution to I w.r.t. E. We recall that J 0 is the unique minimal typed graph J 0 that satisfies the st-tgds Σ st and the Σ TP S rules for S (cf. Section 1.5). We compute the completed graph G E (I) w.r.t. I and E. Let U = J 0 ∪ G E (I). By Lemma 3.3.4, U is a solution.

We are now ready to establish our main results regarding consistency.

Theorem 3.4.1. E is consistent iff E is value consistent and node kind consistent.

Proof. For the ⇒ direction. We prove by contraposition. Assume E is not value consistent or E is not node kind consistent. We have to prove E is inconsistent.

• When E is not value consistent. By negation of Definition 3.2.1, there is an instance I of R such that the core pre-solution J 0 to I w.r.t. E is not value consistent.

Since J 0 is contained in every solution then I does not admit a solution w.r.t. E.

Consequently, E is inconsistent.

• When E is not node kind consistent then there is a set X in CoTypes(E) such that {Lit, T } ⊆ X for some T in T. By Lemma 3.3.2, there is an instance I of R where the co-typing of its core pre-solution J 0 contains X. We construct an instance I where the active domain is composed of only one constant i.e., adom(I) = {a} for some a ∈ Const. Because the active domain is only one constant, J 0 is value consistent. Since CoTypes(J 0 ) contains X, then J 0 is not node kind consistent. Since we require J 0 to be value consistent and node kind consistent by Lemma 3.4.1 for I to admit a solution, then because we have that J 0 is value consistent and not node kind consistent, then I does not admit a solution to E. Consequently, E is inconsistent.

For the ⇐ direction. We assume E is value consistent and node kind consistent.

We prove that E is consistent. We take an instance I of R. By definition of value consistent and node kind consistent, its core pre-solution is value consistent and node kind consistent. By Lemma 3.4.1, we know that there is a solution to I w.r.t. E. Then, we conclude that E is consistent.

Decidability

Now, we show that the checking the two conditions for consistency independently is decidable.

Node kind consistency

We show that checking node kind consistency is decidable with the following lemma.

Lemma 3.4.2. Deciding whether E is node kind consistent is in coNP.

Proof. A certificate for deciding node kind inconsistency is composed of types T, S, S ∈ T and a function symbol f ∈ F. We use the Algorithm 3 to decide if E is node kind inconsistent. More precisely, we choose non-deterministically T, S, S and f s.t. (S, f ) and (S, f ) are accessible in E (the latter can be tested in polynomial time). Finding nodes in G E that contains S and S can be tested in polynomial time. Reachability of a node in a graph also can be done in polynomial time. Thus the whole algorithm runs in polynomial time. Consequently, deciding whether E is node kind consistent is in coNP.

Value consistency

We show that checking value consistency is decidable with the following lemma.

Lemma 3.4.3. Deciding whether E is value consistent is in coNP.

Proof. Theorem 3.2.7 implies that E is value inconsistent if and only if there is an instance I π,σ,σ in CInst(Σ st ) such that there is a solution I for I π,σ,σ to the set of functional dependencies Σ fd of R. This instance I is a certificate for the value inconsistency.

We now argue that such certificate has size polynomial in the size of E and we can test in polynomial time whether the setting is indeed value inconsistent with Algorithm 1. Thus, the Algorithm 1 is a procedure that decides if E is value inconsistent. It remains to prove that Algorithm 1 runs in polynomial time. By construction of a contentious-based instance, I is constructed in polynomial time. The construction of V R is in polynomial size because the set of violation sorts V s is finite, and the construction of V s is in polynomial size of T, F and Prop S ; and the construction of each I π,σ,σ is in polynomial size. Then the construction of V R is in polynomial time because for any I ∈ V R , testing if I satisfies functional dependencies of R can be done with the chase of Σ fd . The chase does not increase the size of the instance, and only a polynomial number of chase steps can be executed before a solution to I w.r.t. Σ fd or a failure is reached. The evaluation of each chase step is polynomial since all bodies of dependencies in Σ fd contain exactly two atoms, thus require to compute a unique join in order to be evaluated. Finally, testing the emptiness of V R is in polynomial time. Consequently, deciding whether E is value consistent is in coNP.

Finally, based on these results we show that checking consistency for E is decidable with the following theorem.

Theorem 3.4.2 (Complexity of consistency). Checking consistency of a relational to RDF data exchange setting is coNP-complete.

Proof. To show that checking consistency is coNP-complete, we show that this problem is in coNP (upper bound) and it is as hard as all problems that are in coNP (lower bound).

We first prove that deciding consistency is coNP and then the coNP-hardness.

Upper bound. By Theorem 3.4.1, deciding consistency is equivalent to decide value consistency and node kind consistency. Checking value consistency and node kind consistency is coNP as shown in Lemmas 3.4.3 and 3.4.2 respectively. Therefore, deciding consistency is in coNP.

Lower bound. We recall that complement of SAT is coNP-hard. Therefore, to show coNP-hardness, we reduce from the complement of SAT to deciding consistency. Take any CNF ϕ = c 1 ∧ . . . ∧ c m for m ∈ N, where c j = j,1 ∨ . . . ∨ j,k j for k j ∈ N is a clause over the variables x 1 , . . . , x n for n ∈ N. We define a data exchange setting E ϕ = (R, S, Σ st , F) that is inconsistent. The relational schema is defined with the following signature R = {V t , V f , R 1 , . . . , R n }. The relational schema consists of the following binary relations (each relation with a single key)

V t (x, y), V f (x, y), R 1 (x, y), . . . , R n (x, y)
The library of IRI constructors F consists of the following set of IRI constructors

F = {f 1 , . . . , f n , f n+1 }
and their interpretation F is the concatenation of a number, which is the number of function, and the value of the argument i.e., f i (x) = "i:" + str(x). The shapes schema S consists of the following set of types:

T = {T 1 , . . . , T n , T n+1 },
and the shape constraints:

T j → p :: T * j+1 for 1 ≤ j ≤ n and
(3.1)

T n+1 → p :: Lit 1 . (3.2)
The set of st-tgds Σ st are defined as follows. First, we have the two rules:

V t (x, y) ⇒ Triple(f n+1 (x), p, y) (3.3) V f (x, y) ⇒ Triple(f n+1 (x), p, y) (3.4)
Next, for any 1 ≤ j ≤ m let c j = j,1 ∨ . . . ∨ j,k j and for 1 ≤ k ≤ k j if j,k = x i for some i ∈ {1, . . . , n}, then we add this rule

R i (x, y) ∧ V t (x, y) ⇒ Triple(f j (x), p, f j+1 (x)) (3.5)
and otherwise if j,k = ¬x i , then we add this rule

R i (x, y) ∧ V f (x, y) ⇒ Triple(f j (x), p, f j+1 (x)) (3.6)
And finally, we add the following two rules:

V t (x, y) ⇒ T 1 (f 1 (x)) (3.7) V f (x, y) ⇒ T 1 (f 1 (x)) (3.8) We claim that ϕ ∈ SAT iff E ϕ is not consistent.
For the ⇒ direction. Assume ϕ ∈ SAT. We take a valuation θ that satisfies ϕ and construct an instance I θ as follows. We fix 3 constants c, t, and f. The instance is

I θ = {V t (c, t), V f (c, f)} ∪ {R i (c, t) | i ∈ {1, . . . , n}, θ(x i ) = true} ∪ {R i (c, f) | i ∈ {1, . . . , n}, θ(x i ) = false}.
where n is the number of propositional variables that appear in ϕ. It is easy to see that

I θ is consistent of R.

Now the proof goes by induction in the number n of different propositional variables

that appears in ϕ. The base case is that n = 0 i.e., ϕ does not have any propositional variables. By construction of E ϕ , we have that the relational signature is R = {V t , V f }, the set of IRI constructors is F = {f 1 }, the set of types T = {T 1 } and the set of st-tgds Σ st is composed of rules: (3.3),(3.3),(3.7) and (3.8). The shapes schema has one shape definition for T 1 that is T 1 → a :: Lit 1 . The instance is I θ = {V t (c, t), V f (c, f)}. We chase I θ with Σ st ∪ Σ S obtaining a graph J that contains T 1 (f 1 (c)) and the two triples

Triple(f 1 (c), p, t) and Triple(f 1 (c), p, f) which violates the shape constraint on the type T 1 . Suppose that (IH) our claim holds for u number of propositional variables:

ϕ ∈ SAT iff E ϕ is not consistent. Let ϕ = ϕ ∧x u+1 . We construct E ϕ = (R , S , Σ st , F),
adding one more relation R u+1 to the relational signature in E ϕ . Also, we add the IRI constructor f u+2 to those defined in E ϕ and the corresponding type T u+2 . Then, we add the triple constraint p :: T * u+2 in the definition of T u+1 and the triple constraint p :: Lit 1 in the definition of the type T u+2 . Finally, we add to the Σ st of E ϕ the following rules:

V t (x, y) ⇒ Triple(f u+2 (x), p, y) V f (x, y) ⇒ Triple(f u+2 (x), p, y) R u+1 (x, y) ∧ V t (x, y) ⇒ Triple(f u+1 (x), p, f u+2 (x)).
By IH there is a valuation θ that satisfies ϕ. Let θ (x i ) = θ(x i ) for i ∈ {1, . . . , u} and θ (x u+1 ) = true. We construct I θ = I θ ∪ {R u+1 (c, t)}. We chase I θ with Σ st ∪ Σ S obtaining a graph J that contains T u+2 (f u+2 (c)) and the two triples Triple(f u+2 (c), p, t)

and Triple(f u+2 (c), p, f) which violates the shape constraint on the type T u+1 .

For the ⇐ direction. Assume E ϕ is not consistent. By negation of Theorem 3.4.1, E ϕ is value inconsistent or node kind inconsistent. It is easy to see that E ϕ is node kind consistent because by negation of Theorem 3.3.3, the co-typing of E ϕ does not contain {Lit, T } for some T ∈ T. Thus, E ϕ is value inconsistent. By negation of Definition 3.2.1, there is an instance I of R such that the core pre-solution J 0 to I is value inconsistent. By negation of definition of graph to be value consistent, there is a violation in J 0 . The only triple constraint that can be violated is p :: Lit 1 in the type definition of T n+1 where n is the number of propositional variables in ϕ. Consequently J 0 contains T n+1 (a n+1 ), Triple(a n+1 , p, t), and Triple(a n+1 , p, f), for some a n+1 , f, and t. Naturally, the two triples must be introduced with the rules (3.3) and (3.3), and therefore, there is a constant c such that a n+1 = f n+1 (c), V t (c, t) ∈ I, and V f (c, f) ∈ I. Now, the proof goes by induction in the number n of propositional variables as done in the proof of the ⇒ direction. It is easy to see with the inductive proof for every j ∈ {1, . . . , n} we have T j (f j (c)) ∈ J 0 , Triple(f j (c), a, f j+1 (c)) ∈ J. We observe the triples Triple(f j (c), a, f j+1 (c)) can only be added by chase with the use of rules (3.5) and (3.6), and the inductive proof also shows that every clause c j has at least one literal for which the corresponding rule must have been triggered. Since I is consistent of R then there is not R i (c, t) and R i (c, f) in I for i ∈ {1, . . . , n} or I may have none of the two. We can therefore define the following valuation

θ(x i ) =      true if R i (c, t) ∈ I, false otherwise.
We show that valuation θ satisfies ϕ by observing that if for the chase triggers a clause (3.5) or (3.6) that corresponds to some literal of c j , then θ satisfies c j . We finish the proof by observing that the proposed reduction is polynomial.

Conclusion

We have studied the problem of checking consistency of a constructive data exchange setting. We have proposed a static analysis tool that decides if a constructive setting is consistent or not. This tool consists of checking conditions that are necessary and sufficient for deciding consistency. These conditions are value consistency and node kind consistency. Both conditions use the core pre-solution to do the analysis. The first condition verifies the presence of violations that is when a node has two edges with the same predicate and the neighbor nodes are constants while the shapes schema constrains the node to have one outgoing edge with that predicate. The second condition verifies that there is no malformed rule such that the application of rules can produce a graph with a node whose type is literal and non-literal. The static analysis tool checks the value consistency by creating counter-examples from the setting. If they are valid counter-examples, instances that are consistent with the relational schema then the setting is not value consistent. The checking of node kind consistency is done by creating a co-typing graph of the setting and evaluating if there is a node where literal and non-literal types co-occur. Finally, the checking of consistency is coNP-complete.

Related work

Consistency in the case of relational data exchange is undecidable, and decidable classes usually rely on chase termination ensured by restrictions such as acyclicity, or guarded dependencies, or restrictions on the structure of source instances. Relational to RDF data exchange studied here is a particular case of Relational Data Exchange (except for the IRI constructors, which however do not bring difficulties), therefore all results on relational data exchange apply also to the setting studied here.

De Rougemont et Vielleribière studied the problem of source-consistency in the context of approximate data exchange [START_REF] De | Approximate Data Exchange[END_REF]]. The setting is in the context of trees and words i.e., they transform from a source tree to a target tree, and from a source word to a target word. The mappings are specified by transducers.

They did not study the problem of checking consistency of the setting, but, the property of far distance and close distance of an instance to the setting can be adapted to test consistency of our setting. In that sense, the checking tool can construct counter-examples and adapt the property of far and close distance, and if there is an instance that is far from the setting then the setting is not consistent. It remains to be proven if it can be decidable.

On the other hand, we can consider an OBDA system as a data exchange setting because it is composed of source relational schema, an ontology, and a set of mappings.

Console et Lenzerini [START_REF] Console | [END_REF] studied the case of consistency on an OBDA system. They define two conditions that ensure the consistency of an OBDA system, which are faithfulness and protection. Protection means that if an instance of the relational schema does not satisfy the source constraints then there is no solution to the instance w.r.t. the ontology constraints. Faithfulness means that there is a solution to an instance if the instance is consistent with the relational schema. These conditions are related to the condition of value consistency of a constructive setting in the sense that both conditions of OBDA and constructive setting checks if the source constraints can cause a conflict in the solution w.r.t. the target schema. Authors show that checking consistency of an OBDA system is undecidable, but for OBDA systems with ontologies written in DL-Lite [Calvanese et al. 2005], checking consistency is in NP.

Finally, consistency in the case of XML data exchange was studied by Bojańczyk et al. in [START_REF] Bojańczyk | [END_REF]. Authors called absolute consistency and it is defined if for every possible source XML document there is a solution. The complexity of checking absolute consistency is coNEXP. To our knowledge, there are no other studies of consistency in other data exchange contexts.

Chapter 4

Certain query answering

Motivation and problems

Incomplete information is present in the result of the data exchange from relational to RDF in the presence of shapes schema. Moreover, given a source relational instance, there is an infinite number of solutions and, an answer to a query over a single solution does not provide relevant information. We are interested in answers that are preserved in every solution. Therefore, we focus on the study of certain query answering, which is the computation of good answers i.e., answers present in all solutions, because these good answers provide relevant information from graphs that contain incomplete data.

Certain query answering in the context of data exchange involves two main challenges that are reliable answers and materialization of a good solution [Fagin et al. 2005a].

For the first challenge, we consider reliable answers to a query w.r.t. a data exchange setting E = (R, S, Σ st , F) and a consistent instance I of R those answers that are preserved in every solution to I w.r.t. E. For the second challenge, we consider that for any class of queries Q, for any data exchange setting E and for any instance I of R, a graph G is a good solution to I w.r.t. E and Q if and only if G is finite and for any query Q ∈ Q, G preserves certain answers to query Q. Then, computing certain answers depends on the family of queries and the family of data exchange settings.

Results from existing approaches

In this section, we show how existing results can be easily adapted from relational data exchange and query answering.

Super-weakly acyclic tgds

Marnette [Marnette 2009] introduces the class of super-weakly acyclic tgds that has the property of chase termination producing a universal solution, which is used to compute certain answers.

Definition of super-weakly acyclic tgds

Super-weak acyclicity [Marnette 2009] is defined using a unification algorithm and its conditions are based on the study of oblivious chase, which is distinguished from restricted chase (presented in Section 1.3.2) in the sense that the rule is triggered even if the head is already satisfied.

The approach to identify whether a set of tgds is super-weakly acyclic uses the skolemization method that replaces every existentially-quantified variable by a Skolem function (cf. Section 1.3) that depends on all the universally-quantified variables that appear before the existential variable (in the original tgd). Marnette defines the skolemization as follows.

Definition 4.2.1. Given a set of tgds Σ, skolemization, denoted by P(Σ), is the function that replaces every tgd σ ∈ Σ of the form ϕ(x, y) ⇒ ∃z. ψ(y, z) by a tgd ϕ(x, y) ⇒ ψ(y, f σ z 1 (x), . . . , f σ zn (x))

where n = |z| and f σ z j is a fresh function symbol of arity |x|.

We fix Σ to be a set of tgds and let P(Σ) the skolemization of Σ. We recall technical definitions used by Marnette. A place is a pair (R(t), i) that indicates the term that appears in the position i of a relational atom R(t) where R(t) is a relational atom of P(Σ) with some vector of terms t and 1 ≤ i ≤ |attrs(R)|. Given a tgd σ ∈ Σ and a existential variable y ∈ vars(head (σ)) \ fvars(head (σ)), we define Out(σ, y) as the set of places (called output places) in the head of P(σ) where a function term of the form f σ y (t) occurs for some vector of terms t. Given a tgd σ ∈ Σ and a universal variable x of σ, we define In(σ, x) as the set of places (called input places) in the body of σ where x occurs.

Given a set of variable names V ⊆ V V , a substitution θ is a function mapping each v ∈ V to a finite term θ(v) build upon constants and function symbols. Two places (R(t), i) and (R(t ), j) for some vector of terms t and t are unifiable, in symbols (R(t), i) ∼ (R(t ), j), iff i = j and there exist two substitutions θ and θ such that for every t ∈ t, t ∈ t , it holds that θ(t) = θ (t ). Given two sets of places P and P , we write P ⊆ P for the containment between two sets of places iff for all p ∈ P there exists some p ∈ P such that p ∼ p . Given a set P of places, we define Move(Σ, P ) as the smallest set of places P such that P ⊆ P , and for every tgd of the form ϕ ⇒ ψ in P(Σ) and for every universal variable x, if Γ x (ϕ) ⊆ P then Γ x (ψ) ⊆ P , where Γ x (ϕ) and Γ x (ψ) denote the sets of places in ϕ and ψ where x occurs respectively. Given two tgds σ, σ ∈ Σ, we say that σ triggers σ in Σ, in symbols σ σ , iff there exists an existential variable y in the head of σ, and a universal variable x in σ occurring both in the body and the head of σ such that:

In(σ , x) ⊆ Move(Σ, Out(σ, y)).

A trigger relation is acyclic if there is no σ that triggers σ. A set of tgds Σ is superweakly acyclic iff the trigger relation is acyclic. We illustrate the evaluation of a set of tgds that is super weakly acyclic in Example 4.2.4.

Weakly-recursive shapes schema

We identify a family of weakly-recursive shapes schemas whose set of dependencies is super-weakly acyclic tgds. To define this family of shapes schemas, we define the dependency graph of a shapes schema, which is a modification of the shape graph of a shapes schema (cf. Section 1.5.2), as follows.

Definition 4.2.2. Let S = (T, δ) be a shapes schema and G S = (T, E S ) be the shape graph of S. The dependency graph of S is the directed graph whose set of nodes is T and has an edge (T, T ) if there is an edge with T and T in the set of edges of the shape graph i.e., (T, (p, µ), T ) ∈ E S for some p ∈ Prop S and some µ ∈ {1, ?, +, *}.

There are two kind of edges: (T, T ) is a strong edge if the edge (T, (p, µ), T ) ∈ E S has multiplicity µ in {1, +}; and (T, T ) is a weak edge if the edge (T, (p, µ), T ) ∈ E S has a multiplicity in {*, ?}.

We are now ready to define a kind of shapes schema that guarantees a super-weakly acyclic set of dependencies.

Definition 4.2.3. A shapes schema is weakly-recursive if for its dependency graph, every cycle has at least one weak edge.

For instance, Figure 4.1 shows the dependency graph of shapes schema in Example 1.5.1.

We observe that this dependency graph has only one cycle composed at least of one weak edge. Thus, the shapes schema in Example 1.5.1 is weakly-recursive. We recall that a shapes schema can be translated to a set of dependencies as shown in Section 1.5.4. We illustrate that set of dependencies that captures the weakly-recursive shapes schema of Example 1.5.1 is super-weakly acyclic. Then, the set of places in Σ S : p 1 = (ShResearcher(x), 1), p 2 = (Triple(x, foaf:knows, y), 1), p 3 = (Triple(x, foaf:knows, y), 3), p 4 = (ShResearcher(y), 1), p 5 = (ShResearcher(x), 1), . . . , p 25 = (ShAddress(y), 1). The set of input places and output places are as follows:

ShResearcher ShTopic ShUniversity

ShAddress

In(σ 1 , y) = {p 3 } In(σ 2 , x) = {p 5 } In(σ 3 , y) = {p 10 } In(σ 4 , x) = {p 11 } In(σ 5 , y) = {p 17 } In(σ 6 , x) = {p 19 } In(σ 7 , y) = {p 24 } Out(σ 2 , y) = {p 7 } Out(σ 4 , y) = {p 14 } Out(σ 6 , y) = {p 21 }
We can observe that the places p 18 and p 19 are unifiable because there are two substitutions θ and θ such that θ(x) = θ (y). Another pair of places that are unifiable are p 7 and p 10 because there are two substitutions θ and θ such that θ(x, ex:masters, y) = θ (x, ex:masters, f y (x)). But, places p 2 and p 6 are not unifiable because there is not pair (θ, θ ) of substitutions such that θ(x, foaf:knows, y) = θ (x, ex:masters, y). We can check that the only pairs of places that are unifiable are the following: We observe that there is no rule σ that triggers itself. Therefore, the set of dependencies Σ S is super-weakly acyclic.

p 1 ∼ p 4 ,
In general, any cycle with at least one weak edge in the dependency graph of a shapes schema makes trigger relations to be acyclic. Thus, a set of dependencies that captures a weakly recursive schema is super-weakly acyclic as shown in the following lemma.

Lemma 4.2.1. For every shapes schema S, if S is weakly-recursive then Σ S is superweakly acyclic.

Proof. Take a shapes schema S. Assume S is weakly-recursive. We prove by contradiction. Assume Σ S is not super-weakly acyclic i.e., there is σ ∈ Σ S such that σ σ. By definition of trigger relation there is an existential variable y in the head of σ and a universal variable x occurring in body and head of σ such that In(σ, x) ⊆ Move(Σ S , Out(σ, y)). The only kind of rule in Σ S that has an existential variable is a PE rule, which also has a universal variable occurring in body and head. Let σ be T (x) ⇒ ∃y. Triple(x, p, y) for some T ∈ T. We compute In(σ, x) and the function returns a set composed of one position because there is one universal variable occurring in body and head of σ. Let this position be p i . We compute Out(σ, y) and the function such that p i ∼ p k . This means that there are two relational atoms with the same name that are unifiable in positions p i and p k . This p k is in a tgd that corresponds to a TP rule such that the head is T (x) and this head is unifiable with the body of σ. Since PE corresponds to a multiplicity {1, +} and TP rule propagates the type and because this unification sequence between PE and TP rules, then there is a cycle from T → . . . → T composed of only strong edges. Thus, S is not weakly-recursive; a contradiction.

The property of weakly-acyclic tgds w.r.t. query answering identified by Fagin et al. [Fagin et al. 2005a], is also applicable to super-weakly acyclic tgds [Marnette 2009].

Thus, we get the following corollary.

Corollary 4.2.1. Let E be a relational to RDF data exchange setting with weaklyrecursive target schema. Let I be a consistent instance of R. Let Q be the class of conjunctive queries over the target schema.

1. If the chase with I and E does not fail then a universal solution J to I w.r.t. E exists and cert E (Q, I) = Q(J) for some Q ∈ Q.

2. The data complexity of computing certain answers to a query in Q w.r.t. I and E is in PTIME.

Discussion

This approach of using the result of super-weakly acyclic tgds achieves the two challenges of query answering. A universal solution is materialized and we can decide if a tuple of constants from Iri∪Blank∪Lit are certain answers by testing membership in the universal solution. A limitation of this approach is that it only applies to weakly-based settings and not all families of data exchange settings.

Guarded tgds

We recall the definition of guarded tgds. A tgd σ is guarded iff it contains an atom in its body that contains all universally quantified variables of σ. We use the results from Calì et al. [Calì et al. 2012a] for query answering under guarded tgds.

First, we show that the set of dependencies Σ S that captures the shapes schema is guarded. We recall that Σ S is constructed with the TP, PF and PE rules. We observe that the TP rule is guarded because there is a guarded atom that is Triple. For the PE rule the guarded atom is the type name.

Computing certain answers and data complexity

Based on the results of Calì et al., we can compute certain answers to the family of Boolean conjunctive queries (BCQ) Q w.r.t. any data exchange setting E. Let I be an instance of R, a query Q in Q and a data exchange setting E, we construct an auxiliary finite structure using the guarded chase with I and Σ st ∪ Σ S as follows. Recall that G = {Triple} is the relational signature of RDF graphs. For every fact in I, we construct all exponential descendants in the guarded chase up to (|Q| + 1)

• |G| • (2 • w) w • 2 |G|•(2•w) w
where w is the maximal arity of a relation in G. The complexity of the construction of all descendants is exponential in the size of R. Since the size of the graph signature is one and the value of w is three, then the construction of descendants for a fact in I is up to (|Q| + 1) • 216 • 2 216 . Since |Σ st ∪ Σ S | is constant and the guarded chase is seen as a tree, then every node in this tree has only a constant number of children. Thus, the tree can be constructed in constant time, and the number of applications of tgds in it is constant. Hence, the union of all applications of tgds in the trees of descendants of all R(a) ∈ I for some R ∈ R and some vector of constants a can also be constructed in linear time. We compute certain answers to Q w.r.

Discussion

This approach of using the results of guarded tgds does not achieve the first challenge of materializing a good solution. The second challenge is achieved but the complexity of construction of the finite structure is very high likely because the setting proposed by Calì et al. is more general.

Simulation-based approach

In this section, we propose a simulation-based approach for certain query answering and construct a good solution. This approach covers all constructive data exchange settings that we have defined until now and uses a navigational query language for graphs.

Throughout this section, we fix a constructive relational to RDF data exchange setting E = (R, S, Σ st , F) and assume it is consistent. We also fix a consistent source instance

I of R.

Preliminar notions

Now, we recall two main concepts that are used in the definition of bisimulation.

Graph simulation

The notion of simulation was introduced by Milner [Milner 1971] to define how a process is simulated by another process in a program system. Henzinger et al. [Henzinger et al. 1995]

R ⊆ nodes(G) × nodes(H)
such that for any (n, m) ∈ R, we have

• n is a literal node if and only if m is a literal node,

• if n is not a null node, then m is not a null node and n = m; and

• for any outgoing edge from n with label p that leads to n there is a corresponding outgoing edge from m with label p that leads to m such that (n , m ) ∈ R.

A finite family of sets is closed under union if, for any two element of the family, the union of these two sets is in family. It is east to see that any finite family closed under union has exactly one maximal element [Winskel 1993].

E ::= | p | | | [E] | E * | E -| E • E | E + E where p ∈ Prop S , ∈ Iri ∪ Lit,
G = {(n, n) | n ∈ nodes(G)}, [E] G = {(n, n) | ∃m. (n, m) ∈ E G }, p G = {(n, m) | (n, p, m) ∈ G}, G = {(n, m) | ∃p ∈ Iri. (n, p, m) ∈ G}, E 1 + E 2 G = E 1 G ∪ E 2 G , G = {(n, n) | n ∈ nodes(G) ∧ n = }, E 1 • E 2 G = E 1 G • E 2 G , E * G = E * G . E - G = E -1 G .
where E * G is the Kleene's closure of E G and E -1 G is the inverse relation of E G . An NRE is forward if it does not use the inverse operator. In the sequel, we focus on the forward NRE. A forward NRE E is satisfied in a graph G, in symbols G |= E, if and only if E G = ∅. Also, we define the size of a forward NRE as its number of symbols:

|E 1 • E 2 | = |E 1 + E 2 | = |E 1 | + |E 2 | + 1, |[E]| = |E * | = |E| + 1 and | | = |p| = | | = | | = 1.

Forward NRE-based Boolean query language

A query Q can be expressed using forward NREs. We define an answer and certain answer to a query expressed with NRE as follows:

Definition 4.3.2. A pair of nodes (n, m) is an answer to a forward NRE E in a graph G iff (n, m) ∈ E G . A pair (n, m) is a certain answer to a forward NRE E in I w.r.t. E iff (n, m
) is an answer in every solution to I w.r.t. E.

A forward-based Boolean query is a query expressed by a forward NRE E such that its answers is true if there is an answer to E in G, or false otherwise. True is certain answer to a forward NRE E in I w.r.t. E iff true is the answer in every solution to I w.r.t. E.

Robust query classes

Now, we define a class of Boolean queries for which computing certain answers is possible.

Definition 4.3.3. A class Q of Boolean queries on graphs is robust under simulation iff for any query Q ∈ Q and any two graphs G and H such that G is simulated by

H, if Q is true in G, then Q is true in H.
Next step, we show that the subclass of forward NREs is robust under simulation. Proof. We fix G, H to be graphs and E to be a forward NRE-based Boolean query. We first prove the following claim. Proof. Take two graphs G, H. Take three nodes n, n ∈ nodes(G) and m ∈ nodes(H).

Assume n m and (n, n ) ∈ E G . The proof is by induction on the structure of E.

For a forward NRE E of size |E| = 1, we have the following cases:

• When E = , the assumption is (n, n ) ∈ G .
Then n = n and by assumption m ∈ nodes(H), trivially (m, m) ∈ H . Then m = m. Therefore, n m .

• When E = p, the assumption is • When E = , the assumption is (n, n ) ∈ G . By semantics of G and n m, there is a m ∈ nodes(H), and p ∈ Prop S such that (m, p, m ) ∈ H.

(n, n ) ∈ p G .
Since (m, p, m ) ∈ H, then (m, m ) ∈ p H and n m .

• When E = , the assumption is (n, n ) ∈ G . Then n = n and n = . Since n m, then m = . By m = and m ∈ nodes(H), then (m, m) ∈ H . Let m = m, then n m . Now, let E be of size i and assume for any sub expression E with size less than i, it holds the Claim 4.3.1.1. E can be the composition of two sub expressions E 1 and E 2 .

Then, we have the following cases:

1

. E = E 1 + E 2 . By semantics of +, (n, n ) ∈ E 1 G or (n, n ) ∈ E 2 G . By induction hypothesis on E 1 , there is m ∈ nodes(H) such that (m, m ) ∈ E 1 H and n m . Therefore, (m, m ) ∈ ( E 1 H ∪ E 2 H ). By previous result, (m, m ) ∈ E H .
The proof for the second case is similar.

2 Also, E can be composed of only of one subexpression E 1 as follows:

. E = E 1 •E 2 . By semantics of •, (n, n ) ∈ E 1 G • E 2 G . By composition of binary relations, there is n 2 ∈ nodes(G) such that (n, n 2 ) ∈ E 1 G and (n 2 , n ) ∈ E 2 G . By induction hypothesis on (n, n 2 ) ∈ E 1 G and n m, there is m 2 ∈ nodes(H) such that (m, m 2 ) ∈ E 1 H and n 2 m 2 . By induction hypothesis on n 2 m 2 and (n 2 , n ) ∈ E 2 G , there is a m ∈ nodes(H) such that (m 2 , m ) ∈ E 2 H
1. E = E * 1 . By semantics of Kleene closure * , we have that (n, n

) ∈ k≥0 E 1 k G .

By union of binary relation, we obtain

(n, n ) ∈ G ∪ E 1 G ∪ E 1 2 G ∪ E 1 3 G . . .

By definition of binary relation to some number,

(n, n ) ∈ G ∪ E 1 G ∪ E 1 G • E 1 G ∪ E 1 G • E 1 2 G . . .

It was proven for

G • E 1 G • E 1 G . . .. We rewrite as E 1 G • E 2 G where E 2 = E 1 1 • E 1 k-1 . Since E 2 is

Universal simulation solution

Now, we define the core component of our approach called universal simulation solution.

Construction

We begin the construction of a universal simulation solution to I w.r.t. E with the core pre-solution J 0 to I w.r.t. E because J 0 is the unique minimal typed graph that satisfies st-tgds Σ st and TP rules for S (cf. Section 1.5.4). Then, we compute the completed graph G E (I) w.r.t. I and E (cf. Section 3.3.2). Thus, we obtain the typed graph U = J 0 ∪ G E (I). Now, we show that U is a universal simulation solution to I w.r.t. E with the following lemma.

Lemma 4.3.2. Let I be an instance of R. Let J 0 be the core pre-solution to I w.r.t. E

and G E (I) be the completed graph w.r.t. I and E. Let U = J 0 ∪ G E (I) be a typed graph.

For every solution J ∈ sol E (I) to I w.r.t. E, U is simulated by J.

Proof. Take an instance I of R and a solution J ∈ sol E (I). Let J 0 be the core presolution to I w.r.t. E and G E (I) be the completed graph w.r.t. I and E. We construct the following relation

R = {(n, m) ∈ nodes(J 0 ) × nodes(J 0 ) | n = m} ∪ {(n, m) | ∃(n 0 , p 0 ) ∈ F S (J 0 ). ∃π = p 0 • p 1 • . . . • p k . n ∈ ∇ U ({n 0 }, π)∧, m ∈ ∇ J ({n 0 }, π)}.
where the function ∇ G over a graph and path in a graph are defined in Section 3.3.5.

We show that R is a simulation of U by J. Then, we take any pair (n, m) ∈ R and p ∈ Prop S . We have the following cases:(a) n ∈ nodes(J 0 ) ∧ (n, p) ∈ F S (J 0 ) and (b)

(n, p) ∈ F S (J 0 ) ∨ n ∈ nodes(G E (I)).
For the case a. We know that (n, m) ∈ nodes(J 0 ) × nodes(J 0 ) and n = m. We take n ∈ nodes(J 0 ) such that Triple(n, p, n ) ∈ J 0 . As a result of considering m = n , we obtain m ∈ nodes(J 0 ) then m ∈ nodes(J). Since Triple(n, p, n ) ∈ J 0 , then we have Triple(m, p, m ) ∈ J 0 , and by (n , m ) ∈ nodes(J 0 ) × nodes(J 0 ), we conclude

(n , m ) ∈ R.
To prove the case b, we require the following claim where we use the notion of a path in a graph G and frontier defined in Section 3.3.2. Also, we use the obligatory property label and an extension of the type reachability function presented in Section 3.3.1 to define a set of types reachable by a path as follows:

∆ * (X, π • p) = ∆(∆ * (X, π), p), ∆ * (X, ε) = X.
Claim 4.3.2.1. For any instance I of R, let J 0 be the core pre-solution to I w.r.t. E, let G E (I) be the completed graph w.r.t. I and E, and let U = J 0 ∪ G E (I). For any solution J ∈ sol E (I) to I w.r.t. E and for any path π ∈ Prop * S in U , it holds that π is also in J.

Proof. Take any instance I of R and take any solution J ∈ sol E (I) to I w.r.t. E. We compute the core pre-solution J 0 to I w.r.t. E. We compute the completed graph G E (I) w.r.t. I and E. Let U = J 0 ∪ G E (I). Take a path π ∈ Prop * S . Assume π exists in U . We prove by induction in the size of π. The base cases is when π is of size 1 and 0 i.e., π = p 0 and π = ε. For the case of size 0, trivially holds. For case of size 1. We distinguish two cases: when π starts at a node that is not in the frontier of J 0 and when π starts at a node that is in the frontier of J 0 . For the first case, we know J 0 is in every solution, so π is in J. For the second case where π = p 0 , we know (n 0 , p 0 ) ∈ F S (J 0 ) and by definition of frontier p 0 ∈ Req(types J 0 (n 0 )). Since J is a solution to I w.r.t. E then the outgoing edges required in S by types J 0 (n 0 ) must be satisfied. Since p 0 ∈ Req(types J 0 (n 0 )), then there is m ∈ nodes(J) such that Triple(n 0 , p 0 , m) ∈ J. Thus, π is in J. Now, we assume the claim holds for any path π in U of length k > 1. Take any path π in U of length k + 1. By definition of path in a graph, there is a sequence of nodes n 0 , . . . , n k such that (n i-1 , p i-1 , n i ) ∈ U where i ∈ {1 . . . , k} and π = p 0 • . . .

• p k-1 . Let π = π • p k-1 such that |π | = k -1 and π = p 0 • . . . • p k-2
. By construction of U , we distinguish two cases: when π is in J 0 and since J 0 is included in every solution, then π is in J. The other case is when π is in G E (I). By hypothesis, we have that π is a path in J and there are m k-2 , m k-1 ∈ nodes(J) such that Triple(m k-2 , p k-2 , m k-1 ) ∈ J. By construction of U , every edge in G E (I) is with a obligatory property label, which means that every solution must have at least one outgoing edge with the obligatory property label. Since J is a solution to I w.r.t. E, then it holds that

Triple(m k-1 , p k-1 , m k ) ∈ J.
Thus, π is a path in J.

We continue the proof of the case b. W.l.o.g., we only consider the case when n ∈ nodes(G E (I)); the other case is implied by the proof. By n ∈ nodes(G E (I)) and

(n, m) ∈ R, we have that n ∈ ∇ U ({n 0 }, π) where π = p 1 • . . . • p k and (n 0 , p 1 ) ∈ F S (J 0 ) and m ∈ ∇ J ({n 0 }, π). Then, we take p ∈ Prop S , n ∈ nodes(U ) such that Triple(n, p, n ) ∈ U , i.e. n ∈ ∇ U ({n 0 }, π •p) and π •p is a path in U . By Claim 4.3.2.1, we have π • p is a path in J i.e., there is a node m ∈ ∇ J ({n 0 }, π • p). Thus, we conclude that (n , m ) ∈ R.

Minimal universal simulation solution

The universal simulation solution as constructed above might have nodes that are equivalent, constructing one without redundancy can be done with the notions of bisimulation and quotient bisimulation. The related notion of bisimulation has found application in normalizing blank nodes and essentially minimizing RDF graphs without altering its informational contents [Tzitzikas et al. 2012].

G/ = {(η [n] , p, η [m] ) | (n, p, m) ∈ G}.
The choice of the representative does not matter in the definition of the quotient because a non-null node is bisimilar only to itself, and consequently, every non-singleton equivalence class in nodes(G)/ contains null values only.

Universal simulation solutions are good solutions, but they can contain redundant information. Then, this raises the question if among those good solutions, can we have the best solution. The answer is inspired by the core universal solution proposed in [Fagin et al. 2005b] that is based on using minimality as a key criterion for what constitutes the best universal solution.

Definition 4.3.7. A minimal universal simulation solution U 0 to I w.r.t. E is a universal simulation solution to I w.r.t. E such that for any universal simulation solution U to I w.r.t. E, the size of U is greater or equal that the size of U 0 . Now, we show that there is a minimal universal simulation solution to I w.r.t. E. We compute the core pre-solution J 0 to I w.r.t. E. Then, we compute the completed graph G E (I) w.r.t. I and E. Then, we take the bisimulation quotient of G E (I) and together with the core pre-solution J 0 we define the T-typed graph U 0 i.e., U 0 = J 0 ∪ G E (I)/ .

We point out that because J 0 does not have any null nodes, we can write the T-typed graph U 0 as U 0 = (J 0 ∪ G E (I))/ . Now, for any universal simulation solution U to I w.r.t. E, we show that U 0 simulated by U . Proof. First, we show that U 0 is simulated by U . We construct the relation R 0 as follows.

R 0 = {(η [n] , m) ∈ nodes(U 0 ) × nodes(U ) | m ∈ [n]}. Take (η [n] , m) ∈ R 0 . Since nodes of U 0 use the maximal bisimulation of nodes of U .
There is a simulation from nodes U by nodes of U that is symmetric and reflexive.

Because n also is in U and m ∈ [n], then n is simulated by m, and consequently, η [n] is simulated by m. Thus, R 0 is a simulation of U 0 by U . Now, we show that U is simulated by U 0 . We construct the relation R 1 as follows.

R 1 = {(m, η [n] ) ∈ nodes(U ) × nodes(U 0 ) | m ∈ [n]} Take (m, η [n] ) ∈ R 0 . Take m ∈ nodes(U ). Assume (m, p, m ) ∈ U . Since also n ∈ nodes(U ) and m ∈ [n], then there is n ∈ nodes(U ) such that (n, p, n ) ∈ U .
Thus, m ∈ [n ] and we have (m , η [n ] ) ∈ R 1 . Therefore, U 0 is simulated by U and U is simulated by U 0 . Now, we show a property of U 0 .

Finally, we can state that U 0 is simulated by U because of Claim 4.3.3.1, the transitivity of simulation, and the following claim.

Claim 4.3.3.2. U is simulated by U .

Proof. We show that U is simulated by U by contradiction. Given two nodes n ∈ nodes(U 0 ) and m ∈ nodes(U ), we assume that n is not simulated by m. By negation of simulation definition, we negate the three conditions. For the first condition, we have two cases either (1.1) n is literal and m is not literal or (1.2) n is not literal and m is literal. For the first case and second case, there is a contradiction because U is simulated by U i.e., m is simulated by n, then m is literal if and only if n is literal. For the second condition we have n is not null node and n = m. Because n = m, if m is literal and by the first condition proved, we have n is literal; a contradiction.

For the third condition, for any outgoing edge (n, p, n ) ∈ U either there is no outgoing edge from m with p in U or if there exists a corresponding outgoing edge with (m, p, m ) ∈ U then n is not simulated by m . Recall that U = J 0 ∪ G E (I). Assume (n, p, n ) ∈ U . We have the following cases:

• If n ∈ J 0 , then , by second condition proved, m is in J 0 of U . Because m = n,
there is a m ∈ nodes(U ) and a corresponding edge (m, p, m ) ∈ U ; a contradiction with the no existence of edge with p.

• If n ∈ nodes(J 0 ) and n is not null node then n m . Recall that E is consistent, thus there is no co-occurrence of literal and non literal types for a node. If n is literal then m is literal. Because these nodes are literals, there are no outgoing edges, and consequently, n m ; a contradiction.

• When n is a null node, then n ∈ nodes(G E (I)). By construction of G E (I), every edge in G E (I) corresponds to an obligatory property that must be satisfied in any solution to I w.r.t. E. Since U is simulated by a solution and p is a obligatory property label and any solution must satisfy an obligatory property, then there is m ∈ nodes(U ) such that (m, p, m ) ∈ U ; a contradiction with the no existence of edge with p.

• When there is a corresponding outgoing edge with (m, p, m ) ∈ U , then because from n the outgoing edges are those that are required to stay in a solution, then U contains corresponding edges from m . Consequently, n m ; a contradiction with n is not simulated by m .

This ends the proof.

By transitivity of simulation, U 0 is simulated by every solution J to I w.r.t. E. Therefore, U 0 is a universal simulation solution. Now, we show that U 0 is minimal. The size of E is the sum of the size of the relational schema and the size of the shapes schema and the size of Σ st . Since the size of R and Σ st are 1, then the size of E is linear in m where m is the number of shape names. Finally, we get for m ∈ N, the size of |U 0 | is asymptotic to 2 2m/3 . This ends the proof of Theorem 4.3.8.

Computing certain answers

Based on the property of simulation defined previously, certain answers can be computed for Boolean queries that are robust under simulation. Thus, we state our theorem as follows.

Theorem 4.3.9. Let Q be a class of Boolean graph queries robust under simulation.

For any query Q ∈ Q and for any universal simulation solution U to I w.r.t. E, true is the certain answer to Q w.r.t. I and E if and only if true is the answer to Q in U .

Proof. Fix a family of Boolean queries Q that are robust under simulation. Take any query Q ∈ Q. Take a universal simulation solution U to I w.r.t. E.

For the ⇒ direction. We assume true is certain answer to Q w.r.t. I and E i.e., true in all solutions J to I w.r.t. E. Take a solution J. By Lemma 4.3.2, U is simulated by the solution J. By property of queries that robust under simulation, we conclude true is an answer to Q in U .

For the ⇐ direction. It suffices to notice that a universal simulation solution is also a solution as shown in Lemma 3.3.4.

Data complexity

Now, we evaluate the tractability of our framework for the problem of computing certain answers to a query w.r.t. I and E. This evaluation is done using data complexity. Data complexity of evaluating NREs is known to be PTIME [Pérez et al. 2010]. Thus, the evaluation of our approach with forward NREs is stated in the following theorem.

Conclusion

The current chapter shows an adaptation of existing results in relational data exchange to certain query answering in relational to RDF data exchange. Our approach proposes a family of Boolean graph queries that are robust under simulation where computing certain query answering is decidable. We have shown that forward NRE-based query language is robust under simulation. We have introduced the notion of universal simulation solution, which can be constructed for any constructive data exchange setting, that allows to easily compute certain answers to any query class robust under simulation.

We have achieved attractive complexity for certain query answering. Our approach is different from the adaptation of existing results, as seen in Table 4.1 where M. is the acronym for materialization. We treat a family of queries that are incomparable with the family of queries treated in the existing results. Moreover, there is no restriction in the shapes schemas, so we cover any kind of data exchange settings.

It remains an open question to explore full NRE-based query language and investigate if computing certain query answering is decidable. We envisage as a possible idea to use two way alternating tree automata (2ATA) [Vardi 1998] for infinite trees corresponding to unraveling the universal simulation solution. This idea has been applied

to the closely related problem of computing certain answers to variants of regular path queries in the presence of ontologies [Jung et al. 2018[START_REF] Calvanese | Answering regular path queries in expressive Description Logics via alternating treeautomata[END_REF]].

Related work

A considerable amount of work has been done in the area of certain query answering [Fagin et al. 2005a, David et al. 2010[START_REF] Arenas | XML data exchange: Consistency and query answering[END_REF], Arenas et al. 2013, Pérez et al. 2010[START_REF] Calvanese | Answering regular path queries in expressive Description Logics via alternating treeautomata[END_REF]. We present those that are close to our work and compare them.

Query answering for relational data exchange. Fagin et al. [Fagin et al. 2005a] use a universal solution to compute certain answers to conjunctive queries. The difference with our contribution is that we compute certain answers to forward NREs that is incomporable to conjunctive queries and we compute certain answers for any family of constructive data exchange settings while their approach can be adapted to a fragment of constructive setting where the shapes schema has no cycles in its shape graph or every cycle is only composed of weak edges.

Marnette [Marnette 2009] introduces the class of super-weakly acyclic tgds that generalizes the class of weakly acyclic tgds identified by Fagin et al. [Fagin et al. 2005a] that has the same properties with respect query answering. We have used their results in Section 4.2.1. The same difference in the family of queries as done with Fagin et al., and the result of Marnette is only applicable to constructive settings where shapes schemas are weakly-recursive while our approach is applicable to any constructive setting.

Several other results exist on certain query answering, which use chase termination [Calì et al. 2012b, Baget et al. 2011], or some finite representation of an infinite universal solution. Those works identify properties of family of tgds that allows to ob-tain chase termination. In particular, Calì et al. [Calì et al. 2012a] present a finite structure based on the chase of guarded tgds. We have used their results in Section 4.2.2.

Since the shapes schema is captured by a set of tgds that is guarded, then we do not detail the other classes. The difference with our contribution is that we materialize a solution.

Arenas et al. [START_REF] Arenas | [END_REF] propose the use of query rewriting to compute certain answers in a data exchange context. In this sense, given a data exchange setting E, given an instance I of R, a query is rewritable under the E if there is a first order formula over the target schema such that a universal solution to I w.r.t. E satisfies this formula. But it is undecidable whether a query is rewritable over a universal solution.

Consequently, Arenas et al. identify conditions to know if a query admits a rewriting over a universal solution. We can adapt this technique to our context but since it uses a universal solution, then their approach will only work for weakly-recursive shapes schemas. It is known that if a query is rewritable then query answering is AC0 in data complexity, which will be better for the particular class of weakly-recursive shapes schemas.

Query answering for XML data exchange. [START_REF] David | [END_REF]] study how to compute certain answers for XML queries. Authors define the notion of maximal description of a set of databases as a finite set of formulas over the query language that is satisfied in all structures of databases. In XML, the query language is defined by tree patterns, which is related to forward NREs because forward NRE does not use the inverse operator and NRE and queries descendant nodes as tree pattern queries children nodes. Thus, for a set of XML trees, a pattern is a maximal description if it is modeled in all XML trees. This pattern is called by authors a certain answer, because there exist a homomorphism from the pattern to every tree. Authors apply their result to the XML data exchange context obtaining PTIME in data complexity. The contributions of this work cannot be used in our context because there is no materialization of a good solution and tree patterns work only for trees. However, the notion of maximal description is similar to the universal simulation solution because every solution is simulated by a universal simulation solution.

Query answering for RDF. The majority of queries for RDF are based on graph pat-terns [START_REF] Barceló | [END_REF]]. The standard language for querying RDF is SPARQL that is based on graph pattern-matching expression. In particular, Pérez et al. [Pérez et al. 2010] present an extension of SPARQL using NREs to navigate RDF data. We use a fragment of NREs to define a family of queries where we ensure that any query of this family on a graph has certain answers. Nikolaou and Koubarakis [START_REF] Nikolaou | Querying incomplete information in RDF with SPARQL[END_REF] introduce the notion of representation system to answer SPARQL queries over a set of incomplete RDF databases. They identify a fragment of SPARQL where certain answers are ensured by querying the representation system. This notion of representation system is not a solution and the data complexity, which is coNPcomplete, is higher than ours.

Ciucanu [Ciucanu 2015] studies the problem of query answering in the context of relational to graph data exchange. He considers only egds as target constraints and defines a family of queries using full NREs. He shows that deciding computing certain answers to full NRE-based queries is coNP-hard. His work does not subsume our contribution because the set of dependencies that captures shapes schema includes not only egds but also tgds.

Another language based on graph patterns used for querying RDF is regular path queries (RPQs) [Cruz et al. 1987]. [START_REF] Barceló | [END_REF]] study the problem of certain query answering on graphs, but not in the context of data exchange, which means that no solution is materialized. Also, authors study many family of queries and show that the data complexity of computing certain answers to a query in those families ranges from NLOGSPACE to coNP. It remains an open question to adapt their work to our context.

Query answering for knowledge bases. The following works are not in the context of data exchange but they treat the problem of certain query answering on knowledge bases. Calvanese et al. [START_REF] Calvanese | Answering regular path queries in expressive Description Logics via alternating treeautomata[END_REF]] study certain query answering with positive 2-way regular path queries (P2RPQS). They take account of constraints in the knowledge base as we consider target constraints in the target schema. The drawback with their approach is that the data complexity of computing certain answers, which is coNP-complete, is higher than classical approaches and also from our approach. Bienvenu et al. [START_REF] Bienvenu | [END_REF]] study the complexity of answering queries over knowledge bases. Authors consider conjunctive two-way regular path queries (C2RPQ)

and the data complexity is NL-complete. Since their approach is not in the data exchange context, then there is no materialization of solution. Also, they do not consider target constraints.

Chapter 5

Visual mapping language

Motivation and use case

The majority of relational, XML and graph data exchange frameworks [Fagin et al. 2005a[START_REF] Arenas | XML data exchange: Consistency and query answering[END_REF], Boneva et al. 2015] use a logical language to express the rules for exchanging data. There are implementations [Marnette et al. 2011,Fagin et al. 2009, Raffio et al. 2008] of those frameworks that define a visual language for expressing the rules to reduce the difficulties of learning a logical language that a user can have. Authors of these implementations develop visual languages on top of text-based languages, such as SQL.

In the relational to RDF data exchange, an example of text-based language is R2RML.

Sicilia et al. [Sicilia et al. 2017] and [START_REF] Crotti | Juma: An Editor that Uses a Block Metaphor to Facilitate the Creation and Editing of R2RML Mappings[END_REF]] have defined visual languages for R2RML in their tools. Such visual languages facilitate the specification of mappings. However, we cannot use these tools in the data exchange from relational database to RDF in presence of shapes schema. In the following use case, we illustrate how our tool helps a database administrator to define mappings.

Example 5.1.1. Consider the database of software bug reports, presented in Figure 5.1.

Each bug is reported by a user and a bug may have a number of related bugs. Each user may track a number of bugs. We wish to export the contents of the above relational database to RDF for using by an existing application. The RDF will use three distinct IRI prefixes the default prefix ex: for the predicates, bug: for bugs, and usr: for users. The prefix ex: stands for https://example.com/, the prefix bug: stands for https://example.com/ShBug and usr: stands for https://example.com/ShUser. This schema defines two types of nodes: ShBug for bug reports and ShUser for user info.

User

This shapes schema happens to closely mimic the structure of the relational database with two exceptions: the type ShUser requires that every user must track at least one bug and must have a single email while the relational database is free of such constraints.

To assign an IRI to every user and every bug, we define two IRI constructors Bu2iri

and Us2iri that concatenate a value of the argument with the prefix bug: and usr:

respectively.

Given the database instance, the shapes schema and the set of IRI constructors presented below, a database administrator wants to export this database instance to an RDF graph that satisfies the shapes schema in some practical way. But, the administrator is not able to write mappings. Instead, the administrator can load the definition of the relational schema with DDL statements and the source instance of this relational schema from a SQL script and load the shape definition from JSON script in our tool. Then, the database administrator will see boxes with text that either represent a table with its attributes or a shape name with its triple constraints. Then graphically, the database administrator defines mappings by drawing arrows from boxes of the relational schema to boxes of the shapes schema as seen in Figure 5.2. This set of arrows seen in Figure 5.2 corresponds to the following mappings:

Preliminary notions

In this section, we recall basic notions of data visualization and human-computer interaction used to develop ShERML.

Visual representations. Interaction between users and computers is done by a graphical interface that uses visual representations of data. Visual representations [START_REF] Lohse | [END_REF]] are representations assigned to data that use visual variables (graphical objects in screen) to convey the information to the user. A visual object can be a picture, a geometric form, or text with color or composition of them.

Visual representations can be more effective than symbolic information such as text [Treisman 1985] because they amplify the cognition by providing the human more information, faster and with less cognitive effort. Thus, for non-expert users, the learning of text-based languages requires a considerable amount of time.

Visual language. Visually encoding on top of a text-based language is one way to en-able non-expert users the usage of text-based languages. As a result, we have a visual language, which is a language that uses visual representations to depict words of a textbased language A. The alphabet of a visual language is a set of visual objects and visual representations.

Interaction paradigms. The purpose of an interaction model is to provide guidelines for guiding designers and developers to create interactive systems. One such interaction model is direct manipulation [Shneiderman 1983]. This paradigm is based on visual representations and establishes a guideline when designing an interactive tool. This guideline consists of four principles: choosing a visual representation, learning components of the visual representation, setting operations with the visual representation and displaying visual representations on the screen. The first principle provides techniques to clearly and accurately represent the information. The second principle provides techniques to measure the complexity of learning the visual representation by a user. The third principle provides interaction techniques such as drag and drop. This interaction technique consists of enabling the user to move visual objects, change a sorting order or put a visual object in a particular place. The last principle provides techniques for arranging visual representations so the information is clear to the user. Hutchins et al. [Hutchins et al. 1985] show that tools following these principles facilitate the tasks of users.

The intermediary language

In this section, because VML is constructed on top a text-based language, we present an intermediary language called R2VML. It is a declarative text-based representation of the mapping language based on logical rules that uses vocabulary of SQL that is familiar for users with basic background on databases. R2VML mappings capture a fragment of constructive st-tgds specified in the data exchange framework presented in this manuscript as seen in Figure 5.4.

We can observe that writing R2VML mapping is more intuitive than writing st-tgds for a user that has background on databases. R2VML is presented without using variables compared to st-tgds and with a Turtle-like style, which is familiar for RDF users.

Also, R2VML constraints the way of writing mappings such that our tool ShERML User(x, y) ∧ Email(x, z) ∧ Track(x, w) ⇒ ShUser(Us2iri(x)) ∧ Triple(Us2iri(x), ex:name, y) ∧ Triple(Us2iri(x), foaf:mbox, z) ∧ Triple(Us2iri(x), ex:tracks, Bu2iri(w)) The interpretation of the grammar is as follows. The identifier trim is interpreted as the function that removes all spaces from text except for single spaces between words.

The identifier upper as the function that converts a string to uppercase letters and the identifier lower as the function that converts a string to lowercase letters. The identifier R is interpreted as the name of a table in a database. The identifier F is interpreted as a function that generates an IRI using the value of the parameter. The relational expression is interpreted as a SQL query. If the conditional expression is in the rule is interpreted as the filters on the query result. The triple expression is interpreted as the generation of triples where the subject is an IRI resulting from the application of an IRI constructor with the value of the attribute. The property expression is interpreted as the set of property objects associated with the subject. We allow trim, upper and lower functions to be applied to data values of the object. The triple objects come from the values of the attributes specified in the property expression. Some objects can be IRIs resulting from the application of an IRI constructor with the value of the attribute.

The triple expression is expressed as a Turtle syntax that is a natural way to declare RDF graphs except the specification of types. The subject of the triple expression includes in the grammar the symbols "as" T that indicates the type of the subject nodes that will be generated. It is created a monadic fact with the name T and the subject node. This constitutes the typing relation that together with the set of triples is the typed graph.

Now, for human-computer interaction reasons, we restrict the kind of R2VML mappings that can be defined in ShERML. We set a restriction over the set of tables, which we call a path, used in a query of R2VML. In ShERML, the drawing of a green or orange arrow requires a path to be specified. We propose a set of paths, so a user is not concerned to write it. A path in this set has the property that for every two tables of the path, there exists a foreign key such one table references the other. This property guarantees that a st-tgd is uniquely defined. For instance, suppose we have the following two relations User(uid , name) and Track(tid, uid , track -nbr ). Also, we have the following R2VML. This R2VML mapping can correspond to the following st-tgd

User(x, y) ∧ Track(u, x, v) ⇒ Triple(Us2iri(x), ex:name, y) ∧ Triple(Us2iri(x), ex:tracks, v) ∧ ShUser(Us2iri(x)) (5.1)
or can correspond to the two following st-tgds

User(x, y) ⇒ Triple(Us2iri(x), ex:name, y) ∧ ShUser(Us2iri(x)), (5.2)
User(x, y) ∧ Track(u, x, v) ⇒ Triple(Us2iri(x), ex:tracks, v).

(5.3)

These two corresponding sets of st-tgds generate two different graphs from a given instance. A graph generated from st-tgd 5.1 will have nodes of type ShUser only if there is a user that has some track-nbr. While in a graph generated from st-tgds 5.2 and 5.3, the number of nodes of type ShUser will be as many users are stored in User. But, if we assume the existence of a reference from uid of Track to User, then the unique correspondence of the R2VML mapping is the st-tgd 5.1.

To define a VML mapping, green and orange arrows are grouped by the first element of the path, which is the table that is connected by a blue arrow. We describe later on how a VML mapping is created. To define the path to be specified in a R2VML mapping from these arrows, the paths specified on the arrows are combined in a single path such that there is no repetition of tables and the first element of the path is the table that the blue arrow connects.

To visually represent a R2VML mapping in a directly way and to define a unique sttgd from a R2VML mapping, R2VML is well defined if the primary key of the first table of the path π is the argument for the IRI constructor and if there is a path π composed with the tables of path π such that for every two elements of π , there is a foreign key from one to the other.

The visual mapping language

In this section, we define a visual mapping language (VML). It is composed of different types of boxes, arrows that have a label or not, and an orthogonal line that is used to relate boxes. Each element of VML has its correspondence to an element of R2VML and its semantics follows from there.

The alphabet of VML is composed of the following visual objects:

VL = { , F (a)
, , F , RN , AN , KN , SN , PL , PS } where • F is the identifier for an IRI constructor and a is the identifier of the argument for the IRI constructor,

• RN is the identifier for a relational name in R,

• AN is the identifier for an attribute name of a relational name,

• KN is the identifier for an attribute name that is the primary key in a relation name,

• SN is the identifier for a shape name in T,

• PL is the identifier for a property name such that there is a triple constraint in the shapes schema with this property where the target type is Lit,

• PS is the identifier for a property name such that there is a non-literal type S and a triple constraint with this property name and target type S.

For instance in Figure 5.2, we observe the blue arrow with label Us2iri(uid ) that goes from relation name User to shape name ShUser. Here the relational name User corresponds to RN, the shape name ShUser to SN and the label Us2iri(uid ) to F (a).

Then, we observe the green arrow with label Email User that goes from attribute mail of Email to the triple constraint with property tracks :: ShBug of shape ShUser. Here the relational names User and Email corresponds to RN, the attribute mail corresponds to AN, the shape ShUser corresponds to SN, email corresponds to PL, the path of Email User, the dependence of the attribute to a table and the dependence of a triple constraint to its shape corresponds to the orthogonal line.

Now, given a library of IRI constructors F = (F, F ), the relational schema R = (R, attrs, Σ fd , Σ ind ), the shapes schema S = (T, δ), we define VML mappings with the following grammar:

VR ::= RN VB F (a) SN VB ::= RN VB | AN PL | KN F PS A visual
expression VR allows to relate a query with a shape and its triple constraints and defines a VML mapping. A VML mapping is composed of a set of visual objects that represents the relational expression and triple expression of an R2VML mapping.

The mapping starts with a blue arrow between a source box with RN and a target box with SN. This arrow has as a label an IRI constructor and specifies that the primary key of the source box is converted to an IRI and is typed with the shape name SN.

The attribute name either AN or KN comes from the result query. The target box of a green arrow is specified only to property PL of the related shape that comes from a triple constraint whose target type is Lit. This arrow species that the value of AN is directly used as the object of the triple that will be generated. A target box of an orange arrow is specified only to property PS of the related shape that comes from a triple constraint whose target type is a shape. This arrow specifies that the value of attribute KN is converted to an IRI by the application of F where its interpretation is given in the library F.

We illustrate in Figure 5.5, a R2VML mapping and its correspondent VML map-ping. This VML mapping indicates how the graph will be populated with properties of ShUser where the object values of triples come from the attribute values. In the case of the orange arrow, there is a conversion of a value of the attribute bid with the IRI constructor Bu2iri that is in the label of the orange arrow. Here the subjects of triples are obtained from the application of Us2iri to the values of uid . This VML mapping is constructed from the R2RML mapping in Figure 5.5 as follows. The query User join Track is mapped to the two boxes related to the orthogonal line. The subject Us2iri(uid ) as ShUser is mapped to the blue arrow with Us2iri(uid ) as a label where the target box has the shape name ShUser. The property expression ex:name ShUser.name is mapped to the green arrow where the source box has the attribute name that comes from the query and the target box has the property label ex:name that comes from a triple constraint in the definition of ShUser where the target type is Lit. The property expression ex:tracks Bu2iri(Track.bid ) is mapped to the orange arrow with Bu2iri as a label where the source box has the attribute name bid that also comes from the query and target box has the property label ex:tracks that comes from a triple constraint in the definition of ShUser but the target type is the shape ShBug. Now, we describe in Table 5.1 the correspondence between the visual objects of a VML mapping and elements of R2VML mapping.

Based on the correspondence given in Table 5.1, we can define the semantics of Visual object Correspondence to RN R used in the relational expression and the triple expression.

SN

T used in the triple expression after the string "as".

RN R in the relational expression but after the string "join".

AN

Aname when the object in the property of the triple expression is of the form either R.Aname or Fun(R.Aname).

KN

Aname but when the object in the property expression is of the form F (R.Aname).

PL p in the property expression when the object is of the form either R.Aname or Fun(R.Aname).

PS

p when the object in the property expression is of the form F (R.Aname). F (a)

"=>" and F (R.A.name) in the triple expression that appears before the string "as". "=>" and the writing of the property expression p R.Aname or p Fun(R.Aname). F "=>" and the writing of the property expression p F (R.Aname).

Table 5.1: Correspondence of grammar of VML with grammar of R2VML.

VML mappings as follows:

RN F (a) SN It defines how rows from table RN are to be mapped to IRI nodes using the IRI constructor F with the value of the primary key a satisfying the shape constraint SN. We call this mapping an IRI mapping.

AN PL It defines how table rows are mapped to triples where the predicate of every triple is the value of PL and the objects are values of AN. This VML mapping depends on the existence of an IRI mapping. We call this mapping a property mapping.

KN

F PS It defines how table rows are mapped to triples where the predicate of every triple is the value of PS and the objects are IRI nodes that are obtained from the application of F with the values of the attribute KN. As the property mapping, it depends on the existence of an IRI mapping. We call this mapping a reference mapping.

The other elements of the relational expression in an R2VML mapping are used as annotations over the visual objects such as the conditional expression and string functions. Figure 5.6 shows an example of a VML mapping with annotations. The conditional expression has no proper visual representation as the other elements, but the conditional expression has its correspondence as a text annotation over an IRI mapping.

In the case of string functions, they are annotated over a property mapping.

User

ShERML

In this section, we describe a tool for data exchange from relational to RDF called ShERML. Our tool enables users to create mappings between a source relational schema and a target shapes schema. Also, ShERML verifies consistency of mappings. We have developed our tool with the direct manipulation paradigm. This component generates a VML script that is the input for the materializer component that executes it by running SQL queries on the relational database and constructing the desired RDF graph. Then, the converter component generates a R2RML script that can be used by third-party applications. We detail these components in the sequel.

Architecture

VML Editor

The VML editor is the main component and is used to define mappings. The definition of mappings is done by drawing arrows with the drag and drop technique. This component receives as inputs the source and target schemas and produces a VML script. The VML editor seen in Figure 5.9 consists of two panels: the modeling and the mapping panel. The modeling panel displays graph representations for source and target schema.

The mapping panel displays the VML mappings, which are created by drawing of arrows, with modify and delete buttons. The input for starting the mapping process consists of loading the database and the schema for RDF which can be a ShEx or SHACL script. When the shapes schema is loaded, ShERML creates for each shape name its corresponding function symbol. This function symbol is unique and its interpretation is by default the concatenation of an URL assigned to the shape that is also unique and the value of the argument. Thus, every IRI constructor in ShERML is used with a unique shape name. Now, we describe the implemented interactions in the editor. In the modeling panel, the user can reorder nodes and edges of the graph representations and can draw arrows from nodes of source schema to nodes of the target schema. Each arrow drawn in the VML editor creates a VML mapping displayed in the mapping panel. Each VML mapping can be modified with the modify button that allows users to add string functions on property mappings, to modify IRI constructors on an IRI and a reference mapping.

Also in the modify button over an IRI mapping, a user can add filter conditions on the attributes of the relation name. These conditions of attributes are displayed as annotations to the arrows. In the following, we describe the graph representations for source and target schema, and describe a VML script.

Graph representation for relational and shapes schema. The graph representation for the relational schema is described in Figure 5.10.

Visual object Representation

RN KN AN

The whole visual object is composed of three different visual objects and represents a relation name with its attributes. The visual object for a relation name identified with RN is a box with a square anchor. The visual object for an attribute name identified with AN is composed of a box and a circular anchor of color green, which represents any attribute that is not a primary key or foreign key. The visual object identified with KN is composed of a box with the name of the attribute and a circular anchor of color orange. If this visual object has the text underline, then it represents a primary key. Otherwise, it represents a foreign key.

It represents an inclusion dependency. The black arrows are between relational tables. The graph representation for the shapes schema is described in Figure 5.11. The

Visual object Representation

SN PS PL

The whole visual object is composed of three different visual objects and represents a shape name and the set of triple constraints that the shape defines. The visual object for a shape name identified with SN is a box with a square anchor. The visual object for a triple constraint, where target type is a shape name, identified with PS is composed of a box and a circular anchor of color orange. The visual object for a triple constraint, where the target type is literal, identified with PL is composed of a box and a circular anchor of color green.

It represents the relation between two shape names, i.e a shape name T is related with S if there is a triple constraint with S that is the definition of T . The black arrows are between shape names. Furthermore, in the mapping panel, the draw of a VML mapping is designed to avoid the crossing of arrows. From a blue arrow in the editor, it is analyzed all the paths contained in the set of green and orange arrows that depend on the blue arrow.

First, the arrows that connect the attributes of the relation name. Then, the arrows are organized according to the length of the set of paths and if the paths have the same length then the paths are organized in lexicographical order. Finally, arrows that connect the attributes of the same table in the path, first are created the property mappings and then the reference mappings.

VML script. The output of the editor is a VML script that contains the set of VML mappings, R2VML mappings, the graph representations of schemas and the set of positions.

Materializer

We recall that the problem of relational to RDF data exchange is to find a solution i.e., a graph that satisfies the shapes schema and the set of mappings. In this sense, the materializer generates an RDF graph that is a solution to an instance given as input in ShERML w.r.t. the set of mappings defined in the editor. This component receives as input a VML script and uses the R2VML mappings that are contained in it and outputs an RDF graph. In order to extract the data from the tables, we translate the R2VML mappings to SQL views that will represent the RDF data. The translation is done as follows. The materializer converts each R2VML mapping to a st-tgd. Every st-tgd is normalized and translated to a SQL query following the method used by Benedikt et al. [Benedikt et al. 2017]. This SQL view selects the head of a st-tgd from the data contained in relations that appear on the left side of the st-tgd. There will be two types of views: the triple view and the type view. The following SQL query illustrates the corresponding equivalence of a st-tgd.

Bug(x, y, z) ∧ Rel(x, z)

⇒ ShBug(Bu2iri(x))

Bug(x, y, z) ∧ Rel(x, z)

⇒ Triple(Bu2iri(x), ex:rep, y) The execution of views previously defined will generate an RDF graph, but there can be constraints that are not yet satisfied. So, the materializer creates the relation Shape (source, prop,target,mult) in the database that stores the shape names and its triple constraints with multiplicity 1 or +, i.e., we store the obligatory shape graph (cf. Section 3.3.5). Then, the materializer constructs two views called Triples that selects all triple views and Types that select all type views. These views are used to create another view called TripleSim that generates triples with fresh nodes to satisfy the triple constraints that are not yet satisfied. This process of generating triples with fresh nodes can be infinite. We use the symbol "@@@" as the value for generating the fresh nodes so the process of generating triples arrives at fixed point. Finally, the converter constructs the view Solution that selects all triples and the view TypeSol that selects all the content of the view Types and the views that typed the unknown values. The view Solution is materialized as a table with attributes sub, pred and obj. The data that will contain this table is translated into an RDF graph by using the methods provided by Apache Jena 1 . The content of the view TypeSol with the RDF graph obtained is a solution to an instance of the relational schema w.r.t. a data exchange setting. ShERML offers three formats to export the solution: Turtle, N-Triples and RDF/JSON. Now, we discuss why we use the symbol "@@@" to represent the null values. To obtain a solution to a given instance w.r.t. the setting, we use the chase procedure with the st-tgds and the set of dependencies that captures the shapes schema. Since the chase can be infinite if there are cycles in the obligatory shape graph, then inventing new values each time a PE rule is triggered is not a good solution because the chase will never terminate and we want a finite solution. Thus, we invent a fixed IRI value for each type so a PE rule with the same type will be triggered only once and a fixed literal value. Because this fixed literal value must represent a null literal value we decide to use "@@@" symbol that has no meaning for a user. However, this is also a problem because the solution will have meaningless information. Here no good solution for the problem of representing null literal value exists. We use also the "@@@" symbol in the creation of a fixed IRI value for each type. Since, the chase is implemented in SQL, we cannot use blank nodes. Because of the approach adopted here, we do not generate a universal solution. For instance, the solution in Figure 5.3 for the setting and instance

shown in Example 5.1.1 is not universal.

Converter

The converter generates an R2RML script that can be used into other applications. This component receives as input a VML script and outputs R2RML mappings. The converter uses the set of R2VML mappings contained in the script. The process of converting from R2VML to R2RML is as follows. Each rule in R2VML is converted to a triple map in R2RML. The relational expression in R2VML is inside rr:logicalTable.

The triple expression is translated to rr:subjectMap and rr:predicateObjectMap. The IRI constructor is mapped to the IRI value of concatenation specified in the program.

The expression "as" T is translated as an additional rule where the predicate map is rr:class and the object is T . The application of the predicate map rr:class will generate a triple with the predicate label rdf:type. For instance, Figure 5.12 shows the translation of R2VML mapping to R2RML mapping.

R2VML R2RML

User

Consistency checking

A novelty of our tool that distinguishes from other mapping tools is the consistency verification. This functionality allows users to know if the set of VML mappings that have specified in the tool are consistent i.e., for any instance of the relational schema there is a solution. To deciding consistency we use two algorithms presented in Section 3.2.1 and 3.3.5. The set of st-tgds that captures R2VML mappings specified in ShERML belongs to a simpler class where every st-tgd has a triple and a monadic atom that types the subject term. Given a database, the application of this set of st-tgds will avoid:

• to have conflicting types in any extended graph of the core pre-solution to the source instance; and

• to compute the whole set of violation sorts and reduce the steps for constructing the set of contentious-based instances in the algorithm of Section 3.2.1.

Therefore, deciding consistency in ShERML is a simpler version of Algorithm 1.

ShERML translates the set of VML mappings to R2VML mappings and from R2VML mappings to set of st-tgds as follows. For each R2VML mapping, we take the properties associated to the subject T and IRI constructor f in the R2VML mapping and for each property p we create a rule of the form ϕ(x) ⇒ T (f (y)) ∧ Triple(f (y), p, t) for y ⊆ x where ϕ contains relational atoms with the names of relation names contained the relational expression of the R2VML mapping. In the creation of st-tgds, each two rules use mutually disjoint set of variables. In the end, we have a set of st-tgds Σ st where we analyze if the setting is consistent using the Algorithm 4. This algorithm has as inputs pings in a VML script, but these mappings are not readable because the script combines R2VML mappings with VML mappings and position annotations. The feature of color configuration allows users to assign colors to the three different kinds of arrows.

Evaluation

In this section, we have assessed our tool in its usability with six users: three of them are undergraduate students of computer science, one user is a doctoral student, one user is a software engineer that works with system databases and the last user is a researcher on the semantic web. We identify these users with the following letters (a) to (c) for the undergraduate students, (d) for the doctoral student, (e) for software engineer and (f) for the researcher.

Methodology

The methodology for testing ShERML consists of three phases: preparation, evaluation and observation. In the preparation phase, we provide every user a manual of how it is used ShERML describing its main functionalities. Also, the manual contains a brief description of what is shapes schema. Then, we provide a testing document containing four cases where we describe every case as follows. A case is presented with a description of the relational database, a screenshot of graph representations of the relational and shapes schema, the set of mappings to perform expressed in natural language and the desired graph that should be obtained when materializing the mappings. Next, we provide two scripts: a SQL script containing the relational schema and the instance, and JSON script containing a shapes schema. Finally, we guide the user in the installation of the application. The tool, all testing scripts, manual and testing document can be found in this repository htpps://github.com/josemachino/ShERML.

In the evaluation phase, the user can ask questions while doing the mappings if they do not understand certain functionalities of the tool. If users do not succeed to do the mappings they can leave the case and pass to another one. Before passing to other cases, the user sends us the VML mappings. We do not restrict the time for each case.

Finally, in the observation phase, users provide us their impressions of ShERML and we observe if their VML mappings are correct and analyze the reason for the incorrect mappings. For this purpose, we distinguish two types of mappings. A mapping is simple if the path is composed of less equal than two relational names, otherwise the mapping is complex. Case one and two are composed of simple mappings, while cases three and four are composed of complex mappings.

Results

The results of the correct mappings done by a user in the four different cases are shown in Table 5.2. In cases one and two, we observe that users (a), (b) and (e) did not succeed to do the correct mappings because they created property arrows instead of reference arrows. User (c) did the reference arrows but the IRI constructors were incorrect. Users (d) and (f) did correctly mappings.

In cases three and four, we observe that users (a) and (c) did not succeed the complex mappings because the notion of paths is not well understood. One reason can be that the manual only presented a case of simple mappings and did not emphasize the notion of paths. The manual did not describe the notion paths because we were interested in evaluating the interactions of the editor. The result was not as expected because not all undergraduate students, who have less experience in databases, succeeded to make complex mappings. For the rest of users, the notion of paths was understood because they have more experience in databases. • All users: Many arrows crossing each other in the editor for case two. ShERML cannot arrange the arrows in the editor such that they are not crossed. But in the mapping panel, ShERML presents the corresponding VML mappings without crossing lines. However, a solution for the crossing of arrows in the editor is not possible. This is a drawback of ShERML.

Type of Mapping

• User (f): Most issues of users with Ontop2 , which is an application that relies on R2RML mappings, comes from bad mapping design. ShERML addresses this problem through the creation of VML mappings and the conversion to R2RML script.

Finally, we draw the following conclusion from the evaluation:

• ShERML does not have the right interactions for showing the user the importance of the IRI constructor. One way to approach the lack of understanding of the IRI constructor is to have a visual object for the IRI constructor and interaction operation over it. As it is now, the IRI constructor is over the IRI arrow or reference arrow as text. According to users, the text over arrows is lost in the editor. One way to solve this problem is the use of a visual object that captures the attendance of a user to check if the IRI constructor corresponds to the shape name or triple constraint that the arrow connects.

• ShERML has to enhance the readability of the graph representation of schemas by a better distribution of nodes and avoiding the crossing of edges in the panel.

• ShERML helps the creation of complex mappings with the path selector, but it should be more intuitive for non-expert users such (a) and (b).

• ShERML facilitates the mapping design.

• ShERML is compatible with third-party applications such as Ontop.

Discussion and conclusion

We have achieved in this chapter the definition of a visual mapping language. We have developed ShERML that hides for non-expert users the complexity of learning a data exchange framework and creates VML mappings. ShERML is a tool that offers its users an easy mapping process and a distinct characteristic of this tool is the consistency verification. The feature of ShERML of import and export of VML script allows users to reuse the data exchange setting with other instances.

However, ShERML has some limitations inherent to the framework that we have chosen. For instance, we limit the kind of queries that can be expressed with R2VML as discussed in Section 5.3. Also, the aim to produce a solution to a given instance of a relational schema w.r.t. the shapes schema carries the limitation of representing null values that are meaningless for users as discussed in Section 5.5.3.

As future work, we propose the enhancement of some functionalities and considering additional features for a better data exchange experience. We will improve the user feedback in the consistency checking such that a user can know the arrow that is causing the inconsistency of the setting. In terms of additional features, we will add the functionality of searching VML mappings in the visualization panel and a graph visualization of the RDF graph.

Related work

Different tools [Fagin et al. 2009,Raffio et al. 2008,Pichler & Savenkov 2009,Marnette et al. 2011, Sengupta et al. 2013, Sicilia et al. 2017] have been developed to assist users in the definition of mappings in relational, XML and relational to RDF data exchange.

We describe first those tools used for relational and XML data exchange. Then, we describe the tools used in relational to RDF data exchange.

Clio system [Fagin et al. 2009] presents a graphical interface to assist a user in the definition of mappings in the relational data exchange context. It uses a tree representation to show the source and target schemas with constraints. This tree representation does not capture the inclusion dependencies information. The definition of mappings is by drawing arrows between attributes. ShERML uses graph representation for relational schema where the inclusion dependencies information is also captured. Our tool is used in a relational to RDF data exchange context with shape constraints. This implies the use of IRI constructors and verification of constraints when doing the arrow. Thus, in ShERML is distinguished two arrows more. Also in Clio, SQL is used to present the mapping that is less declarative than R2VML.

Clip [START_REF] Raffio | [END_REF]] is a tool used in XML data exchange context. It uses tree representations to show the source and target XML schemas. The definition of mappings is done by drawing of arrows and expressed using XQuery. ShERML is used in another context, but the use of arrows to define mappings is the same approach implemented in our tool.

Pitchler and Savenkov [Pichler & Savenkov 2009] present a data exchange modeling tool called DEMo. In this tool, there is no target schema loaded in the input. They define the target schema while doing the mappings that are SQL queries. This tool does not use visual representations for schemas. The set of mappings defined in this tool is stored in a script so users can continue with the mapping definition later on. We take this idea of storing the set of mappings in a file.

++Spicy [Marnette et al. 2011] is a tool for relational and XML data exchange context. The tool uses tree representations for the source and target schema and the mappings are defined with arrows. The tool allows to define filters on the attributes. We take this idea to be used in ShERML by allowing filters on attributes. The tool considers target as ShERML does. Now, we describe tools used for relational to RDF data exchange. One of them uses D2RQ and the rest use R2RML as the language to define mappings. None of these tools uses target constraints. RDOTE [Vavliakis et al. 2013] is a tool that develops a text-based language called D2RQ to define mappings from a relational schema to an ontology. An ontology defines a set of classes that are organized in a hierarchical taxonomy, a set of properties of those classes and relationships between those classes.

The input of this tool is a database and an ontology. RDOTE defines D2RQ mappings manually in a editor form.

Sengupta et al. [Sengupta et al. 2013] present a R2RML mapping editor. This editor allows the materialization of an RDF graph. Defining a R2RML mapping is done in an editor form. Also, this editor provides a search utility where given a set of VML mappings defined by the editor, users can search a mapping by the path specify in the SQL query and the term map used in the subject, predicate and object. This utility can be added in ShERML to easily find a VML mapping from the list of VML mappings created by the editor. As it is now, users have to scroll down in the visualizing panel to find a VML mapping. Their tool does not use visual representations.

Heyvaert et al. [START_REF] Heyvaert | [END_REF] Map-On [Sicilia et al. 2017] is a tool that defines a visual mapping language for relational to RDF data exchange with an ontology as a target schema. Map-On uses arrows between elements of the relational schema to elements of the ontology. The visual representation for each element is a box and they use different colors to distinguish table, attribute, and type names of the ontology. The set of arrows in the panel creates R2RML mappings.

Juma [START_REF] Amsterdamer | [END_REF]] is a tool that creates R2RML mappings using the block metaphor. Each R2RML rule is a block and each block is composed of sub-blocks that construct the rule such a sub-block for the query where the tool gets the data, sub-block for the subject and other for predicate object. This tool only allows the connection of blocks that would create a valid mapping. Juma defines a visual mapping language on top of R2RML using blocks as the visual representation for every element of R2RML.

This tool requires that users must known R2RML syntax while in ShERML we hide the step of learning R2VML. A similar feature to our tool is that we also create valid mappings.

SQuaRE [Bak et al. 2017] is a tool that allows to create R2RML mappings. The target schema is an ontology. The user loads a database and an ontology. Because an ontology is a hierarchy of concepts, the tool uses a tree representation for the ontology.

There is no visual representation of the relational schema. Instead, the user has to choose a table from the relational and a visual representation only of the table is shown.

SQuaRE has a mapping panel where the user drags types of the ontology and draw arrows from the attributes to the types in the mapping panel. A feature of this tool is that they allow conditions on the mappings. From these arrows, a R2RML mapping is generated. This tool has defined a visual mapping language over the relational signature and set of types of the ontology. In ShERML, we also allow to set conditions on the blue arrows and use the arrows to generate mappings.

YARRRML [Heyvaert et al. 2018] Finally, Table 5.3 summarizes the main features of the different mapping tools in the relational to RDF data exchange context and of ShERML presented in this chapter.

The acronym VR is for visual representation and VML for visual mapping language.

The tools are compared with the visual mapping language defined, the text-based mapping language used, whether they use visual representations in their tool, whether they provide a panel to see all the mappings created by the tool, whether they are concerned with target constraints and if they materialized having a solution. Since most these tools work with an ontology as target schema, they always a produce solution because of the absence of constraints.

Chapter 6

Shapes schema elicitation

Motivation

The presence of R2RML standard indicates that there is a considerable amount of web applications that exchange information using the RDF format. In this context, the exchanged information comes from relational databases. R2RML mappings might specify the type of the nodes that they produce, but in this chapter, we focus on mappings where no node is typed. Also, we focus on R2RML mappings as modeled by constructive sttgds. We consider the problem of schema elicitation which means constructing a shapes schema that describes the structure of the output graph.

Schema elicitation is not an easy task. We identify the main primary challenge: the differences between the source and target languages i.e., on one side we have the language for expressing constraints of the source relational databases and on the other side we have the language for expressing target shapes schemas. Also, the set of mappings can have additional information that must be considered in the elicitation of the target schema. As consequence of the difference of languages, there might not exist a target schema that capture all the graphs produced by the mapping.

To address this challenge, we characterize what a good target schema is. We identify soundness and completeness as properties of a desirable target schema. A sound schema recognizes every possible output of the mapping. A complete schema recognizes only graphs that can be a possible output of the mapping. Finally, we present an elicitation algorithm that is sound but also that is complete for a large practical set of The following constructive st-tgds are given:

Emp(x 1 , x 2 ) ⇒Triple(f emp2iri (x 1 ), ex:name, x 2 ), (6.1)

Email(x 1 , x 3 ) ⇒Triple(f emp2iri (x 1 ), foaf:mbox, x 3 ), (6.2)

Sys(x 1 , x 2 ) ⇒Triple(f sys2iri (x 1 ), ex:name, x 2 ), (6.3)
Access(x 1 , x 2 ) ⇒Triple(f emp2iri (x 1 ), ex:access, f sys2iri (x 2 )), (6.4)

Access(x 1 , x 2 ) ∧ Sup(x 3 , x 1 ) ⇒Triple(f sys2iri (x 2 ), ex:admin, f emp2iri (x 3 )). (6.5)

ShEmp ShSys

Lit We examine the set of st-tgds and observe the IRI constructors. We propose for every IRI constructor a dedicated shape name: ShEmp for f emp2iri that represents employees and ShSys for f sys2iri that represents systems. We can propose two schemas as seen in Figure 6.2, where one of them is sound and the other is sound and complete. The schema in Figure 6.2a is obtained by simply identifying the outgoing edges of ShEmp and ShSys and the multiplicity for every edge be *. For instance, there is an outgoing edge with label ex:name from ShEmp to Lit because in the mapping 6.1 no IRI constructor is used in the object position. Also, we observe the outgoing edge ex:admin that connects ShSys with ShEmp. This corresponds to the mapping 6.5 because the IRI constructor f sys2iri appears in the subject position and the IRI constructor f emp2iri in the object position. This target schema is sound but it is overly general and not complete because this schema allows to have a shape employee with two emails or no name, and yet this kind of information is not allowed by the relational schema.

By carefully analyzing the mappings and the set of dependencies of the relational schema we can refine the previous schema to obtain a sound and complete schema as shown in Figure 6.2b. This refinement is done by precisely determining the multiplicity constraints, which are obtained from the analysis of the set of source dependencies and the mapping. Thus, we will make a better fit for the shapes schema. For the outgoing edge ex:name from ShEmp and ShSys, the multiplicity constraint is 1 because there is a key dependency that restricts to have exactly one name for an employee and system. For the outgoing edge foaf:mbox from ShEmp, we observe the relation Email has an inclusion dependency that references to an employee and the attribute emp id is a primary key for Email. This means that an employee will have at most one email and sometimes might have none. Thus, the multiplicity is ? for this outgoing edge. For the outgoing edge ex:access from ShEmp, we observe that the primary key of Access is composed of the attributes emp id and sys id with inclusion dependencies to ShEmp and Sys, which means that an employee might have access to multiple systems and might have access to none. Thus, the multiplicity is *. Now the rule that indicates that an employee is an admin of a system is (6.5). Here, we observe the inclusion dependencies related to Access and Sup. With respect to Access the inclusion dependencies shown in Figure 6.1 indicates that a system must be accessed by at least one employee. With respect to Sup, the inclusion dependencies shown in Figure 6.1 indicates that an employee must have a supervisor. From these two observations, we conclude that for the outgoing edge ex:admin, the multiplicity is +.

Also, we show that there are cases where there might not exist a target schema that is complete or if a complete a schema exists then this schema is of exponential size. In the next example, we in fact show that a complete target schema might not exist. Example 6.1.2. Now, we consider the additional st-tgd that connects employees with their supervisors.

ShEmp ShSys

Lit

Sup(x 1 , x 2 ) ⇒ Triple(f emp2iri (x 1 ), ex:sup, f emp2iri (x 2 )).
Following the same procedure of elicitation, we construct the schema shown in Figure 6.3. This schema is sound, however, it is not complete. We observe the graphs obtained from the application of this new set of st-tgds have a triangle pattern shown in Figure 6.4. Consequently, a complete target schema does not exist because the language of shapes schema cannot express such a triangle pattern. Here, we observe that the differences between the source and target languages for expressing constraints together with the information coming from the mappings renders elicitation of a complete shapes schema unfeasible.

f emp2iri (x 1 ) f emp2iri (x 2 ) f sys2iri (

Problem statement

In this section, we define formally the elicitation problem that takes a relational to RDF data exchange setting without schema and outputs a target suitable shapes schema and we propose two desirable properties of target schema.

Schema-less data exchange setting

We define a schema-less data exchange setting that we use as input for the elicitation problem.

Definition 6.2.1. A schema-less relational to RDF data exchange setting is a tuple

E d = (R, Σ st , F)
such that for every relation R of R, R has a key dependency and the tuple (R, S ∅ , Σ st , F) ShAdmin → ex:name :: Lit 1 ; ex:sup :: ShAdmin ? .

ShSys → ex:id :: Lit 1 .

Also, we consider the multiplicity 0 with its corresponding interval [0, 0] in the multiplicities of a non-deterministic shapes schema. Now, we define how a graph satisfies a non-deterministic shapes schema under close interpretation. We recall the definition of embedding [Staworko & Wieczorek 2019].

Recall that we view a shape graph as (p, µ)-labeled graph. First, we identify the set of all outgoing edges of a node n ∈ nodes(G) with

out G (n) = {(n, p, m) ∈ G}.
Also, we define a function occur over a graph G that assigns an interval to an edge in G. If the graph is an RDF graph the interval assigned is 1, otherwise, the interval is the multiplicity contained in the label of the edge. Next, we define the point-wise addition operator ⊕ between two intervals as follows:

[n 1 ; m 1 ] ⊕ [n 2 ; m 2 ] = [n 1 + n 2 ; m 1 + m 2 ].
Now, we define an embedding as follows:

Definition 6.2.2 (Embedding). Given a RDF graph G and a shape graph H, a binary relation R ⊆ nodes(G) × nodes(H) is a simulation of G and H iff for any (n, n ) ∈ R we have that

• n is a literal node iff n is a literal type,

• n is a non-literal node iff n is a non-literal type, and

• there exists a witness of simulation of n by n w.r.t. R i.e. a function λ n,n :

out G (n) → out H (n ) such that for every (n, p, m) ∈ out G (n) -there is m ∈ nodes(H) and µ ∈ {0, 1, ?, +, *} such that (n , (p, µ), m ) ∈ out H (n ), λ n,n ((n, p, m)) = (n , (p, µ), m ) and (m, m ) ∈ R, -for every (n , (q, µ), m ) ∈ H it holds that {occur G ((n, q, o)) | (n, q, o) ∈ G, λ((n, q, o)) = (n , (q, µ), m )} ⊆ occur H ((n , (q, µ), m )). An embedding of G in H is a simulation R of G in H such that adom(R) = nodes(G),
and we write G H if G can be embedded in H.

A graph G satisfies a shapes schema S, if there is an embedding from G into the shape graph of S, i.e., G G S . We illustrate graphically an embedding in the following example.

Example 6.2.3. Consider the shapes schema S presented previously and the graph G presented in the left hand side of Figure 6.5, with the interval 1 added to each edge for the purpose of illustrating the embedding. In the right hand side, we have the shape graph of the S. This graph satisfies the non-deterministic shapes schema because there is embedding as shown in Figure 6.5. Finally, we define the language of a non-deterministic shapes schema under close interpretation as the set of graphs that can be embedded in the shape graph of the shapes schema i.e., L C (S) = {G | G S is the shape graph of S, G G S }.

Elicitation Problem

The schema elicitation problem aims at constructing a target schema for a given relational to RDF schema-less data exchange setting. We identify two desirable properties of the target schema. The first property is soundness that requires the target schema to recognize every output of the mapping. This property is not enough because trivial solutions do not inspect schemas and obtain universal schemas, which are also sound.

The second property is completeness, which intuitively means that the target schema recognizes only graphs that can be produced by the mapping. Formalizing completeness is challenging because graphs produced by mappings use node identifiers that are generated by IRI constructors and those may have limited range. We circumvent this problem by employing the standard notion of isomorphism.

Example 6.2.4 (cont. Example 6.1.1.). In this example, we assume that for an employee the IRI constructor is f emp2iri (id ) = "univ:emp#" + str(id ) and for a system, the IRI constructor is f sys2iri (id ) = "univ:sys#" + str(id ).

Take a graph G 0 recognized by the language of S shown in Figure 6.2b. The identifier that we use in the graph G 0 cannot be obtained by the IRI constructors described above.

From G 0 , we construct an instance of the relational schema as presented in Figure 6.6. If we apply the mappings with Σ st , then we get an isomorphic graph as shown on the right side in Figure 6.6. Here, we observe that both graphs are recognized by the language of the schema shown in Figure 6 In the sequel, we fix a schema-less data exchange setting E d = (R, Σ st , F).

M3 Elicitation algorithm

In this section, we propose an elicitation algorithm called min-max models (M3), which constructs the minimum and maximum models that describe the minimum and maximum multiplicities in the output schema. For every IRI constructor f , the algorithm constructs a type T f of nodes constructed by f obtaining that the set of types T for the target schema is defined as follows:

T = {T f | f ∈ F}.
We illustrate the M3 algorithm with the following example. First, for each mapping, we construct the minimal model as follows. We take mapping (6.6) and construct from it a canonical instance I 1 = {R(x, y)}. We observe it is consistent with R. Then, we apply the mappings and obtain the graph

G 1 min = {Triple(f (x), r, y)}. (6.8)
From G 1 min , we construct a shape expression for T f , which is a set of triple constraints. So we observe that G 1 min has a triple with f (x) and r and, therefore, there must be a triple constraint with label r and multiplicity 1. Because in the set of mappings there is a triple atom with p and this graph has no outgoing edges with p from f (x), there must be a triple constraint with p and multiplicity 0. We obtain the following shape expression that fits this particular graph: r :: Lit 1 ; p :: Lit 0

We do an analysis later on over the corresponding shape expression. Now, we process the mapping (6.7) and construct the canonical instance I 2 = {P (x, y)}. We notice that I 2 is not consistent with R because of the inclusion dependency P

[x] ⊆ R[x].
Therefore, we chase it with Σ R obtaining I 2 = {P (x, y), R(x, ⊥)}. Next, we apply the mappings obtaining the graph G 2 min = {Triple(f (x), r, ⊥), Triple(f (x), p, y)} (6.9)

Upon inspection, G 2 min yields shape expression for T f r :: Lit 1 ; p :: Lit 1 Now, we proceed to construct the maximal model as follows. We take the graph produced by all mappings with f in the subject

G f max = {Triple(f (x), r, ⊥ 1 ), Triple(f (x), p, ⊥ 2 )}.
Next, we saturate it by duplicating each outgoing edge label with fresh null values for the target nodes. The result is the following graph

G f max = {Triple(f (x), r, ⊥ 1 ), Triple(f (x), r, ⊥ 3 ), Triple(f (x), p, ⊥ 2 ), Triple(f (x), p, ⊥ 4 )}.
Then, we apply backwards the mappings Σ st to G f max obtaining the following instance

I max = {R(x, ⊥ 1 ), R(x, ⊥ 3 ), P (x, ⊥ 2 ), P (x, ⊥ 4 )}.
Here, we observe that I max satisfies the inclusion dependencies, but the functional dependency R : x → y is not satisfied. Thus, we perform the chase, which equates the null values ⊥ 1 and ⊥ 3 , yielding I max = {R(x, ⊥ 1 ), P (x, ⊥ 2 ), P (x, ⊥ 4 )}. Then, we apply the mappings to I 0 yielding a graph G f max = {Triple(f (x), r, ⊥ 1 ), Triple(f (x), p, ⊥ 2 ), Triple(f (x), p, ⊥ 4 )}. (6.10)

We observe the multiplicities related to f (x) in G f max , we restrict the maximum multiplicity to be 1 for label r and infinite for label p obtaining the following shape expression for T f r :: Lit 1 ; p :: Lit + Finally, we obtain the shape definition for T f by fitting the shape expressions obtained from the minimal models (6.8), (6.9) and the maximal model (6.10). The result of this fitting is T f → r :: Lit 1 ; p :: Lit *

Preliminary notions

We recall the notion of canonical instance and introduce the terminology of minimal and maximal models. We also modify the chase procedure for purpose of construction of the minimal and maximal models.

Canonical instance

By canonical source instance of a constructive st-tgd of the form ϕ(x, y) ⇒ ψ(y), we mean an instance whose facts are the relational atoms of ϕ with the set of variables used in the subject term treated as constants and the rest of variables are assigned to fresh null values. For instance, for the st-tgd

ϕ(x, y, z) = User(x, y) ∧ Email(x, z) ⇒ Triple(f (x), p, y) the corresponding canonical instance is I ϕ = {User(x, ⊥ 1 ), Email(x, ⊥ 2 )}.

Localized chase for source dependencies

The problem of using the standard chase procedure for our purposes are potential infinite chase sequences due to inclusion dependencies. In the context of schema elicitation, we are interested in the triples produced for a specific subject and, moreover, we have a bound on how many similar triples are required to define the maximum multiplicity of a triple constraint. Consequently, we can stop pursuing a branch of chase with inclusion dependencies when we determine it will not add further information relevant to the task at hand. We, therefore, propose a localized chase procedure, which we first illustrate in the following example.

Example 6.3.2. Consider the relational schema with three relations R(x, y), P (x, y, z), Q(x, y) and the set of inclusion dependencies and the corresponding tgds.

R[x y]

⊆ P [y z] P [x y] ⊆ Q[x y] P [z] ⊆ R[y] P [y] ⊆ R[y] Q[y] ⊆ P [y]
R(x, y) ⇒ ∃z . P (z , x, y) (6.11) P (x, y, z) ⇒ Q(x, y) (6.12) P (x, y, z) ⇒ ∃y . R(y , z) (6.13) P (x, y, z) ⇒ ∃y . R(y , y) (6.14) Q(x, y) ⇒ ∃y , y . P (y , y, y ) (6.15)

The set of mappings Σ st is R(x, y) ⇒ Triple(f (x), r, y), (6.16) Q(x, y, z) ⇒ Triple(f (x), q, y), (6.17) P (y, x, z) ⇒ Triple(f (x), p, x). (6.18)

We intentionally rename the variables so that the same variable is used in the IRI constructor and this variable allows to distinguish target positions in the bodies of the mappings that may yield a node constructed with the IRI constructor f . For mapping (6.16), we take the source canonical instance I = {R(x, ⊥ 0 )}. The standard chase procedure on I with Σ ind is infinite because there is a cycle of triggering inclusion dependencies (6.11), (6.14), (6.11), obtaining an instance at step three I * = {R(x, ⊥ 0 ), P (⊥ 1 , x, ⊥ 0 ), R(⊥ 2 , x), P (⊥ 3 , ⊥ 2 , x), . . .}. Thus, we use the localized chase that focuses on the IRI constructor f and the set of trace variables A = {x}.

(G f A ) = {(R, 1
), (R, 2), (P, 1), (P, 2), (P, 3), (Q, 1), (Q, 2)},

and edges identify values that can be transferred from one position to other with the application of an inclusion dependency. Then, we identify the distinguished target positions in relational atoms of the mappings Σ st that may yield a triple with f (x) as its subject. For ease of reference, we assign a unique label to each edge in the graph. Now, we perform localized chase on I = {R(x, ⊥ 0 )}. We first trigger the tgd (6.11) (R,1) (R,2) (P,1) (P,2) because its body is on I and its head is not and it is productive, i.e.,the edge e 1 takes the value x that appears in the position (R, 1) in the instance I and leads the value to the marked position (P, 2). We apply this tgd obtaining I 1 = {R(x, ⊥ 0 ), P (⊥ 1 , x, ⊥ 0 )} and we mark this tgd to prevent triggering it multiple times. Here, for the two inclusion dependencies (6.13) and (6.14), the body is in I 1 but not the head is, yet we shall not trigger them. Consider the tgd (6.14), the corresponding edge is e 3 in Figure 6.7, which indicates that this tgd can send the values from position (P, 2) to (R, 2). We observe that from position (R, 2) there is a cycle that does not pass by a marked a position. Therefore, this tgd is not productive and we do not run it. Now, consider tgd (6.13), it is not productive because no path starts with e 7 that leads to a marked position. We point out that the localized chase is defined so that if the same tgd is in a cycle, then it is not triggered more than once as we see for the next tgd. The third tgd (6.12) has not been triggered before and it is productive because the path e 4 , e 5 , which is a cycle, leads to a marked position. Thus, we apply it obtaining the instance I 2 = {R(x, ⊥), P (⊥ 1 , x, ⊥ 0 ), Q(⊥ 1 , x)} and we mark this tgd. Then, the tgd (6.15) is triggered on I 2 and applied to it obtaining the instance

(P,3) (Q,1) (Q,2)
I 3 = {R(x, ⊥ 0 ), P (⊥ 1 , x, ⊥ 0 ), Q(⊥ 1 , x), P (⊥ 2 , x, ⊥ 3 )}.
Here, we do not trigger the inclusion dependency (6.12) any further because it is marked. Then, there are no more inclusion dependencies to trigger. The result of the localized chase on I = {R(x, ⊥ 0 )} with the target f (x) is the locally-chased canonical instance I 3 of mapping (6.16).

The localized chase, denoted by -chase, has as inputs an instance I of R, a set of inclusion dependencies Σ ind of the relational schema, set of mappings Σ st , an IRI constructor f and the set of trace variables A used as arguments of f . Because A and the terms used in I (adom(I)) contain variables and null values, the constructor cannot be applied to them. Instead, we shall represent their result symbolically as terms of the form f (x).

We construct the value flow dependency graph, denoted by G f A , which is a directed graph with distinguished target nodes defined as follows. The nodes are the pairs (R, i)

where R ∈ R of arity k and 1 ≤ i ≤ k, and (R, i) denotes the i-th argument of relation R. We call each pair a position. For every ρ ∈ Σ ind , there is a corresponding set of edges E ρ defined as follows (we treat inclusion dependencies as tgds):

E ρ = {((R, i), (P, j)) ∈ nodes(G f A ) 2 | t, t ⊆ vars(ρ). R(t) ∈ body(ρ), P (t ) ∈ head (ρ), ∃x ∈ vars(ρ).
x on position i of t and on position j of t }.

For instance, if we take the inclusion dependency (6.11), we obtain the edges (R, 1) to (P, 2) and (R, 2) to (P, 3) that indicates that values in the sources positions are transferred to the target positions. The set of edges of

G f A is E = ρ∈Σ ind E ρ .
Given a mapping σ ∈ Σ st whose IRI constructor is f , we distinguish a target position (R, i) if there is a variable x occurring in the i-argument of R in the body of σ and x is in vocabulary of the subject term of σ i.e., x ∈ Vocab(sub(σ)) \ F, where sub is a function that obtains the subject term of a mapping. Formally, the set of marked positions N m ⊆ nodes(G f A ) for an IRI constructor f is defined as

N m (f ) = {(R, i) ∈ nodes(G f A ) | ∃σ ∈ Σ st . constructor (σ) = f. ∃x ∈ vars(σ), t ⊆ vars(σ). R(t) ∈ body(σ), x ∈ Vocab(sub(head (σ))),
x is in position i of t},

where constructor : Σ st → F is the function that returns the IRI constructor used in the subject position of a st-tgd.

The localized chase is used only with inclusion dependencies. For each inclusion dependency ρ, we call a variable x a transfer variable if x appears in body(ρ) and in head (ρ). We say that a transfer variable x is relevant in the presence of I if there is a homomorphism h : body(ρ) → I such that h(x) is a trace variable i.e., h(x) ∈ A. At each step, ρ is triggered if ,

• there is a homomorphism h from body(ρ) to the instance,

• there is no extension h of h such that h (head (ρ)) ⊆ I, and

• there is an edge in E ρ that begins at a relevant transfer variable and can be extended to a path that leads to a target position in G f A .

• ρ has not been triggered more than once i.e., the inclusion dependency is not marked.

The localized chase applies iteratively any triggered inclusion dependency and marks it.

The complexity of testing if there exists a trigger for a given instance I and an inclusion dependency is given by the following proposition:

Proposition 6.3.3. Given an instance I of R, testing whether there is an inclusion dependency that is triggered can be done in polynomial time in the size of I.

Proof. Take an inclusion dependency ρ ∈ Σ ind of the form R(x, y) ⇒ ∃z. P (y, z). The first condition can be verified by checking row by row in the instance if it satisfies the body of the dependency. We also need to consider if the head of the dependency is not satisfied in the instance by inspecting row by row. These tasks can be carried out in polynomial time in the size of I. For the third condition, we can use a standard graph reachability algorithm to know if a position leads to a marked position. This task is also done in polynomial time. Thus, testing if an inclusion dependency is triggered is in polynomial time in the size of I.

The complexity of the localized chase is given by the following proposition

Additional notions

To describe next sections, we define the following auxiliary functions. We assume that nodes of the minimal and maximal models have implicit types and we define the function node-type that identifies the type of a node as follows:

node-type(n) =      T g , if n = g(x) for some x ∈ V V Lit, if n = x for some x ∈ V V
For instance, given the graph G = {Triple(f (x), p, y)}, the function applied on the nodes of G obtains node-type(f (x)) = f and node-type(y) = Lit.

In the sequel, we fix f ∈ F. For constructing both minimal and maximal model, we denote by Σ f st the subsets of Σ st that share the same IRI constructor f in their subject terms. Implicitly, we rename the variables so that in all st-tgds of Σ st , the same set of variables appears in the subject term. Every variable that does not appear in the subject term is a non-shared variable.

A locally-chased canonical instance of a st-tgd σ ∈ Σ f st , denoted by I σ , is the instance obtained from chasing locally with the source canonical instance of σ and the set of source dependencies Σ R focusing in the IRI constructor f and its arguments. For instance in the Example 6.3.2, I 3 is the locally-chased canonical instance of mapping (6.16) on I.

We define the function multiplicity-set Mult : 2 Iri → {0, 1, +} that returns a multiplicity depending on the cardinality of the set A ∈ 2 Iri defined as

mult(A) =              0, if |A| = 0 1, if |A| = 1 +, otherwise
A shape expression is a function E : Iri × T → {0, 1, ?, +, *} that assigns to a pair of predicate and type a multiplicity. We define the function ShExpr (G, n) that returns the shape expression E that describes the neighborhood of a node n in graph G and is defined as follows E(p, t) = Mult(Dst n p:t (G)), where Dst n p:t (G) is the set of target nodes for a given source node n and predicate p, whose type of those nodes is t i.e.,

Dst n p:t (G) = {m | (n, p, m) ∈ G, node-type(m) = t}.
We recall that every multiplicity corresponds to an interval. Also, every interval The result is an interval that is a basic interval.

A fitting of a set of shape expressions E constructs a shape expression E fit from the set of shape expressions as follows. For every property and type (p, t) ∈ Iri × T, E fit is defined as

E fit (p, t) = fit({E(p, t) | E ∈ E}).

Minimal models

The minimal model of σ ∈ Σ f st is a graph G σ min produced by Σ f st on the locally-chased canonical instance of σ. Recall that M3 algorithm is constructing a single type for every IRI constructor and, consequently, we consider G σ min a minimal model for this type. The complexity of constructing all minimal models for a type T f is given by the following proposition: Proposition 6.3.5. Let m be the maximum number of atoms in a st-tgd in Σ f st . Let l be the number of st-tgds in Σ f st . There is at most l minimal models and the construction of each minimal model is of polynomial size in n • k + m + l where n is the number of inclusion dependencies and k is the maximum arity of relational name in R.

Proof. Let l be the number of st-tgds in Σ f st . Since the subject term of each st-tgd is in every minimal model and there is at most l subject terms, then there are at most l minimal models. The construction of the minimal model is the result of chasing the canonical source instance that is bounded by m, which is the maximum number of atoms in a st-tgd in Σ f st . First, we chase locally, which by Proposition 6.3.4 is polynomial in the size of n • k + m where n is the number of inclusion dependencies and k is is the maximum arity of relational name in R. The result is the locally-chased canonical instance. The chase with functional dependencies does not increase the size of locallychased canonical instance. On the other hand, at each chase step of a st-tgd, we add one triple atom and since we have l number of st-tgds and by Beeri and Vardi [Beeri & Vardi 1984], then the result is bounded by the size of the input instance then the minimal model is of polynomial size in n • k + m + l.

Maximal model

To obtain the maximal model, we introduce the following terminology. A saturated instance of a st-tgd σ ∈ Σ f st , denoted by I * σ , is obtained by the following process. We create a copy of σ, denoted by σ , such that both st-tgds share the same variables in the subject term and every non-shared variable is renamed. Then, we compute its locallychase canonical instance I σ and J σ for σ and σ respectively. Finally, we chase the union of these two locally-chase canonical instances with the functional dependencies of R, I * * σ = chase(I σ ∪ I σ , Σ fd ). A saturated instance for f , denoted by I f max , is the instance obtained from the union of saturated instances of st-tgds in Σ f st ,

I f max = {I * * σ | σ ∈ Σ f st }. The maximal model of T f is a graph G f
max obtained from chasing the saturated instance for f with the set of mappings. The complexity of constructing the maximal model for f is given by the following proposition: Proposition 6.3.6. Let m be the maximum number of atoms in a st-tgd in Σ f st . Let l be the number of st-tgds in Σ f st . The construction of the maximal model for f is bounded by l • (n • k + m) + l where n is the number of inclusion dependencies and k is the maximum arity of relational name in R.

Proof. Let l be the number of st-tgds in Σ f st . We use the localized chase twice per st-tgd and we do repeat it l times obtaining the union of all this localized-chased canonical instances. By Proposition 6.3.4 the result of applying each localized chase is bounded by n • k + m. Thus, the saturated instance for f is bounded by l • (n • k + m). Then we chase this result with Σ f st , which by Beeri and Vardi [Beeri & Vardi 1984], we obtain that the maximal model is bounded by l • (n • k + m) + l.

Algorithm

Now, we present the M3 algorithm based on the use of minimal and maximal models.

The input is a schema-less data exchange setting E d = (R, Σ st , F). The aim of the elicitation algorithm is to generate a shape definition for each type that covers all possible graphs produced by any instance of R with the mappings.

Algorithm 5: M3: Elicitation algorithm.

Input: a schema-less data exchange setting Algorithm 5 begins with the definition of the set of types T obtained from the IRI constructors that appeared in the subject position of a st-tgd in Σ st . For each type T f in T, we compute its shape definition as follows. We construct all the minimal models and the maximal model. Then we fit the set of shape expressions obtained from each model, and assign the fitted shape expression to the shape definition of T f .

E d = (R, Σ st , F) Output: a shapes schema S = (T, δ). 1 T := {T f | ∃σ ∈ Σ st , constructor (σ) = f }; 2 for T f in T do 3 G := ∅; 4 I f max := ∅;

Soundness

Now, we show that M3 is sound using the notion of embedding. Now, we take (T, (q, µ), T ) ∈ out G S (T ) and show by contradiction that {occur G ((n, q, o)) | (n, q, o) ∈ out G (n), λ((n, q, o)) = (T, (q, µ), T )} ⊆ occur G S ((T, (q, µ), T ). For the first case, we assume G has no outgoing edges from n with q and target type of the node being T and assume the shape definition for T requires at least one outgoing edge with q to a node of type T . By construction of the shape expression in M3, there is a st-tgd σ ∈ Σ st of the form ϕ(u, v) ⇒ Triple(f (u), q, v)

that is triggered in some locally-chased canonical instance I σ of some mapping σ . By construction of I σ , there is set of inclusion dependencies Σ ind that have been applied from the canonical source instance of σ such that body(σ) has been triggered. Because G ∈ T (E d ), there is an instance I ∈ Inst(R) such that I ∪ G |= Σ st . Since σ ∈ Σ st and G does not have an outgoing edge from n with q, then there is no homomorphism h(body(σ)) ⊆ I. Because σ ∈ Σ st and not restriction is given of σ , we assume that there is h (body(σ )) ⊆ I. Since Σ ind exist and the value flow dependency graph indicates that value from the position must be send to the marked position that appears in the body of σ, then I must satisfy Σ ind . However, no homomorphism is in the body of σ. Thus, I does not satisfy Σ ind and I ∈ Inst(R); a contradiction.

For the second case, we assume G has more than one outgoing edge from n with q and target type of the node being T and assume the shape definition for T restricts to have only one outgoing edge with q to a node of type T . By construction of the shape expression by M3, there is σ ∈ Σ st of the form ϕ(x, y) ⇒ Triple(f (x), q, y) that is triggered in every minimal model and maximal model for T . Also, there is a functional dependency ρ ∈ Σ fd that is applied such that in the construction of the maximal model for T , some values in the saturated instance for T are equated and from these values one is used to generate a triple with q. This implies that there is some relation in ϕ(x, y)

such that the attributes in positions of x implies y. Because G ∈ T (E d ), there is an instance I ∈ Inst(R) such that I ∪ G |= Σ st . We apply backwards the mappings on G and have that for σ ∈ Σ st there must be different homomorphisms that assign variables of σ to constant values such that h 1 (y) = h 2 (y) = . . .. Because there is a functional dependency ρ ∈ Σ fd , on the attributes corresponding to x, then those constant values will be equated. Then I ∈ Inst(R); a contradiction.

Completeness

We identify a class of mappings where M3 algorithm is complete i.e., for any schemaless data exchange setting in such class, the constructed target schema is complete. This class is based on the classical translation of an entity-relationship diagram to mappings.

We recall the notion of an entity-relationship diagram and present a natural translation to a schema-less data exchange setting with the following example. Now, from this ER diagram and assuming the relational schema is constructed as above, we construct a set of mappings as follows. For every entity, we identify the relation that corresponds to it, assign a unique IRI constructor and for every attribute related to the entity, we create a mapping with objects as literals. If the relation has any referential keys due to a relationship with orientation , then a mapping is created with object as IRI node where the IRI constructor is the one assigned to the entity and the argument is the key attributes. For instance, mapping (6.21) is created from relation with referential constraint. The subject in these mappings is composed of the IRI constructor assigned to the entity and the primary key of the entity. Next, for every relationship between E 1 and E 2 with orientations and , we create a mapping with subject composed of the IRI constructor assigned to E 1 and the argument is the key attributes of E 1 , the predicate is the name of the relation, and the object composed of the IRI constructor assigned to E 2 and the argument of this object is the key attributes of E 2 . For instance, mapping (6.25). We obtain the following mappings:

Project(id , title, idSup) ⇒ Triple(pro2iri (id ), id, id ), (6.19)

Project(id , title, idSup) ⇒ Triple(pro2iri (id ), title, title), (6.20)

Project(id , title, idSup) ⇒ Triple(pro2iri (id ), manages, sup2iri (idSup)), (6.21)

Supervisor (id , name, office) ⇒ Triple(sup2iri (id ), id, id ), (6.22)

Supervisor (id , name, office) ⇒ Triple(sup2iri (id ), name, name), (6.23)

Supervisor (id , name, office) ⇒ Triple(sup2iri (id ), office, office), (6.24)

Oversees(idPro, idSup) ⇒ Triple(pro2iri (idPro), oversees, sup2iri (idSup)) (6.25)

• the function key : Ent → 2 A assigns to every entity E ∈ Ent a finite set of attributes A ⊆ attr (E) that is a key.

• orient : Rel → { , , } specifies the type of a relation as follows. The symbol specifies the many-to-many relationship. The symbol specifies the many-toone relationship and the last symbol specifies the many-to-one relationship with referential integrity constraint. • the set of inclusion dependencies is • a 1 , . . . , a n to the attributes of the entity,

Σ ind = {R r [A] ⊆ R E 1 [A], R r [B] ⊆ R E 2 [
• each y 1 , . . . , y k corresponds to each many-to-one relationship with referential integrity constraints of E i.e., there is an inclusion dependency R

E [y l ] ⊆ R E l [x ]
where l ∈ {1, . . . , k} with k being the number of many-to-one relationship with referential integrity constraints, and

• x corresponds to the primary key of R E l .

For each corresponding many-to-one relationship with referential integrity constraint, we denote as q l where l ∈ {1, . . . , k}. Then, we create the following mappings for E: R E (x, a 1 , . . . , a n , y 1 , . . . , y k ) ⇒ Triple(f E (x), a i , a i ) R E (x, a 1 , . . . , a n , y 1 , . . . , y k ) ⇒ Triple(f E (x), q l , f E i (y l ))

where i ∈ {1, . . . , n}.

For every many-to-many relationship and many-to-one relationship r between two entities E 1 and E 2 , there is a relation of the form R r (y, z) where y and z correspond to the primary key of E 1 and E 2 , respectively. Moreover, there are two inclusion depen-

dencies R r [y] ⊆ R E 1 [y] and R r [z] ⊆ R E 2 [z ]
. Then, we create the following mapping R r (y, z) ⇒ Triple(f E 1 (y), r, f E 2 (z)),

where f E 1 and f E 2 are two IRI constructors assigned to E 1 and E 2 , respectively.

Interestingly, from a given ER diagram, we can produce a shapes schema for graphs representing the information that is modeled by the ER diagram. This is a natural construction. By, sh-schema(ER) we denote the function of constructing a shapes schema as follows. For every entity E ∈ Ent, we assign a distinguish type T E and for every attribute of E, we create a triple constraint where the attribute name is the property label and the target type is Lit. For every relationship of E that relates some other entity E ∈ Ent, we create a triple constraint where the property label is the name of the relationship and the target type is E . The multiplicity of each triple constraint where the target type is not a literal is assigned according to the type of relationship.

• If the relationship is many-to-one with referential integrity constraint, then the multiplicity is 1 because this relationship allows an object of E to be related with at most one object of E and since the object is identified by some key, then is one to one object.

• If relationship is many-to-many, then the multiplicity is * because this relationship allows an object of E to be related with zero or more objects of E .

• If relationship is many-to-one, then the multiplicity is ? because this relationship does not allow two objects of E to be related with the same object of E i.e, a object of E is related with zero or one object of E .

Otherwise, if the target is Lit, then the multiplicity is 1. Formally, sh-schema(ER) = (T, δ) where

• the set of types is T = {T E | E ∈ Ent},

• for every type T E its shape definition is Proof. Take a flat ER diagram ER. The proof of ER.1 follows from construction of the algorithm and definition of sh-schema(ER) i.e., all the predicates in Σ st come from relationships and attributes that are mapped to property labels as done in sh-schema(ER)

and each triple constraint obtained by M3 is in sh-schema(ER) and the multiplicities are the same. Now, we prove ER.2 by proving that M3 is sound and complete for E ER d . By Theorem 6.4.1 and because E ER d is a subclass of a schema-less data exchange setting, M3 is sound for E ER d . Now, we prove completeness of M3. Let S = sh-schema(ER). Take a graph G ∈ L C (S). Assume G uses IRI nodes of the form f (k 1 , . . . , k n ) for some f ∈ F, k i ∈ Const where i ∈ {1, . . . , n} and n = |key(E)| for some E ∈ Ent and f corresponds to E. We apply backwards the mappings on G obtaining an instance I. The form of mapping(ER) and S ensures that the backchase step is well-defined as follows.

If we take a node n ∈ nodes(G) then every outgoing edge label of n is either attribute or relationship name, other kind of label is not accepted by S. Since every attribute and relationship name is considered in rel -schema(ER), then for every outgoing edge of n, there is tuple in a relation with the values of the source and target node. For instance, Triple(f (1), a, 3), we have a fact R(1, . . . , 3, . . .). Also, no two st-tgds obtained by mapping(ER) have same subject and predicate and every argument of an IRI constructor is a primary key in the relation that appears in the body of a st-tgd.

We prove by contradiction that I satisfies the set of dependencies of R. Assume that I |= Σ R . Then, there are two possible cases. We choose l ∈ {1, . . . , k} and u ∈ {1, . . . , m}, and by mapping(ER), we identify two mappings R(x, a 1 , . . . , a n , y 1 , . . . , y k ) ⇒ Triple(f (x), q l , g(y l )) P (x , z 1 , . . . , z m ) ⇒ Triple(g(x ), z u , z u ) where f, g ∈ F and f is assigned to R, and g is assigned to P . M3 obtains for T g a triple constraint z u :: Lit 1 . Because I is obtained by applying backwards the mappings, then G contains triple Triple(f (d), q l , g(b l )) and does not contain an outgoing edge with z u from g(b l ); a contradiction because the shape definition for T g has z u :: Lit 1 and G ∈ L C (S). Now, let chase(I, Σ st ) = G . We prove by contradiction that G ∼ = G. For the ⇒ direction, take a node n ∈ nodes(G ) and assume n not in G . Since every node is produced by the application of an IRI constructor then let be f the IRI constructor. The assumption only is possible if f (x) = n and f (x) = m being m in G ; a contradiction because the IRI constructor only generates precisely one IRI value. For the ⇐ direction, take a triple (n, a, m) ∈ G and assume this triple is not in G . By construction of shape expressions of minimal and maximal models and G ∈ L C (S), then there is a triple constraint with a::T µ for some T ∈ T and some µ ∈ {1, ?, +, *} and there is a mapping σ with predicate a in the head atom. Since we applied backwards the mappings to obtain I, we know there is a homomorphism h such that h(body(σ)) ⊆ I. We chase I with the mappings and we obtain that (n, a, m) is in G ; a contradiction. A schema-less data exchange setting is flat if the relational schema is flat, and the set of mappings has a single body atom, the subject is used as key in the relation and there are no two st-tgds with the same subject and predicate. It is easy to see that the setting be as follows.

R(x, y) ⇒ Triple(f (x), r, f (y)) (6.26) P (x, y) ⇒ Triple(f (x), q, g(y)) (6.27) P (x, y) ∧ R(x, z) ⇒ Triple(g(y), p, f (z)) (6.28) Figure 6.9 indicates the following inclusion dependencies:

R[x] ⊆ R[y] R[y] ⊆ R[x] Q[x] ⊆ P [y] P [y] ⊆ Q[x] P [x] ⊆ R[x]
We prove by contradiction. Assume there is a complete shapes schema S such that a graph recognized by the language can have the triangle pattern. Let I 0 = {R(2, 2), R(1, 2), P (1, 1), Q(1, 3)} be an instance of the relational schema. The graph produced by the mappings is presented in Figure 6.10a. Since the graph satisfies the schema, then we assume that there are the types T 1 , T 2 and T 3 such that T 1 is assigned to f (1), T 2 is assigned to f (2) and T 3 is assigned to g(1). We observe the triangle pattern present in this graph. We break this pattern by cloning the node f (2) such that for every outgoing edge of f (2), we add the same outgoing edge in the cloned node having r-edge that goes from the cloned node to f (2). Let this cloned node be f (4). Then, we redirect the p-edge from g(1) to be f (4). Then, we assign the type T 2 to f (4). Thus, we obtain a graph G shown in Figure 6.10b. We observe that G satisfies the schema because G is bisimilar to G. In particular, f (4) must satisfy T 2 . Take the instance that constructs an isomorphic graph to the one presented in Figure 6.10b. For edge from f (1) to f (2), we obtain the fact R(1, 2) and for edge f (1) to g(1), we obtain the facts P (1, 1). But, we observe that this set of facts {R(1, 2), P (1, 1)} triggers rule (6.28) adding new edge from g(1) to f (2)

to G obtaining the triangle pattern. Contradiction because the graph obtained from the application of the mapping to the instance chosen is different from G .

f (1)

T 1 f (

Conclusion

We have investigated the problem of shapes schema elicitation that aims at constructing a target schema for a schema-less relational to RDF data exchange setting, which is composed of the relational schema, set of mappings from relational schema to RDF graph and library of IRI constructors. This is a practically important problem in the context of the Web, because many RDF graphs on the Web have been exported from relational databases as evidenced by the proliferation of languages for mapping relational databases to RDF.

We have identified two desirable properties of the target shapes schema, which are soundness and completeness. The property of completeness of the target schema ensures that no trivial solutions are presented for this problem. Our solution is the M3 algorithm based on minimal and maximal models, which produces a sound schema for every schema-less data exchange setting. We have identified a practical class of schema-less data exchange setting that follows from relational databases modeled by flat ER diagrams where M3 obtains a complete schema. Finally, we have shown that the task of producing sound and complete schemas has inherent limitations: a complete schema may be of exponential size and even the possibility of non existence of complete schema.

Related work

Schema elicitation can be generalized as constructing a schema from a set of mappings between two models and an input schema. We distinguish two kind of models: structured and semi-structured. By structured models, we mean relational databases where the schema is fixed i.e., if we add data to a relational database, we need to specify the schema. By semi-structured models, we mean XML, JSON, RDF databases and property graphs where we can have a database without specifying the schema. The problem of schema elicitation is trivial when both models are structured because the target schema is part of the description and together with the mappings contains all the information for the construction of the schema. The schema elicitation is relevant when the target schema is semi-structured.

In the case of mappings from structured model to RDF, to our knowledge there are no works that have tackled this problem. Our work is the first one in treating this case. In the case of mappings between XML databases, Groppe and Groppe [START_REF] Groppe | [END_REF] has consider a variant of this problem because they do not have an input schema but a set a set of XML documents and the set of mappings is in a XSLT stylesheet, and the problem aims at constructing a XML Schema [START_REF] Thompson | XML Schema Definition Language (XSD)[END_REF] that characterizes the output language. Authors propose an algorithm that analyzes the XSLT stylesheet where the target schema obtained follows from the mappings. In their algorithm, there is a merging process and they notice, however, that there is a loss of information while during the merging. Thus, they do not consider the problem of completeness and most importantly they do not have an input schema.

Another related problem to schema elicitation is the typechecking problem that consists of evaluating if the target schema is sound w.r.t. an input schema and a set of mappings. Noga et al. [START_REF] Alon | [END_REF]] has studied decidable cases where a DTD is sound w.r.t. a relational schema and set of mappings. In our approach, we construct a complete schema and we can see the typechecking as testing the containment between the target schema provided and the one that we obtained. Also, the schema inference problem is related with schema elicitation and it consists of constructing a schema from a set of instances of a model. For instance, Baazizi et al. [START_REF] Baazizi | [END_REF]] infer a schema from JSON databases, Li et al. [START_REF] Li | [END_REF]] infer a XML schema from a set of XML documents and Kellou-Menouer and [START_REF] Kedad | Kenza Kellou-Menouer and Zoubida Kedad. Schema Discovery in RDF Data Sources[END_REF] infer a RDF schema from a set of RDF databases. However, we do no present them because the setting does not consider mappings.

Conclusion

In this manuscript, we have investigated data exchange from relational databases to RDF graphs with target shapes schemas. We have presented different problems of interest in the data exchange problem due to the consideration of target schemas and use of declarative formalisms for expressing mappings such as R2RML. To study those problems we have formalized the constructive relational to RDF data exchange setting that captures a large fragment of R2RML.

For the error-prone process of designing mappings and consistency checking problem, we have developed a static analysis tool that allows to find non trivial modeling errors and illustrates them by constructing counter-examples, whose study allows to repair the modeling errors done in the mappings. Moreover, our techniques could potentially be used to manage complex process by decomposing the process into independent components. The decomposition process allows to lower the complexity and mitigate this error-prone process. One method to know if decomposition is possible is by testing independency of rules for which the technique for testing node kind consistency can be adapted to know if certain triples will appears in both results. Also, we have shown that checking consistency for a constructive setting is coNP-complete. A future work is to study redundancy of mappings by identifying mapping rules whose subtraction will not change anything. However, this problem requires additional techniques that we do not have study because redundancy is a a problem of containment and our techniques are not enough to solve this problem.

For the problem of certain query answering, we have proposed the notion of universal simulation solution. This solution has the property of a universal solution because certain answers for queries that are robust under simulation can be computed. Contrasted to other approaches, a universal simulation solution can be constructed for any kind of constructive setting. Our contribution of this notion might give the foundation to know if a solution is good by showing that a solution must preserve the exchanged information and contain the missing information required by the schema as encoding of those constraints that are not satisfied. A challenge related to this problem is the construction of a solution in low complexity. We can construct a minimal-size universal simulation solution which is exponential in the size of the schema. Compared to other approaches, we materialize a solution, which is important in the context of data exchange, and constructs our good solution in low complexity. We have shown that the data complexity of computing certain answers in a universal simulation solution for forward NRE and any constructive setting is PTIME. Our approach does not follow from existing results on the standard relational data exchange, which are too limited in their expressive power. As a future work, we plan to study computing certain answers with full NRE-based queries and extending to non-Boolean queries.

For the problem of visual mapping language, we have proposed a visual mapping language (VML) to overcome the barriers of non-expert users in the specification of mappings. VML uses simple visual representations such arrows, boxes and lines, which combined make the mapping accessible and of easy use. However, the expressivity of VML is constrained in the tool to ensure the computation of a solution for a data exchange setting. We have developed ShERML that uses this language to specify mappings and performs the relational to RDF data exchange. This tool is an answer to the challenge of providing an interface that covers at most as possible the specification of constructive mappings. As a future work, we plan to extend the capabilities of ShERML so users can specify mappings with R2VML.

Finally for the problem of schema elicitation, we have defined a non-trivial algorithm that constructs a shapes schema using a method of minimal and maximal models.

We can use this method to measure the quality of other algorithms. For instance, any other solution that does not recognize a minimal model is not correct, also a solution that recognizes graphs with more edges than the identified for the maximal model is a trivial solution. We have identified two properties that makes a target shapes schema a good schema. This two properties are soundness and completeness. Our algorithm is sound for every input and complete for a particular class of inputs derived from flat ER diagrams. As a future work, we plan to identify the precise class of inputs for which our algorithm is complete. Our study also shows that inherent limitations of constructing target shapes schemas.

Our investigation has been focused on deterministic shapes schema and constructive st-tgds. It might be interesting to study each problem of interest in a data exchange setting with non-deterministic shapes schema and non-constructive st-tgds.

  Nous étudions le problème du calcul de réponses certaines. Une réponse est certain si la réponse tient dans chaque solution. En générale, réponses certaines sont calculées en utilisant d'une solution universelle. Cependant, dans notre contexte, une solution universelle pourrait ne pas exister. Ainsi, nous introduisons la notion de solution de simulation universelle, qui existe toujours et permet de calculer certaines réponses à n'importe quelle classe de requêtes robustes sous simulation. Une de ces classes sont les expressions régulières imbriquées (NRE) qui sont forward c'est-à-dire qui n'utilisent pas le opération inverse. L'utilisation d'une solution de simulation universelle rend traitable le calcul de réponses certaines pour les NRE (data-complexity). Enfin, nous étudions le problème d'extraction de schéma des formes qui consiste à construire un schéma de formes cibles à partir d'un système constructif d'échange de données relationnel vers RDF sans le schéma de formes cibles. Nous identifions deux propriétés souhaitables d'un bon schéma cible, qui sont la correction c'est-à-dire que chaque graphe RDF produit est accepté par le schéma cible; et la complétude c'est-à-dire que chaque graphe RDF accepté par le schéma cible peut être produit. Nous proposons un algorithme d'extraction qui convient à tout système d'échange de données sans schéma, mais qui est également complet pour une grande classe pratique de systèmes sans schéma.

Figure 1 . 1 :

 11 Figure 1.1: Database instance of conference schema.

  where R, P ∈ R are relation names, X ⊆ attrs(R) and Y ⊆ attrs(P ) and |X| = |Y |.

t

  : X → Dom and t.X(a) = t(a) for a ∈ X. An instance I of a relational schema R is a function I that maps every relation name R ∈ R to a finite set I(R) of tuples over attributes of R. The size of an instance I of R, denoted by |I| is the sum of number of tuples by relation mapped by I.

  an answer to a query ϕ in I if and only if (I, val ) |= ϕ. The set of answers to a query ϕ in I is QA(ϕ, I) = {val | (I, val ) |= ϕ}. If a query is a closed formula, the answers are Boolean: true if QA(ϕ, I) = {∅}, otherwise is false. This kind of query is called Boolean query. A conjunctive query is an existentially quantified conjunction of atomic formulas over a relational signature R and Boolean conjunctive query (BCQ) is conjunction of closed atomic formulas. The size of a conjunctive query Q is denoted by |Q| and it represents the number of atoms in Q.

Figure 1

 1 Figure 1.5: A solution for data exchange setting with function names.

  Example 1.3.3 (cont. Example 1.3.1 and 1.2.2). Recall the conference database I and the set of st-tgds Σ st (rules in Example 1.3.1). The procedure initializes with an empty instance J of the target schema. In Figure1.6 we observe that the st-tgd (1.3) is triggered because the body of the dependency matches values in the instance I and the head of the dependency does not match values in instance J. The application of this dependency generates fresh values for matching the head of the dependency in J. By triggering the rules in Example 1.3.1, we get the following chase sequence.

  h assigns values to the null values used by h, and we have h (h(x i )) = h (h(x j )) while the other null values remain the same; and I = h (I). If σ is triggered in I by h but does not have a successful execution, we say that it fails, in symbols I

Figure 1 .

 1 Figure 1.11: Solutions for Example 1.3.5.

Figure 1 .

 1 Figure 1.11, we view solutions as graphs where nodes are the data values and edges are the relation names that contain the data values. The corresponding graph of each

Figure 1 .

 1 Figure 1.12: Graph representation of the set of solutions in Figure 1.11.

Figure 1 .

 1 Figure 1.14: Answers to Boolean queries Q 2 and Q 3 in solutions J 1 and J.

Figure 1 .

 1 Figure1.14 shows that true is not certain answer to query Q 2 .

Figure 1 .

 1 Figure 1.15: Example of consistency problem.

Figure 1 .

 1 Figure 1.18: Set of statements written in Turtle.

Figure 1 .

 1 Figure 1.19: Serialization of a neighborhood of node ulille:etupac in Turtle.

Figure 1 .

 1 Figure 1.20: Serialization of the neighborhood of node ulille: in Turtle.

  typing 0 (dbp:Mathematics) = {ShTopic} typing 0 ( :b 1 ) = {ShAddress} typing 0 (ulille:jlozano) = {ShResearcher} typing 0 (ulille:) = {ShUniversity} typing 0 ("Jose Lozano") = {Lit} Then the pair (G 0 , typing 0 ) is called a typed RDF graph.

Figure 1

 1 Figure 1.23: Shape graph of shapes schema in Example 1.5.1.

  Example 2.1.1. Recall the database schema of the academic institute in Example 1.2.1 which has six relations: UniTeam(Team, University, Place), Researcher(Idr , Name, Email , Expertise, Team), Talk(Idr , Idc, Title) Conference(Idc, Name, Year , Place), Registration(Idr , Idc, Date), Collaborator(Idr , Idc, Title, Idrc).

Figure 2 . 1 :

 21 Figure 2.1: Example of shapes schema.

  1) = ulille:res/jlozano; • f pap2iri takes the name and year of a Conference and the title of a Talk presented in the given conference. It outputs an IRI consisting of the prefix dblp:paper# with a unique integer associated to the paper. For instance, f pap2iri (icdt, 2019, Tutoring Web math platform) = dblp:paper#1;

Figure 2

 2 Figure 2.2: A solution for the Example 2.1.1.

Figure 2

 2 Figure 2.4: A well-formed R2RML mapping node from [Rodriguez-Muro & Rezk 2015].

Figure 2 . 6 :

 26 Figure 2.6: Example of consistency problem.

Figure 2 . 7 :

 27 Figure 2.7: Part of the infinite solution for the database conference I w.r.t. E 1 .

Figure 2 .

 2 Figure2.8 shows mappings from R 1 to the shapes schemas described above. We study the accessibility of the proposed visual mapping language by a user evaluation.

  The authors define what is a solution for data exchange. We adapt their setting to our context and define a solution as Fagin et al. did. XML data exchange [Arenas & Libkin 2008], proposed by Arenas et al., deals with hierarchical data. Their setting uses source and target DTDs and for the mappings a closer formalism to tree patterns [Amer-Yahia et al. 2002] and XPath [Benedikt

  Example 3.1.2. We consider the database instance I in Figure 3.1a, the following shape schema ShAddress → ex:name :: Lit 1 ShInstitute → ex:address :: ShAddress 1 ShUniversity → ex:address :: Lit * ShConference → ex:name :: Lit 1 ; ex:year :: Lit 1 ; ex:place :: Lit 1 ; ex:sponsor :: ShInstitute 1 and the following transformation rules

  y e a r ex:place e x : p l a c e ex:sponsor ex:address (b) The core pre-solution to I w.r.t. E of Example 3.1.2.

Figure 3

 3 Figure 3.1: Example of a inconsistency setting.

  Definition 3.1.3. A graph G has a violation w.r.t. a shapes schema S if the following conditions are satisfied:

  F k (f (x)) = b. By head of σ being of the form T (f (x)) and because in definition of accessibility the path can be empty, (T, f ) is accessible in E. Otherwise (b) there is a k < k, S ∈ T, p ∈ Prop S , b ∈ Iri such that J k contains the set of facts {S(b ), Triple(b , p, b)}. Also, the rule S(x) ∧ Triple(x, p, y) ⇒ T (y) was triggered in a chase step after k and before k generating the fact T (b). The existence of rule above in Σ TP

  Conditions (a) and (b) are evaluated each time an instance contains a fact T (b) for some T ∈ T and some b ∈ Iri. If condition (a) is found, then (T, f ) is accessible because each time condition (b) is found, by Claim 3.2.2.2 there is a rule in Σ st that is added to the sequence of rules such that the conditions for accessibility are satisfied.

  tuple of constants a from the domain of I and constants b, b s.t. the core pre-solution to I w.r.t. E includes {T (f (a)), Triple(f (a), p, b), Triple(f (a), p, b )} with b = b and there is triple constraint p :: S µ ∈ δ(T ) with some S ∈ T ∪ {Lit} and some µ ∈ {1, ?}.Proof. Take an instance I of R. For the ⇒ direction. Assume there is a violation sort (T, f, p) and there exists π, σ, σ , h s.t. (T, f ) is accessible with path π in E, σ, σ are contentious st-tgds with (T, f, p) and h : I π,σ,σ → I is a homomorphism. Because

  For the ⇐ direction. Assume there exist a tuple of constants a from the domain of I and constants b, b s.t. the core pre-solution J 0 to I w.r.t. E includes the set of facts W = {T (f (a)), Triple(f (a), p, b), Triple(f (a), p, b )} with b = b and there is triple constraint p :: S µ ∈ δ(T ) with some S ∈ T ∪ {Lit} and some µ ∈ {1, ?}. By Lemma 3.2.2 on the fact that T (f (a)) is in J 0 , (T, f ) is accessible with path π in E. Since every triple is generated by the application of a st-tgd, then there are two rules σ and σ that were triggered to generate Triple(f (a), p, b) and Triple(f (a), p, b ). Because every violation in J 0 has a violation sort, then {T (f (a)), Triple(f (a), p, b), Triple(f (a), p, b )} has as sort (T, f, p). Since there is a violation sort (T, f, p) and (T, f ) is accessible, then σ and σ are contentious with (T, f, p).

  t. E. Because the existence of a violation, we know there is the set of facts {T (f (a)), Triple(f (a), p, b), Triple(f (a), p, b )} in J 0 with some tuple of constants a in the domain of I and constants b, b such that b = b . Also, by existence of violation, we know there is a triple constraint p :: S µ ∈ δ(T ) for some S ∈ T ∪ {Lit}

  where h : I π,σ,σ → I is the unique homomorphism and t, t are two different terms such that head of σ is Triple(f (x), p, t) and the head of σ is Triple(f (x), p, t ) where σ, σ are used in the construction of I π,σ,σ . By definition of the set of contentious-based instances, there is π, σ, σ , h π,σ,σ s.t. (T, f ) is accessible with π in E, σ, σ are contentious with sort (T, f, p) and h π,σ,σ is a homomorphism from B π,σ,σ to I π,σ,σ . Now, we compute the core pre-solution J 0 to I w.r.t. E. Since (T, f, p) exists such that (T, f ) is accessible with π in E and σ, σ are contentious with (T, f, p) and h :I π,σ,σ → Iis a homomorphism then by Proposition 3.2.6, there is a triple constraint p :: T µ ∈ δ(T ) for some T ∈ T ∪ {Lit} and some µ ∈ {1, ?} and J 0 contains the set of facts {T (f (a)), Triple(f (a), p, b), Triple(f (a), p, b )} for some tuple of constants a in the domain of I and some constants b, b where

Figure 3

 3 Figure 3.2: Co-typing graph of a setting E.

  Lemma 3.3.4. Let I be an instance of R. Let J 0 be the core pre-solution to I w.r.t. E and G E (I) the completed graph w.r.t. I and E. The typed graph J 0 ∪ G E (I) is a solution to I w.r.t. E.

  T ∈ X and Lit ∈ Y

Figure 4 . 1 :

 41 Figure 4.1: Dependency graph of shapes schema in Example 1.5.1.

  Example 4.2.4. Consider the dependency graph shown Figure 4.1 of shapes schema in Example 1.5.1. We consider the following set of tgds Σ S that captures the weak edge and strong edge of the dependency graph. For a strong edge, there is a PE and TP rule and for a weak edge only a TP rule. ShResearcher(x) ∧ Triple(x, foaf:knows, y) ⇒ ShResearcher(y) ShResearcher(x) ⇒ ∃y. Triple(x, ex:masters, y) ShResearcher(x) ∧ Triple(x, ex:masters, y) ⇒ ShUniversity(y) ShResearcher(x) ⇒ ∃y. Triple(x, ex:worksIn, y) ShResearcher(x) ∧ Triple(x, ex:worksIn, y) ⇒ ShUniversity(y) ShUniversity(x) ⇒ ∃y. Triple(x, ex:address, y) ShUniversity(x) ∧ Triple(x, ex:address, y) ⇒ ShAddress(y)We skolemize the Σ S obtaining:σ 1 :ShResearcher(x) ∧ Triple(x, foaf:knows, y) ⇒ ShResearcher(y) σ 2 :ShResearcher(x) ⇒ Triple(x, ex:masters, f σ 2 y (x))σ 3 :ShResearcher(x) ∧ Triple(x, ex:masters, y) ⇒ ShTopic(y) σ 4 :ShResearcher(x) ⇒ Triple(x, ex:worksIn, f σ 4 y (x)) σ 5 :ShResearcher(x) ∧ Triple(x, ex:worksIn, y) ⇒ ShUniversity(y) σ 6 :ShUniversity(x) ⇒ Triple(x, ex:address, f σ 6 y (x)) σ 7 :ShUniversity(x) ∧ Triple(x, ex:address, y) ⇒ ShAddress(y)

  {p 10 } = In(σ 3 , y) ⊆ Move(Σ S , Out(σ 2 , y)) = {p 7 , p 11 } {p 17 } = In(σ 5 , y) ⊆ Move(Σ S , Out(σ 4 , y)) = {p 14 , p 18 , p 20 , p 25 } {p 24 } = In(σ 7 , y) ⊆ Move(Σ S , Out(σ 6 , y)) = {p 21 , p 25 }.

  returns a set compose of one position because there is only one existential variable. Let this position p o . The function Move computes positions in heads of rules that are reachable from Out(σ, y) such that those positions corresponds to universal variables in rules of the skolemization such that head of σ is unifiable with body of σ ∈ Σ S in positions p o and some position in body of σ and then the head of σ is unifiable with body of σ and so on. Then σ is a TP rule of the form T (x) ∧ Triple(x, p, y) ⇒ T (y) for some T ∈ T and σ is a PE rule, in essence TP and PE rules are interleaved. By definition of containment between set of places, there is a position p k ∈ Move(Σ S , Out(σ, y))

  Lemma 4.3.1. Forward NRE-based Boolean queries are robust under simulation.

  Claim 4.3.1.1. For any two graphs G and H, for any three nodes n, n ∈ nodes(G) and m ∈ nodes(H) if n m and (n, n ) ∈ E G then there is a node m ∈ nodes(H) such that (m, m ) ∈ E H and n m .

  By semantics of p G and n m, there is a m such that (m, p, m ) ∈ H. Since (m, p, m ) ∈ H, then (m, m ) ∈ p H and n m .

  (m, m 2 ) ∈ E 1 H and (m 2 , m ) ∈ E 2 H and composition of binary relation, we have that (m, m ) ∈ E 1 H • E 2 H . By semantics of •, (m, m ) ∈ E 1 • E 2 H . Thus, we obtain (m, m ) ∈ E H and n m .

  Definition 4.3.4. A universal simulation solution to I w.r.t. E is a T-typed graph U that is simulated by every solution J to I w.r.t. E.

  Definition 4.3.5. A bisimulation of a graph G is a simulation R of G by G that is symmetric and reflexive.We note that a non-null node is bisimilar to itself because, by definition of simulation of a graph G, every two non-null nodes n, m ∈ nodes(G) that are simulated, they are equated n = m. Thus, the simulation is reflexive. Because the two non-null nodes are in the same graph, then the simulation is symmetric. Therefore, a non-null node is bisimilar to itself.Many bisimulations can be defined in a graph. We are interested in the maximal bisimulation because the minimal universal simulation solution is based on the maximal bisimulation. We denote the maximal bisimulation by . It is easy to see that bisimulation is an equivalence relation. We fix a graph G and define the equivalence class of a node n ∈ nodes(G) by [n] and the set of all equivalence classes by nodes(G)/ . For each equivalence class C ∈ nodes(G)/ we fix an arbitrarily chosen representative node η C ∈ C. Now, we define the quotient bisimulation of a graph G denoted by G/ as follows. Definition 4.3.6. The quotient bisimulation of a graph G is the set

  Lemma 4.3.3. For any universal simulation solution U to I w.r.t. E, U 0 is simulated by U where U 0 = (J 0 ∪ G E (I))/ and J 0 is the core pre-solution to I w.r.t. E. Proof. We compute the core pre-solution J 0 to I w.r.t. E. Take a universal simulation solution U to I w.r.t. E. Let U = J 0 ∪ G E (I). By Lemma 3.3.4, U is a solution to I w.r.t. E. By Definition 4.3.4, U is simulated by U . Let U 0 = U / . Claim 4.3.3.1. U 0 is simulated by U and U is simulated by U 0 .

  Figure 4.2: Shape Schema Graph

Figure 5 . 3 :

 53 Figure 5.3: Solution in Turtle format.

Figure 5 . 4 :

 54 Figure 5.4: Comparison example of R2VML mappings and st-tgds.

Figure 5

 5 Figure 5.5: A correspondent VML mapping of a R2VML mapping.

  Figure 5.6: An example of VML mapping with annotations.

Figure 5

 5 Figure 5.8: ShERML Architecture and Workflow.

Figure 5 . 9 :

 59 Figure 5.9: Modeling panel at left side and Mapping panel at right side of VML editor.

Figure 5 .

 5 Figure 5.10: Graph representation for relational schema.

Figure 5 .

 5 Figure 5.11: Graph representation for shapes schema.

Figure 5 .

 5 Figure 5.12: An example of R2VML and R2RML mapping.

  mappings per case and user. Now, we analyze the comments of users about ShERML:• Users (a), (b) and (c): it is not clear the use of the IRI constructor and its purpose. One reason because these users did not have a clear understanding of IRI constructors is the lack of knowledge about RDF where the domain is over IRIs or literals.

  present a tool called RML editor. This tool has a visual graph-based user interface, which allows users to create mapping rules graphically. The tool consists of three panels: input panel, modeling panel and result panel. In the input panel, a user loads a relational database that is represented with tabular data. There is no visual representation of a relational schema. Then the user defines IRI constructors in the modeling panel. The visual object for the IRI constructor is a circle that contains its definition. Its definition consists of an IRI with attribute names coming from the relational schema. Then the user drags attributes names from a table and a visual representation is created in the modeling panel for the attribute name. Next, the user draws arrows from the visual representation of an IRI constructor to the visual representation of an attribute name. This arrow is interpreted as a R2RML mapping. The graph defined in the modeling panel defines a set of R2RML mappings that is used in the result panel to show the materialized graph. Similar to this tool, we define IRI constructors but not with a visual object only as text on top of an arrow.

  Figure 6.1: A relational schema.

  Figure 6.2: Shapes schemas elicited.

Figure 6

 6 Figure 6.3: Sound and not complete.

Figure 6

 6 Figure 6.4: A triple pattern present in any output of Σ.

  is a constructive relational to RDF data exchange setting with S ∅ = (∅, ∅) being an empty shapes schema.In the sequel, we treat E d as the corresponding constructive relational to RDF data exchange setting. In particular by sol E d (I) we denote the set of solutions to I ∈ Inst(R)w.r.t. E d i.e., sol E d (I) = {G | I ∪ G |= Σ st }. Also, by T (E d ) we denote all graphsproduced by E d over any instance of the relational schema R i.e.,T (E d ) = {sol E d (I) | I ∈ Inst(R)}.Non-deterministic shapes schemas under close interpretationIn previous chapters of this manuscript, we have considered deterministic shapes schemas interpreted under open interpretation. However, in this chapter, we drop the restriction of determinism. More precisely, a shapes schema now can have a type whose shape definition has multiple triple constraints with the same property. For instance, the following shapes schema is non-deterministic because for type TUniv there are two triple constraints with ex:has. ShUniv → ex:has :: TEmp 1 ; ex:has :: ShSys + . ShEmp → ex:name :: Lit 1 ; ex:sup :: ShAdmin 1 .

Figure 6 . 5 :

 65 Figure 6.5: An example of embedding.

  Figure 6.6: Example of graphs that are isomorphic.

  Example 6.3.1. Consider the schema-less setting where the relational schema has two relations R(x, y), P (x, y) and the inclusion dependency P[x] ⊆ R[x]. The set of mappings Σ st is R(x, y) ⇒ Triple(f (x), r, y),(6.6)P (x, y) ⇒ Triple(f (x), p, y). (6.7)

First

  , we construct the value flow dependency graph G f A of Σ ind w.r.t. Σ st in Figure 6.7. Its nodes are positions in relational names such as nodes

Figure 6

 6 Figure 6.7: Value flow dependency graph.

  [n; m] has its lower bound min([n; m]) = n and its upper bound max ([n; m]) = m. We extend the lower bound to a set of intervals min(Iv ) = {min(k) | k ∈ Iv }, and the upper bound to a set of intervals max (Iv ) = {max (k) | k ∈ Iv }. A fitting of a set of basic intervals Iv is defined as follows. fit(Iv ) = [min(min(Iv )), max (max (Iv ))]

θ

  assigns to every non-share variable a fresh variable;12 J σ := {body(θ(σ))}; 13 J * σ := -chase Σst f (J σ , Σ ind ); 14 I * * := chase(I * σ ∪ J * σ , Σ fd ); f ) := fit({ShExpr (G, f (x)) | G ∈ G});20 end 21 return S = (T, δ);

  Theorem 6.4.1 (Soundness). Let S be a shapes schema obtained by M3. It holds that S is sound w.r.t. E d .Proof. Let S be the shapes schema obtained with M3. Take G ∈ T (E d ). We construct implicitly the typing of G by using the type of a node n ∈ nodes(G) that corresponds to the IRI constructor used to construct n. We prove that G ∈ L C (S). Let G S be the shape graph of S. By definition, a graph G |= S if there is an embedding R from G in G S . We construct a relation R and show it is an embedding.Let R = {(n, T ) ∈ nodes(G) × nodes(G S ) | T ∈ typing(n)}.We take two nodes n ∈ nodes(G) and T ∈ nodes(G S ) and show there is a witness of simulation of n by T . Take (n, p, m) ∈ out G (n). By construction of shape expressions of minimal and maximal models, we know there is a triple constraint with the predicate label p and the type of the target node i.e., p :: T µ ∈ δ(T ) for some µ multiplicity and some T the target type of m. Thus, (T, (p, µ), T ) ∈ G S . Then, we define the function λ : out G (n) → out G S (T ). Because we have constructed implicitly the types of G, then for every outgoing edge of n there is an outgoing edge in out G S (T ). Because T ∈ typing(m), (m, T ) ∈ R.

  So we have two possible cases one corresponding the lower bound and the other corresponding the upper bound 1. {0, . . .} ⊆ {1, . . .} 2. {1, 2, . . .} ⊆ {1}

Figure 6

 6 Figure 6.8: An example of ER diagram.

  By rel -schema(ER), we denote the standard function of constructing a relational schema from a ER diagram presented in Example 6.5.1. Formally, rel -schema(ER) = (R, attrs, Σ fd , Σ ind ) where• R = {R E | ∃E ∈ Ent. } ∪ {R r | ∃r ∈ Rel . orient(r) ∈ { , }} . • For every E ∈ Ent, there is R E ∈ R such that if there is no r ∈ Rel such that src(r) = E and orient(r) = , then attrs(R E ) = attr (E).if there exists r ∈ Rel such that src(r) = E and orient(r) = , thenattrs(R E ) = attr (E) ∪ {key(E ) | r ∈ Rel . orient(r) = , src(r) = E, tgt(r) = E }.• the set of functional dependencies isΣ fd = {R E : A → B | ∃E ∈ Ent. ∃r ∈ Rel . src(r) = E, orient(r) = , A = key(E), B = attr (E)} ∪ {R E : A → B | ∃E ∈ Ent. ∀r ∈ Rel . src(r) = E, orient(r) = , A = key(E), B = {key(E ) | r ∈ Rel . orient(r) = , src(r) = E, tgt(r) = E }} ∪ {R r : A → A | ∃r ∈ Rel . orient(r) = , A = key(E 1 ) ∪ key(E 2 )} ∪{R r : A → B | ∃r ∈ Rel . orient(r) = , A = key(E 1 ), B = key(E 2 )}

  B] | ∃r ∈ Rel . orient(r) ∈ { , }, src(r) = E 1 , tgt(r) = E 2 , A = key(E 1 ), B = key(E 2 )} ∪ {R E 1 [A] ⊆ R E 2 [A] | ∃r ∈ Rel . orient(r) = , src(r) = E 1 , tgt(r) = E 2 , A = key(E 2 )}We introduce a function, denoted by mapping that takes an ER diagram and returns a schema mapping from relational schema to graphs. By mapping(ER), we denote the set of mappings constructed from an ER diagram. In this function, the set of IRI constructors is defined as F = {f E | E ∈ Ent}. First, we construct its relational schema and the construction of the set of mappings is as follows. For every E ∈ Ent, we assign a unique IRI constructor f E and let R E ∈ R be the corresponding relation to E of the form R E (x, a 1 , . . . , a n , y 1 , . . . , y k ) where • x corresponds to the primary key,

  δ(T E ) = {a :: Lit | a ∈ attr (E)} ∪ {r :: T 1 E | r ∈ Rel , src(r) = E, tgt(r) = E , orient(r) = } ∪ {r :: T * E | r ∈ Rel , src(r) = E, tgt(r) = E , orient(r) = } ∪ {r :: T ? E | r ∈ Rel , src(r) = E, tgt(r) = E , orient(r) = }Now, we claim the following theorem.Theorem 6.5.2. For any flat ER diagram ER, let F be defined in mapping(ER) and letE ER d = (rel -schema(ER), mapping(ER), F), it holds that ER.1 M3 on E ER d returns sh-schema(ER),ER.2 sh-schema(ER) is a sound and complete shapes schema for E ER d .

•

  Not satisfying key constraints. It implies that 1. we have {R(d, a 1 , . . . , a m ), R(d, b 1 , . . . , b m )} ⊆ I for some a 1 , . . . , a m ∈ Const, b 1 , . . . , b m ∈ Const and d ∈ Const such that for every i ∈ {1, . . . , m},it holds that a i = b i , and 2. there is R(x, a 1 , . . . , a m , y 1 , . . . , y k ) in the relational schema where x is the key for R.Because x is a key in R and by definition of mapping(ER), x is used in some IRI constructor f ∈ F, then M3 obtains for T f a triple constraint a :: Lit 1 for some a ∈ attrs(R). From (1) and mapping(ER), there is mapping with IRI constructor f assigned to R and predicate a in its triple atom. Because I is obtained by applying backwards the mappings, G contains at least the triples {(f (d), a, a k ), (f (d), a, b k )} for some k ∈ {1, . . . , m}. Since G ∈ L C (S) and the shape definition for T f has a :: Lit 1 , then G |= S; a contradiction. • Not satisfying a foreign key. It implies that for a fact in I such as the following R(d, a 1 , . . . , a n , b 1 , . . . , b k ) ⊆ I, there is no fact with P (b l , c 1 , . . . , c m ) ⊆ I for some d ∈ Const, some vector of constants b l and some constants c 1 , . . . , c m where l ∈ {1, . . . , k} and there is an inclusion dependency R[b k ] ⊆ P [b k ].

  Given a flat ER diagram ER, we introduce a class of relational schemas that char-acterizes rel -schema(ER). A relational schema R = (R, attrs, Σ fd , Σ ind ) is flat if for every R ∈ R, it holds that• for every fd of the form R : A → B in Σ fd for some A ⊆ attrs(R), it holds that B = attrs(R),• for every inclusion dependency of the form R[A] ⊆ P [B] for some P ∈ R, A ⊆ attrs(R), B ⊆ attrs(P ), we have that -B is the primary key of P ,if A ⊆ K where K is the primary key of R, then there is a relation Q ∈ R such that the set E = attrs(R) \ A has an inclusion dependency of the form R[E] ⊆ Q[E ] for some E ⊆ attrs(Q),there is no inclusion dependency of the form P[B] ⊆ R[A].

  Figure 6.9: A relational schema.

f

  Figure 6.10: Graphs recognized by L C (S).

  There are cases where these new attribute values depend on the source instance such as transformation or extraction of attribute values or a set of attribute values. The representation of such transformation or extraction is done by the help of function names. If the function creates fresh values that depend on the set of all attributes then the function is called Skolem function. We illustrate the use of function names with the next example.

		Author
	Id	Name	Country
	1 Jose Lozano	⊥ 1
	2 Edith Tupac	⊥ 1
	3	Steve	⊥ 1
	4	Bernard	⊥ 1
	5	Lucia	⊥ 1
		Conference
	Name Year	BookTitle	Place
	ICDT 2019	⊥ 2	Lille
	ISWC 2019	⊥ 3	Chile
	AMW 2015 Proc. AMW Cuba
			Publication
	IdAuthor	Title	BookTitle
	1	Tutoring Web math platform	⊥ 2
	1	Skolemization of prenex formulas	⊥ 2
	2	On algebraic connectivity of graphs	⊥ 3
	3	On algebraic connectivity of graphs	⊥ 3
	4	Tutoring Web math platform	⊥ 2
	5	Skolemization of prenex formulas	⊥

Example 1.3.2. Consider the target instance of Example 1.4 as the source database for a new data exchange setting. The target schema of this data exchange setting contains 2 Figure 1.4: Example of a solution. only the relation Book, which stores a list of books with the attributes: id, title, country key abbreviated by ck and editor. The rule for transformation is that every conference is mapped to a book where:

  ⊥ 3 , Chile) fe257fa3467 Proc. AMW 53 f ed(AMW, 2015, Proc. AMW, Cuba)

	Id	Name	Ck	Editor
	422f7196b35	⊥ 2	33	f ed (ICDT, 2019, ⊥ 2 , Lille)
	9d1a8988af4	⊥ 3	56	f ed (ISWC, 2019,

  Publication(x 1 , x 6 , y 2 )

				Researcher
	Idr		Name	Email Expertise Team
	1 Jose Lozano j@s.fr	Math	ALG
	3		Steve	s@s.fr Algebra ALG
				Talk
	Idr Idc		Title
	1	1		Tutoring Web math platform
	1	1	Skolemization of prenex formulas
	3	2 On algebraic connectivity of graphs
				Researcher	Talk
	x 1

  Conference(ICDT, 2019, ⊥ 13 , Peru) is mapped to Conference(ICDT, 2019, ⊥ 2 , Peru) by h(⊥ 13 ) = ⊥ 2 . Then all tuples of Author from J are mapped to J 1 . For instance, the tuple Author(3, Steve, ⊥ 11 ) is mapped to Author(3, Steve, ⊥ 1 ) by h(⊥ 11 ) = ⊥ 1 .

  ) ∃x 1 , x 2 , x 3 , x 4 , x 5 . Author(x 1 , Steve, x 2 ) ∧ Conference(ISWC, 2019, x 3 , x 4 ) ∧ Publication(x 1 , x 5 , x 3 ) asking if Steve has a publication in an ISWC conference, and (Q 3 ) ∃x 1 , x 2 , x 3 , x 4 , x 5 , x 6 . Author(x 1 , Jose Lozano, x 2 ) ∧ Author(x 3 , 'Bernard, x 4 ) ∧ Publication(x 1 , x 5 , x 6 ) ∧ Publication(x 3 , x 5 , x 6 ) asking if authors Jose Lozano and Bernard have co-authored the same publication.

	Consider the following Boolean queries:
	(Q 2
			.1 w.r.t. data exchange setting E 0 in Example 1.3.1.
	Consider the query Q 1 (y) = ∃x 1 , x 2 , x 3 . Conference(y, x 1 , x 2 , x 3 ) asking what are the
	names of the conferences. In fact, we see that the certain answers are (ICDT) and
	(ISWC). An example of not certain answer is AMW.
	Query	Solution J 1	J
		Q 1	{(ICDT), (ISWC), (AMW)} {(ICDT), (ISWC),
				(⊥ 15 ), (⊥ 18 ), (⊥ 21 )}
			Figure 1.13: Answers to queries Q 1 in solutions J 1 and J.

Table 1

 1

	.1.
	"29" "University of Lille" e x : a g e	e x : w o r k s I n ulille:name	ulille:	e x : w o r k s I n ex:address	:b 1	ex:city e x : z ip	"59000" "Lille"
	"Jose Lozano"	foaf:name	ulille:jlozano	foaf:knows	ulille:etupac	foaf:name	"Edith Tupac"
	dbp:Mathematics e x : m a s t e r s "j@s.fr" fo a f: m b o x	dbp:Logic ex :m as te rs	"Tree automata for infinite trees" e x : m a s t e r s ex :a ut ho rs	e x : a u t h o r s
		ex:name	ex:name	"Containment problem for Register Automata"
		"Math"	"Logic"
		Figure 1.17: An RDF graph where prefixes are in Table1.1.
	ulille:jlozano
	foaf:name "Jose Lozano";
	ex:masters dbp:Mathematics , dbp:Logic;
	foaf:mbox "j@s.fr" ;
	foaf:age "29";
	ex:worksIn ulille:;
	foaf:homepage _:b.

  Lit 1

	ShAddress → ex:city :: Lit 1 ;
	ex:zip :: Lit 1
	ShUniversity → ex:name :: Lit 1 ;
	ex:address :: ShAddress 1
	ShResearcher → foaf:name :: Lit 1 ;
	foaf:knows :: ShResearcher * ;
	ex:masters :: ShTopic + ;
	ex:authors :: Lit * ;
	ex:worksIn :: ShUniversity 1 ;
	foaf:mbox :: Lit ?

Table 1 .

 1 1 and the rest of an IRI is a name, but in the abstract formalism for ease of notation, we use only the name.

	ex:ShTopic{
	ex:name xsd:Lit
	}
	ex:ShAddress{
	ex:city xsd:Lit;
	ex:zip xsd:Lit
	}
	ex:ShUniversity{
	ulille:name xsd:Lit;
	ex:address @ex:ShAddress
	}
	ex:Researcher{
	foaf:name xsd:Lit;
	foaf:knows @ex:Researcher * ;
	foaf:mbox xsd:Lit ?;
	ex:authors xsd:Lit * ;
	ex:worksIn @ex:University;
	ex:masters @ex:Topic +
	}
	Figure 1.22: Example of schema for RDF written in ShEx where prefixes are described
	in Table 1.1.

  2.3.1. Consider the data exchange setting of Example 2.1.1. There is no solution for this instance in Figure 2.6a w.r.t. the data exchange setting. Therefore, this setting is not consistent. The problem springs from two tuples with ICDT name

	Conference
	Idc Name Year Place
	1 ICDT 2019 Lille
	2 ICDT 2019 Chile

  and only if there is a violation in the core pre-solution to I w.r.t. E.

Proposition 3.2.6. For any instance Iof R, there is a violation sort (T, f, p) such that there exist π, σ, σ , h s.t. (T, f ) is accessible with path π in E, σ, σ are contentious sttgds with (T, f, p) and h : I π,σ,σ → I is a homomorphism if and only if there exist a

  p 6 ∼ p 9 , p 7 ∼ p 10 , p 13 ∼ p 16 , p 14 ∼ p 17 , p 20 ∼ p 23 , p 21 ∼ p 24 , p 18 ∼ p 19 , p 19 ∼ p 22 , p 4 ∼ p 5 , p 5 ∼ p 8 , p 8 ∼ p 12 , p 12 ∼ p 15 . Now, for each set of output places we compute the

	move function(cf. Section 4.2.1):
	Move(Σ

S , Out(σ 2 , y)) = {p 7 , p 11 } Move(Σ S , Out(σ 4 , y)) = {p 14 , p 18 , p 20 , p 25 } Move(Σ S , Out(σ 6 , y)) = {p 21 , p 25 }

Then we compare each two rules σ, σ ∈ Σ S and if for every universal variable in σ there is an existential variable y in σ such that In(σ , x) ⊆ Move(Σ S , Out(σ, y)), we say that σ triggers σ . We obtain the following trigger relations: σ 4 σ 5 ,σ 6 σ 7 and

  t. I and E by testing existence of homomorphism of Q in the finite structure. Using the results in data complexity of Calì et al., we claim in the following proposition that data complexity of computing certain answers to BCQs w.r.t. E is P-complete. Proposition 4.2.5. For any data exchange setting E and for any instance I of R, the data complexity of computing certain answers to Boolean conjunctive queries w.r.t. I

and E is P-complete.

  adapted the notion of simulation to graphs as the relation between two graphs G and H such for every node n ∈ nodes(G) there is a node m ∈ nodes(H) such that every outgoing edge from n has a corresponding outgoing edge from m. In the context of RDF graphs, nodes are labeled and there are two kind of nodes IRIs and literals. Thus, we need to do the following adaptation. Two nodes with different IRIs or literal values are distinguishable and they cannot be simulated one another. Also an IRI cannot simulate a literal and vice-versa. Only blank node can simulate an IRI and null-literal node can simulate a literal value.

Definition 4.3.1. A simulation of a graph G by a graph H is a relation

  The set of simulations of G in H is closed under union, and consequently, there exists exactly one maximal simulation of G in H. When both G and H are known from the context, we denote the maximal Nested regular expressions (NREs) are regular expressions that use concatenation •, union +, Kleene's closure * , inverse -, and permit nesting and testing node and edge labels. Formally, NREs are defined with the following grammar:

	4.3. SIMULATION-BASED APPROACH	123
	Nested regular expressions

simulation of G in H by , we use it as an infix relation symbol, and we say that n is simulated by m if n m. Finally, we say that G is simulated by H if every node of G is simulated by a node of H.

  and is a distinguished wildcard predicate symbol. A NRE E defines a binary relation E G on nodes of a graph G as follows.

  H . For the second case, applying the induction hypothesis on E 1 , there is a m ∈ nodes(H)such that (m, m ) ∈ E 1 H and n m . Thus, (m, m ) ∈ E H . For the third case, (n, n ) ∈ E 1 G • E 1 G . It was proven for operator • that there is m ∈ nodes(H) such that (m, m ) ∈ E 1 H • E 1 H and n m , then (m, m ) ∈ E H .For the fourth case and rest of cases until k, we are going to have the composition of E 1 G for k times i.e., E 1

G , that there is m ∈ nodes(H) such that (m, m ) ∈ H and n m , consequently, (m, m ) ∈ E 1 * H . Thus, (m, m ) ∈ E

  a sub expression of E and by proof of •, we have that there ism ∈ nodes(H) such that (m, m ) ∈ E 1 H • E 2 H and n m . Thus, (m, m ) ∈ E H . 2. E = [E 1 ]. By semantics of [],there is an m ∈ nodes(G) and (n, m ) ∈

E 1 G . Applying induction hypothesis on E 1 , there is m ∈ nodes(H) such that (m, m ) ∈ E 1 H and m m . By (m, m ) ∈ E 1 H , (m, m) ∈ [E 1 ] H . Thus, we conclude that (m, m) ∈ E H . Next, we show that if G |= E then H |= E.

Take any two graphs G and H instances of G. Assume G H and G |= E. By definition of G |= E, E G = ∅, and in consequence there is a pair (n, n ) ∈ E G . By G H, there is a node m ∈ nodes(H) such that n m. By Claim 4.3.1.1, n m and (n, n ) ∈ E G , there is a node m ∈ nodes(H) such that (m, m ) ∈ E H . Since E H = ∅, then H |= E. This ends the proof.

  Theorem 4.3.10. The data complexity of computing certain answers to forward NREbased queries w.r.t. E is in PTIME.Proof. Take a forward NRE-based query E and an instance I of R. It is known in[Pérez

et al. 2010] that the evaluation of a query E in a graph G is polynomial in the size of the graph i.e., O(|G| • |E|). Here the forward NRE E is evaluated in a minimal universal simulation solution U 0 to I w.r.t. E. By proof of Theorem 4.3.8, the size of E is linear in the size of S and constructing U 0 is tight. Since S is fixed, then deciding to evaluate a forward NRE in U 0 is in PTIME.

  is a R2RML editor that uses YAML[Ben-Kiki et al. 2009] to write R2RML mappings. YAML is a data serialization language that simplifies the elements of R2RML syntax to be more human friendly. Visual representations are not used in YARRRML.

	Tools	VML Text-	VR for	Mapping	Target	Solution
			based	schemas	overview	con-
			lan-			straints
			guage
	RDOTE	No	D2RQ	No	No	No	Yes
	Sengupta et al. No	R2RML No	No	No	Yes
	RML editor	Yes	R2RML No	Yes	No	Yes
	SQuaRE	No	R2RML Yes	Yes	No	Yes
	Map-On	Yes	R2RML Yes	Yes	No	Yes
	YARRRML	No	R2RML No	No	No	Yes
	ShERML	Yes	R2VML Yes	Yes	Yes	Yes
			Table 5.3: Summary of tool features.

  .2b.Formally, two graphs G and G are isomorphic, denoted by G ∼ = G , if there is a bijective homomorphism from G to G . Also, for two set of graphs G and H, we write G ⊆ iso H iff for any graph G ∈ G, there is a graph G ∈ H such that G and G are isomorphic. Now, we can formally state the two desirable properties as follows.

				Emp	Sup	Sys	Access
	G 0 : ex:a dmin	emp 1 e x : n a m e ex:sup Spes emp 2 ex:sup sys 1 ex:access e x : a c c e s s	1 jose 2 edith	2 1 2 2	1 Spes Σ st	1 1 2 1
		ex:name	ex:name
		jose	edith		univ:emp#1
		Definition 6.2.5. Given a schema-less data exchange setting E d , a target schema is

  Proposition 6.3.4. Let m be the maximum number of atoms in a st-tgd in Σ st . Let n be the number of inclusion dependencies of Σ ind . Let k be the maximum arity of a relational name in R. Given an instance I bounded by m, the localized chase can be done in polynomial time in n • k + m and its result is bounded by n • k + m.Proof. Take an instance I of R bounded by m, which is the maximum number of atoms in a st-tgd in Σ st . Let n be the number of inclusion dependencies. The localized chase tests if a dependency is triggered at most n number of times because we do no trigger any inclusion dependency more than once. At each chase step, we add at most one atom, which varies in the arity of a head of the dependency. This arity is bounded by the maximum arity of a relational name in R. Therefore, the result of the localized chase is bounded by n • k + m. Also, at each step by Proposition 6.3.3, we require a polynomial time in the size of I. Then, the localized chase is in polynomial time in n • k + m.

https://jena.apache.org/

https://ontop-vkg.org/

Acknowledgements

cessfully all through the endeavour.

This research benefits from the support of the Région Hauts-de-France by a grant from CPER Nord-Pas de Calais/FEDER DATA Advanced data science and technologies 2015-2020 and by the ANR project DataCert ANR-15-CE39-0009.

Last but not least, I would be glad to thank my dear parents, Nilda and Walter,

CHAPTER 5. VISUAL MAPPING LANGUAGE <https://example.com/ShBug/1> <https://example.com/descr> "Boom!"; <https://example.com/rep> <https://example.com/ShUser/1>. <https://example.com/ShBug/2> <https://example.com/descr> "Kabang"; <https://example.com/rep> <https://example.com/ShUser/1>. <https://example.com/ShBug/3> <https://example.com/descr> "Bang!"; <https://example.com/rep> <https://example.com/ShUser/2>. <https://example.com/ShUser/1> <https://example.com/name> "Jose"; <https://example.com/email> "j@ex.com"; <https://example.com/tracks> <https://example.com/ShBug/2> , <https://example.com/ShBug/1>. <https://example.com/ShUser/2> <https://example.com/name> "Edith"

; <https://example.com/email> "@@@"; <https://example.com/tracks> <https://example.com/ShBug/@@@>. <https://example.com/ShBug/@@@> <https://example.com/descr> "@@@"; <https://example.com/rep> <https://example.com/ShUser/@@@>. <https://example.com/ShUser/@@@> <https://example.com/name> "@@@"; <https://example.com/email> "@@@"; <https://example.com/tracks> <https://example.com/ShBug/@@@>.

CHAPTER 5. VISUAL MAPPING LANGUAGE the relational schema R, the shapes schema S, the set of st-tgds Σ st and the set of IRI constructors, and gives as output a Boolean value. True if the setting is consistent, false otherwise. The algorithm is as follows. For any two rules in Σ st , if both rules use the same IRI constructor f for their subjects and have the same predicate, the same subject type T and there is a type S ∈ T such that p :: S µ ∈ δ(T ) with µ = 1 or µ = ?, then an instance I is constructed similarly as a contentious-based instance (line 3 to 5). Then, the algorithm chases I with the set of functional dependencies (line 6). Finally, the algorithm checks if the result of the chase has equated two different values (line 7), and if so, the algorithm finishes with a false value. If the algorithm ends without equating two values (line 7), then the setting is consistent.

Algorithm 4: Deciding consistency in ShERML.

Input: a data exchange setting The output of M3 with this schema-less data exchange setting composed of the relational schema obtained above, the set of mappings obtained from the ER diagram, and the IRI constructors assigned to the entities, is the following shapes schema.

T Proj → id :: Lit 1 ; title :: Lit 1 ; manages :: T 1 Sup ; oversees :: T * Sup .

T Sup → id :: Lit 1 ; name ::

This shapes schema is a complete schema.

Our claim holds for a subclass of ER diagrams, which we introduce next. An entityrelation (ER) diagram is a graphical language used to design databases. This language uses entities and relations. A entity is a class of objects of the same type. An object is described by a set of attributes, where a subset of them is used to identify the object within the class. A relationship connects two entities E 1 and E 2 . We distinguish three types of relationship: many-to-many relationship, many-to-one relationship, and manyto-one with referential integrity constraint. The first type indicates that an object of E 1 can be related with many objects of E 2 and vice-versa. The second type indicates that two objects of E 2 cannot be related with the same object of E 1 . The third type indicates that an object of E 1 must be related with an object of E 2 and at most one.

We assume an infinite set of names N. We identify the set of entity names Ent ⊆ N, the set of attribute names A ⊆ N and the set of relation names Rel ⊆ N. We assume that these sets are pairwise disjoint. Formally, a flat ER diagram is a tuple ER = (Ent, Rel , src, tgt, attr , key, orient) where

• Ent is the set of entities, which are the set of nodes,

• Rel is the set of edges,

• src : Rel → Ent and tgt : Rel → Ent identify respectively, the origin entity of the relationship and the end entity of the relationship,

• attr : Ent → 2 A assigns to an entity a finite set of attributes, E ER d = (rel -schema(ER), mapping(ER), F) where F is defined in mapping(ER) is flat.

The following theorem follows from Theorem 6.5.2.

Theorem 6.5.3. M3 is sound and complete elicitation algorithm for every flat schemaless data exchange setting obtained from flat ER diagram.

Negative results

It is possible to conceive an algorithm that is complete for a larger class of schema-less data exchange settings. However, in this section, we present two results that identify the inherent limitations of the task of producing a sound and complete schema. First, we

show that a sound and complete output may be exponential.

Theorem 6.6.1. For any n ∈ N, there exists a relational schema and set of mappings of size polynomial in n such that the complete target schema has at least 2 n -1 types.

Proof. For n ∈ N, we construct a relational schema R n with n + 1 relations R = {R(x), P 1 (x, y 1 , y 2 ), . . . , P n (x, y 1 , y 2 )} with the indicated key constraint and n inclu-

for i ∈ {1, . . . , n} and some f ∈ F.

Suppose we have a sound and complete schema S and assume by contradiction that S has less than 2 n -1 types. We take a enumeration (X 1 , . . . , X 2 n -1 ) of the collection P({1, . . . , n})\{∅} of non-empty subsets of {1, . . . , n}. Then, we construct an instance as follows:

Applying the mappings, we obtain a graph G with 2 n IRI nodes n 1 , . . . , n 2 n such that

Now, we type the set of nodes of G against S. Because S has less than 2 n -1 types, there are two nodes n i and n j that has the same type T where i = j for some 6.6. NEGATIVE RESULTS i, j ∈ {1, . . . , 2 n -1}. We know X i ÷ X j = ∅ because i = j. We observe that for l ∈ X i ∩ X j , both n i and n j have outgoing edges labeled with both p l and q l . Therefore, the type T has in its shape definition for any l ∈ X i ∩ X j , p l :: Lit µ for some µ ∈ {+, ?} and q l :: Lit µ for some µ ∈ {+, ?}. On the other hand, we observe that for any l ∈ X i ÷ X j , one of the nodes n i or n j has two outgoing edges p l , q l while the other has none. Therefore, the type T has in its shape definition for any l ∈ X i ÷ X j , p l :: Lit µ for some µ ∈ {?, *} and q l :: Lit µ for some µ ∈ {?, *}.

Since X i ÷ X j = ∅, we choose l ∈ X i ÷ X j and construct a graph G such that there is a node m ∈ nodes(G ) that has the common parts from nodes n i , n j ∈ nodes(G) and one outgoing edge with p l and no outgoing edge with q l . More precisely, we obtain

We observe that m has type T and, therefore, G ∈ L C (S). Since the shapes schema is complete, then there must exist an instance such that application of Σ st produces an isomorphic graph to G . We evaluate the rules that can be triggered to produce G and must contain at least the following set of facts.

for some c ∈ Const. We observe that the set of facts {R(c), P l (c, a, ⊥)} triggers the rule R(x) ∧ P l (x, y 1 , y 2 ) ⇒ Triple(f (x), q l , y 2 )

causing that m has an outgoing edge from with label q l i.e., when applying the mappings we obtain a graph G different from G . Contradiction, the shapes schema needs to have at least 2 n -1 types.

Next, we show that a sound and complete schema may not exist.

Theorem 6.6.2. There is a schema-less data exchange setting E d that does not admit a complete target schema w.r.t. E d .

Proof. Let the relational schema be presented in Figure 6.9 and the set of mappings Σ st