DOCSLIB.ORG

Ontop: Answering SPARQL Queries Over Relational Databases

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ontop: Answering SPARQL Queries Over Relational Databases Undefined 0 (0) 1 1 IOS Press Ontop: Answering SPARQL Queries over Relational Databases Diego Calvanese a, Benjamin Cogrel a, Sarah Komla-Ebri a, Roman Kontchakov b, Davide Lanti a, Martin Rezk a, Mariano Rodriguez-Muro c, and Guohui Xiao a a Free University of Bozen-Bolzano {calvanese,bcogrel, sakomlaebri,dlanti,mrezk,xiao}@inf.unibz.it b Birkbeck, University of London [email protected] c IBM TJ Watson [email protected] Abstract. In this paper we present Ontop, an open-source Ontology Based Data Access (OBDA) system that allows for querying relational data sources through a conceptual representation of the domain of interest, provided in terms of an ontology, to which the data sources are mapped. Key features of Ontop are its solid theoretical foundations, a virtual approach to OBDA that avoids materializing triples and that is implemented through query rewriting techniques, extensive optimizations exploiting all elements of the OBDA architecture, its compliance to all relevant W3C recommendations (including SPARQL queries, R2RML mappings, and OWL 2 QL and RDFS ontologies), and its support for all major relational databases. Keywords: Ontop, OBDA, Databases, RDF, SPARQL, Ontologies, R2RML, OWL 1. Introduction vocabulary, models the domain, hides the structure of the data sources, and can enrich incomplete data with Over the past 20 years we have moved from a background knowledge. Then, queries are posed over world where most companies had one all-knowing this high-level conceptual view, and the users no longer self-contained central database to a world where com- need an understanding of the data sources, the relation panies buy and sell their data, interact with several between them, or the encoding of the data. Queries are data sources, and analyze patterns and statistics com- translated by the OBDA system into queries over po- ing from all of them. The challenge is shifting from tentially very large (usually relational and federated) obtaining information to finding the right informa- data sources. The ontology is connected to the data tion. It has always been the case that information is sources through a declarative specification given in power but today attention rather than information be- terms of mappings that relate symbols in the ontol- comes the scarce resource, and those who can distin- ogy (classes and properties) to (SQL) views over data. guish valuable information from background clutter The W3C standard R2RML [12] was created with the gain power [16]. To separate the wheat from the chaff, goal of providing a language for the specification of the companies need a comprehensive understanding of mappings in the OBDA setting. The ontology together their data and the ability to cope with diversity in the with the mappings exposes a virtual RDF graph, which data. can be queried using SPARQL, the standard query lan- Since the mid 2000s, Ontology-Based Data Access guage in the Semantic Web community. These vir- (OBDA) has become a popular approach to tackling tual RDF graphs can be materialized, generating RDF this problem [27]. In OBDA, a conceptual layer is triples that can be used with RDF triplestores, or al- given in the form of an ontology that defines a shared ternatively they can be kept virtual and queried only 0000-0000/0-1900/$00.00 c 0 – IOS Press and the authors. All rights reserved 2 Ontop during query execution. The virtual approach avoids ment regime in SPARQL. The system is available as a the cost of materialization and can profit from more Protégé 4 plugin, a SPARQL endpoint through Sesame than 30 years’ maturity of relational systems (efficient Workbench, and a Java library supporting OWL API query answering, security, robust transaction support, and Sesame API. etc.). The structure of the paper is as follows. Section 2 To illustrate these concepts and the different notions presents a high-level overview of the architecture of in this paper, we will use the following running exam- Ontop. Section 3 describes the SPARQL query answer- ple. All the material needed to run this example in the ing techniques implemented in Ontop. Section 4 out- OBDA system Ontop (and a complementary tutorial) lines the applications of Ontop, in particular the Sta- can be found online1. toil and Siemens use cases in the context of the Op- tique project. Related SPARQL query answering sys- Example 1.1 (Hospital Database). We consider a hos- tems are surveyed in Section 5. Section 6 is a retro- pital database with a single table tbl_patient that spective on the development of Ontop over the past five contains information about lung cancer patients. The years. Finally, Section 7 concludes the paper. table has 4 attributes: the patient identifier (pid), his/her name, the type of cancer (tumor) and its stage. The lung cancer can be of two types: Non-Small Cell 2. Architecture of Ontop Lung Carcinoma (NSCLC) and Small Cell Lung Car- cinoma (SCLC), which are encoded in the table by a Ontop is an open-source3 OBDA system released boolean value type as follows: under the Apache license, developed at the Free Uni- – false for NSCLC and true for SCLC. versity of Bozen-Bolzano. The Ontop system exposes relational databases as virtual RDF graphs by linking The stage of the cancer is encoded by a positive integer the terms (classes and properties) in the ontology to value stage as follows: the data sources through mappings. This virtual RDF – 1–6 for NSCLC stages I, II, III, IIIa, IIIb and IV, graph can then be queried using SPARQL, by translat- – 7–8 for SCLC stages Limited and Extensive. ing the SPARQL queries into SQL queries over the re- lational databases. This translation process is transpar- Finally, our sample table contains the following data: ent to the user. pid name type stage The architecture of Ontop, which is illustrated in Fig. 1, can be divided in four different layers: (i) the 1 ’Mary’ false 4 inputs, i.e., the domain-specific artifacts such as the 2 ’John’ true 7 ontology, database, mappings, and queries; (ii) the core Suppose we need a simple piece of information from of the system in charge of query translation, optimiza- tion, and execution; (iii) the APIs exposing standard this database: “Give me the names of patients with a Java interfaces to users of the system; and (iv) the tumor of stage IIIa”. Even this simple query in this applications that allow end-users to execute SPARQL tiny database already presents some challenges, since queries over databases. to create the query and to understand and analyze the We explore each of these components in turn. results we need to know how the information is en- coded in the data. In the following sections we describe 2.1. Inputs: Ontology, Mappings, Queries, and how to use the Ontop system to address this challenge Databases by enhancing the database with a semantic layer. In this paper we present the OBDA system Ontop2, To the best of our knowledge, Ontop is the first a mature open-source system, which is currently being OBDA system that supports all the W3C recom- used in a number of projects. Ontop supports all the mendations related to OBDA: OWL 2 QL, R2RML, W3C recommendations related to OBDA: OWL 2 QL, SPARQL, SWRL, and the OWL 2 QL entailment R2RML, SPARQL, SWRL, and the OWL 2 QL entail- regime in SPARQL4. In addition, it supports all 1https://github.com/ontop/ontop-examples/ 3http://github.com/ontop/ontop/ tree/master/swj-2015 4SWRL and the OWL 2 QL entailment regime are currently sup- 2http://ontop.inf.unibz.it/ ported experimentally. Ontop 3 Sesame Workbench & Optique Application Protege Layer SPARQL Endpoint Platform API OWL-API Sesame Storage And Inference Layer (SAIL) API Layer Ontop Ontop SPARQL Query Answering Engine (Quest) Core OWL-API Sesame API R2RML API JDBC (OWL Parser) (SPARQL Parser) OWL 2 QL R2RML Inputs Relational SPARQL Ontologies Mappings Databases Queries Fig. 1. Architecture of the Ontop system the major commercial and open-source relational mapping language, which is easier to learn and use. databases. Ontop allows users to convert native mappings into R2RML mappings and vice-versa. Intuitively, a map- Ontology. Ontop allows for RDFS [6] and ping assertion consists of a source (an SQL query re- OWL 2 QL [24] as ontology languages. OWL 2 QL is trieving values from the database) and a target (defin- based on the DL-Lite family of lightweight description ing RDF triples with values from the source). logics [9,2], which guarantees that queries over the ontology can be rewritten into equivalent queries over Example 2.2. The ontology in Example 2.1 can be the databases. Recently Ontop has been extended to populated from the database in Example 1.1 by means support also a fragment of SWRL [43]. of the following mappings: :db1/{pid} rdf:type :Patient . Example 2.1. The following ontology captures the do- SELECT pid FROM tbl_patient main knowledge of our running example. It describes :db1/neoplasm/{pid} rdf:type :NSCLC . the concepts of cancer and cancer patient with the fol- SELECT pid, stage FROM tbl_patient lowing OWL axioms: WHERE type = false :NSCLC rdfs:subClassOf :LungCancer . :db1/neoplasm/{pid} rdf:type :SCLC . :SCLC rdfs:subClassOf :LungCancer . SELECT pid, stage FROM tbl_patient :LungCancer rdfs:subClassOf :Neoplasm . WHERE type = true :hasNeoplasm rdfs:domain :Patient . :db1/{pid} :hasName {name} . :hasNeoplasm rdfs:range :Neoplasm . SELECT pid, name FROM tbl_patient :hasName rdf:type owl:DatatypeProperty . :db1/{pid} :hasNeoplasm :db1/neoplasm/{pid} . :hasStage rdf:type owl:ObjectProperty . SELECT pid FROM tbl_patient In particular, classes :NSCLS and :SCLC are both :db1/neoplasm/{pid} :hasStage :stage-IIIa . SELECT pid FROM tbl_patient subclasses of :LungCancer (that is, they both are WHERE stage = 4 types of lung cancer), which in turn is a subclass of (To ease readability we use a slightly simplified :Neoplasm.
Load more

