# Directly Mapping RDF Databases to Property Graph Databases111A newer version
of this article has been accepted and published at the IEEE Access Journal,
DOI: 10.1109/ACCESS.2020.2993117. Please refer to and cite [1] for the latest
version of this article.

Renzo Angles, Harsh Thakkar, Dominik Tomaszuk

###### Abstract

RDF triplestores and property graph databases are two approaches for data
management which are based on modeling, storing and querying graph-like data.
In spite of such common principle, they present special features that
complicate the task of database interoperability. While there exist some
methods to transform RDF graphs into property graphs, and vice versa, they
lack compatibility and a solid formal foundation. This paper presents three
direct mappings (schema-dependent and schema-independent) for transforming an
RDF database into a property graph database, including data and schema. We
show that two of the proposed mappings satisfy the properties of semantics
preservation and information preservation. The existence of both mappings
allows us to conclude that the property graph data model subsumes the
information capacity of the RDF data model.

##  1 Introduction

RDF [22] and Graph databases [29] are two approaches for data management that
are based on modeling, storing and querying graph-like data. The database
systems based on these models are gaining relevance in the industry due to
their use in various application domains where complex data analytics is
required [3].

RDF triplestores and graph database systems are tightly connected as they are
based on graph data models. RDF databases are based on the RDF data model
[22], their standard query language is SPARQL [16], and RDF Schema [9] allows
to describe classes of resources and properties (i.e. the data schema). On the
other hand, most graph databases are based on the Property Graph (PG) data
model, there is no standard query language, and there is no standard notion of
property graph schema [27]. Therefore, RDF and PG database systems are
dissimilar in data model, schema constraints and query language.

Motivation. The term “Interoperability” was introduced in the area of
information systems, and is defined as the ability of two or more systems or
components to exchange information, and to use the information that has been
exchanged [34]. In the context of data management, interoperability is
concerned with the support of applications that share and exchange information
across the boundaries of existing databases [30].

Databases interoperability is relevant for several reasons, including:
promotes data exchange and data integration [26, 25]; facilitates the reuse of
available systems and tools [23, 30]; enables a fair comparison of database
systems by using benchmarks [2, 35, 37]; and supports the success of emergent
systems and technologies [30, 36].

Given the heterogeneity between RDF triplestores and graph database systems,
and considering their graph-based data models, it becomes necessary to develop
methods to allow interoperability among these systems.

The Problem. To the best of our knowledge, the research about the
interoperability between RDF and PG databases is very restricted (cf. Section
5). While there exist some system-specific approaches, most of them are
restricted to data transformation and lack of solid formal foundations.

Objectives & Contributions. Database interoperability can be divided into
syntactic interoperability (i.e. data format transformation), semantic
interoperability (i.e. data exchange via schema and instance mappings) and
query interoperability (i.e. transformations among different query languages
or data accessing methods) [4].

The main objective of this paper is to study the semantic interoperability
between RDF and PG databases. Specifically, we propose two mappings to
translate RDF databases into PG databases. We study two desirable properties
of these database mappings, named semantics preservation and information
preservation. Based on such database mappings, we conclude that the PG data
model subsumes the information capacity of the RDF data model.

The remainder of this paper is as follows: A formal background is presented in
Section 2, including definitions related to database mappings, RDF databases,
and Property Graph databases; A schema-dependent database mapping, to
transform RDF databases into PG databases, is presented in Section 3; A
schema-independent database mapping is presented in Section 4; The related
work is presented in Section 5; Our conclusions are presented in Section 6.

##  2 Preliminaries

This section presents a formal background to study the interoperability
between RDF and PG databases. In particular, we formalize the notions of
database mapping, RDF database, and property graph database.

###  2.1 Database mappings

In general terms, a database mapping is a method to translate databases from a
source database model to a target database model. We can consider two types of
database mappings: _direct database mappings_ , which allow an automatic
translation of databases without any input from the user [33]; and _manual
database mappings_ , which require additional information (e.g. an ontology)
to conduct the database translation. In this paper, we focus on direct
database mappings.

##### Database schema and instance

Let $M$ be a database model. A _database schema_ in $M$ is a set of semantic
constraints allowed by $M$. A _database instance_ in $M$ is a collection of
data represented according to $M$. A _database_ in $M$ is an ordered pair
$D^{M}=(S^{M},I^{M})$, where $S^{M}$ is a schema and $I^{M}$ is an instance.

Note that the above definition does not establish that the database instance
satisfies the constraints defined by the database schema. Given a database
instance $I^{M}$ and a database schema $S^{M}$, we say that $I^{M}$ is valid
with respect to $S^{M}$, denoted $I^{M}\models S^{M}$, iff $I^{M}$ satisfies
the constraints defined by $S^{M}$. Given a database $D^{M}=(S^{M},I^{M})$, we
say that $D^{M}$ is a valid database iff it satisfies that $I^{M}\models
S^{M}$.

##### Schema, instance, and database mapping

A database mapping defines a way to translate databases from a “target”
database model to a “source” database model. For the rest of this section,
assume that $M_{1}$ and $M_{2}$ are the source and the target database models
respectively.

Considering that a database includes a schema and an instance, we first define
the notions of schema mapping and instance mapping. A _schema mapping_ from
$M_{1}$ to $M_{2}$ is a function $\mathcal{SM}$ from the set of all database
schemas in $M_{1}$, to the set of all database schemas in $M_{2}$. Similarly,
an _instance mapping_ from $M_{1}$ to $M_{2}$ is a function $\mathcal{IM}$
from the set of all database instances in $M_{1}$, to the set of all database
instances in $M_{2}$.

A database mapping from $M_{1}$ to $M_{2}$ is a function $\mathcal{DM}$ from
the set of all databases in $M_{1}$, to the set of all databases in $M_{2}$.
Specifically, a database mapping is defined as the combination of a schema
mapping and an instance mapping.

######  Definition 1 (Database Mapping)

A database mapping is a pair $\mathcal{DM}=(\mathcal{SM},\mathcal{IM})$ where
$\mathcal{SM}$ is a schema mapping and $\mathcal{IM}$ is an instance mapping.

####  2.1.1 Properties of database mappings

Every data model allows to structure the data in a specific way, or using a
particular abstraction. Such abstraction determines the conceptual elements
that the data model can represent, i.e. its representation power or
information capacity [21].

Given two database models $M_{1}$ and $M_{2}$, the possibility to exchange
databases between them depends on their information capacity. Specifically, we
say that $M_{1}$ subsumes the information capacity of $M_{2}$ iff every
database in $M_{2}$ can be translated to a database in $M_{2}$. Additionally,
we say that $M_{1}$ and $M_{2}$ have the same information capacity iff $M_{1}$
subsumes $M_{2}$ and $M_{2}$ subsumes $M_{1}$.

The information capacity of two database models can be evaluated in terms of a
database mapping satisfying some properties. In particular, we consider three
properties: computability, semantics preservation, and information
preservation.

Assume that $\mathcal{D}_{1}$ is the set of all databases in a source database
model $M_{1}$, and $\mathcal{D}_{2}$ is the set of all databases in a target
database model $M_{2}$.

######  Definition 2 (Computable mapping)

A database mapping $\mathcal{DM}:\mathcal{D}_{1}\to\mathcal{D}_{2}$ is
computable if there exists an algorithm $\mathcal{A}$ that, given a database
$D\in\mathcal{D}_{1}$, $\mathcal{A}$ computes $\mathcal{DM}(D)$.

The property of computability indicates the existence and feasibility of
implementing a database mapping from $M_{1}$ to $M_{2}$. This property also
implicates that $M_{2}$ subsumes the information capacity of $M_{1}$.

######  Definition 3 (Semantics preservation)

A computable database mapping $\mathcal{DM}:\mathcal{D}_{1}\to\mathcal{D}_{2}$
is semantics preserving if for every valid database $D\in\mathcal{D}_{1}$,
there is a valid database $D^{\prime}\in\mathcal{D}_{2}$ satisfying that
$D^{\prime}=\mathcal{DM}(D)$.

Semantics preservation indicates that the output of a database mapping is
always a valid database. Specifically, the output database instance satisfies
the constraints defined by the output database schema. In this sense, we can
say that this property evaluates the correctness of a database mapping.

######  Definition 4 (Information preservation)

A database mapping $\mathcal{DM}=(\mathcal{SM},\mathcal{IM})$ from $M_{1}$ to
$M_{2}$ is information preserving if there is a computable database mapping
$\mathcal{DM}^{-1}=(\mathcal{SM}^{-1},\mathcal{IM}^{-1})$ from $M_{2}$ to
$M_{1}$ such that for every database $D=(S,I)$ in $M_{1}$, it applies that
$D=\mathcal{DM}^{-1}(\mathcal{DM}(D))$.

Information preservation indicates that, for some database mapping
$\mathcal{DM}_{1}$, there exists an “inverse” database mapping
$\mathcal{DM}^{-1}$ which allows to recover a database transformed with
$\mathcal{DM}_{1}$. Note that the above definition implies the existence of
both a “inverse” schema mapping $\mathcal{SM}^{-1}$ and a “inverse” instance
mapping $\mathcal{IM}^{-1}$.

Information preservation is a fundamental property because it guarantees that
a database mapping does not lose information [33]. Moreover, it implies that
the information capacity of the target database model subsumes the information
capacity of the source database model.

Our goal is to define database mappings between the RDF data model and the
Property Graph data model. Hence, next, we will present a formal definition of
the notions of instance, schema, and database for them.

###  2.2 RDF Databases

An RDF database is an approach for data management which is oriented to
describe the information about Web resources by using Web models and
languages. In this section we describe two fundamental standards used by RDF
databases: the Resource Description Framework (RDF) [22], which is the
standard data model to describe the data; and RDF Schema [9], which is a
standard vocabulary to describe the structure of the data.

####  2.2.1 RDF Graph.

Assume that I and L are two disjoint infinite sets, called IRIs and Literals
respectively. IRIs are used as web resource identifiers and Literals are used
as values (e.g. strings, numbers or dates). In addition to IRIs and Literals,
the RDF data model considers a domain of anonymous resources called Blank
Nodes. Based on the work of Hogan et al. [20], we avoid the use of Blank Nodes
as that their absence does not affect the results presented in this paper.
Moreover, we can obtain similar results by replacing Blank Nodes with IRIs
(via Skolemisation [20]).

An RDF triple is a tuple $t=(v_{1},v_{2},v_{3})$ where $v_{1}\in\textbf{I}$ is
called the _subject_ , $v_{2}\in\textbf{I}$ is the _predicate_ and
$v_{3}\in\textbf{I}\cup\textbf{L}$ is the _object_. Here, the subject
represents a resource (identified by an IRI), the predicate represents a
relationship of the resource (identified by an IRI), and the object represents
the value of such relationship (which is either an IRI or a literal).

