Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Luca Faggianelli - Master Thesis in Electronic Engineering - University of Bologna

Design and implementation of an ontology agnostic historical repository for a semantic knowledge base

Luca Faggianelli

on 24 January 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Luca Faggianelli - Master Thesis in Electronic Engineering - University of Bologna

Web services
On demand contents
User's favorite shows
Web controlled
Diffuse music in rooms
Music from cloud
User musical taste
Electronic devices everywhere (Ubicomp),
interconnected to
make human interaction a pleasant experience
adapt their behaviors to user's context and on his profile.
Smart Environments
Semantic Web based Smart Environments
Main features:
Data organized in graphs (Semantic web)
TCP interface for high interoperability
Subscription and notification system for alerts on specific data change (allows device sleep). Obtained with low level TCP messaging protocol.
Open-source project for information sharing between software and devices. Maintained by ARCES.
Devices and sensors produce an amount of data that is difficult to handle:
big data
Main cause is continuous update of their status.
Up-to-date context representation: the last information overwrites the old one.
If the history is needed, it must be stored somewhere else.
Historical data
In many cases historical data is not important. In other it is.
"Just" save history in external DB
History Service concept
Centralized repository, with server-client interface
Existing solutions
Historical data is a well known problem: workarounds exist.
“Storing OWL Ontologies in SQL Relational Databases”
by Astrova, Korda, and Kalja
Ontology Agnostic History Service
It seems easy, but it is only the tip
Data handling
The graph must keep only fresh data to be fast and reactive.
Historical data must be held in another storage
Need of supplementary storage
Smart TV
Smart Lighting
Smart Music
Historical data to find water autonomy
Storage Requests
Read Requests
Clients issue requests to the service
Graph is accessed by anyone
Proper backup would load too much the historical DB, also would be useless.
Service interface is used for selecting which data is really needed in the historical repository
Main challenge
Graphs and relational databases belong to different realms, communication is difficult.
Why a Service?
Ontology Agnostic History Service
Thanks for your attention
Luca Faggianelli
Smart environments implemented with Smart-M3
Face the problem of storing a fixed, but not known, ontology on a SQL DB.
Do not take into account graph evolution over time
Do not care about data removal
Drafted rules for graphs to DBs mapping
Historical SQL DB
Graph DB
StorageRequest( )
ReadRequest( )
History Service subscribed to SPARQL graph.
When a change on main graph affects it...
...the sub-graph is converted into SQL using a mapping...
...and is written on the historical repository
The historical SPARQL...
...is converted in SQL.
The history DB is queried in SQL.
Historical data is in SQL format.
History is organized as a set of snapshots of the graph at different instants
History as Graph
History is physically stored in SQL DB
User interact with History through SPARQL
Ad-hoc solution that works only on a specific ontology

It is a working solution, but has several limits:
Works only on small sub-graphs
Not configurable
Gabriele Fittipaldi's thesis work
8 Jul 2013
18 Jul 2013
History DB accessed only by service
History Service
SQL database back end.
Requests issued using Smart-M3 messaging protocol.
I developed a system for storing and retrieving historical data of a graph.

I use a SQL DB for storing History, but users query it with SPARQL thanks to a conversion. Not all SPARQL features are currently supported.

I finally produced:
History Service Server script which can even run on a host different from the graph's one. (Python)
History Service Client library to import into user application for adding historical functionality. (Language independent, example library in Python)
Website for the documentation and for accessing GIT repository.
RDF graphs querable in SPARQL
Full transcript