Manfred Linking the Real World

Digital Enterprise Research Institute www.deri.ie

Linking the Real World
Manfred Hauswirth

Copyright 2011 Digital Enterprise Research Institute. All rights reserved.

Enabling networked knowledge

DERI’s Mission

Enabling & exploiting
Networked Knowledge


About DERI

 Founded June 2003 as a CSET (Centre for Science,
Engineering and Technology).
 Link scientists and engineers / academia and industry
 Fundamental research
 Development of Irish-based technology companies
 Attract industry
 Education & outreach
 DERI Institute
 CSET
 Commercialization, DAI
 EU, EI, direct industry, IRCSET
 DERI strategic plan responds to priorities
 Local: University focus on Informatics, Physical &
Computational Sciences
 National: SMART Economy, Program for Government
 International: EU Digital Agenda


About DERI

 Number one in our core space
 Research Publications > 1000
 Participation in 17 standardisation groups (W3C, OASIS)
 Approx. 140 members from 30 nations
 57 PhDs /Masters
 42 completed PhDs/Masters
 Core Industrial Partners:
 MNC’s: Cisco, Avaya, Bel-Labs, Ericsson…
 SME’s: Storm, Celtrak, OpenLink……
 Research: FBK
 Total Research Grants: > €60 million
 SFI, EU Framework, Enterprise Ireland, Industry
 Currently 18 EU project running
 Industry funded projects with Fujitsu Labs Japan, Cisco,
Google, Renault, EADS, Fidelity,…


Key Industry Collaborations

CSET Partners

6

DERI Innovation Approach

• Seevl
• Sindice.com
Spin Outs • Peracton

• Atom
• PEPPR
• IVEA Commerci-
alisation • Joint projects
• Patents and
Industry Licensing
• DERI Applied
Research Collaboration Innovation
Excellence
• W3C
• OASIS
• SIOC
• VOID, DCAT
• schema.org
• OData Standards • Drupal 7
Open • Semantic Desktop
• SIREn
Source
Prototypes


The DERI House

DERI Applied
Research Commercialisation

eBusiness Green &
eLearning
Financial Services Sustainable IT

Health Care Cyber
Data eGovernment
Life Sciences Security Linked
Cloud Analy
Data
tics
Information Security,
Cloud Data Sensor
Social Software Mining Privacy
Management Middleware
and Retrieval & Trust
Data Natural Service
Reasoning and Knowledge
Visualisation Language Oriented
Querying Discovery
and Interaction Processing Architecture

DERI is designed to provide an integrated solution


Solve which problem?


A Network of Knowledge

 Interconnected
 Universal
 All encompassing

 Assists humans,
organizations and systems in
problem solving
 Enable global and local
collaboration


A Network of Knowledge

 Interconnected
 Universal
All encompassing
•Application
• Search Research Domains
• Collaboration • Commercialization
• Information Mining
• Middleware
Linked Data

 assists humans,
organizations and systems
with problem solving
 enabling innovation and
increased productivity


Two Key Ingredients

1. RDF – Resource Description Framework
Graph based Data – nodes and arcs
 Identifies objects (URIs)
 Interlink information (Relationships)

2. Vocabularies (Ontologies)
 provide shared understanding of a domain
 organise knowledge in a machine-comprehensible way
 give an exploitable meaning to the data

12 of 46

Why Graphs and Ontologies?

Cities:Dublin
Geo:hasLargestCity
84421km2
Wikipedia.org Geo:IslandOfIreland
Geo:hasCapital
Geo:area
Geo:locatedOn

EU:RepublicOfIreland

EU:RepublicOfIreland
Gov:hasDepartment
Gov:hasTaoiseach
Gov.ie Person:EndaKenny
IE:DepartmentOfFinance


Linked Open Data Cloud

2008
2007 2008 2010
2009
2008 2009
2008

14
14

Linked Data Domains
BestBuy
http://lod-cloud.net/ Overstock.com
Facebook
Powered US government
UK government
by DERI! Media

User-generated

Government Publications
BBC
New York Times

Cross-domain
Geo
Life sciences

LinkedGeoData
Over 200 open data sets with more than 25 billion facts,
interlinked by 400 million typed links, doubling every 10 month!
Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch.

15

Challenges of Big Data

“90% of the data in the world today
has been created in the last two
years alone” – IBM

The bringing together of a vast
amount of data from public and
private sources […] is what Big Data is
all about,” – IDC


