SPARQL. An Introduction to Semantic Web Technologies and Benchmarking

Transcription

1 SPARQL An Introduction to Semantic Web Technologies and Benchmarking Seminar Database Systems Master of Science in Engineering Speciality Information and Communication Technologies (ICT) Author: Michael Hedinger Advisor: Prof. Martin Studer Version: 1.0 Final Chur, February 2014

2 Abstract SPARQL is a query language for RDF datastores, also called triplestores. The growing usage of RDF data, for example for Linked Open Data, leads to a greater usage of SPARQL as query language as well. That is why thoughts about performance become a key factor. The performance of SPARQL queries relates on the used RDF supporting database. Besides native RDF storage systems which are also called triplestores RDF data is often stored in relational or graph database systems. The first two chapters of this paper give an introduction to RDF and SPARQL and how these technologies are comparable to the relational databases query language SQL. The next two chapters are dedicated to benchmarking of RDF triplestores. The scope of this paper does not reach beyond an introduction of the mentioned techniques. In particular it does not cover federated queries which would be the very meaning of using Linked (Open) Data.

3 Contents 1. An Introduction to RDF The Semantic Web The Resource Description Framework (RDF) Storage of RDF Data An Introduction to SPARQL Basic SPARQL Queries Filter Results with FILTER Query a SPARQL Endpoint over HTTP Existing Benchmarks Dataset Specification Explore Use Case - Specifications Benchmarking Results Database Systems in Question Existing Comparisons Own Benchmarks Benchmark Platform Software Configurations (Apache) Jena (OpenRDF) Sesame (Openlink) Virtuoso Opensource store Datasets Results Loading Times Results Conclusion and Outlook 18 A. Installation Guides 19 References 22 List of Tables 25 List of Figures 26 3

4 1. An Introduction to RDF The purpose of this chapter is to give an understanding about RDF. This also includes the general idea about the semantic web and its need to retrieve data The Semantic Web The Semantic Web is also called The Web of Data or Web 3.0. While the actual Web 2.0 is focused on people and Social Networking services like Facebook and Twitter the Semantic Web deals with the question how to make the web smarter. That means how can data be stored in a way that the web itself can find related data. Another common used word in this context is Linked (Open) Data. The World Wide Web Consortium (W3C) summarizes the Semantic Web as follows: The ultimate goal of the Web of data is to enable computers to do more useful work and to develop systems that can support trusted interactions over the network. The term Semantic Web refers to W3C s vision of the Web of linked data. Semantic Web technologies enable people to create data stores on the Web, build vocabularies, and write rules for handling data. [23] The W3C is responsible for defining Web standards like HTML, CSS, RDF and SPARQL. The latter two will be explained in this and the next chapter The Resource Description Framework (RDF) The Resource Description Framework (RDF) is a framework for representing information in the Web. [19] The data structure used in RDF are triples where a subject and an object are linked by a predicate. This is called a graph of which an example is shown in figure 1.1. The figure shows two triples both have HTW Chur as subject. The object of the first triple is University of Applied Sciences of Eastern Switzerland. The subject and this object are linked with the relation (the predicate) is part of. The second triple works the same way. In the technical reference for the SPARQL query language [24, section 1.2.2] the notation Turtle [26] is used to describe RDF data. This notation will be used throughout this paper unless stated otherwise. The dataset in figure 1.1 would be written in Turtle as it is shown in listing 1.1 4

