1.
Progetto_4 Version 1.0 Date: 20/07/2017
1
Sviluppo di un Framework semantico
per la contestualizzazione delle activity
Authors
Michele Palumbo
[Mat. 0222600017]
Angelo Conte
[Mat. 0222600016]
Alessandro Russo
[Mat. 0222600006]
Università degli studi di Salerno
Disa-Mis “Business Innovation & Informatics”
Course of IT Safe and Awareness Systems
Year 2016/2017

2.
Progetto_4 Version 1.0 Date: 20/07/2017
2
Web Sematic Framework
INDICE
Introduzione ............................................................................................ 3
1.Richiami teorici: Situation Awareness............................................ 4
2.Problema, Scopo, tecnologie e linguaggi......................................... 7
2.1 Definizione del problema affrontato ................................................. 7
2.2 Scopo del problema .......................................................................... 9
2.3 Tecnologie utilizzate ...................................................................... 11
2.4 Linguaggi utilizzati......................................................................... 13
3.Sviluppo della Soluzione del Problema......................................... 14
3.1 Views ............................................................................................ 14
3.2 Queries ........................................................................................... 15
3.3 Result set ....................................................................................... 22
3.4 Schema di massima ............................................................................................28
4.Testing del sistema...................................................................................29
4.1 Testing Video_1 ............................................................................ 30
4.2 Testing Video_2 ............................................................................. 31
4.3 Testing Video_3 ............................................................................. 32
5.Considerazioni, conclusioni e sviluppi futuri ...................................33
5.1 Considerazioni per il miglioramento del sistema ........................... 33
5.2 Conclusioni e sviluppi futuri........................................................... 35

3.
Progetto_4 Version 1.0 Date: 20/07/2017
3
Introduzione
La Situation Awareness è quel processo di osservazione di persone, oggetti, aree di
diversa vastità in conformità a norme definite o comportamenti attesi, inclusa la
capacità di esercitare le funzioni di Comando & Controllo in reazione al verificarsi di
un’activity (evento). In particolare, questa tematica è incentrata sul rilevamento
automatico di eventi anomali, il riconoscimento di potenziali minacce, e la capacità di
reazione (comando e controllo) in scenari complessi.
L’obiettivo di questo documento è quello di presentare un sistema di tracciamento di
oggetti nell’ambito dello sviluppo di activity complesse.
Nel capitolo 1 faremo un breve richiamo teorico sulla Situation Awareness in cui
fisseremo concetti legati alla percezione, comprensione e proiezione.
Nel capitolo 2 definiremo il contesto e il problema da affrontare partendo da
un’analisi di un algoritmo di video-tracking, passando alla descrizione e definizione
dei concetti più significativi quali, algoritmo di video-tracking e track,
RDF (Resource Description Framework), ontologia, activity semplice e complessa,
bounding box, punto di interesse, etc. Inoltre, faremo una panoramica per quel che
riguarda le tecnologie (Apache Jena) e i linguaggi utilizzati (OWL “Ontology Web
Language, SPARQL “Protocol and RDF Query Language”, JAVA).
Successivamente, passeremo allo sviluppo del problema che verrà affrontato nel
capitolo 3. In questo capitolo, presenteremo le queries implementate ed il loro
significato con annesso codice (commentato riga per riga) e ne mostreremo il
risultato a video, attraverso degli screenshot riepilogativi. In aggiunta, mostreremo
uno schema di massima di soggetti, predicati ed oggetti individuati in una scena.
Nel capitolo 4, illustreremo il testing effettuato sui quattro file associati ai 4 video
fornitoci ad inizio progetto.
Infine, nel capitolo 5, forniremo delle considerazioni per il miglioramento del
sistema e sviluppi futuri.

