Incremental schema integration for data wrangling via knowledge graphs

2.1. Related work on bootstrapping

Bootstrapping techniques are responsible for extracting a representation of the source schemata and there has been a significant amount of work in this area, as presented in several surveys [2,23,27,52]. Most of the current available efforts, however, do require an a priori available target schema and/or materialize the source data in the global schema [8,14,36]. Since our approach is bottom-up and meant for virtual systems, we subsequently focus on approaches generating the schema from each source (either checking the available metadata or instances) without using a reference schema or ontology. Table 1 depicts the most representative ones. To better categorize them, we distinguish three dimensions: required metadata, supported data sources, and implementation, which we detail as follows, accompanied by a discussion to highlight our contributions.

Required metadata All approaches define transformation rules to generate the schemata from the available data source metadata as in [6,8,57], and [56]. However, these transformation rules do require well-defined schemata, even for semi-structured data sources such as XML, which is not realistic for data wrangling tasks. Another relevant problem we identified in all these approaches is the lack of standardization of both the process and the generated schemata. All of them present ad-hoc rules that are not compliant with both the data source metamodel and, importantly, the target metamodel (typically, RDFS or OWL). This hinders the reuse and interoperability of these approaches within the end-to-end schema integration process. Indeed, the same schema processed by different approaches may result in different outputs. This is aligned with the current efforts on schema integration, which are specific for a project and do not generalize well.

Supported data sources Most approaches focus on bootstrapping relational data sources, assuming a traditional data integration setting, and only three support semi-structured data models [6,56,57] (in all cases, XML). Yet, in data science, most of the data available comes in the form of semi-structured data sources (e.g., JSON and CSV).

Implementation Current approaches do not provide an open implementation. BootOX [31] is integrated into Optique system [19], but it is no longer maintained or publicly available.

Discussion Our bootstrapping proposal differs from the state-of-the-art as follows: (1) the schema is extracted from the physical structure of the available data (i.e., instances) without relying on a pre-defined available schema of the source, (2) the process and produced schema are standardized. Specifically, our transformation rules are defined at the metamodel level and guarantee the output generated is compliant with both the data source and target metamodels. Standardization is key for efficient maintenance and its reuse in the subsequent schema integration phase, and (3) our approach is generic and adaptable to any data source data model. For those models not considered, we could extend our approach by providing a set of transformation rules satisfying the soundness and completeness properties defined in Section 4. Note that these rules are per pair of metamodels and therefore reusable between sources of the same format.

Schema integration is the process of generating a unified schema that represents a set of source schemata. This process requires as input semantic correspondences between their elements (i.e., alignments). In Table 2, we depict the most relevant state-of-the-art approaches. We distinguish three dimensions: integration type, strategy, and implementation:

Integration type We follow the classification presented in [45], which categorizes the kinds of integration into three types, namely: simple merge, full merge, and asymmetric merge. The former integrates schemata by adding one-to-one bridge axioms between pairs of schemata. Approaches such as [40] and [16] preserve the original source schemata and alignments, which is a desirable property to manage source evolution [4] and mandatory for incremental approaches. However, their main drawback is the lack of common concepts, which can lead to complex queries when integrating a large number of schemata. Full merge integrates the source schemata generating a new schema where equivalent concepts are merged into a single new concept. In most approaches, the original source schemata is not preserved and therefore lost. Thus, these approaches are not incremental. [5] is the only approach under this category able to preserve specific elements of the source schemas upon request. Asymmetric merge can be performed using the simple and merge schema via one-to-many axioms to integrate schemas and derive a full merge. To the best of our knowledge, [51] is the only approach in this category. This kind of merge prioritizes one of the schemas (target) over the others (source), that is, the target schema will preserve all axioms and in case of disagreement with the target schema, elements of the source schema are removed from the integration.

Incremental integration Most approaches (e.g., [16,44,55]) integrate the source schemata in one shot. Thus, to process a new data source the whole process is started from scratch without reusing the previously generated structures. Instead, [51] reuses the integrated structure to facilitate further integration incrementally. To that end, it adopts the asymmetric merge strategy, however, it only supports the integration of taxonomies (i.e., classes with no attributes and only hierarchical relationships among them).

Implementation All approaches provide tools, however only [5] is openly available. There exists a demo of [16] on its website,6

Discussion Our work differs from these works as follows: (1) the global schema is incrementally generated, rather than generated in one shot. (2) We thus incrementally support the integration of any resource (e.g., rdfs:Class and rdf:Property) rather than just focusing in one resource as in [51] (3) In contrast to any other approach, we generate annotations (i.e., metadata) and preserve the original schemata and alignments. These metadata are agnostic of the virtual data integration system at hand, and we are able to derive generic system-specific constructs from our system-agnostic annotations.

We examined virtual data integration systems that have introduced a pipeline supporting bootstrapping and/or schema integration with the goal of providing query access to a set of data sources. We have excluded systems that rely on the manual generation of schema integration constructs [11,41] and focus on those that support semi-automatic creation of such constructs.In all cases, nevertheless, the processes introduced are specific and dependent on the virtual data integration system at hand. Further, note that some popular data integration systems such as Karma [36], Pool Party Semantic [53], or Ontotext7

Optique [ 19 ] It is a virtual data integration system developed as a result of research and industrial projects (e.g., [35]). For each data source, the source schema and RML mappings are generated using BootOX. In order to integrate schemata, equivalent resources between the source and global schemas are mapped manually. During this process, there is no matching technique. Moreover, the global schema is fully maintained by the user, who must update it if it is incomplete with respect to the data sources and propagate the changes throughout the system constructs. However, creating the system constructs does not follow an incremental process. Therefore, new constructs, which are tightly coupled with the system, are needed each time a new data source is added, or the global schema is updated. Finally, Optique allows the integration of relational, streaming, and sensor data and provides a query interface which is performed by the Ontop tool [11].

Mastro studio [ 12 ] It is a virtual data integration system currently available as commercial software maintained by OBDA Systems. The system supports only relational databases, which are mapped to a provided global schema. The mappings are defined in the system’s native language, making them tightly coupled to the system. Moreover, there are no schema matching and schema integration phases as it is assumed the user will provide the global schema. Thus, the main complexity is maintaining the global schema and mappings. The query phase explodes the ad-hoc mappings to provide a more efficient query retrieval.

Discussion All systems generate constructs tightly coupled with the system needs and assume a provided global schema. We, instead, construct the global schema incrementally from the sources, which is crucial for data wrangling. In these approaches, there are three common problems: (1) maintaining the mappings when the schema evolves, (2) updating the global schema to get a complete view of the data sources, and (3) incrementally generating all systems constructs. These problems are even more complex for all the other approaches (e.g., systems and query engines) that fully rely on creating such constructs manually [10,11,17,38,42,50]. Our approach is the only one incrementally generating and propagating changes. Further, we are not tied to any system. Our approach generates and collects rich metadata from the bootstrapping and schema integration steps. These metadata are rich enough to generate system-specific constructs for schema integration, as we show in Section 6. Our generic metadata is able to capture the evolution and automates its maintenance. Thus, if we need to update the constructs generated for a specific system, we only need to re-run the algorithms to produce the specific constructs and replace them in the system. Moreover, as integration is performed bottom-up, generating a global schema will always be complete with respect to the data sources, which is the main requirement for data wrangling.