5 Figure 1.1.: RDF triple Listing 1.1 : Turtle notation of a simple RDF dataset s: <http :// fho.ch/xmlns/ schools #>. 2 3 s: HTWChur s: partof s: FHO. 4 s: HTWChur s: phoneno "+41 (81) " Storage of RDF Data Triple Stores Triple stores are database systems which are designed to hold statements of the format subject - predicate - object. As they only support triples they natively support RDF datasets and are supposed to be faster than other database systems. RDF optimized database systems are for example Sesame [1] (BSD-style License) or the TDB component of the Apache Jena Framework [10] (Apache License 2.0). Graph Databases While a dataset in a triple store only has one relationship between two nodes, a node in a graph database can have one or more relationships to other nodes. The visualization of the relationships of the graphs in figure 1.1 is shown in figure 1.2. Examples for graph database systems are Neo4j [25] (Commercial or GPL3 License) or ArangoDB [12] (Apache License 2.0). Unfortunately those systems neither read datasets formatted for storage in an RDF store nor do they have native SPARQL endpoints. Both mentioned database management systems support the Gremlin query language. Figure 1.2.: Relationships in a graph Relational Database Systems Commercial relational database systems like IBM DB2 [13] or Oracle Database 12c [18] also store RDF triples which can be queried with SPARQL. For public available RDBMS like MySQL or PostgreSQL there is middleware software like Open Anzo [16] or Apache Jena SDB [11] (not in active development anymore) which provide a way to serve data stored in their tables as a result to a SPARQL query. 5

6 2. An Introduction to SPARQL The official documentation of the SPARQL 1.1 Query Language including syntax, EBNF notation and other resources can be found in the respective technical reference of the W3C [24] Basic SPARQL Queries To get to know SPARQL we will begin with some similarities to the Structured Query Language SQL. The QL in SPARQL stands for the same as in SQL: query language whereas the R stands for RDF. A SPARQL query is quite comparable to a SQL query. Let fhoaddressbook be a SQL table with the columns school and phoneno. To query a phone number of a known school we would write the SQL query as in listing 2.1. Listing 2.1 : SQL query for a phone number 1 SELECT phoneno FROM fhoaddressbook 2 WHERE 3 school == " HTW Chur "; In SPARQL the query would look like in listing 2.2. The FROM part is to specify if the RDF data is stored in another store or file. In this example it would be a file called fhoaddressbook1.ttl with the content of listing 1.1. Listing 2.2 : SPARQL query for a phone number 1 PREFIX s: <http :// fho.ch/ xmlns/ schools #> 2 3 SELECT? htwnumber FROM < fhoaddressbook1. ttl > 4 WHERE 5 { s: HTWChur s: phoneno? htwnumber. } As in natural languages a SPARQL statement ends with a dot. The answer would look like something in listing 2.3. The output was generated by a command line tool of the Apache Jena framework called arq. Listing 2.3 : Response for the previous query htwnumber 3 ======================== 4 "+41 (81) " In listing 2.2 you may have noticed the string?htwnumber. The question mark indicates that the following word is a variable. Variables are the parts of an SPARQL query which we would like to 6

7 find out. Furthermore variables can stand in either of the three positions and it is also possible to define two variables. For example if we want to find out all the schools which have a phone number we would write the query as in listing 2.4. Note that in the SELECT clause unlike SQL we do not write a comma between the variables. Listing 2.4 : SPARQL query with two variables 1 PREFIX s: <http :// fho.ch/ xmlns/ schools #> 2 3 SELECT? school? number 4 WHERE 5 {? school s: phoneno? number. } 2.2. Filter Results with FILTER In listing 2.5 we add some more triples to our RDF dataset. Listing 2.5 : Extended data set s: <http :// fho.ch/xmlns/ schools #>. 2 3 s: FHO s: isa s: umbrellagroup. 4 5 s: HTW s: name " Hochschule fuer Technik und Wirtschaft Chur ". 6 s: HTW s: isa s: school. 7 s: HTW s: phoneno "+41 (81) ". 8 s:htw s:canton "GR" s: HSR s: name " Hochschule fuer Technik Rapperswil ". 11 s: HSR s: isa s: school. 12 s: HSR s: phoneno "+41 (55) ". 13 s:hsr s:canton "SG" s: NTB s: name " Interstaatliche Hochschule fuer Technik Buchs". 16 s: NTB s: isa s: school. 17 s: NTB s: phoneno "+41 (81) ". 18 s:ntb s:canton "SG". Now we want to find all schools (variable?x, only used during the query to identify the same subject) which names (variable?name) start with the letter H. The regular expression for starts with is the hat symbol: ˆH. Thus we write the query as listed in listing 2.6. Listing 2.6 : SPARQL query with FILTER expression 1 PREFIX s: <http :// fho.ch/ xmlns/ schools #> 2 3 SELECT? name FROM < fhoaddressbook2. ttl > 4 WHERE 5 { 6? x s: isa s: school. 7?x s: name?name. 8 FILTER regex (? name, "ˆH"). 9 } 7