4.
Progetto_4 Version 1.0 Date: 20/07/2017
4
1.Richiami teorici: Situation Awareness
La Situation Awareness, non è altro che il sapere cosa sta accadendo attorno a sé.
Rispetto a questa definizione il ruolo importante è giocato dalla parola “cosa”.
É ovvio che l’oggetto SA (Situation Awareness) è dominio specifico, ad esempio per
un pilota di aerei conoscere il numero di scarpe o l’altezza del suo copilota
(informazioni che pur fanno parte del sistema di cui è protagonista) non è funzionale al
compito che deve portare a termine; sarà importante, invece, la mole di informazioni
legate al compito principale di pilotare l’aereo in modo sicuro.
Quindi possiamo definire la Situation Awareness come “la percezione degli elementi
in un ambiente all’interno di un volume di spazio e tempo, la comprensione del loro
significato e la proiezione del loro stato nell’immediato futuro”.

5.
Progetto_4 Version 1.0 Date: 20/07/2017
5
Essa è dunque formata da tre livelli:
➢ Percezione: La percezione degli indizi ambientali è la base della SA (Situation
Awareness). Senza la percezione basilare delle informazioni importanti, il
pericolo di formarsi un’immagine incorretta della situazione incrementa
drammaticamente.
I problemi a questo livello consistono nelle difficoltà di reperimento
dell’informazione, dovute o ad erronei processi cognitivi, o a problemi legati alla
rappresentazione dell’informazione nel sistema.
➢ Comprensione: La SA (Situation Awareness) va oltre la semplice percezione.
Riguarda anche il come le persone combinano, interpretano, immagazzinano e
richiamano l’informazione.
Pertanto la SA (Situation Awareness) include più del percepire e prestare
attenzione, infatti consiste anche nell’integrazione di svariati pezzi di
informazione e nella determinazione della loro rilevanza in relazione ai propri
obiettivi.

6.
Progetto_4 Version 1.0 Date: 20/07/2017
6
➢ Proiezione: L’abilita di predire gli eventi e le dinamiche della situazione futura
caratterizza l’operatore che ha il più alto livello di comprensione della situazione.
L’abilità di anticipare gli eventi e le dinamiche future permette una presa di
decisione temporalmente adeguata.
Questo è il livello dell’operatore esperto.
Perché è importante parlare di Situation Awareness?
Pensiamo a come un giocatore di calcio percepisce la tattica della propria squadra,
oppure a come prende decisioni; pensiamo a un qualunque operatore che si trovi di
fronte ad un compito; è vitale comprendere il come egli si percepisca all’interno della
situazione, e come percepisca, comprenda e immagini la situazione, sia per l’esito
positivo del portare a termine il compito di lavoro, sia per la ristrutturazione del compito
stesso e per la formazione degli operatori , sia per la progettazione delle interfacce
esistenti tra l’uomo e l’ambiente (ad es. la riprogettazione di software).

7.
Progetto_4 Version 1.0 Date: 20/07/2017
7
2.Problema, scopo, tecnologie e linguaggi
2.1 Definizione del problema affrontato
Partendo da un’analisi di un algoritmo di video-tracking, abbiamo ricevuto, come
output, un file. Questo file è stato ulteriormente partizionato per permettere di inserire
i tag che vengono fuori dalle tecnologie semantiche.
Il file corredato con i tag semantici, ci viene dato come estensione rdf, che costituisce
l'ontologia, dalla quale abbiamo, successivamente, sviluppato le queries.
• Gli algoritmi di video-tracking riconoscono il medesimo oggetto in ogni
immagine della sequenza video in cui è presente al fine di determinare in ogni
istante la sua posizione (velocità ed eventualmente altri parametri).
Le caratteristiche dell’algoritmo di video-tracking sono fondamentali per la
qualità delle prestazioni dell’analisi video.
Per track si intende il tracciato dell’activity.
• Per RDF (Resource Description Framework) si intende una particolare
applicazione XML deputata alla gestione delle relazioni tra informazioni,
ispirandosi ai principi della logica dei predicati e ricorrendo agli strumenti tipici
del Web (ad es. URI) e dell'XML (namespace).
In estrema sintesi, secondo la logica dei predicati, le informazioni sono
esprimibili con asserzioni (statement) costituite da triple formate da soggetto,
predicato e valore (noti anche come subject, predicate e object,
rispettivamente).
RDF lavora, quindi, con tre tipi di elementi fondamentali:
- Risorse: entità riferite attraverso URI
- Proprietà: relazioni binarie tra risorse e/o valori atomici di tipo primitivo
- Affermazioni: specificano il valore di una certa proprietà relativa a una risorsa.

