1 Introduction
Data exchange can be seen as a process of transforming an instance of one schema, called the source schema, to an instance of another schema, called the target schema, according to a set of rules, called sourcetotarget tuple generating dependencies (sttgds). But more generally, for a given source schema, any instance of the target schema that satisfies the dependencies is a solution to the data exchange problem. Naturally, there might be no solution, and then we say that the setting is inconsistent. Conversely, there might be a possibly infinite number of solutions, and a considerable amount of work has been focused on finding a universal solution, which is an instance (potentially with incomplete information) that represents the entire space of solutions. Another fundamental and wellstudied problem is checking consistency of a data exchange setting i.e., given the source and target schemas and the sttgds, does a solution exist for any source instance. For relational databases the consistency problem is in general known to be undecidable [13, 6] but a number of decidable and even tractable cases has been identified, for instance when a set of weaklyacyclic dependencies is used [10].
Resource Description Framework (RDF) [2] is a wellestablished format for publishing linked data on the Web, where triples of the form allow to represent an edgelabeled graph. While originally RDF was introduced schemafree to promote its adoption and widespread use, the use of RDF for storing and exchanging data among web applications has prompted the development of schema languages for RDF [17, 19, 3]. One such schema language, under continuous development, is Shape Expressions Schemas (ShEx) [20, 8], which allows to define structural constraints on nodes and their immediate neighborhoods in a declarative fashion.
In the present paper, we study the problem of data exchange where the source is a relational database and the target is an RDF graph constrained with a ShEx schema. Although an RDF graph can be seen as a relational database with a single ternary relation , RDF graphs require using Internationalized Resource Identifiers (IRIs) as global identifiers for entities. Consequently, the framework for data exchange for relational databases cannot be directly applied as is and we adapt it with the help of IRI constructors, functions that assign IRIs to identifiers from a relational database instance. Their precise implementation is out of the scope of this paper and belongs to the vast domain of entity matching [14].
Example 1
Consider the relational database of bug reports in Figure 1, where the relation Bug stores a list of bugs with their description and ID of the user who reported the bug, the name of each user is stored in the relation User and her email in the relation Email. Additionally, the relation Rel identifies related bug reports for any bug report.
Bug  bid  descr  uid 

1  Boom!  1  
2  Kaboom!  2  
3  Kabang!  1  
4  Bang!  3 
User  uid  name 

1  Jose  
2  Edith  
3  Steve89 
uid  

1  j@ex.com  
2  e@o.fr 
Rel  bid  rid 

1  3  
1  4  
2  4 
Now, suppose that we wish to share the above data with a partner that has an already existing infrastructure for consuming bug reports in the form of RDF whose structure is described with the following ShEx schema (where is some default prefix):
The above schema defines two types of (nonliteral) nodes: for describing bugs and for describing users. Every bug has a description, a user who reported it, and a number of related bugs. Every user has a name, an email, and an optional phone number. The reserved symbol indicates that the corresponding value is a literal.
The mapping of the contents of the relational database to RDF is defined with the following logical rules (the free variables are implicitly universally quantified).
On the lefthandside of each rule we employ queries over the source relational database, while on the righthandside we make corresponding assertions about the triples in the target RDF graph and the types of the nodes connected by the triples. The atomic values used in relational tables need to be carefully converted to IRIs with the help of IRI constructors pers2iri and bug2iri. The constructors can be typed i.e., the IRI they introduce are assigned a unique type in the same sttgd.
We point out that in general, IRI constructors may use external data sources to properly assign to the identifiers from the relational database unique IRIs that identify the object in the RDF domain. For instance, the user Jose is our employee and is assigned the corresponding IRI , the user Edith is not an employee but a registered user of our bug reporting tool and consequently is assigned the IRI , and finally, the user Steve89 is an anonymous user and is assigned a special IRI indicating it .
Figure 2 presents an RDF instance that is a solution to the problem at hand. We point out that the instance uses a (labeled) null literal for the email of Steve89 that is required by the ShEx schema but is missing in our database.∎
The presence of target schema raises the question of consistency. On the one hand, we can prove that for any instance of the relational database in Example 1 there exists a target solution that satisfies the schema and the set of sourcetotarget tuple generating dependencies. On the other hand, suppose we allow a user to have multiple email addresses, by changing the key of Email to both and ). Then, the setting would not be consistent as one could construct an instance of the relational database, with multiple email addresses for a single user, for which there would be no solution.
Our investigation provides a preliminary analysis of the consistency problem for relational to RDF data exchange with target ShEx schema. Our contribution can be summarized as follows:

a formalization of relational to RDF data exchange with target ShEx schema and typed IRI constructors.

a decidable characterization of a fullytyped keycovered data exchange setting that is a sufficient and necessary condition for consistency.

an additional restriction of weakrecursion on ShEx schemas that ensures the existence of universal solution.
Related Work. Relational Data Exchange, Consistency. The theoretical foundations of data exchange for relational databases are laid in [10, 4]. Sourcetotarget dependencies with Skolem functions were introduced by nested dependencies [11] in order to improve the quality of the data exchange solution. General existentially quantified functions are possible in second order tgds [5]. 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. The consistency criterion that we identify in this paper is orthogonal and is particular to the kind of target constraints imposed by ShEx schemas. In [15], static analysis is used to test whether a target dependency is implied by a data exchange setting, these however rely on chase termination. Consistency is an important problem in XML data exchange [4] but the techniques developed for XML do not apply here.
Value Invention, Relational to RDF Data Exchange. Value invention is used in the purely relational setting for generating null values. Tools such as Clio [9] and ++Spicy [16] implement Skolem functions as concatenation of their arguments. IRI value invention is considered by R2RML [1], a W3C standard for writing customizable relational to RDF mappings. The principle is similar to what we propose here. A R2RML mapping allows to specify logical tables (i.e. very similar to lefthandsides of sourcetotarget dependencies), and then how each row of a logical table is used to produce one or several triples of the resulting RDF graph. Generating IRI values in the resulting graph is done using templates that specify how a fixed IRI part is to be concatenated with the values of some of the columns of the logical table. R2RML does not allow to specify structural constraints on the resulting graph, therefore the problem of consistency is irrelevant there. In [18], a direct mapping that is a default automatic way for translating a relational database to RDF is presented. The main difference with our proposal and with R2RML is that the structure of the resulting RDF graph is not customizable. In [7] we studied relational to graph data exchange in which the target instance is an edge labelled graph and sourcetotarget and target dependencies are conjunctions of nested regular expressions. Such a framework raises a different kind of issues, among which is the materialization of a solution, as a universal solution is not necessarily a graph itself, but a graph pattern in which some edges carry regular expressions. On the other hand, IRI value invention is not relevant in such framework.
Organization. In Section 2 we present basic notions. In Section 3 we show how ShEx schemas can be encoded using target dependencies. In Section 4 we formalize relational to RDF data exchange. In Section 5 we study the problem of consistency. And finally, in Section 6 we investigate the existence of universal solutions. Conclusions and directions of future work are in Section 7.
2 Preliminaries
Firstorder logic.
A relational signature (resp. functional signature ) is a finite set of relational symbols (resp. functional symbols), each with fixed arity. A type symbol is a relational symbol with arity one. A signature is a set of functional and relational symbols. In the sequel we use , resp. , resp. for sets of relational, resp. functional, resp. type symbols.
We fix an infinite and enumerable domain partitioned into three infinite subsets of IRIs, literals, and blank nodes respectively. Also, we assume an infinite subset of null literals. In general, by null values we understand both null literals and blank nodes and we denote them by .
Given a signature , a model (or a structure) of is a mapping that with any symbol in associates its interpretation s.t.:

for any relational symbol of arity ;