8 The result of the query is listed in listing 2.7. Listing 2.7 : Response for the previous query name 3 ================================================= 4 " Hochschule fuer Technik Rapperswil " 5 " Hochschule fuer Technik und Wirtschaft Chur " If the subject stays the same as such is the case in listing 2.6 rows 6-7 there is an abbreviated format as shown in listing 2.8. Note that the dot is changed into an semicolon. This is called a predicate object list. Listing 2.8 : Partial alternative to previous query 1? x s: isa s: school ; 2 s: name? name. 3 FILTER regex (? name, "ˆH"). There are also object lists meaning the subject and predicate stay the same. The objects in question would be written with a comma in between. The FILTER clause is comparable to the LIKE function in SQL queries. Multiple statements which all have to be true are concatenated with the word AND. In SQL the query of listing 2.6 would look like in listing 2.9. Listing 2.9 : SQL query with LIKE and AND 1 SELECT school FROM fhoaddressbook 2 WHERE 3 ( school LIKE "H%") AND (type == " school "); 2.3. Query a SPARQL Endpoint over HTTP If an organisation wants to make its RDF store publicly available this can be done via a SPARQL endpoint. This is an URL which a SPARQL client can access to get the wanted data. The webservice which serves the endpoint forwards the SPARQL query to the RDF store driver and provides the answer. The SPARQL protocol is based on the HTTP protocol which means that queries are executed with the HTTP GET and POST commands. As [...] only alphanumerics, the special characters $-.+!* (),, and reserved characters used for their reserved purposes may be used unencoded within a URL. [...] [22] and a SPARQL query contains a lot of special characters not specified here (like spaces and line breaks) they have to be encoded. The query URL from listing 2.4 against the SPARQL endpoint would be like in listing Listing 2.10 : Encoded URL for SPARQL query 1 http :// / sparql /? query= PREFIX+s%3A+%3 Chttp %3A%2F%2 Ffho.ch %2 Fxmlns %2 Fschools %23%3E+%0D%0A%0D%0 ASELECT +%3 Fschool +%3 Fnumber %0D%0 AWHERE %0D%0A%7B+%3 Fschool +s%3 AphoneNo +%3 Fnumber +.+%7 D 8

9 3. Existing Benchmarks A good overview of existing RDF Store and/or SPARQL benchmarks is found in [21]. There are various benchmark tests available. They include: Berlin SPARQL Benchmark (BSBM) defines a suite of benchmarks for comparing the performance of these systems across architectures. The benchmark is built around an e-commerce use case in which a set of products is offered by different vendors and consumers have posted reviews about products. The benchmark query mix illustrates the search and navigation pattern of a consumer looking for a product. [15] The Explore Use Case of this benchmark will be used for our own benchmark tests. Lehigh University Benchmark (LUBM) is developed to facilitate the evaluation of Semantic Web repositories in a standard and systematic way. The benchmark is intended to evaluate the performance of those repositories with respect to extensional queries over a large data set that commits to a single realistic ontology. It consists of a university domain ontology, customizable and repeatable synthetic data, a set of test queries, and several performance metrics. [27] 3.1. Dataset Specification The specification of the used dataset is found in [3]. The class diagram [6, page 4] of the used dataset is shown in figure 3.1. The product is the central class which can have up to 22 product features and is of one product type. Per product there are up to 32 possible offers from different vendors. People who bought the product can write reviews, a maximum of 16 reviews per product is possible. Figure 3.1.: Class diagram of the dataset 9