8.
Progetto_4 Version 1.0 Date: 20/07/2017
8
• Per ontologia si intende, un modello di rappresentazione formale della realtà e
della conoscenza. È una struttura di dati che consente di descrivere le entità
(oggetti, concetti, ecc.) e le loro relazioni in un determinato dominio di
conoscenza.
Ritornando al problema, più in dettaglio, abbiamo estratto informazioni
concentrandoci sulle activity complesse, per risalire alle azioni salienti per quanto
riguarda le situazioni di imminente pericolo, ad esempio, persone che attraversano,
macchine che si spostano sulla strada, etc., le quali denotano una situazione di
potenziale pericolo.
Inoltre, abbiamo rilevato anche situazioni pericolose già accadute (incidenti), ad
esempio, macchine che decelerano, persone che camminano in gruppi, etc., in quanto
ci possono essere persone che si raggruppano e soccorrono la vittima del sinistro
stradale.
Abbiamo esaminato questo tipo di situazioni sulla base di statement (asserzioni)
modellati dal gruppo del PROGETTO_3, il quale ci ha fornito il modello sul quale
sviluppare il nostro framework che prevede la restituzione dei risultati finali delle
situazioni analizzate.

9.
Progetto_4 Version 1.0 Date: 20/07/2017
9
2.2 Scopo del problema
Lo scopo del problema affrontato è stato quello di definire un framework per l’analisi
delle relazioni tra le activity complesse di un dato oggetto rispetto a:
1. Spazio
2. Tempo
3. Contesto (relazioni con POI e Oggetti)
Il problema è stato affrontato con l’utilizzo di queries sulle activity complesse, le
quali sono un insieme di activity semplici (triple costruite su di una specifica
relazione tra due oggetti, in uno specifico intervallo di tempo) relazionate in base al
tempo o allo spazio, e ci consentono di fare delle ricerche all’interno delle finestre
temporali.
Quindi, ricapitolando:
• Activity semplice
Si intende, una tripla basata su una specifica relazione tra due oggetti, in uno
specifico intervallo di tempo.
• Activity complessa
Si intende, un insieme di activity semplici relazionate in base al tempo o allo
spazio.

10.
Progetto_4 Version 1.0 Date: 20/07/2017
10
➢ Esempio di queries:
• BB2 negli intervalli t_1 - t_4
• BB2 crossing POI 1. nell'intervallo di tempo t_1
• BB2 grouping BB3. nell'intervallo di tempo t_3
- BB2 e BB3 rappresentano i bounding box, cioè il rettangolo di selezione degli
oggetti, che vengono fuori dall’algoritmo di video-tracking, e possono
racchiudere persone o veicoli.
- POI 1 è il punto di interesse, e rappresentano oggetti immobili come, ad
esempio, la strada, il parco etc.
➢ Esempio raffigurativo:

11.
Progetto_4 Version 1.0 Date: 20/07/2017
11
2.3 Tecnologie utilizzate
• Apache Jena
Apache Jena (o semplicemente Jena) è un framework scritto in Java per lo sviluppo di
applicazioni orientate al semantic web ed ai linked data.
L'architettura, visualizzata nella figura qui sotto, è organizzata a strati e consiste di un
insieme di API, che permettono di sfruttare a pieno gli standard definiti da W3C.
Pertanto, tutte le informazioni sono memorizzate come triple RDF (Resource
Description Framework) in grafi diretti, secondo il pattern subject- predicate-object
(SPO).
La stratificazione delle API è chiaramente evidente