, which is a total function for any function symbol of arity .
We fix a countable set of variables and reserve the symbols for variables, and the symbols , ,
for vectors of variables. We assume that the reader is familiar with the syntax of firstorder logic with equality and here only recall some basic notions. A
term over is either a variable in , or a constant in , or is of the form where and the length of is equal to the arity of ; we remark that we do not allow nesting of function symbols in terms. A dependency is a formula of the form and in the sequel, we often drop the universal quantifier, write simply , and assume that implicitly all free variables are universally quantified.The semantics of firstorder logic formulas is captured with the entailment relation defined in the standard fashion for a model , a firstorder logic formula with free variables and a valuation . The entailment relation is extended to sets of formulas in the canonical fashion: iff for every .
Relational Databases.
We model relational databases using relational structures in the standard fashion. For our purposes we are only concerned with functional dependencies, which include key constraints. Other types of constraints, such as inclusion dependencies and foreign key constraints, are omitted in our abstraction.
A relational schema is a pair where is a relational signature and is a set of functional dependencies (fds) of the form , where is a relational symbol of arity , and . An fd is a short for the following formula . An instance of is a model of and we say that is valid if . The active domain of the instance is the set of values from that appear in for some relational symbol in . Unless we state otherwise, in the sequel we consider only instances that use only constants from .
RDF Graphs and Shape Expressions Schemas.
Recall that an RDF graph, or graph for short, is a set of triples in . The set of nodes of the graph is the set of elements of that appear on first or third position of a triple in .
We next define the fragment of shape expression schemas that we consider, and that was called in . Essentially, a ShEx is a collection of shape names, and each comes with a definition consisting of a set of triple constraints. A triple constraint indicates a label of an outgoing edge, the shape of the nodes reachable with this label, and a multiplicity indicating how many instances of this kind of edge are allowed. We remark that the constraints expressible with this fragment of ShEx, if nonrecursive, can also be captured by a simple fragment of SHACL with and operator only.
Formally, a multiplicity is an element of with the natural interpretation: is exactly one occurrence, stands for none or one occurrence, stands for an arbitrary number of occurrences, and stands for a positive number of occurrences. A triple constraint over a finite set of shape names is an element of , where is an additional symbol used to indicate that a node is to be a literal. Typically, we shall write a triple constraint as . Now, a shape expressions schema, or ShEx schema for short, is a couple where is a finite set of shape names, and is shape definition function that maps every symbol to a finite set of triple constraints over such that for every shape name and for every IRI , contains at most one triple constraint using .
For a finite set of shape names, a typed graph is a couple where is a graph and is a mapping from the nodes of into that with every node of associates a (possibly empty) set of types. Let be a ShEx schema. The typed graph is correctly typed w.r.t. if it satisfies the constraints defined by i.e., for any node of :

if , then ;

