Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

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.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

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

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

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
Self-management
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
Light
Off
Status
Step#5
Position
Smart-M3
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
On
30%
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
about.me/lucafaggianelli
doc.tesladocet.com/historyservice
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
SQL
NoSQL
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...
SQL
...and is written on the historical repository
The historical SPARQL...
SQL
...is converted in SQL.
The history DB is queried in SQL.
SQL
Historical data is in SQL format.
History is organized as a set of snapshots of the graph at different instants
HistoryService
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.
SPARQL
SPARQL
Conclusions
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