Recommended publications
  • Ontotext Platform Documentation Release 3.4 Ontotext
    Ontotext Platform Documentation Release 3.4 Ontotext Apr 16, 2021 CONTENTS 1 Overview 1 1.1 30,000ft ................................................ 2 1.2 Layered View ............................................ 2 1.2.1 Application Layer ...................................... 3 1.2.1.1 Ontotext Platform Workbench .......................... 3 1.2.1.2 GraphDB Workbench ............................... 4 1.2.2 Service Layer ........................................ 5 1.2.2.1 Semantic Objects (GraphQL) ........................... 5 1.2.2.2 GraphQL Federation (Apollo GraphQL Federation) ............... 5 1.2.2.3 Text Analytics Service ............................... 6 1.2.2.4 Annotation Service ................................ 7 1.2.3 Data Layer ......................................... 7 1.2.3.1 Graph Database (GraphDB) ........................... 7 1.2.3.2 Semantic Object Schema Storage (MongoDB) ................. 7 1.2.3.3 Semantic Objects for MongoDB ......................... 8 1.2.3.4 Semantic Object for Elasticsearch ........................ 8 1.2.4 Authentication and Authorization ............................. 8 1.2.4.1 FusionAuth ..................................... 8 1.2.4.2 Semantic Objects RBAC ............................. 9 1.2.5 Kubernetes ......................................... 9 1.2.5.1 Ingress and GW .................................. 9 1.2.6 Operation Layer ....................................... 10 1.2.6.1 Health Checking .................................. 10 1.2.6.2 Telegraf ....................................... 10
    [Show full text]
  • Data Platforms Map from 451 Research
    1 2 3 4 5 6 Azure AgilData Cloudera Distribu2on HDInsight Metascale of Apache Kaa MapR Streams MapR Hortonworks Towards Teradata Listener Doopex Apache Spark Strao enterprise search Apache Solr Google Cloud Confluent/Apache Kaa Al2scale Qubole AWS IBM Azure DataTorrent/Apache Apex PipelineDB Dataproc BigInsights Apache Lucene Apache Samza EMR Data Lake IBM Analy2cs for Apache Spark Oracle Stream Explorer Teradata Cloud Databricks A Towards SRCH2 So\ware AG for Hadoop Oracle Big Data Cloud A E-discovery TIBCO StreamBase Cloudera Elas2csearch SQLStream Data Elas2c Found Apache S4 Apache Storm Rackspace Non-relaonal Oracle Big Data Appliance ObjectRocket for IBM InfoSphere Streams xPlenty Apache Hadoop HP IDOL Elas2csearch Google Azure Stream Analy2cs Data Ar2sans Apache Flink Azure Cloud EsgnDB/ zone Platforms Oracle Dataflow Endeca Server Search AWS Apache Apache IBM Ac2an Treasure Avio Kinesis LeanXcale Trafodion Splice Machine MammothDB Drill Presto Big SQL Vortex Data SciDB HPCC AsterixDB IBM InfoSphere Towards LucidWorks Starcounter SQLite Apache Teradata Map Data Explorer Firebird Apache Apache JethroData Pivotal HD/ Apache Cazena CitusDB SIEM Big Data Tajo Hive Impala Apache HAWQ Kudu Aster Loggly Ac2an Ingres Sumo Cloudera SAP Sybase ASE IBM PureData January 2016 Logic Search for Analy2cs/dashDB Logentries SAP Sybase SQL Anywhere Key: B TIBCO Splunk Maana Rela%onal zone B LogLogic EnterpriseDB SQream General purpose Postgres-XL Microso\ Ry\ X15 So\ware Oracle IBM SAP SQL Server Oracle Teradata Specialist analy2c PostgreSQL Exadata
    [Show full text]
  • Representing and Reasoning About Semantic Conflicts in Heterogeneous Information Systems
    Representing and Reasoning about Semantic Conflicts in Heterogeneous Information Systems Cheng Hian Goh CISL WP# 97-01 January 1997 The Sloan School of Management Massachusetts Institute of Technology Cambridge, MA 02142 Representing and Reasoning about Semantic Conflicts in Heterogeneous Information Systems by Cheng Hian Goh Submitted to the Sloan School of Management on Dec 5, 1996, in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract The context INterchange (COIN) strategy [Sciore et al., 1994, Siegel and Madnick, 1991] presents a novel perspective for mediated data access in which semantic con- flicts among heterogeneous systems are not identified a priori, but are detected and reconciled by a Context Mediator through comparison of contexts associated with any two systems engaged in data exchange. In this Thesis, we present a formal character- ization and reconstruction of this strategy in a COIN framework, based on a deductive object-oriented data model and language called COIN. The COIN framework provides a logical formalism for representing data semantics in distinct contexts. We show that this presents a well-founded basis for reasoning about semantic disparities in heterogeneous systems. In addition, it combines the best features of loose- and tight- coupling approaches in defining an integration strategy that is scalable, extensible and accessible. These latter features are made possible by teasing apart context knowledge from the underlying schemas whenever feasible, by enabling sources and receivers to remain loosely-coupled to one another, and by sustaining an infrastructure for data integration. The feasibility and features of this approach have been demonstrated in a prototype implementation which provides mediated access to traditional database systems (e.g., Oracle databases) as well as semi-structured data (e.g., Web-sites).
    [Show full text]
  • A Semantic Query Method for Deep Web∗
    Proceedings of the 2nd International Conference on Computer Science and Electronics Engineering (ICCSEE 2013) A Semantic Query Method for Deep Web∗ Jiang Hao**,Liu Wen-ju, Lu Li-li School of Computer Science and Engineering Southeast University Nanjing, Jiangsu Province 210096, China [email protected] Abstract—Based on the idea of "functionality-centric", this Web environment. paper proposes a complete set of oriented semantic query methods for Deep Web, builds up the relevant software II. RELEVANT RESEARCH WORK architecture, provides a new method for full use of Deep Web Lots of relevant researches have been done at home data resources in semantic web environment through and abroad in recent years, including following describing the establishment of the semantic environment, implementations: re-writing the SPARQL-to-SQL query, semantic packaging of semantic query result, and the architecture of semantic query A. Web data integration services. It mainly includes two methods in traditional Web data Keywords-Deep Web; semantic query; SPARQ and RDF integration and ontology-based semantic integration. The view traditional Web data integration is typical for WISE-Integrator[4] and MetaQuerier[5] developed by I. INTRODUCTION American scholar with the idea of schema extracting of the Deep Web query interface, constructing the integrated The Deep Web, an important part of the current Web interface, implementing data query and integration through information, refers to the hidden information in the Web the meta-queries. While Ontology-based semantic database. With the continuous development of computer integration is mainly concentrated on the Deep Web depth, networks, the reality of how to use effectively the Deep Web describing the semantics of Web data sources through local data resources becomes a hot issue.
    [Show full text]
  • A Survey of Geospatial Semantic Web for Cultural Heritage
    heritage Review A Survey of Geospatial Semantic Web for Cultural Heritage Ikrom Nishanbaev 1,* , Erik Champion 1 and David A. McMeekin 2 1 School of Media, Creative Arts, and Social Inquiry, Curtin University, Perth, WA 6845, Australia; [email protected] 2 School of Earth and Planetary Sciences, Curtin University, Perth, WA 6845, Australia; [email protected] * Correspondence: [email protected] Received: 23 April 2019; Accepted: 16 May 2019; Published: 20 May 2019 Abstract: The amount of digital cultural heritage data produced by cultural heritage institutions is growing rapidly. Digital cultural heritage repositories have therefore become an efficient and effective way to disseminate and exploit digital cultural heritage data. However, many digital cultural heritage repositories worldwide share technical challenges such as data integration and interoperability among national and regional digital cultural heritage repositories. The result is dispersed and poorly-linked cultured heritage data, backed by non-standardized search interfaces, which thwart users’ attempts to contextualize information from distributed repositories. A recently introduced geospatial semantic web is being adopted by a great many new and existing digital cultural heritage repositories to overcome these challenges. However, no one has yet conducted a conceptual survey of the geospatial semantic web concepts for a cultural heritage audience. A conceptual survey of these concepts pertinent to the cultural heritage field is, therefore, needed. Such a survey equips cultural heritage professionals and practitioners with an overview of all the necessary tools, and free and open source semantic web and geospatial semantic web platforms that can be used to implement geospatial semantic web-based cultural heritage repositories.
    [Show full text]
  • Benchmarking RDF Query Engines: the LDBC Semantic Publishing Benchmark
    Benchmarking RDF Query Engines: The LDBC Semantic Publishing Benchmark V. Kotsev1, N. Minadakis2, V. Papakonstantinou2, O. Erling3, I. Fundulaki2, and A. Kiryakov1 1 Ontotext, Bulgaria 2 Institute of Computer Science-FORTH, Greece 3 OpenLink Software, Netherlands Abstract. The Linked Data paradigm which is now the prominent en- abler for sharing huge volumes of data by means of Semantic Web tech- nologies, has created novel challenges for non-relational data manage- ment technologies such as RDF and graph database systems. Bench- marking, which is an important factor in the development of research on RDF and graph data management technologies, must address these challenges. In this paper we present the Semantic Publishing Benchmark (SPB) developed in the context of the Linked Data Benchmark Council (LDBC) EU project. It is based on the scenario of the BBC media or- ganisation which makes heavy use of Linked Data Technologies such as RDF and SPARQL. In SPB a large number of aggregation agents pro- vide the heavy query workload, while at the same time a steady stream of editorial agents execute a number of update operations. In this paper we describe the benchmark’s schema, data generator, workload and re- port the results of experiments conducted using SPB for the Virtuoso and GraphDB RDF engines. Keywords: RDF, Linked Data, Benchmarking, Graph Databases 1 Introduction Non-relational data management is emerging as a critical need in the era of a new data economy where heterogeneous, schema-less, and complexly structured data from a number of domains are published in RDF. In this new environment where the Linked Data paradigm is now the prominent enabler for sharing huge volumes of data, several data management challenges are present and which RDF and graph database technologies are called to tackle.
    [Show full text]
  • Federated Query Processing for the Semantic Web
    Departamento de Inteligencia Artificial Facultad de Informatica´ Federated Query Processing for the Semantic Web A thesis submitted for the degree of PhD Thesis Author: Msc. Carlos Buil-Aranda Advisor: Dr. Oscar Corcho Garc´ıa January 2012 ii Tribunal nombrado por el Sr. Rector Magfco. de la Universidad Politecnica´ de Madrid, el d´ıa...............de.............................de 20.... Presidente : Vocal : Vocal : Vocal : Secretario : Suplente : Suplente : Realizado el acto de defensa y lectura de la Tesis el d´ıa..........de......................de 20...... en la E.T.S.I. /Facultad...................................................... Calificacion´ .................................................................................. EL PRESIDENTE LOS VOCALES EL SECRETARIO iii Abstract The recent years have witnessed a constant growth in the amount of RDF data available on the Web. This growth is largely based on the increasing rate of data publication on the Web by different actors such governments, life science researchers or geographical institutes. RDF data generation is mainly done by converting already existing legacy data resources into RDF (e.g. converting data stored in relational databases into RDF), but also by creating that RDF data directly (e.g. sensors). These RDF data are normally exposed by means of Linked Data-enabled URIs and SPARQL endpoints. Given the sustained growth that we are experiencing in the number of SPARQL endpoints available, the need to be able to send federated SPARQL queries across them has also grown. Tools for accessing sets of RDF data repositories are starting to appear, differing between them on the way in which they allow users to access these data (allowing users to specify directly what RDF data set they want to query, or making this process transparent to them).
    [Show full text]
  • EAGLE—A Scalable Query Processing Engine for Linked Sensor Data †
    sensors Article EAGLE—A Scalable Query Processing Engine for Linked Sensor Data † Hoan Nguyen Mau Quoc 1,* , Martin Serrano 1, Han Mau Nguyen 2, John G. Breslin 3 and Danh Le-Phuoc 4 1 Insight Centre for Data Analytics, National University of Ireland Galway, H91 TK33 Galway, Ireland; [email protected] 2 Information Technology Department, Hue University, Hue 530000, Vietnam; [email protected] 3 Confirm Centre for Smart Manufacturing and Insight Centre for Data Analytics, National University of Ireland Galway, H91 TK33 Galway, Ireland; [email protected] 4 Open Distributed Systems, Technical University of Berlin, 10587 Berlin, Germany; [email protected] * Correspondence: [email protected] † This paper is an extension version of the conference paper: Nguyen Mau Quoc, H; Le Phuoc, D.: “An elastic and scalable spatiotemporal query processing for linked sensor data”, in proceedings of the 11th International Conference on Semantic Systems, Vienna, Austria, 16–17 September 2015. Received: 22 July 2019; Accepted: 4 October 2019; Published: 9 October 2019 Abstract: Recently, many approaches have been proposed to manage sensor data using semantic web technologies for effective heterogeneous data integration. However, our empirical observations revealed that these solutions primarily focused on semantic relationships and unfortunately paid less attention to spatio–temporal correlations. Most semantic approaches do not have spatio–temporal support. Some of them have attempted to provide full spatio–temporal support, but have poor performance for complex spatio–temporal aggregate queries. In addition, while the volume of sensor data is rapidly growing, the challenge of querying and managing the massive volumes of data generated by sensing devices still remains unsolved.
    [Show full text]
  • Semantic Web Technologies and Data Management
    Semantic Web Technologies and Data Management Li Ma, Jing Mei, Yue Pan Krishna Kulkarni Achille Fokoue, Anand Ranganathan IBM China Research Laboratory IBM Software Group IBM Watson Research Center Bei Jing 100094, China San Jose, CA 95141-1003, USA New York 10598, USA Introduction The Semantic Web aims to build a common framework that allows data to be shared and reused across applications, enterprises, and community boundaries. It proposes to use RDF as a flexible data model and use ontology to represent data semantics. Currently, relational models and XML tree models are widely used to represent structured and semi-structured data. But they offer limited means to capture the semantics of data. An XML Schema defines a syntax-valid XML document and has no formal semantics, and an ER model can capture data semantics well but it is hard for end-users to use them when the ER model is transformed into a physical database model on which user queries are evaluated. RDFS and OWL ontologies can effectively capture data semantics and enable semantic query and matching, as well as efficient data integration. The following example illustrates the unique value of semantic web technologies for data management. Figure 1. An example of ontology based data management In Figure 1, we have two tables in a relational database. One stores some basic information of several companies, and another one describes shareholding relationship among these companies. Sometimes, users want to issue such a query “find Company EDOX’s all direct and indirect shareholders which are from Europe and are IT company”. Based on the data stored in the database, existing RDBMSes cannot represent and answer the above query.
    [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]
  • Remote Sensing
    Remote Sens. 2015, 7, 9473-9491; doi:10.3390/rs70709473 OPEN ACCESS remote sensing ISSN 2072-4292 www.mdpi.com/journal/remotesensing Article Improving the Computational Performance of Ontology-Based Classification Using Graph Databases Thomas J. Lampoltshammer 1,2,* and Stefanie Wiegand 3 1 School of Information Technology and Systems Management, Salzburg University of Applied Sciences, Urstein Süd 1, Puch, Salzburg 5412, Austria 2 Department of Geoinformatics (Z_GIS), University of Salzburg, Schillerstrasse 30, Salzburg 5020, Austria 3 IT Innovation Centre, University of Southampton, Gamma House, Enterprise Road, Southampton SO16 7NS, UK; E-Mail: [email protected] * Author to whom correspondence should be addressed; E-Mail: [email protected]; Tel.: +43-50-2211 (ext. 1311); Fax: +43-50-2211 (ext. 1349). Academic Editors: Ioannis Gitas and Prasad S. Thenkabail Received: 31 March 2015 / Accepted: 17 July 2015 / Published: 22 July 2015 Abstract: The increasing availability of very high-resolution remote sensing imagery (i.e., from satellites, airborne laser scanning, or aerial photography) represents both a blessing and a curse for researchers. The manual classification of these images, or other similar geo-sensor data, is time-consuming and leads to subjective and non-deterministic results. Due to this fact, (semi-) automated classification approaches are in high demand in affected research areas. Ontologies provide a proper way of automated classification for various kinds of sensor data, including remotely sensed data. However, the processing of data entities—so-called individuals—is one of the most cost-intensive computational operations within ontology reasoning. Therefore, an approach based on graph databases is proposed to overcome the issue of a high time consumption regarding the classification task.
    [Show full text]
  • SMART: a Web-Based, Ontology-Driven, Semantic Web Query Answering Application
    SMART: A Web-Based, Ontology-Driven, Semantic Web Query Answering Application Alexander De Leon Battista1, Natalia Villanueva-Rosales1, Myroslav Palenychka1, Michel Dumontier1,2 1 School of Computer Science, 2Department of Biology, Carleton University, 1125 Colonel By Drive, Ottawa, Ontario, K1S5B6 Canada {adlbatti,nvillanu,mpalenyc}@scs.carleton,ca, [email protected] Abstract. SMART (Semantic web information Management with automated Reasoning Tool) is an open-source project, which aims to provide intuitive tools for life scientists for represent, integrate, manage and query heterogeneous and distributed biological knowledge. SMART was designed with interoperability and extensibility in mind and uses AJAX, SVG and JSF technologies, RDF, OWL, SPARQL semantic web languages, triple stores (i.e. Jena) and DL reasoners (i.e. Pellet) for the automated reasoning. Features include semantic query composition and validation using DL reasoners, a graphical representation of the query, a mapping of DL queries to SPARQL, and the retrieval of pre-computed inferences from an RDF triple store. With a use case scenario, we illustrate how a biological scientist can intuitively query the yeast knowledge base and navigate the results. Continued development of this web-based resource for the biological semantic web will enable new information retrieval opportunities for the life sciences. Keywords: Semantic Web, Query Answering, Graphical User Interface. 1 Introduction The primary goal of the Semantic Web is to add semantics to the current Web in such a way that machines can reason about the content [1]. Research activities in the Dumontier Lab are focused on using semantic web technologies to enable biochemical knowledge discovery [2, 3]. In combination with complimentary efforts, we expect that more powerful knowledge discovery tools will facilitate data integration in bioinformatics and create powerful new data mining opportunities over heterogeneous biochemical knowledge.
    [Show full text]