DOCSLIB.ORG

Design and Analysis of a Query Processor for Brick

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design and Analysis of a Query Processor for Brick Design and Analysis of a Query Processor for Brick Gabe Fierro David E. Culler UC Berkeley UC Berkeley [email protected] [email protected] ABSTRACT to increase energy efficiency and comfort, as well as provide mon- Brick is a recently proposed metadata schema and ontology for de- itoring and fault diagnosis. While many such applications exist, scribing building components and the relationships between them. the lack of a common description scheme, i.e. metadata, limits the It represents buildings as directed labeled graphs using the RDF portability of these applications across the heterogeneous building data model. Using the SPARQL query language, building-agnostic stock. applications query a Brick graph to discover the set of resources While several efforts address the heterogeneity of building meta- and relationships they require to operate. Latency-sensitive ap- data, these generally fail to capture the relationships and entities plications, such as user interfaces, demand response and model- that are required by real-world applications [8]. This set of re- predictive control, require fast queries — conventionally less than quirements drove the development of Brick [6], a recently proposed 100ms. metadata standard for describing the set of entities and relationships We benchmark a set of popular open-source and commercial within a building. Brick succeeds along three metrics: completeness SPARQL databases against three real Brick models using seven (captures 98% of building management system data points across six application queries and find that none of them meet this perfor- real buildings), expressiveness (can capture all important relation- mance target. This lack of performance can be attributed to design ships) and usability (represents this information in an easy-to-use decisions that optimize for queries over large graphs consisting manner). of billions of triples, but give poor spatial locality and join per- Brick’s goals of expressiveness and usability informed the choice formance on the small dense graphs typical of Brick. We present of the RDF data model [19] and SPARQL query language [28] for the design and evaluation of HodDB, a RDF/SPARQL database for representing and querying graphs, respectively. Initial work [6] Brick built over a node-based index structure. HodDB performs showed that RDF/SPARQL fulfill Brick’s requirements of descrip- Brick queries 3-700x faster than leading SPARQL databases and tion and representation, but did not address the question of how consistently meets the 100ms threshold, enabling the portability of well suited these technologies are to fulfilling the “systems” require- important latency-sensitive building applications. ments of Brick queries integrated into building applications. We focus on latency-sensitive applications including user interfaces, CCS CONCEPTS building modeling, demand response, alarms and model-predictive control. We target a query response time of <100ms, a conventional • Information systems → Graph-based database models; Data interactive latency threshold [25]. We address three questions re- structures; Information retrieval; garding this integration: KEYWORDS (1) What are the characteristics of the Brick workload, and what requirements does the workload place on a Brick query pro- Smart Buildings, Building Management, Metadata, Graph Database, cessor? RDF, SPARQL (2) How well do existing RDF/SPARQL databases meet these ACM Reference format: requirements? Gabe Fierro and David E. Culler. 2017. Design and Analysis of a Query Pro- (3) How can we leverage the characteristics of the Brick work- cessor for Brick. In Proceedings of BuildSys ’17, Delft, Netherlands, November load to design a query processor that does meet these re- 8–9, 2017, 10 pages. quirements? https://doi.org/10.1145/3137133.3137155 We begin with a brief overview of Brick, RDF and SPARQL, and then present a performance evaluation of several popular RDF 1 INTRODUCTION databases against the Brick workload, represented by seven Brick queries of varying complexity on three real Brick building models. Modern buildings present a rich deployment opportunity for ap- We then characterize the Brick workload by the graph properties plications that take advantage of networked sensors and actuators of Brick models and the required query language features. Finally, Permission to make digital or hard copies of all or part of this work for personal or we use these findings to develop HodDB, a RDF/SPARQL query classroom use is granted without fee provided that copies are not made or distributed processor for Brick that consistently meets the latency demands of for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the Brick applications. author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. 2 BACKGROUND BuildSys ’17, November 8–9, 2017, Delft, Netherlands © 2017 Copyright held by the owner/author(s). Publication rights licensed to Associa- This section provides a brief primer on the structure and usage of tion for Computing Machinery. Brick and how it is realized using the RDF data model and SPARQL ACM ISBN 978-1-4503-5544-5/17/11...$15.00 https://doi.org/10.1145/3137133.3137155 query language. BuildSys ’17, November 8–9, 2017, Delft, Netherlands Gabe Fierro and David E. Culler 2.1 Brick Overview 1 ### VAV Enum (Building Dashboard) 2 SELECT DISTINCT ?vav WHERE { 3 ?vav rdf:type brick:VAV . 4 } 5 ### Temp Sensors (Building Dashboard, Room Diagnostics) 6 SELECT DISTINCT ?sensor WHERE { 7 ?sensor rdf:type/rdfs:subClassOf* brick:Zone_Temperature_Sensor . 8 } 9 ### AHU Children (Building Dashboard) 10 SELECT DISTINCT ?x WHERE { 11 ?ahu rdf:type brick:AHU . 12 ?ahu bf:feeds+ ?x. 13 } 14 ### Spatial Mapping (Building Dashboard) 15 SELECT DISTINCT ?floor ?room ?zone WHERE { 16 ?floor rdf:type brick:Floor . 17 ?room rdf:type brick:Room . 18 ?zone rdf:type brick:HVAC_Zone . 19 ?room bf:isPartOf+ ?floor. 20 ?room bf:isPartOf+ ?zone. 21 } 22 ### Sensors In Rooms (Room Diagnostics) 23 SELECT DISTINCT ?sensor ?room 24 WHERE { 25 { ?sensor rdf:type/rdfs:subClassOf* brick:Zone_Temperature_Sensor .} 26 UNION 27 { ?sensor rdf:type/rdfs:subClassOf* brick:Discharge_Air_Temperature_Sensor .} 28 UNION 29 { ?sensor rdf:type/rdfs:subClassOf* brick:Occupancy_Sensor .} 30 UNION Figure 1: Example Brick graph for a simple building, show- 31 { ?sensor rdf:type/rdfs:subClassOf* brick:CO2_Sensor .} ing class instantiations and subclass declarations. Solid blue 32 ?vav rdf:type brick:VAV . 33 ?zone rdf:type brick:HVAC_Zone . boxes make up the building, and dotted tan boxes repre- 34 ?room rdf:type brick:Room . sent the class hierarchy. Note the long chains of feeds and 35 ?vav bf:feeds+ ?zone. 36 ?zone bf:hasPart ?room. subClassOf relationships. 37 {?sensor bf:isPointOf ?vav} 38 UNION 39 {?sensor bf:isPointOf ?room} Brick represents a building as a directed, labeled graph. Nodes 40 } 41 ### VAV Relships (Building Dashboard) (entities) represent equipment, sensors, spaces, timeseries streams or 42 SELECT DISTINCT ?vav ?x ?y ?z ?a ?b WHERE { any other “thing” in a building. The names of nodes are drawn from 43 ?vav rdf:type brick:VAV . 44 ?vav bf:feeds+ ?x. Brick’s class hierarchy. Edges represent the relationships between 45 ?vav bf:isFedBy+ ?y. things and are named according to the minimal, multipurpose set 46 ?vav bf:hasPoint+ ?z. 47 ?vav bf:hasPart+ ?a. of relationships defined by Brick. 48 } Figure 1 shows the Brick graph for a simple example building; 49 ### Grey Box (Automatic Grey Box Modeler) 50 SELECT DISTINCT ?vav ?room ?temp_uuid ?valve_uuid ?setpoint_uuid WHERE { each node is labeled with its name or Brick class and each edge 51 ?vav rdf:type brick:VAV . 52 ?vav bf:hasPoint ?tempsensor. is labeled with a Brick relationship. The building consists of two 53 ?tempsensor rdf:type/rdfs:subClassOf* brick:Temperature_Sensor . adjacent rooms in an HVAC zone and conditioned by a variable air 54 ?tempsensor bf:uuid ?temp_uuid. 55 ?vav bf:hasPoint ?valvesensor. volume box (VAV) with a damper, which receives supply air from a 56 ?valvesensor rdf:type/rdfs:subClassOf* brick:Valve_Command . air handling unit (AHU); one room contains a temperature sensor. 57 ?valvesensor bf:uuid ?valve_uuid. 58 ?vav bf:hasPoint ?setpoint. The chain of feeds edges denotes that air passes from the AHU 59 ?setpoint rdf:type/rdfs:subClassOf* brick:Zone_Temperature_Setpoint . through the VAV and damper to the HVAC zone. 60 ?setpoint bf:uuid ?setpoint_uuid. 61 ?room rdf:type brick:Room . Brick helps mitigate heterogeneity, but also allows applications 62 ?tempsensor bf:isLocatedIn ?room. to understand salient structure. The particular sequence of equip- 63 } ment from an AHU to a zone differs from building to building. Because the “flow” has a consistent edge type (feeds), application Figure 2: The set of SPARQL queries used in real-world Brick developers can use the notion of “one or more feeds edges” to apps, used here for benchmarking RDF databases in §3. associate HVAC equipment with a zone without having to know the exact sequence. This is one way in which Brick allows queries usually refer to generic parent classes, so Brick queries must have to operate consistently despite differences in the structure ofa a way of specifying the semantics of the
Load more

