DOCSLIB.ORG

Download (888.22

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Download (888.22 Survey of RDF Stores & SPARQL Engines for Querying Knowledge Graphs This paper was downloaded from TechRxiv (https://www.techrxiv.org). LICENSE CC BY 4.0 SUBMISSION DATE / POSTED DATE 06-04-2021 / 09-04-2021 CITATION ali, waqas; Yao, Bin; Saleem, Muhammad; Hogan, Aidan; Ngomo, A.-C. Ngonga (2021): Survey of RDF Stores & SPARQL Engines for Querying Knowledge Graphs. TechRxiv. Preprint. https://doi.org/10.36227/techrxiv.14376884.v1 DOI 10.36227/techrxiv.14376884.v1 Noname manuscript No. (will be inserted by the editor) A Survey of RDF Stores & SPARQL Engines for Querying Knowledge Graphs Waqas Ali · Muhammad Saleem · Bin Yao · Aidan Hogan · Axel-Cyrille Ngonga Ngomo Received: date / Accepted: date Abstract Recent years have seen the growing adop- 1 Introduction tion of non-relational data models for representing di- verse, incomplete data. Among these, the RDF graph- The Resource Description Framework (RDF) is a graph- based data model has seen ever-broadening adoption, based data model where triples of the form (s; p; o) de- p particularly on the Web. This adoption has prompted note directed labeled edges s −! o in a graph. RDF has the standardization of the SPARQL query language for gained significant adoption in the past years, particu- RDF, as well as the development of a variety of local larly on the Web. As of 2019, over 5 million websites and distributed engines for processing queries over RDF publish RDF data embedded in their webpages [27]. graphs. These engines implement a diverse range of spe- RDF has also become a popular format for publishing cialized techniques for storage, indexing, and query pro- knowledge graphs on the Web, the largest of which – cessing. A number of benchmarks, based on both syn- including Bio2RDF, DBpedia, PubChemRDF, UniProt thetic and real-world data, have also emerged to allow and Wikidata – contain billions of triples. These devel- for contrasting the performance of different query en- opments have brought about the need for optimized gines, often at large scale. This survey paper draws to- techniques and engines for querying large RDF graphs. gether these developments, providing a comprehensive We refer to engines that allow for storing, indexing and review of the techniques, engines and benchmarks for processing joins over RDF as RDF stores. querying RDF knowledge graphs. A variety of query languages have been proposed for RDF, but the SPARQL Protocol and RDF Query Keywords Knowledge Graph · Storage · Indexing · Language (SPARQL) has become the standard [76]. Query Processing · SPARQL · Benchmarks The first version of SPARQL was standardized in 2008, while SPARQL 1.1 was released in 2013 [76]. SPARQL is an expressive language that supports not only joins, W. Ali but also variants of the broader relational algebra (pro- SEIEE, Shanghai Jiao Tong University, Shanghai, China jection, selection, union, difference, etc.). Various new E-mail: [email protected] features were added in SPARQL 1.1, including property M. Saleem paths for matching paths in the RDF graph matching a AKSW, University of Leipzig, Leipzig, Germany given regular expression. Hundreds of SPARQL query E-mail: [email protected] services – called endpoints – have emerged on the Web B. Yao since its standardization [35], with the most popular SEIEE, Shanghai Jiao Tong University, Shanghai, China E-mail: [email protected] endpoints receiving millions of queries per day [164, 125]. We refer to engines that support storing, index- A. Hogan DCC, University of Chile & IMFD, Santiago, Chile ing and processing SPARQL (1.1) queries over RDF as E-mail: [email protected] SPARQL engines. Since SPARQL supports joins, we A.-C. Ngonga Ngomo consider any SPARQL engine to also be an RDF store. University of Paderborn, Paderborn, Germany Efficient data storage, indexing and join processing E-mail: [email protected] are key to RDF stores (and thus, to SPARQL engines): 2 Ali et al. – Storage. Different engines may store RDF data us- techniques for storage, indexing, join processing and ing a variety of different structures (tables, graphs, query processing, respectively. Section 8 explains differ- etc.), encodings (integer IDs, string compression, ent graph partitioning techniques for distributing stor- etc.) and media (main memory, disk, etc.). Which age over multiple machines. Section 9 concludes with storage to use may depend on the scale of the data, research problems and future directions. An appendix the types of query features supported, etc. attached to this extended version compares specific sys- – Indexing. Various indexes are used in RDF stores tems and benchmarks. for fast data lookup and query execution. Different types of indexes can support different operations with differing time–space trade-offs. More indexes generally lead to better query runtimes. However, maintaining such indexes can be costly in terms of 2 Literature Review space consumption and updates. – Join Processing. At the core of evaluating queries We first discuss related studies, including peer-reviewed lies efficient methods for processing joins. While tra- tertiary literature (surveys in journals, short surveys ditional pairwise join algorithms – as used in rela- in proceedings, book chapters, surveys with empirical tional databases – are most often employed, recent comparisons, etc.) from the last 10 years collating tech- years have seen the emergence of novel techniques, niques, engines and/or benchmarks for querying RDF. such as multiway and worst-case optimal joins. Op- timizing the order of evaluation of joins can also be We summarize the topics covered by these works in important to ensure efficient processing. Table 1. We use 3, ∼ and blank cells to denote detailed, partial or little/no discussion, respectively, when com- Beyond processing joins, SPARQL engines must of- pared with the current survey (the bottom row). We fer efficient support for more expressive query features: also include the number of engines and benchmarks in- – Query Processing. SPARQL is an expressive lan- cluded in the work; in some cases the respective pub- guage containing a variety of query features beyond lication does not formally list all systems/benchmarks joins that need to be supported efficiently, such as (e.g., as a table), in which case we may write n+ as an filter expressions, optionals, path queries, etc. estimate for the number discussed in the text. RDF stores can further be divided into two cate- Earlier surveys by Sakr et al. [163], Faye et al. [55], gories: (1) local (single-node) stores that manage RDF Luo et al. [119] focus on RDF storage for individual data on a single machine and (2) distributed stores that machines, particularly using relational storage. Another partition RDF data among multiple machines. While early survey, provided by Svoboda et al. [187], rather fo- local stores are more lightweight, the resources available cuses on querying RDF data over the Web. More recent on one machine limit scalability [211,146,86]. Various surveys by Ma et al. [122], Öszu [145] and Alaoui [8], kinds of distributed RDF stores have thus been pro- Abdelaziz et al. [3], Elzein et al. [52], Yasin et al. [216], posed [72,86,170,171] that typically run on networked Wylot et. al [211], Janke and Staab [93], Zambom San- clusters of commodity, shared-nothing machines. tana and dos Santos Mello [218], and Chawla et al. [40] In this survey, we describe storage, indexing, join all focus on distributed, cloud and decentralized set- processing and query processing techniques employed tings, with only brief summaries of standard techniques by local RDF stores, as well as high-level strategies for applicable on individual machines. With respect to more partitioning RDF graphs as needed for distributed stor- general discussions, Pan et al. [146] provide a short sur- age. An appendix attached to this extended version fur- vey that serves as a quick o/verview of the area. ther compares 116 local and distributed RDF engines In summary, recent surveys have focused primar- in terms of the techniques they use, as well as 12 bench- ily on distributed (e.g., cloud) and decentralized (e.g., marks in terms of the types of data and queries they Web) environments. However, local RDF stores consti- contain. The goal of this survey is to crisply introduce tute the bulk of those found in practice [35], where novel the different techniques used by RDF query engines, storage, indexing and querying techniques continue to and also to help users to choose the appropriate engine emerge. This survey focuses on techniques applicable or benchmark for a given use-case. for individual machines, rather summarizing partition- The remainder of the paper is structured as follows. ing schemes for RDF graphs in distributed environ- Section 2 discusses and contrasts this survey with re- ments. In the appendix, we present a comprehensive lated studies. Section 3 provides preliminaries relating comparison of both local and distributed RDF query to RDF and SPARQL. Sections4,5,6 and7 review engines and benchmarks. A Survey of RDF Stores & SPARQL Engines for Querying Knowledge Graphs 3 Table 1: Prior tertiary literature on RDF query engines; the abbreviations are: Sto./Storage, Ind./Indexing, J.Pr./Join Processing, Q.Pr./Query Processing, Dis./Distribution, Eng./Engines, Ben./Benchmarks Techniques Study Year Type Eng. Bench. Sto. Ind. J.Pr. Q.Pr. Dis. Chawla et al. [39] 2020 Survey 3 ∼ ∼ ∼ 46 9 Zambom & dos Santos [218] 2020 Short Survey ∼ ∼ 3 24 Alaoui [8] 2019 Short Survey 3 ∼ 30+ Janke et al. [91] 2018 Chapter ∼ ∼ ∼ ∼ 3 50+ 9 Wylot et. al [211] 2018 Survey 3 ∼ ∼ ∼ 3 24 8 Pan et al. [146] 2018 Short survey 3 ∼ ∼ ∼ 25+ 4 Yasin et al. [216] 2018 Short survey ∼ 3 ∼ 14 Elzein et al. [52] 2018 Survey 3 ∼ ∼ ∼ 15+ Abdelaziz et al. [3] 2017 Comparison 3 ∼ ∼ ∼ 3 21 4 Ma et al. [122] 2016 Survey 3 ∼ ∼ 17 6 Özsu [145] 2016 Survey 3 ∼ ∼ ∼ 35+ Kaoudi et al.
Load more

Recommended publications
  • Mapping Spatiotemporal Data to RDF: a SPARQL Endpoint for Brussels
    International Journal of Geo-Information Article Mapping Spatiotemporal Data to RDF: A SPARQL Endpoint for Brussels Alejandro Vaisman 1, * and Kevin Chentout 2 1 Instituto Tecnológico de Buenos Aires, Buenos Aires 1424, Argentina 2 Sopra Banking Software, Avenue de Tevuren 226, B-1150 Brussels, Belgium * Correspondence: [email protected]; Tel.: +54-11-3457-4864 Received: 20 June 2019; Accepted: 7 August 2019; Published: 10 August 2019 Abstract: This paper describes how a platform for publishing and querying linked open data for the Brussels Capital region in Belgium is built. Data are provided as relational tables or XML documents and are mapped into the RDF data model using R2RML, a standard language that allows defining customized mappings from relational databases to RDF datasets. In this work, data are spatiotemporal in nature; therefore, R2RML must be adapted to allow producing spatiotemporal Linked Open Data.Data generated in this way are used to populate a SPARQL endpoint, where queries are submitted and the result can be displayed on a map. This endpoint is implemented using Strabon, a spatiotemporal RDF triple store built by extending the RDF store Sesame. The first part of the paper describes how R2RML is adapted to allow producing spatial RDF data and to support XML data sources. These techniques are then used to map data about cultural events and public transport in Brussels into RDF. Spatial data are stored in the form of stRDF triples, the format required by Strabon. In addition, the endpoint is enriched with external data obtained from the Linked Open Data Cloud, from sites like DBpedia, Geonames, and LinkedGeoData, to provide context for analysis.
    [Show full text]
  • Open Web Ontobud: an Open Source RDF4J Frontend
    Open Web Ontobud: An Open Source RDF4J Frontend Francisco José Moreira Oliveira University of Minho, Braga, Portugal [email protected] José Carlos Ramalho Department of Informatics, University of Minho, Braga, Portugal [email protected] Abstract Nowadays, we deal with increasing volumes of data. A few years ago, data was isolated, which did not allow communication or sharing between datasets. We live in a world where everything is connected, and our data mimics this. Data model focus changed from a square structure like the relational model to a model centered on the relations. Knowledge graphs are the new paradigm to represent and manage this new kind of information structure. Along with this new paradigm, a new kind of database emerged to support the new needs, graph databases! Although there is an increasing interest in this field, only a few native solutions are available. Most of these are commercial, and the ones that are open source have poor interfaces, and for that, they are a little distant from end-users. In this article, we introduce Ontobud, and discuss its design and development. A Web application that intends to improve the interface for one of the most interesting frameworks in this area: RDF4J. RDF4J is a Java framework to deal with RDF triples storage and management. Open Web Ontobud is an open source RDF4J web frontend, created to reduce the gap between end users and the RDF4J backend. We have created a web interface that enables users with a basic knowledge of OWL and SPARQL to explore ontologies and extract information from them.
    [Show full text]
  • A Performance Study of RDF Stores for Linked Sensor Data
    Semantic Web 1 (0) 1–5 1 IOS Press 1 1 2 2 3 3 4 A Performance Study of RDF Stores for 4 5 5 6 Linked Sensor Data 6 7 7 8 Hoan Nguyen Mau Quoc a,*, Martin Serrano b, Han Nguyen Mau c, John G. Breslin d , Danh Le Phuoc e 8 9 a Insight Centre for Data Analytics, National University of Ireland Galway, Ireland 9 10 E-mail: [email protected] 10 11 b Insight Centre for Data Analytics, National University of Ireland Galway, Ireland 11 12 E-mail: [email protected] 12 13 c Information Technology Department, Hue University, Viet Nam 13 14 E-mail: [email protected] 14 15 d Confirm Centre for Smart Manufacturing and Insight Centre for Data Analytics, National University of Ireland 15 16 Galway, Ireland 16 17 E-mail: [email protected] 17 18 e Open Distributed Systems, Technical University of Berlin, Germany 18 19 E-mail: [email protected] 19 20 20 21 21 Editors: First Editor, University or Company name, Country; Second Editor, University or Company name, Country 22 Solicited reviews: First Solicited Reviewer, University or Company name, Country; Second Solicited Reviewer, University or Company name, 22 23 Country 23 24 Open reviews: First Open Reviewer, University or Company name, Country; Second Open Reviewer, University or Company name, Country 24 25 25 26 26 27 27 28 28 29 Abstract. The ever-increasing amount of Internet of Things (IoT) data emanating from sensor and mobile devices is creating 29 30 new capabilities and unprecedented economic opportunity for individuals, organisations and states.
    [Show full text]
  • Storage, Indexing, Query Processing, And
    Preprints (www.preprints.org) | NOT PEER-REVIEWED | Posted: 23 May 2020 doi:10.20944/preprints202005.0360.v1 STORAGE,INDEXING,QUERY PROCESSING, AND BENCHMARKING IN CENTRALIZED AND DISTRIBUTED RDF ENGINES:ASURVEY Waqas Ali Department of Computer Science and Engineering, School of Electronic, Information and Electrical Engineering (SEIEE), Shanghai Jiao Tong University, Shanghai, China [email protected] Muhammad Saleem Agile Knowledge and Semantic Web (AKWS), University of Leipzig, Leipzig, Germany [email protected] Bin Yao Department of Computer Science and Engineering, School of Electronic, Information and Electrical Engineering (SEIEE), Shanghai Jiao Tong University, Shanghai, China [email protected] Axel-Cyrille Ngonga Ngomo University of Paderborn, Paderborn, Germany [email protected] ABSTRACT The recent advancements of the Semantic Web and Linked Data have changed the working of the traditional web. There is a huge adoption of the Resource Description Framework (RDF) format for saving of web-based data. This massive adoption has paved the way for the development of various centralized and distributed RDF processing engines. These engines employ different mechanisms to implement key components of the query processing engines such as data storage, indexing, language support, and query execution. All these components govern how queries are executed and can have a substantial effect on the query runtime. For example, the storage of RDF data in various ways significantly affects the data storage space required and the query runtime performance. The type of indexing approach used in RDF engines is key for fast data lookup. The type of the underlying querying language (e.g., SPARQL or SQL) used for query execution is a key optimization component of the RDF storage solutions.
    [Show full text]
  • A Survey of Current Property Graph Query Languages Peter Boncz (CWI)
    A Survey Of Current Property Graph Query Languages Peter Boncz (CWI) incorporating slides from: Renzo Angles (Talca University), Oskar van Rest (Oracle), Mingxi Wu (TigerGraph) & Stefan Plantikow (neo4j) 1 History of Graph Query Languages Gremlin DNAQL HPQL BiQL RLV PDQL THQL SoQL GXPath GRE HNQL GUL GraphQL ECRPQ GMQL GSQL SQL/PGQ Graphlog Hyperlog UnQL HQL SPARQL SPARQL 1.1 PGQL GQL G G+ Gram PORL SLQL PRPQ Cypher RQ G-CORE 1987 1989 1995 1997 1999 2009 2013 2015 2017 2019 1990 1992 1994 2000 2002 2006 2008 2012 2016 2018 2021/2022? SPARQL Cypher Gremlin PGQL GSQL G-CORE SQL/PGQ GQL 2 History: the query language G • By Isabel Cruz, Alberto Mendelzon & Peter Wood • Data model: simple graphs • Formal and Graphical forms • Main functionality – Graph pattern queries – Path finding queries I. F. Cruz et al. A graphical query language supporting recursion. SIGMOD 1987. 3 G Example I. F. Cruz et al. A graphical query language supporting recursion. SIGMOD 1987. 4 Systems: Popular Query Language Implementations SQL • MySQL, SQLserver, Oracle, SQLserver, Postgres, Redis, DB2, Amazon Aurora, Amazon Redshift, Snowflake, Spark SQL, etc etc etc (398000k google hits for `sql query’) SPARQL • Amazon Neptune, Ontotext, GraphDB, AllegroGraph, Apache Jena with ARQ, Redland, MarkLogic, Stardog, Virtuoso, Blazegraph, Oracle DB Enterprise Spatial & Graph, Cray Urika-GD, AnzoGraph (1190k google hits for ‘sparql query’) • neo4j, RedisGraph, neo4j CAPS (Cypher on APache Spark), SAP HANA, Agens Graph, AnzoGraph, Cypher Cypher for Gremlin, Memgraph, OrientDB
    [Show full text]
  • Performance of RDF Library of Java, C# and Python on Large RDF Models
    et International Journal on Emerging Technologies 12(1): 25-30(2021) ISSN No. (Print): 0975-8364 ISSN No. (Online): 2249-3255 Performance of RDF Library of Java, C# and Python on Large RDF Models Mustafa Ali Bamboat 1, Abdul Hafeez Khan 2 and Asif Wagan 3 1Department of Computer Science, Sindh Madressatul Islam University (SMIU), Karachi, (Sindh), Pakistan. 2Department of Software Engineering, Sindh Madressatul Islam University (SMIU) Karachi, (Sindh), Pakistan. 3Department of Computer Science, Sindh Madressatul Islam University (SMIU), Karachi (Sindh), Pakistan. (Corresponding author: Mustafa Ali Bamboat) (Received 03 November 2020, Revised 22 December 2020, Accepted 28 January 2021) (Published by Research Trend, Website: www.researchtrend.net) ABSTRACT: The semantic web is an extension of the traditional web, in which contents are understandable to the machine and human. RDF is a Semantic Web technology used to create data stores, build vocabularies, and write rules for approachable LinkedData. RDF Framework expresses the Web Data using Uniform Resource Identifiers, which elaborate the resource in triples consisting of subject, predicate, and object. This study examines RDF libraries' performance on three platforms like Java, DotNet, and Python. We analyzed the performance of Apache Jena, DotNetRDF, and RDFlib libraries on the RDF model of LinkedMovie and Medical Subject Headings (MeSH) in aspects measuring matrices such as loading time, file traversal time, query response time, and memory utilization of each dataset. SPARQL is the RDF model's query language; we used six queries, three for each dataset, to analyze each query's response time on the selected RDF libraries. Keywords: dotNetRDF, Apache Jena, RDFlib, LinkedMovie, MeSH.
    [Show full text]
  • The World of Knowledge Graphs in Oracle Databases
    The World of Knowledge Graphs in Oracle Databases Collaboration between Semantic Web Company and Oracle Emma Thomas Sebastian Gabler Principal Solutions Architect Director of Sales Oracle A-team Semantic Web Company November 19th 2019 2 Confidential – © 2019 Oracle Restricted Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation. 3 The World of Knowledge Graphs in Oracle Databases Introduction to Knowledge Graphs Oracle Database Spatial and Graph - RDF Focus Oracle RDF4J adapter Using PoolParty for Search, Similarity, Recommendation and Visualisation 4 Confidential – © 2019 Oracle Restricted Graphs are Everywhere Heiko Paulheim. Journal of Web Semantics: Special Issue on Knowledge Graph Refinement. “Knowledge Graph Refinement: A Survey of Approaches and Evaluation Methods.” [September, 2016] 5 Confidential – © 2019 Oracle Restricted An Opte Project Visualisation of routing paths through a portion of the Internet By The Opte Project - Originally from the English Wikipedia; description page is/was here., CC BY 2.5, https://commons.wikimedia.org/w/index.php?cu rid=1538544 6 What is a Knowledge Graph? Knowledge graphs are large networks of entities, their semantic types, properties, and relationships between entities1. Key Features: Knowledge “Things, not strings” Database Base Knowledge global unique identifiers Graph Formal structure/semantics machine processable, unambiguous Linked descriptions Graph resources are described by their connections 1.
    [Show full text]
  • Graphdb-Free.Pdf
    GraphDB Free Documentation Release 8.5 Ontotext Jun 17, 2019 CONTENTS 1 General 1 1.1 About GraphDB...........................................2 1.2 Architecture & components.....................................2 1.2.1 Architecture.........................................2 1.2.1.1 RDF4J.......................................3 1.2.1.2 The Sail API....................................4 1.2.2 Components.........................................4 1.2.2.1 Engine.......................................4 1.2.2.2 Connectors.....................................5 1.2.2.3 Workbench.....................................5 1.3 GraphDB Free............................................5 1.3.1 Comparison of GraphDB Free and GraphDB SE......................6 1.4 Connectors..............................................6 1.5 Workbench..............................................6 2 Quick start guide 9 2.1 Run GraphDB as a desktop installation...............................9 2.1.1 On Windows........................................ 10 2.1.2 On Mac OS......................................... 10 2.1.3 On Linux.......................................... 10 2.1.4 Configuring GraphDB................................... 10 2.1.5 Stopping GraphDB..................................... 11 2.2 Run GraphDB as a stand-alone server................................ 11 2.2.1 Running GraphDB..................................... 11 2.2.1.1 Options...................................... 11 2.2.2 Configuring GraphDB................................... 12 2.2.2.1 Paths and network settings...........................
    [Show full text]
  • Emergent Relational Schemas for RDF
    Emergent Relational Schemas for RDF Minh Duc Pham Committee prof.dr. Frank van Harmelen prof.dr. Martin Kersten prof.dr. Josep Lluis Larriba Pey prof.dr. Thomas Neumann dr. Jacopo Urbani The research reported in this thesis has been partially carried out at CWI, the Dutch National Research Laboratory for Mathematics and Computer Science, within the theme Database Architectures. The research reported in this thesis has been partially carried out as part of the continuous research and development of the MonetDB open-source database man- agement system. SIKS Dissertation Series No. 2018-19 The research reported in this thesis has been carried out under the auspices of SIKS, the Dutch Research School for Information and Knowledge Systems. The cover was designed by the author. Photo by Leo Rivas on Unsplash. The printing and binding of this dissertation was carried out by Ipskamp Printing. ISBN 978-94-028-1110-0 VRIJE UNIVERSITEIT Emergent Relational Schemas for RDF ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr. V. Subramaniam, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de Faculteit der Bètawetenschappen op donderdag 6 september 2018 om 15.45 uur in de aula van de universiteit, De Boelelaan 1105 door Minh Duc Pham geboren te Bac Ninh, Vietnam promotor: prof.dr. P.A. Boncz copromotor: prof.dr. S. Manegold Tặng bố mẹ của con vì tình yêu thương vô bờ bến, Tặng em yêu vì bao gian khổ, ngọt ngào và con trai - nguồn vui vô tận ..
    [Show full text]
  • Graphdb Free Documentation Release 8.11
    GraphDB Free Documentation Release 8.11 Ontotext Sep 26, 2019 CONTENTS 1 General 1 1.1 About GraphDB...........................................2 1.2 Architecture & Components.....................................2 1.2.1 Architecture.........................................2 1.2.1.1 RDF4J.......................................3 1.2.1.2 The Sail API....................................4 1.2.2 Components.........................................4 1.2.2.1 Engine.......................................4 1.2.2.2 Connectors.....................................5 1.2.2.3 Workbench.....................................5 1.3 GraphDB Free............................................5 1.3.1 Comparison of GraphDB Free and GraphDB SE......................6 1.4 Connectors..............................................6 1.5 Workbench..............................................6 2 Quick start guide 9 2.1 Run GraphDB as a Desktop Installation...............................9 2.1.1 On Windows........................................ 10 2.1.2 On MacOS......................................... 10 2.1.3 On Linux.......................................... 10 2.1.4 Configuring GraphDB................................... 10 2.1.5 Stopping GraphDB..................................... 11 2.2 Run GraphDB as a Standalone Server................................ 11 2.2.1 Running GraphDB..................................... 11 2.2.1.1 Options...................................... 11 2.2.2 Configuring GraphDB................................... 12 2.2.2.1 Paths and network settings...........................
    [Show full text]
  • IDC Techscape IDC Techscape: Internet of Things Analytics and Information Management
    IDC TechScape IDC TechScape: Internet of Things Analytics and Information Management Maureen Fleming Stewart Bond Carl W. Olofson David Schubmehl Dan Vesset Chandana Gopal Carrie Solinger IDC TECHSCAPE FIGURE FIGURE 1 IDC TechScape: Internet of Things Analytics and Information Management — Current Adoption Patterns Note: The IDC TechScape represents a snapshot of various technology adoption life cycles, given IDC's current market analysis. Expect, over time, for these technologies to follow the adoption curve on which they are currently mapped. Source: IDC, 2016 December 2016, IDC #US41841116 IN THIS STUDY Implementing the analytics and information management (AIM) tier of an Internet of Things (IoT) initiative is about the delivery and processing of sensor data, the insights that can be derived from that data and, at the moment of insight, initiating actions that should then be taken to respond as rapidly as possible. To achieve value, insight to action must fall within a useful time window. That means the IoT AIM tier needs to be designed for the shortest time window of IoT workloads running through the end- to-end system. It is also critical that the correct type of analytics is used to arrive at the insight. Over time, AIM technology adopted for IoT will be different from an organization's existing technology investments that perform a similar but less time-sensitive or data volume–intensive function. Enterprises will want to leverage as much of their existing AIM investments as possible, especially initially, but will want to adopt IoT-aligned technology as they operationalize and identify functionality gaps in how data is moved and managed, how analytics are applied, and how actions are defined and triggered at the moment of insight.
    [Show full text]
  • Isa2 Action 2017.01 Standard-Based Archival
    Ref. Ares(2018)3256671 - 20/06/2018 ISA2 ACTION 2017.01 STANDARD-BASED ARCHIVAL DATA MANAGEMENT, EXCHANGE AND PUBLICATION STUDY FINAL REPORT Study on Standard-Based Archival Data Management, Exchange and Publication Final Report DOCUMENT METADATA Property Value Release date 15/06/2018 Status: Final version Version: V1.00 Susana Segura, Luis Gallego, Emmanuel Jamin, Miguel Angel Gomez, Seth Authors: van Hooland, Cédric Genin Lieven Baert, Julie Urbain, Annemie Vanlaer, Belá Harsanyi, Razvan Reviewed by: Ionescu, Reflection Committee Approved by: DOCUMENT HISTORY Version Description Action 0.10 First draft 0.90 Version for Review 0.98 Second version for Review 0.99 Third version for Acceptance 1.00 Final version 2 Study on Standard-Based Archival Data Management, Exchange and Publication Final Report TABLE OF CONTENTS Table of Contents ........................................................................................................................ 3 List of Figures ............................................................................................................................. 8 List of Tables ............................................................................................................................. 10 1 Executive Summary ........................................................................................................... 14 2 Introduction ........................................................................................................................ 16 2.1 Context ..........................................................................................................................
    [Show full text]