3.1. Formal definitions and approach overview

3.1.2. Integrating bootstrapped graphs and generating the schema integration constructs

Here, we present the formal definitions that are concerned with phases 2◯, 3◯ and 4◯ as depicted in Fig. 2.

Alignments An alignment between two graphs G A , G B is a triple of the form a = ⟨ v a , v b , ℓ ⟩ , where v a and v b are nodes, respectively in V G A and V G B , and ℓ is a user-provided label for the aligned node. An alignment a is M -compliant (i.e., compliant with the metamodel M ) if the aligned elements are typed to the same node in M . Formally, ∃ ⟨ v a , rdf:type , m ⟩ ∈ E G A and ∃ ⟨ v b , rdf:type , m ⟩ ∈ E G B , where m ∈ V M .

Graph integration algorithm A graph integration algorithm is a function I : A ‾ → G from the set of all sets of alignments to the set of all graphs. We also consider the notion of M -compliant graph integration algorithms, which entails that any graph generated by evaluating I is typed with respect to M . This is formally defined as ∀ A ∈ A ‾ we have that I ( A ) is typed with respect to M .

Schema integration constructs and their generation We follow Lenzerini’s general framework for schema integration8

⁸

Note that virtual data integration systems just consider schema integration and disregard record linkage and data fusion. Thus, in the original framework it talks about data integration, which is used as a synonym of schema integration.

[37]. Hence, a schema integration system K is defined as a triple ⟨ G , S , φ ⟩ , where G is the global schema, S the source schemata and φ the mappings between S and G . Then, following the previous idea, an algorithm to generate the schema integration constructs is a function Q : G → K from the set of all graphs to the set of all schema integration systems.

Overview of our approach Figure 3, summarizes the formal background introduced above and overviews our approach to automate the generation of schema integration constructs from a set of heterogeneous datasets.Shortly, for each dataset D m compliant with the data model m, we use the bootstrap algorithm B m to generate a typed graph of D’s schema (i.e., G m ). Such graph is later transformed into another graph G c , now typed with respect to a canonical metamodel of choice c. Next, and once all graphs have been generated and typed with respect to c, we can execute the graph integration algorithm I in a pairwise and incremental fashion. Each of the resulting integrated graphs is a candidate to be used to generate the constructs K for a schema integration system.

OPEN IN VIEWER

Fig. 3.

Formal overview of our approach.

We consider a data analyst interested in wrangling two different sources about artworks from the Carnegie Museum of Art (CMOA)9

OPEN IN VIEWER

Fig. 4.

Running example excerpts.

OPEN IN VIEWER

Fig. 5.

Metamodel to represent graph-based schemata of JSON datasets (i.e., M JSON ) inspired from [29].

4.1. Data source metamodeling

In order to guarantee a standardized process, the first step requires the definition of a metamodel for each data model considered (note that several sources might share the same data model). Figure 5 depicts the metamodel to represent graph-based JSON schemata (i.e., M JSON ). Such metamodel (whose elements we prefix as J) describes the basic constructs and the relationships between them. As shown, a consists of one root , which in turn contains at least one instance. Each is associated with one value which is either a , a or a . We also assume elements of a to be homogeneous, and thus it is composed of elements. Last, we consider three kinds of primitives: these are , and . In Appendix A, we present the complete set of constraints that guarantee that any typed graph with respect to M JSON is consistent.

4.2. The canonical metamodel

In order to enable interoperability among graphs typed w.r.t. source-specific metamodels, we choose RDFS as the canonical data model for the integration process. A significant advantage of RDFS is its built-in capabilities for meta-modeling, which supports different abstraction levels. Figure 6, depicts the fragment of the RDFS metamodel ( M RDFS )11

OPEN IN VIEWER

Fig. 6.

Fragment of the RDFS metamodel (i.e., M RDFS ) considered in this paper.

We next present a bootstrapping algorithm to generate graph-based representations of JSON datasets. The generation of wrappers that retrieve data using such graph representation has already been studied (e.g., see [42]), and here we reuse such efforts. Here, we focus on the construction of the required data structure. As depicted in Algorithm 1, the method D OCUMENT returns, for a given dataset, a graph typed with respect to the metamodel M JSON . It contains a set of functions, one per element of the metamodel, with a shared signature consisting of (a) the graph G where to populate the triples, which is passed by reference; (b) the JSON dataset or some of its children (e.g., embedded objects or arrays) D; and (c) D’s parent p (e.g., the key of an embedded object). For simplicity, we make use of a function IRI ( s ) , that, given a string s, generates a unique IRI from s. Additionally, we use FRESH () to define fresh identifiers (i.e., synthetic strings that do not exist in G), and READ F ILE ( D ) to read from disk the content of a dataset D.

The goal of this algorithm is to instantiate the and elements using the document’s root. Then, the method Object recursively instantiates M JSON with D’s content. Precisely, for each key-value pair ⟨ k , v ⟩ , which instantiate , we define its corresponding vt and distinguish the cases of complex (i.e., objects and arrays) and simple (i.e., primitive) elements. Dealing with complex objects requires instantiating or with fresh IRIs (i.e., object or array identifiers). This is not the case for primitive elements, which are either connected to the three possible instances of (i.e., , , or ). The presence of such three possible instances in G is guaranteed by function INSTANTIATE M ETAMODEL . We, additionally, annotate the elements contained in arrays. Assuming that array elements are homogeneous, we relate the instance of to an instance of using the labeled edge.

OPEN IN VIEWER

Algorithm 1

Bootstrap a JSON dataset

Proof of soundness We show that Algorithm 1 is M JSON -sound . This is, for any input JSON dataset, the graph it generates is typed with respect to M JSON and consistent with respect to the set of boolean constraints P M JSON . By construction we can see that for every node v ∈ V G (where G is the output of Algorithm 1) there exists an edge ⟨ v , rdf:type , m i ⟩ where m i ∈ V M JSON . Indeed, all instances of are declared in line 4 of function Document, while all instances of and are declared, respectively, in lines 3 and 5 of function Object. Instances of are declared in line 3 of function Array. Regarding primitive data types, they are all declared once when instantiating the metamodel.

OPEN IN VIEWER

Fig. 7.

Set of triples generated by Algorithm 1. In the left-hand side we depict the function that generates each corresponding set of triples.

Proof of completeness We show that Algorithm 1 is complete with respect to the JSON dataset. That is, for any JSON key k, there exists a resource R in the generated graph. This is guaranteed since for every element in M JSON there exists a function generating a resource R in the graph. Indeed, for , , , and there exists a method named likewise. Regarding , the resource R is created in the method Object. Note that we assume keys in a JSON dataset contain schema values and not data values (i.e., they are well-formed). We also assume that all elements in an array are homogeneous.

We next present the second step of our bootstrapping approach (see Fig. 3), which is the translation of graphs typed with respect to a specific source data model (e.g., M JSON ) into graphs typed with respect to a canonical metamodel (i.e., M RDFS ). Following the idea in [3], we present the production system used to translate graphs typed with respect to JSON to RDFS. The production system P JSON → RDFS consists of five production rules which can be evaluated in no particular order. The remainder of this subsection is devoted to formally present the production rules that compose P JSON → RDFS . It is worth noting the usage of the Kleene closure operator in Rules #4 and #5, which allows to represent multidimensional arrays in the generated graph.

Rule 1.