12.
Progetto_4 Version 1.0 Date: 20/07/2017
12
• lo strato che si occupa della gestione delle triple RDF, delle ontologie e delle
query SPARQL, scambia i dati con lo strato sottostante per poterne fare
inferenza, per mezzo di un determinato reasoner;
• lo strato che si occupa della gestione e della configurazione di motori e regole
di inferenza per RDFS ed OWL, fornisce le funzionalità principali per gestire
le triple RDF e gli schemi ontologici allo strato sovrastante ed i dati allo strato
sottostante, che ne provvederà alla memorizzazione secondo una determinata
strategia.

13.
Progetto_4 Version 1.0 Date: 20/07/2017
13
2.4 Linguaggi utilizzati
• OWL (Ontology Web Language)
È un linguaggio di markup per rappresentare esplicitamente significato e semantica di
termini con vocabolari e relazioni tra gli stessi.
• SPARQL (Protocol and RDF Query Language)
È un linguaggio di interrogazione per dati rappresentati tramite il Resource
Description Framework (RDF).
• JAVA
È un linguaggio di programmazione orientata ad alto livello, orientato agli oggetti e
tipizzazione statica, progettato per essere il più possibile indipendente dalla
piattaforma di esecuzione.

14.
Progetto_4 Version 1.0 Date: 20/07/2017
14
3.Sviluppo della soluzione del problema
3.1 Views
Le viste vengono implementate mediante le query. Successivamente, vengono
applicate le spinrule per fare inferenza sulle activity complesse.
Quindi, sostanzialmente, grazie alle spinrule ottengo altre inferenze, cioè altre
informazioni.
Nella foto possiamo vedere come abbiamo realizzato le viste, in pratica andiamo a
prendere gli eventi coincidenti come spiegato in figura.

15.
Progetto_4 Version 1.0 Date: 20/07/2017
15
3.2 Queries
In questa sezione mostriamo le queries sviluppate ed il loro significato.
Per maggiori dettagli e approfondimenti, il lettore può leggere i singoli commenti nelle
righe del codice di ogni query.
Vediamo adesso un esempio di query realizzate con il framework Jena:
Sia T la finestra temporale e siano T1, T2 e T3 delle partizioni per esempio di
T di 500 sec
Vogliamo sapere:
- Cosa è avvenuto nella partizione T1?
- Cosa è avvenuto nella partizione T2?
- Cosa è avvenuto nella partizione T3?

16.
Progetto_4 Version 1.0 Date: 20/07/2017
16
QUERY #1
Nella QUERY n°1, rileviamo le situazioni di imminente pericoli, ossia incidenti non
ancora avvenuti.
In particolare, cerchiamo persone che attraversano la strada e veicoli che transitano
sulla strada nello stesso intervallo di tempo.
Questa situazione che può denotare un pericolo imminente.

17.
Progetto_4 Version 1.0 Date: 20/07/2017
17
QUERY #2
Con la QUERY n°2, rileviamo incidenti già avvenuti.
In particolare, cerchiamo gruppi di macchine che decelerano in gruppo (slowDown) e
più gruppi di persone che rallentano (grouping) sulla strada, nello stesso intervallo di
tempo.
Questa situazione può denotare un incidente già avvenuto, dove le persone, ad
esempio, si raggruppano per soccorrere una vittima.

18.
Progetto_4 Version 1.0 Date: 20/07/2017
18
QUERY #3
Nella QUERY n°3, troviamo le auto in panne sulla strada.
In particolare, le auto che escono fuori strada (runningOff), in presenza di persone o
di altri veicoli in una scena con lo stesso intervallo temporale.
Questa situazione può denotare un pericolo d’incidente stradale.

19.
Progetto_4 Version 1.0 Date: 20/07/2017
19
QUERY #4
Con la QUERY n°4, cerchiamo auto che si fermano sulla strada (ParkingOnRoad) in
presenza di altri veicoli o persone nelle vicinanze nello stesso intervallo temporale.
Questa situazione può denotare una situazione di pericolo di tamponamento.