Let $S$ be a set of RDF triples. We use $\operatorname{sub}(S)$,
$\operatorname{pred}(S)$ and $\operatorname{obj}(S)$ to denote the sets of
subjects, predicates, and objects in $S$ respectively. There are different
data formats to encode a set of RDF triples. The following example shows an
RDF description encoded using the Turtle data format [28].

###### Example 2.1

⬇

1@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

2@prefix xsd: <http://www.w3.org/2001/XMLSchema#>

3@prefix voc: <http://www.example.org/voc/> .

4@prefix ex: <http://www.example.org/data/> .

5ex:Tesla_Inc rdf:type voc:Organisation ;

6 voc:name "Tesla, Inc." ;

7 voc:creation "2003-07-01"^^xsd:date .

8ex:Elon_Musk rdf:type voc:Person ;

9 voc:birthName "Elon Musk" ;

10 voc:age "46"^^xsd:int ;

11 voc:ceo ex:Tesla_Inc .

The lines beginning with @prefix are prefix definitions and the rest are RDF
triples. A prefix definition associates a prefix (e.g. voc) with an IRI (e.g.
http://www.example.org/voc/). Hence, a full IRI like
http://www.example.org/voc/Person can be abbreviated as a prefixed named
voc:Person. We will use $\operatorname{prefix}(r)$ and
$\operatorname{name}(r)$ to extract the prefix and the name of an IRI $r$
respectively. We will consider two types of literals: a literal which consists
of a string and a datatype IRI (e.g. "46"^^xsd:int), and a literal which is a
Unicode string (e.g. "Elon Musk"), which is a synonym for a xsd:string literal
(e.g. "Elon Musk"^^xsd:string).

A set of RDF triples can be visualized as a graph where the nodes represent
the resources, and the edges represent properties and values. However, the RDF
model has a special feature: an IRI can be used as an object and predicate in
an RDF graph. For instance, the triple (voc:ceo, rdfs:label, "Chief Executive
Officer") can be added to the graph shown in Example 2.1 to include metadata
about the property voc:ceo. It implies that an RDF graph is not a traditional
graph because it allows edges between edges, and consequently an RDF graph
cannot be visualized in a traditional way. Next, we present a formal
definition of the RDF data model which supports a traditional graph-based
representation.

######  Definition 5 (RDF Graph)

An RDF graph is defined as a tuple
$G^{R}=(N_{I},N_{L},E_{O},E_{D},\alpha_{I},\alpha_{L},\beta_{O},\beta_{D},\delta)$
where:

  * •

$N_{I}$ is a finite set of nodes representing RDF resources (i.e. resource
nodes);

  * •

$N_{L}$ is a finite set of nodes representing RDF literals (i.e. literal
nodes), satisfying that $N_{I}\cap N_{L}=\emptyset$;

  * •

$E_{O}$ is a finite set of edges called object property edges;

  * •

$E_{D}$ is a finite set of edges called datatype property edges, satisfying
that $E_{O}\cap E_{D}=\emptyset$222We borrowed the names from Web Ontology
Language.;

  * •

$\alpha_{I}:N_{I}\rightarrow\textbf{I}$ is a total one-to-one function that
associates each resource node with a single IRI;

  * •

$\alpha_{L}:N_{L}\rightarrow\textbf{L}$ is a total one-to-one function that
associates each literal node with a single literal;

  * •

$\beta_{O}:E_{O}\rightarrow(N_{I}\times N_{I})$ is a total function that
associates each object property edge with a pair of resource nodes;

  * •

$\beta_{D}:E_{D}\rightarrow(N_{I}\times N_{L})$ is a total function that
associates each datatype property edge with a resource node and a literal
node;

  * •

$\delta$: $(N_{I}\cup N_{L}\cup E_{O}\cup E_{D})\rightarrow\textbf{I}$ is a
partial function that assigns a resource class label to each node or edge.

Note that the function $\delta$ has been defined as being partial to support a
partial connection between schema and data (which is usual in real RDF
datasets). Concerning the issue about an IRI $u$ occurring as both resource
and property, note that $u$ will occur as resource and property separately. In
such a case, we will have a bipartite graph.

In order to facilitate the transformation of RDF data to Property Graphs, we
will assume that every node or edge in an RDF graph defines a resource class.
This assumption is shown by the following procedure which allows transforming
a set of RDF triples into a formal RDF graph.

The procedure to create an RDF Graph from a set $S$ of RDF triples is defined
as follows:

  * •

For every resource $r\in\operatorname{sub}(S)$, there is a node $n\in N_{I}$
with $\alpha_{I}(n)=r$;

    * –

If $(r,\texttt{\small rdf:type},c)\in S$ then $\delta(n)=c$, else
$\delta(n)=\texttt{\small rdfs:Resource}$;

  * •

For every literal $l\in\operatorname{obj}(S)\cap\textbf{L}$, there is a node
$n\in N_{L}$;

    * –

If $l$ is a literal of the form value then $\alpha_{L}(n)=l$ and
$\delta(n)=\texttt{\small xsd:string}$;

    * –

If $l$ is a literal of the form value^^datatype then $\alpha_{L}(n)$ = value
and $\delta(n)$ = datatype;

  * •

For every triple $(s,p,o)\in S$ where $o\in\textbf{I}$, there is an edge $e\in
E_{O}$ with $\delta(e)=p$ and $\beta_{O}(e)=(n,n^{\prime})$, such that
$\alpha_{I}(n)=s$ and $\alpha_{I}(n^{\prime})=o$;

  * •

For every triple $(s,p,o)\in S$ where $o\in\textbf{L}$, there is an edge $e\in
E_{D}$ with $\delta(e)=p$ and $\beta_{D}(e)=(n,n^{\prime})$, such that
$\alpha_{I}(n)=s$ and $\alpha_{L}(n^{\prime})=o$.

Hence, the RDF graph obtained from the set of RDF triples shown in Example 2.1
is given as follows:

⬇

1$N_{I}=\\{n_{1},n_{2}\\}$, $N_{L}=\\{n_{3},n_{4},n_{5},n_{6}\\}$,

2$E_{O}=\\{e_{1}\\}$, $E_{D}=\\{e_{2},e_{3},e_{4},e_{5}\\}$,

3$\alpha_{I}(n_{1})=\text{ex:tesla\\_Inc}$,
$\alpha_{I}(n_{2})=\text{ex:Elon\\_Musk}$,

4$\alpha_{L}(n_{3})=\text{"Tesla, Inc."}$,
$\alpha_{L}(n_{4})=\text{"2003-07-01"}$, $\alpha_{L}(n_{5})=\text{"Elon
Musk"}$, $\alpha_{L}(n_{6})=\text{46}$,

5$\beta_{O}(e_{1})=(n_{1},n_{2})$,

6$\beta_{D}(e_{2})=(n_{1},n_{3})$, $\beta_{D}(e_{3})=(n_{1},n_{4})$,
$\beta_{D}(e_{4})=(n_{2},n_{5})$, $\beta_{D}(e_{5})=(n_{2},n_{6})$,

7$\delta(n_{1})=\text{voc:Organisation}$, $\delta(n_{2})=\text{voc:Person}$,
$\delta(n_{3})=\text{xsd:string}$, $\delta(n_{4})=\text{xsd:date}$,
$\delta(n_{5})=\text{xsd:string}$, $\delta(n_{6})=\text{xsd:int}$,

8$\delta(e_{1})=\text{voc:ceo}$, $\delta(e_{2})=\text{voc:name}$,
$\delta(e_{3})=\text{voc:creation}$, $\delta(e_{4})=\text{voc:birthName}$,
$\delta(e_{5})=\text{voc:age}$.

Additionally, Figure 1 shows a graphical representation of the RDF graph
described above. The resource nodes are represented as ellipses and literal
nodes are presented as rectangles. Each node is labeled with two IRIs: the
inner IRI indicates the resource identifier, and the outer IRI indicates a
resource class. Each edge is labeled with an IRI that indicates its property
class.

Figure 1: Graphical illustration of an RDF graph.

####  2.2.2 RDF Graph Schema.

RDF Schema (RDFS) [9] defines a standard vocabulary (i.e., a set of terms,
each having a well-defined meaning) which enables the description of resource
classes and property classes. From a database perspective, RDF Schema can be
used to describe the structure of the data in an RDF database.

In order to describe classes of resources and properties, the RDF Schema
vocabulary defines the following terms: rdfs:Class and rdf:Property represent
the classes of resources, and properties respectively; rdf:type can be used
(as property) to state that a resource is an instance of a class; rdfs:domain
and rdfs:range allow to define the domain and range of a property,
respectively. Note that rdf: and rdfs: are the prefixes for RDF and RDFS
respectively.

An RDF Schema is described using RDF triples, so it can be encoded using RDF
data formats. The following example shows an RDF Schema which describes the
structure of the data shown in Example 2.1, using the Turtle data format.

###### Example 2.2

⬇

1@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

2@prefix xsd: <http://www.w3.org/2001/XMLSchema#>

3@prefix voc: <http://www.example.org/voc/> .

4voc:Organisation rdf:type rdfs:Class .

5voc:name rdf:type rdf:Property ;

6 rdfs:domain voc:Organisation ;

7 rdfs:range xsd:string .

8voc:creation rdf:type rdf:Property ;

9 rdfs:domain voc:Organisation ;

10 rdfs:range xsd:date .

11voc:Person rdf:type rdfs:Class .

12voc:birthName rdf:type rdf:Property ;

13 rdfs:domain voc:Person ;

14 rdfs:range xsd:string .

15voc:age rdf:type rdf:Property ;

16 rdfs:domain voc:Person ;

17 rdfs:range xsd:int .

18voc:ceo rdf:type rdf:Property ;

19 rdfs:domain voc:Organisation ;

20 rdfs:range voc:Person .

Note that a resource class $c$ is defined by a triple of the form ($c$
rdf:type rdfs:Class). A property class $pc$ is defined (ideally) by three
triples of the form ($pc$ rdf:type rdf:Property), ($pc$ rdfs:domain $rc_{1}$)
and ($pc$ rdfs:range $rc_{2}$), where $rc_{1}$ indicates the resource class
having property $p$ (i.e. the domain), and $rc_{2}$ indicates the resource
class determining the value of the property $pc$ (i.e. the range).

If the range of a property class $pc$ is a resource class (defined by the
user), then $pc$ is called an object property (e.g. voc:birthName). If the
range is a datatype class (defined by RDF Schema or another vocabulary), then
$pc$ is called a datatype property. The IRIs xsd:string, xsd:integer and
xsd:dateTime are examples of datatypes defined by XML Schema [6]. Let
$I_{DT}\subset\textbf{I}$ be the set of RDF datatypes.

Note that the RDF schema presented in Example 2.2 provides a complete
description of resource classes and property classes. However, in practice, it
is possible to find incomplete or partial RDF schema descriptions. In
particular, a property could not define its domain or its range.

We will assume that a partial schema can be transformed into a total schema.
In this sense, we will use the term rdfs:Resource333According to the RDF
Schema specification [9], rdfs:Resource denotes the class of everything. to
complete the definition of properties without domain or range. For instance,
suppose that our sample RDF Schema does not define the range of the property
class voc:ceo. In this case, we include the triple (voc:ceo, rdfs:range,
rdfs:Resource) to complete the definition of voc:ceo.

Now, we introduce the notion of RDF Graph Schema as a formal way to represent
an RDF schema description. Assume that $I_{V}\subset\textbf{I}$ is a set that
includes the RDF Schema terms rdf:type, rdfs:Class, rdfs:Property, rdfs:domain
and rdfs:range.

######  Definition 6 (RDF Graph Schema)

An RDF graph schema is defined as a tuple $S^{R}=(N_{S},E_{S},\phi,\varphi)$
where:

  * •

$N_{S}$ is a finite set of nodes representing resource classes;

  * •

$E_{S}$ is a finite set of edges representing property classes;

  * •

$\phi:(N_{S}\cup E_{S})\to I\setminus I_{V}$ is a total function that
associates each node or edge with an IRI representing a class identifier;

  * •

$\varphi$: $E_{S}\rightarrow(N_{S}\times N_{S})$ is a total function that
associates each property class with a pair of resource classes.

Recall that $I_{DT}$ denotes the set of RDF datatypes. Given an RDF Schema
description $D$, the procedure to create and RDF Graph schema
$S^{R}=(N_{S},E_{S},\phi,\varphi)$ from $D$ is given as follows:

  1. 1.

Let $C=\\{rc\mid(rc,\texttt{\small rdf:type},\texttt{\small rdfs:Class})\in
D\lor(pc,\texttt{\small rdfs:domain},rc)\in D\lor(pc,\texttt{\small
rdfs:range},rc)\in D\\}$

  2. 2.

For each $rc\in C$, we create $n\in N_{S}$ with $\phi(n)=rc$

  3. 3.

For each pair of triples $(pc,\texttt{\small rdfs:domain},rc_{1})$ and
$(pc,\texttt{\small rdfs:range},rc_{2})$ in $D$, we create $e\in E_{S}$ with
$\phi(e)=pc$ and $\varphi(e)=(n_{1},n_{2})$, satisfying that $n_{1},n_{2}\in
N_{S}$, $\phi(n_{1})=rc_{1}$ and $\phi(n_{2})=rc_{2}$.

Following the above procedure, the RDF schema shown in Example 2.2 can be
formally described as follows:

⬇

1$N_{S}=\\{n_{1},n_{2},n_{3},n_{4},n_{5}\\}$,

2$E_{S}=\\{e_{1},e_{2},e_{3},e_{4},e_{5}\\}$;

3$\phi(n_{1})=\\{\text{voc:Organisation}\\}$,
$\phi(n_{2})=\\{\text{voc:Person}\\}$, $\phi(n_{3})=\\{\text{xsd:date}\\}$,
$\phi(n_{4})=\\{\text{xsd:string}\\}$, $\phi(n_{5})=\\{\text{xsd:int}\\}$

4$\phi(e_{1})=\\{\text{voc:ceo}\\}$, $\phi(e_{2})=\\{\text{voc:creation}\\}$,
$\phi(e_{3})=\\{\text{voc:name}\\}$, $\phi(e_{4})=\\{\text{voc:birthName}\\}$,
$\phi(e_{5})=\\{\text{voc:age}\\}$,

5$\varphi(e_{1})=(n_{1},n_{2})$, $\varphi(e_{2})=(n_{1},n_{3})$,
$\varphi(e_{3})=(n_{1},n_{4})$, $\varphi(e_{4})=(n_{2},n_{4})$,
$\varphi(e_{5})=(n_{2},n_{5})$.

Additionally, Figure 2 shows a graphical representation of the RDF schema
graph described above.

Figure 2: Graphical illustration of an RDF graph schema.

Given an RDF graph schema $S^{R}=(N_{S},E_{S},\phi,\phi,\varphi)$ and an RDF
graph
$G^{R}=(N_{I},N_{L},E_{O},E_{D},\alpha_{I},\alpha_{L},\beta_{O},\beta_{D},\delta)$,
we say that $G^{R}$ is valid with respect to $S^{R}$, denoted as $G^{R}\models
S^{R}$, iff:

  1. 1.

for each $r\in N_{I}\cup N_{L}$, it applies that there is $rc\in N_{S}$ where
$\delta(r)=\phi(rc)$;

  2. 2.

for each $e\in E_{O}$ with $\beta_{O}(e)=(n,n^{\prime})$, it applies that
there is $pc\in E_{S}$ where $\delta(e)=\phi(pc)$,
$\varphi(pc)=(rc,rc^{\prime})$, $\delta(n)=\phi(rc)$ and
$\delta(n^{\prime})=\phi(rc^{\prime})$.

  3. 3.

for each $e\in E_{D}$ with $\beta_{D}(e)=(n,n^{\prime})$, it applies that
there is $pc\in E_{S}$ where $\delta(e)=\phi(pc)$,
$\varphi(pc)=(rc,rc^{\prime})$, $\delta(n)=\phi(rc)$ and
$\delta(n^{\prime})=\phi(rc^{\prime})$.

Here, condition (1) validates that every resource node is labeled with a
resource class defined by the schema; condition (2) verifies that each object
property edge, and the pairs of resource nodes that it connects, are labeled
with the corresponding resource classes; and condition (3) verifies that each
datatype property edge, and the pairs of nodes that it connects (i.e. a
resource node and a literal node), are labeled with the corresponding resource
classes

Finally, we present the notion of RDF database.

######  Definition 7 (RDF Database)

An RDF database is a pair $(S^{R},G^{R})$ where $S^{R}$ is an RDF graph schema
and $G^{R}$ is an RDF graph satisfying that $G^{R}\models S^{R}$.

###  2.3 Property Graph Databases

A Property Graph (PG) is a labeled directed multigraph whose main
characteristic is that nodes and edges can contain a set (possibly empty) of
name-value pairs referred to as properties. From the point of view of data
modeling, each node represents an entity, each edge represents a relationship
(between two entities), and each property represents a specific characteristic
(of an entity or a relationship).

Figure 3: Graphical illustration of a Property Graph.

Figure 3 presents a graphical representation of a Property Graph. The circles
represent nodes, the arrows represent edges, and the boxes contain the
properties for nodes and edges.

Currently, there are no standard definitions for the notions of Property Graph
and Property Graph Schema. However, we present formal definitions that
resemble most of the features supported by current PG database systems.

####  2.3.1 Property Graph.

Assume that $\mathbb{L}$ is an infinite set of labels (for nodes, edges and
properties), $\mathbb{V}$ is an infinite set of (atomic or complex) values,
and $\mathbb{T}$ is a finite set of data types (e.g. _string_ , _integer_ ,
_date_ , etc.). A value in $\mathbb{V}$ will be distinguished as a quoted
string. Given a value $v\in\mathbb{V}$, the function $\operatorname{type}(v)$
returns the datatype of $v$. Given a set $S$, $\mathcal{P}^{+}(S)$ denotes the
set of non-empty subsets of $S$.

######  Definition 8 (Property Graph)

A Property Graph is defined as a tuple
$G^{P}=(\mathbb{N},\mathbb{E},\mathbb{P},\Gamma,\Upsilon,\Sigma,\Delta)$
where:

  * •

$\mathbb{N}$ is a finite set of nodes, $\mathbb{E}$ is a finite set of edges,
$\mathbb{P}$ is a finite set of properties, and
$\mathbb{N},\mathbb{E},\mathbb{P}$ are mutually disjoint sets;

  * •

$\Gamma:(\mathbb{N}\cup\mathbb{E})\to\mathbb{L}$ is a total function that
associates each node or edge with a label;

  * •

$\Upsilon:\mathbb{P}\to(\mathbb{L}\times\mathbb{V})$ is a total function that
assigns a label-value pair to each property.

  * •

$\Sigma:\mathbb{E}\to(\mathbb{N}\times\mathbb{N})$ is a total function that
associates each edge with a pair of nodes;

  * •

$\Delta:(\mathbb{N}\cup\mathbb{E})\to\mathcal{P}^{+}(\mathbb{P})$ is a partial
function that associates a node or edge with a non-empty set of properties,
satisfying that $\Delta(o_{1})\cap\Delta(o_{2})=\emptyset$ for each pair of
objects $o_{1},o_{2}\in\operatorname{dom}(\Delta)$;

The above definition supports Property Graphs with the following features: a
pair of nodes can have zero or more edges; each node or edge has a single
label; each node or edge can have zero or more properties; and a node or edge
can have the same label-value pair one or more times.

On the other side, the above definition does not support multiple labels for
nodes or edges. We have two reasons to justify this restriction. First, this
feature is not supported by all graph database systems. Second, it makes
complex the definition of schema-instance consistency.

Given two nodes $n_{1},n_{2}\in N$ and an edge $e\in E$, satisfying that
$\Sigma(e)=(n_{1},n_{2})$, we will use $e=(n_{1},n_{2})$ as a shorthand
representation for $e$, where $n_{1}$ and $n_{2}$ are called the “source node”
and the “target node” of $e$ respectively.

Hence, the formal description of the Property Graph presented in Figure 3 is
given as follows:

⬇

1$\mathbb{N}=\\{n_{1},n_{2}\\}$,

2$\mathbb{E}=\\{e_{1}\\}$,

3$\mathbb{P}=\\{p_{1},p_{2},p_{3},p_{4},p_{5}\\}$,

4$\Gamma(n_{1})=\\{\text{Organisation}\\}$,
$\Gamma(n_{2})=\\{\text{Person}\\}$,

5$\Gamma(e_{1})=\\{\text{ceo}\\}$,

6$\Upsilon(p_{1})=(\text{name},\text{"Tesla, Inc."})$,
$\Upsilon(p_{2})=(\text{creation},\text{2003-07-01})$,
$\Upsilon(p_{3})=(\text{birthName},\text{"Elon Musk"})$,
$\Upsilon(p_{4})=(\text{age},\text{46})$,
$\Upsilon(p_{5})=(\text{since},\text{2003})$

7$\Sigma(e_{1})=\\{n_{1},n_{2}\\}$,

8$\Delta(n_{1})=\\{p_{1},p_{2}\\}$, $\Delta(n_{2})=\\{p_{3},p_{4}\\}$,
$\Delta(e_{1})=\\{p_{5}\\}$.

####  2.3.2 Property Graph Schema.

A Property Graph Schema defines the structure of a PG database. Specifically,
it defines types of nodes, types of edges, and the properties for such types.

Figure 4: Graphical illustration of a Property Graph Schema.

For instance, Figure 4 shows a graphical representation of a PG schema. The
formal definition of PG schema is presented next.

######  Definition 9 (Property Graph Schema)

A Property Graph Schema is defined as a tuple
$S^{P}=(\mathbb{N}_{S},\mathbb{E}_{S},\mathbb{P}_{S},\Theta,\Pi,\Phi,\Psi)$
where:

  * •

$\mathbb{N}_{S}$ is a finite set of node types;

  * •

$\mathbb{E}_{S}$ is a finite set of edge types;

  * •

$\mathbb{P}_{S}$ is a finite set of property types;

  * •

$\Theta:(\mathbb{N}_{S}\cup\mathbb{E}_{S})\to\mathbb{L}$ is a total function
that assigns a label to each node or edge;

  * •

$\Pi:\mathbb{P}_{S}\to(\mathbb{L}\times\mathbb{T})$ is a total function that
associates each property type with a property label and a data type;

  * •

$\Phi:\mathbb{E}_{S}\to(\mathbb{N}_{S}\times\mathbb{N}_{S})$ is a total
function that associates each edge type with a pair of node types;

  * •

$\Psi:(\mathbb{N}_{S}\cup\mathbb{E}_{S})\to\mathcal{P}^{+}(\mathbb{P}_{S})$ is
a partial function that associates a node or edge type with a non-empty set of
property types, satisfying that $\Psi(o_{1})\cap\Psi(o_{2})=\emptyset$, for
each pair of objects $o_{1},o_{2}\in\operatorname{dom}(\Psi)$.

Hence, the formal description of the Property Graph Schema shown in Figure 4
is the following:

⬇

1$\mathbb{N}_{S}=\\{n_{1},n_{2}\\}$,

2$\mathbb{E}_{S}=\\{e_{1}\\}$,

3$\mathbb{P}_{S}=\\{p_{1},p_{2},p_{3},p_{4},p_{5}\\}$,

4$\Theta(n_{1})=\\{\text{Organisation}\\}$,
$\Theta(n_{2})=\\{\text{Person}\\}$, $\Theta(e_{1})=\\{\text{ceo}\\}$,

5$\Pi(p_{1})=(\text{name},\text{String})$,
$\Pi(p_{2})=(\text{creation},\text{Date})$,
$\Pi(p_{3})=(\text{birthName},\text{String})$,
$\Pi(p_{4})=(\text{age},\text{Integer})$,
$\Pi(p_{5})=(\text{since},\text{Date})$,

6$\Phi(e_{1})=(n_{1},n_{2})$,

7$\Psi(n_{1})=\\{p_{1},p_{2}\\}$, $\Psi(n_{2})=\\{p_{3},p_{4}\\}$,
$\Psi(e_{1})=\\{p_{5}\\}$

Given a PG schema
$S^{P}=(\mathbb{N}_{S},\mathbb{E}_{S},\mathbb{P}_{S},\Theta,\Pi,\Phi,\Psi)$
and a PG
$G^{P}=(\mathbb{N},\mathbb{E},\mathbb{P},\Gamma,\Upsilon,\Sigma,\Delta)$, we
say that $G^{P}$ is valid with respect to $S^{P}$, denoted as $G^{P}\models
S^{P}$, iff:

  1. 1.

for each $n\in\mathbb{N}$, it applies that there is $nt\in\mathbb{N}_{S}$
satisfying that:

     * (a)

$\Gamma(n)=\Theta(nt)$;

     * (b)

for each $p\in\Delta(n)$, there is $pt\in\Psi(nt)$ satisfying that
$\Upsilon(p)=(l,v)$ and $\Pi(t_{p})=(l,\operatorname{type}(v))$.

  2. 2.

for each $e=(n,n^{\prime})\in\mathbb{E}$, it applies that there is
$et\in\mathbb{E}_{S}$ with $\Phi(et)=(nt,nt^{\prime})$ satisfying that:

     * (a)

$\Gamma(e)=\Theta(et)$, $\Gamma(n)=\Theta(nt)$,
$\Gamma(n^{\prime})=\Theta(nt^{\prime})$;

     * (b)

for each $p^{\prime}\in\Delta(e)$, there is $pt^{\prime}\in\Psi(et)$
satisfying that $\Upsilon(p^{\prime})=(l^{\prime},v^{\prime})$ and
$\Pi(pt^{\prime})=(l^{\prime},\operatorname{type}(v^{\prime}))$.

Here, condition (1a) validates that every node is labeled with a node type
defined by the schema; condition (1b) verifies that each node contains the
properties defined by its node type; condition (2a) verifies that each edge,
and the pairs of nodes that it connects, are labeled with an edge type, and
the corresponding node types; and condition (2b) verifies that each edge
contains the properties defined by the schema.

Finally, we present the notion of the Property Graph database.

######  Definition 10 (Property Graph Database)

A Property Graph database $D^{P}$ is a pair $(S^{P},G^{P})$ where $S^{P}$ is a
PG schema and $G^{P}$ is a PG satisfying that $G^{P}\models S^{P}$.

###  2.4 RDF databases versus PG databases

Upon comparison of RDF graphs and PGs, we see that both share the main
characteristics of a traditional labeled directed graph, that is, nodes and
edges contain labels, the edges are directed, and multiple edges are possible
between a given pair of nodes. However, there are also some differences
between them:

  * •

An RDF graph contains nodes of type resource (whose label is an IRI) and nodes
of type Literal (whose label is a value), whereas a PG allows a single type of
node;

  * •

Each node or edge in an RDF graph contains just a single value (i.e. a label),
whereas each node or edge in a PG could contain multiple labels and properties
respectively;

  * •

An RDF graph supports multi-value properties, whereas a PG usually just
support mono-value properties;

  * •

An RDF graph allows to have edges between edges, a feature which isn’t
supported in a PG (by definition);

  * •

A node in an RDF graph could be associated with zero or more classes or
resources, while a node in a PG usually has a single node type.

We consider factors such as the availability of schema information in the
source model while developing database mappings. Depending on whether or not
the input RDF data has schema, the database mappings can be classified into
two types: (i) schema-dependent: one that generates a target PG schema from
the input RDF graph schema, and then transforms the RDF graph into a PG (see
Section 3); and (ii) schema-independent: one that creates a generic PG schema
(based on predefined structure) and then transforms the RDF graph into a PG
(see Section 4). In this paper, we developed these two types of database
mappings.

Our research omits two special features of RDF: Blank Nodes and reification
(i.e. the description of RDF statements using a specific vocabulary). After an
empirical study of different RDF datasets e.g. Bio2RDF [5], Europeana [18],
LOD Cache [32], Wikidata [42], Billion Triple Challenge (BTC) [19] we noticed
that these features are rarely used in RDF. Table 1 resume our analysis of the
use of Blank Nodes and reification in the above datasets.

Table 1: Blank Nodes and reification in different datasets. Snapshot:
2019-10-08

Datasets | Blank Nodes | Reification
---|---|---
Europeana | 0% | 0%
Bio2RDF | 0% | 0%
LOD Cache | 2.67% | 1.3%
Wikidata | 0.01% | 0%
BTC | 12.08% | 0.02%

##  3 Schema-dependent Database Mapping

In this section we present a database mapping from RDF databases to PG
databases. Specifically, the database mapping $\mathcal{DM}_{1}$ is composed
by the schema mapping $\mathcal{SM}_{1}$ and the instance mapping
$\mathcal{IM}_{1}$.

Recall that $I_{DT}$ is the set of RDF datatypes and $\mathbb{T}$ is the set
of PG datatypes. Assume that there is a total function $f:I_{DT}\to\mathbb{T}$
which maps RDF datatypes into PG datatypes. Additionally, assume that $f^{-1}$
is the inverse function of $f$, i.e. $f^{-1}$ maps PG datatypes into RDF
datatypes.

###  3.1 Schema mapping $\mathcal{SM}_{1}$

We define a schema mapping $\mathcal{SM}_{1}$ which takes an RDF graph schema
as input and returns a PG Schema as output.

######  Definition 11 (Schema Mapping $\mathcal{SM}_{1}$)

Let $S^{R}=(N_{S},E_{S},\phi,\varphi)$ be an RDF schema and
$S^{P}=(\mathbb{N}_{S},\mathbb{E}_{S},\mathbb{P}_{S},\Theta,\Pi,\Phi,\Psi)$ be
a Property Graph Schema. The schema mapping $\mathcal{SM}_{1}(S^{R})=S^{P}$ is
defined as follows:

  1. 1.

For each $rc\in N_{S}$ satisfying that $\phi(rc)\notin I_{C}$

     * •

There will be $nt\in\mathbb{N}_{S}$ with $\Theta(nt)=\phi(rc)$

  2. 2.

For each $pc\in E_{S}$ satisfying that $\varphi(pc)=(rc_{1},rc_{2})$

     * •

If $\phi(rc_{2})\in I_{DT}$ then

       * –

There will be $pt\in\mathbb{P}_{S}$ with $\Pi(pt)=(\phi(pc),f(\phi(rc_{2})))$,
$\Psi(nt)=\Psi(nt)\cup pt$ where $nt\in\mathbb{N}_{S}$ corresponds to
$rc_{1}\in N_{S}$.

     * •

If $\phi(rc_{2})\notin I_{DT}$ then

       * –

There will be $et\in\mathbb{E}_{S}$ with $\Theta(et)=\phi(pc)$,
$\Phi(et)=(nt_{1},nt_{2})$ where $nt_{1},nt_{2}\in\mathbb{N}_{S}$ correspond
to $rc_{1},rc_{2}\in N_{S}$ respectively.

Hence, the schema mapping $\mathcal{SM}_{1}$ creates a node type for each
resource type (with exception of RDF data types); creates a property type for
each object property; and creates an edge type for each value property.

For instance, the Property Graph Schema obtained from the graph schema shown
in Figure 2 is given as follows:

⬇

1$\mathbb{N}_{S}=\\{n_{1},n_{2}\\}$,

2$\mathbb{E}_{S}=\\{e_{1}\\}$,

3$\mathbb{P}_{S}=\\{p_{1},p_{2},p_{3},p_{4}\\}$,

4$\Theta(n_{1})=\\{\text{voc:Organisation}\\}$,
$\Theta(n_{2})=\\{\text{voc:Person}\\}$, $\Theta(e_{1})=\\{\text{voc:ceo}\\}$,

5$\Pi(p_{1})=(\text{voc:creation},\text{Date})$,
$\Pi(p_{2})=(\text{voc:name},\text{String})$,
$\Pi(p_{3})=(\text{voc:birthName},\text{String})$,
$\Pi(p_{4})=(\text{voc:age},\text{Integer})$,

6$\Phi(e_{1})=(n_{1},n_{2})$,

7$\Psi(n_{1})=\\{p_{1},p_{2}\\}$, $\Psi(n_{2})=\\{p_{3},p_{4}\\}$.

###  3.2 Instance Mapping $\mathcal{IM}_{1}$

Now, we define the instance mapping $\mathcal{IM}_{1}$ which takes an RDF
graph as input and returns a Property Graph as output.

######  Definition 12 (Instance Mapping $\mathcal{IM}_{1}$)

Let –
$G^{R}=(N_{I},N_{L},E_{O},E_{D},\alpha_{I},\alpha_{L},\beta_{O},\beta_{D},\delta)$
be an RDF graph and
$G^{P}=(\mathbb{N},\mathbb{E},\mathbb{P},\Gamma,\Upsilon,\Sigma,\Delta)$ be a
Property Graph. The instance mapping $\mathcal{IM}_{1}(G^{R})=G^{P}$ is
defined as follows:

  1. 1.

For each $r\in N_{I}$

     * •

There will be $n\in\mathbb{N}$ with $\Gamma(n)=\delta(r)$.

     * •

There will be $p\in\mathbb{P}$ with $\Upsilon(p)=(\text{iri},\alpha_{I}(r))$

     * •

$\Delta(n)=\\{p\\}$.

  2. 2.

For each $dp\in E_{D}$ satisfying that $\beta_{D}(dp)=(r_{1},r_{2})$

     * •

There will be $p\in\mathbb{P}$ with
$\Upsilon(p)=(\delta(dp),\alpha_{L}(r_{2}))$, $\Delta(n)=\Delta(n)\cup\\{p\\}$
where $n\in\mathbb{N}$ corresponds to $r_{1}\in N_{I}$.

  3. 3.

For each $op\in E_{O}$ satisfying that $\beta_{O}(op)=(r_{1},r_{2})$

     * •

There will be $e\in\mathbb{E}$ with $\Gamma(e)=\delta(op)$,
$\Sigma(e)=(n_{1},n_{2})$ where $n1,n2\in\mathbb{N}$ correspond to $r1,r2\in
N_{I}$ respectively.

According to the above definition, the instance mapping $\mathcal{IM}_{1}$
creates a node in $G_{R}$ for each resource node, creates a property in
$G_{R}$ for each datatype property, and creates an edge in $G_{R}$ for each
object property.

For example, the PG obtained from the RDF graph is shown in Figure 1 is given
as follows:

⬇

1$\mathbb{N}=\\{n_{1},n_{2}\\}$,

2$\mathbb{E}=\\{e_{1}\\}$,

3$\mathbb{P}=\\{p_{1},p_{2},p_{3},p_{4},p_{5},p_{6}\\}$,

4$\Gamma(n_{1})=\\{\text{voc:Organisation}\\}$,
$\Gamma(n_{2})=\\{\text{voc:Person}\\}$,

5$\Gamma(e_{1})=\\{\text{voc:ceo}\\}$,

6$\Upsilon(p_{1})=(\text{iri},\text{"ex:Test\\_Inc"})$,
$\Upsilon(p_{2})=(\text{voc:name},\text{"Tesla, Inc."})$,
$\Upsilon(p_{3})=(\text{voc:creation},\text{2003-07-01})$,
$\Upsilon(p_{4})=(\text{iri},\text{"ex:Elon\\_Musk"})$
$\Upsilon(p_{5})=(\text{voc:birthName},\text{"Elon Musk"})$,
$\Upsilon(p_{6})=(\text{voc:age},\text{46})$,

7$\Sigma(e_{1})=\\{n_{1},n_{2}\\}$,

8$\Delta(n_{1})=\\{p_{1},p_{2},p_{3}\\}$,
$\Delta(n_{2})=\\{p_{4},p_{5},p_{6}\\}$.

###  3.3 Properties of $\mathcal{DM}_{1}$

In this section, the database mapping
$\mathcal{DM}_{1}=(\mathcal{SM}_{1},\mathcal{IM}_{1})$ will be evaluated with
respect to the properties described in Section 2.1.1. Specifically, we will
analyze computability, semantics preservation, and information preservation.

Recall that $\mathcal{DM}_{1}$ is a formed by the schema mapping
$\mathcal{SM}_{1}$ and the instance mapping $\mathcal{IM}_{1}$.

###### Proposition 1

The database mapping $\mathcal{DM}_{1}$ is computable.

It is straightforward to see that Definition 11 and Definition 12 can be
transformed into algorithms to compute $\mathcal{SM}_{1}$ and
$\mathcal{IM}_{1}$ respectively.

###### Lemma 1

The database mapping $\mathcal{DM}_{1}$ is _semantics preserving_.

Note that the schema mapping $\mathcal{SM}_{1}$ and the instance mapping
$\mathcal{IM}_{1}$ have been designed to create a Property Graph database that
maintains the restrictions defined by the source RDF database. On one side,
the schema mapping $\mathcal{SM}_{1}$ allows transforming the structural and
semantic restrictions from the RDF graph schema to the PG schema. On the other
side, any Property Graph generated by the instance mapping will be valid with
respect to the generated PG schema.

The semantics preservation property of $\mathcal{DM}_{1}$ is supported by the
following facts:

  * •

We provide a procedure to create a complete RDF graph schema $S^{R}$ from a
set of RDF triples describing an RDF schema, i.e. each property defines its
domain and range resource classes.

  * •

We provide a procedure to create an RDF graph $G^{R}$ from a set of RDF
triples, satisfying that each every node and edge in $G^{R}$ is associated
with a resource class; it allows a complete connection between the RDF
instance and the RDF schema.

  * •

The schema mapping $\mathcal{SM}_{1}$ creates a node type for each user-
defined resource type, a property type for each datatype property edge, and an
edge for each object property type.

  * •

Similarly, the instance mapping $\mathcal{IM}_{1}$ creates a node for each
resource, a property for each resource-literal edge, and an edge for each
resource-resource edge.

###### Theorem 1

The database mapping $\mathcal{DM}_{1}$ is _information preserving_.

In order to prove that $\mathcal{DM}_{1}$ is information preserving, we need
to define a database mapping
$\mathcal{DM}^{-1}_{1}=(\mathcal{SM}^{-1}_{1},\mathcal{IM}^{-1}_{1})$ which
allows to transform a PG database into an RDF database, and satisfying that
$D=\mathcal{DM}^{-1}_{1}(\mathcal{DM}_{1}(D))$ for any RDF database $D$. Next
we define the schema mapping $\mathcal{SM}^{-1}_{1}$ and the instance mapping
$\mathcal{IM}^{-1}_{1}$.

######  Definition 13 (Schema mapping $\mathcal{SM}^{-1}_{1}$)

Let
$S^{P}=(\mathbb{N}_{S},\mathbb{E}_{S},\mathbb{P}_{S},\Theta,\Pi,\Phi,\Psi)$ be
a Property Graph Schema and $S^{R}=(N_{S},E_{S},\phi,\varphi)$ be an RDF
schema. The schema mapping $\mathcal{SM}^{-1}_{1}(S^{R})=S^{P}$ is defined as
follows:

  1. 1.

Let $T=\\{dt\mid(pl,dt)\in\operatorname{range}(\Pi)\\}$

  2. 2.

For each $dt\in T$, we create $rc\in N_{S}$ with $\phi(rc)=f^{-1}(dt)$

  3. 3.

For each $et\in\mathbb{E}$ with $\Phi(et)=(nt_{1},nt_{2})$, we create $pc\in
E_{S}$ with $\phi(pc)=\Theta(et)$ and $\varphi(pc)=(rc_{1},rc_{2})$ satisfying
that $rc_{1},rc_{2}\in N_{S}$, $\phi(rc_{1})=\Theta(nt_{1})$ and
$\phi(rc_{2})=\Theta(nt_{2})$

  4. 4.

For each $nt\in\mathbb{N}_{S}$, we create $rc\in N_{S}$ with
$\phi(rc)=\Theta(nt)$

    1. (a)

For each $pt\in\Psi(nt)$ such $\Pi(pt)=(pl,dt)$, we create $pc\in E_{S}$ with
$\phi(pc)=pl$ and $\varphi(pc)=(rc_{1},rc_{2})$ satisfying that
$rc_{1},rc_{2}\in N_{S}$, $\phi(rc_{1})=\Theta(nt)$ and
$\phi(rc_{2})=f^{-1}(dt)$

      1. i.

There will be $pc\in E_{S}$ with

In general terms, the schema mapping $\mathcal{SM}^{-1}_{1}$ creates a
resource class for each node type, an object property for each edge type, and
a datatype property for each property type. Given a PG schema
$S^{P}=\mathcal{SM}_{1}(S^{R})$, the schema mapping $\mathcal{SM}^{-1}_{1}$
allows to “recover” all the schema constraints defined by $S^{R}$, i.e
$\mathcal{SM}^{-1}_{1}(S^{P})=S^{R}$.

An issue of $\mathcal{SM}^{-1}_{1}$, is the existence of RDF datatypes which
are not supported by PG databases. For example, rdfs:Literal has no equivalent
datatype in PG database systems. The solution to this issue is to find a one-
to-one correspondence between RDF datatypes and PG datatypes.

######  Definition 14 (Instance mapping $\mathcal{IM}^{-1}_{1}$)

Let $G^{P}=(\mathbb{N},\mathbb{E},\mathbb{P},\Gamma,\Upsilon,\Sigma,\Delta)$
be a Property Graph and
$G^{R}=(N_{I},N_{L},E_{O},E_{D},\alpha_{I},\alpha_{L},\beta_{O},\beta_{D},\delta)$
be an RDF graph. The instance mapping $\mathcal{IM}^{-1}_{1}(G^{P})=G^{R}$ is
defined as follows:

  1. 1.

For each $n\in\mathbb{N}$, there will be $r\in N_{I}$ where

    1. (a)

$\alpha_{I}(r)=v$ such that $p\in\Delta(n)$ and $\Upsilon(p)=(\texttt{\small
iri},v)$

    2. (b)

$\delta(r)=\Gamma(n)$

    3. (c)

For each $p\in\Delta(n)\setminus\\{\texttt{\small iri}\\}$ where
$\Upsilon(p)=(lab,val)$, there will be $l\in N_{L}$ and $dp\in E_{D}$ with
$\alpha_{L}(l)=val$, $\delta(l)=f^{-1}(\operatorname{type}(val))$,
$\delta(dp)=lab$ and $\beta(dp)=(r,l)$

  2. 2.

For each $e\in\mathbb{E}$ where $\Sigma(e)=(n_{1},n_{2})$, there will be
$op\in E_{O}$ with $\delta(op)=\Gamma(e)$ and $\beta(op)=(r_{1},r_{2})$ such
that $r_{1},r_{2}$ correspond to $n_{1},n_{2}$ respectively.

Hence, the method defined above defines that each node in $G^{P}$ is
transformed into a resource node in $G^{R}$, each property in $G^{P}$ is
transformed into a datatype property in $G^{R}$, and each edge in $G^{P}$ is
transformed into an object property in $G^{R}$. Given a Property Graph
$G^{P}=\mathcal{IM}_{1}(G^{R})$, the instance mapping $\mathcal{IM}^{-1}_{1}$
allows to “recover” all the data in $G^{R}$, i.e
$\mathcal{IM}^{-1}_{1}(G^{P})=G^{R}$.

Note that each RDF graph produced by the instance mapping
$\mathcal{IM}^{-1}_{1}$ will be valid with respect to the schema produced with
the corresponding schema mapping $\mathcal{SM}^{-1}_{1}$. Hence, any RDF
database $D^{R}$ can be transformed into a PG database by using the database
mapping $\mathcal{DM}(D^{R})$, and $D^{R}$ could be recovered by using the
database mapping $\mathcal{DM}^{-1}_{1}$.

##  4 Schema-independent Database Mapping

In this section we present a database mapping, from RDF databases to PG
databases, which does not consider the database schema. In this sense, we
provide a method to transform any RDF graph into a Property Graph database.

Given an RDF database $D^{R}=(S^{R},G^{R})$, we will define the database
mapping $\mathcal{DM}_{2}=(\mathcal{SM}_{2},\mathcal{IM}_{2})$ which allows to
construct a PG database $D^{P}=(S^{*},\mathcal{IM}_{2}(G^{R}))$ where
$\mathcal{SM}_{2}$ is a schema mapping that, for any RDF graph $G^{R}$,
$\mathcal{SM}_{2}$ creates a generic Property Graph Schema $S^{*}$.

###  4.1 Generic Property Graph Schema

First we introduce a Property Graph Schema which is able to model any RDF
graph.

######  Definition 15 (Generic Property Graph Schema)

Let –
$S^{*}=(\mathbb{N}_{S},\mathbb{E}_{S},\mathbb{P}_{S},\Theta,\Pi,\Phi,\Psi)$ be
the Property Graph Schema defined as follows:

⬇

1$\mathbb{N}_{S}=\\{n_{1},n_{2}\\}$,

2$\mathbb{E}_{S}=\\{e_{1},e_{2}\\}$,

3$\mathbb{P}_{S}=\\{p_{1},p_{2},p_{3},p_{4},p_{5},p_{6}\\}$,

4$\Theta(n_{1})=\\{\text{Resource}\\}$, $\Theta(n_{2})=\\{\text{Literal}\\}$,
$\Theta(e_{1})=\\{\text{ObjectProperty}\\}$,
$\Theta(e_{1})=\\{\text{DatatypeProperty}\\}$

5$\Pi(p_{1})=(\text{iri},\text{String})$,
$\Pi(p_{2})=(\text{type},\text{String})$,
$\Pi(p_{3})=(\text{value},\text{String})$,
$\Pi(p_{4})=(\text{type},\text{String})$,
$\Pi(p_{5})=(\text{type},\text{String})$,
$\Pi(p_{6})=(\text{type},\text{String})$

6$\Phi(e_{1})=(n_{1},n_{1})$, $\Phi(e_{1})=(n_{1},n_{2})$

7$\Psi(n_{1})=\\{p_{1},p_{2}\\}$, $\Psi(n_{2})=\\{p_{3},p_{4}\\}$,
$\Psi(e_{1})=\\{p_{5}\\}$, $\Psi(e_{2})=\\{p_{6}\\}$

In the above definition: the node type Resource will be used to represent RDF
resources, the node type Literal will be used to represent RDF literals, the
edge type ObjectProperty allows to represent object properties (i.e.
relationships between RDF resources), and the edge type DatatypeProperty
allows representing datatype properties (i.e. relationships between an RDF
resource an a literal). Figure 5 shows a graphical representation of the
generic Property Graph Schema.

Figure 5: A generic Property Graph Schema.

###  4.2 Instance Mapping $\mathcal{IM}_{2}$

Now, we define the instance mapping $\mathcal{IM}_{2}$ which takes an RDF
graph and produces a Property Graph following the restrictions established by
the generic Property Graph Schema defined above.

######  Definition 16 (Instance mapping $\mathcal{IM}_{2}$)

Let –
$G^{R}=(N_{I},N_{L},E_{O},E_{D},\alpha_{I},\alpha_{L},\beta_{O},\beta_{D},\delta)$
be an RDF graph and
$G^{P}=(\mathbb{N},\mathbb{E},\mathbb{P},\Gamma,\Upsilon,\Sigma,\Delta)$ be a
Property Graph. The instance mapping $\mathcal{IM}_{2}(G^{R})=G^{P}$ is
defined as follows:

  1. 1.

For each $r\in N_{I}$

     * •

There will be $n\in\mathbb{N}$ with $\Gamma(n)=\texttt{\small Resource}$

     * •

There will be $p\in\mathbb{P}$ with $\Upsilon(p)=(\texttt{\small
iri},\alpha_{I}(r))$

     * •

There will be $p^{\prime}\in\mathbb{P}$ with
$\Upsilon(p^{\prime})=(\texttt{\small type},\delta(r))$

     * •

$\Delta(n)=\Delta(n)\cup p\cup p^{\prime}$

  2. 2.

For each $l\in N_{L}$

     * •

There will be $n\in\mathbb{N}$ with $\Gamma(n)=\texttt{\small Literal}$

     * •

There will be $p\in\mathbb{P}$ with $\Upsilon(p)=(\texttt{\small
value},\alpha_{L}(l))$

     * •

There will be $p^{\prime}\in\mathbb{P}$ with
$\Upsilon(p^{\prime})=(\texttt{\small type},\delta(l))$

     * •

$\Delta(n)=\Delta(n)\cup p\cup p^{\prime}$

  3. 3.

For each $dp\in E_{D}$ satisfying that $\beta_{D}(dp)=(r_{1},r_{2})$

     * •

There will be $e\in\mathbb{E}$ with $\Gamma(e)=\texttt{\small
DatatypeProperty}$, and $\Sigma(e)=(n_{1},n_{2})$ where
$n_{1},n_{2}\in\mathbb{N}$ correspond to $r_{1},r_{2}\in N_{I}$ respectively

     * •

There will be $p\in\mathbb{P}$ with $\Upsilon(p)=(\texttt{\small
type},\delta(dp))$

     * •

$\Delta(e)=\Delta(e)\cup p$

  4. 4.

For each $op\in E_{O}$ satisfying that $\beta_{O}(op)=(r_{1},r_{2})$

     * •

There will be $e\in\mathbb{E}$ with $\Gamma(e)=\texttt{\small
ObjectProperty}$, and $\Sigma(e)=(n_{1},n_{2})$ where
$n_{1},n_{2}\in\mathbb{N}$ correspond to $r_{1},r_{2}\in N_{I}$ respectively

     * •

There will be $p\in\mathbb{P}$ with $\Upsilon(p)=(\texttt{\small
type},\delta(op))$

     * •

$\Delta(e)=\Delta(e)\cup p$

According to the above definition, the instance mapping $\mathcal{IM}_{2}$
creates PG nodes from resource nodes and literal nodes, and PG edges from
datatype properties and object properties. The property type is used to
maintain resource class identifiers and RDF datatypes. The property iri is
used to store the IRI of RDF resources and properties. The property value is
used to maintain a literal value.

For example, the PG obtained after applying $\mathcal{IM}_{2}$ over the RDF
graph shown in Figure 1 is given as follows:

⬇

1$\mathbb{N}=\\{n_{1},n_{2},n_{3},n_{4},n_{5},n_{6}\\}$,

2$\mathbb{E}=\\{e_{1},e_{2},e_{3},e_{4},e_{5}\\}$,

3$\mathbb{P}=\\{p_{1},\dots,p_{17}\\}$,

4$\Gamma(n_{1})=\\{\text{Resource}\\}$, $\Gamma(n_{2})=\\{\text{Resource}\\}$,
$\Gamma(n_{3})=\\{\text{Literal}\\}$, $\Gamma(n_{4})=\\{\text{Literal}\\}$,
$\Gamma(n_{5})=\\{\text{Literal}\\}$, $\Gamma(n_{6})=\\{\text{Literal}\\}$,

5$\Gamma(e_{1})=\\{\text{ObjectProperty}\\}$,
$\Gamma(e_{2})=\\{\text{DatatypeProperty}\\}$,
$\Gamma(e_{3})=\\{\text{DatatypeProperty}\\}$,
$\Gamma(e_{4})=\\{\text{DatatypeProperty}\\}$,
$\Gamma(e_{5})=\\{\text{DatatypeProperty}\\}$,

6$\Upsilon(p_{1})=(\text{iri},\text{"ex:Tesla\\_Inc"})$,
$\Upsilon(p_{2})=(\text{type},\text{"voc:Organisation"})$,
$\Upsilon(p_{3})=(\text{iri},\text{"ex:Elon\\_Musk"})$,
$\Upsilon(p_{4})=(\text{type},\text{"voc:Person"})$
$\Upsilon(p_{5})=(\text{value},\text{"Tesla, Inc."})$,
$\Upsilon(p_{6})=(\text{type},\text{"xsd:string"})$,
$\Upsilon(p_{7})=(\text{value},\text{"2003-07-01"})$,
$\Upsilon(p_{8})=(\text{type},\text{"xsd:date"})$,
$\Upsilon(p_{9})=(\text{value},\text{"Elon Musk"})$,
$\Upsilon(p_{10})=(\text{type},\text{"xsd:string"})$,
$\Upsilon(p_{11})=(\text{value},\text{"46"})$,
$\Upsilon(p_{12})=(\text{type},\text{"xsd:int"})$,
$\Upsilon(p_{13})=(\text{iri},\text{"voc:ceo"})$,
$\Upsilon(p_{14})=(\text{iri},\text{"voc:name"})$,
$\Upsilon(p_{15})=(\text{iri},\text{"voc:creation"})$,
$\Upsilon(p_{16})=(\text{iri},\text{"voc:birthName"})$,
$\Upsilon(p_{17})=(\text{iri},\text{"voc:age"})$

7$\Sigma(e_{1})=\\{n_{1},n_{2}\\}$, $\Sigma(e_{2})=\\{n_{1},n_{3}\\}$,
$\Sigma(e_{3})=\\{n_{1},n_{4}\\}$, $\Sigma(e_{4})=\\{n_{2},n_{5}\\}$,
$\Sigma(e_{5})=\\{n_{2},n_{6}\\}$,

8$\Delta(n_{1})=\\{p_{1},p_{2}\\}$, $\Delta(n_{2})=\\{p_{3},p_{4}\\}$,
$\Delta(n_{3})=\\{p_{5},p_{6}\\}$, $\Delta(n_{4})=\\{p_{7},p_{8}\\}$,
$\Delta(n_{5})=\\{p_{9},p_{10}\\}$, $\Delta(n_{6})=\\{p_{11},p_{12}\\}$,

9$\Delta(e_{1})=\\{p_{13}\\}$, $\Delta(e_{2})=\\{p_{14}\\}$,
$\Delta(e_{3})=\\{p_{15}\\}$, $\Delta(e_{4})=\\{p_{16}\\}$,
$\Delta(e_{5})=\\{p_{17}\\}$.

Figure 6 shows a graphical representation of the Property Graph described
above.

Figure 6: Example of Property Graph obtained after applying the schema-
independent database mapping.

###  4.3 Properties of $\mathcal{DM}_{2}$

In this section, we evaluate the computability, semantics preservation and
information preservation of the database mapping $\mathcal{DM}_{2}$.

Recall that $\mathcal{DM}_{2}$ is a formed by the schema mapping
$\mathcal{SM}_{2}$ and the instance mapping $\mathcal{IM}_{2}$, where
$\mathcal{SM}_{2}$ always creates a generic PG schema $S^{*}$.

###### Proposition 2

The database mapping $\mathcal{DM}_{2}$ is _computable_.

It is not difficult to see that an algorithm can be created from the
description of the instance mapping $\mathcal{IM}_{2}$, presented in
Definition 16.

###### Lemma 2

The database mapping $\mathcal{DM}_{2}$ is _semantics preserving_.

It is straightforward to see (by definition) that any PG graph created with
the instance mapping $\mathcal{IM}_{2}$ will be valid with respect to the
generic PG schema $S^{*}$.

###### Theorem 2

The database mapping $\mathcal{DM}_{2}$ is _information preserving_.

In order to prove that $\mathcal{DM}_{2}$ is information preserving, we need
to provide a database mapping $\mathcal{DM}^{-1}_{2}$ which allows to
transform a PG database into an RDF database, and show that for every RDF
database $D^{R}$, it applies that
$D^{R}=\mathcal{DM}^{-1}_{2}(\mathcal{DM}_{2}(D^{R})$.

Recalling that the objective of this section is to provide a schema-
independent database mapping, we will assume that for any RDF database
$D^{R}=(S^{R},G^{R})$, the RDF graph schema $S^{R}$ is null or irrelevant to
validate $G^{R}$. Hence, we just define an instance mapping
$\mathcal{IM}^{-1}_{2}$ which allows to transform a PG graph into an RDF
database, such that for every RDF graph $G^{R}$, it must satisfy that
$G^{R}=\mathcal{IM}^{-1}_{2}(\mathcal{IM}_{2}(G^{R}))$.

######  Definition 17 (Instance mapping $\mathcal{IM}^{-1}_{2}$)

Let $G^{P}=(\mathbb{N},\mathbb{E},\mathbb{P},\Gamma,\Upsilon,\Sigma,\Delta)$
be a Property Graph and
$G^{R}=(N_{I},N_{L},E_{O},E_{D},\alpha_{I},\alpha_{L},\beta_{O},\beta_{D},\delta)$
be an RDF graph. The instance mapping $\mathcal{IM}^{-1}_{2}(G^{P})=G^{R}$ is
defined as follows:

  1. 1.

For each $n\in\mathbb{N}$ satisfying that $\Gamma(n)=\texttt{\small
Resource}$, $p_{1},p_{2}\in\Delta(n)$, $\Upsilon(p_{1})=(\texttt{\small
iri},v_{1})$ and $\Upsilon(p_{2})=(\texttt{\small type},v_{2})$, then there
will be $r\in N_{I}$ with $\alpha_{I}(r)=v_{1}$ and $\delta(r)=v_{2}$

  2. 2.

For each $n\in\mathbb{N}$ satisfying that $\Gamma(n)=\texttt{\small Literal}$,
$p_{1},p_{2}\in\Delta(n)$, $\Upsilon(p_{1})=(\texttt{\small value},v_{1})$ and
$\Upsilon(p_{2})=(\texttt{\small type},v_{2})$, then there will be $r\in
N_{L}$ with $\alpha_{L}(r)=v_{1}$ and $\delta(r)=v_{2}$

  3. 3.

For each $e\in\mathbb{E}$ satisfying that $\Gamma(e)=\texttt{\small
ObjectProperty}$ , $p\in\Delta(e)$, $\Upsilon(p)=(\texttt{\small type},v)$,
$\Sigma(e)=(n_{1},n_{2})$, then there will be $op\in E_{O}$ with
$\delta(op)=v$, $\beta_{O}(op)=(r_{1},r_{2})$ where $r_{1}\in N_{I}$
corresponds to $n_{1}\in\mathbb{N}$, and $r_{2}\in N_{I}$ corresponds to
$n_{2}\in\mathbb{N}$

  4. 4.

For each $e\in\mathbb{E}$ satisfying that $\Gamma(e)=\texttt{\small
DatatypeProperty}$ , $p\in\Delta(e)$, $\Upsilon(p)=(\texttt{\small type},v)$,
$\Sigma(e)=(n_{1},n_{2})$, then there will be $dp\in E_{D}$ with
$\delta(dp)=v$, $\beta_{D}(dp)=(r_{1},r_{2})$ where $r_{1}\in N_{I}$
corresponds to $n_{1}\in\mathbb{N}$, and $r_{2}\in N_{L}$ corresponds to
$n_{2}\in\mathbb{N}$

Hence, the method defined above defines that for each node labeled with
Resource is transformed into a resource node, each node labeled with Literal
is transformed into a literal node, each edge labeled with ObjectProperty is
transformed into a resource-resource edge, and each edge labeled with
DatatypeProperty is transformed into a resource-literal edge. Additionally,
the property iri is used to recover the original IRI identifier (for nodes),
and the property type allows us to recover the IRI identifier of the resource
class associated to each node or edge.

It is not difficult to verify that for any RDF graph $G^{R}$, we can produce a
PG graph $G^{P}=\mathcal{SM}_{1}(G^{R})$, and then recover $G^{R}$ by using
$\mathcal{IM}^{-1}_{2}(G^{P})$.

##  5 Related Work

In this section we present the related work that targets the interoperability
issue between the RDF and PG data models. We group the efforts based on
mapping of the data model they target, i.e. RDF $\rightarrow$ PG and vice
versa, and summarise their shortcomings.

On the other hand, how to build RDF from existing data sources becomes an
important issue in the area of Semantic Web. For that purpose, many papers
come up with transforming methods of constructing RDF from different sources,
e.g. XML [7, 40], relational databases [8, 13]. However, there are also more
general approaches [11, 12, 10, 15].

RDF $\rightarrow$ PG. Hartig [17] proposes two formal transformations between
RDF⋆ and PGs. RDF⋆ is a conceptual extension of RDF which is based on
reification. The first transformation maps any RDF triple as an edge in the
resulting PG. Each node has the “kind” property to describe the node type
(e.g. IRI). The second transformation distinguishes data and object
properties. The former is transformed into node properties and latter into
edges of a PG. The shortcoming of this approach is that RDF⋆ – (i) does not
support mapping an RDF graph schema, and (ii) adds an extra step of an
intermediate mapping and; (iii) isn’t supported by major RDF stores.

In S2X, Schätzle et al. [31] propose a GraphX-specific RDF-PG transformation.
The mapping uses attribute label to store the node and edge identifiers, i.e.
each triple t = (s, p, o) is represented using two vertices $v_{s},v_{0}$, an
edge ($v_{s},v_{o}$) and labels $v_{s}$.label = s, $v_{o}$.label = o,
($v_{s},v_{o}$).label = p. Apart from being only GraphX-specific, this
approach misses the concept of properties and also does not cover RDF graph
Schema.

Nyugen et al. [24], propose the LDM-3N (labeled directed multigraph - three
nodes) graph model. This data model represents each triple element as separate
nodes, thus the three nodes (3N) . The LDM-3N graph model is used to address
the Singleton Property (SP) based reified RDF data. The problem with this
approach is that: (i) it adds adds an extra computation step (and 2n triples);
(ii) does not cover RDF graph Schema; and misses the concept of properties.

Tomaszuk [41], propose YARS serialization for transforming RDF data into PGs.
This approach performs only a syntactic transformation between encoding
schemes and does not cover RDF Schema.

PG $\rightarrow$ RDF. There exist very few proposals for the PG-to-RDF
transformation, such as Das et al. [14] and Hartig [17], that mainly use RDF
reification methods (including Blank Nodes) to convert nodes and edge
properties in a PG to RDF data. While [17] propose an in-direct mapping that
requires converting to the $RDF^{\star}$ model (as mentioned earlier), [14]
lacks a formal foundation. Both approaches do not consider the presence of a
PG schema. Another approach is Unified Relational Storage (URS) [43]. It
focuses on interchangeably managing RDF and Property Graphs, and this is not a
strict transformation method.

Table 2, presents a consolidated summary of related work and the features they
address.

Table 2: A consolidated summary of related work addressing data
interoperability. Here "-" implies no evidence/claim was found the respective
study.

Work |  Target |  Is a Direct mapping? |  Formally Defined? |  Covers Schema? |  Is Information Preserving?
---|---|---|---|---|---
$\text{RDF}^{\star}$ [17] |  RDF$\leftrightarrow$PG |  No |  Yes |  No |  –
URS [43] |  RDF$\leftrightarrow$PG |  No |  No |  Yes |  No
S2X [31] |  RDF$\rightarrow$PG |  - |  No |  No |  No
LDM-3N [24] |  RDF$\rightarrow$PG |  No |  No |  No |  No
Das et al. [14] |  PG$\rightarrow$RDF |  No |  No |  No |  No
YARS [41] |  PG$\rightarrow$RDF |  No |  No |  No |  No
Our approach |  RDF$\leftrightarrow$PG |  Yes |  Yes |  Yes |  Yes

##  6 Conclusions

In this article, we have presented two mappings to transform RDF databases
into Property Graph databases. We have shown that both database mappings
satisfy the property of information preservation, i.e. there exist inverse
mappings that allow recovering the original databases without losing
information. These results allow us to present the following conclusion about
the information capacity of the Property Graph data models with respect to the
RDF data model.

###### Corollary 1

The property graph data model subsumes the information capacity of the RDF
data model.

Although our methods assume some condition for the input RDF databases, they
are generic and can be easily extended (by overloading the mapping functions)
to provide support for features such as inheritance (e.g. rdfs:subClassOf,
rdfs:subPropertyOf) and Blank Nodes (via Skolemisation [20]). Furthermore, our
formal definitions will be very useful to study query interoperability [39,
38, 36, 25] and query preservation between RDF and Property Graph databases
(i.e. query transformation between SPARQL queries and any Property Graph query
language). Thus, with this paper, we take a substantial step by laying the
core formal foundation for supporting interoperability between RDF and
Property Graph databases. As future work, we plan to incorporate features such
as RDF reification techniques (N-ary Relations, Named Graphs, etc),
inheritance, and OWL 2 RL.

## References

  * [1] R. Angles, H. Thakkar, and D. Tomaszuk.  Mapping rdf databases to property graph databases.  IEEE Access, 8:86091–86110, 2020.
  * [2] Renzo Angles, Peter Boncz, Josep Larriba-Pey, Irini Fundulaki, Thomas Neumann, Orri Erling, Peter Neubauer, Norbert Martinez-Bazan, Venelin Kotsev, and Ioan Toma.  The linked data benchmark council: a graph and rdf industry benchmarking effort.  Sigmod Record, 43(1), March 2014.
  * [3] Renzo Angles and Claudio Gutierrez.  An introduction to graph data management.  In Graph Data Management: Fundamental Issues and Recent Developments, pages 1–32. Springer, 2018.
  * [4] Renzo Angles, Harsh Thakkar, and Dominik Tomaszuk.  RDF and property graphs interoperability: Status and issues.  In Proceedings of the 13th AMW, 2019., 2019.
  * [5] François Belleau, Marc-Alexandre Nolin, Nicole Tourigny, Philippe Rigault, and Jean Morissette.  Bio2RDF: towards a mashup to build bioinformatics knowledge systems.  Journal of biomedical informatics, 41(5):706–716, 2008.
  * [6] Paul V. Biron, Michael Sperberg-McQueen, Sandy Gao, Ashok Malhotra, Henry Thompson, and David Peterson.  W3C XML schema definition language (XSD) 1.1 part 2: Datatypes.  W3C recommendation, W3C, April 2012.
  * [7] Stefan Bischof, Stefan Decker, Thomas Krennwallner, Nuno Lopes, and Axel Polleres.  Mapping between RDF and XML with XSPARQL.  J. Data Semantics, 1(3):147–185, 2012.
  * [8] Christian Bizer and Andy Seaborne.  D2RQ - Treating Non-RDF Databases as Virtual RDF Graphs.  In ISWC2004 (posters), November 2004.
  * [9] Dan Brickley and R. V. Guha.  RDF Schema 1.1, W3C recommendation.  W3C recommendation, World Wide Web Consortium, February 25 2014.
  * [10] Dan Connolly.  Gleaning Resource Descriptions from Dialects of Languages (GRDDL).  W3C recommendation, World Wide Web Consortium, September 2007.
  * [11] Olivier Corby and Catherine Faron-Zucker.  A Transformation Language for RDF based on SPARQL.  Web Information Systems and Technologies, 2015.
  * [12] Olivier Corby, Catherine Faron-Zucker, and Fabien Gandon.  A Generic RDF Transformation Software and Its Application to an Online Translation Service for Common Languages of Linked Data.  In International Semantic Web Conference (2), volume 9367 of Lecture Notes in Computer Science, pages 150–165. Springer, 2015.
  * [13] Souripriya Das, Richard Cyganiak, and Seema Sundara.  R2RML: RDB to RDF Mapping Language.  W3C recommendation, World Wide Web Consortium, September 2012.
  * [14] Souripriya Das, Jagannathan Srinivasan, Matthew Perry, Eugene Inseok Chong, and Jayanta Banerjee.  A tale of two graphs: Property graphs as RDF in oracle.  In EDBT, 2014.
  * [15] Anastasia Dimou, Miel Vander Sande, Pieter Colpaert, Ruben Verborgh, Erik Mannens, and Rik Van de Walle.  RML: A Generic Language for Integrated RDF Mappings of Heterogeneous Data.  In Proceedings of the 7th Workshop on Linked Data on the Web, volume 1184 of CEUR Workshop Proceedings, April 2014.
  * [16] Steve Harris and Andy Seaborne.  SPARQL 1.1 query language - W3C recommendation.  W3C recommendation, World Wide Web Consortium, Mar 2013.
  * [17] Olaf Hartig and Bryan Thompson.  Foundations of an alternative approach to reification in RDF.  arXiv:1406.3399, 2019.
  * [18] Bernhard Haslhofer and Antoine Isaac.  data. europeana. eu: The europeana linked open data pilot.  In International Conference on Dublin Core and Metadata Applications, pages 94–104, 2011.
  * [19] José-Miguel Herrera, Aidan Hogan, and Tobias Käfer.  BTC-2019: The 2019 billion triple challenge dataset.  In 18th International Semantic Web Conference (ISWC), 2019.
  * [20] Aidan Hogan, Marcelo Arenas, Alejandro Mallea, and Axel Polleres.  Everything you always wanted to know about blank nodes.  Journal of Web Semantics, 27(1), 2014.
  * [21] Richard Hull.  Relative information capacity of simple relational database schemata.  SIAM Journal on Computing, 15(3):856–886, 1986.
  * [22] Graham Klyne and Jeremy Carroll.  RDF 1.1 concepts and abstract syntax.  W3C recommendation, World Wide Web Consortium, February 2014.
  * [23] Mohamed Nadjib Mami, Damien Graux, Harsh Thakkar, Simon Scerri, Sören Auer, and Jens Lehmann.  The query translation landscape: a survey.  CoRR, abs/1910.03118, 2019.
  * [24] Vinh Nguyen, Jyoti Leeka, and Sheth Amit Bodenreider, Olivier.  A formal graph model for RDF and its implementation.  arXiv:1606.00480, 2016.
  * [25] Vinh Nguyen, Hong Yung Yip, Harsh Thakkar, Qingliang Li, Evan Bolton, and Olivier Bodenreider.  Singleton property graph: Adding a semantic web abstraction layer to graph databases.  In Proceedings of the 2nd International Semantic Web Conference (ISWC) Workshop on Contextualised Knowledge Graphs (CKG), 2019.
  * [26] Christine Parent and Stefano Spaccapietra.  Database integration: the key to data interoperability.  Advances in Object-Oriented Data Modeling, 2000.
  * [27] Jaroslav Pokorný, Michal Valenta, et al.  Integrity constraints in graph databases.  Procedia Computer Science, 109:975 – 981, 2017.
  * [28] Eric Prud’hommeaux and Gavin Carothers.  RDF 1.1 Turtle.  W3C recommendation, World Wide Web Consortium, February 2014.
  * [29] Ian Robinson, Jim Webber, and Emil Eifrem.  Graph Databases.  O’Reilly Media, first edition, June 2013.
  * [30] S.Ceri, L. Tanca, and R. Zicari.  Supporting interoperability between new database languages.  In CompEuro, 1991.
  * [31] Alexander Schätzle, Martin Przyjaciel-Zablocki, Thorsten Berberich, and Georg Lausen.  S2X: graph-parallel querying of RDF with graphx.  In Biomedical Data Management and Graph Online Querying, pages 155–168. Springer, 2015.
  * [32] Max Schmachtenberg, Christian Bizer, and Heiko Paulheim.  Adoption of the linked data best practices in different topical domains.  In The Semantic Web–ISWC 2014, pages 245–260. Springer, 2014\.
  * [33] Juan F. Sequeda, Marcelo Arenas, and Daniel P. Miranker.  On directly mapping relational databases to RDF and OWL.  In Proc. of the International Conference on World Wide Web (WWW), pages 649–658. ACM, 2012.
  * [34] IEEE standard computer dictionary: A compilation of IEEE standard computer glossaries.  IEEE Std 610, Jan 1991.
  * [35] Harsh Thakkar.  Towards an open extensible framework for empirical benchmarking of data management solutions: LITMUS.  In 14th International Conference, ESWC, 2017.
  * [36] Harsh Thakkar, Renzo Angles, Marko Rodriguez, Stephen Mallette, and Jens Lehmann.  Let’s build bridges, not walls: Sparql querying of tinkerpop graph databases with sparql-gremlin.  In 2020 IEEE 14th International Conference on Semantic Computing (ICSC), pages 408–415. IEEE, 2020.
  * [37] Harsh Thakkar, Yashwant Keswani, Mohnish Dubey, Jens Lehmann, and Sören Auer.  Trying not to die benchmarking: Orchestrating RDF and graph data management solution benchmarks using LITMUS.  In SEMANTICS, 2017.
  * [38] Harsh Thakkar, Dharmen Punjani, Yashwant Keswani, Jens Lehmann, and Sören Auer.  A stitch in time saves nine–SPARQL querying of property graphs using gremlin traversals.  arXiv:1801.02911, 2018.
  * [39] Harsh Thakkar, Dharmen Punjani, Jens Lehmann, and Sören Auer.  Two for one: querying property graph databases using SPARQL via Gremlinator.  In Proceedings of the 1st ACM SIGMOD Joint International Workshop GRADES-NDA, page 12. ACM, 2018.
  * [40] Pham Thi Thu Thuy, Young-Koo Lee, and SungYoung Lee.  DTD2OWL: Automatic Transforming XML Documents into OWL Ontology.  In Proceedings of the 2Nd International Conference on Interaction Sciences: Information Technology, Culture and Human, ICIS ’09, pages 125–131, New York, NY, USA, 2009. ACM.
  * [41] Dominik Tomaszuk.  RDF data in property graph model.  In MTSR. Springer, 2016.
  * [42] Denny Vrandečić.  Wikidata: A new platform for collaborative data collection.  In Proceedings of the 21st international conference on world wide web, pages 1063–1064. ACM, 2012.
  * [43] Ran Zhang, Pengkai Liu, Xiefan Guo, Sizhuo Li, and Xin Wang.  A unified relational storage scheme for RDF and property graphs.  In International Conference on Web Information Systems and Applications, pages 418–429. Springer, 2019.