dataesr/scientific-paragraphs-categorization huggingface dataset:
Handling large knowledge bases of information from different domains such as the World Wide Web is a complex problem addressed in the Resource Description Framework (RDF) by adding semantic meaning to the data itself. The amount of linked data has brought with it a number of specialized databases that are capable of storing and processing RDF data, called RDF stores. We explore the RDF store landscape with the aim of finding an RDF store that sufficiently meets the storage needs of an enhanced living environment, more concretely the requirements of a Smart Space platform aimed at running on a cluster set up of low-power hardware that can be run locally entirely at home with the purpose of logging data for a reactive assistive system involving, e. g. , activity recognition or domotics. We present a literature analysis of RDF stores and identify promising candidates for implementation of consumer Smart Spaces.
Related Work: RDF Stores RDF provides possibilities in knowledge processing that are not possible in other database models. The new way of thinking about information in these semantic technologies also presents their own challenges and new sets of tools. Even the most fundamental functionality of providing efficient storage and retrieval of information in an RDF data model is an issue that has created a new breed of information storage systems called the RDF stores. Besides providing storage and retrieval of information in the RDF format, RDF stores often consist of software solutions for a number of functionalities related to semantic technologies and information processing. The RDF data model does not define the physical layout of the data itself, but instead it defines how the information should be presented to the user or the application when it is accessed from the RDF store.
This abstraction of information has resulted in large differences in the underlying data structures used for different RDF store. The data structures used for RDF stores range from off-the-shelf relational databases  [15, 41]  to state-of-the-art advanced indexing schemes, which are specifically designed for the RDF data model  [51]. As the underlying data structures greatly affect both the performance and the scalability of the storage system, this Section first presents the concepts that have shaped modern RDF stores. This presentation is then followed by a brief runthrough of some of the most influential RDF stores. The Section concludes with a discussion of RDF store benchmarking software. The data storage techniques in RDF stores range from mapping the RDF data model onto existing DBMS to custom DBMS where the data structures used are designed specifically for the RDF data model.
Peer-2-peer RDF stores are discussed in length in  [35]. Defining an exact taxonomy of RDF stores, as presented in Fig. 1 , and classifying each RDF store can be considered somewhat misleading as RDF stores can incorporate a combination of storage techniques. Some RDF store vendors do not publicize the details for the underlying data structure, and this makes the task even harder. Nevertheless, it is important for the database system administrator to be aware of the different techniques used in the available RDF stores and how they affect both the performance and the scalability of the RDF stores. Below follows short descriptions of the main techniques used in RDF stores as presented in Fig. 1. [34]  Triple Table. The triple table can be considered the most straight forward way of storing RDF triples.
In the study, Filali et al. identify the decentralization, the scalability, and the fault-tolerance provided by peer-to-peer systems as the leading factors that motivated the design of the RDF data stores that were covered. RDF storage solutions capable of performing queries on large RDF datasets mapped onto distributed file systems and queried using a MapReduce engine have been presented in a number of research papers. SHARD  [56] , which was one of the earliest peer-to-peer RDF stores presented, uses Hadoop and the HDFS. The RDF graph is grouped into SHARDs that are directly mapped to the HDFS file system. Queries are evaluated by performing triple patterns match MapReduce operations on the SHARDs in a sequential order. Another Hadoop based RDF query system is CliqueSquare  [36] , which reduces the network traffic by exploiting the built-in replication in the HDFS and a clique-based algorithm to find connected subgraphs to speed up query processing.
RDF Frameworks In addition to individual RDF stores such as BitMat  [21] , MonetDB  [63] , TriAD  [38] , AdPart  [40] , H2RDF  [55] , there are a number of RDF-centric frameworks that provide interfaces to third party RDF storage implementations or implement their own internal RDF storage solutions. A listing of the major RDF frameworks with an accompanying description is presented below. Apache Jena  [2]  RDF framework originated from the Hewlett Packard Labs and includes a whole range of RDF specific tools from parsers, RDF stores, reasoners and query systems. The libraries support both internal RDF stores and provide libraries to access a number of independent RDF stores. The libraries are Java-based, but bindings for the most common languages are provided. Developed by Aduna, the OpenRDF Sesame framework  [6]  is similar to the Apache Jena framework in that it provides a de-facto standard tool set for processing RDF data in Java APIs.
Access to most modern RDF stores is provided through the SAIL API part of the framework. The framework has been developed for over ten years and is used by companies in several different industries. The OWLIM platform  [24]  is a high-performance Java-based semantic repository that is packaged as an implementation of Sesame's SAIL API. Besides serving as an interface to the OWLIM RDF store, the platform also supports reasoning for RDFS, OWL Horst, OWL 2 QL and OWL 2 RL semantics. Developed by Dave Beckett, the Redland RDF libraries  [12] , written in C, provide tools for parsing, querying and storage on RDF data. The Redland storage library supports a limited number of RDF stores, the default being a custom storage solution based on the Oracles Berkeley DB database. Besides the C API, the libraries have bindings to Ruby, PHP, Python and Perl.
Individual RDF Stores Since the first RDF stores appeared in the early 2000s, a number of surveys and evaluations have been presented that both evaluate the state of RDF stores and discuss the techniques used. An incomplete list of recent studies include: an evaluation of RDF database solutions from 2009  [64] , a report over RDF stores done for the European project 2011  [44] , a discussion of interesting RDF stores in a literature survey of RDF storage approaches  [34]. The RDF stores covered in the studies vary largely based on the aim of the studies. RDF stores briefly covered in this chapter were included on the basis of having either shaped the evolution of RDF stores or being considered a major player in the current state of RDF stores. Below follows a short introduction to these RDF stores.
By doing so, the indexing structure sacrifices insertion speed for better query performance, as all six indices must be calculated in a specific order when inserting new triples. Huffman encoding is used in the data blocks in order to save storage space. The entire lexical value of the triple is indexed in order to speed up the queries that contain FILTER operations. Virtuoso. Virtuoso is defined as "a general purpose relational/federated database system and application platform"  [32]  developed by OpenLink Software, and can be considered a full-featured RDF solution with interfaces for the Jena framework, the Sesame and Redland libraries, a limited OWL inference engine, full-text search, relational data analytics and Multi Version Concurrency Control (MVCC) for transaction handling. Virtuoso was originally a relational database that was later extended in order to support RDF data.
The software first used a row-wise transaction scheme  [33] , but the latest version of the software, Virtuoso 7, uses column-wise compressed storage with a vectored execution  [31]. The software is provided under both an open-source license for single machines and a commercial license for software that supports federated (distributed) storage and other additional functionality. Virtuoso uses a quadruplet structure for modelling RDF triples and by doing so extends the subject S, predicate P and object O with a G graph node column representing the graph IRI ID. The earlier versions of Virtuoso used only two covering indices, <GSPO> and <OGPS >, for each statement. The index structure was motivated by the assumption that most triples are queried using either the subject or the object. Virtuoso 6 and 7 extended the covering indices to include the optional covering indices <PSOG> and <POGS > as well as the additional indices <OP >, <SP > and <GS > for distinct projections.
All SPARQL queries in Virtuoso are transformed into SQL statements that are then handled inside Virtuoso's SQL query engine in a similar fashion as Oracle's RDF Match table function (see Sect. 2. 3). The latest version of the software is marketed as scaling up to datasets over a trillion triples. 4store. 4store  [42]  is an open-source RDF store that was originally developed by Garlik in order to be used in the company's personal data protection products. As Garlik moved on to their new clustered RDF-store, 5store, 4store has been maintained by the 4store user community. Even if 4store is labelled as the logical successor of 3store  [41] , it shares very little code with its predecessor. The main feature that has remained is the mapping of RDF resources as integers. The data structure used in 4store resembles the property table used in Jena SDB rather than the triple table used in 3store.
4store does possess some clear deficiencies compared to other leading RDF stores. The major deficiencies are an incomplete SPARQL 1. 1 support, and a lack of both transaction handling and built-in inference engines. However, a separate version of 4store that supports backward inferencing on a minimal RDFS set  [60]  has been developed, but is yet to be included in the official 4store release. SYSTAP, BigData. BigData is a RDF platform targeting the Semantic Web and it has been developed by Systap LLC since 2006. BigData was initially released in a single node version that is currently named journal. BigData has later been extended to a clustered version of the software called federation. The journal version is in principal a main memory RDF store, while the federation version uses a "dynamic horizontal partitioning architecture" that is inspired by BigTable  [27].
The change is motivated by the significantly better performance offered by keeping the RDF graph in the main memory compared to the initial disk based system, for which further development has been discontinued. Another of the selling points for the Jena TDB RDF storage solution is the extensive tools provided with the Jena framework. Allegrograph. Developed by Franz Inc, Allegrograph  [1]  is a commercial grade graph database for RDF data, containing a range of RDF tools. Allegrograph represents triples in assertions and each triple is mapped into a subject, a predicate, an object, a graph and a triple-id assertion. The triple-id is mainly used for graph extension when performing direct graph reification for RDF graphs. The system uses a combination of dictionaries, seven different indices and a cache handling system in order to provide the storage and retrieval of the RDF data.
Knowledge bases in Allegrograph can be queried using both the SPARQL language and a specialized Prolog instruction set. The system supports full RDFS and partial OWL reasoning through its RacerPro  [39]  software, which is built on tableau calculus. Rather unique features found in Allegrograph are the possibilities for doing geospatial inferencing as well as temporal reasoning. Federation and ACID compliant transactions are also supported 1. The system can be accessed by the number of programming languages or through the Jena platform. [24]  is a family of semantic repositories that provides storage, inference and novel data-access features for RDF data. The software comes in three different versions: a main memory RDF store for datasets up to 100 million statements called OWLIM-Lite (previously SwiftOWLIM), a file system based RDF store for larger data volumes called OWLIM-SE (previously BigOWLIM) and a replication cluster RDF store called OWLIM-Enterprise.
Version 11g of the Oracle RDBMS that was released in 2007 provided native RDF storage that scales up to billions of triples. Also included in the release of version 11g was OWL inference and the integration to prominent RDF technologies such as Jena, Sesame and Protégé  [22]. The RDF graphs in Oracle 11g are modelled using relational tables and views that are optimized for semantic data. RDF graphs can be accessed in the system by using mixed SQL and SPARQL queries. Nevertheless, all SPARQL queries are translated in runtime into table/join structures that are executed by the underlying DBMS  2. A separate software product provided by the Oracle Corporation that has RDF support is the Oracle NoSQL database  [9]. The underlying storage is based on the key-value store, Oracle Java Berkeley DB (previously SleepyCat DB).
The first version of the RDF-3X software was mainly optimized for retrieving information from RDF graphs. Later versions of the software include a compact differential indices and an integrated versioning, which enables the deferral of changes to the RDF graph that can be merged with the main RDF graph in batch operations. The additions enabled online updates to the knowledge base and provided time travel queries that offer both flexibility and consistency through a transaction concurrency control system  [52]. The index structure in combination with the query optimisations used give RDF-3X a good performance in many types of queries, although it has been noted that the performance of RDF-3X degrades for unbound queries and queries where the selectivity factor is low  [52]. Trinity. RDF. Trinity.
RDF  [67]  is a main-memory RDF graph database based on the Trinity  [62]  distributed graph system. The system was designed to handle large Web scale data. Trinity. RDF introduces graph database specific features that are not available in other RDF stores like random walks and reachability that can be used for data analytics and data mining purposes. The defining feature for Trinity. RDF is that queries are performed using graph exploration instead of relational joins common in many other RDF stores. This graph exploration is claimed to provide especially good performance compared to current solutions for graph walking queries, which, at the time of writing, shows superior performance compared to state-of-the-art systems in a number queries.
RDF Store Benchmarks Since the introduction of RDF stores, a number of benchmark suites (  [19, 25, 37] , Waterloo SPARQL Diversity Test Suite (WatDiv)  [20] , Bio2RDF  [26] , Yago2 and 3  [46] ) have been presented in order to measure RDF stores. The methods used in the benchmark differ somewhat from each other, but most of the benchmarks include at least the measurements load time for inserting datasets to the RDF store and the measurements on query performance using either synthetic or real world datasets. The accuracy of how well the benchmark measures real world performance has been questioned  [30] , and therefore, the benchmarks are included in this chapter as they provide a general impression of both the scalability and performance of RDF stores. One of the earliest RDF benchmarks was the Leigh University Benchmark (LUBM)  [37]  released in 2005.
The benchmark aimed to evaluate the reasoning capabilities and the query performance of RDF storage solutions by using OWL knowledge bases. The datasets used in the benchmarks are generated using an ontology dataset generator, which replicates university setting with triple data relating to professors, students and courses. The test suite provides 14 evaluation queries that can be used in order to evaluate the semantic inference and the reasoning capabilities of RDF stores while at the same time providing execution times for the aforementioned queries. The LUBM group does not provide updated experimental results for RDF stores, but the benchmarking suite has been used by several RDF store developers to compare the performance of their RDF stores against other RDF stores. Another benchmark suite using synthetic data is the Berlin SPARQL Benchmark (BSBM)  [25]  that was first presented in 2009.
Like LUBM, BSBM measures RDF store query speed using a number of SPARQL queries, but the evaluation is focused on explore and update scenarios in a business intelligence use case. The test suite includes multi-client benchmarks that are performed through a HTTP SPARQL front end in the RDF store. The SPARQL Performance Benchmark (SP 2 Bench)  [61]  introduced in 2009 uses SPARQL construct operator constellations and broader data access patterns in order to evaluate RDF stores in non-application specific use cases. The SP 2 Bench suit uses artificially generated datasets related to publications, with a benchmark end goal to cover a large range of use cases. The SP 2 Bench suite uses a total of 17 SPARQL queries in order to benchmark RDF store performance. DBpedia SPARQL Benchmark  [49]  is a project that aims to provide a generic SPARQL benchmark creation methodology by using real world datasets.
In 2011  [49] , Morandi et al. present methods for how they extracted sample data subsets from the DBpedia dataset, and how they from the resulting dataset derive 25 unique SPARQL queries that can be used in order to benchmark the performance of RDF stores. A table of the different RDF benchmark suites experiments is presented below. From the table, one can note that there are several orders of magnitude differences between the dataset sizes in the different benchmark experiments. The BSBM testing suite experiments are the largest in scale and can therefore be considered the most extensive. In addition to the experiment done by the benchmark creators mentioned above, both individual RDF store developers and independent sources have performed experiments using the different benchmarking suites.
For the evaluation, the feasibility of a centralized clustered in-home SIB box, a hardware prototype (hereafter referenced as prototype) that consists of two ODROID U2 [5] development boards. The boards are based on the Samsung Exynos 5 32-bit ARM architecture chipsets with each board equipped with 2 GB of DDR2 SDRAM and an 8 GB SDCARD memory modules. To be considered in the evaluation, the proposed RDF stores should be able to run on the prototype hardware. Defining requirements for the RDF stores for the Smart-M3 in this evaluation relies on rough estimates, as no Smart-M3 environment has been created that could give an accurate representation of the storage needs of a large scale smart space environment. As discussed in Sect. 2. 3, the properties of the RDF dataset that are used and the type of queries that are normally performed in a smart space setting will affect the performance of the RDF-store.
Additionally, the size of the datasets that the underlying RDF store can handle will limit the scalability of the system. To know how the above mentioned factors affect the functionality of the Smart-M3 system, it would be preferable to know in advance what kind of data is to be used in the Smart-M3 5. The defining factor of many of the use case scenarios is that the system will need to handle frequent small inserts and deletions of triples. For updates of the knowledge base, this works well in RDF stores that do not need to perform expensive index updates every time the knowledge base has been updated. The frequent updates were identified as a possible concern for the index-based RDF solution for which batched triple inserts and removes are preferred. For evaluation purposes, it was decided that the RDF stores should at a bare minimum be able to handle an arbitrarily chosen number of ten millions of triples, based on what can be considered to be a reasonable number of triples that a smart space should be able to serve.
The criteria for the RDF stores in this evaluation are that they should be able to keep loading this number of triples, while at the same time they should be able to perform simple queries within the millisecond range. At the outlook the evaluation, there were no hard criteria on how fast queries should be handled in a smart space. As is observable from RDF store benchmarks, it is not unreasonable to expect a modern RDF store to be able to execute simple SPARQL queries in milliseconds. This order of magnitude of query execution times should reasonably be assumed not to incur noticeable delays in the RedSIB software. More complex queries require more execution time and this can potentially slow down the Smart-M3 system due to only one query being processed at a time, effectively leaving the whole system waiting for the query to finish before a new query is performed.
RDF store transaction support was not considered to be an obligatory feature as the Smart-M3 software does not, at the time of writing, have support for transactions. Nevertheless, it is not unreasonable to expect that transactions will become part of future releases of the RedSIB software in order to support transactions, as it is a proven method for handling the reliability and security aspects of sensitive information. For this reason, transaction database operation support was considered as a desirable feature for future use. However, the introduction of transactions in the RedSIB software is out of the scope for the work performed in this chapter. Even though data persistence and data integrity might not be a hard requirement in all smart space environments, there are certain use cases, such as those involving medical data, for which the integrity of the data in the smart space is of high importance.
A non-functional requirement worth mentioning is that due to the limited time frame available for the integration of a new RDF store into the Smart-M3 in combination with the extensive use of the Redland storage library in RedSIB, it is mandatory that the chosen RDF store should be interfacable with the RedSIB software through the Redland storage library. A summary of the requirements and desired features for RDF stores are listed in Table  6  below.
Virtuoso in Smart-M3 Virtuoso has shown some of the best query performances in RDF benchmarks of all complete RDF stores, especially version 7 of the software. Virtuoso has also been shown to be able to scale up to datasets over trillions of  [14]. The compliance with the latest version of SPARQL is also good in Virtuoso, and it can be considered a well-documented system with a sizeable number of active developers working on improving the system. The fact that a storage module for Virtuoso 6 has already been created for the Redland storage library means that adding a Virtuoso option to the RedSIB software is a trivial task. The biggest downside for Virtuoso is, that compared to 4store and Bigdata, that the open source version of the software does not support federation.
Bigdata in Smart-M3 A third alternative considered was the Bigdata software, which is provided under both open-source and free-to-use license. The software is well-documented, and it showed a comparable performance with both 4store and Virtuoso 6 in the BSBM 3. 1 experiment. A major unfavourable factor when considering Bigdata as RDF store in Smart-M3 is that there is a large difference in the data structures used by Bigdata and the triple representation used in the Redland storage library. Due to the limited time to complete the project, creating the necessary interface between Bigdata and librdf was concluded infeasible, and therefore Bigdata had to be discarded as a possible candidate for the project.