20.
Progetto_4 Version 1.0 Date: 20/07/2017
20
QUERY #5
La QUERY n°5, effettua un conteggio sulle istanze di imminente pericolo nella
finestra temporale.
In particolare, persone che attraversano la strada e auto che transitano nello stesso
intervallo di tempo. Questa situazione può denotare un pericolo di sinistro stradale.

21.
Progetto_4 Version 1.0 Date: 20/07/2017
21
QUERY #6
Nella QUERY n°6, contiamo gli incidenti già avvenuti.
In particolare, auto che rallentano e persone che rallentano il loro passo per poi
raggrupparsi perché, ad esempio, stanno per soccorrere una vittima.

22.
Progetto_4 Version 1.0 Date: 20/07/2017
22
3.3 Result Set
In questa sezione, il lettore può vedere alcuni screenshot relativi ai result set, delle
query realizzate in SPARQL viste precedentemente.
SCREEN RESULT QUERY #1
Inserendo un intervallo temporale di 500 secondi il sistema stampa a video i seguenti
result set per la query di ricerca di persone che compiono azioni nello spazio e nella
finestra temporale.

23.
Progetto_4 Version 1.0 Date: 20/07/2017
23
SCREEN RESULT QUERY #2
Inserendo un intervallo temporale di 500 secondi il sistema stampa a video i seguenti
result set per la query di ricerca di veicoli che compiono azioni, nello spazio e nella
finestra temporale.

24.
Progetto_4 Version 1.0 Date: 20/07/2017
24
SCREEN RESULT QUERY #3
Inserendo un intervallo temporale di 500 secondi il sistema stampa a video i seguenti
result set per la query di ricerca di oggetti che subiscono delle azioni da parte del
soggetto, nello spazio e nella finestra temporale.

25.
Progetto_4 Version 1.0 Date: 20/07/2017
25
SCREEN RESULT QUERY #4
Inserendo un intervallo temporale di 500 secondi il sistema stampa a video i seguenti
result set per la query di ricerca di situazioni di pericolo sia da parte di umani che di
veicoli.

26.
Progetto_4 Version 1.0 Date: 20/07/2017
26
SCREEN RESULT QUERY #5
Inserendo un intervallo temporale di 500 secondi il sistema stampa a video i seguenti
result set per la query che conta istanze di imminente pericolo nella finestra
temporale.

27.
Progetto_4 Version 1.0 Date: 20/07/2017
27
SCREEN RESULT QUERY #6
Inserendo un intervallo temporale di 500 secondi il sistema stampa a video i seguenti
result set per la query che conta istanze di incidenti avvenuti nella finestra
temporale.

28.
Progetto_4 Version 1.0 Date: 20/07/2017
28
3.4 Schema di massima
Asserzione RDF che definisce uno schema di massima di soggetti, predicati ed
oggetti individuati in una scena, senza tener conto della cadenza temporale.

29.
Progetto_4 Version 1.0 Date: 20/07/2017
29
4.Testing del sistema
In questo capitolo, sono illustrati i test svolti per ognuno dei quattro file relativi ai
corrispettivi video.
Per fare il testing abbiamo utilizzato la spin function (spin: timeRelationS) per il
calcolo dell’istante d’inizio e la spin function (spin: timeRelationE) per il
calcolo dell’istante di fine di un activity.
La spin function spin:timeRelationS e spin:timeRelationE
• Id del track
• Un track poi
• la relazione, ossia il predicato dell’asserzione
In particolare, abbiamo verificato se le activity complesse (di cui vogliamo
calcolare la durata) erano effettivamente presenti nella knowledge base.
In parole povere, ci siamo calcolati la durata dell’activity attraverso la durata dei
frame, e poi abbiamo verificato se la durata dell’activity 1 coincideva con quella
dell’activity 2.
Più precisamente, abbiamo verificato se le macchine passavano nello stesso istante
di quando attraversava una persona.
Il testing, come anticipato, è stato effettuato sui quattro file associati ai quattro
video.