10 3.2. Explore Use Case - Specifications The original document about the specification of the BSBM Explore Use Case can be found in [4]. One benchmark run consists of a query mix with 12 different queries where queries can be used multiple times. The possible queries are as follows: Query 1: A consumer is looking for a product and has a general idea about what he wants. Query 2: The consumer wants to view basic information about products found by query 1. Query 3: After looking at information about some products, the consumer has a more specific idea what he wants. Therefore, he asks for products having several features but not having a specific other feature. Query 4: After looking at information about some products, the consumer has a more specific idea what he wants. Therefore, he asks for products matching either one set of features or another set. Query 5: The consumer has found a product that fulfills his requirements. He now wants to find products with similar features. Query 7: The consumer has found a product which fulfills his requirements. Now he wants in-depth information about this product including offers from German vendors and product reviews if available. Query 8: The consumer wants to read the 20 most recent English language reviews about a specific product. Query 9: In order to decide whether to trust a review, the consumer asks for any kind of information that is available about the reviewer. Query 10: The consumer wants to buy from a vendor in the United States who is able to deliver within 3 days and is looking for the cheapest offer that fulfills these requirements. Query 11: After deciding on a specific offer, the consumer wants to get all information that is directly related to this offer. Query 12: After deciding on a specific offer, the consumer wants to save information about this offer on his local machine using a different RDF schema. The query mix runs the following sequence: 1, 2, 2, 3, 2, 2, 4, 2, 2, 5, 7, 7, 5, 7, 7, 8, 9, 9, 8, 9, 9, 10, 10, 11, 12. For the Use Case this means that a customer looks for a overview of products that he is interested in (query 1 executed once) and then basic information of two found products are looked up (query 2 executed twice). Query number 6 is not used in the query mix anymore. One value (called a metric) which is returned when running a BSBM test is the so called QMpH (Query Mixes per Hour) which calculates how many query mixes could be executed within an hour. Another metric which is dependent from the QMpH is the CQET (Composite Query Execution Time) which measures the average runtime of a query mix. We will be using this metric throughout the following benchmark comparisons and also with the own benchmark tests as the diagrams in the next chapter show how long a query mix takes over time. 10

11 3.3. Benchmarking Results Database Systems in Question As there are over 200 different tools for RDF storage [20] plus various graph and relational database systems supporting RDF it is a challenge to select only a few solutions for benchmark comparisons. According to the Linked Open Data Cloud [14] a lot of Linked Open Data databases are connected to DBPedia, a project to provide the data from Wikipedia as Linked Data over SPARQL. The database in the background serves over 240 million triples as seen in the Linked Data Sets available as RDF Dumps overview [7]. This means that their database must offer a high performance. According to [8] the used database is Openlink Virtuoso (Virtuoso), a multipurpose database written in C [17] so we will use this in our benchmark comparison. Two other triplestores which are found often in existing benchmarking tests are the Apache Jena framework (Jena) which is written in Java [9] and the OpenRDF Sesame framework (Sesame) which uses an existing Apache Tomcat web server as SPARQL endpoint [2]. In addition another C written store called 4store was chosen as it also appears in some existing benchmark results Existing Comparisons The original comparison is available at [5]. These benchmark tests were made with the Explore Use Case of the BSBM Version 3 (current version is 3.1). The RDF stores which were tested and which are of interest in this paper are 4store version 1.1.2, TDB (Jena) version and Virtuoso version 7.0. Table 3.1 shows the loading times of the datasets 100M (100 million triples) and 200M on the three database systems. With both datasets 4store shows the shortest loading times. 100M 200M Jena 1:14:48 2:45:13 Virtuoso 1:49:26 3:59:38 4store 26:42 1:12:04 Table 3.1.: Loading times of the existing benchmark In table 3.2 the average query mix execution time (CQET) is shown (in milliseconds). Virtuoso had the best performance on both datasets but on the bigger dataset 4store had almost the same good performance. 100M 200M Jena Virtuoso store Table 3.2.: CQET of the datasets (existing benchmark) 11