How to exploit Big Data?

Solutions required for
 Management and Integration
 Abstraction and Reasoning
 Analytics and Visualization
 Interaction and Collaboration
 Domain Knowledge
and
 Integration into a coherent
Framework!


Knowledge Dashboard

Analytics
Visualisation

Abstraction
Reasoning
Networked
Data


What is a Smart City?

 Invests in
 human and social capital
 traditional/modern infrastructure

 that
 fuels sustainable economic development
 and high quality of life

 while
 managing natural resources

 through
 participatory governance
http://ideas.repec.org/p/dgr/vuarem/2009-48.html


A Smart City removes silos moving
towards a connected digital layer.


Silos’ Value Untapped Value

http://www.mckinsey.com/mgi/publications/ig_data/pdfs/MGI_big_data_full_report.pdf


A Smart City driver of change will be Data.


The Problem


Goal

Streams are just yet another
form/source of linked data
 Semantic description of sensors, streams,
events, observations, etc.
 “Senso ergo sum” – semantic descriptions
down to the sensor level
 Web protocols down to the sensor level
 SPARQL-like access to streams and sensors
 Infrastructure framework


Keep it simple, Stupid!

Application := Data + Services

Application

LOD REST


KISS revisited

Application

CQELS REST SPARQL

Linked Streams Linked Data

Virtual COAP
Sensors Sensors



Where are we
right now?



Sensors, streams,
events, observations


W3C SSN XG

 Semantic Sensor Networks ontology to describe sensors
and sensor data

 Semantic annotations for OGC’s SWE Sensor Model
Language

 Motivations
 No existing sensor ontology included all the basic concepts
 Ease integration of (some) semantics in more spread languages
and standards (specifically SensorML)


Relation to existing
standards


SSN-XG Ontology Structure


SSN Application: SPITFIRE

•DUL: DOLCE+DnS Ultralite
•EventF: Event-Model F
•SSN: SSN-XG
•CC: Contextualised-Cognitive

Concepts on sensor network topology and
devices

Sensor Datasets

Event LOD Cloud
Datasets
Concepts on sensor role, events, sensor project


SPITFIRE Vocabulary

coalesenses

http://www.spitfire-project.eu


Size matters!

• OS + 6LowPAN + CoAP + Semantic description < 48kB?
• Processing power?


Storage requirements



OK, we can
describe sensors
and their data now


RESTful sensor
interfaces

 Standardisation
 Physical: 802.15.4
 Network: IEEE 6LoWPAN, ROLL
 Service layer:
– IETF CoRE (Constrained RESTful Environments):
CoAP protocol + extensions (very recent)
– Encoding (Extensible XML interchange - EXI, SensorML)
– Ontologies

 CoAP = Constrained Application Protocol
 IETF draft, http://tools.ietf.org/id/coap
 Core proposal + > 17 extensions


CoAP = HTTP for sensors


CoAP Example

 Accessing sensors from we browser using HTTP-CoAP
proxying – SPITFIRE Smart Service Proxy (SSP)



OK, we can access
sensors via RESTful
interfaces now


CQELS

 Continuous Query Evaluation over
Linked Streams
 Scalable processing model for unified
Linked Stream Data and Linked Open
Data
 Combines data pre-processing and an
adaptive cost-based query
optimization algorithm
 Experimental evaluation shows great
performance (w.r.t. response time
and scalability)


Black Box Approach

Query

Query rewriter
Optimizer

SPARQL-like
Operator implementations Orchestrator

Overhead
Executor
Data transformation
Execution

Access methods


EP-SPARQL and C-SPARQL

CSPARQL to SPARQL

EP-SPARQL to Prolog Query Rewriter

SPARQL
Query Rewriter Engine

Data
transformation

EP-SPARQL

C-SPARQL
Orchestrator
Orchestrator
RDF to Java objects
Prolog Engine Data
transformation
RDF to prolog facts

ESPER
Data
transformation
Query Rewriter
EP-SPARQL
CSPARQL to EPSER EPL
C-SPARQL


White Box Approach

Query

Adaptive Optimizer

Operator implementations

Adaptive Executor
Adaptive Execution

Native Access methods

RDF Linked
dataset datastream


Enabling adaptivity

 Incoming data will continuously change the costs of query plans
➥ Data elements are adaptively routed to processing operators on
equivalent data flows (routing policies)


