<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Towards a Benchmark for Knowledge Base Exchange</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Bahar Ghadiri Bashardoost</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Renee J. Miller</string-name>
          <email>miller@northeastern.edu</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Kelly Lyons</string-name>
          <email>klyonsg@cs.toronto.edu</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Northeastern University</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Toronto</institution>
        </aff>
      </contrib-group>
      <abstract>
        <p>As interest in supporting data exchange between heterogeneous knowledge bases (KBs) has increased, so has interest in benchmarking KB exchange systems. One important benchmark, LODIB (Linked Open Data Integration Benchmark), has been proposed that re ects the real and deep heterogeneity of knowledge bases in the Linked Open Data Cloud. In this position paper, we re ect on requirements for benchmarks of KB exchange systems and bring to bear important lessons learned from other data exchange systems. Speci cally, we consider the importance, in data exchange, of explicitly modeling incompleteness, something that is at the heart of relational data exchange and that is solved using principled value invention methods. We also consider the incompleteness that arises naturally within knowledge bases and how that in uences KB exchange. Instances of a single class in a KB may exhibit heterogeneity in their structure and modeling this is important in a KB exchange benchmark. Using these insights, we propose a set of new requirements for a KB exchange benchmark.</p>
      </abstract>
      <kwd-group>
        <kwd>Data Exchange Knowledge bases Benchmarking</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Machines cannot comprehend a large portion of data produced by humans. The