12 4. Own Benchmarks 4.1. Benchmark Platform For our own benchmark tests we assume and define the following: The BSBM data generator and test drivers are chosen to test the different database systems All tests are performed with the same hardware and operating system: Platform: Lenovo Thinkpad W530 Processor: Intel i7 Quad Core 2.60 GHz Memory: 8 GB, 1600 MHz Storage 1: 1x 500 GB HDD, rpm Storage 2: 1x 120 GB SSD OS: Ubuntu GNU/Linux bit We are aware that this configuration is not representative for todays web and application servers Software Configurations This describes the version of the used database systems and which configurations were made (Apache) Jena The version of the Jena framework is The HTTP endpoint Fuseki is at version As Jena runs with Java we called the Java executable with the option -Xmx7168m which allocates a maximum of 7GB RAM memory to the Java VM. The used OpenJDK JRE is version Update 25, 64 bit (OpenRDF) Sesame Sesame is at version at the time of writing. It runs on a Apache Tomcat server (version ) which itself runs on a Java VM. As for Jena the Java VM version is Update 25, 64 bit. Tomcat was also started with 7GB heap space (Openlink) Virtuoso Opensource Virtuoso Opensource was installed in version There were no additional configurations made. 12

13 store 4store relies on various libraries which are found in listing A.10 in appendix A. These were installed with the Ubuntu package manager APT. 4store itself is at version Datasets Five datasets were generated with the BSBM data generator each in Turtle and in N-Triple representations. The datasets are called 1M (one million triples), 5M, 25M, 50M and 100M. The Turtle files were imported on all database systems except 4store where the N-Triple files were used. This was necessary because the 4store import tool returned an error on the Turtle file which had 25 million triples or more Results A total of 32 tests were made. Four different database systems (Apache Jena, Sesame, Openlink Virtuoso, 4store) were tested against three datasets (1M, 5M, 25M) on two different storage devices (HDD, SSD). In addition the 50M and 100M datasets were tested against all systems but only on an SSD Loading Times The loading times for all the tests are shown in table 4.1 (in min:sec). In figure 4.1 the loading times are shown subject to the dataset size. 1M HDD 5M HDD 25M HDD 1M SSD 5M SSD 25M SSD 50M SSD 100M SSD Jena 00:35 02:28 14:02 00:29 02:18 11:51 27:43 58:19 Sesame 00:23 02:38 40:36 00:23 02:02 11:34 25:95 65:26 Virtuoso 00:05 00:23 03:59 00:05 00:23 02:21 06:45 12:49 4store 00:05 00:28 07:41 00:05 00:24 03:30 07:47 19:06 Table 4.1.: Loading times of the own benchmark With the tested datasets the loading times on a SSD were increasing proportional to the dataset. On a HDD this was also true except from Sesame. On both storage devices the two Java based stores Jena and Sesame had longer loading times than the other two database systems Results In table 4.2 the average query mix execution time (CQET) is shown (in milliseconds). On a HDD 4store shows the best performance with the generated datasets. On the other hand on a SSD the average executions times vary heavily between the used database systems. For the small datasets Jena is the best choice whereas for larger datasets 4store would be better. 13

14 Loading times HDD Jena Sesame Virtuoso 4store Jena Sesame Virtuoso 4store Loading times SSD seconds dataset size dataset size Figure 4.1.: Loading times of the own benchmark 1M HDD 5M HDD 25M HDD 1M SSD 5M SSD 25M SSD 50M SSD 100M SSD Jena Sesame Virtuoso store Table 4.2.: CQET of the datasets (own benchmark) The figures 4.2 to 4.4 show the running times of the query mix against the four database management systems on a HDD and a SSD. Some datapoints at the beginning of the plots are not visible because if they were shown the other (more interesting) datapoints would have vanished. The missing datapoints are mentioned at each figure. The figures show the performance in query mix execution time of datasets over time. The first 50 runs up to run number 0 were executed to warm up the database. The 1M dataset consists of exactly one million triples. The dataset has the following properties: 151 Product Types Product Features 61 Producers and Products 30 Vendors and Offers 4 Rating Sites with Persons and Reviews In figure 4.2 the first query mix run for Sesame on a HDD took 8.8 seconds. The rest of the datapoints are visible. The plot shows that all the stores converge during the 50 warmup runs. This means that after these 50 initial runs the query times per query mix do not change significantly anymore. The 5M dataset consists of exactly five million triples. The dataset has the following properties: 329 Product Types Product Features 291 Producers and Products 143 Vendors and Offers 14