Instances of are translated to instances of . ( R 1 ) ∀ o ( ⟨ o , rdf:type , J:Object ⟩ ( G ) ) ⟹ ∃ c ( ⟨ c , rdf:type , rdfs:Class ⟩ ( G ′ ) ∧ c = o )

Rule 2.

Instances of are translated to instances of . Additionally, this requires defining the of such newly defined instance of . ( R 2 ) ∀ o , k ( ⟨ o , J:hasKey , k ⟩ ( G ) ) ⟹ ∃ c , p ( ⟨ p , rdf:type , rdf:Property ⟩ ( G ′ ) ∧ ⟨ p , rdfs:domain , c ⟩ ( G ′ ) ∧ p = k ∧ c = o )

Rule 3.

Instances of which have a value an instance of are also instance of . ( R 3 ) ∀ o , k ( ⟨ o , J:hasKey , k ⟩ ( G ) ∧ ⟨ k , J:hasValue , a ⟩ ( G ) ∧ ⟨ a , rdf:type , J:Array ⟩ ( G ) ) ⟹ ∃ p ( ⟨ p , rdf:type , rdfs:ContMembProperty ⟩ ( G ′ ) ∧ p = k )

Rule 4.

The of an instance of is its corresponding counterpart in the xsd vocabulary. Below we show the case for instances of whose counterpart is . The procedure for instances of and is similar using their pertaining type. ( R 4 ) ∀ k , v ( ⟨ k , J:hasValue + , v ⟩ ( G ) ∧ ⟨ k , rdf:type , J:Key ⟩ ( G ) ∧ ⟨ v , rdf:type , J:String ⟩ ( G ) ) ⟹ ∃ p ( ⟨ p , rdf:type , rdf:Property ⟩ ( G ′ ) ∧ ⟨ p , rdfs:range , xsd:string ⟩ ( G ′ ) ∧ p = k )

Rule 5.

The of an instance of is the value itself. ( R 5 ) ∀ k , v ( ⟨ k , J:hasValue + , v ⟩ ( G ) ∧ ⟨ k , rdf:type , J:Key ⟩ ( G ) ∧ ⟨ v , rdf:type , J:Object ⟩ ( G ) ) ⟹ ∃ p , r ( ⟨ p , rdfs:range , r ⟩ ( G ′ ) ∧ p = k ∧ r = v )

Example 2.

Here, we take as input the graph generated by our bootstrapping algorithm depicted in Fig. 7. Then, Fig. 8 shows the resulting graph typed w.r.t. the RDFs metamodel after applying the production rules. Each node and edge is annotated with the rule index that produced it.

OPEN IN VIEWER

Fig. 8.

Graph typed w.r.t. the RDFS metamodel resulting from evaluating the production rules.

OPEN IN VIEWER

Fig. 9.

Extension of the rdfs metamodel for the integration annotation.

5. Incremental schema integration

This section describes phase 3◯ in Fig. 2, which addresses the problem of generating the integrated graph (IG) from a pair of typed graphs, as illustrated in Fig. 3. To facilitate the schema integration process, we extend the fragment of the RDFS metamodel (See Section 4.2) to include two new resources, namely and (see Fig. 9). These resources are essential to annotate how the underlying data sources must be integrated (e.g., union or join). The integration is accomplished through a set of invariants (see Section 5.1) that guarantee the completeness and incrementality of the IG. Importantly, our proposal is sound and complete with regard to the bootstrapping method described in Section 4 and it can only guarantee these properties if its input is typed graphs (see Fig. 3). The algorithm we propose in this phase takes as input two typed graphs and a list of semantic correspondences (i.e., alignments) between them. The integration algorithm is guided by semantic correspondences when generating the IG, keeping track of used and unused alignments in the process. Unused alignments identify those semantic correspondences not yet integrated due to conditions imposed by the integration algorithm, but to be integrated once the conditions are met in further executions. To obtain the semantic correspondences, we rely on existing schema matching techniques (e.g., LogMap [30] or Nextia JD [18]) to produce alignments.

All in all, the IG is a rich set of metadata containing all relevant information to perform schema integration and, as such, it traces all information from the sources as well as that of integrated resources to support their incremental construction. In Appendix B.1, we present the complete set of constraints that guarantee that any IG is consistent.

Example 3.

Continuing the running example, Fig. 10 illustrates the result of the bootstrapping step to generate the typed graph representation of the data sources CMOA.json and Cooperhewitt.json. Note that the range properties are omitted due to space reasons. Also, we distinguish and . Since this information is not available in the input typed graphs, we use and distinguish them by checking their range. Hereinafter, as shown in Fig. 10, we use the following color schemes to represent , and . We use dark colors to represent integrated resources: of type class, of type datatype property and of type object property.

OPEN IN VIEWER

Fig. 10.

The extracted canonical RDF representations for the CMOA and cooperhewitt sources.

5.1. Integration of resources

We here present an implementation for the graph integration algorithm (see Section 3.1.2). This algorithm, system-agnostic (i.e., not tied to any specific system) and incremental by definition, generates an integrated graph G I for the input typed graphs. Our algorithm requires as input two typed graphs G A and G B and a list of alignments A (see Section 3 for a precise definition of the typed graph and the kind of alignments ⟨ R A , R B , l ⟩ considered). Intuitively, we generate G I as the union of G A and G B plus a set of integrated resources generated from the input alignments. As shown in Fig. 3, the integration is performed pairwise and the result of executing our algorithm is always an IG. Importantly, an IG is, by definition, a typed graph and therefore it guarantees the closure of our algorithm: i.e., it can take as input a previously generated G I and a typed graph produced from a new data source and generate a new IG, G I ′ , that integrates both inputs. The integration of N data sources requires the execution of this algorithm N − 1 times and generates N − 2 intermediate IGs prior generating the final IG integrating all sources. In the following, we present the invariants that guarantee the creation and propagation of the integrated resources into the final IG, which hereinafter we will refer to as G I ′ . We first present the invariants for class resources.

I1 If R A and R B are not , then R A and R B become subclass of a new R l defined as the URI representation of l (i.e., R l = generateURI ( l ) ). Formally: ∀ ⟨ R A , R B , l ⟩ ∈ A : ⟨ R A , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R A , rdf:type , rdfs:Class ⟩ ∈ G I ∧ ⟨ R B , rdf:type , rdfs:Class ⟩ ∈ G I ⟹ ∃ R l = generateURI ( l ) : ⟨ R l , rdf:type , :IntegratedResource ⟩ ∈ G I ′ ∧ ⟨ R l , rdf:type , rdfs:Class ⟩ ∈ G I ′ ∧ ⟨ R A , rdfs:subClassOf , R l ⟩ ∈ G I ′ ∧ ⟨ R B , rdfs:subClassOf , R l ⟩ ∈ G I ′

I2 If R A is not an and R B is an , then R A becomes a subclass of R B . Formally: ∀ ⟨ R A , R B , l ⟩ ∈ A : ⟨ R A , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∈ G I ∧ ⟨ R A , rdf:type , rdfs:Class ⟩ ∈ G I ∧ ⟨ R B , rdf:type , rdfs:Class ⟩ ∈ G I ⟹ ⟨ R A , rdf:type , :IntegratedResource ⟩ ∉ G I ′ ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∈ G I ′ ∧ ⟨ R B , rdf:type , rdfs:Class ⟩ ∈ G I ′ ∧ ⟨ R A , rdfs:subClassOf , R B ⟩ ∈ G I ′

