[orcid=0000-0002-4489-9025, bioid=1]

[1]

[1]

1]organization=Department of Electrical Engineering and Computer Science,
Hochschule Niederrhein University of Applied Sciences,
addressline=Reinarzstrasse 49, city=Krefeld, postcode=47805, state=NRW,
country=Germany

[orcid=0000-0002-2639-1949]

2]organization=Chair of Databases and Information Systems, RWTH Aachen
University, addressline=Ahornstraße 55, Aachen, city=Aachen, postcode=52074,
state=NRW, country=Germany

[orcid=0000-0002-1698-4345]

3]organization=Department of Data Science and Artificial Intelligence,
Fraunhofer Institute for Applied Information Technology FIT,
addressline=Schloss Birlinghoven, city=St. Augustin, postcode=53757,
state=NRW, country=Germany

[1]Corresponding author

# Semantic Data Management in Data Lakes

Sayed Hoseini<EMAIL_ADDRESS>[  Johannes Theissen-Lipp  [
Christoph Quix  [

###### Abstract

In recent years, data lakes emerged as a way to manage large amounts of
heterogeneous data for modern data analytics. One way to prevent data lakes
from turning into inoperable data swamps is semantic data management. Some
approaches propose the linkage of metadata to knowledge graphs based on the
Linked Data principles to provide more meaning and semantics to the data in
the lake. Such a semantic layer may be utilized not only for data management
but also to tackle the problem of data integration from heterogeneous sources,
in order to make data access more expressive and interoperable. In this
survey, we review recent approaches with a specific focus on the application
within data lake systems and scalability to Big Data. We classify the
approaches into (i) basic semantic data management, (ii) semantic modeling
approaches for enriching metadata in data lakes, and (iii) methods for
ontology-based data access. In each category, we cover the main techniques and
their background, and compare latest research. Finally, we point out
challenges for future work in this research area, which needs a closer
integration of Big Data and Semantic Web technologies.

###### keywords:

Semantic Data Management Semantic Web Big Data Data Lakes Ontology-based Data-
Access

Definitions and Taxonomy: Provides clear definitions of terms related to
Semantic Data Management and presents a taxonomy, classifications and
comparisons of systems and approaches in this area.

Review of metadata models for data lake systems: Reviews metadata models for
data lake systems that address semantics, defines requirements, derives
evaluation criteria, and performs a detailed comparison.

Approaches for Semantic Modeling: Details algorithms for creating semantic
models, distinguishing between semantic labeling and semantic modeling
approaches..

Ontology-Based Data Access: Explores the use of semantic information for OBDA,
where a Knowledge Graph serves as a common data model for specifying queries,
and reviews scalable approaches for query processing over Big Data including a
comparison and historical timeline.

Challenges in Semantic Data Management: Discusses the challenges that remain
to be addressed in the field of semantic data management.

##  1 Introduction

Due to the growing dependence on data, its seamless provision and consumption
becomes more and more important for different stakeholders. Data lakes have
been proposed to tackle challenges in managing unstructured and structured
data sources [1]. Many organizations have established data lakes to collect
data from heterogeneous sources, which can then be used in data science
projects [2, 3, 4, 5].

The description of data sources with meaningful metadata is essential for the
usability of data. Especially for users with limited domain knowledge, or when
they are unfamiliar with a data set, meaningful metadata are indispensable.
The mapping of raw data from data sources to semantically rich models
increases the usability and interpretability of data. Here, the usage of
knowledge graphs (KGs) equipped with an expressive ontology to ensure well-
defined meaning [6, 7] has proven useful in various ways, e.g., for data
integration using ontology-based data access (OBDA) [8].

These advantages have been recognized in data lake research and practice in
the recent years. While first implementations aimed at processing Big Data
efficiently using distributed, scalable systems (such as Hadoop), the need for
proper management of metadata and data quality has also been recognized [9,
10]. Several approaches have been proposed for semantic data management (SDM)
in data lakes. Semantic data lakes need to integrate Big Data and Semantic Web
technologies. In the Semantic Web, the Resource Description Framework (RDF)
and the Web Ontology Language (OWL) are the main languages to represent data
as a set of linked data items [11]. These languages can be used also to
represent metadata in form of ontologies or KGs. Although the technologies for
linked data and the Semantic Web have become more mature in the recent years,
the amount of data considered in Semantic Web applications is far less than in
Big Data applications. Thus, scalability to large, heterogeneous data sets is
major challenge for applying Semantic Web technologies in data lakes.

Figure 1: Semantic data management for heterogeneous data sources in a data
lake. Most concepts of the semantic model are drawn from the KG, but in order
to describe specific data sets one may define novel classes and relationships.

Semantic data extends the regular, extractable metadata (e.g., schema, data
types) to convey context information that is not inherent to the individual
data source at hand. According to [12], there are two important processes that
ensure the quality and acceptance of SDM: (1) the creation and maintenance of
conceptualizations as well as (2) the description of data sources in the form
of semantic models, i.e., linking source schemas to the conceptualization. A
semantically well-annotated data source can be discovered using the conceptual
representations of the data and understood using the provided context
information stored in the model. The creation of such semantic models involves
decoding the current data source, checking suitable KGs, and linking data
attributes to concepts in the KG. The KG can therefore be seen as a common
data model which provides a conceptual description of the data resources of an
organization. As companies recognize the increasing value of data for their
business processes, such models are frequently being established as part of a
data governance strategy or a master data management program [13]. The
modeling of a KG is a complex process which requires human intelligence; in
this article, we focus on the mapping between data sources and the KG. We
assume that the KG is already available; it might be extended during semantic
modeling to capture the complete semantics of the data sources.

The semantic model can be viewed as a _projection_ of the entities and
relationships of the KG onto the data sources. The semantic model is an
additional layer between the data layer and the knowledge layer [2]. The basic
idea of the semantic model is sketched in Figure 1. The raw data sets in the
data lake are represented in the lower data layer; they can be in different
formats, such as tabular data or hierarchical JSON data, but have partially
overlapping content. Typically, data lakes are able to extract schema
information from the sources automatically. The semantic model can be
represented as a graph with nodes and edges derived from the KG, enriched with
nodes and edges to represent the mapping and the extended semantics of the
data sources. In the example of Figure 1, we reuse concepts and properties
from the WikiData ontology (prefix wd) as a part of our KG. By explicitly
encoding the semantic type and relationship between source attributes in the
graph, the semantic model precisely describes the intended meaning of the data
source. A SDM platform should support the process, e.g., by proposing
appropriate concepts and related mappings when creating the semantic model.

Furthermore, instead of only using a static KG, the semantic model may also
introduce novel classes and properties. This need for evolution arises when
users provide data sources that include concepts and relationships which are
not covered by the KG. In the example, the JSON document contains data about a
specific cinema (prefix cd (cinema domain)) that needs to be modeled
explicitly. This novel knowledge needs to be incorporated in a structured way,
thereby continuously evolving the knowledge layer [14].

_Semantic labels_ are the direct annotations of elements of the data source
(e.g., schema attributes) with elements of the semantic model. The semantics
are defined by a suitable predicate and object. A semantic label is usually
represented as a triple: (schema attribute, predicate, object). In Figure 1,
the semantic label of the table’s attribute “Title” is constructed through the
object “wd:film” and the predicate “wd:title” modeling the relationship
between them. A semantic data lake should assist the extraction of a semantic
model from the raw data sets, i.e., a more conceptual description of data sets
including concepts and their relationships. The semantic models are then
linked to the data sets to know which data set is related to which concept
[13].

In Figure 2, we propose an extended version of the data lake architecture in
[15], where especially metadata-related functions are enriched with semantics.
For example, a semantic labeling component in the ingestion layer adds
semantic labels to the extracted metadata elements. Data quality (DQ)
management can be also improved, e.g., by verifying whether semantic
information is present for a data source. The semantic information (labels,
models, KG, etc.) is managed in the storage layer in an extend semantic
metadata repository, which provides, for example, the mappings required for
OBDA. In particular, the semantic metadata should facilitate the usage and
interpretation of data. Therefore, the interaction layer has several
additional components, e.g., for browsing the KG and semantic models, for
defining queries using a semantic query language such as
SPARQL111https://www.w3.org/TR/rdf-sparql-query/, and editors for refining the
semantic mappings and models.

Figure 2: Semantic data lake architecture, extended from [15]

###  1.1 Related surveys, research methodology and contribution

In this survey, we give an overview of the recent developments in SDM related
to semantic data lakes in particular. In contrast to other surveys in this
field, discussed briefly in the following, we focus especially on approaches
which can be scaled up to Big Data and facilitate the semantic integration of
data.

Sawadogo et al. [16] focus on generic data lake architectures and metadata
management and discuss the pros and cons of data lakes and their design
alternatives. Similarly, Hai et al. [17] present a comprehensive overview of
research questions for designing and building general data lakes. They
classify the existing approaches and systems based on their provided functions
for data lakes and provide a thorough comparison of existing solutions and the
discussion of open research challenges.

Paulus et al. [12] investigate existing semantic modeling approaches, discuss
their strengths and weaknesses for real-world use and present future
challenges and necessary research directions that the community needs to focus
on in order to make semantic data management acceptable in everyday business.
Data lakes and scalability to Big Data is not in the focus of Paulus et al.

Xiao et al. present first a more theoretical discussion on the formal
implementation details in OBDA [18]. In a follow-up work [8], they present the
tooling ecosystem and concrete use cases in a wide range of commercial
applications. Additional works in this context and a more detailed discussion
can be found in Section 4.

A recent survey by Liu et al. [19] reviews approaches for semantic labeling
(see Section 2.2). It is closely related to this work, but we take a more
holistic approach. We address the complete process, starting from SDM in
general in semantic data lakes, to semantic modeling for data integration and
finally OBDA. In each section, we focus especially on the applicability to
data lakes and Big Data. To provide a clear and logical presentation, we were
inspired by the pipeline presented by [20] (see Figure 3), which has been
extended by OBDA, because it provides a uniform data access interface for
heterogeneous data in data lakes.

Figure 3: Overview of the phases during the automated generation of a semantic
model as illustrated in [20] extended by OBDA

To collect the relevant papers, we made use of Google Scholar primarily. We
first used a list of keywords, which was manually created when reading
relevant papers starting from e.g. [12, 13, 21]) and evolved dynamically
during the course of the writing: ‘semantic data lake’, ‘knowledge graph data
lake’, ‘semantic data catalog’, ‘semantic data integration’, ‘semantic /
ontology-based data management’, ‘semantic models’, ‘semantic annotation’,
‘semantic table interpretation’, ‘semantic type detection’, ‘ontology-based-
data-access’. For each query, we first retrieve relevant results by importing
the DOI into Citavi, a program for reference management, then read each
retrieved paper to judge whether the paper is relevant for one of the three
domains of interest (Semantic Data Lakes, Semantic Data Management /
Integration, OBDA). From there we assigned each paper to a category resembling
the structure of this article. We made heavy use of the citation snowballing
method [22], i.e., extending the results by searching through the cited
references in the initial keyword-based findings as well as exploiting the
‘Cited By’ functionality in Google Scholar. The commercial systems were found
using Google Search.

In summary, this article makes the following contributions:

  * •

A definition of the terms related to SDM is provided in section 2.1. Terms
like semantic models or semantic labels are frequently used in the context of
SDM; in order to make a proper classification and comparison of systems and
approaches in this area, we first need clear definitions. Additionally, a
taxonomy (Figure 4) of the various notions is presented as a high-level
overview.

  * •

Following the basic definitions for SDM, we review metadata models and data
lakes addressing semantics in some way in sections 2.2 to 2.6. We define
requirements for metadata models and data lakes, derive criteria for
evaluation, and perform a detailed comparison.

  * •

Section 3 addresses in detail approaches for semantic modeling, i.e.,
algorithms for creating the semantic models (as sketched in Figure 1)
(semi-)automatically. We distinguish between approaches for semantic labeling
and semantic modeling.

  * •

The most advanced use of semantic information is for ontology-based data
access (OBDA). A KG is used as common data model for specifying queries; OBDA
systems take mappings to data sources into account and translate queries into
the query language of the particular data source. Especially in this context,
scalable approaches are required for query processing over Big Data. We review
several systems in this area that have been proposed in the recent years
(section 4).

  * •

In Section 5, we discuss two application areas for SDM in data lakes:
Industrial Internet-of-Things and Smart Cities. This shows that the SDM
techniques can be applied to real-world use cases.

  * •

Finally, we derive in section 6 challenges that still need to be addressed in
the field of semantic data management.

##  2 Semantic Data Management in Data Lakes

We will first provide definitions for the main terms used in this survey
(section 2.1) and discuss in detail the distinction between semantic labeling
and semantic modeling (section 2.2). The subsequent sections then review the
state of the art for metadata models for data lakes with semantics (section
2.3), semantic data lake systems (section 2.4), and commercial systems
(section 2.5). The final subsection summarizes the discussion and provides a
detailed comparison.

###  2.1 Definitions

We have been using terms like semantic data lakes, semantic labels, and
semantic models in the introduction and now clarify their meaning. All given
definitions should be general and are not limited to a specific technology.
Semantic tools often apply W3C standards (e.g., RDF, OWL), but some industrial
solutions do not focus on compatibility with a standard but model KGs and
semantic metadata in a different way.

######  Definition 1.

[Data lake] “A data lake is a flexible, scalable data storage and management
system, which ingests and stores raw data from heterogeneous sources in their
original format, and provides query processing and data analytics in an on-
the-fly manner.” [17]

In particular, here query processing in an on-the-fly-manner refers to the ELT
(Extract-Load-Transform) principle [15]. In data warehouses, the classical ETL
(Extract-Transform-Load) idea is applied: data is transformed into a uniform
schema before it is loaded. Only then, queries can be executed on this
integrated data set. In data lakes, raw data is stored in a heterogeneous
storage layer, query processing needs to be able to work with heterogeneous
storage systems (e.g., as Apache Spark does with its query language SparkSQL).
In the Big Data context, this behavior is also referred to as schema-on-read.
This is also an important aspect for the scope of this survey: we only
consider approaches that do not require the data to be converted into a
uniform schema, as such approaches are just not scalable to Big Data.

######  Definition 2.

[Semantic data lake] Semantic data lakes are a specific form of traditional
data lakes which extend the capabilities through a semantic layer that
enriches and connects the stored data semantically. The semantic layer equips
data sets in the lake with connections from the data set’s metadata to
conceptual/logical models, which encapsulate knowledge potentially external to
the content of the data, such as domain knowledge.

######  Definition 3.

[Semantic labels] Semantic labels manifest the connection between data sources
and concepts of a conceptualization with the objective to describe the
semantics of the data source’s attribute to which the label is associated to.

Semantic labels are the core concept of implementing semantic data management
in practice. They complement extractable metadata (such as data types, sizes,
formats, etc.) to convey context information which may not be inherent to the
data source at hand. The most common semantic labels are those which connect
elements of a data source’s schema in a One-to-one-relationship, e.g., the
column of a table or a leaf node in a hierarchical/nested data set (e.g., JSON
file), to their counterparts from a KG as previously described. However, they
can also be used for example on the level of individual data values, for a
specific row of the table, to denote relationships between individual schema
entries, the entire data set, or any other relevant concept. In the
literature, various terms are used for semantic labels, for example, semantic
enrichment, links, tags, types, profiling, or annotations [23, 24, 25, 16].
The idea behind semantic labels differs from approaches that model their
entire metadata/data catalog as a KG, such as Aurum [26], by the fact that
their primary objective is to provide context, hence additional information
from external sources, in contrast to the latter which store metadata in a
graph-based data model.

In the area of OBDA (see section 4), the term mapping is also commonly used.
Mappings establish a connection between data attributes and KGs and they are
the technical prerequisite for query rewriting, e.g., from SPARQL to SQL.
While mappings in OBDA refer to different notions technically, on a conceptual
level however, they can be regarded as closely related to semantic labels,
because essentially they connect the metadata of a data source to instances of
a conceptualization. The main difference is that mappings in OBDA require a
precise semantics in order to rewrite queries correctly. Semantic labels are
usually not defined with precise semantics in mind, as they aim at providing
more context information to the user or at connecting related data sets.

######  Definition 4.

[Semantic models] A semantic model specifies the broader context of a data
source by extending the semantic labels through additional meaningful concepts
and provides suitable relationships that hold between various concepts.

Figure 4: A Taxonomy for the concepts and methods discussed in this survey

To make the definitions more clear, we provide a rough formalization,
explained by referring to the case study of Figure 1. We consider two data
sources stored in a data lake, a table and a JSON file where each data source
$D$ consists of a set of attributes $D=(c_{1},...,c_{n})$ (i.e., columns in a
table or paths in hierarchical data sets, respectively). For the
conceptualization, we consider a standard knowledge graph $KG$ defined by a
set of RDF triples in the form of subject-predicate-object: $(s,p,o)$.

The idea behind a semantic label for $c_{i}$ is to best describe the semantics
of $c_{i}$ by defining a triple $SL_{c_{i}}=(c_{i},p,o)$, with $p$ and $o$
preferably, but not necessarily, coming from $KG$. For example, the semantic
label for the JSON key “tickets_sold” is represented as the triple:
(tickets_sold, cd:sellsTickets, cd:cinema_x). Here, $p$ and the $o$ are novel
concepts for a specific domain, that are not present in this form in the
general-purpose ontology of WikiData. Users may incorporate these novel facts
into the overall knowledge layer, thereby evolving it dynamically. On the
other hand, the table’s column “Title” and the JSON’s key “movie” possess the
same predicate and object and therefore provide a suitable entry point for
data integration between the two heterogeneous data sets.

The semantic model $SM$ is a set of triples built upon the set of semantic
labels $SL=\\{SL_{c_{1}},\ldots,SL_{c_{n}}\\}$. In order to specify the
broader context of the data source $D$, it may additionally contain further
nodes and edges drawn from $KG$ denoted as $SM_{KG}$. The semantic model can
be extend by concepts and relationships of the sources, which are not
represented in $KG$. We denote this extension of the semantic model as
$SM_{X}$. Note that $SL$, $SM_{KG}$, and $SM_{X}$ are pairwise disjoint.

$SM=SL\cup SM_{KG}\cup SM_{X}$
(cd:cinema_x, cd:playsFilm, wd:film) $\in SM_{X}$
(wd:film director, rdfs:domain, wd:film) $\in SM_{KG}$
(”Title”, wd:title, wd:Film) $\in SL$

The given case study is restricted to the schema of the two data sources for
the purpose of illustration, but the same formalization can be generalized to
various scenarios. Naturally, it can easily be applied to other concepts in
the data layer, e.g., entire data sets and relationships between them (replace
$c_{i}$ with data set $d_{i}$). In Figure 1, modeling the film genre of the
movie “The Matrix” on the level of individual data entries (single row/object
or specific cell entry/value in the table/JSON) of the data sources could have
been included.

Some approaches, like DoDuo [27], establish the relationship between any two
columns in a table directly via a predicate without an intermediate element of
the semantic model in between. For example, the triple is composed of two
table columns and only the predicate comes from the conceptualization:
$(c_{i},p,c_{j})$. Semantic labels, especially when considered as ‘weak’
annotations, are frequently also modeled as just an additional field in the
metadata repository and not expressed as a triple in RDF, e.g., in GEMMS [25].
If one thinks of the predicate being isRelatedTo, the given formalization
still applies with no further specification.

###  2.2 Semantic Data Management Taxonomy

In Figure 4, we have structured the various concepts and methods discussed in
this survey into a taxonomy. The approaches are horizontally separated by the
three main areas addressed in this article: data management, knowledge
management and their particular intersection SDM. We further differentiate
five dimensions vertically which gradually decrease the level of abstraction
to culminate into concrete applications which are described throughout the
article. The first dimension represents higher-level conceptual components; in
this article, these include a data lake system (i.e., (No)SQL sources and
their metadata), semantic labels and models, as well as serialized knowledge
in the form of KGs in the second dimension. In the third dimension the
semantic layer includes functionality that a semantic data lake system may
implement to generate the semantics required for effective SDM, which are
implemented by different methods in fourth dimension.

Semantic labeling is the process of creating semantic labels for a data
source. In the literature, the automation of this process is also denoted as
Semantic Type Detection (STD) [28] or Semantic Table Interpretation (STI)
[19]. Burgdorf et al. [29] identify three different directions for this task:
schema-driven, i.e., using the schema of each data point within a data set,
such as [30, 31]; data-driven, i.e., using the actual data values contained in
a data set to assign fitting concepts with statistics or machine-learning-
based classification, such as [32, 33, 34]; metadata-driven, i.e., using all
available additional pieces of information on a data set that might contribute
to the semantic labeling of the data, e.g., comments or textual data
documentation, such as [35]. Liu et al. divide approaches further into ML-
based, heuristic or feature-engineering methods [19].

From the taxonomy it is evident that the concept of the semantic label,
combining facts stored in the KG and schema attributes of the data sources, is
central to the whole framework. This is one of the reasons why STDs have
gained so much attention recently [19]. Another crucial property is whether
the detection can be performed against arbitrary KGs (see Section 3). The
labels are the prerequisite for the generation of semantic models that are
ultimately refined using a graphical interfaces and potentially contribute
novel facts to the KGs. Data provenance and governance can be enhanced or
built entirely from these semantic data structures and again there exists an
important distinction between KG-centric and agnostic approaches (see Section
2.6). Finally, there exists a variety of applications, i.e., semantic data
discovery (e.g. semantic similarity [22]) or ontology-based data access (see
Section 4).

The Semantic Web Challenge on Tabular Data to Knowledge Graph
Matching222https://www.cs.ox.ac.uk/isg/challenges/sem-tab/index.html (SemTab)
is an annual competition (since 2019) for researchers to present novel
approaches evaluated with regards to accuracy and usability on proposed
benchmarks. The challenge’s problems include three tasks to annotate a table
with semantics.

Cell Entity Annotation is a cell-based annotation task which deals with
annotating the values in the table cells with entities inside a KG. Column
Type Annotation (CTA) is a schema-level annotation task which aims to map the
underlying table schema to a KG. Finally, Column Predicate Annotation (CPA) is
a schema-level annotation that defines binary relationships (properties of the
KG) between pairs of columns of the table. [19] further consider the tasks of
Row-to-instance (R2I), i.e. annotating an entire row of a relational table
with a KG entity and Topic annotation, i.e. annotating the entire table with a
concept or an entity from the target KG. Because Semantic Models, OBDA as well
as most data integration techniques predominantly live on the level of a data
sources schema, the only relevant tasks we consider here are CTA & CPA.

With semantic modeling, we refer to the process of creating relationships
between the semantic labels thereby describing the data source’s context. In
practice, semantic modeling often depends on accurate semantic labels, which
can be viewed as elements of a semantic model of only the first order. In
section 3 we discuss recent papers that present algorithms to automate these
processes.

Paulus et al. [20] introduce a phase called semantic refinement. They
reinforce the view that the automated creation of semantic labels and models
is a self-evident requirement for any OBDM platform. While automated
approaches can provide initial semantic labeling and modeling after analyzing
the schemata of the data sources, erroneously chosen or missing labels for
concepts will have a severe impact on the semantic modeling phase. Therefore,
the human operator shall have the opportunity to improve the quality of the
semantic labels as well as the resulting model manually by checking,
validating, correcting, selecting, or exchanging ambiguous or mutually
exclusive concepts, as well as adding new concepts that were not included
initially.

Mami et al. [36] describe a transformation called semantic lifting. Given a
set of semantic labels and a (yet non-semantic) data set, a semantic lifting
function returns a semantically-annotated data set with semantic labels for
entities and attributes. Mami et al. considered semantic labels only in their
original proposal, however semantic lifting can potentially be applied to
include entire semantic models as well any other descriptive metadata (e.g.,
comments or textual data documentations stored in documentation tools or
Wikis). Transforming data sources to incorporate semantic information along
with the raw values beforehand to prepare them for subsequent semantic access
necessarily corresponds to an ETL approach contradicting the ELT principle
that is inherent to data lakes. When dealing with large data sets, this
transformation can be challenging and expensive, particularly when data
liveliness is important.

###  2.3 Metadata models for data lakes that account for semantics

Metadata models for data lakes have been an active area of research in recent
years and many existing proposals consider semantics as a fundamental issue
for the management of heterogeneous data sources.

MEDAL and its successor goldMEDAL, [23] identify requirements for a generic
metadata model for data lakes and consider semantic enrichment as a core
requirement. The earlier proposals HANDLE [37] as well as GEMMS [25] enable
manual semantic labeling already.

Other approaches model their metadata directly in the RDF language as an
ontology. An early approach is presented by Farid et al. [10], where all
source data and metadata are stored in the RDF format. Diamantini et al. [38]
choose a network-based and semantics-driven representation for their model
that can be extended with external KGs. In a follow-up work [39], they
describe another ontology-based metadata model tailored to query-driven
analytics. Here, a special focus is laid on key performance indicators and
statistical measures typical in data science, where the user specify the
indicators of interest at query time, as well as related dimensions of
analysis, in terms of KG concepts. The framework then performs the required
data discovery and on-demand integration to provide the requested indicators.

A similar approach is followed by Bagozi et al. [40] who utilize indicators to
enable personalised data lake exploration. Indicators are usually computed
based on the centralization of the data storage, according to a less flexible
ETL approach than what traditional data lakes offer. In addition, domain
experts, who know the data stored within the data lake, are usually distinct
from data analysts, who define indicators, and users, who exploit indicators.
Hence, the authors allow domain experts to enrich the heterogeneous data
sources within a data lake with semantic models using domain ontologies and
further propose an ontology used by analysts to define indicators and analysis
dimensions, in terms of concepts within semantic models as well as formulas to
aggregate them. In [41] and [42], Bianchini et al. demonstrate the
effectiveness of this model in the Smart City environment extended by
theoretical considerations about modeling user preferences to enable
personalized exploration of data.

At Bosch, the potential of semantic technologies has already been exploited at
scale in production. The development of KGs required an immense initial effort
by the company, but promises a long-term solution for a series of
sophisticated challenges. Dibowski et al. [43, 13] describe a metadata model
represented as an ontology called DCPAC, based on W3C recommendations such as
the Data Catalogue Vocabulary (DCAT333https://www.w3.org/TR/vocab-dcat-2/) and
the PROV Ontology (PROV-O444https://www.w3.org/TR/prov-o/) for data catalog
management and provenance control. Ingested data assets are enriched with
semantics by aligning, annotating, and enriching the input data with DCPAC
concepts. In addition, they utilize a new concept called ontology-driven,
self-adaptive frontends, in which the data catalog’s GUI can dynamically
render information from a KG. A similar concept was presented in [44]. This is
useful because changes in the underlying ontology do not require any changes
at the frontend.

###  2.4 Existing semantic data lake systems

There exist several proposals for data lake systems that include functions for
SDM.

Google Dataset Search (Goods) [45] bootstraps its data catalog by crawling
Google’s storage systems and logs in order to discover what data sets exist.
It examines their content and metadata and matches it against Google’s
Knowledge Graph (GKG) to identify entities and this may perhaps be the most
obvious demonstration of the power semantics for data management.

Besides its metadata model, GEMMS [25] is a tool for the automatic metadata
extraction in data lakes. The authors recognized that often acronyms or
synonyms are used as the name of a schema element. By using semantic
annotations, such ambiguities can be avoided and the semantics of elements can
be clearly defined. Constance [9] takes up this idea and is one of the first
data lake systems to enable semantic labels on the level of the data source’s
schema.

Apache ATLAS is a stand-alone data governance framework for Hadoop that has
been successfully integrated into data lakes [46] allowing semantic labeling.
goldMedal demonstrates their metamodel for data lakes using Apache ATLAS.
Hence, it is neither viewed as a standalone data lake system nor a metamodel,
but may be utilized as a core technology worth of being mentioned.

The data discovery system Aurum [26] has KGs as a central element. The system
builds a so-called enterprise KG in a single pass through the data sources by
using data summarization and hashing to capture relationships between them.
Aurum describes the data discovery problem by properties and relationships of
the data sources stored in the data lake. Properties include schema labels and
quality measures, relationships may include similarity and primary/foreign key
relationships. In the KG, each node represents columns of the data sources,
edges represent relationships between two nodes, and hyperedges connect any
number of nodes that are hierarchically related, such as columns of the same
table, or tables of the same source. Aurum allows individual entries to be
represented, but suggests that the additional storage costs are not offset by
the gain in expressiveness. To calculate the weights associated with each
property, it considers content similarity (the values of the columns are
similar), schema similarity (the attribute names are similar), or the
existence of a foreign-key-relationship between them. As such, the underlying
algorithm to generate the hypergraph involves two steps: firstly, each data
source is profiled, and secondly, relationships are calculated based on the
profiles. Querying is performed through a language called Source Retrieval
Query Language (SRQL) specifically designed for the enterprise KG, which is
significantly different from SPARQL.

KGLac [47] follows a similar approach in that it is an external service that
generates a central KG based on the extracted profiles to perform all data
management. The data profiling is assisted by a machine learning model to
represent each data source in an embedding space to perform a similarity
search between tables or columns without revealing the raw data. Again, in the
KG vertices represent data sources, i.e., tables, or columns, while edges
represent relationships between these nodes. In contrast to Aurum, KGLac
relies on a custom extension of the RDF standard. A specific ontology is used
for querying with SPARQL to allow navigation and maintenance of the central
KG. The system does not have a user interface, but relies on Python APIs to
query a RDF database with direct integration into common data science
pipelines.

CoreKG [48] is an open-source service developed for data lakes to curate
stored data sources via REST APIs, which is composed of the extraction of
metadata, their enrichment, linking, and annotation. Linkage in CoreKG means
establishing a connection to an external KG such as WikiData as well as to
other data sources. It is not a complete data lake, because it does not
provide any storage or processing capabilities, but its functionality can be
easily added to existing data lakes using the REST API.

BARENTS [49] introduces an ontology-based method that enables analysts to
model how data sets have to be pre-processed to transform them into meaningful
knowledge. They introduce an ontology, not for data discovery but explicitly
for pre-processing. Domain experts can use this ontology to describe which
data transformations have to be applied to the raw data from source systems in
order to make it exploitable in their use cases.

###  2.5 Commercial systems

There exists a series of proprietary software stacks worth being mentioned,
but due to the ‘paywall’, the functionality and details are not fully
revealed.

The metadata model used by Bosch as described in the previous section is
implemented using the Enterprise Knowledge Graph Plattform by Stardog
555https://www.stardog.com/ for storing and processing the semantic layer as a
KG. The Poolparty Semantic Suite666https://www.poolparty.biz/ from the
Semantic Web Company offers a wide range of service, accessible through (REST)
APIs that can be exploited in conjunction with a data lake. The Anzo Semantic
Data Lake777https://cambridgesemantics.com/solutions-3/asdl-2/ offered by
Cambridge Semantics focuses on adding context by first building a catalog of
KGs from existing data sources in a data lake and then aligning those to
semantic models based on business meaning.

Table 1: Comparison of data lakes with a semantic layer. | SL | SR | C/E | MI | IAL | TA | C | O
---|---|---|---|---|---|---|---|---
Goods[45] | ✓ | ✓ | X | X | ✓ | X | X | X
Constance[9] | ✓ | X | X | X | X | X | X | X
Aurum[26] | ✓ | ✓ | ✓ | X | ✓ | X | X | ✓
KGLac[47] | X | ✓ | ✓ | X | ✓ | ✓ | ✓ | X
CoreKG[48] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
BARENTS[49] | X | ✓ | ✓ | ✓ | X | ✓ | ✓ | X
Enterprise Knowldege Graph Plattform by Stardog at Bosch | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | X
Semantic Integrator from the Semantic Web Company | ? | ✓ | ? | ? | ✓ | ✓ | ? | X
Anzo Semantic data lake | ? | ✓ | ? | ? | ✓ | ✓ | ? | X
Semantic Layer by AtScale | X | ✓ | X | ✓ | ✓ | ✓ | X | X
Semantic Layer Dremio LakeHouse Plattform | X | ✓ | X | ✓ | ✓ | ✓ | X | X

The Semantic Layer by AtScale888https://www.atscale.com/ follows a different
approach in that it does not apply Semantic Web technologies at all. Instead,
it focuses on data integration through data modeling in a canvas, where users
can establish relationships and hierarchies between heterogeneous data sources
from different storages without ever replicating or moving any data, but only
via reference. The Semantic Layer complements cloud data platforms (such as
DataBrick’s LakeHouse [50]) and provides a platform for integration and
orchestration of the platform’s query and transformation engines. This bridges
the gap from the data sources to business intelligence tools and AI
applications. A typical workflow involves selecting data sources from cloud
storages or a data lake, modeling their schemas, establishing relationships,
and exporting the model to an analytics platform (such as Power BI or
Tableau). All the connection details to the different storage platforms are
hidden by abstraction and users may start generating insights based on the
semantic model created by them.

A similar approach is followed by the Dremio Lakehouse
Platform999https://www.dremio.com/resources/demos/dremio-semantic-layer/. Just
like the Semantic Layer by AtScale, Dremio’s semantic layer manifests into a
hierarchical structure that exposes business representations of an
organization’s data assets to enable exploration.

###  2.6 Comparison & discussion

We identify criteria to compare and to check the comprehensiveness of the
existing systems summarized in Table 1. The table is limited to concrete data
lake systems and does not list approaches that just propose a metadata model.

  1. 1.

SL: Semantic labels denotes the possibility to connect schema entries with
instances in an external KG, either a domain KG to be uploaded or an online KG
such as schema.org.

  2. 2.

SR: Semantic relationships, i.e., any form of hierarchical, generic, or pre-
defined semantic relationships (semantic connections between data sets, e.g.,
for provenance or governance). It should be noted that none of the existing
data lake systems provides advanced modeling features such as those depicted
in Figure 1.

  3. 3.

C/E: Central KG graphs vs external KGs. Here we distinguish whether the
underlying metamodel itself is modeled directly as a KG (i.e., relationships
are limited to those defined in this KG). A more flexible system would allow
an external KG, and any concepts and relationships from this KG can be used in
the semantic model. A checked field indicates that the metadata model uses a
central, predefined KG.

  4. 4.

MI: Metadata interoperability This denotes whether the authors have considered
the possibility of importing or exporting metadata. i.e., serialization of the
semantic model. This is strongly related to criteria C since serialized models
are ported to different systems more easily.

  5. 5.

IAL: _Initial automatic semantic labeling_ denotes the functionality to
generate semantic labels automatically from the schema at the time of
ingestion.

  6. 6.

TA: Technical abstraction. This denotes whether the authors have explicitly
considered the technical abstraction of the semantic modeling as a requirement
to increase usability for unfamiliar users. This means that technical details
are hidden from the users, e.g., a user does not need to be familiar with RDF.

  7. 7.

C: Compatibility with Semantic Web technology. This criterion checks whether
semantic labels are modeled in a language of the Semantic Web (e.g., RDF,
OWL).

  8. 8.

O: Open Source. This criterion checks whether there is an open-source
implementation available.

##  3 Semantic Modeling for Data Integration

Semantic modeling targets at providing a semantic description of data sources
and is not restricted to data lakes, but can be applied to data management in
general. Nevertheless methods for enriching metadata are very relevant in this
context, because they increase the usability of a data lake. The semantic
model acts as a bridge between the data source and a semantically rich KG,
which can be applied in data integration or ontology-based data access. In
this section, we first focus on approaches for creating semantic models semi-
automatically, potentially supported by human input in a graphical user
interface (GUI). Manual definition of semantic models is possible, but is not
feasible for a large number of heterogeneous data sets as expected in data
lakes. Thus, automating the generation of semantic labels and models helps to
reduce manual efforts in a semantic data lake system [51]. In the following
sections, we investigate the current state of such proposals and conclude with
a comparison and discussion.

###  3.1 Semantic modeling systems

The systems mentioned in the previous section focus on _semantic labeling_ ,
i.e., enable the annotation of data sets with elements from internal and
external ontologies. _Semantic modeling_ is the next step in semantic
enrichment: the associated ontology elements are enriched with further
semantics to reflect the relationships represented in the data sets (see
Figure 1).

ESKAPE [52] is a semantic data platform handling the full data management
process from ingestion to extraction supporting heterogeneous data sources. It
introduces an intuitive interface where users can create semantic models. In
[2], the authors report the integration of ESKAPE into a data lake system in a
production setting. Instead of just dumping raw data into the data lake
directly, they use ESKAPE during data ingestion to enable the semantic
annotation of data sets to perform semantic data integration. To combine the
defined semantic models, ESKAPE also allows the integration of external KGs,
such as WordNet, BabelNet, or domain-specific ontologies. Elements of the KGs
can be reused during the modeling process and therefore serve as anchors when
relating different distinct semantic models and data sets.

Karma [53] is a data integration tool that enables users to ingest data as
well as as a vocabulary defined as an OWL ontology to create a corresponding
semantic model. Karma supports multiple data formats and proposes an initial
semantic model which the users can edit using a GUI. Karma is an important
pioneering work being one of the first to introduce key technologies such as
conditional random fields (CRF) and an algorithm to solve a Steiner tree
problem for learning of semantic labels and to discover relationships among
the schema elements of a source. Once the semantic modeling based on the
ontology is completed, Karma integrates data sets based on the defined
semantic model. The resulting semantic models can be exported as a RDF file.
In contrast to ESKAPE, Karma provides initial semantic labeling suggestions,
but it also requires users to have in-depth knowledge about technical details,
e.g., the RDF format. Furthermore, it focuses on automatically creating
semantic models based on a fixed ontology per use case where the ontology does
not evolve over time. ESKAPE claims to be easier to use because it hides the
technical details; however, there is no implementation available to compare
the usability.

Recently, the open-source platform PLASMA [20] has emerged from ESKAPE as well
as several other notable works, described in more detail in the next section.
Paulus et al. introduce a phase called semantic refinement (see Figure 3) in
which the human is responsible to improve the quality of the semantic model by
manually checking, validating, correcting, selecting, or exchanging concepts.
PLASMA comes with a semantic concept recommendation framework to suggest
semantic concepts extracted from public KGs as well as any proprietary source
(e.g., a company’s KG). The semantic models can be created, deleted, searched,
and exported as RDF in Turtle syntax. Central to the whole framework is the
idea of continuously evolving ontologies. As data sources need to be added or
updated, the created semantic model must be extended or adapted to reflect
these changes. To address this issue, Pomp et al. [54] propose an approach
featuring an evolutionary KG that consists of an internal growing universal KG
and data source specific mappings. A user, who creates a semantic label, is
enabled to define and use concepts and relationships in their semantic models
that were previously unknown to the KG. This is, for instance, the case if the
concept the user wants to use is missing in the current conceptualizations.
This novel knowledge must be integrated into the ontology of the universal KG.
For this, Pomp et al. developed a strategy for the controlled and evolutionary
development of the KG which evaluates the relationships and concepts that a
user selects or introduces, and validates if the user introduces
contradictions to the current KG. The framework identifies additional
relationships between concepts that improve the density of the underlying
ontology and contains validation logic to eliminate inconsistencies.

The dataspace management system On-demand Data INtegration (ODIN) [55] allows
data integration by virtually querying heterogeneous data sources grounded on
KGs. ODIN automatically extracts the schemata from (semi-)structured data
sources, translates them into a canonical data model, aligns their schemata,
and generates target-specific metadata from them. In the spirit of semantic
refinement, it relies on a supported user feedback process for incrementally
merging the semantics into a dataspace-wide ontology101010A demonstration of
the system is available at https://www.essi.upc.edu/~snadal/odin.html. ODIN
supports an advanced visual query mechanism by relying on
WebVOWl111111http://vowl.visualdataweb.org/webvowl.html, which is an open-
source application for interactive visualization of ontologies. This ontology-
mediated query interface allows selecting nodes of interest from any available
semantic model by marking them graphically in order to generate a SPARQL
query. Data sources associated with the marked nodes represent the connection
point to the data sets; wrappers encode the query to extract their data and
expose a first-normal form relation of their schemata.

###  3.2 Automated assignment of semantic labels

The technique of bootstrapping an initial ontology from (relational) databases
and directly establishing a mapping between the databases and the created
concepts is present in several systems. For example, Optique as well as its
successor OnTop (see section 4.1) provide such a capabilities. An early
benchmark for evaluating the quality of the generated mappings in the context
of ontology-based data access (OBDA, see section 4) is presented by RODI [56].
Influential works include the SemanticTyper presented by Ramnandan et al.
[32], who apply heuristic rules (a TF-IDF-based approach for textual data and
the Kolmogorov-Smirnov statistical hypothesis test for numeric data) as well
as the Domain-Independent Semantic Labeler (DSL) by Pham et al. [33], which
presents a machine learning approach around similarity measures.

As mentioned previously, interested readers are referred to the survey by Liu
et. al. [19] for a thorough and comprehensive discussion of proposals for
STD’s up until the year 2021 including the numerous developments based on deep
learning. Here, we want to include one more recent approach called Tab2KG
([57], 2022), which follows an entirely different approach in the sense that
it can interpret previously unseen data on the basis of arbitrary domain KGs.
Interestingly, Tab2KG uses RML to serialize semantic labels possibly useful to
perform OBDA (see section 4) They introduce so-called semantic profiles for
domain ontologies and data tables to facilitate effective semantic table
interpretation. For creating a domain profile, the domain KG, that contains
representative values for the data type relations in the target domain, is
transformed into a feature vector containing a set of statistics, computed
using all literals coming from to set of data type relations. For creating a
data table profile, a feature vector of descriptive values is computed which
includes data types and basic statistics (completeness, mean, standard
deviation, skewness, histogramms etc.). The selection is motivated by the
expected feature effectiveness for semantic table interpretation, i.e.,
matching the domain and data table profiles and can be extended to include
relevant domains-specific characteristics. The profiles are generated
automatically and described using the DCAT2 and the SEAS3 vocabularies to
enable their reusability. Then, Tab2KG uses the domain and data table profiles
to perform the semantic type detection using a novel one-shot learning
approach. In contrast to domain-specific approaches such as DoDuo[27, 19],
Tab2KG uses a Siamese network that generalizes towards unseen data type
relations by inducing a metric that represents the domain-independent
similarity between two input feature vectors (e.g., between an unknown and a
known sample). The similarity between a column and a data type relation is
predicted based on the experience of the similarity of other profiles learned
earlier. Given a set of candidate column mappings with their respective
similarity scores for each column in the input data table, they map each table
column to a data type relation in a greedy manner..

###  3.3 Automated semantic model generation

While the previous approaches focus on semantic labels solely, there also
exists some that aim to construct entire semantic models (some including
semantic label generation as well) and the field has attracted increasing
interest lately.

Vu et al. [58] present PGM-SM which uses probabilistic graphical models to
create semantic models. From previously generated semantic models and the
detected semantic labels, a conditional random field is trained to distinguish
between good and bad semantic models. The graph is then used to identify
possible semantic models and the best k out of them are selected using a
scoring function based on probabilistic graphical models. In follow-up work,
[59] they recognize that despite being flexible in choosing a target ontology,
the approach requires users to label enough data sources before the systems
can achieve good performance and this issue is more profound the larger the
target ontology is. For this reason, they shift the supervised problem towards
utilizing large-scale KGs, such as DBPedia and WikiData. For this, they
present a novel probabilistic approach for automatically building semantic
descriptions of Wikipedia tables leveraging hyperlinks and existing knowledge
in Wikidata to construct a graph of possible relationships in the table and
its context. To assess the effectiveness of the method, it is evaluated on a
data set from the SemTab2020 challenge as well as another data set with 250
Wikipedia tables with their semantic descriptions built using the Wikidata
ontology.

Further notable works related to the SemTab2020 challenge are MantisTable
[60], bbw [61], and MTab4WikiData [62] each of them aiming at the automatic
generation of semantic models for data from Wikipedia or Wikidata.

In the spirit of CoreKG, Feng et al. [63] present ASMaaS (Automatic Semantic
Modeling as a Service), which is an external service for data lake vendors and
users to generate a semantic model for their data sets. The paper describes a
service-oriented architecture including annotating training data, training the
machine learning models, and predicting an accurate semantic model for new
data sources.

Futia et al. [64] present an approach called SeMi (SEmantic Modeling machIne)
based on graph neural networks (GNNs), that was inspired by the work of
Taheryan et al. [65, 66, 67], Knoblock et al. [68] (who are also co-founders
of Karma) as well as the SemanticTyper by Ramnandan covering the process of
semantic modeling. They adopt the exploitation of linked data repositories as
background knowledge similar to Taheriyan et al. They replace the manual
extraction of compound features (e.g., complex graph patterns to represent
semantic relationships of different lengths) by a graph neural network that
automatically learns latent features for entities and properties, encoding
them in a vector space exploiting the local neighborhood structures within the
linked data graph. In their processing pipeline, the Semantic Model Builder
generates an initial semantic model. The proposed Steiner tree within the
graph includes the shortest path to connect semantic type classes. However, it
does not necessarily express the correct semantic description of the target
source. For this reason, a refinement process is required in order to identify
a more accurate semantic model. The semantic model refinement (notice, that
here an automatic process is applied as opposed to the one in PLASMA, cf.
Figure 3) requires preparing data sets as input of the deep learning model.
The graph neural network’s main goal is to reconstruct the linked data edges
using the latent representation of entities and properties.

Burgdorf et al. [29] present VC-SLAM, a corpus that allows the evaluation and
comparison of semantic labeling and modeling approaches across different
methodologies. It contains 101 data sets composed of labels, data, and
metadata, as well as corresponding semantic labels and a semantic model. The
semantic labels and the semantic model are manually refined by human experts
using an ontology that was explicitly built for the corpus. While the first
two directions in the semantic labeling process (see section 2), i.e., data- &
schema-driven, have been addressed by the majority of the works presented so
far, the third direction has attracted only little attention so far. Metadata-
based semantic labeling regards all available additional pieces of information
on a data set that might contribute to the semantic labeling of the data. For
example, structured data like CKAN standards and any additional metadata
within a database, like comments or textual data documentations stored in
documentation tools or Wikis could be used to enhance the semantic labeling
process. They have tried to evaluate SeMi against their datasets, but were
unable, due to the fact that they have created a novel domain ontology which
is not reasonably big enough to train the GNN with background data. For this
reason, they include additional exploitable textual data documentation.

Burgdorf et al. present also DocSemMap [69] a novel approach that utilizes
textual data documentations of data sets as an additional source for the
creation of semantic mappings. It utilizes Natural Language Processing (NLP)
techniques jointly with structured data to perform semantic modeling. They
show that especially when compared to data-driven methods, there are different
cases where DocSemMap can map concepts that would not otherwise be identified.
Hence there is great potential for performing semantic mapping based on
textual data documentations.

In [70], Ramirez et al. present Relational Natural Language Inference (RLNI)
aiming to provide explainable data exploration on data lakes. They address the
fact that many frameworks tend to build on similarity metrics that stop short
of providing a clear explanation as to how an identified data set relates to a
provided target. In order to tackle this problem they focus on based on
Natural Language Inference (NLI), which has a limited set of relationships
(i.e., equivalence, forward entailment, reverse entailment, negation,
alternation, cover, and independence), and provide an unsupervised analysis as
well as a supervised alternative, that requires training data both based on
pre-trained language models. The approach lacks to incorporate the semantic
expressivity inherent to full-fledged ontologies, but rather provides
semantics and explainability to the problem of exploration in data lakes which
is recognized as insufficient in comparable works such as Aurum [26, 71].

Haller et al. [72, 73] study the whole problem from a different angle. In
particular, they analyze SQL queries written by data analysts, who already
understand the semantic relationships of the heterogeneous data sources. Their
prototype called Pharos connects to an existing SQL session of any program
that has a JDBC interface, and records and analyzes all queries in the
background. It extracts knowledge fragments from SQL queries and represents
them in an RDF-based KG for which they have designed a new ontology. Examples
include foreign/primary key constructs extracted from JOIN queries or log
entries of the form “attribute salary has been cast to the data type long”
from which it can be concluded that the salary column can be summed.

###  3.4 Comparison & discussion

The comparison is divided into two parts. We first review complete modeling
platforms, that include methods for semantic labeling and/or modeling, as well
as a graphical user interface to allow the user the adaptation of the created
artefacts. For this category, we have identified several criteria:

  1. 1.

IAM: Initial automatic semantic model. In contrast IAL in section 2.6, this
denotes here the functionality to generate entire semantic models
automatically from the schema after the ingestion of a data source. This
includes the first three phases in Figure 3.

  2. 2.

EX: Support for external KGs. Is the approach capable of handling arbitrary
KGs or fixed to a predefined KG?

  3. 3.

M: Maturity. Here we check whether the system has been reported to be
successfully utilized in a Big Data project.

  4. 4.

C: Compatibility with Semantic Web technology. This criterion checks whether
semantic labels are modeled in a language of the Semantic Web (i.e., RDF or
OWL).

  5. 5.

O: Open-source software is available.

The comparison is summarized in Table 2.

Table 2: Comparison of semantic modeling platforms. | IAM | SR | EX | M | C | O
---|---|---|---|---|---|---
ESKAPE [2] | ✓ | X | ✓ | ✓ | X | X
KARMA [74] | X | ✓ | ✓ | ✓ | ✓ | ✓
PLASMA [75] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
ODIN [55] | ✓ | ✓ | ✓ | X | ✓ | ✓

It should be noted that all of the mentioned approaches focus on
relational/tabular or at least (semi-)structured data (including JSON and XML)
only. The heterogeneity inherent to Big Data applications is still far from
being covered for automatic semantic modeling approaches. In terms of GUI-
based manual modeling PLASMA displays a mature solution, proven to be
applicable in production with many built-in features which can be tested
publicly.121212http://plasma.uni-wuppertal.de/modelings

Semantic Type Detection has gained in research momentum lately, but the field
is far from a truly mature solution. The latest solutions based on deep
learning achieve impressive accuracies when evaluated on their specific test
data sets, but considering the fact that any labeled data set to performed
supervised learning (such as WikiTables131313http://websail-
fe.cs.northwestern.edu/TabEL/ or GitTables 141414https://gittables.github.io/)
can only contain a limited amount of semantic types, its usefulness in
practise becomes very limited. They utlimately suffer from a closed-world
assumption as in the case of DoDuo [27]: their final model can distinguish
only between 255 different types. In order to sensitize the model for a
different domain ontology (other than WikiData), it is required to train the
model on a manually labeled data set containing corresponding semantic types.
Furthermore, because they use a language model, the detection performs poorly
on numeric data so far and most approaches are limited in dealing with high-
dimensional and large data sets. Taking up DoDuo again, it has been trained on
tables with an explicit maximum of 10 columns and 32 tokens in sequence
length. In contrast, the embedding approach in DAGOBAH or the heuristic
strategies by MTab and JenTab [76, 77, 78] may possibly predict arbitrary
semantic types, because here semantic types are extracted via look-ups, that
are not limited to specific targets. However, both the strategies evaluate
their algorithms on excerpts of cross-domain KGs such as WikiData and DBpedia
and are not specifically designed to work with a specialized
conceptualization, such as a domain ontology. This is particularly important
for the applicability to data lakes, as they are often utilized in a specific
domain (e.g., smart manufacturing [13, 79] or the energy sector [80]) and
specialized knowledge is needed for in-depth data understanding.

In terms of automated modeling, SeMi’s approach relying on KG embeddings
computed with GNNs is an advanced solution, but its semantic type detection,
the first and most crucial step in the pipeline, is not generic but tailored
towards the specific data sets [64].

##  4 Ontology-based Data Access

With semantic labels and semantic models, a semantic description of the data
sources is available; it is hence reasonable to use these semantics for data
integration and querying. This is the topic of _ontology-based data access_
(OBDA) which has been developed since the mid-2000s [81] with the aim of
facilitating access to various types of data sources, using an ontology as the
common data model. The setup can be described as a set of existing data
sources forming the data layer, and the goal is to build a service on top of
this, aiming at presenting a conceptual view of data to the clients. The
ontology describes the domain of interest and is usually developed
independently from the data layer.

A challenge in this scenario is the combination of different abstraction
levels and formalisms. Whereas ontologies model the conceptual level, use
open-world assumption and are based on description logics, the data sources
are described by schemas on the logical level which focus on the structure of
the data and use the close-world assumption. By posing the query to the
ontology, the primary advantage of OBDA is that users can query various data
sources without the need to know how the data is organized and where it is
stored.

Fathy et al. [82] identify two main approaches for applying OBDA: (1)
materialization, meaning all source data sets are converted into a common data
format (e.g., RDF or relational tables) and stored in one data repository, or
(2) on-demand translation (or rewriting) of queries (ususally expressed in
SPARQL) into the required query language of the data sources. In this survey,
we emphasize the applicability to Big Data; hence, scalability is a strong
requirement. Materialization approaches can be challenging and expensive when
dealing with large data sets. Hence, only query translation approaches are
feasible in data lakes, albeit the fact that it is significantly more complex,
because it requires profound theoretical consideration. It is part of the
larger domain of data federation [83] which addresses the problem of uniformly
accessing multiple, possibly heterogeneous data sources, by mapping them into
a unified schema. The common data model used for querying can be also
expressed in other schema languages. Earlier approaches for data integration
used the relational model and translated the data sources into a common
relational schema [84]. Query rewriting in this relational setting has been
well studied; we consider the more complex scenario of query translation with
ontologies over heterogeneous sources.

Query translation [85] is hence strongly related and essential for any
effective OBDA framework to deal with the variety of heterogeneous data
sources in a data lake. In OBDA, on-demand query translation exposes the
content of data sources as RDF triples, using classes and predicates from a
KG. The RDF triples are not materialized, they are part of a virtual knowledge
graph (VKG), which means that data remains in the data sources instead of
being stored in some common database. A VKG system has the following
components (see Figure 5): (a) queries that describe user information needs,
(b) an ontology with classes and properties, (c) mappings to the data sources,
and (d) a collection of data sources. The W3C published recommendations for
languages for components (a)–(c): SPARQL, OWL 2, and
R2RML151515https://www.w3.org/TR/r2rml/, respectively.

Figure 5: Illustration of Ontology-Based Data Access

Mapping creation and management is probably the most complicated OBDA design-
time task, as the mapping specifies the semantics of the data sources in terms
of the ontology and bridges the typically large conceptual gap between the
source schema and the ontology. By applying knowledge representation and
automated reasoning techniques, an OBDA system uses ontologies and mappings to
reformulate the SPARQL queries into source-specific queries. A formal
framework is presented by [8], including query answering, mapping management
and analysis, and extensions of the classical OBDA framework. Here, we omit
the theoretical details of query rewriting and focus on the practical
application for data integration in the Big Data regime.

A comprehensive survey on query translation methods by Mami et al. is given in
[85], including a classification, a map for different language translation
paths, and a historical timeline. While computer scientists have been looking
for the holy grail of data representation for decades (logic, ER/relational,
XML, graph, NoSQL), their work reinforces the view that no single data
representation scheme fits to all use cases. Mami et al. further identify
several interesting shortcomings: First, they recognize that many translation
methods fail to support the more sophisticated operations such as different
join types and temporal functions in SQL, or blank nodes, grouping, and
binding in SPARQL. Then, they state that there a many well-founded and defined
query translation frameworks, from the query translation process to the
various optimization strategies; however, they would hardly represent real-
world queries, but mostly simple queries. Use-case-driven translation methods
would be more helpful to reveal useful query patterns and to evaluate the
translation methods and optimizations on real-world data. They state that
there is a wide variety in the evaluation frameworks used by each of the query
translation methods and a need for a unique standardized benchmark specialized
in evaluating and assessing query translation aspects. In their final remarks,
they discuss candidates for a ‘universal’ query language. Based on their
findings exploring various query translation methods, they see SQL and SPARQL
as the most suitable languages to act as a ‘universal’ language for realizing
heterogeneous data integration.

###  4.1 OBDA over relational data

Some of the earliest systems performing OBDA include Mastro (2011, [86]),
UltraWrap (2013, [87]) and MorphDB (2014, [88]). Optique (2013 [89]) was the
first successful OBDA system designed for Big Data scenarios. Its underlying
architecture mainly uses Ontop (see below) to manage data access using R2RML
mappings, and Exareme [90], a research prototype which acts as a back-end
query execution component handling large-scale data processing tasks. A major
drawback of these early systems is the lack of horizontal scalability.

The Ontop framework for OBDA [91] is likely to be one of the most mature open-
source161616https://github.com/ontop/ontop OBDA systems, which has come a long
way since its beginnings in 2009 [91, 92]. It is the result of an active
research and development community and has been adopted in many academic and
industrial projects [93, 4, 94]. Because Ontop moved towards supporting the
W3C recommendations for SPARQL and R2RML, new challenges emerged, which
required the development of a core data structure called intermediate query
(IQ), an algebra-based data structure that unifies both SPARQL and relational
algebra. IQ is a uniform representation both for SPARQL queries and for SQL
queries from the mapping. When the query transformation (rewriting and
unfolding) is complete, the IQ expression is converted into SQL, and executed
by the underlying relational database management system (DBMS). OnTop aims to
shift almost all query processing to the DBMS and performs only the topmost
projection, which typically transforms database values into RDF terms.
Sophisticated optimization techniques such as redundant join elimination,
using primary and foreign keys, efficient duplicate elimination [95], and
pushing down joins to the data-level [96] as well as exploiting integrity
constraints to enhance query completeness and performance [97] have been
extensively studied during the past decade to make sure that queries can be
efficiently processed by the underlying DBMS.

With a recent extension called Ontop4theWeb [98], the framework can now be
evaluated on-the-fly against web data using SPARQL without materializing it
into a DBMS first. Ontop4theWeb implements an approach for posing SPARQL
queries on top of non-RDF Web data on-the-fly. To achieve this, virtual table
operators are embedded in the SQL queries that are included in R2RML mappings.
They specify which part and source of Web data will be fetched and how they
will be mapped to virtual RDF terms. The specification these mappings creates
the usual overhead, but they need to be specified only once unless the schema
changes. Although no explicit materialization of data is performed and the
responses of web-native and NoSQL JSON APIs can be obtained, Ontop4theWeb
still relies on the relational data model and relies on a relational database
system in the backend.

Ontopic Studio171717https://ontopic.ai/ is a commercial spin-off of Ontop that
provides a GUI to ease the creation and search of mappings via a mapping
editor. The Ontop framework has recently attracted interest for an application
in data lakes: Schwade et al. [99] show a successful integration into a data
lake by adding a semantic layer based on the Ontop framework.

The Chimera Suite [100] extends the native OnTop systems by two components:
(1) OntopSpark, an extension that enables OnTop to perform OBDA on relational
data using Apache Spark effectively translating SPARQL queries into SparkSQL
and (2) a JDBC endpoint to connect Spark Thrift Server with OnTop that can
direct the SparkSQL queries to an HDFS filesystem. Belcao et al. point out the
current gap between Big Data technologies and the semantic world. On the one
hand, knowledge engineers work with OWL and RDF to create knowledge graphs. On
the other hand, data engineers define ETL processes to provide the source data
in form which can be consumed by data scientists. Then, data scientists need
to combine these two perspectives to provide interpretable analytics results.
To tackle this problem, Belcao et al. introduce a comprehensive pipeline,
where data scientists write SPARQL queries and send them to Jena Fuseki in a
Jupyter Notebook using the PySPARQL library to get a semantically enriched
response. Using the mappings and the ontology, the query is re-written into
SQL. OntopSpark accesses the data stored as Parquet files in HDFS using Apache
Spark. The SPARQL response returned from OntopSpark is further enriched by
Jena Fuseki using the knowledge graph, and the final results are sent back to
the Jupyter notebook.

Belcao et al. further describe in [100] a real-world deployment at Italy’s
largest public company for industrial research in the energy sector [3]. In
this scenario, they developed a KG containing around 7 million triples
representing Milan’s metropolitan area storing the network topology and all
the information about the various pieces of electrical equipment. The Chimera
Suite enables the data science team to make analytical predictions by querying
both the KG and the Big Data repository. The knowledge engineers can access
the graph and retrieve the results of the data scientists’ analysis.

Ontario [101] is a query processing engine over heterogeneous data sources in
a data lake utilizing VKGs. Ontario translates queries from a global querying
mechanism, e.g., SPARQL, to the underlying native query mechanism of the data
sources. Therefore, the system transforms raw data to RDF on demand by
applying mapping rules based on R2RML. Ontario utilizes custom extensions of
the RDF and SPARQL standards, where compliance with W3C standards is unclear.

Obi-Wan [102] is built on top of the Tatooine [103] mediator for heterogeneous
sources and Graal, a toolkit for query answering in knowledge bases [104]. The
approach relies on mappings that are Global-Local-As-View (GLAV) as opposed to
Global-As-View (GAV), which are used, for example, in Ontop, MorphDB and
Mastro. GLAV mappings are considered to be more flexible in scenarios with
evolving data sources [84]. In GAV mappings, a change in a data source might
require a change in the global schema and all source mappings. With GLAV
mappings, the sources are described independently of each other with respect
to the global schema.

This was also recognized by the work of Nadal et al. [105] who propose a
framework for data integration entirely based on graphs utilizing GLAV
mappings. A prototype of the rewriting algorithms is incorporated into ODIN
(see section 3). The proposed query language is based on coverings of a graph
representing the global schema and does not require users to define join
conditions. The query is visually represented as graph. Required join
operations on the data are generated by the rewriting algorithm. Encoding all
required metadata (i.e., global schema, source descriptions, mappings, and
queries) as graphs simplifies the interoperability among them and allows
rewriting algorithms to efficiently identify the relevant sources.

PolyWeb [106] relies on R2RML and its proposed successor
RML181818https://rml.io/specs/rml/. PolyWeb performs a predicate-based source
selection where a set of relevant data sources on the Web (RDF & CSV) for a
given query are discovered by matching predicates used in a basic graph
pattern and the input data sources. A SPARQL query provided as input is
translated into a native query of the underlying system (CSV files, relational
databases, RDF triple stores are considered) and executed on this system.

###  4.2 OBDA over non-relational data

There are four main groups of NoSQL Database Management Systems (DBMS) [82]:
document-oriented, column-oriented, graph-oriented, and key-value stores. Each
of these DBMSs rely on different data models and query engines, which
complicates the task of creating a uniform OBDA system in this case. Because
of increasing popularity and the lack of unified query languages and data
models for these systems, there is growing interest in applying OBDA in this
context. Systems based on VKGs promise to provide the desired unified semantic
view of data sets. Early papers include [107, 108] and different languages
have been proposed to extend the R2RML mapping language.

RML [109] is such a proposed extension to deal with heterogeneous data
sources. There are proposals to extend RML with functions and operations
described uniformly, unambiguously, and independently of the technology used
for implementation. Examples for those include the Function Ontology (FnO)
[110] and FunUL [111]. While RML extends R2RML to schema transformations, the
combination of RML with FnO extends R2RML with respect to data
transformations. RML is widely spread and implemented in existing systems, and
many proposals exists that aim to ease its use. YARRRML [112] simplifies the
use of both R2RML and RML by a human-readable text-based representation for
mapping rules expressed in YAML191919https://yaml.org/spec/, a widely used
human-friendly data serialization language. The RML Editor [113], RMLx [114]
Map-On (only for R2RML [115]) and MapVOWL [116] provide visual support to help
users in generating Linked Data from raw data by defining RML mappings. In
[117] the authors conduct a usability experiment on three different languages:
ShExML [117], YARRRML and SPARQL-Generate [118]. RML was left out, because of
too high verbosity. Their prototype translates files (JSON, XML) into RDF
using one of the mappings languages and examines the usability via a
questionnaire for first-time users, which are have only basic skills in
programming and linked data. The results show that ShExML users tend to
perform better than those of YARRRML and SPARQL-Generate. With SDM-RDFizer,
RocketRML [119, 120], there exist further concrete solutions that built upon
RML. However these approaches, as well as some of the ones mentioned before,
follow the ETL approach, i.e., converting all data into a huge RDF file as
opposed to on-demand query re-writing.

xR2RML is a language for mapping various types of databases to RDF which
enables the translation of a broad scope of data sources via query re-writing
[121]. To achieve this goal, they propose a two-phase approach. First, they
define an abstract query language derived from SPARQL. Utilizing the xR2RML
mapping language and leveraging R2RML-based SPARQL-to-SQL works, they
introduce a generic method to translate a SPARQL graph pattern into their
abstract query language. In the second phase, the abstract query is translated
into the query language of a target database. For demonstration purpose, they
apply the approach to MongoDB, but acknowledge that adopting a different NoSQL
DBMS will still be challenging. This is mainly because these systems are
generally optimized for fast storage and retrieval of vast collections of
data, rather than on expressive query languages. The prototype implementation
is open-source202020https://github.com/frmichel/morph-xr2rml/ including the
SPARQL-to-MongoDB translator and connectors for the MySQL and PostgreSQL
relational databases.

Delva et al. [122] identify certain shortcomings of ShExML, xR2RML and combine
concepts of both to introduce RMLFields. It extends RML with a nested
iteration model empowering it to write nested loops over input data. In
another approach [123] called OntoMongo the authors seek to delegate query
execution to a NoSQL source engine. They rely on an object-oriented
intermediate representation, where they map from the ontology vocabulary to
this object-oriented, conceptual layer. The aim is to simplify the mapping
specification and make it independent of the underlying source database.

A team around the creators of Ontop has been working on generalizing the OBDA
concepts to non-relational data models. They have carried out experiments on
MongoDB to extend the functionality of the system [124]. They explain a two-
step rewriting process of SPARQL queries into the MongoDB aggregate query
language, where they represent the results of native queries as relations to
provide a uniform view of non-relational queries. The idea is to view a
collection of MongoDB documents in the nested relational model.

A similar implementation is reported in [125] aiming to fill the gap between
NoSQL and the Semantic Web, in order to enable access to such databases and
integration of non-relational data sources. They present the Ontop-CB project
which implements the query translation method based on the Ontop system as a
backbone, allowing to query Couchbase, a NoSQL document store. The key
components are an OWL ontology, an access interface, mappings, a NoSQL
database, a SPARQL to NoSQL query adjustment, and a JSON export. The approach
exploits Ontop answers to SPARQL queries by rewriting them into SQL queries
and delegating their execution to the database. To do so, they also establish
an object-oriented intermediate layer between the OWL ontology and the
Couchbase data source.

The authors of [126] report the implementation of OBDA for a Neo4j graph
database via two phases. First, the xR2RML mapping language is used to connect
the RDF data model to the LPG data model. In the LPG data model, edges may
have multiple data properties, referred as ‘Composite Edge’. Then, relational
graph algebra is used to translate a given SPARQL query into the Cypher query
language native to Neo4j.

In line with the use of OBDA in NoSQL, the problem of ontology-mediated query
answering over key-value stores is studied in [127]. The authors create a
rule-based language in which keys are used as unary predicates and rules are
applied at the record stage (a record is a set of key-value pairs).

Chimera’s main competitor is the Semantic ANalytics StAck (SANSA) [128], that
comes with Squerall. Squerall is a scalable OBDA engine that relies on the RML
standard and allows querying several databases simultaneously. Squerall uses
wrappers to query heterogeneous data sources directly in their original form.
In the paper, they evaluate and compare five different data sources
(Cassandra, MySQL, MongoDB, Parquet and CSV) and run queries involving
multiple joins between the different sources. They compare the Presto and
Apache Spark processing engines for making SPARQL-to-SQL conversions and find
out that Presto works faster in their specific evaluation. Squerall addresses
the variety challenge of Big Data in that it can conveniently be extended to
embrace new data sources. This is the most immediate advantage over Chimera
and Ontop, because those usually require a single DBMS (or Hive store) in the
backend. However, Squerall does not comply to many W3C Recommendations. For
example, basic SPARQL graph patterns OPTIONAL and UNION were not yet supported
at the time of the first publication in 2019. Similarly, it is unclear about
how generic the framework truly is from a theoretical perspective beyond the
evaluation scenario given in the paper. However, the work is a crucial step in
the vision of implementing a polystore system that can query data in an on-
the-fly-manner, i.e., no prior transformation.

Table 3: Overview of OBDA techniques sorted by date of publication | Year |  Data Model |  Query Languages |  Mapping Model
---|---|---|---|---
Maestro | 2011 |  Relational |  SQL |  DL-Lite
UltraWrap | 2013 |  Relational |  SQL |  RDB2RDF
Optique | 2013 |  Relational |  SQL |  RDB2RDF
MorphDB | 2014 |  Relational |  SQL |  R2RML
OnTop | 2014 |  Relational |  SQL |  R2RML
Mugnier et al. [127] | 2017 |  SQL & Key-Value |  SQL, XPath, JSONPath, MongoDB |  NO-RL
OntoMongo | 2017 |  Relational & Document |  SQL & MongoDB |  Object-relational & Object-Document
PolyWeb | 2019 |  Relational |  SQL |  R2RML & RML
OnTop over MongoDB | 2019 |  Relational & Document |  SQL & MongoDB |  JSON-to-RDF & SQL-to-RDF
Ontario | 2019 |  RDF & Relational |  SQL |  RDF-MT
Squerral (SANSA) | 2019 |  Relational & NoSQL |  Spark- & Presto-SQL |  RML+FNO
Fathy et al. [126] | 2019 |  labeled property graph |  Cypher |  xR2RML
Obi-Wan | 2020 |  Relational & Document |  SQL & MongoDB |  (G)LAV view-based query rewriting
OnTop4theWeb | 2021 |  REST (CSV, JSON, XML) |  SPARQL |  R2RML
Chimera | 2021 |  Relational (Hive) |  SparkSQL |  R2RML
OntoCB | 2021 |  Document |  Couchbase (N1QL) |  Object-oriented

###  4.3 Discussion

R2RML has been proven to be a useful mapping language for relational sources.
Simply extending the R2RML standard to support other types of sources does not
necessarily carry on all its features [129]. For example, select conditions
and transformation functions are supported by R2RML implicitly relying on the
expressivity of SQL, but this cannot be applied for querying XML or JSON
documents. In [130], the authors argue first, typical mapping languages are
designed to work with a specific data format, and second, they are designed in
a format to be parsed by machines and they do not take into account human
readability and compactness. YARRRML is clearly a contribution in that
direction. Because these languages are not necessarily interoperable, and many
of them support a specific engine only, the next generation of OBDA systems
would have to consider how to address translation mapping languages, in
addition to the query re-writing techniques that have been widely addressed in
the SOTA of OBDA so far (see Figure 6).

Squerall extracts data, transfers it to an efficient format, and queries it in
a scalable manner using Apache Spark. In contrast, Ontop predates the
publication of the Chimera and therefore does not utilize any Big Data
technology. However, the comparison reported states that Ontop is still
competitive for the majority of the evaluated query types (12 in total),
except for such queries that involve aggregating, where Squerall is more
efficient. This might come from the fact that OnTop has more sophisticated
query optimization techniques, while Squerall relies solely on its processing
engine. Furher, Squerall does not support all query types.

Based on the existing literature we identify a historical development of OBDA
techniques (see Figure 6) which is separated into four different periods:

Figure 6: Timeline of OBDA techniques

First, there are proposals following the ETL approach, i.e., transforming all
data sources into a huge RDF graph to be queried using SPARQL. Although the
approach might suggest a uniform query method for heterogeneous data sources,
the question of data integration remains unanswered as data is only
transformed into a common format, but it is unclear how they relate
semantically to each other. The approach also has the previously described
deficiencies with regard to the liveliness of data and the overhead that comes
with the initial transformation into RDF.

These weak points were then addressed by the first platforms to perform OBDA
over relational databases via query re-writing, which leaves the data in their
respective DBMS retrieving it through the native via query optimization
techniques. Although these solutions display impressive progress, they are
mostly limited to support only a single relational DBMS at once. The process
of creating mappings is also mostly manual and hence tedious, error-prone, and
tailored towards a single static ontology.

The third period bridges the gap to access NoSQL databases and more flexible
data models such as nested structures, graphs, or REST APIs and also expands
the query result space to NoSQL data models. In this period many ’single-
purpose’ solutions arise that extend support to a single NoSQL DBMS or to
semi-structured files like JSON and XML, but no solution exists that is
flexible enough to query arbitrary databases. In this period we also observe
the first real-world applications that built GUIs for these methods to perform
business intelligence effectively, e.g., [4]. In parallel, the development of
algorithms for automated generation of mappings gain increasing momentum, some
of which have been discussed in section 3. Early proposals with a focus on
OBDA include the already mentioned BootOX complemented by MIRROR [131], both
promoting the automatic generation of W3C R2RML from RDBMSs. They are followed
by Hazber et al.[132], Heyvaert et al. [133], AutoMap4OBDA [134], MILAN [135]
and Iglesias-Molina et al. [136]
(Mapeathor212121https://morph.oeg.fi.upm.es/tool/mapeathor/swagger/$#$/default/post_tool_mapeathor_api_)
each presenting different algorithms to improve the mapping quality,
decreasing the task complexity, and hence the user effort for creating R2RML
mappings.

Finally, the most recent approaches add efficient, scalable, and distributed
processing engines like Apache Spark or Hive and storages like HDFS. The
Chimera Suite supports all W3C recommendations for the R2RML mapping language
to translate SPARQL to SQL and bridges an important gap between semantic and
Big Data technologies. However, at the same time, it is limited to Hive and
the relational data model. Furthermore, the traditional GAV-based mappings
have the drawback that one needs to revisit them if schema changes happen at
the source level. For example, the Ontop docker
container222222https://github.com/chimera-suite/use-case needs to be restarted
every time changes are made to the mapping definitions or the data sources.
This problem is partly lifted by utilizing GLAV mappings, but they have not
gained widespread attention yet and scalable open-source proposals are to be
presented. On the other side Squerall supports arbitrary NoSQL databases while
also utilizing scalable processing engines, but does not support the
sophisticated SPARQL queries232323https://github.com/EIS-
Bonn/Squerall/wiki/Squerall-Basics#3-sparql-query-interface. Furthermore, we
observe the emergence of data-driven methods, in particular scaling usability
of Machine Learning (ML) analytics, which requires managing a large variety of
heterogeneous data with a unified mechanism, in order to save time on
developing new ML solutions, and to reuse already developed ones. For this,
companies commit to the development of a long-term common semantic frameworks
for industrial data management and ML analysis [137].

##  5 Applications

The closer collaboration between human-machine and machine-machine systems has
revolutionized the current industrial landscape, leading to Industry 4.0 (also
known as Industrial Internet-of-Things, IIoT) [138]. The key drivers of IIoT
include the continuous addition of new types of devices with their own data
models. This data explosion requires highly agile data models that enable
monitoring, processing, optimizing, and analyzing data to derive insights for
better decision-making. However, effective data utilization demands data
integration, encompassing cleaning, de-duplication, and semantic
homogenization. We proceed by presenting two hand-selected use cases where
semantic data management has transcended the realm of academia and has been
applied to real-world IIoT problems.

###  5.1 Manufacturing

The company Bosch has recognized the potential of knowledge graphs, and a
series of subsequent publications highlight the company’s significant
advancements in the field of semantic data management and integration.
Firstly, OBDA using the SANSA Stack as well as OnTop has been reported in the
area of Surface Mount Technology (SMT), the process for mounting electronic
components on printed-circuit boards [79, 43]. This process involves several
subprocesses executed by specialized machines, each generating substantial
amounts of data. These data contain semantic interoperability conflicts, such
as variations in object naming. To effectively explore this data, these
conflicts need to be resolved by mapping them to ontology terms. The
development of the SMT Ontology resulted from a collaborative effort spanning
several weeks, involving a line engineer, two line managers, an SMT process
expert, an SMT data manager, a project manager, two Big Data managers, and
four semantic experts. Thus, adopting the VKG approach, which focuses on
producing high-quality mappings, is a labor-intensive process requiring the
combination of three types of knowledge initially: domain knowledge, database
schema details, and understanding of the VKG approach. However, once achieved,
an integrated Data View provided by the SMT Ontology enables domain experts to
perform intricate product analysis tasks on previously unintegrated raw data.

The development of knowledge graphs is a major undertaking for the company,
involving substantial initial effort but promising long-term solutions for
various complex challenges. Firstly, it serves the primary purpose of storing
knowledge and supporting material science engineers in their information
search [139]. Additionally, the focus extends to data-driven methods,
particularly enhancing the usability of Machine Learning (ML) analytics. This
entails managing heterogeneous data from a wide array of sources through a
unified mechanism, saving time in developing new ML solutions, and reusing
previously developed ones [140]. Their system comprises several semantic
artifacts: a core ontology that encapsulates general knowledge of the
manufacturing process, domain ontologies reflecting domain-specific knowledge,
and data-to-domain ontology mappings that link raw data attributes to domain
ontology terms to enable OBDA. Several semantic modules support the management
of the three fundamental building blocks: the KG generation module, a mapping
reasoner/annotator, and a data integration module. The company’s primary goal
is to leverage ML analytics to achieve a high degree of production automation.
All these components serve as prerequisites, culminating in a platform known
as SemML (Semantic Machine Learning) [43, 141], addressing three core
challenges through semantically enhanced ML: (1) communication, as the
workflow involves collaboration among experts from diverse areas, including
data scientists, engineers, process experts, and managers with distinct
backgrounds, making communication time-consuming and error-prone; (2) data
integration; and (3) generalizability of ML models.

###  5.2 Smart City

The digital transformation encompasses not only industrial applications but
also infrastructures for services of general interest, such as transportation
networks and associated transport options, water and energy supply, as well as
waste and wastewater disposal. These activities are commonly associated with
the term _Smart City_. In a Smart City, intelligent information and
communication technology is employed to enhance participation, quality of
life, and to create an economically, ecologically, and socially sustainable
community or region.

As described in Section 2.6, Bagozi et al. [40] and Bianchini et al. [41, 42]
utilize indicators to enable personalized data lake exploration, demonstrating
the model’s effectiveness in the Smart City environment due to its data and
user role diversity. Furthermore, Bianchini et al. [142] present a tool that
implements a semantic layer over a heterogeneous ecosystem of data sources,
serving as a starting point for semantics-enabled applications or data source
exploration. Their pipeline involves three steps: (1) Lexical enrichment of
attributes, standardizing concept names for annotation; (2) semantic
annotation of data attributes; and (3) creation of semantic relationships.

Similarly, Pomp et al. introduce a Semantic Data Marketplace for Easy Data
Sharing within a Smart City, applying a predecessor of PLASMA (refer to
Section 2) to the Smart City use case. The semantic data marketplace was
employed in a project242424https://youtu.be/3G9IQgK09sU, requiring teams to
develop Smart City applications based on datasets provided by city departments
from three different cities. Both approaches involve a Data Producer and a
Data Consumer. The Data Producer, a domain expert, is responsible for
uploading datasets and enriching them with semantic metadata from knowledge
graphs. Using the knowledge graph and associated semantic models, data
consumers can find and comprehend data by searching and reviewing semantic
concepts. VC-SLAM [29] (refer to Section 3.3), composed of 101 datasets with
corresponding semantic labels and a semantic model, has been constructed using
Smart City data extracted from Open Data portals. A recent survey [143]
introduces semantic Internet-of-Things technologies, which may play a crucial
role in addressing essential Smart City issues, primarily interoperability
challenges.

##  6 Challenges

Even though we have seen various tools in which KGs play a crucial role, a
comprehensive solution that provides truly scalable access to heterogeneous
data based on ontology-based mappings, including a semantic modeling component
to create and maintain the mappings, is not yet available. We have illustrated
this gap in Figure 7.

Figure 7: Venn-Diagram to illustrate our view of the current state in the
field of Semantic Data Management

In the Venn-diagram, we put three topics in relation: OBDA, semantic modeling,
and data lakes. Semantic Data Management may include more approaches, such as
the ETL approaches neglected here. The intersection between semantic modeling
and OBDA is represented for example by ODIN. The combination of OBDA for Big
Data and data lakes is illustrated for example by the manufacturing use case
[79]. However, it involved a great amount of manual labour by experts, is not
available (neither open-source nor as commercial system) and we found no
evidence that the semantic modeling techniques discussed in section 3 are
applied in this use case.

Semantic modeling is enabled within a data lake by ESKAPE. However, a custom
data format named Semantic Linked Tree (SLT) is used, which is a JSON-based
data format in which the semantic labels are attached to the raw data values.
This transformation can be interpreted as semantic lifting. Due to its rather
early development, the system also does not incorporate scalable data storage
and processing engines inherent to most modern data lakes.

OBDA has grown from a long tradition, it has been reported in production
several times, and recent proposals, such as SANSA and Chimera display
meaningful progress towards semantics-based on-demand data access. However,
the creation of the required mappings is a tedious, manual task for the user.
There is not yet enough assistance either by good user interfaces or automatic
procedures.

The field faces several challenges today:

  1. 1.

Initial overhead & usability: Creating meaningful semantic models for a large
number of heterogeneous data sets comes with a huge initial overhead in
generating KGs and the corresponding connections. First, generating domain-
specific conceptualizations is already time-consuming and resource-intensive,
quite apart from the fact that this task is truly an entire field of its own.
Even if we assume to have a versatile set of suitable KGs at hand, the
creation of suitable mappings to data sources is still a time-consuming
process. As presented in this survey, there are some proposals for automatic
creation of semantic models and mappings; yet, more emphasis should be put on
the required human input (see Technical abstraction).

  2. 2.

Evaluation: Automated generation of semantic labels and models has gained much
attention lately; however, it is unclear how accurate the methods really are,
beyond the scope of the test sets used in the particular publication. For
semantic labeling, SemTab has presented various data sets and benchmarks and
research is under way for more sophisticated table interpretation. For
semantic models, VC-SLAM is the very first proposal towards standardization of
a set of ontologies and data sets alongside the corresponding semantic models.
The emergence of annual challenges and the publication of benchmarks will be
helpful and could be further streamlined by an initiative similar to the
OAEI252525http://oaei.ontologymatching.org/ for ontology alignment.

  3. 3.

Technical interoperability: Considering the variety of today’s data landscape,
one has to point out that the majority of methods for semantic labeling and
modeling are based on tabular data. The field is yet far away from covering
all NoSQL data models uniformly. This is also the focus of modern OBDA
research. While scalable data access via ontologies can be regarded as solved
to a large extent for relational data, the focus has shifted more towards
incorporating different NoSQL query languages as well as supporting federated
query processing against multiple databases, file systems and other
miscellaneous data sources simultaneously. Any such solution must be
compatible with W3C standards for the Semantic Web to ensure maximal
interoperability between systems.

  4. 4.

Technical abstraction: The overall quality of a semantic model must ultimately
be refined by the human operator. This human-in-the-loop process needs
guidance for unfamiliar users through a strong technical abstraction, i.e.,
technical details must be hidden from the user. It is hard to imagine that
even with very enhanced AI techniques (see below Leverage AI), human
verification and refinement of mappings will become obsolete. Therefore,
enhanced user interfaces that focus on usability also for non-technical users
are required in this domain.

  5. 5.

Applicability for Big Data: Solutions like Squerall and Chimera are promising
approaches to address OBDA also in Big Data scenarios. Yet, there are many
limitations in the expressiveness of queries or mappings. Furthermore, they
are bound to specific versions of Big Data platforms which complicates their
deployment. The maturity of such solutions could be improved if a larger
community would continue the development of these prototypes, in order to
remove the aforementioned limitations and make them applicable to a wide
variety of NoSQL / Big Data systems.

  6. 6.

Leverage AI: Since the publication of ChatGPT, it has been discussed for many
human tasks whether they can be solved by Large Language Models (LLMs) in the
future. This is also relevant for all tasks related to data integration as
ChatGPT can describe data sources, create ontologies, find relationships
between different data sets, to name just a few examples of what can be
achieved with LLMs. In view of the latest development of AI techniques, we
have to expect that these systems will be able to solve more complex data
integration tasks in the future of which the first papers are appearing
already [144]. It would be interesting to see how such general-purpose AI
systems based can be customized and optimized for specific data integration
tasks within data lake systems at scale. On the other hand, we need to examine
the processes discussed in this survey to see at which points and how an AI
system based on LLMs can be integrated to improve the overall process.

##  7 Conclusion

In this article, we have given an overview of semantics-based methods for data
management, access, and integration and related those findings to current
semantic data lake proposals. Conclusively, we can state that the community
faces several challenges and a gap in today’s landscape between present data
lake platforms, OBDA and semantic technologies for modeling the context in
which heterogeneous data sets arise. The heterogeneity inherent to Big Data
applications is still a concern in the current OBDA platforms although there
has been significant progress recently.

In the previous section, we have pointed out several challenges that can be
addressed in this research area. We are confident that Big Data and Semantic
Web technologies can benefit from each other and that more enhanced solutions
for semantic data lakes will become available in the next years.

## References

  * [1] R. Hai, C. Quix, C. Zhou, Query rewriting for heterogeneous data lakes, in: Proc. ADBIS 2018, Vol. 11019 of LNCS, Springer, 2018, pp. 35–49.  doi:10.1007/978-3-319-98398-1\\_3.
URL https://doi.org/10.1007/978-3-319-98398-1_3

  * [2] A. Pomp, A. Paulus, A. Kirmse, V. Kraus, T. Meisen, Applying semantics to reduce the time to analytics within complex heterogeneous infrastructures, Technologies 6 (3) (2018) 86.
  * [3] E. Bionda, C. Tornelli, M. Brambilla, M. Balduini, G. Mauri, D. D. Giustina, F. Garrone, E. D. Valle, The smart grid semantic platform: Synergy between iec common information model (cim) and big data, in: Proc. IEEE EEEIC/I&CPS Europe), 2019, pp. 1–6.  doi:10.1109/EEEIC.2019.8783632.
  * [4] E. Kharlamov, T. Mailis, G. Mehdi, C. Neuenstadt, Ö. L. Özçep, M. Roshchin, N. Solomakhina, A. Soylu, C. Svingos, S. Brandt, M. Giese, Y. E. Ioannidis, S. Lamparter, R. Möller, Y. Kotidis, A. Waaler, Semantic access to streaming and static data at siemens, J. Web Semant. 44 (2017) 54–74.  doi:10.1016/j.websem.2017.02.001.
  * [5] M. Yahya, J. G. Breslin, M. I. Ali, Semantic web and knowledge graphs for industry 4.0, Applied Sciences 11 (11) (2021).
  * [6] A. Hogan, E. Blomqvist, M. Cochez, C. d’Amato, G. de Melo, C. Gutierrez, S. Kirrane, J. E. L. Gayo, R. Navigli, S. Neumaier, A. N. Ngomo, A. Polleres, S. M. Rashid, A. Rula, L. Schmelzeisen, J. F. Sequeda, S. Staab, A. Zimmermann, Knowledge graphs, ACM Comput. Surv. 54 (4) (2022) 71:1–71:37.  doi:10.1145/3447772.
URL https://doi.org/10.1145/3447772

  * [7] L. Ehrlinger, W. Wöß, Towards a definition of knowledge graphs, in: Proc. SEMANTiCS & SuCCESS, Vol. 1695 of CEUR WS, 2016\.
URL http://ceur-ws.org/Vol-1695/paper4.pdf

  * [8] G. Xiao, D. Calvanese, R. Kontchakov, D. Lembo, A. Poggi, R. Rosati, M. Zakharyaschev, Ontology-based data access: A survey, in: Proceedings of the Twenty-Seventh International Joint Conference on Artificial Intelligence, IJCAI 2018, July 13-19, 2018, Stockholm, Sweden, ijcai.org, 2018, pp. 5511–5519.
  * [9] R. Hai, S. Geisler, C. Quix, Constance: An intelligent data lake system, in: Proc. ACM SIGMOD, 2016, pp. 2097–2100.
  * [10] M. H. Farid, A. Roatis, I. F. Ilyas, H. Hoffmann, X. Chu, CLAMS: bringing quality to data lakes, in: Proc. ACM SIGMOD, 2016, pp. 2089–2092.  doi:10.1145/2882903.2899391.
  * [11] C. Bizer, T. Heath, T. Berners-Lee, Linked data, in: Semantic Services, Interoperability and Web Applications - Emerging Concepts, CRC Press, 2011, pp. 205–227.  doi:10.4018/978-1-60960-593-3.ch008.
URL https://doi.org/10.4018/978-1-60960-593-3.ch008

  * [12] A. Paulus, A. Burgdorf, A. Pomp, T. Meisen, Recent advances and future challenges of semantic modeling, in: Proc. 15th IEEE ICSC, IEEE, 2021, pp. 70–75.  doi:10.1109/ICSC50631.2021.00016.
  * [13] H. Dibowski, S. Schmid, Y. Svetashova, C. Henson, T. Tran, Using semantic technologies to manage a data lake: Data catalog, provenance and access control, in: Proc. Scalable Semantic Web Knowledge Base Systems Workshop, Vol. 2757 of CEUR WS, 2020, pp. 65–80.
URL http://ceur-ws.org/Vol-2757/SSWS2020_paper5.pdf

  * [14] A. Pomp, J. Lipp, T. Meisen, You are missing a concept! enhancing ontology-based data access with evolving ontologies, in: Proc. ICSC, IEEE, 2019, pp. 98–105.  doi:10.1109/ICOSC.2019.8665620.
  * [15] C. Quix, R. Hai, Data lake, in: Encyclopedia of Big Data Technologies, Springer, 2019.  doi:10.1007/978-3-319-63962-8\\_{7}{-}{1}.
URL https://doi.org/10.1007/978-3-319-63962-8_7-1

  * [16] P. N. Sawadogo, J. Darmont, On data lake architectures and metadata management, J. Intell. Inf. Syst. 56 (1) (2021) 97–120.  doi:10.1007/s10844-020-00608-7.
  * [17] R. Hai, C. Koutras, C. Quix, M. Jarke, Data lakes: A survey of functions and systems, IEEE Transactions on Knowledge and Data Engineering (2023) 1–20doi:10.1109/TKDE.2023.3270101.
  * [18] G. Xiao, L. Ding, B. Cogrel, D. Calvanese, Virtual knowledge graphs: An overview of systems and use cases, Data Intell. 1 (3) (2019) 201–223.
  * [19] J. Liu, Y. Chabot, R. Troncy, V.-P. Huynh, T. Labbé, P. Monnin, From tabular data to knowledge graphs: A survey of semantic table interpretation tasks and methods, Journal of Web Semantics (2022) 100761.
  * [20] A. Paulus, A. Burgdorf, L. Puleikis, T. Langer, A. Pomp, T. Meisen, PLASMA: platform for auxiliary semantic modeling approaches, in: Proc. ICEIS, SCITEPRESS, 2021, pp. 403–412.  doi:10.5220/0010499604030412.
  * [21] M. N. Mami, D. Graux, S. Scerri, H. Jabeen, S. Auer, J. Lehmann, Squerall: Virtual ontology-based access to heterogeneous and large data sources, in: Proc. ISWC, Vol. 11779 of LNCS, Springer, 2019, pp. 229–245.  doi:10.1007/978-3-030-30796-7\\_{1}{5}.
URL https://doi.org/10.1007/978-3-030-30796-7_15

  * [22] S. Galhotra, U. Khurana, Semantic search over structured data, in: Proceedings of the 29th ACM International Conference on Information & Knowledge Management, CIKM ’20, Association for Computing Machinery, New York, NY, USA, 2020, p. 3381–3384.  doi:10.1145/3340531.3417426.
URL https://doi.org/10.1145/3340531.3417426

  * [23] É. Scholly, P. N. Sawadogo, P. Liu, J. Espinosa-Oviedo, C. Favre, S. Loudcher, J. Darmont, C. Noûs, Coining goldmedal: A new contribution to data lake generic metadata modeling, in: Proc. DOLAP, Vol. 2840 of CEUR WS, 2021, pp. 31–40.
URL http://ceur-ws.org/Vol-2840/paper5.pdf

  * [24] D. Zhang, Y. Suhara, J. Li, M. Hulsebos, Ç. Demiralp, W. Tan, Sato: Contextual semantic type detection in tables, Proc. VLDB Endow. 13 (11) (2020) 1835–1848.
URL http://www.vldb.org/pvldb/vol13/p1835-zhang.pdf

  * [25] C. Quix, R. Hai, I. Vatov, Metadata extraction and management in data lakes with GEMMS, Complex Syst. Informatics Model. Q. 9 (2016) 67–83.  doi:10.7250/csimq.2016-9.04.
  * [26] R. C. Fernandez, Z. Abedjan, F. Koko, G. Yuan, S. Madden, M. Stonebraker, Aurum: A data discovery system, in: Proc. IEEE ICDE, 2018, pp. 1001–1012.  doi:10.1109/ICDE.2018.00094.
  * [27] Y. Suhara, J. Li, Y. Li, D. Zhang, Ç. Demiralp, C. Chen, W. Tan, Annotating columns with pre-trained language models, in: Proc. ACM SIGMOD, 2022, pp. 1493–1503.
URL https://doi.org/10.1145/3514221.3517906

  * [28] M. Hulsebos, K. Z. Hu, M. A. Bakker, E. Zgraggen, A. Satyanarayan, T. Kraska, Ç. Demiralp, C. A. Hidalgo, Sherlock: A deep learning approach to semantic data type detection, in: Proc. ACM SIGKDD, 2019, pp. 1500–1508.  doi:10.1145/3292500.3330993.
  * [29] A. Burgdorf, A. Paulus, A. Pomp, T. Meisen, VC-SLAM - A handcrafted data corpus for the construction of semantic models, Data 7 (2) (2022) 17.  doi:10.3390/data7020017.
  * [30] C. Pinkel, C. Binnig, E. Jiménez-Ruiz, E. Kharlamov, A. Nikolov, A. Schwarte, C. Heupel, T. Kraska, Incmap: A journey towards ontology-based data integration, in: Proc. BTW, Vol. P-265 of LNI, GI, 2017, pp. 145–164.
URL https://dl.gi.de/20.500.12116/625

  * [31] A. Paulus, A. Pomp, L. Poth, J. Lipp, T. Meisen, Gathering and combining semantic concepts from multiple knowledge bases, in: Proc. ICEIS, 2018, pp. 69–80.  doi:10.5220/0006800700690080.
  * [32] S. K. Ramnandan, A. Mittal, C. A. Knoblock, P. A. Szekely, Assigning semantic labels to data sources, in: Proc. ESWC, Vol. 9088 of LNCS, Springer, 2015, pp. 403–417.  doi:10.1007/978-3-319-18818-8\\_{2}{5}.
URL https://doi.org/10.1007/978-3-319-18818-8_25

  * [33] M. Pham, S. Alse, C. A. Knoblock, P. A. Szekely, Semantic labeling: A domain-independent approach, in: Proc. ISWC, Vol. 9981 of LNCS, 2016, pp. 446–462.
  * [34] N. Abdelmageed, S. Schindler, Jentab meets semtab 2021’s new challenges, in: Proc. SemTab, Vol. 3103 of CEUR WS, 2021, pp. 42–53.
URL http://ceur-ws.org/Vol-3103/paper4.pdf

  * [35] X. Deng, H. Sun, A. Lees, Y. Wu, C. Yu, TURL: table understanding through representation learning, SIGMOD Rec. 51 (1) (2022) 33–40.
  * [36] M. N. Mami, S. Scerri, S. Auer, M. Vidal, Towards semantification of big data technology, in: Proc. DaWaK 2016, Vol. 9829 of LNCS, Springer, 2016, pp. 376–390.  doi:10.1007/978-3-319-43946-4\\_{2}{5}.
URL https://doi.org/10.1007/978-3-319-43946-4_25

  * [37] R. Eichler, C. Giebler, C. Gröger, H. Schwarz, B. Mitschang, Modeling metadata in data lakes - A generic model, Data Knowl. Eng. 136 (2021) 101931\.
  * [38] C. Diamantini, P. L. Giudice, L. Musarella, D. Potena, E. Storti, D. Ursino, A new metadata model to uniformly handle heterogeneous data lake sources, in: Proc. ADBIS Short Papers & Workshops, Vol. 909 of CCIS, Springer, 2018, pp. 165–177.  doi:10.1007/978-3-030-00063-9\\_{1}{7}.
URL https://doi.org/10.1007/978-3-030-00063-9_17

  * [39] C. Diamantini, D. Potena, E. Storti, A semantic data lake model for analytic query-driven discovery, in: Proc. iiWAS, ACM, 2021, pp. 183–186.  doi:10.1145/3487664.3487783.
  * [40] A. Bagozi, D. Bianchini, V. D. Antonellis, M. Garda, M. Melchiori, Personalised exploration graphs on semantic data lakes, in: Proc. OTM Conf., Vol. 11877 of LNCS, Springer, 2019, pp. 22–39.  doi:10.1007/978-3-030-33246-4\\_2.
URL https://doi.org/10.1007/978-3-030-33246-4_2

  * [41] D. Bianchini, V. D. Antonellis, M. Garda, M. Melchiori, Exploiting smart city ontology and citizens’ profiles for urban data exploration, in: Proc. OTM Conf., Vol. 11229 of LNCS, Springer, 2018, pp. 372–389.  doi:10.1007/978-3-030-02610-3\\_{2}{1}.
URL https://doi.org/10.1007/978-3-030-02610-3_21

  * [42] D. Bianchini, V. D. Antonellis, M. Garda, M. Melchiori, Contextual preferences to personalise semantic data lake exploration, in: Proc. DEXA, Vol. 12392 of LNCS, Springer, 2020, pp. 322–332.  doi:10.1007/978-3-030-59051-2\\_{2}{2}.
URL https://doi.org/10.1007/978-3-030-59051-2_22

  * [43] E. G. Kalayci, I. Grangel-González, F. Lösch, G. Xiao, A. ul Mehdi, E. Kharlamov, D. Calvanese, Semantic integration of bosch manufacturing data using virtual knowledge graphs, in: Proc. ISWC, Vol. 12507 of LNCS, Springer, 2020, pp. 464–481.
  * [44] D. Calvanese, L. Ding, A. Mosca, G. Xiao, Realizing ontology-based reusable interfaces for data access via virtual knowledge graphs, in: Proc. Italian SIGCHI (CHItaly), ACM, 2021, pp. 35:1–35:5.  doi:10.1145/3464385.3464744.
  * [45] A. Y. Halevy, F. Korn, N. F. Noy, C. Olston, N. Polyzotis, S. Roy, S. E. Whang, Goods: Organizing google’s datasets, in: Proc. ACM SIGMOD, 2016, pp. 795–806.  doi:10.1145/2882903.2903730.
URL https://doi.org/10.1145/2882903.2903730

  * [46] P. Liu, S. Loudcher, J. Darmont, E. Perrin, J. Girard, M. Rousset, Metadata model for an archeological data lake, in: Proc. Digital Humanities Conf., 2020\.
URL https://dh2020.adho.org/wp-
content/uploads/2020/07/206_Metadatamodelforanarcheologicaldatalake.html

  * [47] A. Helal, M. Helali, K. Ammar, E. Mansour, A demonstration of kglac: A data discovery and enrichment platform for data science, Proc. VLDB Endow. 14 (12) (2021) 2675–2678.  doi:10.14778/3476311.3476317.
URL http://www.vldb.org/pvldb/vol14/p2675-helal.pdf

  * [48] A. Beheshti, B. Benatallah, R. Nouri, A. Tabebordbar, Corekg: a knowledge lake service, Proc. VLDB Endow. 11 (12) (2018) 1942–1945.  doi:10.14778/3229863.3236230.
URL http://www.vldb.org/pvldb/vol11/p1942-beheshti.pdf

  * [49] C. Stach, J. Bräcker, R. Eichler, C. Giebler, B. Mitschang, Demand-driven data provisioning in data lakes: BARENTS - A tailorable data preparation zone, in: Proc. iiWAS, ACM, 2021, pp. 187–198.  doi:10.1145/3487664.3487784.
  * [50] M. Zaharia, A. Ghodsi, R. Xin, M. Armbrust, Lakehouse: A new generation of open platforms that unify data warehousing and advanced analytics, in: Proc. CIDR, 2021.
URL http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

  * [51] G. A. Braun, L. A. Cecchi, P. R. Fillottrani, Towards _All-In-One_ OBDA systems, in: Proc. Styrian Autumn of Ontology, Vol. 2518 of CEUR WS, 2019\.
URL http://ceur-ws.org/Vol-2518/paper-DAOSI1.pdf

  * [52] A. Pomp, A. Paulus, S. Jeschke, T. Meisen, ESKAPE: information platform for enabling semantic data processing, in: Proc. ICEIS, SciTePress, 2017, pp. 644–655.  doi:10.5220/0006324906440655.
  * [53] S. Gupta, P. A. Szekely, C. A. Knoblock, A. Goel, M. Taheriyan, M. Muslea, Karma: A system for mapping structured sources into the semantic web, in: ESWC Satellite Events - Revised Selected Papers, Vol. 7540 of LNCS, Springer, 2012, pp. 430–434.  doi:10.1007/978-3-662-46641-4\\_40.
URL https://doi.org/10.1007/978-3-662-46641-4_40

  * [54] A. Pomp, J. Lipp, T. Meisen, Enabling the continuous evolution of ontologies for ontology-based data management, Intl. Journal of Robotic Computing (2019).
  * [55] S. Nadal, K. Rabbani, O. Romero, S. Tadesse, ODIN: A dataspace management system, in: ISWC Satellite Tracks, Vol. 2456 of CEUR WS, 2019, pp. 185–188.
URL http://ceur-ws.org/Vol-2456/paper48.pdf

  * [56] C. Pinkel, C. Binnig, E. Jiménez-Ruiz, E. Kharlamov, W. May, A. Nikolov, A. S. Bastinos, M. G. Skjæveland, A. Solimando, M. Taheriyan, C. Heupel, I. Horrocks, RODI: benchmarking relational-to-ontology mapping generation quality, Semantic Web 9 (1) (2018) 25–52.  doi:10.3233/SW-170268.
  * [57] S. Gottschalk, E. Demidova, Tab2kg: Semantic table interpretation with lightweight semantic profiles, Semantic Web (2022) 1–27.
  * [58] B. Vu, C. A. Knoblock, J. Pujara, Learning semantic models of data sources using probabilistic graphical models, in: Proc. WWW, 2019, pp. 1944–1953.  doi:10.1145/3308558.3313711.
  * [59] B. Vu, C. A. Knoblock, P. A. Szekely, M. Pham, J. Pujara, A graph-based approach for inferring semantic descriptions of wikipedia tables, in: Proc. ISWC, Vol. 12922 of LNCS, Springer, 2021, pp. 304–320.  doi:10.1007/978-3-030-88361-4\\_{1}{8}.
URL https://doi.org/10.1007/978-3-030-88361-4_18

  * [60] R. Avogadro, M. Cremaschi, Mantistable V: A novel and efficient approach to semantic table interpretation, in: Proc. SemTab, Vol. 3103 of CEUR WS, 2021, pp. 79–91.
URL http://ceur-ws.org/Vol-3103/paper7.pdf

  * [61] R. Shigapov, P. Zumstein, J. Kamlah, L. Oberländer, J. Mechnich, I. Schumm, bbw: Matching CSV to wikidata via meta-lookup, in: Proc. SemTab 2020, Vol. 2775 of CEUR WS, 2020, pp. 17–26.
URL http://ceur-ws.org/Vol-2775/paper2.pdf

  * [62] P. Nguyen, I. Yamada, N. Kertkeidkachorn, R. Ichise, H. Takeda, Mtab4wikidata at semtab 2020: Tabular data annotation with wikidata, in: Proc. SemTab, Vol. 2775 of CEUR WS, 2020, pp. 86–95.
URL http://ceur-ws.org/Vol-2775/paper9.pdf

  * [63] Z. Feng, W. Mayer, M. Stumptner, G. Grossmann, S. Kwashie, D. Ning, K. He, Asmaas: Automatic semantic modeling as a service, in: Proc. IEEE SERVICES, 2021, pp. 33–40.  doi:10.1109/SERVICES51467.2021.00033.
  * [64] G. Futia, A. Vetrò, J. C. D. Martin, Semi: A semantic modeling machine to build knowledge graphs with graph neural networks, SoftwareX 12 (2020) 100516\.  doi:10.1016/j.softx.2020.100516.
  * [65] M. Taheriyan, C. A. Knoblock, P. A. Szekely, J. L. Ambite, A graph-based approach to learn semantic descriptions of data sources, in: Proc. ISWC, Vol. 8218 of LNCS, Springer, 2013, pp. 607–623.  doi:10.1007/978-3-642-41335-3\\_{3}{8}.
URL https://doi.org/10.1007/978-3-642-41335-3_38

  * [66] M. Taheriyan, C. A. Knoblock, P. A. Szekely, J. L. Ambite, Leveraging linked data to discover semantic relations within data sources, in: Proc. ISWC, Vol. 9981 of LNCS, 2016, pp. 549–565.  doi:10.1007/978-3-319-46523-4\\_{3}{3}.
URL https://doi.org/10.1007/978-3-319-46523-4_33

  * [67] M. Taheriyan, C. A. Knoblock, P. A. Szekely, J. L. Ambite, Learning the semantics of structured data sources, J. Web Semant. 37-38 (2016) 152–169.  doi:10.1016/j.websem.2015.12.003.
  * [68] C. A. Knoblock, P. A. Szekely, J. L. Ambite, A. Goel, S. Gupta, K. Lerman, M. Muslea, M. Taheriyan, P. Mallick, Semi-automatically mapping structured sources into the semantic web, in: Proc. ESWC, Vol. 7295 of LNCS, Springer, 2012, pp. 375–390.  doi:10.1007/978-3-642-30284-8\\_{3}{2}.
URL https://doi.org/10.1007/978-3-642-30284-8_32

  * [69] A. Burgdorf, A. Paulus, A. Pomp, T. Meisen, Docsemmap: Leveraging textual data documentations for mapping structured data sets into knowledge graphs, in: Proc. IEEE ICSC, 2022, pp. 209–216.  doi:10.1109/ICSC52841.2022.00042.
  * [70] M. Ramirez, A. Bogatu, N. W. Paton, A. Freitas, Natural language inference over tables: Enabling explainable data exploration on data lakes, in: Proc. ESWC, Vol. 12731 of LNCS, Springer, 2021, pp. 304–320.  doi:10.1007/978-3-030-77385-4\\_{1}{8}.
URL https://doi.org/10.1007/978-3-030-77385-4_18

  * [71] R. C. Fernandez, E. Mansour, A. A. Qahtan, A. K. Elmagarmid, I. F. Ilyas, S. Madden, M. Ouzzani, M. Stonebraker, N. Tang, Seeping semantics: Linking datasets using word embeddings for data discovery, in: Proc. IEEE ICDE, 2018, pp. 989–1000.  doi:10.1109/ICDE.2018.00093.
  * [72] D. Haller, R. Lenz, Pharos: Query-driven schema inference for the semantic web, in: ECML/PKDD Workshops, Part II, Vol. 1168 of CCIS, Springer, 2019, pp. 112–124.  doi:10.1007/978-3-030-43887-6\\_{1}{0}.
URL https://doi.org/10.1007/978-3-030-43887-6_10

  * [73] D. Haller, R. Lenz, Discovery of ontologies from implicit user knowledge, in: Proc. Conf. on "Lernen, Wissen, Daten, Analysen", Vol. 2738 of CEUR WS, 2020, pp. 241–245.
URL http://ceur-ws.org/Vol-2738/LWDA2020_paper_4.pdf

  * [74] P. A. Szekely, C. A. Knoblock, J. Slepicka, A. Philpot, A. Singh, C. Yin, D. Kapoor, P. Natarajan, D. Marcu, K. Knight, D. Stallard, S. S. Karunamoorthy, R. Bojanapalli, S. Minton, B. Amanatullah, T. Hughes, M. Tamayo, D. Flynt, R. Artiss, S. Chang, T. Chen, G. Hiebel, L. S. Ferreira, Building and using a knowledge graph to combat human trafficking, in: Proc. ISWC, Vol. 9367 of LNCS, Springer, 2015, pp. 205–221.  doi:10.1007/978-3-319-25010-6\\_{1}{2}.
URL https://doi.org/10.1007/978-3-319-25010-6_12

  * [75] A. Pomp, A. Paulus, A. Burgdorf, T. Meisen, A semantic data marketplace for easy data sharing within a smart city, in: Proceedings of the 30th ACM International Conference on Information & Knowledge Management, CIKM ’21, Association for Computing Machinery, New York, NY, USA, 2021, p. 4774–4778.  doi:10.1145/3459637.3481995.
URL https://doi.org/10.1145/3459637.3481995

  * [76] Y. Chabot, T. Labbé, J. Liu, R. Troncy, DAGOBAH: an end-to-end context-free tabular data semantic annotation system, in: Proc. SemTab, Vol. 2553 of CEUR WS, 2019, pp. 41–48.
URL http://ceur-ws.org/Vol-2553/paper6.pdf

  * [77] P. Nguyen, N. Kertkeidkachorn, R. Ichise, H. Takeda, Mtab: Matching tabular data to knowledge graph with probability models, in: Proc. Workshop on Ontology Matching, Vol. 2536 of CEUR WS, 2019, pp. 191–192.
URL http://ceur-ws.org/Vol-2536/om2019_poster2.pdf

  * [78] N. Abdelmageed, S. Schindler, Jentab: A toolkit for semantic table annotations, in: Proc. Workshop on Knowledge Graph Construction, Vol. 2873 of CEUR WS, 2021.
URL http://ceur-ws.org/Vol-2873/paper5.pdf

  * [79] M. N. Mami, I. Grangel-González, D. Graux, E. Elezi, F. Lösch, Semantic data integration for the SMT manufacturing process using SANSA stack, in: ESWC Satellite Events, Revised Selected Papers, Vol. 12124 of LNCS, Springer, 2020, pp. 307–311.  doi:10.1007/978-3-030-62327-2\\_{4}{7}.
URL https://doi.org/10.1007/978-3-030-62327-2_47

  * [80] L. Gagliardelli, L. Zecchini, D. Beneventano, G. Simonini, S. Bergamaschi, M. Orsini, M. Luca, M. Emma, L. Andrea, G. Nicola, et al., Ecdp: A big data platform for the smart monitoring of local energy communities, in: CEUR WORKSHOP PROCEEDINGS, Vol. 3135, 2022.
  * [81] A. Poggi, D. Lembo, D. Calvanese, G. D. Giacomo, M. Lenzerini, R. Rosati, Linking data to ontologies, J. Data Semant. 10 (2008) 133–173.
  * [82] N. Fathy, W. Gad, N. Badr, A unified access to heterogeneous big data through ontology-based semantic integration, in: Proc. ICICIS, IEEE, 2019, pp. 387–392.
  * [83] Z. Gu, F. Corcoglioniti, D. Lanti, A. Mosca, G. Xiao, J. Xiong, D. Calvanese, A systematic overview of data federation systems, submitted, not yet accepted (2022).
  * [84] M. Lenzerini, Data integration: A theoretical perspective, in: Proc. ACM PODS, 2002, pp. 233–246.  doi:10.1145/543613.543644.
URL https://doi.org/10.1145/543613.543644

  * [85] M. N. Mami, D. Graux, H. Thakkar, S. Scerri, S. Auer, J. Lehmann, The query translation landscape: a survey, CoRR abs/1910.03118 (2019).  arXiv:1910.03118.
URL http://arxiv.org/abs/1910.03118

  * [86] D. Calvanese, G. D. Giacomo, D. Lembo, M. Lenzerini, A. Poggi, M. Rodriguez-Muro, R. Rosati, M. Ruzzi, D. F. Savo, The MASTRO system for ontology-based data access, Semantic Web 2 (1) (2011) 43–53.  doi:10.3233/SW-2011-0029.
  * [87] J. F. Sequeda, D. P. Miranker, Ultrawrap: SPARQL execution on relational data, J. Web Semant. 22 (2013) 19–39.  doi:10.1016/j.websem.2013.08.002.
  * [88] F. Priyatna, Ó. Corcho, J. F. Sequeda, Formalisation and experiences of r2rml-based SPARQL to SQL query translation using morph, in: Proc. WWW, ACM, 2014, pp. 479–490.  doi:10.1145/2566486.2567981.
  * [89] E. Kharlamov, E. Jiménez-Ruiz, D. Zheleznyakov, D. Bilidas, M. Giese, P. Haase, I. Horrocks, H. Kllapi, M. Koubarakis, Ö. L. Özçep, M. Rodriguez-Muro, R. Rosati, M. Schmidt, R. Schlatte, A. Soylu, A. Waaler, Optique: Towards OBDA systems for industry, in: Proc. ESWC Satellite Events, Revised Selected Papers, Vol. 7955 of LNCS, Springer, 2013, pp. 125–140.  doi:10.1007/978-3-642-41242-4\\_{1}{1}.
URL https://doi.org/10.1007/978-3-642-41242-4_11