15 15 Rating Sites with Persons and Reviews In figure 4.3 the first query mix run for Sesame on a HDD took 16.8 seconds. The rest of the datapoints are visible. On the HDD for Sesame the execution times keep sinking until run number 200. Query times for 1M dataset on a HDD Query times for 1M dataset on a SSD Jena Sesame Virtuoso 4store Jena Sesame Virtuoso 4store milliseconds run number run number Figure 4.2.: Results for 1M dataset Query times for 5M dataset on a HDD Jena Sesame Virtuoso 4store Query times for 5M dataset on a SSD Jena Sesame Virtuoso 4store milliseconds run number run number Figure 4.3.: Results for 5M dataset 15

16 The 25M dataset consists of triples. The dataset has the following properties: 731 Product Types Product Features Producers and Products 725 Vendors and Offers 73 Rating Sites with Persons and Reviews In figure 4.4 the first query mix run for Sesame on a HDD took 56.8 seconds. The plot for Virtuoso starts at 20.2 seconds. The rest of the datapoints are visible. With this dataset Jena and Sesame need a longer time to converge on a HDD. After an initial peak at beginning 4store and especially Virtuoso have very little executions times (around 400 milliseconds). 15 Query times for 25M dataset on a HDD Jena Sesame Virtuoso 4store 15 Query times for 25M dataset on a SSD Jena Sesame Virtuoso 4store seconds run number run number Figure 4.4.: Results for 25M dataset 16

17 The 50M dataset consists of triples. The dataset has the following properties: Product Types Product Features Producers and Products Vendors and Offers 141 Rating Sites with Persons and Reviews The 100M dataset consists of triples. The dataset has the following properties: Product Types Product Features Producers and Products Vendors and Offers 293 Rating Sites with Persons and Reviews In figure 4.5 the first query mix run for Virtuoso on the 50M dataset took 16.1 seconds. On the plot for on the 100M starts at 20.3 seconds. The rest of the datapoints are visible. On both visible plots the curves for Sesame are very jittery. The curves of the other database systems are more or less constant. Something interesting is visible at the very end of the 100M plot for the Virtuoso curve as the execution times start to increase again after run 450. Although this is not visualized at the same time the CPU load on the server machine increased rapidly. Even after the test runs were finished the CPU load was still very high. An explanation for this could not be found. 15 Query times for 50M dataset on a SSD Jena Sesame Virtuoso 4store 15 Query times for 100M dataset on a SSD Jena Sesame Virtuoso 4store seconds run number run number Figure 4.5.: Results for 50M and 100M dataset 17

18 5. Conclusion and Outlook The installation and configuration of the different systems were more or less well documented. The datasets had to be created in Turtle and N-Triple serializations because the 4store import tool had problems with larger datasets in the Turtle format. The loading of the datasets was made with the respective loading tools where Virtuoso shows the best performance over all possible datasets and storage devices. The larger datasets were not loaded on the HDD because on Sesame the loading times increased significantly compared to the loading times on the other stores. An explanation for the unsteadiness of certain database systems on larger datasets (especially for Sesame and Jena) was not found. As the test server was only setup once and the operating system was not reinstalled from scratch after a test run this might be a possible reason as the smaller datasets were loaded at the beginning of the test series. To get better results the individual tests should have run multiple times and the average would have been taken. Another improvement on the own benchmark would be the usage of other datasets as the data generated by BSBM are synthetic. A dataset which is derived from the real world would be the one from DBpedia. Furthermore the dataset should be applicable to graph and relation database systems. Acknowledgement At this point I would like to thank all the people involved in this project. This includes Prof. Martin Studer and Beatrix Fehr for proofreading. 18