Example


Processing Model:
Operators

 Triple-based window operators extracts triples
from RDF stream or dataset that
 match a given triple pattern
 are valid within in a time window

 Relational operators enable employing relational
algebras in the processing model
 Streaming operators generate new streams from
output of other operators based on graph
templates


Continuous Query Evaluation over
Linked Streams (CQELS)

Query CQELS language (an extension of SPARQL 1.1)

Caching and Indexing

Adaptive Optimizer

Operator implementations

Adaptive Executor
Adaptive Execution

SPO index scheme
Dictionary
Ring Triple-based
Dynamic Routing Policy Native Access methods indices for
windows

RDF Linked
dataset datastream


Techniques

 Dictionary encoding
 Smaller memory for representing triples
 Avoid lookup & decoding overhead for numeric RDF nodes
 Caching and Indexing
 Caching: avoid re-computing of intermediate results of sub-
queries over non-stream data.
 Indexing: facilitate faster access on caches and window data.
 Dynamic Routing Policy
 Incoming data can be evaluated in multiple equivalent data
flows adaptive to changes
 Easy & flexible support to implement routing policies


CQELS query language

CQELS Language – an extension to SPARQL 1.1

Construct new RDF stream Stream pattern


Experimental setup

 Conference scenario: combine linked stream from RFID tags
(physical relationships) with DBLP data (social relationships)

 Setup
 Systems: CQELS vs ETALIS and C-SPARQL
 Datasets
– Replayed RFID data from Open Beacon deployments
– Simulated DBLP by SP2Bench

 Queries: 5 query templates with different complexities
– Q1: selection,
– Q2: stream joins, Q3,Q4: Stream and non-stream joins
– Q5: aggregation

 Experiments
– Single query: generate 10 query instances of each template by varying the constants
– Vary size of DBLP dataset (104-107triples)
– Multiple queries: register 2M parallel instances (0≤M≤10)


Experiment results - Query
execution time

 CQELS performs faster by orders of magnitude

Query 1 Query 2 Query 3 Query 4 Query5

CQELS 0.47 3.90 0.51 0.53 21.83

C-SPARQL 332.46 99.84 331.68 395.18 322.64

ETALIS 0.06 27.47 79.95 469.23 160.83

Aggregation:
Simple selection: ETALIS performs best 15 times faster than C-SPARQL
Stream join: Stream and non-stream joins:
8 times faster than ETALIS
25 times faster than C-SPARQL
>600 times faster than C-SPARQL
8 times faster than ETALIS 150-850 times faster than ETALIS


Scalability: Static data size


Scalability: # of queries


Next steps

 Optimization
 Adaptive cost-based query optimization
 Inter-query optimization
 Smart and dynamic caching
 Adaptive caching
 Materialized view maintenance for dynamic data
 Scalability: clusters and cloud



OK, now we can also
process Linked
Streams and integrate
Linked Data efficiently


RDF-on-the-go
http://rdfonthego.googlecode.com/

 A single, integrated mobile phone data store for all
applications
 Intrinsically integrated with the Web (Linked Data)


RDF-on-the-go
http://rdfonthego.googlecode.com/


Business Card Demo

URI to FOAF file



OK, we can do all
that on mobile
phones too


Global Sensor Networks

Decrease the cost and complexity of sensor
network deployment

 Abstraction level
 Heterogeneous platforms  Abstract from data
producers

 Heterogeneous data  Data level
 Semantic description of
sensors and sensor data
 No common abstractions  Data integration

 Large scale
 Very large scale  Distributed query
processing and reasoning


Where are we now?

Global Sensor Networks
http://gsn.sourceforge.net/
WS
• Uniform, declarative abstractions
• Simple semantic descriptions
SOA • Supports all major platforms
• Fast and simple deployment
• Plug & play
GSN
• Zero-programming
• Efficient query processing


GSN’s view of the world

 Sensor network +
base computer =
sensor node
 Many sensor nodes
produce a lot of data on
the Internet
 Questions:
 Deployment
 Description
 Discovery
 Integration
 Distributed processing


Central abstraction:
Virtual sensors

 A virtual sensor can be any kind of data producer
 a real sensor, a wireless camera, a mobile phone, etc.

N input streams 1 (structured) output stream

processing

 a combination of other local or
remote virtual sensors

 Specification
 simple semantic descriptions of sensors and data streams
 declarative SQL-based specification of the data stream processing
 functional properties related to stream quality management, etc.