I3 If R A is an and R B is not an , then R B is a subclass of R A . Formally: ∀ ⟨ R A , R B , l ⟩ ∈ A : ⟨ R A , rdf:type , :IntegratedResource ⟩ ∈ G I ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R A , rdf:type , rdfs:Class ⟩ ∈ G I ∧ ⟨ R B , rdf:type , rdfs:Class ⟩ ∈ G I ⟹ ⟨ R A , rdf:type , :IntegratedResource ⟩ ∈ G I ′ ∧ ⟨ R A , rdf:type , rdfs:Class ⟩ ∈ G I ′ ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∉ G I ′ ∧ ⟨ R B , rdfs:subClassOf , R A ⟩ ∈ G I ′

I4 If R A and R B are , then the new integrated resource C l defined as the URI representation of l (i.e., C l = generateURI ( l ) ) replaces R A and R B . Formally: ∀ ⟨ R A , R B , l ⟩ ∈ A : ⟨ R A , rdf:type , :IntegratedResource ⟩ ∈ G I ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∈ G I ∧ ⟨ R A , rdf:type , rdfs:Class ⟩ ∈ G I ∧ ⟨ R B , rdf:type , rdfs:Class ⟩ ∈ G I ∧ ⟨ r , rdfs:subClassOf , R A ⟩ ∈ G I ∧ ⟨ r ′ , rdfs:subClassOf , R B ⟩ ∈ G I ∧ r ≠ r ′ ⟹ ∃ R l = generateURI ( l ) ∧ ∀ r , r ′ : ⟨ R l , rdf:type , :IntegratedResource ⟩ ∈ G I ′ ∧ ⟨ R I , rdf:type , rdfs:Class ⟩ ∈ G I ′ ∧ ⟨ R A , rdf:type , :IntegratedResource ⟩ ∉ G I ′ ∧ ⟨ R A , rdf:type , rdfs:Class ⟩ ∉ G I ′ ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∉ G I ′ ∧ ⟨ R B , rdf:type , rdfs:Class ⟩ ∉ G I ′ ∧ ⟨ r , rdfs:subClassOf , R A ⟩ ∉ G I ′ ∧ ⟨ r ′ , rdfs:subClassOf , R B ⟩ ∉ G I ′ ∧ ⟨ r , rdfs:subClassOf , C l ⟩ ∈ G I ′ ∧ ⟨ r ′ , rdfs:subClassOf , C l ⟩ ∈ G I ′

Intuitively, the presented invariants guarantee the soundness and completeness of our approach, since it covers all potential cases derived from one-to-one mappings: non-previously integrated resources, either one or another previously integrated or both already integrated. Grounded on these invariants, Algorithm 2 generates the corresponding integrated metadata and supports their incremental construction and propagation. Note that invariant I1 creates a new of type class, invariants I2 and I3 reuse an existing and invariant I4 replace an . To accomplish I4, our algorithm uses the method replaceIntegratedResource depicted in Algorithm 3, which provides the necessary functionality to replace the resources that were integrated by an with . When integrating classes, all resources (e.g., properties) connected to must be connected to For example, replacing an of type class requires updating all properties referencing by rdfs:range or rdfs:domain to reference . Therefore, we introduce the method concordanceRelations to redirect the relations from an old resource to a new resource.

OPEN IN VIEWER

Algorithm 2

Integration of resources – classes

OPEN IN VIEWER

Algorithm 3

Replace integrated resource – classes

Algorithm 4 is the main integration algorithm to generate G I ′ . It expects sets of alignments to integrate resources pertaining to the same type and implements the methods IntegrateClasses for class resources, IntegrateDataTypeProperties for datatype properties and IntegrateObjectProperties for object properties following the rationale previously presented and guaranteeing the class and property invariants.

5.1.1. Integration of classes

We have introduced the IntegrateClasses method implementing the class invariants presented in Algorithm 2. Note that, for invariant 4, Algorithm 5 illustrates the method concordanceRelations to ensure that all axioms are coherent when replacing an .

OPEN IN VIEWER

Algorithm 4

Incremental schema integration.

OPEN IN VIEWER

Algorithm 5

ConcordanceRelations – classes.

OPEN IN VIEWER

Table 4

Discovered correspondences for G CMOA and G Cooperhewitt

G CMOA	G Cooperhewitt	User-provided label l
		Artworks
		Title
		URL
		Creator
		Name
		Contributors

OPEN IN VIEWER

Fig. 11.

Integration of two classes from G CMOA and G Cooperhewitt .

Example 4.

Retaking the running example, consider the alignments depicted in Table 4 between G CMOA and G Cooperhewitt . Let us consider the alignment and . For this case, invariant I1 is applied as illustrated in Fig. 11. Thus, both classes are connected to a newly defined instance of class and , namely . For this example, two were generated: and . Note, the set A unused is empty since this is the first integration performed.

5.1.2. Integration of properties

The invariants for properties are very similar to those presented for classes. Thus, we will use the IntegrateClasses method as a baseline to discuss the integration of properties. Importantly, we follow a class-oriented integration for properties, that is, properties can only be integrated once their corresponding domain and range classes have been integrated into the same integration class. Doing so, we guarantee that integrated properties are semantically equivalent as to performing a union operation. Next, we describe how property integration happens and exemplify it by using Example 3. We distinguish two main integration cases for properties: and .

Let us start with datatype properties. Following the class-oriented integration idea introduced, we only integrate datatypes if they are part of the same entity, that is, if their domains (e.g., ) have already been integrated into the same of type class. Therefore, the invariants for integration must reflect this condition. In the following, we present invariant I1 for . Note that the remaining invariants should be updated accordingly. ∀ ⟨ R A , R B , l ⟩ ∈ A R : ⟨ R A , rdfs:domain , C A ⟩ ∈ G I ∧ ⟨ C A , rdfs:subClassOf , C IA ⟩ ∈ G I ∧ ⟨ R B , rdfs:domain , C B ⟩ ∈ G I ∧ ⟨ C B , rdfs:subClassOf , C IB ⟩ ∈ G I ∧ ⟨ C IA , rdf:type , IntegratedResource ⟩ ∈ G I ∧ C IA = C IB ∧ ⟨ R A , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R A , rdf:type , rdf:Property ⟩ ∈ G I ∧ ⟨ R B , rdf:type , rdf:Property ⟩ ∈ G I ⟹ ∃ R l = generateURI ( l ) : ⟨ R l , rdf:type , :IntegratedResource ⟩ ∈ G I ′ ∧ ⟨ R l , rdf:type , rdf:Property ⟩ ∈ G I ′ ∧ ⟨ R A , rdfs:subPropertyOf , R l ⟩ ∈ G I ′ ∧ ⟨ R B , rdfs:subPropertyOf , R l ⟩ ∈ G I ′

OPEN IN VIEWER

Algorithm 6

Integration of data type properties – adapted from Algorithm 2.

Algorithm 6 implements the IntegrateDataTypeProperties method in Algorithm 4. The implementation of IntegrateDataTypeProperties method is similar to Algorithm 2 except for the additional conditions and the manipulation of the domain and range axioms. If the conditions are not fulfilled, the algorithm does not integrate the alignment and preserves it in the set of A unused until their domains are integrated into the same in further integrations. Thus, whether this integration will take place depends on the discovered set of alignments from the schema matching approaches. Further, the domain of the of type property is an of type class. And for the range, we assign the more flexible xsd type (e.g., xsd:string). Algorithm 7 implements the method concordanceRelations to ensure all axioms are coherent when replacing an or an of type property.