19 A. Installation Guides As mentioned in the report the installations were performed on the same hardware. The operating system Ubuntu GNU/Linux Server (64 bit) was installed once and after testing one database system the needed components were removed. During the installation the OpenSSH-Server package was chosen to simplify the installation process. Furthermore after initial booting the commands from listing A.1 were used to update the system to the latest software releases. Listing A.1 : Commands to update the installed Linux installation 1 apt - get update 2 apt - get upgrade 3 apt -get dist - upgrade 4 reboot The server was assigned an IP address of /24. Installation of Jena As the Jena components are written in Java these packages have to be installed. This is done by typing the command of listing A.2. Listing A.2 : Installation of Java 1 apt - get install openjdk -7- jre - headless The tarballs including the binaries of Apache Jena (APIs, SPARQL engine, RDF database) and Fuseki (SPARQL HTTP Endpoint) were downloaded from the download server ( dist/jena/binaries/), extracted and moved to the desired target directory as seen in listing A.3 Listing A.3 : Download of Apache Jena 1 cd /usr/src/ 2 wget http :// www. apache.org/ dist /jena / binaries /apache -jena tar.gz 3 wget http :// www. apache.org/ dist /jena / binaries /jena -fuseki distribution.tar.gz 4 5 tar xzf apache - jena tar. gz 6 tar xzf jena -fuseki distribution.tar.gz 7 8 mv apache -jena / /usr/ local/apache - jena / 9 mv jena -fuseki / /usr/ local/apache - jena /fuseki / After these commands all the Apache Jena components (including the Fuseki Server) are installed under the directory /usr/local/apache-jena/. To run the Fuseki server invoke the command from 19

20 listing A.4 to start the server with its dataset in the Dataset subdirectory. Now we already have our SPARQL server running. Listing A.4 : Start of the Fuseki server 1 cd /usr/ local/apache -jena / fuseki / 2 mkdir Datasets 3./ fuseki - server -- update -- loc = Datasets / ds & The SPARQL endpoint for this server would be The Turtle dataset can be loaded into the database with tdbloader2 as shown in listing A.5. Listing A.5 : Bulk load into Jena 1 cd /usr/ local/apache -jena 2 bin / tdbloader2 -- loc fuseki/ Datasets / dataset. nt Installation of Sesame OpenRDF Sesame is also dependent on Java like Apache Jena. Furthermore it uses Tomcat as HTTP server. We install Sesame as shown in listing A.6. Listing A.6 : Installation of Sesame 1 apt - get install tomcat7 2 cd /usr/src/ 3 wget http :// sourceforge. net/ projects / sesame / files/ Sesame %202/2.7.9/ openrdf - sesame sdk.tar.gz 4 tar xzf openrdf - sesame sdk.tar.gz 5 mv openrdf -sesame /usr/ local/ sesame/ To allocate more memory for Tomcat we will edit the configuration file as in listing A.7. Listing A.7 : Configuration of Tomcat 1 # in /etc/ default / tomcat7 : 2 # JAVA_OPTS ="- Djava.awt. headless =true -Xmx7168m -XX :+ UseConcMarkSweepGC " (was: 128m, no Xms to provide Tomcat more RAM resources ) Finally the war (Web Archive) files are copied into the respective folder and the needed folders for Sesame are created. If not done so there will be an error message saying the folder does not exist on first startup. Listing A.8 shows the necessary commands. Listing A.8 : Copy Sesame Tomcat Webapps 1 cp /usr/ local/ sesame /war /* /var /lib/ tomcat7 / webapps / 2 3 cd /usr/ share/ tomcat7 4 mkdir. aduna 5 chown tomcat7 : tomcat7. aduna/ Now via a webbrowser the URL is called. On this webpage we create a new repository with the name ds. As type we choose Native Java Store. The indexes which should be created are the same ones which were built with Jena automatically: spoc,posc,ospc. 20

21 Installation of Virtuoso Openlink Virtuoso could be installed directly from Ubuntu s repository. But as this version is older we build Virtuoso from source as in listing A.9. Listing A.9 : Installation of Openlink Virtuoso 1 apt - get install build - essential libssl - dev 2 cd /usr/src/ 3 wget http :// sourceforge. net/ projects / virtuoso / files/ virtuoso /7.0.0/ virtuoso - opensource tar. gz 4 tar xzf virtuoso - opensource tar. gz 5 cd virtuoso - opensource / configure 7 make 8 make install 9 cd /usr/ local/ virtuoso - opensource / 10 bin /virtuoso -t -c var/lib/ virtuoso /db/ virtuoso.ini Installation of 4store 4store needs some more libraries which can be installed with the Ubuntu package manager. In listing A.10 is shown the installation procedure. Listing A.10 : Installation of 4store 1 apt - get install build - essential pkg - config libglib2.0- dev libxml2 - dev libraptor2 - dev librasqal3 - dev uuid - dev libncurses5 - dev libreadline6 - dev 2 cd /usr/src 3 wget http ://4 store.org/ download /4 store -v tar.gz 4 tar xzf 4store -v tar.gz 5 cd 4store -v / configure 7 make 8 make install Next the store is setup with the commands from listing A.11. Listing A.11 : Setting up a store on 4store 1 4s- backend - setup htwchur 2 4s- backend htwchur 3 4s- httpd -p 8000 htwchur 21