Virtual sensor definition:
XML + SQL Structure / data type
Digital Enterprise Research Institute
Meta-data of output stream www.deri.ie

<virtual-sensor name="room-monitor" priority="11"> <query>
<addressing> select AVG(temp1) as T1 from WRAPPER
<predicate key="geographical">BC143</predicate> </query>
<predicate key="usage">room monitoring</predicate> </stream-source>
</addressing> <stream-source alias="temperature2“
<life-cycle pool-size="10" /> storage-size="1m"
<storage permanent="true" history-size="10h" /> disconnect-buffer-size="10">
<output-structure> <address wrapper="remote">
<field name="image" type="binary:jpeg" /> Input stream 2:
<predicate key="type">
<field name="temp" type="int" /> System resources temperature
Temperature
</output-structure> </predicate>
<input-streams> to assign <predicate key="geographical">
<input-stream name="cam"> BC143-S Query over input
<stream-source alias="cam" storage-size="1"
disconnect-buffer-size="10">
</predicate>
</address>
streams to produce
<address wrapper="remote"> <query> output stream of
<predicate key="geographical">BC143</predicate> select AVG(temp2) as T2
<predicate key="type">Camera</predicate> from WRAPPER the Virtual Sensor
</address> </query>
<query>select * from WRAPPER</query> </stream-source>
</stream-source> <query>
<stream-source alias="temperature1“ select cam.picture as image, temperature.T1
storage-size="1m" as temp
disconnect-buffer-size="10"> from cam, temperature1
<address wrapper="remote"> where temperature1.T1 > 30 AND
<predicate key="type">temperature</predicate> temperature1.T1 = temperature2.T2
<predicate key="geographical">
BC143-N Input stream 1:
</query>
</input-stream>
Input stream 3:
</predicate>
</address> Camera images
</input-streams>
</virtual-sensor>
Temperature

70 of 58

Accessing sensors:
Wrappers

HTTP Generic Wrapper Generic UDP Wrapper
 HTTP GET or POST requests  UDP connections

Serial Forwarder Wrapper Generic Serial Wrapper
Local RS-232 connections
TinyOS compatible motes



TI-RFID Wrapper
USB Camera Wrapper
 Texas Instruments Series
 Local USB connection 6000 S6700 multi-protocol
RFID readers
Bluetooth Wrapper
 MAC and RFCOMM Bluetooth Generic RSS/XML Wrapper

GPSD Wrapper
COAP Wrapper
 More than 60 NMEA-compliant GPS devices
 RESTful interface to sensors
 Contiki, Coalesenses


Coding efforts

Wrapper type Lines of code

TinyOS 120

WiseNode 75

Generic UDP 45

Generic serial 180

Wired camera 300

Wireless camera (HTTP) 60

RFID reader (TI) 50


Selected Features

Workflow Editor
- Web-based design of
Virtual Sensors

SafeStorage
- Safe data backups


Plug and Play: Zero
Programming

 An IEEE 1451-compliant sensor provides a Transducer
Electronic Data Sheet (TEDS) which is stored inside the sensor
 TEDS provides a simple semantic description of the sensor
 the sensor's properties and measurement characteristic
 GSN uses the TEDS self-description feature for dynamic
generation and deployment of virtual sensor descriptions
 Next step: store queries not only data in TEDS or RFID tags

New level of data processing in terms of flexibility



Does it really work?


Experimental setup

 5 desktop PCs
 Pentium 4, 3.2GHz with 1MB
cache, 1GB memory, 100Mbit
Ethernet, Debian 3.1
 Linux kernel 2.4.27, MySQL
5.18
 SN-1: 10 Mica2 motes with light and
temperature sensors, packet size 15
Bytes, TinyOS
 SN-2: 8 Mica2 motes with light,
temperature, acceleration, and
sound sensors, packet size 100
Bytes, TinyOS
 SN-3: 4 Shockfish Tiny-Nodes with a
light and two temperature sensors
packet size 29 Bytes, TinyOS
 SN-4: 15 wireless 8002.11b cameras
(AXIS 206W), 640x480 JPEG, 5 with
16kB average image size, 5 with
32kB, 5 with 75kB
 SN-5: TI Series 6000 S6700 multi-
protocol RFID reader with three
different kind of tags (up to 8KB of
data)


Experimental setup

 2 1.8 GHz Centrino laptops with