Recommended publications
  • A Comparative Evaluation of Geospatial Semantic Web Frameworks for Cultural Heritage
    heritage Article A Comparative Evaluation of Geospatial Semantic Web Frameworks for Cultural Heritage Ikrom Nishanbaev 1,* , Erik Champion 1,2,3 and David A. McMeekin 4,5 1 School of Media, Creative Arts, and Social Inquiry, Curtin University, Perth, WA 6845, Australia; [email protected] 2 Honorary Research Professor, CDHR, Sir Roland Wilson Building, 120 McCoy Circuit, Acton 2601, Australia 3 Honorary Research Fellow, School of Social Sciences, FABLE, University of Western Australia, 35 Stirling Highway, Perth, WA 6907, Australia 4 School of Earth and Planetary Sciences, Curtin University, Perth, WA 6845, Australia; [email protected] 5 School of Electrical Engineering, Computing and Mathematical Sciences, Curtin University, Perth, WA 6845, Australia * Correspondence: [email protected] Received: 14 July 2020; Accepted: 4 August 2020; Published: 12 August 2020 Abstract: Recently, many Resource Description Framework (RDF) data generation tools have been developed to convert geospatial and non-geospatial data into RDF data. Furthermore, there are several interlinking frameworks that find semantically equivalent geospatial resources in related RDF data sources. However, many existing Linked Open Data sources are currently sparsely interlinked. Also, many RDF generation and interlinking frameworks require a solid knowledge of Semantic Web and Geospatial Semantic Web concepts to successfully deploy them. This article comparatively evaluates features and functionality of the current state-of-the-art geospatial RDF generation tools and interlinking frameworks. This evaluation is specifically performed for cultural heritage researchers and professionals who have limited expertise in computer programming. Hence, a set of criteria has been defined to facilitate the selection of tools and frameworks.
    [Show full text]
  • V a Lida T in G R D F Da
    Series ISSN: 2160-4711 LABRA GAYO • ET AL GAYO LABRA Series Editors: Ying Ding, Indiana University Paul Groth, Elsevier Labs Validating RDF Data Jose Emilio Labra Gayo, University of Oviedo Eric Prud’hommeaux, W3C/MIT and Micelio Iovka Boneva, University of Lille Dimitris Kontokostas, University of Leipzig VALIDATING RDF DATA This book describes two technologies for RDF validation: Shape Expressions (ShEx) and Shapes Constraint Language (SHACL), the rationales for their designs, a comparison of the two, and some example applications. RDF and Linked Data have broad applicability across many fields, from aircraft manufacturing to zoology. Requirements for detecting bad data differ across communities, fields, and tasks, but nearly all involve some form of data validation. This book introduces data validation and describes its practical use in day-to-day data exchange. The Semantic Web offers a bold, new take on how to organize, distribute, index, and share data. Using Web addresses (URIs) as identifiers for data elements enables the construction of distributed databases on a global scale. Like the Web, the Semantic Web is heralded as an information revolution, and also like the Web, it is encumbered by data quality issues. The quality of Semantic Web data is compromised by the lack of resources for data curation, for maintenance, and for developing globally applicable data models. At the enterprise scale, these problems have conventional solutions. Master data management provides an enterprise-wide vocabulary, while constraint languages capture and enforce data structures. Filling a need long recognized by Semantic Web users, shapes languages provide models and vocabularies for expressing such structural constraints.
    [Show full text]
  • Diplomová Práce Prostředky Sémantického Webu V Uživatelském
    Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky Diplomová práce Prostředky sémantického webu v uživatelském rozhraní pro správu elektrofyziologických experimentů Plzeň 2020 Jan Palcút Místo této strany bude zadání práce. Prohlášení Prohlašuji, že jsem diplomovou práci vypracoval samostatně a výhradně s po- užitím citovaných pramenů. V Plzni dne 9. srpna 2020 Jan Palcút Poděkování Tímto bych chtěl poděkovat vedoucímu diplomové práce panu Ing. Romanovi Moučkovi, Ph.D. za cenné rady, připomínky a odborné vedení této práce. Abstract The work aims to verify the applicability of technologies and languages of the semantic web in creating an application for the management of electro- physiological experiments. The application will allow us to manage multiple experiments of the same characteristic type at once, display their metadata, and search in them. The theoretical part of the work describes the semantic web, selected data standards for electrophysiology, and the neuroinformat- ics laboratory of the University of West Bohemia in Pilsen. The analysis and design of the application describe requirements’ specifications and se- lect the data standard and technologies to implement the solution. Part of the proposal is also a description of the solution of writing metadata of experiments into the newly designed structure. Based on the design, the ap- plication for the selected data standard is implemented. The functionality of the application was verified on experiments of various types. Abstrakt Cílem této práce je ověření použitelnosti technologií a jazyků sémantického webu při tvorbě aplikace pro správu elektrofyziologických experimentů. Apli- kace umožní spravovat více experimentů stejného charakteristického typu najednou, zobrazovat jejich metadata a vyhledávat v nich.
    [Show full text]
  • SWAD-Europe Deliverable 3.11: Developer Workshop Report 4 - Workshop on Semantic Web Storage and Retrieval
    Sat Jun 05 2004 22:31:44 Europe/London SWAD-Europe Deliverable 3.11: Developer Workshop Report 4 - Workshop on Semantic Web Storage and Retrieval Project name: Semantic Web Advanced Development for Europe (SWAD-Europe) Project Number: IST-2001-34732 Workpackage name: 3 Dissemination and Implementation Workpackage description: ☞http://www.w3.org/2001/sw/Europe/plan/workpackages/live/esw-wp-3 Deliverable title: 3.11 Developer Workshop Report 4 URI: ☞http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_4/ Author: Dave Beckett Abstract: This report summarises the fourth SWAD-Europe developer ☞Workshop on Semantic Web Storage and Retrieval which was held 13-14 November 2003 at Vrije Universiteit, Amsterdam, Netherlands and attended by 26 semantic web developers from Europe and the USA discussing practical aspects of developing and deploying semantic web storage and retrieval systems. STATUS: Completed 2004-01-12, updated 2004-01-13 with workshop evaluation details. Contents 1. ☞Introduction 2. ☞Summary 3. ☞Evaluation 4. ☞Outcomes 5. ☞Minutes 6. ☞Attendees 1. Introduction The workshop aimed to discuss: Implementation techniques and problems met Storage models and database schemas Aggregation and tracking provenance Using RDBMSes for semantic web storage Discussion of useful test data and queries for comparisons. Implementing RDF datatypes, entailment (from ☞RDF Semantics) 2. Summary The fourth SWAD-Europe workshop was on ☞Semantic Web Storage and Retrieval and held at Vrije Universiteit, Amsterdam, Netherlands organised by ☞Dave Beckett (ILRT) and hosted by ☞Frank van Harmelen from VU. The workshop participants were mostly technical developers and researchers from a ☞variety of Page 1 Sat Jun 05 2004 22:31:45 Europe/London organisations mostly in industry and education from Greece, UK, Slovenija, The Netherlands and Italy in Europe and from the United States.
    [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]
  • Inscribing the Blockchain with Digital Signatures of Signed RDF Graphs. a Worked Example of a Thought Experiment
    Inscribing the blockchain with digital signatures of signed RDF graphs. A worked example of a thought experiment. The thing is, ad hoc hash signatures on the blockchain carry no information linking the hash to the resource for which the hash is acting as a digital signature. The onus is on the inscriber to associate the hash with the resource via a separate communications channel, either by publishing the association directly or making use of one of the third-party inscription services that also offer a resource persistence facility – you get to describe what is signed by the hash and they store the description in a database, usually for a fee, or you can upload the resource for storage, definitely for a fee. Riccardo Cassata has a couple of technical articles that expose more of the practical details: https://blog.eternitywall.it/2016/02/16/how-to-verify-notarization/ So what's published is a hexadecimal string indistinguishable from all the others which purportedly matches the hash of Riccardo's mugshot. But which? https://tineye.com/search/ed9f8022c9af413a350ec5758cda520937feab21 What’s needed is a means of creating an inscription that is not only a signature but also a resovable reference to the resource for which it acts as a digital signature. It would be even better if it were possible to create a signature of structured information, such as that describing a social media post – especially if we could leverage off’ve the W3’s recent Activity Streams standard: https://www.w3.org/TR/activitystreams-core/ An example taken from the
    [Show full text]
  • Wiki S Podporou Zpracování Sémantiky
    MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345<yA| Wiki s podporou zpracování sémantiky DIPLOMOVÁ PRÁCE Bc. Jakub Talaš Brno, podzim 2010 Prohlášení Prohlašuji, že tato diplomová práce je mým p ˚uvodnímautorským dílem, které jsem vypra- coval samostatnˇe.Všechny zdroje, prameny a literaturu, které jsem pˇrivypracování použí- val nebo z nich ˇcerpal,v práci ˇrádnˇecituji s uvedením úplného odkazu na pˇríslušnýzdroj. Vedoucí práce: RNDr. Tomáš Gregar ii Podˇekování Chtˇelbych podˇekovatRNDr. Tomáši Gregarovi za odborné vedení. Rodiˇc˚umza podporu bˇehemstudia a všem ostatním, kteˇríjakkoliv napomohli vzniku této práce. iii Shrnutí Sémantické technologie prodˇelalyv posledních letech bouˇrlivývývoj. Novým cílem sou- ˇcasnýchsnah je pˇredstavitjejich výhody a pˇrivéstje i k bˇežnémuuživateli. Jednou z cest nabývajících na významu je nenásilná a vhodná integrace sémanticky zpracovávaných dat do známých systém ˚ua aplikací – operaˇcních systém ˚u,wiki, systém ˚upro správu obsahu apod. Moje diplomová práce se zabývá zapojením sémantických dat do wiki systému Trac a jejich využití pˇredevšímv oblasti project managementu a e-learningu. iv Klíˇcováslova sémantický web, wiki, Trac, XML, RDF, project management, Python v Obsah 1 Úvod ............................................. 1 2 Motivace pro sémantický web .............................. 3 3 Technologie sémantického webu ............................. 5 3.1 Sémantika dat ..................................... 5 3.2 Ontologie ........................................ 6 3.3
    [Show full text]
  • Introduction to Linked Open Data Github.Com/Cmh2166/Swib18lodintro Simeon Warner, Cornell University Christina Harlow, Stanford University
    Introduction to Linked Open Data github.com/cmh2166/SWIB18LODintro Simeon Warner, Cornell University Christina Harlow, Stanford University SWIB 2018, 26 November 2018 Bonn, Germany github.com/cmh2166/SWIB18LODintro Workshop Resources: github.com/cmh2166/SWIB18LODintro github.com/cmh2166/SWIB18LODintro Workshop Etiquette (influenced by the Hacker School Rules) ● Feel free to ask questions ● Help others where you can ● Be open to different domain expertise & experiences ● Be kind More info on the “Hacker School Rules”: https://www.recurse.com/blog/38-subtle-isms-at-hacker-school https://www.recurse.com/manual#sub-sec-social-rules github.com/cmh2166/SWIB18LODintro Schedule 13:00 - 13:15 General Workshop Introduction 13:15 - 14:00 RDF Introduction: Create Your Graph 14:00 - 14:30 Linked Data Introduction: Link Your Graph 14:30 - 15:30 Linked Data & Semantic Web: Expand Your Graph 15:30 - 16:00 30 minute break, cake served in the foyer 16:00 - 16:15 Linked Open Data & Licensing: License Your Graph 16:15 - 17:15 Linked Data Experimentation: SPARQL & Vis. 17:15 - 18:00 Linked Data Examples, Resources & Questions github.com/cmh2166/SWIB18LODintro Our Goals for this Workshop ● Introduce & Leverage the RDF data model ● Create & Refine RDF Documents ● Explain Fundamentals of Linked Data Technologies ● Introduce & Discuss Basic Issues of Linked Open Data ● Apply Open Data Principles to RDF data ● Understand Pros & Cons of Modeling in RDF ● Understand Pros & Cons of Publishing Linked Data ● Share LOD Tools, Projects, Resources, Examples github.com/cmh2166/SWIB18LODintro Your goals for this Workshop? ● Why are you attending this workshop? ● What are your goals - immediate or long-term? ● What's your level of comfort & experience with any aspect of Linked Data? github.com/cmh2166/SWIB18LODintro RDF Introduction: Create Your Graph github.com/cmh2166/SWIB18LODintro Facilitator’s Starter RDF @prefix z: <https://pad.riseup.net/p/swib-18-ws-z#> .
    [Show full text]
  • Semantic Web and Python Concepts to Application Development
    PyCon 2009 IISc, Bangalore, India Semantic Web and Python Concepts to Application development Vinay Modi Voice Pitara Technologies Private Limited Outline • Web • Need better web for the future • Knowledge Representation (KR) to Web – Challenges • Data integration – challenges • KR to Web - solutions for challenges • Metadata and Semantic Web – protocol stack • RDF, RDFS and SPARQL basic concepts • Using RDFLib adding triples • RDFLib serialization • RDFLib RDFS ontology • Blank node • SPARQL querying • Graph merging • Some possible things one can do with RDFLib Text in Natural Languages Multimedia Images Web Deduce the facts; create mental relationships Need better Web for the future I Know What You Mean KR to Web – Challenges Traditional KR Scaling KR techniques and Network effect Algorithmic complexity and Performance for information space like W3 KR to Web – Challenges Continue … 1 Representational Inconsistencies Machine down Partial Information Data integration - Challenges • Web pages, Corporate databases, Institutions • Different content and structure • Manage for – Company mergers – Inter department data sharing (like eGovernment) – Research activities/output across labs/nations • Accessible from the web but not public. Data Integration – Challenges Continue … 1 • Example: Social sites – add your contacts every time. • Requires standard so that applications can work autonomously and collaboratively. What is needed • Some data should be available for machines for further processing • Data should be possibly combined, merged on Web scale • Some time data may describe other data – i.e. metadata. • Some times data needs to be exchanged. E.g. between Travel preferences and Ticket booking. Metadata • Data about data • Two ways of associating with a resource – Physical embedding – Separate resource • Resource identifier • Globally unique identifier • Advantages of explicit metadata • Dublin core, FOAF KR to Web – Solution for Challenges Continue … 2 Solve syntactic interoperability.
    [Show full text]
  • Design of an Effective Ontology and Query Processor Enabling Portable Building Applications
    Design of an Effective Ontology and Query Processor Enabling Portable Building Applications Gabe Fierro Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2019-29 http://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-29.html May 10, 2019 Copyright © 2019, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Acknowledgement This thesis is based in part on work done with Bharathan Balaji, Arka Bhattacharya, Gabe Fierro, Jingkun Gao, Joshua Gluck, Dezhi Hong, Aslak Johansen, Jason Koh, Yuvraj Agarwal, Mario Berges, David E. Culler, Rajesh Gupta, Mikkel Baun Kjaergaard, Joern Ploennigs and Kamin Whitehouse Design of an Effective Ontology and Query Processor Enabling Portable Building Applications by Gabriel Tomas Fierro A thesis submitted in partial satisfaction of the requirements for the degree of Master of Science, Plan II in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor David E. Culler, Research Advisor Professor Randy H. Katz Spring 2019 The thesis of Gabriel Tomas Fierro, titled Design of an Effective Ontology and Query Pro- cessor Enabling Portable Building Applications, is approved: Research Advisor Date Date University of California, Berkeley Design of an Effective Ontology and Query Processor Enabling Portable Building Applications Copyright 2019 by Gabriel Tomas Fierro 1 Abstract Design of an Effective Ontology and Query Processor Enabling Portable Building Applications by Gabriel Tomas Fierro Master of Science, Plan II in Computer Science University of California, Berkeley Professor David E.
    [Show full text]
  • RDF in the JRS Server
    RDF in the JRS Server Simon Johnston, Martin Nally, Edison Ting May 16, 2008 This document describes the manner in which the JRS Server leverages, and exposes, RDF. JRS is not an RDF server, however it has made extensive use of RDF in the way in which it indexes resources and exposes indexed properties to client applications. This document covers not only the manner in which clients interact with this RDF view but the motivation for using RDF and some of the implementation details. 1 Motivation The Jazz REST Services (JRS) Server is a set of REST storage services that allow for the secure storage, indexing and query of resources supporting the development of Application Lifecycle Management (ALM) application clients. A JRS server should not make any restriction on the type or representation of resources1 stored, and yet indexing of resources does require knowledge of the “raw” format (XML vs. plain text for example) and specific domain schema (requirement XML vs. test case XML for example). To this end the workflow within JRS on the storage of resources is to invoke a set of indexer tasks that are raw format specific and which may be further configured with declarative rules for domain schema. For example the JRS server provides an image indexer that is able to extract EXIF2 properties from photographs and indexes a fixed subset, the XML indexer however must be configured by a client to extract specific elements and attributes using a set of XPath expressions. These indexer tasks are responsible for the extraction of properties from the resource which the JRS server then makes available for queries.
    [Show full text]
  • RDF Triplestores and SPARQL Endpoints
    RDF triplestores and SPARQL endpoints Lecturer: Mathias Bonduel [email protected] LDAC summer school 2019 – Lisbon, Portugal Lecture outline • Storing RDF data: RDF triplestores o Available methods to store RDF data o RDF triplestores o Triplestore applications – databases – default graph – named graphs o List of triplestore applications o Comparing triplestores o Relevant triplestore settings o Communication with triplestores • Distributing RDF data: SPARQL endpoints o Available methods to distribute RDF data o SPARQL endpoints o Reuse of SPARQL queries o SPARQL communication protocol: requests and responses June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 2 Storing RDF data June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 3 Available methods to store RDF data • In-memory storage (local RAM) o Working memory of application (e.g. client side web app, desktop app) o Frameworks/libraries: RDFLib (Python), rdflib.js (JavaScript), N3 (JavaScript), rdfstore-js (JavaScript), Jena (Java), RDF4J (Java), dotNetRDF (.NET), etc. o Varied support for SPARQL querying • Persistent storage (storage drive) o RDF file/dump (diff. RDF serializations): TTL, RDF/XML, N-Quads, JSON-LD, N-triples, TriG, N3, TriX, RDFa (RDF embedded in HTML), etc. o RDF triplestore o (ontology editing applications: Protégé, Topbraid Composer, etc.) June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 4 RDF triplestores “a database to store and query RDF triples” • Member of the family of graph/NoSQL databases • Data structure: RDF • Main query language: SPARQL standards • Oftentimes support for RDFS/OWL/rules reasoning • Data storage is typically persistent June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 5 Triplestore applications – databases - default graph - named graphs • An RDF triplestore instance (application) can have one or multiple databases (repositories) • Each database has one default graph and zero or more named graphs o a good practice is to place TBox in a separate named graph.
    [Show full text]