For the integration of , we follow a similar approach and only integrate object properties if their domain and range have already been integrated. Accordingly, the object property invariants should reflect this condition and we showcase it for invariant I1 as follows: ∀ ⟨ R A , R B , l ⟩ ∈ A R : ⟨ R A , rdfs:domain , C AD ⟩ ∈ G I ∧ ⟨ C AD , rdfs:subClassOf , C IAD ⟩ ∈ G I ∧ ⟨ R B , rdfs:domain , C BD ⟩ ∈ G I ∧ ⟨ C BD , rdfs:subClassOf , C IBD ⟩ ∈ G I ∧ ⟨ C IAD , rdf:type , IntegratedResource ⟩ ∈ G I ∧ C IAD = C IBD ∧ ⟨ R A , rdfs:range , C AR ⟩ ∈ G I ∧ ⟨ C AR , rdfs:subClassOf , C IAR ⟩ ∈ G I ∧ ⟨ R B , rdfs:range , C BR ⟩ ∈ G I ∧ ⟨ C BR , rdfs:subClassOf , C IBR ⟩ ∈ G I ∧ ⟨ C IAR , rdf:type , IntegratedResource ⟩ ∈ G I ∧ C IAR = C IBR ∧ ⟨ R A , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R B , rdf:type , :IntegratedResource ⟩ ∉ G I ∧ ⟨ R A , rdf:type , rdf:Property ⟩ ∈ G I ∧ ⟨ R B , rdf:type , rdf:Property ⟩ ∈ G I ⟹ ∃ R l = generateURI ( l ) : ⟨ R l , rdf:type , :IntegratedResource ⟩ ∈ G I ′ ∧ ⟨ R l , rdf:type , rdf:Property ⟩ ∈ G I ′ ∧ ⟨ R A , rdfs:subPropertyOf , R l ⟩ ∈ G I ′ ∧ ⟨ R B , rdfs:subPropertyOf , R l ⟩ ∈ G I ′

OPEN IN VIEWER

Algorithm 7

ConcordanceRelations – properties.

The implementation of the integration is very similar to Algorithm 6. We should accordingly add the proper conditions set by the invariants and consider the manipulation of the axioms as we performed for . We illustrate the integration of properties in Example 5.

Example 5.

Continuing the Example 4, the algorithm will integrate all using invariant I1 since their domains were already integrated. If their domains are not integrated, the properties will be preserved in the set of unused alignments A unused . Figure 12 illustrates the integration process of integrating and . The integration algorithm uses rdfs:subPropertyOf to connect both to the of type property, that is, . For this example, the following were generated: , and . Then, we proceed to integrate as we can note that the domain and range of and have already been integrated, fulfilling the object property requirement. Finally, Fig. 13 depicts the complete integrated graph generated from Example 4 and 5. The result of this schema integration generates one of type class, three of type datatype property and one of type object property. Note that the set A unused contains the alignments not used during this integration, allowing them to be used in further integrations.

OPEN IN VIEWER

Fig. 12.

Result of integrating two classes and two data type properties from G CMOA and G CooperhewittInt .

OPEN IN VIEWER

Fig. 13.

Final integration graph from Examples 4 and 5.

OPEN IN VIEWER

Algorithm 8

Join integration

OPEN IN VIEWER

Fig. 14.

Example of a join integration.

OPEN IN VIEWER

Fig. 15.

New data source.

OPEN IN VIEWER

Table 5

Alignments discovered for I ( G CMOA , G Cooperhewitt ) and G Artists

I ( G CMOA , G Cooperhewitt )	G Artists	User-provided label l
		Artist
		Nationality
		Name

OPEN IN VIEWER

Fig. 16.

Result of integrating two integrated classes from I ( G CMOA , G Cooperhewitt ) and G Artistsi .

As discussed, our property integration is class-oriented and we only automate the process if the integrated properties are equivalent and can be integrated via a union operator. However, in real practice, this is very restrictive and we allow to integrate two datatype properties whose classes have not been previously integrated in what we call a . This integration must be performed by a post-process task triggered by a user request. This type of property integration occurs when the domains are not semantically related, but the properties have a semantic correspondence in an input alignment. We thus consider this case as a join operation. Algorithm 8 depicts this integration type. Having no conditions allows us to integrate properties from completely distinct entities. To allow this integration, we must express the join relationship by creating an that connects both domain of the to integrate, as illustrated in Fig. 14. This object property aims to add semantic meaning to the implicit relation of the properties domain. Thus, this connects to the using to identify that this is an on-demand datatype property integration not meeting the regular integration algorithms.

We will use the final result of Example 5 to perform an incremental integration. For this case, consider the data analyst wants to integrate the typed graph I ( G CMOA , G Cooperhewitt ) in Fig. 13 with the typed graph G artists in Fig. 15. In this iteration, the schema matching approach proposed the alignments depicted in Table 5. First, we integrate . Let us consider the alignment and . Note that we have two of type class in this alignment resulting in the use of invariant I 4 from Algorithm 2. Figure 16 illustrates the integration process for this alignment in which and are replaced by the new of type class, namely . Now, the algorithm proceeds to integrate . Let us consider the alignment and representing invariant I 2 . The integration process is illustrated in Fig. 17. For this case, instead of creating a new of type property, we reuse . Therefore, will be a . For the last alignment, and , we replace both of type property by . In summary, our approach creates one of type class and two of type property. The resulting integrated graph is depicted in Fig. 18.

OPEN IN VIEWER

Fig. 17.

Result of integrating one integrated data type property from I ( G CMOA , G Cooperhewitt ) and G Artists .

OPEN IN VIEWER

Fig. 18.

Integration graph from a second integration.

OPEN IN VIEWER

Fig. 19.

Example of two different data models.

The integration algorithm is our incremental proposal to integrate the typed graphs. However, this algorithm assumes one-to-one input alignments, a limitation all schema alignment techniques have. Our integration algorithm integrates equivalent resources, but it is not able to deal with other complex semantic relationships. To illustrate this, consider the example presented in Fig. 19. Let us consider a data analyst interested in retrieving the country’s name related to a project. For the G ds 1 graph, this information can be obtained by using the property to retrieve the entity. However, the G ds 2 graph has a different way to represent the country information from a project requiring to retrieve the entity, using the property, and then using the property to retrieve the entity, which contains the information. The main problem in this case is that the alignment is not one-to-one, instead, the alignment matches a subgraph to one resource. As far as we know, there is no schema alignment technique that considers such case and we for now do not either and leave it for future work. Last, but not least, we would like to stress that even if largely automated, schema integration must be a user-in-the-loop process, since this is the only way to guarantee the input alignments generated by a schema alignment tool are correct.

6.1. Mediator-based systems

We consider ODIN as a representative mediator-based data integration system [43]. ODIN relies on knowledge graphs to represent all the necessary constructs for query answering (i.e., the global graph, source graphs and local-as-view mappings). However, all its constructs must be manually created. Thus, we show how to generate its constructs automatically from the integrated graph generated in our approach.