if then and for every in we have that (1) for any triple in , belongs to , and (2) if is the set of triples in whose first element is and second element is , then the cardinality of is bounded by i.e., if , if , and if (there is no constraint if ).
For instance, a correct typing for the graph in Figure 2 assigns the type to the nodes , , , and ; the type to the nodes , , and ; and to every literal node.
3 ShEx Schemas as Sets of Dependencies
In this section we show how to express a ShEx schema using dependencies.
First, we observe that any typed graph can be easily converted to a relational structure over the relational signature , where is a ternary relation symbol for encoding triples, and are monadic relation symbols indicating node types (details in Appendix 0.A). Consequently, in the sequel, we may view a typed graph as the corresponding relational structure (or even a relational database over the schema ).
Next, we define auxiliary dependencies for any two and any
We point out that in terms of the classical relational data exchange, and are tuple generating dependencies (tgds), and is an equality generating dependency (egd). We capture the ShEx schema with the following set of dependencies:
Lemma 1
For every ShEx schema and every typed RDF graph , is correctly typed w.r.t. iff .
4 Relational to RDF Data Exchange
In this section, we present the main definitions for data exchange.
Definition 1 (Data exchange setting)
A relational to RDF data exchange setting is a tuple where is a source relational schema, is a target ShEx schema, is a function signature, as an interpretation for that with every function symbol in of arity associates a function from to , and is a set of sourcetotarget tuple generating dependencies, clauses of the form , where is a conjunction of atomic formulas over the source signature and is a conjunction of atomic formulas over the target signature . Furthermore, we assume that all functions in have disjoint ranges i.e., for if , then .
Definition 2 (Solution)
Take a data exchange setting , and let be a valid instance of . Then, a solution for w.r.t. is any typed graph such that and .
A homomorphism between two relational structures of the same relational signature is a mapping from to that 1) preserves the values of nonnull elements i.e., whenever , and 2) for every and every we have , where and is the arity of .
Definition 3 (Universal Solution)
Given a data exchange setting and a valid source instance , a solution for w.r.t. is universal, if for any solution for w.r.t. there exists a homomorphism .
As usual, a solution is computed using the chase. We use a slight extension of the standard chase (explained in the appendix) in order to handle function terms, which in our case is simple (compared to e.g. [5]) as the interpretation of function symbols is given.
5 Consistency
Definition 4 (Consistency)
A data exchange setting is consistent if every valid source instance admits a solution.
We fix a relational to RDF data exchange setting and let . We normalize sourcetotarget tuple generating dependencies so that their righthandsides use exactly one atom and at most two type assertions on the subject and the object of the triple; such normalization is possible as our sttgds do not use existential quantification. In this paper, we restrict our investigation to completely typed sttgds having both type assertions, and therefore being of the following form
where is the subject term, is the subject type, is the predicate, is the object term, and is the object type. Because the subject of a triple cannot be a literal, we assume that for and for , and . As for the object, we have two cases: 1) the object is an IRI and then for and for , and , or 2) the object is literal for and . Moreover, we assume consistency with the target ShEx schema i.e., for any sttgd in with source type , predicate , and object type we have for some multiplicity . Finally, we assume that every IRI constructor in is used with a unique type in . When all these assumptions are satisfied, we say that the sourcetotarget tuple generating dependencies are fullytyped.
While the sttgds in Example 1 are not fullytyped, an equivalent set of fullytyped dependencies can be easily produced if additionally appropriate foreign keys are given. For instance, assuming the foreign key constraint , the first rule with Bug on the lefthandside is equivalent to
Now, two sttgds are contentious if both use the same IRI constructor for their subjects and have the same predicate, hence the same subject type and object type , and with or . We do not want two contentious sttgds to produce two triples with the same subject and different objects. Formally, take two contentious sttgds and and assume they have the form (for , and assuming are pairwise disjoint)
The sttgds and are functionally overlapping if for every valid instance of
Finally, a dataexchange setting is keycovered if every pair of its contentious sttgds is functionally overlapping. Note that any single sttgd may be contentious with itself.
Theorem 5.1
A fullytyped data exchange setting is consistent if and only if it is keycovered.
The sole reason for the nonexistence of a solution for a source instance is a violation of some egd in . The keycovered property ensures that such egd would never be applicable. Intuitively, two egdconflicting objects and are necessarily generated by two contentious sttgds. The functionaloverlapping criterion guarantees that the terms and are “guarded” by a primary key in the source schema, thus cannot be different.
Theorem 5.2
It is decidable whether a fullytyped data exchange setting is keycovered.
The proof uses a reduction to the problem of functional dependency propagation [12].
6 Universal Solution
In this section, we identify conditions that guarantee the existence of a universal solution. Our results rely on the existence of a universal solution for sets of weaklyacyclic sets of dependencies for relational data exchange [10]. As the tgds and egds that we generate are driven by the schema (cf. Section 3), we introduce a restriction on the ShEx schema that yields weaklyacyclic sets of dependencies, and consequently, guarantees the existence of universal solution.
The dependency graph of a ShEx schema is the directed graph whose set of nodes is and has an edge if appears in some triple constraint of . There are two kinds of edges: strong edge, when the multiplicity , and weak edge, when . The schema is stronglyrecursive if its dependency graph contains a cycle of strong edges only, and is weaklyrecursive otherwise. Take for instance the following extension of the ShEx schema from Example 1:
The dependency graph of this schema, presented in Figure 3. contains two cycles but neither of them is strong. Consequently, the schema is weaklyrecursive (and naturally so is the ShEx schema in Example 1).
As stated above, a weaklyrecursive ShEx schema guarantees a weaklyacyclic set of dependencies and using results from [10] we get
Proposition 1
Let be a data exchange setting and be a valid instance of . If is weakly recursive, then every chase sequence of with is finite, and either every chase sequence of with fails, or every such chase sequence computes a universal solution of for .
7 Conclusion and Future Work
We presented a preliminary study of the consistency problem for relational to RDF data exchange in which the target schema is ShEx. Consistency is achieved by fullytyped and keycovered syntactic restriction of sttgds. An open problem that we plan to investigate is consistency when the fullytyped restriction is relaxed; we believe that it is achievable if we extend the definition of contentious sttgds. Another direction of research is to consider a larger subset of ShEx. Finally, we plan to extend our framework to typed literals which are not expected to bring fundamental difficulties but are essential for practical applications.
References
 [1] R2RML: RDB to RDF Mapping Language. W3C Recommendation 27 September 2012, http://www.w3.org/TR/r2rml/
 [2] RDF 1.1 Semantics. W3C Recommendation 25 February 2014, https://www.w3.org/TR/2014/RECrdf11mt20140225/
 [3] Shapes Constraint Language (SHACL). W3C Recommendation 20 July 2017, https://www.w3.org/TR/shacl/
 [4] Arenas, M., Barcelo, P., Libkin, L., Murlak, F.: Relational and XML Data Exchange. Morgan and Claypool Publishers (2010)
 [5] Arenas, M., Pérez, J., Reutter, J., Riveros, C.: The Language of Plain SOtgds: Composition, Inversion and Structural Properties. J. Comput. Syst. Sci. (2013)
 [6] Beeri, C., Vardi, M.Y.: The implication problem for data dependencies. In: Even, S., Kariv, O. (eds.) Automata, Languages and Programming (1981)
 [7] Boneva, I., Bonifati, A., Ciucanu, R.: Graph Data Exchange with Target Constraints. In: EDBT/ICDT Workshops  Querying Graph Structured Data (GraphQ) (2015)
 [8] Boneva, I., Labra Gayo, J.E., Prud’hommeaux, E.G.: Semantics and Validation of Shapes Schemas for RDF. In: International Semantic Web Conference (2017)
 [9] Fagin, R., Haas, L.M., Hernández, M.A., Miller, R.J., Popa, L., Velegrakis, Y.: Clio: Schema Mapping Creation and Data Exchange. In: Conceptual Modeling: Foundations (2009)
 [10] Fagin, R., Kolaitis, P.G., Miller, R.J., Popa, L.: Data exchange: semantics and query answering. Theoretical Computer Science (2005)
 [11] Fuxman, A., Hernández, M.A., Ho, C.T.H., Miller, R.J., Papotti, P., Popa, L.: Nested Mappings: Schema Mapping Reloaded. In VLDB pp. 67–78 (2006)
 [12] Klug, A., Price, R.: Determining View Dependencies Using Tableaux. ACM Trans. Database Syst. (1982)
 [13] Kolaitis, P.G., Panttaja, J., Tan, W.C.: The complexity of data exchange. In: Proceedings of the Twentyfifth ACM SIGMODSIGACTSIGART Symposium on Principles of Database Systems. pp. 30–39 (2006)
 [14] Köpcke, H., Rahm, E.: Frameworks for Entity Matching: A Comparison. Data Knowl. Eng. (2010)
 [15] Marnette, B., Geerts, F.: Static Analysis of Schemamappings Ensuring Oblivious Termination. In: Proceedings of the International Conference on Database Theory (2010)
 [16] Marnette, B., Mecca, G., Papotti, P., Raunich, S., Santoro, D., Roma, U.R.T.: ++Spicy: an OpenSource Tool for SecondGeneration Schema Mapping and Data Exchange (2011)
 [17] Ryman, A., Hors, A.L., Speicher, S.: Oslc resource shape: A language for defining constraints on linked data. In: Workshop on Linked Data on the Web (2013)
 [18] Sequeda, J.F., Arenas, M., Miranker, D.P.: On Directly Mapping Relational Databases to RDF and OWL. In: Proceedings of the 21st International Conference on World Wide Web (2012)
 [19] Sirin, E.: Data Validation with OWL Integrity Constraints. In: Hitzler, P., Lukasiewicz, T. (eds.) Web Reasoning and Rule Systems. pp. 18–22 (2010)
 [20] Staworko, S., Boneva, I., Labra Gayo, J.E., Hym, S., Prud’hommeaux, E.G., Solbrig, H.R.: Complexity and Expressiveness of ShEx for RDF. In: ICDT (2015)
