Property graph databases provide e cient implementations of graph traversal operations, while Semantic Web technologies provide expressive symbolic representation, querying, and reasoning tasks. Despite the di erences between the goals of the two data models, they do share similar graph characteristics. In this paper, we attempt to combine the bene ts of each model into a single graph abstraction layer called Singleton Property Graph (SPG). The SPG layer sits on top of the RDF and simulates the property graph model. We describe the SPG model and its queries, which are Semantic Web-compliant, to be executed inside property graph databases such as TinkerPop. We have tested the prototype and evaluated the experiments with the two datasets BKR and PubChem.
Although property graphs and RDF are the most popular graph models
supported by several graph databases, a single database engine implementing both
graph models and their query languages remains to be developed. Graph databases
such as AllegroGraph [
Due to the similarity in the graph characteristics between the property graph and the RDF graph, a common graph model simulating both graph models is feasible, and it can combine the advantages of both worlds, graph databases and Semantic Web. The simulation enables the RDF datasets and their SPARQL queries to be loaded and executed in a property graph. This common graph model will provide the capability to run Semantic Web tasks on top of a property graph database and hence, provide the bridge to connect the two worlds.
In this paper, we propose such a common graph model. Here we use the example from Figure 1 as the motivating example for demonstrating our graph model throughout the paper. 1.1
A Property Graph (PG) is a directed labeled graph with a set of nodes and
a set of edges in which every edge is unique and connects an ordered pair of
nodes. A node represents an entity, and an edge represents a relationship
between two entities. Each node or edge has properties associated with it in the
form of key-value pairs. Figure 1 shows an example of a property graph taken
from the Apache TinkerPop Gremlin documentation [
Next, we will present our approach to representing a property graph model and its graph characteristics using RDF. 1.2
Compared to the RDF graph model, the distinct characteristics of the property graph model described above are: 1) the edges have their own properties just like the nodes, and 2) every edge or node has a unique identi er. In the running example, the relationship created has a property key weight showing the contribution of each person to the creation of the software. The nodes have identi ers 1-6 and the edges have identi ers 7 -12.
We observed that this property model shares distinct characteristics with
the singleton property (SP) model [
Each blue node represents an entity of type person or software. A person node has two property keys: name and age. A software node has two property keys: name and lang. Each edge represents one unique relationship knows between two person entities or one unique relationship created between one person entity and one software entity. properties for each edge, each singleton property can also be associated with additional metadata triples. Therefore, the similarities between the singleton properties of the SP model and the edges of the PG model may provide the foundation for developing a common data model between them. Here we show how edge number 9 in Figure 1 can be represented in the SP model with URIs created by concatenating the label and the id of each node as follows: T1 : person#1 created#9 software#3 .
T2 : created#9 singletonPropertyOf created .
T3 : created#9 weight 0.4 .
Although the SP model can represent the PG edges intuitively as shown
above, its SPARQL query pattern ?sub ?sp ?obj . (TP1) and
?sp singletonPropertyOf ?p . (TP2) cannot be used to e ciently traverse
this PG model. The singleton properties are unknown in most cases and are
represented as variables in this SP query pattern. Because the singleton
properties are usually unknown, if they are used to query the edges of the PG model,
the PG traversal algorithm's performance may su er severely because of the
all-variable triple pattern ?sub ?sp ?obj . [
Furthermore, a singleton property can be associated with a metadata value which turns out to be another entity or node. For example, in the SP patterns with ?sp derives_from PMID_1 . (TP3) and PMID_1 type Article . (TP4), the singleton property ?sp is associated with the metadata value PMID_1 (in TP3), and this metadata value is also an entity of Article (in TP4). This feature makes the SP model more expressive, but unfortunately it is not supported in the PG model. A PG edge can only take the property value from a data type; it does not accept another entity node like the PMID_1. As a result, the PG model cannot support the join between the edge's property values and the nodes to simulate the join between the singleton property's metadata value PMID_1 (in TP3) and the subject PMID_1 (in TP4).
Therefore, to develop a common graph model for both RDF and PG models and their query languages, we identify three requirements: (R1) consider the intrinsic similarities between the singleton properties and the PG edges, (R2) resolve the potential degraded performance caused by the SP all-variable query pattern (in TP1) applied to the PG whole-graph traversals, and (R3) enable support for the singleton property's additional metadata values as entity nodes (in TP3 and TP4). 1.3
In this paper, we propose the SPG, a common graph model that meets the three requirements analyzed above. Our contribution for the SPG model includes: { a graph model as abstraction graph layer on top of the RDF singleton property that can simulate the two distinct characteristics of the PG model, { a graph query pattern that can express the PG traversals to the key-value properties of the nodes and edges, a SPARQL-compliant querying mechanism that can be executed in PG databases, and { an implementation of this SPG model for two use cases, BKR and PubChem.
Two SPG models with their sets of SPG queries generated from the BKR and PubChem inputs are loaded and evaluated in the PG databases.
The rest of the paper is organized as follows. Section 2 describes our SPG model. Section 3 describes the SPG queries and the SPARQL-compliant querying mechanism with two use cases from the BKR and PubChem datasets. Section 4 demonstrates the feasibility of our implementation for representing and querying the SPG model in the PG databases such as Apache TinkerPop and Neo4j. We provide the related work in Section 5 and conclude with Section 6. 2
Here we explain how the SPG model can be constructed to be compatible with both the RDF and PG models and to meet the three requirements analyzed in Section 1.2.
Given the motivating example from the property graph in Figure 1 , the SP triples T1; T2; and T3 annotate the semantics of the edge property using the SP model. As this annotation is straightforward, Requirement R1 can be met easily with the adoption of the SP model as the foundation for the new common model SPG.
Here we address the Requirements R2 and R3 for the new SPG model.
Nodes. We observe that the two issues discussed in Requirements R2 and R3 only occur when the PG edges and the singleton properties are mapped into the edges of a basic graph. In other words, mapping the SP and the PG edges into the edges of a graph is the cause of the two issues.
If we do not map the PG edges and SPs into the edges of a graph, indeed, we
are left with another choice, which is to map them to the nodes of that graph. We
have explored this choice in our prior work [
First, comparing the edges and the nodes in a PG, we observe that both of them share the same characteristic that both of them can carry their own properties. However, the edges carry one extra connectivity characteristic that the nodes do not. In the SP triple, the subject/object and the singleton property also share the same characteristic that all of them can be asserted in any triple. The singleton property itself can also carry the unique connection between the subject and the object. Therefore, from this point of view, we believe that the PG edges and SPs do carry the characteristics of both nodes and edges of a graph, and it is reasonable to map them to a special type of nodes which we refer to as property nodes.
Second, if the mapping is to the nodes, then we have all three disconnected nodes. Requirement R3 is satis ed because PG nodes can be connected to other nodes via edges by the design of the PG model. Here we show how Requirement R2 with all-variable SP query pattern can be address indirectly.
For the three disconnected nodes, we create the rst edge with id: e1 and label: in connecting the rst and the second nodes, and the second edge with id: e2 and label: out connecting the second node and the third node as shown in Figure 2. The second node is the property node, and it carries the properties from the original PE edge. If the second node is mapped from the singleton property, then its id has the UUID of the SP, and its label has the value from the generic property. In either case, the property node and the two edges e1 and e2 always have a label. When the query for the SP pattern is formed, no variable is needed for the predicate, and that resolves Requirement R2 in the SP all-variable query pattern. Section 3 will discuss this issue in more detail. Therefore, mapping the PG edges and SPs into property nodes satis es the two remaining Requirements R2 and R3.
As a consequence, the resulting graph meets the three requirements for a common graph model. This resulting graph is called the SPG.
Loading and Querying SPG Model in Property Graphs The SPG model described previously is compliant with the RDF representation, and the SPG queries can be expressed in SPARQL. However, here we focus on the implementation of the SPG model and the execution of SPG queries in property graph databases.
We start this section by showing how the SPG model is implemented in the two datasets, PubChem and BKR. We then explain how the SPG queries are constructed and executed.
We collected the data generated by PubChem 3-D similarity algorithm 4,
measuring two similar compounds using 3-D Shape and Color Tanimoto scores [
Given a pair of compounds CUI_1 and CUI_2, we represent the similarity scores between them as the has ST score and the has CT score. We created a singleton property has_sim_score between the two compounds and associate with it the two meta scores. We loaded the PubChem 3-D similarity scores into two models, M0 and M1 datasets. The di erence between the PubChem-M0 and PubChem-M1 datasets is that the PubChem-M0 maps the SPs to edges while PubChem-M1 maps the SPs to property nodes as shown in Figure 3.
We provide the PubChem-M0 to show the limitation of the SPARQL queries if not using our SPG model. The SPARQL query in this model cannot access the key-value of the edges as we pointed out in Requirement R2. 4 ftp://ftp.ncbi.nlm.nih.gov/pubchem/Compound_3D/similar_conformers/
BKR is a biomedical knowledge repository containing over 30 million semantic
predications extracted from PubMed abstracts and the Uni ed Medical
Language System (UMLS) [
Given a semantic predication (C0007028, PART OF, C0026969) extracted from the PubMed abstract PUBMED 99992, we represent it in the form of singleton property as follows.
C0007028 PART OF#1 C0026969 .
PART OF#1 singletonPropertyOf PART OF .
PART OF#1 derives from PUBMED 99992 .
We transformed this SP dataset into the SPG representation using two models, BKR-M1 and BKR-M2 as shown in Figure 4. The di erence between the two models is that in the BKR-M1, we map the singleton properties to a set of property nodes, and the source of the semantic predication is represented as a key-value pair of the property node. Meanwhile, in the BKR-M2, we map the source of the semantic predication to another node and provide additional information about that node, such as the publication date. This BKR-M2 model demonstrates the support for Requirement R3 from Section 1.2. 3.3
We loaded the two PubChem and BKR datasets to the Neo4J database using the
SPG's M1 and M2 models as shown in Figure 3 and Figure 4, respectively. These
models can be queried using SPARQL-compliant SPG queries associated with
each model. The SPG queries are executed by using the Sparql-gremlin plugin
[
For every SPG node triple t = (vi; ve; vj), fSP G(vi; ve; vj) = (ei; eo), the node triple is connected by the pair of (in, out) edges. The subject node vi is connected to the property node ve by the label:in edge ei, and the property node ve is connected to the object node vj by the label:out edge eo. Therefore, the common SPG pattern for accessing any SPG node triple will be in this form: ?sub1 e:in ?pred1 . ?pred1 e:out ?obj1 . (P1)
For accessing the value from the key key_m of any node in the SPG node triple, we use the following pattern: ?sub1 v:key_m ?val. (P2)
These SPG query patterns P1 and P2 can be used in conjunction with each other to traverse and retrieve the key-value pairs of any node in the SPG model. All SPG queries from Figure 3 and Figure 4 use these two patterns.
For example, considering the queries BKR-M2-1 and BKR-M2-2, two node triple patterns P1 and one key-value pattern P2 are used to construct these queries. The queries BKR-M1-1 and BKR-M1-2 share the same combination of one node triple pattern P1 and one key-value pattern P2.
For the PubChem-M1, the query PubChem-M1-1 uses only one node triple pattern P1, and the query PubChem-M1-2 uses one node triple pattern P1 and one key-value pattern P2. Meanwhile, the PubChem-M0 is not a SPG model. It cannot support the access to the key-value properties of the M0's edges.
Next, we report the use of the data models generated here for the experimental evaluation. 4
In this section we report the experiments that demonstrate the proof-of-concept implementation of SPG models serving as a Semantic Web abstraction layer on property graphs with queryable Semantic Web-compliant SPARQL queries. The experiments can be grouped into three main categories: (i) importing the SPG models into property graph database, (ii) comparing the property graph loading and reading times, and (iii) clocking the query execution time and evaluating the query results. In these experiments, we used the Biomedical Knowledge Repository (BKR) and PubChem datasets described in Section 3. 4.1
Transform ..SNPTGriple (SP) to Transform .CSV to .SPG sTehrveerexrpuenrniminegntosnwCereentpOeSrfo7rmweidthon126a proCpreeratytegBraKpRh-Mm1odel pro(CpwreiertahtytmegBreaKtpaRhd-aMmta2o)del pCrroepaetertPyugbraCphhemm-oMde1l PGMB 9o8f3 RNAVMMeansdtor3a.8g4e. TWBe oufseSdamNseuon4Jg version 3.2.3 as the property graph Greenlaetriaotnesnhoipdsefsilaensd Execute queries ldinatavberassieonan3d.4A.0paacshtehTe ingrkaeprPhocpoGmrpeumteImpNoerot/4jinGsrearpthinto wPitehrfSoPrAmRSQPLA-GRQreLmtrlianveprlusaglin aginnds:quNeeroy4eJn-Ggirneeminlisntavlleerdsiwonith3.t4w.1o palnudCreataellinnoddeexses on RAeNpaedaoct4hhjee-GTNrineekmoe4lrjiPnGoprpalupwghiitnohn SNPeAo4RJQ-GLr-eGmrleimnlipnlugvienrsiiosnus3e.d4.1to. pTrhoeNeo4j Graph Apache TinkerPop vide the ability to query and traverse a
Neo4J graph using Gremlin, whereas the Fig. 5: Experiment Flowchart SPARQL-Gremlin is a compiler (also known as Gremlinator) that transforms SPARQL queries into Gremlin traversals.
It uses the Apache Jena SPARQL processor ARQ, which provides access to a syntax tree of a SPARQL query. Together, they provide the necessary interoperability interface between the Semantic Web (SPARQL) and Property Graph (Neo4J) crossover. Next, we describe the experiment processes (Figure 5).
The BKR SP dataset [
While the SPG representation preserves the same number of triples, it excels with a le size of 6.6 GB, an overall 62.5% reduction in storage space compared to the SP model. The BKR-M1 implementation has a total of 36M nodes, 67M relationships, and 69M properties, whereas the BKR-M2 has a total of 73M nodes, 134M relationships, and 110M properties. The PubChem-M1 implementation has a total of 368M nodes, 682M relationships, and 1.05B properties (Table 1).
Discussion. Given that the nal BKR-M2 database is twice the size of BKRM1, the di erence between the insert performances is relatively marginal. Two plausible reasons are the NVMe drives set-up that read 3 GB/s and write at 1 GB/s, and the optimizations (heap memory and page cache) con gured on Neo4J server. 4.3
Apache TinkerPop Gremlin is used in conjunction with the Neo4J-Gremlin and SPARQL-Gremlin plugins to provide the functionality of running SPARQL queries over a property graph database, since Neo4J does not natively support SPARQL query language. The Neo4J-Gremlin plugin is used to provide APIlevel access to the BKR-M1, BKR-M2, and PubChem-M1 databases created in Section 4.2. The plugin is con gured with the same con gurations as the Neo4J server to ensure consistency. Finally, the time taken to read and load the graph into Apache TinkerPop were 4.35, 9.46, and 9.83 seconds for BKR-M1, BKRM2, and PubChem-M1, respectively.
Discussion. Using the Neo4J-Gremlin plugin eliminates the additional overhead to export the Neo4J graph as GraphML format and subsequently be loaded into Apache TinkerPop. Our experiment of loading BKR-M1 as GraphML format into Apache TinkerPop took hours due to the plausible need to reconstruct the nodes and relationships as well as their properties from scratch. Nonetheless, the Neo4J-Gremlin provided acceptable reading and loading times, especially for PubChem-M1, with a relatively high number of nodes and relationships compared to BKR-M1 and BKR-M2.
BKR-M1 vs BKR-M2 vs PubChem-M1 Queries Performance
SetA Q1
SetA Q2
SetA Q3
SetA Q4
SetB Q1
SetB Q2
) 1000
s
m
(
em 750
i
T
n
ito 500
u
c
e
x
E 250
e
g
a
r
veA 0
We created a set of SPARQL-compliant queries (set A and set B) derived from
the [
Discussion. Given that the number of nodes and relationships in BKR-M2 are twice the size of BKR-M1, the di erence between the query performances were relatively comparable. This suggested BKR-M2 was equally e cient, but at a higher information (metadata) gain. SetA Q4 was not applicable to BKR-M1 and PubChem-M1 as it involved metadata query which BKR-M1 lacked. 4.5
Our experiments show that the SPG approach gives a decent performance in terms of number of triples, query size, and query execution time. The results support our proof-of-concept that the SPG queries are indeed SPARQL-compliant and can be used as a Semantic Web abstraction layer on top of graph databases. Such a layer enables the support of the expressiveness and logic of semantic technologies while providing an e cient implementation of graph traversal operations. 5
In this paper, we use the singleton property model proposed by Nguyen et al.
[
We also use the sparql-gremlin package [
For the RDF and PG models, several approaches have been proposed for
formalizing the PG model and transforming it to other data models such as
RDF, and RDF*. Hartig et al. [
We have presented the SPG model and its implementation showing that this graph model can be the common graph model for both RDF and PG models. Our model and its implementation can also be reused for other datasets and applications. This model is compatible with Semantic Web standards, with the representation in the form of RDF triples and the queries expressed in SPARQL.
Acknowledgement This research was supported in part by the Intramural Research Program of the National Institutes of Health (NIH), National Library of Medicine (NLM). This research was also supported in part by an appointment to the National Library of Medicine Research Participation Program. This program is administered by the Oak Ridge Institute for Science and Education through an inter-agency agreement between the U.S. Department of Energy and the National Library of Medicine. We are also thankful for the help from Usha Lokala.