Algorithm 9 shows how to generate the global graph required by ODIN from our integrated graph. In ODIN, the global graph is the integrated view where end-users can pose queries. Hence, this algorithm first merges the sub-classes and sub-properties of integrated resources. As a result, we represent the taxonomy of integrated resources with a single integrated resource and properly modify the domain and range of the affected properties. In the case of non-integrated resources, their original definition remains. Figure 20, illustrates the output provided by Algorithm 9 for the generated integration graph in Fig. 18. The source schemata and wrappers representing the sources and required by ODIN are immediate to retrieve, since our integration schema preserves the original graph representation bootstrapped per source, and the wrappers remain the same. Finally, since the integration graph was built bottom-up, the local-as-view mappings required by ODIN are generated via the sub-class or sub-property relationships created during schema integration between source schemata elements and integrated elements. All ODIN constructs are therefore straightforwardly generated from the integration graph automatically. Once done, and after loading these constructs into ODIN, the user can query the data sources by querying the global graph of ODIN, which will rewrite the user query over the global graph into a set of queries over the wrappers via its built-in query rewriting algorithm. We have implemented the method here described to generate the constructs and integrated it in ODIN. This implementation is available on this paper’s companion website.

OPEN IN VIEWER

Algorithm 9

Global schema

OPEN IN VIEWER

Fig. 20.

Generated global schema.

Ontology-based data access systems provide a unified view over a set of heterogeneous datasets through an ontology, usually expressed in the OWL 2 QL profile, and global-as-view mappings, often specified using languages such as R2RML and RML. The integrated graph is able to derive an OWL ontology by converting RDFS resources into OWL resources. To this aim, Algorithm 9 requires a post-process step to perform this task. Note that, by definition, the integrated graph contains a small subset of RDFS resources. Thus, we only require to map to and to the corresponding or . Concerning mappings, as long as appropriate algorithms are defined to extract and translate the metadata from the integrated graph, we can derive mappings for any dedicated syntax. Here, we will explain the derivation of RML mappings. Each RML mapping consists of three main components: (i) the Logical Source () to specify the data source, (ii) the Subject Map () to define the class of the RDF instances generated and that will serve as subjects for all RDF triples generated, and (iii) a set of Predicate-Object maps () that define the creation of predicates and its object value for the RDF subjects generated by the Subject Map. Algorithm 10 shows how to generate RML mappings from the integrated graph. The process is as follows.

The algorithm creates RML mappings for each entity defined in a data source schema. Therefore, it iterates over all resources of type from the integrated graph that are not , since those resources were generated from a data source during the bootstrapping phase. For each resource c of type , we generate a unique URI, namely m c , to represent the RML mapping and create the three RML components. First, we specify the for the mapping m c . Here, we created the required metadata by the Logical Source: (i) the to specify the data source location, which is obtained from the source wrapper through the method GetDataSourcePath ( c ) , (ii) the to express the data source format, which is assigned dynamically depending on the data source type by using the method GetDataSourceType ( c ) (e.g., for CSV and JSON it generates or ), and (iii) the to define the iteration pattern to retrieve each data instance to be mapped, obtained from the wrapper definition using the method GetIterator ( c ) .

OPEN IN VIEWER

Algorithm 10

RML mappings generation.

The next step is to specify the for the mapping m c . Here, we define the variable c targetType using the URI from c to define the subject type of all RDF instances produced. If resource c is a subclass of an , we define c targetType as the integrated URI. Then, we created the required metadata for the : (i) the to define the URIs of the instances, for which we use the URI from c targetType and append a unique identifier from the data source, and (ii) the to specify the class of the subjects produced. Then, we create of the set of . To that end, we iterate over all that has as domain the class c. Then, for each property p, we define the variable p predicate as the URI from p. If p is a subproperty of an or p is a subproperty of an that represents a , we define p predicate as the integrated URI or as the JoinProperty URI, respectively. Then, we generate the metadata. Here, we distinguish two cases: properties that are not part of a and those that are. In the first case, we will generate the metadata as follows: (i) the to indicate that property p predicate is used to map the subject with the object, and (jj) the as well as to indicate which element of the data source schema should be used to generate the RDF objects instances. Here, we use the method GetSourceReference ( p ) to retrieve the reference of the data source (e.g, a column or JSON key) from a given property, which is obtained from the wrapper metadata. Finally, if the property is part of a , we will create a for all properties that are part of the . Then, the following metadata is generated for each : (i) the where we use the join property URI to connect two entities from different sources, and (ii) the along with a , which is used to link the mappings of two different entities. We use the method GetClassMapping ( p ′ ) to get the mapping URI of a given property. Finally, we proceed to create the metadata for the : (i) the containing the and the , which require a reference of an element from the data source to create the join. We used the method GetSourceReference to obtain the references of each property p and p ′ .

As a result, the provided algorithm generates the RML mappings for all entities and data sources contained in an integrated graph and uses the annotations with regard to unions and joins to construct global-as-view mappings according to the global schema (e.g., ontology). Last but not least, this algorithm showcases the feasibility of generating RML mappings from the integrated graph. Note that the generated RML mappings can be used for any RML compliant engines (virtual or materialized) such as Morph-RDB [49], RDFizer [28] and RMLStreamer [24]. Importantly, note that our objective is not to generate optimized RML mappings, which should be part of the future work.

This user study aims at evaluating the efficiency and quality of Nextia DI in automatically supporting the task of schema integration compared to a conventional schema integration pipeline. The study is, hence, divided into three tasks: (i) generation of source schemata, (ii) generation of an integrated schema, and (iii) generation of mappings. Participants were asked to perform each task using both pipelines: the conventional approach and supported by Nextia DI . In the following, we describe our process:

Data sources We selected four data sources collected from the Tate collection13

Definition of the data collection methods As discussed in Section 2, no tool from the state-of-the-art covers the same end-to-end process as our approach does. Thus, as a baseline representation of the conventional schema integration pipeline, we designed a set of notebooks to support each of the tasks described above.15

Selection of participants A set of 16 practitioners was selected to participate in the user study. Care was taken in selecting participants both from academia (researchers at UPC) and industry with different backgrounds and expertise (e.g., a broad range of skills, different seniority levels). All of them have participated in at least one Data Science project. Figure 21 summarizes how participants describe themselves with regard to the relevant skills required to perform the study. Specifically, we asked them to rate how skilled they felt in data integration (and specifically in the sub-domains of schema integration and virtual data integration systems), data modeling and knowledge graphs. All these skills were needed during the study and, as shown later, provide value when interpreting the results obtained. Participants were divided into two equally sized groups and assigned either v1 or v2.

OPEN IN VIEWER

Fig. 21.

Distribution of level across skills for all participants.

Evaluation of collected results In order to evaluate the results of each survey, we compare the aggregated answers for each non free-form question distinguishing between the conventional approach and Nextia DI . Additionally, in order to compare the answers to questions with different scales, we have normalized all aggregated values to the range [ 0 , 1 ] using the MinMax normalization technique. For all surveys, we measure the time spent on the task, and whether participants managed to finish it or not. We also surveyed participants with questions related to their perceived effort in completing each task. Furthermore, for each task, we also compute the soundness and completeness of the produced results. Soundness is computed by manually checking the correctness of the generated results (e.g., typing and domain and ranges are correctly defined), while completeness is computed using the expression C = 1 − i i / i t , where i i is the number of incomplete items and i t the number of total items, as defined in [13]. This way, we avoid any kind of bias by selecting external metrics defined in the literature.