grand vision of the Semantic Web is to be able to create a web-scale decentralized
corpus of information and knowledge that can be processed automatically by
machines [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. Large-scale machine-readable KBs are one of the main enablers
of the Semantic Web vision. These KBs contain rich information about
domainspeci c and general concepts (also known as classes or types), the relationships
among them (also known as properties), and their instances (also known as
individuals). KBs provide a means for machines to be able to make inferences
and answer questions about the knowledge they store. To this end, it is very
important that a KB is populated with relevant facts that model the domain
that the KB tries to represent. However, populating an existing KB is not a
trivial task. One powerful method for KB expansion is to share or exchange
information between di erent, heterogeneous KBs.
      </p>
      <p>
        Researchers have begun to formalize the problem of exchanging knowledge
between a source and a target KB given a set of mapping rules [
        <xref ref-type="bibr" rid="ref3 ref4 ref5 ref7">7, 4, 5, 3</xref>
        ]. In
addition, several tools have emerged which aim to automatically generate mapping
rules between two KBs [
        <xref ref-type="bibr" rid="ref29 ref30 ref32 ref33">30, 32, 29, 33</xref>
        ], making KB exchange1 more achievable
than ever. Naturally, benchmarks are also beginning to be proposed to evaluate
solutions to challenges that arise in practical KB exchange such as expressiveness
of mapping languages used [
        <xref ref-type="bibr" rid="ref34">34</xref>
        ], or the e ciency and the quality of automatic
mapping rule generation [
        <xref ref-type="bibr" rid="ref31 ref34">31, 34</xref>
        ]. Although these benchmarks propose an
important set of criteria for evaluating various aspects of practical KB exchange,
we believe that their evaluation criteria can be enriched to raise the bar for
evaluating KB exchange.
      </p>
      <p>
        Notably, our work considers the materialized exchange of data which can be
distinguished from OBDA and OBDI. In Ontology-based Data Access (OBDA)
the goal is typically to provide a virtual ontology (or KB) interface over databases
expressed in di erent data models (also known as federation or mediation) [
        <xref ref-type="bibr" rid="ref38">38</xref>
        ].
In Ontology-based Data Integration (OBDI), also known as ontology merging,
the goal is to create a single ontology (KB) that represents all information in a
set of source KBs or DBs [
        <xref ref-type="bibr" rid="ref22 ref35 ref37">37, 35, 22</xref>
        ]. Solutions for OBDI mostly assume the
heterogeneity is limited and can be reconciled with simple mappings like same-as,
subclass-of, or equivalent-class. In contrast, both OBDA and KB exchange
use much richer mapping rules that need to be represented using more expressive
mapping languages. The benchmarking of KB exchange can inform the
benchmarking of both OBDA and OBDI. In this position paper, we look at lessons
learned from benchmarks for data exchange and mapping generation systems and
from how KBs are being used in practice. We propose a new set of requirements
for KB mapping generation tools that can be incorporated into benchmarks to
broaden and deepen the tool evaluations. Having such benchmarks can attract
more attention to this important area by highlighting the challenges that remain
and improving the quality of research by pointing out new issues that are unique
to KB exchange.
1.1
      </p>
    </sec>
    <sec id="sec-2">
      <title>Benchmarking Data Exchange</title>
      <p>
        Populating a structured information resource (target) using data translated from
another structured resource (source) is one of the oldest problems in data
management. Data exchange [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ] is a prominent approach for solving this problem
when both source and target adhere to a relational or nested relational data
1 The term KB Exchange was introduced by Arenas et al. [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] and we use it in this
work to distinguish a speci c setting of the data exchange problem in which the
source and target are both KBs.
model. The theory of data exchange was introduced by Fagin et al. [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ]. This
work laid the theoretical foundation of data exchange and identi ed important
tasks in data exchange, including materializing a good target instance and
answering queries. In data exchange, a set of mapping rules specify the relationship
between a source and target schema. As de ned by Fagin et al. [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], given a source
schema, a target schema, an instance of the source schema, and a set of mapping
rules, data exchange is the problem of creating an instance of the target that
re ects the source instance as closely as possible. Fagin et al. de ned when a
target instance is a solution for data exchange and de ned a class of good solutions
(called universal solutions). They also de ned a declarative mapping language
(source-to-target tuple-generating-dependencies) for relational schemas that has
a good balance between expressiveness and algorithmic properties and has since
been widely adopted in tools and generalized to other data models [
        <xref ref-type="bibr" rid="ref2 ref4 ref6">6, 2, 4</xref>
        ]. An
important issue in data exchange is value invention [
        <xref ref-type="bibr" rid="ref21">21</xref>
        ] which is required when
the target models data not present in the source that plays a structural role in
connecting other data [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ].
      </p>
      <p>
        The problem of data exchange assumes that mapping rules are given.
However, in practice one important challenge that needs to be addressed is how to
obtain these mapping rules. These rules can be de ned manually, however the
manual process is burdensome [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ]. As a result, there is a large body of literature
on systems that reduce the burden of creating these rules manually, by making
the rule creation process as automatic as possible. Clio was an early mapping
generation system for relational and XML schemas [
        <xref ref-type="bibr" rid="ref26 ref27">27, 26</xref>
        ], and this has been
followed by dozens of other research and industrial mapping systems [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ]. Most
systems use a set of correspondences between the source and target, and enrich
them using implicit information that lies within the schemas (or instances) of
the source and target to generate semantically correct mapping rules. Systems
that use declarative mapping rules also translate them into executable programs
(such as queries or scripts) that produce a single data exchange solution.
      </p>
      <p>
        Over time, benchmarks have been developed to evaluate these systems. One
of the rst was STBenchmark [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] that proposed the use of mapping
scenarios (or mapping patterns) that represent a set of transformations that should
be supported by any mapping tool. More recently, iBench [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] permits the e
cient creation of benchmarks with large and complex schemas and mappings.
iBench provides control over a large set of mapping characteristics including the
amount and complexity of the value invention required in a correct mapping
solution. Bellahsene et al. [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] provide a survey of work on evaluating both schema
matching and mapping discovery between schemas in di erent data models. An
important (and computationally hard) issue in benchmarking data exchange is
understanding if the solutions produced by mapping rules are always universal
solutions [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ].
1.2
      </p>
    </sec>
    <sec id="sec-3">
      <title>Benchmarking Knowledge Base Exchange</title>
      <p>
        Arenas et al. [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] were one of the rst to investigate data exchange among KBs.
They identi ed the potential incompleteness of a source instance as one of the
main challenges that needs to be addressed in KB exchange [
        <xref ref-type="bibr" rid="ref3 ref4 ref5 ref7">7, 4, 5, 3</xref>
        ]. For an
incomplete source instance, decisions on how to exchange the unknown entities
of the source are not trivial. Another important challenge which arises in KB
exchange is that both atomic values (RDF literals) and individuals (RDF IRIs)
need to be exchanged.
      </p>
      <p>
        Unlike in data exchange, there has been less work focused on automated
generation of mapping rules for KB exchange [
        <xref ref-type="bibr" rid="ref29 ref30 ref32 ref33">30, 32, 29, 33</xref>
        ]. Additionally, a single
declarative mapping constraint language has not been widely adopted, so most
systems generate executable mappings directly which produce a single KB
exchange instance. Most of these tools generate mapping rules by enriching a set
of given correspondences among two KBs, using clues that lie within the
constraints of the KBs [
        <xref ref-type="bibr" rid="ref29 ref30 ref32">30, 32, 29</xref>
        ]. Buhmann et al. [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ] stated that, in practice, there
is a lack of KBs that contain high quality schema axioms and su cient instance
data adhering to the schema. Thus, it is important for KB mapping generation
tools to rely on a small set of axioms which are commonly used in a large
number of KBs to create mappings. Relying on other less used axioms (or axioms
not part of a widely used schema language like RDFS) limits the applicability
of a tool and the ability to compare it with others. Like many KB integration
or alignment approaches [
        <xref ref-type="bibr" rid="ref36 ref37">37, 36</xref>
        ], we think it is reasonable for a mapping
generation tool to require at most a small set of commonly used constructs, (for
example, rdfs:subClassOf, rdfs:domain, rdfs:range, and rdf:type). Such
constructs are present in most KBs (even those that are automatically created
from relational or semi-structured data sets) and are part of the W3C standard
OWL Web Ontology Language. We refer to tools that aid in the generation of
KB mapping rules for KB exchange between two KBs as KMGT.
      </p>
      <p>
        Benchmarks such as STBenchmark and metadata generation tools like iBench
evaluate tools using a set of parameterized mapping scenarios (or mapping
patterns). To evaluate KMGTs, DTSBenchmark [
        <xref ref-type="bibr" rid="ref31">31</xref>
        ], proposed a set of patterns
when the source and target are both KBs. These patterns were later extended in
LODIB (linked open data integration benchmark) [
        <xref ref-type="bibr" rid="ref34">34</xref>
        ]. Since a single mapping
language for KB exchange is not yet widely adopted, LODIB is mainly designed
to benchmark the expressive power of mapping languages. This benchmark has
been also used to evaluate KMGTs. The scenarios proposed in DTSBenchmark
and LODIB represent an important set of transformations that should be
supported by KMGTs. In this paper, we identify additional scenarios that we think
should be supported by any mapping generation tool and any language that aims
to express KB mapping rules. Our goal is to push the research on KB exchange
to the next level.
2
      </p>
      <sec id="sec-3-1">
        <title>Requirements for KMGTs</title>
        <p>We now describe some challenges that every KM GT should address in order
for it to be of use in practical applications of KB exchange. Any benchmark
that aims to evaluate KMGTs should include scenarios that can be used to test
KMGTs' output in the presence of these challenges. Thus, in addition to
describing these challenges, we include example scenarios which can be incorporated in
benchmarks. Note that the challenges discussed in our paper augment and do
not replace other benchmarks.
2.1</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Dealing with Incomplete Correspondences</title>
      <p>
        In data exchange, mapping rules are created by enriching a given set of
correspondences with implicit information which lies within the schemas, the data,
or which is provided by users (through crowd-sourcing or visual interfaces). The
algorithms proposed for generating these rules often assume that the set of given
correspondences is incomplete [
        <xref ref-type="bibr" rid="ref12 ref23 ref24 ref26 ref28">23, 24, 26, 28, 12</xref>
        ]. This is a realistic assumption
since these correspondences are usually the output of an ontology alignment
(a.k.a., schema matching) process. Assuming that an alignment process can
automatically produce all correspondences between two KBs with high precision is
usually unrealistic [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. When the set of correspondences is incomplete, a
mapping generation tool aims to produce mapping rules based on understanding the
di erent ways that corresponding schema elements can be associated with each
other. To the best of our knowledge, current KMGTs assume the input
correspondences are complete. If there is no correspondence to a target element (for
example a property P ), current KMGTs do not populate the element with any
data. We argue instead that if there is source data that could be used to populate
the element (for example, a source property path between source elements that
are matched by correspondences to the target domain and range of P ), then a
useful function of a KMGT is to suggest a (perhaps ranked) list of alternative
ways to populate the unmatched target element.
      </p>
      <p>Unfortunately, the LODIB benchmark does not consider this case since as
mentioned, it is designed to benchmark the expressive power of languages that
represent the mapping rules. DTSBenchmark is designed to benchmark the
KMGTs, however the scenarios proposed in this benchmark always contain
complete sets of correspondences. An example of a scenario that tests the ability of
a KMGT to handle incomplete correspondences is given below.</p>
      <sec id="sec-4-1">
        <title>Scenario 1. Missing Correspondence to a Target Property:</title>
        <p>Figure 1.a represents the RDFS layer of a source and target KB and a
single correspondence which has been identi ed between them. We argue that a
KM GT should create mapping rules that not only translate the source Person
instances into the target Person, but also suggest possible ways of populating
the unmatched related property in the target. For example, a KM GT should
suggest a set of mapping rules that express that if a Person is supervised by
another Person in the source, these two Persons are related in the target. Or
if a Person P1 hasWorkedOn Project J , and a Person P2 is a contributor to
Project J in the source, then P1 should be related to P2 in the target.</p>
        <p>
          A KMGT should be able to suggest a set of mapping rules that are consistent
with the schemas and correspondences (and perhaps rank them if additional
information like data examples are available [
          <xref ref-type="bibr" rid="ref15">15</xref>
          ]). Indeed, a lesson learned from
data exchange is that an important role of KMGTs is in systematically
enumerating possible mappings, something humans do poorly [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ].
2.2
        </p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Knowledge Base Value Invention</title>
      <p>
        Of course, sometimes an unmatched target element cannot be populated with
source data. This occurs often in data exchange. In order to materialize a target
instance, sometimes values need to be lled in for the undetermined elements.
For instance, Clio [
        <xref ref-type="bibr" rid="ref27">27</xref>
        ] creates oids (using Skolem functions), which are unique
identi ers (also called a labeled nulls ), when source data is matched to multiple
relations connected by unmatched target foreign keys. These labeled nulls help
capture some of the structural characteristics of the target data. Similarly, when
dealing with KBs, sometimes a value needs to be created in order to preserve
the associations between the resources of the target KB. As discussed by Arenas
et al. [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], blank nodes in knowledge graphs can play the same role that labeled
nulls play in relational and nested relational data exchange (see [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ] for more
information on blank nodes). Thus similar to relational data exchange, blank
nodes should be used if an association between two transferred values must be
represented and the mapping rules must have enough information to guide the
generation of these blank nodes. Unfortunately, in the benchmarks proposed so
far, there is no scenario that clearly evaluates value invention in KM GT s. We
propose two scenarios in this direction.
      </p>
      <sec id="sec-5-1">
        <title>Scenario 2. Value Invention 1:</title>
        <p>Consider Figure 1.b. An office is not a contact so the IRIs of offices are not
exchanged into contacts. However, the KM GT must be able to create a blank
node which associates address and phone properly. That is, in this scenario a
KM GT should be able to capture a source-to-target dependency which expresses
that for each office in the source that has an address a, and a phone p, a and
p are associated with each other in the target.</p>
        <p>The following example illustrates why supporting the scenario above is
not trivial for KM GT s. Imagine a KM GT produces the following queries as
mapping rules to transfer data from a source to a target. The where clauses of
these queries select data from the source and the construct clauses create the
facts in the target KB using the target structure and the values selected from
the source. These two queries should not be considered correct in a benchmark
evaluation since they do not guarantee that for a single office in the source
with phone 416-345 and address Toronto that a single blank node is created in
the target associated with these same values.</p>
        <p>constructf
?-:a a trgt:Contact.</p>
        <p>?-:a trgt:phone ?trgtPhoneg
wheref
?o a src:Office.
?o src:phone ?srcPhone.
bind(?srcPhone as ?trgtPhone)g
&amp;
constructf
?-:b a trgt:Contact.</p>
        <p>?-:b trgt:address ?trgtAddressg
wheref
?o a src:Office.
?o src:Address ?srcAddress.</p>
        <p>bind(?srcAddress as ?trgtAddress)g</p>
      </sec>
      <sec id="sec-5-2">
        <title>Scenario 3. Value Invention 2:</title>
        <p>Consider Figure 1.c. The di erence between this scenario and Scenario 2 is that
the blank nodes which need to be created are for a concept (Address) which does
not have any data property which participates in a correspondence. However,
appropriate blank nodes need to be created to correctly associate individual
people and their countries in the target.
2.3</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Dealing with an Open-World Assumption</title>
      <p>Traditionally, the data exchange problem is de ned over a setting where the
source instance is assumed to be complete and has a single interpretation.
However, KBs follow an open-world assumption and are by nature incomplete.
The mapping rules which are generated automatically must be able to handle
unknown values in the source KB properly. Consider Figure 1.b and imagine
that a KM GT produced the following query as a mapping rule.</p>
      <p>
        It is straightforward to see that the mapping rule expressed by the SPARQL
query above is not enough to transfer all instances of src:Office. For example
the query above can not be used to transfer information of an Office which
does not have a Phone. One way to x the problem above is to break the above
query into two queries (see Scenario 2). However, as we have seen in Section 2.2,
breaking queries into separate smaller queries is not trivial and can result in
other problems. Another approach when dealing with missing values of KBs is
to use SPARQL's optional keyword [
        <xref ref-type="bibr" rid="ref39">39</xref>
        ] and this approach can be adapted in
KB exchange. Whatever the approach, it is important that a KMGT create a
correct target instance even when the source is incomplete and that a benchmark
include scenarios to test this. An example scenario for testing the ability of a
KM GT to deal with an incomplete source instance is given below.
      </p>
      <sec id="sec-6-1">
        <title>Scenario 4. Missing Values in the Source:</title>
        <p>Consider Figure 1.b. Also, assume that the source instance contains the
following facts: Office(office1), Office(office2), phone(office1, `416-345'), phone(office2,
`416-456'), address(office1, `Toronto'). In this case, it is expected that the
mapping rule can materialize a correct instance of the target such as the following
(where c1 and c2 are blank nodes) Contact(-:c1), Contact(-:c2), phone(-:c1, `416-345'),
phone(-:c2, `416-456'), address(-:c1, `Toronto'). It is important that all data from the
source including office2 with an unknown address be mapped to the
target.
2.4</p>
      </sec>
    </sec>
    <sec id="sec-7">
      <title>Dealing with Cycles</title>
      <p>A cycle can be used in a KB to model the relationships between individuals
of the same type. For instance, Figure 1.a depicts many cycles each modeling a
relationship between two people. This type of cycle is very common. For instance,
any KB created from a social network contains a large number of these cycles,
since social networks model various relationships between instances of a speci c
type. We believe that an algorithm that generates mapping rules should be able
to handle this type of cycle. Scenario 5 can be used to test whether a KM GT
can correctly map a cycle. We have said that an important role of KMGTs is
in systematically enumerating possible mappings. Cycles pose a challenge as the
possible mappings become in nite.</p>
      <sec id="sec-7-1">
        <title>Scenario 5. Property path with same domain and range:</title>
        <p>Consider Figure 1.a. It is expected that a KM GT can generate mapping rules
based on cycles of source and target KBs. For instance a mapping rule for the
setting introduced in this scenario might express something like 2:
8(x; y); x 6= y;
where (x; y) 2 [[((hasSupervisor + (hasW orkedOn:contributor) )
:(hasSupervisor + (hasW orkedOn:contributor) + hasSupervisor )) ]]src
then (x; y) 2 [[related]]trgt
What is important is for a KMGT to consider alternatives to help a mapping
designer to arrive at a semantically correct mapping.</p>
        <p>Not all mapping languages will contain recursion so a KMGT may create
mappings that only traverse a cycle a x number of times. Nonetheless, a
benchmark should include scenarios containing cycles and where di erent mappings
are desired, some that include a single traversal (e.g., only an immediate
supervisor) and some that include more (e.g., all supervisors and their supervisors).
3</p>
        <p>
          Vision for Knowledge Base Exchange Benchmarks
Data exchange between heterogeneous data sources is important for sharing data
among organizations but, until recently, much of the data exchange research
has focused on relational and nested relational data models. Initiatives such as
ontology based data access (OBDA) [
          <xref ref-type="bibr" rid="ref38">38</xref>
          ] aim to facilitate the exchange of data
between a relational source and a target KB. New exciting work is emerging on
the theory and practice of KB exchange, where a KB can be used to expand
the knowledge contained in another KB. We believe that expanding the current
set of benchmarks in a principled way can enhance research in both mapping
generation and KB exchange.
        </p>
        <p>
          Our position paper enumerates a few important benchmarking issues, but
of course is not complete. One issue that we did not include is dealing with
instances with multiple most-speci c types. Suppose that in a source KB two
concepts Employee and Student are sub-classes of another concept Person. Now
2 Notation borrowed from Kostylev et al. [
          <xref ref-type="bibr" rid="ref25">25</xref>
          ].
assume that instance i is both an Employee and a Student and instance j is
only an Employee. Then the mapping rules generated should be able to transfer
i and j to the target while respecting the fact that i and j share some properties
while di ering on other properties.
        </p>
        <p>
          Benchmarking KB exchange presents many important new research
challenges. Testing whether a set of mappings is equivalent can already be
undecidable for data exchange and is more complex for KB exchange [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ]. For a
benchmark, we must develop new scalable ways of testing if mappings (or KB exchange
solutions) for a benchmark are correct and su cient. Duo et al. [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ] argue that
when it comes to the problem of exchanging data between two KBs, even
checking that a given set of mapping rules is consistent with each other and with the
axioms of the source and the target KBs is not a trivial task. The consistency
of a set of mapping rules generated by a KM GT can be a powerful measure of
quality that benchmarks can report. Thus, we also suggest new approaches need
to be proposed to be able to e ciently evaluate the consistency of the mapping
rules generated by a KM GT .
        </p>
        <sec id="sec-7-1-1">
          <title>Acknowledgement</title>
          <p>This research was supported in part by a Natural Sciences and Engineering
Research Council (NSERC) Strategic Partnership Grant.</p>
        </sec>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Alexe</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tan</surname>
            ,
            <given-names>W.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Velegrakis</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>Stbenchmark: towards a benchmark for mapping systems</article-title>
          .
          <source>PVLDB</source>
          <volume>1</volume>
          (
          <issue>1</issue>
          ),
          <volume>230</volume>
          {
          <fpage>244</fpage>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Amano</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Libkin</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Murlak</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          :
          <article-title>Xml schema mappings</article-title>
          .
          <source>In: ACM PODS</source>
          . pp.
          <volume>33</volume>
          {
          <issue>42</issue>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Botoeva</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calvanese</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Knowledge base exchange</article-title>
          . In: International Workshop on Description Logics. p.
          <volume>4</volume>
          (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Botoeva</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calvanese</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ryzhikov</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          :
          <article-title>Knowledge base exchange: The case of owl 2 ql</article-title>
          .
          <source>Arti cial Intelligence</source>
          <volume>238</volume>
          ,
          <fpage>11</fpage>
          {
          <fpage>62</fpage>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Botoeva</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calvanese</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ryzhikov</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sherkhonov</surname>
          </string-name>
          , E.:
          <article-title>Exchanging description logic knowledge bases</article-title>
          .
          <source>In: KR</source>
          . AAAI Press (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Libkin</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Xml data exchange: consistency and query answering</article-title>
          .
          <source>JACM</source>
          <volume>55</volume>
          (
          <issue>2</issue>
          ),
          <volume>7</volume>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perez</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reutter</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          :
          <article-title>Data exchange beyond complete data</article-title>
          .
          <source>JACM</source>
          <volume>60</volume>
          (
          <issue>4</issue>
          ),
          <volume>28</volume>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Arocena</surname>
            ,
            <given-names>P.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Glavic</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ciucanu</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.:</given-names>
          </string-name>
          <article-title>The ibench integration metadata generator</article-title>
          .
          <source>PVLDB</source>
          <volume>9</volume>
          (
          <issue>3</issue>
          ),
          <volume>108</volume>
          {
          <fpage>119</fpage>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Arocena</surname>
            ,
            <given-names>P.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Glavic</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.:</given-names>
          </string-name>
          <article-title>Value invention in data exchange</article-title>
          .
          <source>In: SIGMOD</source>
          . pp.
          <volume>157</volume>
          {
          <issue>168</issue>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Bellahsene</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bonifati</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Duchateau</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Velegrakis</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>On evaluating schema matching and mapping</article-title>
          .
          <source>In: Schema matching and mapping</source>
          , pp.
          <volume>253</volume>
          {
          <fpage>291</fpage>
          . Springer (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Berners-Lee</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hendler</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lassila</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          :
          <article-title>The semantic web</article-title>
          . Scienti c american
          <volume>284</volume>
          (
          <issue>5</issue>
          ),
          <volume>28</volume>
          {
          <fpage>37</fpage>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Bonifati</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mecca</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pappalardo</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Raunich</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Summa</surname>
          </string-name>
          , G.:
          <article-title>Schema mapping veri cation: The spicy way</article-title>
          .
          <source>In: EDBT</source>
          . pp.
          <volume>85</volume>
          {
          <fpage>96</fpage>
          .
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Bonifati</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mecca</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Papotti</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Velegrakis</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>Discovery and correctness of schema mapping transformations</article-title>
          .
          <source>In: Schema matching and mapping</source>
          , pp.
          <volume>111</volume>
          {
          <fpage>147</fpage>
          . Springer (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14. Buhmann, L.,
          <string-name>
            <surname>Lehmann</surname>
          </string-name>
          , J.:
          <article-title>Universal owl axiom enrichment for large knowledge bases</article-title>
          .
          <source>In: EKAW</source>
          . pp.
          <volume>57</volume>
          {
          <fpage>71</fpage>
          . Springer (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>ten Cate</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kolaitis</surname>
            ,
            <given-names>P.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tan</surname>
            ,
            <given-names>W.C.</given-names>
          </string-name>
          :
          <article-title>Schema mappings and data examples</article-title>
          .
          <source>In: EDBT</source>
          . pp.
          <volume>777</volume>
          {
          <fpage>780</fpage>
          .
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Dou</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>McDermott</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Qi</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Ontology translation on the semantic web</article-title>
          .
          <source>In: Journal on data semantics II</source>
          , pp.
          <volume>35</volume>
          {
          <fpage>57</fpage>
          . Springer (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Euzenat</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shvaiko</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          : Ontology Matching. Springer, 2nd edn. (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Fagin</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Haas</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Popa</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Velegrakis</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>Clio: Schema mapping creation and data exchange. Conceptual modeling: foundations</article-title>
          and applications pp.
          <volume>198</volume>
          {
          <issue>236</issue>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Fagin</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kolaitis</surname>
            ,
            <given-names>P.G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Popa</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Data exchange: semantics and query answering</article-title>
          .
          <source>Theoretical Computer Science</source>
          <volume>336</volume>
          (
          <issue>1</issue>
          ),
          <volume>89</volume>
          {
          <fpage>124</fpage>
          (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Hogan</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mallea</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Polleres</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Everything you always wanted to know about blank nodes</article-title>
          .
          <source>Journal of Web Semantics</source>
          <volume>27</volume>
          ,
          <issue>42</issue>
          {
          <fpage>69</fpage>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <surname>Hull</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Yoshikawa</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>ILOG: declarative creation and manipulation of object identi ers</article-title>
          .
          <source>In: VLDB</source>
          . pp.
          <volume>455</volume>
          {
          <issue>468</issue>
          (
          <year>1990</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>Jimenez-Ruiz</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Grau</surname>
            ,
            <given-names>B.C.</given-names>
          </string-name>
          :
          <article-title>Logmap: Logic-based and scalable ontology matching</article-title>
          .
          <source>In: ISWC</source>
          . pp.
          <volume>273</volume>
          {
          <fpage>288</fpage>
          . Springer (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <surname>Kimmig</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Memory</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Getoor</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>A collective, probabilistic approach to schema mapping</article-title>
          .
          <source>In: ICDE</source>
          . pp.
          <volume>921</volume>
          {
          <issue>932</issue>
          (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          24.
          <string-name>
            <surname>Kimmig</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Memory</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Getoor</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>A collective, probabilistic approach to schema mapping using diverse noisy evidence</article-title>
          .
          <source>TKDE</source>
          (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          25.
          <string-name>
            <surname>Kostylev</surname>
            ,
            <given-names>E.V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reutter</surname>
            ,
            <given-names>J.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Romero</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vrgoc</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Sparql with property paths</article-title>
          .
          <source>In: ISWC</source>
          . pp.
          <volume>3</volume>
          {
          <fpage>18</fpage>
          . Springer (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          26.
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Haas</surname>
            ,
            <given-names>L.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>M.A.</given-names>
          </string-name>
          :
          <article-title>Schema mapping as query discovery</article-title>
          .
          <source>In: VLDB</source>
          . vol.
          <year>2000</year>
          , pp.
          <volume>77</volume>
          {
          <issue>88</issue>
          (
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          27.
          <string-name>
            <surname>Popa</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Velegrakis</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>M.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fagin</surname>
          </string-name>
          , R.:
          <article-title>Translating web data</article-title>
          .
          <source>In: VLDB</source>
          . pp.
          <volume>598</volume>
          {
          <issue>609</issue>
          (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          28.
          <string-name>
            <surname>Qian</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cafarella</surname>
            ,
            <given-names>M.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jagadish</surname>
          </string-name>
          , H.:
          <article-title>Sample-driven schema mapping</article-title>
          .
          <source>In: SIGMOD</source>
          . pp.
          <volume>73</volume>
          {
          <fpage>84</fpage>
          .
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          29.
          <string-name>
            <surname>Qin</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dou</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          , LePendu, P.:
          <article-title>Discovering executable semantic mappings between ontologies</article-title>
          . OTM pp.
          <volume>832</volume>
          {
          <issue>849</issue>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          30.
          <string-name>
            <surname>Rivero</surname>
            ,
            <given-names>C.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruiz</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Corchuelo</surname>
          </string-name>
          , R.:
          <article-title>Generating sparql executable mappings to integrate ontologies</article-title>
          .
          <source>In: ER</source>
          . pp.
          <volume>118</volume>
          {
          <fpage>131</fpage>
          . Springer (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          31.
          <string-name>
            <surname>Rivero</surname>
            ,
            <given-names>C.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruiz</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Corchuelo</surname>
          </string-name>
          , R.:
          <article-title>On benchmarking data translation systems for semantic-web ontologies</article-title>
          .
          <source>In: CIKM</source>
          . pp.
          <volume>1613</volume>
          {
          <fpage>1618</fpage>
          .
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          32.
          <string-name>
            <surname>Rivero</surname>
            ,
            <given-names>C.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruiz</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Corchuelo</surname>
          </string-name>
          , R.:
          <article-title>Exchanging data amongst linked data applications</article-title>
          .
          <source>Knowl Inf Syst</source>
          <volume>37</volume>
          (
          <issue>3</issue>
          ),
          <volume>693</volume>
          {
          <fpage>729</fpage>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref33">
        <mixed-citation>
          33.
          <string-name>
            <surname>Rivero</surname>
            ,
            <given-names>C.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hernandez</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruiz</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Corchuelo</surname>
          </string-name>
          , R.:
          <article-title>Mapping rdf knowledge bases using exchange samples</article-title>
          .
          <source>Knowledge-Based Systems 93</source>
          ,
          <fpage>47</fpage>
          {
          <fpage>66</fpage>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref34">
        <mixed-citation>
          34.
          <string-name>
            <surname>Rivero</surname>
            ,
            <given-names>C.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schultz</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bizer</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruiz Cortes</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Benchmarking the performance of linked data translation systems</article-title>
          . In: LDOW.
          <string-name>
            <surname>CEUR-WS</surname>
          </string-name>
          (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref35">
        <mixed-citation>
          35.
          <string-name>
            <surname>Stumme</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maedche</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Fca-merge: Bottom-up merging of ontologies</article-title>
          .
          <source>In: IJCAI</source>
          . vol.
          <volume>1</volume>
          , pp.
          <volume>225</volume>
          {
          <issue>230</issue>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref36">
        <mixed-citation>
          36.
          <string-name>
            <surname>Suchanek</surname>
            ,
            <given-names>F.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Abiteboul</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Senellart</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          : Paris:
          <article-title>Probabilistic alignment of relations, instances, and schema</article-title>
          .
          <source>PVLDB</source>
          <volume>5</volume>
          (
          <issue>3</issue>
          ),
          <volume>157</volume>
          {
          <fpage>168</fpage>
          (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref37">
        <mixed-citation>
          37.
          <string-name>
            <surname>Udrea</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Getoor</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Miller</surname>
            ,
            <given-names>R.J.</given-names>
          </string-name>
          :
          <article-title>Leveraging data and structure in ontology integration</article-title>
          .
          <source>In: SIGMOD</source>
          . pp.
          <volume>449</volume>
          {
          <fpage>460</fpage>
          .
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref38">
        <mixed-citation>
          38.
          <string-name>
            <surname>Xiao</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calvanese</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kontchakov</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lembo</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Poggi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rosati</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zakharyaschev</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Ontology-based data access: A survey</article-title>
          .
          <source>IJCAI</source>
          (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref39">
        <mixed-citation>
          39.
          <string-name>
            <surname>Xiao</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kontchakov</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cogrel</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Calvanese</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Botoeva</surname>
          </string-name>
          , E.:
          <article-title>E cient handling of sparql optional for obda</article-title>
          .
          <source>In: ISWC</source>
          . pp.
          <volume>354</volume>
          {
          <fpage>373</fpage>
          . Springer (
          <year>2018</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>