22 Bibliography [1] Aduna. openrdf Home. URL: (last access: 10/27/2013). [2] Aduna. Server software installation. URL: (last access: 12/11/2013). [3] Freie Universität Berlin. Berlin SPARQL Benchmark - Dataset Specification. Nov. 29, URL: (last access: 12/11/2013). [4] Freie Universität Berlin. Berlin SPARQL Benchmark - Explore Use Case. Nov. 29, URL: (last access: 12/16/2013). [5] Freie Universität Berlin. Berlin SPARQL Benchmark Results - 02/22/2011. Feb. 22, URL: (last access: 12/11/2013). [6] Christian Bizer and Andreas Schultz. The Berlin SPARQL Benchmark URL: (last access: 12/16/2013). [7] DataSetRDF Dumps - W3C Wiki. Jan. 31, URL: (last access: 11/06/2013). [8] DBpedia.org. wiki.dbpedia.org: DBpedia Live. May 16, URL: (last access: 11/06/2013). [9] The Apache Software Foundation. Apache Jena - An Introduction to RDF and the Jena RDF API. URL: (last access: 12/11/2013). [10] The Apache Software Foundation. Apache Jena - TDB. URL: (last access: 10/27/2013). [11] The Apache Software Foundation. SDB - persistent triple stores using relational databases URL: (last access: 10/09/2013). 22

23 [12] triagens GmbH. ArangoDB - The universal free and open source nosql database. URL: (last access: 10/27/2013). [13] IBM. RDF application development for IBM data servers. URL: doc/c html (last access: 10/09/2013). [14] lod-cloud.net. The Linked Open Data cloud. Sept. 19, URL: (last access: 10/09/2013). [15] Universität Mannheim. Berlin SPARQL Benchmark. Apr. 26, URL: (last access: 11/14/2013). [16] OpenAnzo.org. openanzo - Introduction. URL: (last access: 10/09/2013). [17] Openlink Virtuoso Sourceforge Project Page. URL: (last access: 12/11/2013). [18] Oracle. Oracle Spatial and Graph URL: fo.pdf (last access: 10/09/2013). [19] RDF 1.1 Concepts and Abstract Syntax. July 23, URL: (last access: 10/09/2013). [20] RDF - Semantic Web Standards. Mar. 22, URL: (last access: 12/16/2013). [21] RDF Store Benchmarking - W3C Wiki. July 8, URL: (last access: 11/05/2013). [22] Request for Comments: 1738: Uniform Resource Locators (URL) URL: (last access: 12/16/2013). [23] Semantic Web - W3C URL: (last access: 09/26/2013). [24] SPARQL 1.1 Query Language. Mar. 21, URL: (last access: 11/07/2013). 23

24 [25] Neo Technology. Neo4j - The World s Leading Graph Database. URL: (last access: 10/27/2013). [26] Turtle. Feb. 19, URL: (last access: 09/26/2013). [27] Lehigh University. Lehigh University Benchmark (LUBM). URL: (last access: 11/14/2013). 24

25 List of Tables 3.1. Loading times of the existing benchmark CQET of the datasets (existing benchmark) Loading times of the own benchmark CQET of the datasets (own benchmark)

26 List of Figures 1.1. RDF triple Relationships in a graph Class diagram of the dataset Loading times of the own benchmark Results for 1M dataset Results for 5M dataset Results for 25M dataset Results for 50M and 100M dataset