OPEN IN VIEWER

Fig. 22.

Aggregated results for the bootstrapping phase. Completed specifies whether participants finished the task within the available time (higher is better). # of source schemas denotes how many schema elements participants managed to bootstrap in the available time (higher is better). Relevance of exploration denotes the need a participant perceived to explore the structure of the sources to conduct the activity (lower is better). Effort and Time specifies, respectively, the perceived effort and time to complete the task (lower is better). Feasibility is used to quantify the perceived feasibility of running the task with the approach at hand (higher is better). Completeness and Soundness refer to the quality metrics previously introduced.

Results on bootstrapping Figure 22 shows the aggregated results from the bootstrapping survey, where participants were required to define a graph-based schema for each data source with the two approaches. In the conventional approach, only 12.5% of the participants generated the four schemata, while using Nextia DI all participants completed the task. We observe that the main challenge in the conventional approach is the required domain knowledge in data modeling and knowledge graphs. Participants P2 and P9 said: “It is really hard and requires knowledge of specific syntax and technologies such as Semantic Web, Knowledge Graph, Data Modeling.” and “You need expertise in Knowledge Graphs and Modeling (e.g., in RDF) to come up with sound schemas/models.” Regardless of their background, all participants in the conventional approach reported a high level of effort. The main reason is the need to explore the data sources, as reported by 81.3% of the participants who reported they were constantly exploring the content of the data sources to understand the structure to design the schema. With Nextia DI , the efforts reported were smoother and 87.5% said no effort is needed. Regarding the time, participants spent an average of 53.44 mins bootstrapping the sources in the conventional approach, while using Nextia DI , participants completed the task in an average of 5.9 mins. As participant P5 pointed out, “It provided a great automation of the process, reducing the time spent to generate the source schema.” When asked how feasible is to bootstrap the schema of data sources using the conventional approach, all participants reported it as unfeasible. With Nextia DI , 93.8% reported it as feasible. The only person not assessing Nextia DI positively commented “Actually I would like to know how Nextia DI behaves when importing large schemas.” However, this is a laborious task we could not cover in the study, which we had to keep reasonable (below 2 h of effort) to involve as many practitioners as possible. We report on this aspect when discussing Q4 later. In this sense, as P3 and P4 reported: “In the context of big data, automation is much required. Nextia DI provides this.” and “Having an automatic way of generating those schemas without even having to look at the underlying data, is a very good solution when huge amounts of data coming from different structures are present.” Concerning the quality of the bootstrapped source schemata, overall by means of the conventional approach they yielded 23 schemas, yet only 21.74% completely represent the data source schema and 47.82% of the schemas only represent less than 31% of the data source content. Additionally, with regard to soundness, only 43.48% of the schemas were compliant with the metamodel. Most common mistakes were the lack of typing (e.g., class or properties) and incorrect usage of axioms. The schemata with the best soundness and completeness were produced by participants who are proficient in knowledge graphs and competent to experts in data modeling. In the case of Nextia DI , all their schemata are complete with regard to the data source content and are compliant with the metamodel.

Results on schema integration Figure 23 depicts the aggregated results for the schema integration survey, where participants were required to integrate the schemas generated in the previous task. In order to accomplish it, three main integrated schemata had to be created (i.e., DS1-DS2, DS1-DS2-DS3, and DS1-DS2-DS3-DS4). On the conventional approach, only 6.25% of the participants managed to generate the three integrated schemas. In contrast, using Nextia DI the task completion rates are significantly higher, although one participant did not finish the task either. In terms of effort, 87.5% of the participants stress that this task needed considerable effort. As highlighted by participants P5 and P11 A lot of different classes, properties, sequences... from different schemas have to be taken into account, and it is difficult to see the big picture when there is a lot of data and integrate without making mistakes.; and it is hard to ensure everything makes sense to merge elements, respectively. Compared to Nextia DI , 81.3% of the participants said no effort was required. Concerning the time, participants spent an average of 30.06 minutes in the conventional approach. Some participants reported frustration with this task: P1 spent 45 minutes generating one integrated schema, while P15 spent 50 minutes and yet could not complete it. In contrast, participants spent an average of 6.94 minutes with Nextia DI . As participant P1 discusses As the number of class or properties increases, it becomes harder and harder to manually check every possible pair of properties. When asked if the conventional approach for schema integration is feasible, 31.3% of participants reported not feasible. In this line, participants P8 and P10 argument that On top of having to develop the base schemas, having to manually integrate all the elements that are needed to is impossible in a big data context, as the amount of time needed is very large. Additionally, the chances of making a mistake are considerable and The complexity of real datasets makes the integration process not trivial and not accurate. Alternatively, using Nextia DI , 75% of participants reported that schema integration is feasible. As P1 commented since the process is done automatically from the beginning, there is a coherence between how the sources are constructed, making it easy to maintain the elements pointing from the source to the global schema. Concerning quality only 22.22% of the integrated schemata using the conventional approach represent all integrated concepts. Regarding soundness, only 33.33% are compliant with the metamodel. When asked about the participants’ satisfaction, 87.5% are very satisfied and 12.5% satisfied with the results provided by Nextia DI . Some of the comments included it seems to use best practices in modeling, for modeling the global schema; Effortless process. Semantically sound schemas; and it is so easy and it completely merge the entities while keeping the connection to the original schemas. Relevantly, one data modeling expert realized Nextia DI is not able to integrate elements at different granularity (as discussed in Section 5.3). Yet, the participant acknowledged the value of Nextia DI ’s output as a baseline to build a better solution.

OPEN IN VIEWER

Fig. 23.

Aggregated results for the schema integration phase. Completed specifies whether participants finished the task within the available time (higher is better). # of integrated schemas denotes how many schema elements participants managed to integrate in the available time (higher is better). Effort specifies perceived effort to complete the task (lower is better). Satisfaction is used to quantify the perceived satisfaction of running the task with each approach (higher is better). Completeness and Soundness refer to the quality metrics previously introduced.

OPEN IN VIEWER

Fig. 24.

Aggregated results for the mapping generation phase. Completed specifies whether participants finished the task within the available time (higher is better). Effort and Time indicate, respectively, the perceived effort and time to complete the task (lower is better). Feasible is used to quantify the perceived feasibility of the task in Big Data settings (higher is better). Completeness and Soundness refer to the quality metrics previously introduced.

Results on generation of mappings Figure 24 shows the aggregated results for the mapping generation survey, where participants were asked to generate the mappings between the source schemata generated in step 1 and the integrated schema generated in step 2. In the conventional approach, only 37.5% of the participants managed to generate the mappings. Indeed, most participants reported a high level of effort required, while all participants generated the mappings using Nextia DI with 93.8% of them reporting no effort was required. Concerning time, the conventional approach required an average of 20.81 mins for this task. As participant P2 discusses “mapppings as same as schema integration requires a lot of time to verify everything is correct.” In contrast, using Nextia DI the process is immediate due to its bottom-up nature (see Section 6). When asked how feasible is to generate mappings using the conventional approach all participants reported its unfeasibility. Oppositely, using Nextia DI 81.3% and 18.8% said it is very feasible or feasible. Participants emphasize that automation is crucial, precisely P5 commented Nextia DI has a great potential to make Data Integration feasible in Big Data scenarios, as it generates the mappings automatically. and “The system creates the mappings automatically and keeps track of them. In addition it allows to modify/remove the incorrect ones. So, it is quite feasible in a Big Data context”, respectively. Regarding quality, with the conventional approach, 6 mappings files were generated among all participants, being only 33.33% fully complete and sound.