Appendix 0.A ShEx Schemas as Sets of Dependencies
Lemma 2
For any typed graph , let be defined as below. For any instance of satisfying and and for all , let be defined as below.
Then for any typed graph and any instance of in the domain of , the following hold:

is an instance of ;

is a typed graph;

is defined and is equal to .
Proof

Immediately follows from the definition .

Immediately follows from the definition of .

Let . By definition, is defined if (a) and (b) and (c) for all . Note that (a) follows from the definition of and the fact that is an RDF graph. Also, (b) and (c) follow from the definition of and the fact that is a typing. Then it immediately follows from the definitions that .
0.a.1 Proof of Lemma 1
Take a typed graph and ShEx schema . For the direction, we will prove by contrapositive. Assume that . Our goal is to prove is not correctly typed w.r.t. . By definition of entailment, there is one dependency that is not satisfied. The dependency can be of the following forms:

. By construction of , the dependency occurs when a triple constraint is of the form where and some property. Since is not satisfied, for some node of . Because the cardinalty of the set of triples with node and propery is 0, the definition of correctly typed in the typed graph w.r.t. is violated.

. By construction of , the dependency occurs when a triple constraint is of the form where . Since is not satisfied, we have that and and , which violates the definition of correctly typed in the typed graph w.r.t. .