30.
Progetto_4 Version 1.0 Date: 20/07/2017
30
Abbiamo definito le seguenti query che restituiscono un grafo rdf ricavato tramite
la clausola CONSTRUCT:
4.1 Testing Video_1
In questo test sul video_3, possiamo vedere che thingObject_88 è un veicolo che
transita sulla strada mentre thingObject_402 è una persona che attraversa la strada

31.
Progetto_4 Version 1.0 Date: 20/07/2017
31
4.2 Testing Video_2
In questo test sul video_2 possiamo vedere che thingObject_407 e thingObject_88
sono veicoli che transitano sulla strada mentre thingObject_94 e thingObject_7
sono persone che attraversano la strada.

32.
Progetto_4 Version 1.0 Date: 20/07/2017
32
4.3 Testing Video_3
In questo test sul video_3 possiamo vedere che thingObject_402 e thingObject_407
sono veicoli che transitano sulla strada mentre thingObject_423 è una persona che
attraversa la strada, e quindi può denotare una situazione d’incidente stradale.

33.
Progetto_4 Version 1.0 Date: 20/07/2017
33
5.Considerazioni, conclusioni e sviluppi futuri
5.1 Considerazioni per il miglioramento del sistema
Seguendo le analisi e valutazioni effettuate in tutto il periodo di lavoro a questo
progetto (seppur breve) abbiamo individuato dei possibili miglioramenti da apportare
al sistema.
Sicuramente, si potrebbe migliorare la gestione della finestra temporale.
Allo stato attuale, infatti, il sistema permette di esaminare le activity complesse in
diversi range di tempo, dati da una cadenza temporale fissa inserita da tastiera.
Ad esempio (come possiamo notare nei Result Set del capitolo precedente), fissiamo
da tastiera una cadenza temporale di 500ms, la quale verrà rispettata per tutti i range
successivi fino alla fine dell’esaminazione.
• Problema
C’è la possibilità di perdita di informazioni riguardo alle activity complesse a
cavallo di due range.
Ad esempio, se esamino un video ogni 50 secondi e vi è un’activity complessa che
inizia dal secondo 45 al secondo 55, il sistema non la trova.
• Soluzione
Abbiamo individuato un paio di idee risolutive, di cui la prima è stata sviluppata.
1. Allargare la finestra temporale in modo da riuscire ad esaminare un range più
ampio. Risoluzione parziale del problema.

34.
Progetto_4 Version 1.0 Date: 20/07/2017
34
2. È l’idea verso cui ci siamo proiettati sin da subito.
Data una cadenza temporale specifica, riuscire ad esaminare range per range
tutto ciò che succede in quel determinato range corrispondente:
➢ inizio e fine di un activity
➢ inizio di un’activity ma non ancora conclusa (l’altra parte si esamina nel
range successivo)
➢ fine di un’activity iniziata nel range precedente
Ad esempio, voglio esaminare due range (range1 e range2).
Ho una cadenza temporale di 30 secondi ed ho un’activity che inizia dal
secondo 15 e finisce al secondo 40.
In questo caso il sistema:
Nel range1, dovrà >>>
- mostrare l’inizio dell’activity
- dare informazioni dal secondo 15 al secondo 30
- segnalare la continuazione dell’activity
Nel range2, dovrà >>>
- recepire la segnalazione di continuazione dell’activity
- dare informazioni dal secondo 30 al secondo 40
- mostrare la fine dell’activity

35.
Progetto_4 Version 1.0 Date: 20/07/2017
35
5.2 Conclusioni e sviluppi futuri
Le query, come sono state applicate per rilevare situazioni di pericolo per quanto
concerne il traffico stradale in cui possono esserci vari soggetti come ad esempio, una
persona, un veicolo, un mezzo di aviazione (elicottero, etc…), possono essere applicate
anche per rilevare situazioni di pericolo nel traffico marittimo, come ad esempio
collisioni tra barche, tra navi in prossimità di un porto.