Conclusion. We confirmed that Nextia DI reduced the effort perceived to bootstrap, integrate the data sources and generate mappings (Q1), which is also confirmed by the time reported in all three tasks (Q2). The study also shows that the effort/time required correlates with the size of the schemata to be produced and therefore the number of elements to check. The larger the number of comparisons, the higher the frustration and perceived effort by the participants, which confirms the need for automating such processes. About the quality of the results produced (Q3), Nextia DI automates bootstrapping based on rules at the metamodel level, which guarantees the correctness of the bootstrapped schema from a data modeling point of view. Similarly, the schema integration is based on solid data modeling principles (e.g., based on taxonomies of concepts) that guarantee good quality outputs. This is confirmed by all participants (specially relevant to the positive answer from all data modeling experts in both tasks). Finally, generating mappings is completely transparent in Nextia DI , which is highly appreciated, while the conventional approach requires expertise on data integration to properly conduct the task. All participants were satisfied with the quality of the outputs of Nextia DI and uncertain about the quality of the output they generated in the conventional approach. Importantly, their answers are sound with the qualitative metrics (completeness and soundness) computed and shown in the three figures.

Another relevant conclusion of the experiment, raised by most of the participants, is the difficulty of the tasks at hand due to the required combined skills. In the conventional approach, they spent a considerable amount of time exploring the sources, modeling and expressing schemata and mappings in RDFS. This combined profile is difficult to find in the field of Data Science, specially, knowledge graph experts as shown in Fig. 21. This fact confirms our claim that is not feasible to make the users responsible for generating the schema integration constructs of virtual data integration systems, even for small scenarios. This can explain the low impact of such tools in industry. Fortunately, all participants believe Nextia DI is an improvement to existing approaches.

In order to address research question Q4, we evaluate our two technical contributions (i.e., bootstrapping and schema integration) to assess their computational complexity and runtime performance. All experiments were carried out on a Mac Intel core 2.3 GHz i5 processor with 16GB RAM and Java compiler 11.

7.3.1. Evaluation of bootstrapping

We evaluated the bootstrapping of JSON and CSV data sources by measuring the impact of the schema size. Therefore, we increase the size of the schema elements. This experiment was executed 10 times. We describe the dataset preparation and the results obtained in the following.

Dataset preparation We generated 100 datasets in JSON and CSV format. The initial JSON dataset contains a schema of 100 keys (9 objects and 91 attributes). We incrementally increased the number of schema elements by appending 50 new keys (1 object with 49 attributes) in the schema. For example, the second and third datasets will contain 150 keys (10 objects and 140 attributes) and 200 keys (11 objects and 189 attributes), respectively. For the initial CSV dataset, the schema contains 91 headers, and we incrementally appended 49 new headers.

Results Figure 25 depicts the correlation between time in milliseconds and the number of keys/headers. Note that in both data sources, the time to generate a typed graph schema depends on the size of the schema. JSON bootstrapping requires more time than CSV bootstrapping, since the algorithm will parse one instance of the JSON to extract the JSON schema and apply the production rules. The initial dataset took 27 milliseconds to produce a typed graph, while the last dataset, with a schema of 108 objects and 4942 attributes, took 71 milliseconds. In contrast, CSV bootstrapping only requires the header information to produce a typed graph schema. The initial dataset took 3 milliseconds to produce the typed graph, and the last dataset, with a schema of 4942 headers, took 17 milliseconds. Overall, we can observe some peeks in the trend. However, we consider these peaks are anomalies produced due to the java garbage collector performance, since all results are constant within milliseconds. The performance obtained by the JSON and CSV shows we can rapidly bootstrap the schema in data wrangling tasks.

OPEN IN VIEWER

Fig. 25.

Performance evaluation when the number of schema elements increased.

7.3.2. Evaluation of schema integration

We evaluate the schema integration under three scenarios: (i) increasing the number of alignments in an incremental integration and (ii) integrate a constant number of alignments with a growing number of elements in the schemata and (iii) perform integration using real data.

Experiment 1 – increased alignments Here, the algorithm requires the generation of schemas and alignments that will be integrated incrementally. For the schemata, we reuse the typed graph generated by the initial JSON dataset generated in Section 7.3.1 to generate 100 typed graph schemata. All the resulting schema contain 9 classes, 90 data type properties and 1 object property. We generated the alignments between each pair of typed graph by increasing in one the number of alignments with regard to the previous pair. Therefore, the first integration generates 1 alignment and the last iteration 100 alignments. Figure 26 depicts the correlation between time in milliseconds and the number of alignments. We can observe that the time to integrate schemata depends on the number of alignments. The time to integrate one alignment took two milliseconds, while the integration of 100 alignments took 112 milliseconds. Moreover, in iteration 13, the number of integrated classes converged. Then, the remaining iteration reuses all integrated classes by applying invariant I3 from Algorithm 2. For datatype and object properties, they converged in iterations 35 and 4, respectively. Then, the remaining iterations did not create any new integrated properties. In addition, the final integrated graph contains 1000 classes, 9 integrated classes, 9000 datatype properties, 90 integrated datatype properties, 900 object properties, and 1 integrated object property. Overall, the algorithm efficiently integrates schemas incrementally.

OPEN IN VIEWER

Fig. 26.

Performance evaluation when alignments increased incrementally.

OPEN IN VIEWER

Fig. 27.

Performance evaluation when the number of schema elements increased.

Experiment 2 – increased number of schema elements Here, we generated 100 schemas using JSON datasets where the number of elements in the schema were increased by 50 keys in each iteration. For the generation of alignments, we produced 100 alignments in each iteration since the goal is to measure the impact of the schema size in the integration. Figure 27 depicts the correlation between time in milliseconds and the total number of resources (e.g., classes and properties) in the integrated graph. We observe that the size of the integrated graph impact the time for integrating alignments. The final integrated graph contains 5950 classes, 9 integrated classes, 256500 datatype properties, 90 integrated datatype properties, 5850 object properties and 1 integrated object property. In total 268400 resources. The impact on the time due to the graph size is largely due to how Jena manages the graph in memory (the underlying triplestore used in the experiments). This demonstrates that Nextia DI can handle the integration and propagation of changes faster, even when the integrated schema is large.

Experiment 3 – real data We have selected two tracks of the Ontology Alignment Evaluation Initiative: anatomy and large biomed track. The former contains the Foundational Model of Anatomy (FMA) with 2744 classes and is part of the National Cancer Institute Thesaurus (NCI) with 3304 classes. The alignments provided are 1516 class alignments. The latter contains the FMA with 78998 classes and 15 properties, and NCI with 77269 classes and 186 properties. There are 2686 class alignments for this track. This integration was performed in one step. For the anatomy track, all elements were integrated in 120 milliseconds. The final integrated graph contains 6048 classes and 1516 integrated classes. For the large biomed track, all elements were integrated in 3043 milliseconds with 156267 classes, 2686 integrated classes, 78 data type properties and 123 object properties. Overall, our integration approach is efficient when dealing with large schemas, such as the biomed track.