. By construction of , the dependency occurs when a triple constraint is of the form where . Since is not satisfied, and . Because the node , it must hold . But this fact is not, then the typed graph w.r.t. is not correctly typed.
For the direction, assume that . Our goal is to prove is correctly typed w.r.t. . We will prove by contradiction. Suppose that is not correctly typed w.r.t. . Then we have two cases when there is a node :

and . By definition of , the node is of type literal, means . Contradiction.

We have two subcases when :

. By definition, all nodes of are in the set . Because is fact in , then . Because blank nodes are potentially IRIs, then . Contradiction.

There is a triple constraint such that

There is a triple such that . Since and are facts in and , then is fact in . Thus, . Contradiction.

Let be the set of triples whose first element is and second element is . The cardinality of is not bounded by . Thus, we have the following cases:

When and . It follows that and . Since , then . Contradiction.

When and . It follows that . Since , then . Contradiction.

When and . It follows that . Since , then . Contradiction.



Appendix 0.B The chase
Let be a data exchange setting with and , and let be an instance of . For a tgd or std and a homomorphism , we say that is applicable to with if (1) either is without existential quantifier and , or (2) and for all extension of on , . Then applying to with yields the instance defined as follows. In the case (1), . In the case (2), where is an extension of and for , is a fresh null value that depends on . If contains a triple constraint , then . If contains for some , then . For an egd , if there exists a homomorphism s.t. , we say that is applicable to with and the result is (1) the instance obtained by replacing by (resp. by ) in all facts of if (resp. ) is a null value, and (2) the failure denoted if both and are non nulls. We write if is applicable to with yielding , where is either another instance or , and is called a chase step.
Let be a set of dependencies and be an instance. A chase sequence of with is a finite or infinite sequence of chase steps for , with and a dependency in . The wellknown result from [10] still holds in our setting: if there exists a finite chase sequence then it constructs a universal solution.
Appendix 0.C Proofs of Theorems 5.1 and 5.2
Before proving the theorems, we define a mapping that will be used to define the notion of homomorphism from a formula into an instance. Let be a function signature and be an interpretation of . For a term over and a mapping , we define as:
The mapping is extended on atoms and conjunctions of atoms as expected: and . Note that if the argument of does not contain function terms, the interpretation is irrelevant so we allow to omit the superscript and write e.g. instead of .
A homomorphism between the conjunction of atoms over signature and the model of is a mapping from to s.t. for every atom in it holds that is a fact in , where , resp. , is the restriction of to , resp. to .
Remark that if does not contain function terms, then in the above definition is irrelevant and we write instead of and instead of .
0.c.1 Proof of Theorem 5.1
Take a data exchange setting with . Assume first that is consistent, and let be a valid instance of and be a solution for by . That is, . Let and be such that
Comments
There are no comments yet.