1GB memory as observers
 Each ran up to 250 lightweight
GSN instances.
 Each instance produced random
queries with varying table names,
varying filtering condition
complexity, and varying
configuration parameters
 3 filtering predicates in the
WHERE clause on average, using
random history sizes from 1
second up to 30 minutes and
uniformly distributed random
sampling rates (seconds) [0.01, 1]
 Motes produce random bursts (1-
100 data items) with 25%
probability


Processing time per
client


Scalability in the number of
clients

79 of 58


OK, now we also have a
nice middleware /
database abstraction
for any sensor type



Putting it all together
Semantics / Linked Data / Real-Time / Streams / GIS


Linking the Real World

People in DERI scan QR code
with mobile to check into room

Position of people in DERI

 RFID tag of person is identified

 FOAF info is displayed

 Availability based on haptic
phone interface

QR code points to FOAF profile

Associated RFID tag

Associated mobile

Available Not Available
Position of other people
In the demo room


Behind the Scenes

www.deri.ie REST
(FOAF) where.deri.ie

REST
gsn.deri.ie (FOAF) REST
(availability)

REST
REST
(position)
(position)

REST
Screen
(position, availability)
Demo room
RFID base station



OK, now let’s make
it bigger and
general-purpose!


KISS re-re-visited

Application

Middleware
CQELS REST SPARQL

Linked Streams Linked Data

Virtual COAP
Sensors Sensors


Linked Sensor
Middleware

 Middleware for the semantic integration of live
real-world data
 SPARQL endpoint for querying unified Linked Stream Data
and Linked Data
 Sensor mashup composer
 Wrappers for collecting and enriching
real-time / stream (sensor) data
Live data
 Web interface for data
exploration, annotation and
visualisation
 Mobile phone applications


LSM Architecture


Linked Stream Model

Sensor metadata
:weatherStation
ssn:observes
ssn:observes
:aTemperature ssn:observedBy
:aHumidity
ssn:isPropertyOf ssn:isPropertyOf
:dublinAirport
ssm:observedPropery ssm:observedPropery
ssn:featureOfInterest

:latestWeather

:tempValue ssn:observationResult :humidValue

ssn:hasValue ssn:hasValue

ssm:value ssm:value ssm:unit
ssm:unit :readings

“18”^xsd:fl “60”^xsd:fl
“Celcius” “%”
oat oat
Stream data snapshot at 2011-07-08T21:32:52


Over 110,000 live data
sources

 Webcams:24570  Weather: 82365
 Traffic:469 (London,  Snowfall: 2639
Ohio)  Snow depth: 377
 Roadactivity:575 (Ohio)  Sea level: 45
 Flights: >1000  Radar:1
 Railway stations:251  Satellite: 12
(London)
 Bike hire:421(London)

… and growing!!!


Deployment

CQELS
Web
Virtuoso (Stream
server
Proc.)

Data Bus

Stream Sources


Mobile Applications

SPARQL,CQELS

SPARQL-XML/RDF

LSM
100-200 lines of code


LSM: Live flights info


LSM: Live train info


LSM: Live traffic info


http://lsm.deri.ie

 A demo is worth a thousand words


LSM Example
Application



OK, what’s next?


Across Research Areas

Semantic Web
Linked Data

Mobile Cloud

Internet of Things


Strategic Application
Domains

Smart Cities
Enterprise Environments

Telehealth


Upcoming Research
Areas

 Sensor data management in the Cloud

 Sensor data annotation and sharing (portals,
community-based)

 Social network analysis (online, mobile, real-world)

 Social and opportunistic sensing (mobile phone)

 Distributed query processing

 Integrating business processes and sensors

10
3

Conclusions

 “Linking the Real World”
requires cross-domain /
cross-layer research

 Non-trivial, open research
questions knowledge
management, Semantic
Web, databases, Cloud,
sensor networks, etc.

 Running systems and
experiments!


Acknowledgements

 Danh Le-Phuoc

 Anh Le Tuan

 Myriam Leggieri

 Hoan Nguyen Mau Quoc

 Josiane Xavier Parreira

 Martin Serrano

 Christian von der Weth


Manfred Linking the Real World

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Manfred Linking the Real World

Similaire à Manfred Linking the Real World (20)

Plus de sssw2012

Plus de sssw2012 (7)

Dernier

Dernier (20)

Manfred Linking the Real World