(LUẬN VĂN THẠC SĨ) Ontologie d’événements vidéos pour un système automatique d’interprétation vidéo

Mémoire de fin d’études

Ontologie d’événements vidéos pour un
système automatique d’interprétation vidéo

Réalisé par

PHAM Le Son

Sous la direction de

Monique THONNAT
Nicolas MAILLOT

Sophia-Antipolis, Septembre 2004

TIEU LUAN MOI download :


2

Remerciements

Je tiens à remercier Monique Thonnat et Nicolas Maillot qui m’ont accueilli dans leur équipe et
m’ont encadré pendant mon stage avec enthousiasme.
Je tiens à remercier toutes les personnes de l’équipe ORION, particuliốrement Thinh Vu Van,
Franỗois Brộmond, Florent Fusier, Julien Canet, Christophe Tornieri et Alberto Avanzi pour
leurs aides et les discussions qui ont fait progresser mon travail.
Merci également à Thanh Le Bach et Fabient Gandon de l’équipe ACACIA pour leurs conseils
précis et les discussions intéressants que j’ai eu avec eux.
Enfin, je tiens à remercier l’Institut de la Francophonie pour l’informatique – IFI qui m’a aidé à

effectuer mon stage de fin d’étude à l’INRIA Sophia Antipolis.

TIEU LUAN MOI download :


3

Résumé

Ce rapport traite du problème de la définition d’une ontologie d’événements vidéos utilisables
par une plate-forme d’interprétation automatique de séquences vidéos. Une grande difficulté
dans la construction d’une telle otologie est qu'il n'y a pas encore une plateforme standard. Pour
résoudre ce problème, les ontologies sont formalisées dans le langage VERL (Video Event
Representation Language). Au lieu d’utiliser XML pour représenter les ontologies comme
l’auteur de VERL, nous avons transformé des expressions de VERL sur OWL (Web Ontology
Language). Grâce à cela, l'ontologie a un sémantique clair et peut être plus facilement partagée
et réutilisée entre des communautés. Nous avons créé également un outil graphique d'acquisition
de connaissance, utilisant cette ontologie, pour aider les experts à définir des événements
d'intérêt dans des domaines d’application spécifiques. A l’aide de l’ontologie d’événements
vidéos, un expert peut créer, gérer et manipuler des événements complexes relatifs à son
domaine. Cette 'outil est utilisé pour définir les événements vidéos dans l'application de la
surveillance en agence bancaire. Malgré des résultats prometteurs, il reste encore des problèmes
non résolus, par exemple, comment enfoncer l'ontologie dans les moteurs d'inférence
disponibles dans les cadres standard de représentation tels que SWRL (Semantic Web Rule
Language).

Mots clés
Ontologie, événement vidéo, OWL, VERL, représentation de connaissances, acquisition de
connaissances

TIEU LUAN MOI download :


4

Abstract

In the thesis, we propose an event ontology that can be used for an Automatic Video
Interpretation system. The main obstacle is that there is no standard framework for defining
event ontologies. To solve this issue, we first use the VERL (Video Event Representation
Language) to describe the ontology as a formalization step. Then, these concepts are
transformed in OWL (Web Ontology Language), a standard language of ontology. So, the
ontology not only has a clear semantic but also can be shared and reused among communities
easily. We also introduce a graphical ontology-based knowledge acquisition tool which allows
the domain experts to understand, manage and manipulate events of interest for video
interpretation. The tool is used to define video events in the banking monitoring application.
Despite of promising results, however, there are still open problems needed further researches,
for example, how to embed the ontology in the inference engines available in standard
representation frameworks such as SWRL (Semantic Web Rule Language).

Key words
ontology, video event, OWL, VERL, knowledge representation, knowledge acquisition.

TIEU LUAN MOI download :


5

Table des matières
CHAPITRE 1:

INTRODUCTION........................................................................................ 8

1.1 Contexte du travail .......................................................................................................... 8
1.2 VSIP : Un système automatique d'interprétation vidéo................................................... 8
1.3 Langage de Description de Scénarios de l’équipe ORION............................................. 9
1.4 Objectifs ........................................................................................................................ 10
1.5 Contenu du rapport ....................................................................................................... 10
CHAPITRE II:

ETAT DE L’ART....................................................................................... 11

2.1 L'ontologie ..................................................................................................................... 11
2.1.1 La notion d’ontologie .............................................................................................. 11
2.1.2 Pourquoi construire des ontologies ?..................................................................... 11
2.1.3 Le processus de création d’une ontologie ........................................................... 12
2.1.4 Vue d'ensemble des langages d'ontologie............................................................. 14
2.2 La représentation d’événements vidéos ....................................................................... 16
2.2.1 Revue de la bibliographie de la représentation d’événements vidéos .................. 16
2.2.2 VERL : Une langage de la représentation d’événements vidéos .......................... 17
2.3 Conclusion..................................................................................................................... 18
CHAPITRE 3 : ONTOLOGIE D’EVENEMENTS VIDEOS................................................ 19
3.1 Vue d’ensemble de la méthodologie............................................................................. 19
3.2 Conceptualisation du domaine...................................................................................... 19
3.2.1 Des objets physiques ............................................................................................. 19
3.2.2 Relations spatiales ................................................................................................. 20
3.2.3 Etats et événements vidéo..................................................................................... 21
3.2.4 Relations temporelle .............................................................................................. 21
3.3 Représentation des événements sur VERL.................................................................. 21
3.3.1 Définition hiérarchique des concepts ..................................................................... 22

3.3.2 Représentation des états et événements sur VERL.............................................. 22
3.4 L’implémentation de l’ontologie sur OWL ..................................................................... 23
CHAPITRE 4 : UN OUTIL D’ACQUISITION DE CONNAISSANCES ............................. 26
4.1 Structure de l’outil ......................................................................................................... 26
4.2 Fonctionnalités de l’outil................................................................................................ 26
4.3 Etude de cas : la représentation de l’événement de l’attaque en agence bancaire ..... 27
4.4 Résultat obtenu ............................................................................................................. 29
CHAPITRE 5:

CONCLUSION & PERSPECTIVES ......................................................... 30

5.1 Conclusion..................................................................................................................... 30

TIEU LUAN MOI download :


6
5.2 Perspectives.................................................................................................................. 30
BIBLIOGRAPHIE................................................................................................................ 31
ANNEX : REPRESENTATION DE L’ONTOLOGIE SUR VERL ........................................ 33

TIEU LUAN MOI download :


7

Table des figures

Figure 1 : Structure simplifiée d’une plate-forme d’interprétation vidéo.............................................8
Figure 2 : Structure du système automatique d'interprétation vidéo VSIP..........................................9

Figure 3 : Le cycle de vie d’une ontologie...............................................................................................12
Figure 4 : Exemple de représentation XML..........................................................................................14
Figure 5 : Exemple de représentation RDF...........................................................................................14
Figure 6 : Représentation d’un graphe de triplets.................................................................................15
Figure 7 : Exemples d’objets physiques..................................................................................................20
Figure 8 : Exemple des relations spatiales..............................................................................................20
Figure 9 : L’arbre des objets physiques (a) et l’arbre des relations spatiales et temporelles (b) ......26
Figure 10 : La fenêtre principale de l’outil ............................................................................................27
Figure 11 : Définition d’un objet physique.............................................................................................27
Figure 12 : Définition d’un composant ...................................................................................................28
Figure 13 : Définition une contrainte......................................................................................................28
Figure 14 : Détection de l'événement de l’attaque en agence bancaire utilisant des scénarios définis
par l’outil graphique........................................................................................................................29
Figure 15 : L’événement vidéo attaque en agence bancaire obtenu grâce à l’outil d’acquisition de
connaissances ...................................................................................................................................29

TIEU LUAN MOI download :


8

CHAPITRE 1: INTRODUCTION
1.1

Contexte du travail

Depuis plusieurs années, une partie de l'équipe Orion de l'Inria Sophia-Antilolis concentre ses
efforts sur la construction d’une plate-forme d'interprétation automatique de séquences vidéos
pour la reconnaissance de comportements humains (ex. situation de violence, attaque en agence
bancaire). Une version simplifiée d’une plate-forme d'interprétation automatique de séquences

vidéos est donnée dans la figure 1. L’objectif de ce système est de reconntre des événements
vidéos définis à priori à partir d’un flux vidéo.

Flux
vidéo

Module
vision

Module de
reconnaissance
d’événements vidéos

Evénements
vidéos
reconnus

Figure 1 : Structure simplifiée d’une plate-forme d’interprétation vidéo.

Lors de la construction d’une plate-forme d’interprétation vidéo, un des problèmes rencontré est
celui de la représentation et de la définition d’événements vidéos d’intérêt.
Dans la plate-forme de l’équipe (VSIP), la définition d’événements vidéos se fait actuellement
par le biais d’un langage de description qui n’est facile d’accès pour un non informaticien. Pour
faciliter ce processus d’acquisition de connaissances, l’équipe s’intéresse à la construction
d'ontologies pour représenter les concepts utiles pour la définition d’événements vidéos. Il s’agit
de construire une ontologie d'événements vidéos fournissant une base sémantique et un
vocabulaire conceptuel consensuel utile pour définir des événements vidéos complexes. Cette
ontologie d'événements vidéos permet à l'utilisateur de comprendre les termes employés pour
décrire des événements vidéos sans être concerné par la problématique du traitement d'image.
De plus, l’ontologie d'événements vidéos facilite la communication entre les experts d’un

domaine (ex. experts de la sécurité en agence bancaire), et les développeurs de systèmes de
interprétation automatique de séquences vidéos. Une telle ontologie est également utile pour
partager et réutiliser des modèles d’événements.
Enfin, cette ontologie d'événements vidéos est utile pour évaluer les systèmes d'interprétation
automatique de séquences vidéos et pour comprendre quels types d'événements ces systèmes
sont capable de reconntre.

1.2 VSIP : Un système automatique d'interprétation vidéo
Nous avons introduit nos intérêts sur la construction d’une plate-forme d'interprétation
automatique de séquences vidéos pour la reconnaissance de comportements humains. Dans cette
section, nous allons présenter notre système automatique d’interprétation vidéo.
VSIP, le système automatique d'interprétation vidéo de l’équipe ORION est décrit dans la figure
2. Le système prend comme entrée les connaissances à priori comprenant des événements
vidéos d’intérêt prédéfinis par des experts, l'information géométrique 3D et la sémantique
relative à l’environnement. En cours d’utilisation du système, le flux vidéo acquis par une
camera constitue une entrée du système. Le sortie du système est l'ensemble des événements

TIEU LUAN MOI download :


9
vidéos identifiés (ex. attaque en agence bancaire). Le module de reconnaissance de scénario est
décrit dans [Vu et al. 2003].
Notre objectif est de proposer une ontologie d’événements vidéos ainsi qu’un outil d’acquisition
de connaissances afin de faciliter la définition d’événements vidéos d’intérêt. Les chapitres 3 et
4 de ce rapport présentent respectivement une ontologie d’événements vidéos et un outil
d’acquisition de connaissances.

La connaissance à priori

Information
géométrique et
sémantique relative à
l’environnement

Flux
vidéo

Evénements vidéos
d’intérêt définis par
des experts

Module

Module de Reconnaissance

Evénements

Vision

d’événements vidéos

Vidéos
Reconnus

Figure 2 : Structure du système automatique d'interprétation vidéo VSIP

1.3 Langage de Description de Scénarios de l’équipe ORION
Des événements vidéos sont représentes par le Langage de Description de Scénarios développé
dans l’équipe ORION.

Il y a deux types principaux de concepts : les objets physiques observés dans la scène et les
événements vidéos apparaissant dans la scène.
•

Un objet physique peut être un objet statique (ex. bureau) ou un objet mobile (ex. personne,
voiture).

•

Un événement vidéo peut être un état primitif, état composite, événement primitif ou
événement composite. Les états primitifs sont des atomes nécessaires pour la construction
d’événements complexes utilisables par la plate-forme d’interprétation automatique de
séquences vidéos de l’équipe ORION.

Un même événement peut être regardé à différentes granularités spatiales et temporelles. Par
exemple, un homme courant dans un Marathon peut être vu comme un état (il court) ou comme
événement composé. La granularité choisie indique les propriétés d'intérêt pour l'utilisateur.
La syntaxe pour définir un état ou un événement se compose trois parties :
PhysicalObjects: déclare les objets physiques concernant le concept. Seulement les objets qui
peuvent changer entre les occurrences de concept doivent être déclarés.

TIEU LUAN MOI download :


10
Components: déclare tous les composants constituant l’événement vidéo.
Constraints: déclare toutes les relations entre les sub-concepts (objets physiques et
composants) du concept.
L’exemple ci-dessous illustre la représentation de l’état Inside_zone dans le Langage de
Description de Scénarios de l’ORION :

PrimitiveState Inside_zone
PhysicalObjects
((p : Person), (z : Zone))
Constraints
(p in z)

Un autre exemple, l’événement Changes_zone est définit en utilisant des états Inside_zone
comme ses composants :
PrimitiveEvent Changes_zone
PhysicalObjects
((p : Person), (z1 : Zone), (z2 : Zone))
Components
((inside_z1 : PrimitiveState inside_zone(p, z1))
(inside_z2 : PrimitiveState inside_zone(p, z2))
Constraints
(inside_z1 before inside_z2)

1.4 Objectifs
Une de limitations de l’ontologie actuellement proposée par l’équipe Orion [Bremond at al.,
2004] est que certains concepts (ex. relations spatiales entre les objets physiques) ne sont pas
définis formellement. De plus, le langage de description de scénarios de l’équipe ORION n'est
pas un langage standard de représentation de connaissances. Notre objectif est de pouvoir
partager l’ontologie d’événements vidéos. C’est pourquoi l’objectif principal de ce stage est de
représenter cette ontologie dans un langage standardisé.
Le but de ce stage de DEPA est d’améliorer le travail de l'équipe Orion sur l’ontologie
d'événements vidéos:
•

Premièrement, il s’agit d’étendre et d’implémenter dans un langage standard l’ontologie
d'événements vidéos existante.

•

Deuxièmement, il s’agit de construire un outil graphique d'acquisition de connaissances
basé sur l’ontologie d’événements vidéos afin de permettre à des experts de comprendre, de
contrôler et de manipuler des événements d'intérêt pour leurs domaines d’application.

1.5 Contenu du rapport
Ce rapport est organisé comme suit. Le chapitre 2 introduit une vue d’ensemble du domaine de
l’ontologie ainsi que le problème de la représentation et la définition d’événements vidéos. Une
ontologie d’événements vidéos est proposée dans la chapitre 3. Le chapitre 4 présente un outil
graphique d'acquisition de connaissances destiné à aider les experts d’un domaine à définir des
événements d’intérêts. Enfin, nous concluons et donnons des perspectives de travail dans le
chapitre 5.

TIEU LUAN MOI download :


11

CHAPITRE II:

ETAT DE L’ART

Comme nous l’avons expliqué dans l’introduction de ce rapport, notre objectif est de faciliter la
définition d’événements vidéos par l’utilisation d’une ontologie d’événements vidéos. L’état de
l’art proposé dans ce chapitre est structuré en deux parties. Une introduction au domaine de
lontologie est dabord proposộe. Ensuite, nous donnons un aperỗu des approches existantes
dans le domaine de la représentation d’événements vidéos.

2.1 L'ontologie

Durant la dernière décennie, l’ingénierie ontologique est devenu un thème de recherche très
populaire [Roche, 2003] et joue un rôle de plus en plus important dans différents domaines tels
que la recherche intelligente sur le Web, le partage, la gestion et la réutilisation de
connaissances.
2.1.1 La notion d’ontologie
En informatique, une ontologie a pour but de représenter formellement l’existant. La
représentation formelle des connaissances est basée sur une étape de conceptualisation. La
conceptualisation consiste à identifier un ensemble de concepts ainsi que les relations qui les
relient. Une spécification explicite de cette conceptualisation s'appelle une ontologie [Gruber,
1993]. Formellement, une ontologie se compose des termes, de ses définitions, des relations et
des axiomes [Gruber, 1993].
Selon [Roche, 2003] l’ingénierie ontologique repose sur une approche multidisciplinaire:
•

linguistique, comme nous employons des mots pour communiquer;

•

théorie de la connaissance, puisque les mots se rapportent à la connaissance qui définit leur
signification;

•

logique, afin de garantir de la concordance;

•

représentation de la connaissance afin d’adresser le problème de la compréhension d’un

domaine.

2.1.2 Pourquoi construire des ontologies ?
Quelles sont les raisons de développer des ontologies? L’une des motivations principales est de
permettre la communication et partager la compréhension commune d’un domaine. Ceci, entre
des personnes ou des agents de logiciel.
Une autre raison importante qui inspire la recherche sur les ontologies est que des ontologies
permettent la réutilisation de la connaissance. Par exemple, dans le cadre de la représentation
d’événements vidéos, plusieurs approches permettent de représenter la notion du temps. Il
s’agit par exemple des notions d’intervalles de temps, points de temps, mesures relatives du
temps. Si un groupe de chercheurs développe une telle ontologie, d'autres peuvent simplement
la réutiliser pour d’autres applications.

TIEU LUAN MOI download :


12
Finalement, l'analyse ontologique clarifie la structure de la connaissance [Chandrasekaran et al.,
1999]. Plus qu’un vocabulaire spécialisé pour un domaine, les ontologies fournissent les
conceptualisations des termes du domaine. De plus, l'analyse formelle des termes est
extrêmement importante pour la réutilisation ou de l’extension d’ontologies existantes.

2.1.3 Le processus de création d’une ontologie
Le processus de création d’une ontologie doit être considéré comme un projet. Les méthodes de
gestion de projet peuvent donc s'appliquer [ Gandon, 2002 ]. Un cycle de vie d’une ontologie est
proposé dans [Lopez et al, 2000]. Trois types d’activités sont identifiés (Figure 3):
•

La gestion

•

La construction

•

Le support

Activités de gestion

Gestion

Planification

Activités de construction

Spécification

Conceptualisation

Formalisation

Implémentation

Activités de support

Acquisition

Integration & Evaluation & Documentation

Figure 3 : Le cycle de vie d’une ontologie

L’activité de construction est la partie centrale du cycle, au cours duquel les activités de gestion
et de support participent. La construction se compose quatre étapes :
Spécification :
La construction d’une ontologie commence par la définition d’un domaine et de sa portée. C’est
à dire, il faut trouver des réponses a des questions comme [Noy et McGuinness, 2001] :
•

Quel est le domaine que l'ontologie couvrira?

•

Quels sont les buts de l'utilisation de l'ontologie?

TIEU LUAN MOI download :


13
•

A quels types de questions l'information contenue dans l'ontologie devra-t-elle fournir des
réponses?

•

Qui va utiliser et maintenir l'ontologie ?

Conceptualisation :
La phase conceptualisation a pour but de la structuration des connaissances d’un domaine. Cette

phase se compose des étapes suivantes:
•

D’identifier des concepts, des attributs, et des valeurs dans un Dictionnaire Glossaire.

•

De classifier des groupes de concepts dans des Arbres de Concepts.

•

De construire une Table des Relations.

•

De construire une Table des Instances d’Attributs.

•

De définir des constantes dans un Table des Constantes.

•

De construire une Table de Formules.

Formalisation :
Une fois le modèle conceptuel structuré, il faut le traduire dans un formalisme formel or
informel. Grâce à la formalisation, les définitions des concepts sont plus explicites et précises.
L’objectif est de faciliter l'interprétation de l’ontologie. [Uschold et Jasper, 1999] ont proposé
quatre niveaux de formalismes d’une ontologie, du haut niveau informel au niveau formel

rigoureux. Le niveau du formalisme d’une ontologie est choisi selon les besoins et selon le
langage d’implémentation de l’ontologie. Par exemple, si l’ontologie est un framework pour la
communication entre des personnes alors la représentation d’une ontologie peut être informelle.
Cependant, si l’ontologie est utilisée par les outils logiciels, la représentation doit être plus
formelle.
Parmi les nombreux langages de formalisation des ontologies, il y a trois grandes familles: les
langages à base de frames, les modèles des graphes contextuels et les logiques de description.
Dans les langages à base de frames, les frames représentent les catégories d’objets et sont dotées
d’attributs (slots). Les slots peuvent prendre différentes valeurs. Une instance de classe, qui a un
identifiant et des attributs uniques est liée à sa classe par le lien « is - a ». Les classes sont
structurées par un lien hiérarchique « a-kind-of ». Flogic [Kifer et al., 1995] est un exemple
connu de formalisme qui intègre les langages à base de frames, les formalismes orientés objet et
la logique du premier ordre.
Dans le modèle des graphes conceptuels [Chein et Mugnier, 1992] on distingue des niveaux
différents. Au niveau conceptuel, il peut servir de base à un langage spécialisé de
communication entre les spécialistes de différentes disciplines impliquées dans un travail
cognitif commun. Au niveau d'exécution, il peut servir de base à un outil commun de
représentation employé par plusieurs modules d'un système complexe.
Les logiques de description sont basées sur la logique prédicat, les réseaux sémantiques et les
langages à base de frame. Dans le formalisme des logiques de description, les connaissances
sont représentées sous forme de concepts, de rôles et d’individus. Un concept est une entité
générale d’un domaine d’application. Les rôles sont des relations binaires entre concepts et les
individus sont les instances des concepts. Les propriétés des concepts, rôles et individus sont
exprimées en logique des prédicats.
Implémentation :
Finalement, on doit l’implémenter l’ontologie sur un langage. Le langage choisit doit
correspondant avec le modèle de formalisation. Une introduction brève des langages d’ontologie
est présentée dans la session suivante.

TIEU LUAN MOI download :

14
2.1.4 Vue d'ensemble des langages d'ontologie
Pour implémenter des ontologies, de nombreux langages ont été utilisés. La plupart sont basés
sur XML et les logiques de description. Dans cette section, nous présenterons brièvement
XML, XML Schema, RDF, RDF Schema et OWL qui sont les langages le plus populaires.
XML
XML (eXtensible Markup Language) recommandé par le World Wide Web Consortium (W3C)
est une spécification destinée à rendre des documents lisibles par une machine.
<employee>
<name="Son">
7634</phone>
</ name>
</employee>
Figure 4 : Exemple de représentation XML

XML fournit seulement une structure syntaxique pour des documents [Klein, 2004]. XML ne
permet pas une interprétation sémantique des données
XML Schema
XML Schema permet de définir les balises ainsi que l’agencement de ces balises autorisé pour
définir la validité d’un document XML. XML Schema est recommandé par le W3C.
RDF & RDFS
Tandis que XML fournit une syntaxe pour coder des données, RDF (Resource Description
Framework) est une fondation pour traiter des données. Comme son nom l’indique, ce n'est pas
un langage mais un modèle pour représenter des données au sujet de « choses sur l’Internet ».
Ce type de données pour données s'appelle des metadonnées. Les choses sont des ressources
dans le vocabulaire de RDF [Klein, 2004].
RDF est basée sur la notion d'URI (Uniform Resource Identifiers), en décrivant des ressources
en termes de propriétés et de valeurs de propriétés.

<rdf:RDF>
<rdf:Description rdf:about=" /><created_by>
<rdf:Description>
<name>Son</name>
7634</phone_number>
</rdf:Description>
</created_by>
</rdf:Description>
</rdf:RDF>

Figure 5 : Exemple de représentation RDF

TIEU LUAN MOI download :


15

Le modèle de base de données de RDF comporte quatre types d'objets:
Les ressources sont toutes les choses décrites par des expressions de RDF. Une ressource peut
varier d’une page entière de Web à un élément d’un document XML.
Une propriété est un aspect, une caractéristique, un attribut, ou une relation spécifique employée
pour décrire une ressource.
La notion de literal est employée pour identifier des valeurs telles que des nombres et des dates
au moyen d'une représentation lexicographique.
Un statement se compose d'une ressource spécifique ainsi que d’une propriété plus la valeur de
cette propriété pour cette ressource.
Chaque statement est représenté par un triplet qui est se compose d'un sujet (une ressource),
d'un attribut (une propriété) et d'un objet (ressource ou un literal). Un ensemble de tels triplets
s'appelle un graphe de RDF. La figure 5 représente l’exemple précédant sous la forme d’un
graphe de triplets.

Comme XML, un modèle RDF ne définit pas (à priori) la sémantique d'un domaine
d'application. Il fournit seulement un mécanisme d’intermédiaire pour décrire des metadonnées. Pour définir les propriétés spécifiques d’un domaine ainsi que leur sémantique, il est
nécessaire d’utiliser des éléments additionnels.
RDF schema fournit un système de type pour RDF. Il fournit un mécanisme pour définir des
propriétés associées à des classes ainsi que leurs ranges et leurs domaines.

/>
created_by

phone_number

name
Son

7634

Figure 6 : Représentation d’un graphe de triplets

Les primitives pour construire un schéma pour un domaine spécifique sont :
•

Les définitions de classe (rdf:Class) de statements rdf:subClassof qui permettent la
définition d’hiérarchies de classe.

•

Les définitions de propriété et les statements rdf :subPropertyof pour créer des hiérarchies
de propriétés.

•

Les statements de domaine et de range pour limiter les combinaisons possibles des
propriétés et des classes.

•

Les statements de type pour déclarer une ressource comme instance d'une classe spécifique.

TIEU LUAN MOI download :


16
Un Langage basé sur les logiques de descriptions et XML : OWL
Une autre famille de langages de représentation de connaissances est construite sur XML et les
logiques de descriptions. Ces langages sont ainsi compatibles avec des normes standard
existantes du Web et en même temps offrent la sémantique des logiques de description. Le
principal représentant de cette famille de langages est OWL. OWL est devenu une
recommandation de W3C en février 2004 (*).
OWL est divisé en trois sous-langages, OWL Lite, OWL DL, et OWL Full. Ces langages visent
différents groupes d'utilisateurs.
•

OWL Lite fournit une base pour les utilisateurs qui ont besoin principalement d’une
hiérarchie de classification et de contraintes simples.

•

OWL DL s’adresse aux utilisateurs qui veulent plus d’expressivité tout en conservant la
décidabilité des raisonnements.

•

OWL Full est destiné aux utilisateurs qui veulent une expressivité maximale et la
liberté syntaxique de RDF mais sans garanties dans la complexité des raisonnements.

2.2 La représentation d’événements vidéos
2.2.1 Revue de la bibliographie de la représentation d’événements vidéos
Dans la communauté de la vision par ordinateur, il a y eu beaucoup de recherches destinées à
définir et à représenter des événements vidéos. Par exemple, les auteurs de [Nagel, 1998]
utilisent une hiérarchie de verbes de mouvements, contenant jusqu'à neuf niveaux d'abstraction
de verbes tels que : « changement », « événement », « verbe-phrase », « phase », « historique ».
Ils proposent également d'utiliser un diagramme de transition à chaque niveau d'abstraction pour
représenter la succession des verbes. [Nevatia et al, 2003] propose une décomposition
hiérarchique des événements et suggèrent l'utilisation des terminologies « single thread » et
« multiple thread ».
Concernant les ontologies d'événements vidéos, peu de travaux ont été menés. En 2003,
l'objectif de trois workshops organisés dans le contexte du programme ARDA (**) était de
proposer une ontologie d'événement vidéo pour le domaine de la sécurité. Pendant ces
workshops, des chercheurs venus de la communauté de la vision par ordinateur et de
l'administration américaine ont travaillé ensemble pour proposer une structure d'ontologie
d'événements vidéos pour faciliter la construction d’ontologies consacrées aux domaines
spécifiques de la sécurité. Les chercheurs de la communauté de la vision par l'ordinateur ont
proposé six ontologies consacrées à des applications spécifiques de sécurité telles que la
surveillance de croisement de chemin de fer. L’équipe ORION a participé à ces workshops et a
proposé deux ontologies pour la surveillance de banque et de métro [Bremond et al. 2004]. Ces
ontologies ont été définies de manière incrémentale par une interaction avec des utilisateurs,
comme par exemple des opérateurs de surveillance de métros et de banques.
A la suite des workshops du programme ARDA, Les auteurs de [Nevatia et al., 2004] ont
proposé un langage formel de représentation d’événements vidéos ainsi que des ontologies
spécifiques pour le domaine de la sécurité. Le langage formel proposé s’appelle VERL que on

va voir en détail dans la session suivant.
_____________________________(*) />(**) />
TIEU LUAN MOI download :


17
2.2.2 VERL : Une langage de la représentation d’événements vidéos
VERL (Video Event Markup Language), proposé par des auteurs dans [Nevatia et al., 2004], est
un langage formel pour décrire une ontologie des événements. Il est possible de traduire des
expressions de VERL dans la logique premier ordre. Les expressions dans VERL ont donc une
sémantique claire.
Objects, états, événements et types
Les notions importantes dans VERL sont objets, états et événements. Les objets ont des
propriétés ou des attributs qui sont considérées comme des prédicats d'un argument. Ils se
composent également des relations avec autres objets. Nous pouvons penser à ces derniers
comme prédicats avec deux ou plus arguments. Les propriétés, les attributs, et les relations
peuvent être considérés comme des états. Un événement est un changement d'état dans un objet.
Il y a de trois types basiques dans le langage. Tout est une thing (une chose). La thing décrit un
état ou un événement, ou une entité telle qu'un objet physique. Il y a deux types de things. Le
type ent comprend des entités, et généralement peut être considéré comme des objets physiques.
Le type ev se compose des états et des événements. Normalement, une personne serait du type
ent, et son action de courir serait du type ev.
Expressions dans VERL
Les constantes peuvent être de n'importe quel type prédéfini. Un constant ou une variable est
une expression de VERL. Une expression de VERL (vexpr) est définie comme ci-dessous:
vexpr --> constant | variable
Une fonction symbolique qui s'est appliquée au nombre approprié de vexprs comme des
arguments est une vexpr:
vexpr --> fct "(" [ vexpr { "," vexpr }* ] " )"
Un prédicat symbolique s’est appliqué au nombre approprié d'arguments est une vexpr :

vexpr --> pred "(" [vexpr { "," vexpr } * ] " )"
Fait attention que les arguments doivent être du bon type et le résultat est toujours de type ev.
Un opérateur logique appliqué au nombre approprié des vexprs de type ev est un vexpr :
vexpr --> "AND" "( " vexpr {"," vexpr } * " )" | "OR" " (" vexpr { "," vexpr }* " ) "
| "IMPLY" " ( " vexpr "," vexpr " )
| "NOT" " ( "vexpr " ) " | "EQUIV" " ( " vexpr "," vexpr " ) "
Représentation des événements composés
L'opérateur de base pour définir des événements composés est PROCESS. Il prend un prédicat
et une vexpr comme ses deux arguments. Le prédicat applique au nombre approprié
d'arguments, où les arguments ont des spécifications optionnel de type.
defn --> "PROCESS" "(" pred "(" [argspec {"," argspec}* ")" ["," vexpr] ")"
argspec --> [type] variable
Par exemple, si nous avons le prédicat located-at reliant une thing à un ent, et un prédicat
change reliant deux arguments de type ev, alors nous pouvons définir le prédicat move comme
ci-dessous:
PROCESS(move(thing x, ent y, ent z),
change(located-at(x,y),located-at(x,z)))

TIEU LUAN MOI download :


18
Règles d’inférence
A coté des annotations des événements spécifiés ainsi que les définitions des propriétés, des
relations et des événements composites, on peut spécifier des règles d’inférence par l’opérateur
RULE qui prend deux vexprs de type ev comme ses arguments :
RULE(vexpr, vexpr)
Une règle est une implication, la premier vexpr implique la deuxième.
Par exemple, supposons que nous définissons carry(x, y, a, b, t), x porte y de a à b pendant
l'intervalle de temps t, comme x tient y pendant t et x déplace d'a à b pendant t :

PROCESS(carry(x,y,a,b,t),
AND(hold(x, y,t), move(x,a,b,t)))
Alors si nous voulons dire que quand x porte y de a à b pendant t, alors y également déplace d'a
à b pendant t, nous pouvons dire:
RULE(IMPLY(carry(x,y,a,b,t), move(y,a,b,t)))

2.3 Conclusion

Le processus de création d’une ontologie doit être considéré comme un projet. Les méthodes de
gestion de projet peuvent donc s'appliquer. La construction se compose quatre étapes:
spécification, conceptualisation, formalisation et implémentation. Parmi les nombreux langages
de formalisation des ontologies, il y a trois grandes familles: les langages à base de frames, les
modèles des graphes contextuels et les logiques de description. Pour implémenter des
ontologies, de nombreux langages ont été utilisés. La plupart sont basés sur XML et les logiques
de description. Le principal représentant de cette famille de langages est OWL. Le langage
OWL, construit sur XML et les logiques de descriptions, est devenu une recommandation de
W3C en février 2004. Le langage est compatibles avec des normes standard existantes du Web
et en même temps offrent la sémantique des logiques de description.
En général, les recherches sur la structure des ontologies d’événements vidéos se concentrent
sur la décomposition d’un événement spatial temporel complexe en des événements plus
simples. Cette décomposition permet de définir des structures hiérarchiques pour représenter
les événements. Les structures obtenues sont très complexes. L’utilisation d’un framework
standard de représentation de connaissances (e.g. OWL, SWRL) pour l’implémentation
d’ontologies d’événements vidéos reste un problème ouvert de recherche.

TIEU LUAN MOI download :


19

CHAPITRE 3 : ONTOLOGIE D’EVENEMENTS VIDEOS

3.1 Vue d’ensemble de la méthodologie
Ce chapitre détaille une ontologie d’événements vidéos. Dans notre cas, la représentation des
objets physiques de la scène observée et les événements vidéos apparaissant dans la scène est le
domaine de l’ontologie. Notre objectif est de représenter cette ontologie dans le langage
standardisé OWL. Notre ontologie est construite suit aux étapes suivant :
•

Conceptualisation: L’étape est pour le but de structurer des connaissances d’un domaine,
l’indication des objets physiques, des événements, leurs propriétés et leurs relations entre
eux.

•

Formalisation dans le langage VERL: Grâce à la formalisation, les définitions des concepts
sont plus explicites et précises. Nous choisissons le langage VERL pour la pas de
formalisation.

•

L’implémentation dans le langage OWL: Différant aux l’auteur de VERL qui a utilisé XML
pour représenter ses ontologies, dans cet étape, nous transformons des expression de VERL
sur OWL.

Les pas décrits ci-dessus sont détaillés dans les parties suivantes.

3.2 Conceptualisation du domaine
Considérons l’exemple du scénario d’attaque en agence bancaire. L’agresseur entre dans une
agence bancaire. Il va ensuite vers le comptoir pendant qu’un employé se trouve derrière le

comptoir. Ensuite, il force le commercial à se diriger vers le coffre-fort. Intuitivement, dans
cet exemple, nous pouvons identifier des objets physiques: l’agresseur, le commercial, le coffrefort, on identifie également des événements (ex. l’agresseur entre dans l'agence bancaire,
l’agresseur va devant le comptoir) et des relations spatiales (devant, derrière) et temporelles
(avant, après).
3.2.1 Des objets physiques
Le concept spatial le plus abstrait est l’objet physique. Les objets physiques sont tous des objets
du monde réel dans une scène surveillée. Selon la capacité de prévision du mouvement des
objets nous définissons deux types d'objets physiques: les objets mobiles et les objets
contextuels.
Un objet mobile est un objet dont le mouvement ne peut pas être prévu. Naturellement, un
objet mobile initie son mouvement. Des objets mobiles typiques sont des personnes, des
groupes de personnes, des animaux, et des robots.
Un objet contextuel est un objet dont le mouvement peut être prévu en utilisant l'information à
priori. Généralement, un objet contextuel ne peut pas automatiquement changer d’endroit dans
la scène. Cependant, il peut être déplacé par un autre objet. Les objets contextuels typiques sont
des murs, des zones d’entrée, des portes, des chaises.
Il y a plusieurs de niveaux de granularité pour considérer les objets physiques. A un niveau de
granularité important, un groupe de personnes peut être considéré comme un objet mobile. A un
niveau de granularité plus fin, une personne peut être considérée comme un objet mobile. A un

TIEU LUAN MOI download :


20
niveau de granularité encore plus fin, nous pouvons prendre une personne comme une entité
complexe qui est capable d'effectuer des actions simultanées avec les parties différentes de son
corps. Dans ce cas, chaque partie de corps peut être vue comme un objet mobile. Ainsi, un
objet physique peut induire la création de plusieurs nouveaux objets ou fusionner avec d'autres
objets pour former un objet unique. La structure hiérarchique des objets physiques est illustrée
dans la figure 7.

PhysicalObject

ContextualObject

MobileObject

Vehicle

Person

Equipment
Car

Wall

Zone

Entrance

Exit

Figure 7 : Exemples d’objets physiques

3.2.2 Relations spatiales

Les relations spatiales définissent des relations entre les objets physiques impliqués dans un
événement donné. Il y a deux types importants de relations spatiales: les relations topologiques
et les relations de distance.
Les relations topologiques et de distance décrivent des relations entre les objets physiques (par

exemple si une personne est proche ou loin d’un distributeur automatique de billets). Les
relations de distance peuvent être quantitatives. Par exemple, on peut définir que la distance
entre deux personnes est de 5 mètres. On peut aussi définir que l’objet A est proche de l’objet B
si et si la distance entre A et B est moins de 1 m. La structure hiérarchique des relations
spatiales est illustrée dans la figure 8.

Spatial Relation
Topological
Distance

Near

Far

Inside

Outside

Figure 8 : Exemple des relations spatiales

TIEU LUAN MOI download :


21

3.2.3 Etats et événements vidéo

Les différentes manières pour caractériser les évolutions et les interactions entre objets mobiles
dans une scène sont des états et des événements (primitif et composé). Ces types de concepts
sont définis ci-dessous.

Un état est une propriété spatio-temporelle valide à un instant donné ou stable sur un intervalle
de temps. Faire attention que des objets physiques ont des propriétés ou des attributs ce qui
contiennent aussi des relations avec des autres objets. Les propriộtộs, les attributs et les relations
peuvent ờtre conỗus comme des états, par exemple : un personne est à l’intérieur ou à l’extérieur
d’une chambre.
Un état primitif est une propriété spatio-temporelle valide et stable sur un intervalle de temps.
Un état composé est une combinaison d’états. Nous appelons composants tous les sous-états
d’un l'état et nous appelons des contraintes toutes les relations concernant ces composants.
Un événement est un ou plusieurs changement(s) d'état à deux instants successifs de temps ou
sur un intervalle de temps (ex. entre, sort).
Un événement primitif est un changement d'état.
Un événement composé est une combinaison d’états et/ou d’événements.
Un même événement peut être regardé à différentes granularités spatiales et temporelles. Par
exemple, un homme courant dans un Marathon peut être vu comme un état (il court) ou comme
événement composé. La granularité choisie indique les propriétés d'intérêt pour l'utilisateur.
3.2.4 Relations temporelle
Les relations temporelles sont employées pour la définition d’événements. Les relations
temporelles incluent des opérateurs d'algèbre d'intervalle d'Allen et des relations quantitatives
entre la durée, le commencement et la fin des événements.
L'ontologie de DAML-Time est un langage riche de spécification pour l'expression dans une
sémantique temporelle. [Hobbs, 2002] a axiomatisée les relations topologiques entre des
instants et des intervalles ainsi que des relations temporelles.
Les instants sont, intuitivement, un point de temps qui n'a aucun point d'intérieur, et les
intervalles sont, intuitivement, des choses avec de l'ampleur. Ceci signifie que des événements
d’instant sont instantanés, comme l'occurrence d'un accident de voiture, et des événements
d'intervalle sont des événements qui durent sur un certain intervalle, par exemple, une réunion
de 2pm a 3pm.
Les relations temporelles auxquelles on s’intéresse pour représenter des événements vidéos
sont : avant, après, pendant et rencontre.

3.3 Représentation des événements sur VERL
Comme cela été expliqué dans la section 2.1.3, grâce à la formalisation, les définitions des
concepts sont plus explicites et précises. Dans cette session nous avons introduire la
représentation des événements sur VERL langage.

TIEU LUAN MOI download :


22
3.3.1 Définition hiérarchique des concepts
Il y a trois types basiques dans le langage VERL. Tout est une thing. Il y a deux types de things.
Le type ent comprend des entités, et généralement peut être considéré comme des objets
physiques. Le type ev comprend des états et des événements.
La définition des sous-types de type ent et ev est effectuée par l’opérateur SUBTYPE de VERL.
Il prend deux arguments, le nom du sous-type et le nom du super-type :
SUBTYPE(type, type)
Grâce à l’opérateur SUBTYPE on peut représenter la structure hiérarchique des objets
physiques. Par exemple, on dit que ent a le sous-type de l’objet physique qui a des sous-types
l’objet mobile et l‘objet contextuel alors on peut écrire :
SUBTYPE (physical objet, ent)
SUBTYPE ( mobile object , physical objet)
SUBTYPE ( contextuel object , physical objet)
SUBTYPE ( human, mobile object)
3.3.2 Représentation des états et événements sur VERL
L’opérateur PROCESS nous permet de définir des états et des événements. Il prendre un
prédicat et une expression de VERL comme ses deux arguments :
defn --> "PROCESS" "(" pred "(" [argspec {"," argspec}* ")" ["," vexpr] ")"
argspec --> [type] variable
Le deuxième argument de PROCESS nous permet de déclarer des composants et des contraints
pour la représentation d’un état ou d’un événement. Par exemple, si on a un prédicat inside

concernant une personne et une zone, alors on peut définir le prédicat inside_zone comme cidessous :
PROCESS (inside_zone(Person p, Zone z), inside(p,z))
En se basans sur des prédicats primitifs on peut représenter des prédicats composites comme cidessus :
PROCESS(changes_zone(Person : p, Zone : z1, Zone : z2),
AND( at_interval(inside_zone(p, z1)), T1),
at_interval(inside_zone(p, z2), T2),
before(T1, T2)))
Dedans nous utilisons des temporels prédicats at_interval et before que nous définissons comme
des expressions dans VERL :
vexpr
vexpr

at_interval "(" ev ", "interval " )"
before "(" ev ", "ev " )"

L’événement d’attaque en agence bancaire, un événement le plus complexe, est définit comme
ci-dessus :
PROCESS (attack(Person: com, Person: arg, Zone : Infront_Branch,
Zone: Infornt_Branch, Zone, Zone: Entrance, Zone: Safe)
AND(at_interval(inside_zone(com, Back_Branch), T1),

TIEU LUAN MOI download :


23
At_interval(changes_zone(arg, Infront_Branch, Entrance_Zone), T2),
At_interval(inside_zone(com, Safe), T3),
At_interval(inside_zone(arg, Safe), T4),
before(T1, T3), before (T2, T3), during(T3, T4)))

3.4 L’implémentation de l’ontologie sur OWL

Dans cette session nous introduisons la transformation des expressions dans le langage VERL
dans la session précédant en des expressions dans le langage OWL. Nous utilisons un model de
OWL FULL qui est étendu de OWL DL pour représenter des événements vidéos.
Une ontologie de OWL dans la syntaxe abstraite contient un ordre des axiomes et des faits. Les
axiomes peuvent être de diverses sortes, par exemple, axiomes de sous-classe. Nous étendons
des axiomes pour permettre également la définition des événements, en ajoutant des axiomes
« PROCESS » et « Variable ».
Les axiomes variables sont des déclarations au sujet des variables, indiquant que l'URI donné
doit être employé comme variable, et ajoutant optionnellement types des variables :
<Variable name = anyURI>
content : [variableType]
</Variable>
Par exemple :
<orion:Variable rdf:ID="p">
<orion:variableType rdf:resource="#Person"/>
</orion:Variable>
déclare que l'URI p qui a le type de Person doit être traité comme variable.
PROCESS peut être considéré comme implication logique entre un prédicat (orion:predication)
et une condition (orion:condition):
<PROCESS>
content: (prédication, condition)
<PROCESS>
Un prédicat est une déclaration d’un événement/état qui se compose nom de l’événement/l’état
et une liste des arguments correspondants :
<Predication name = anyURI>
content : (ArgumentList)
<Predication>
Par exemple :

<orion:predication>
<orion:Event rdf:about="#Changes_zone">
<orion:arguments rdf:parseType="Collection">
<orion:Arg rdf:about="#p"/>

TIEU LUAN MOI download :


24
<orion:Arg rdf:about="#z1"/>
<orion:Arg rdf:about="#z2"/>
</orion:arguments>
</orion:Event>
</orion:predication>
Une condition est une expression dans VERL qui est considérée comme le deuxième argument
de l’opérateur PROCESS. On peut le diviser en deux parties. Une partie déclare tous les sous
événements constituant l’événement déclaré dans la partie prédicat, cette partie est optionnelle
et on ne l’utilise pas en car l’événement déclaré dans la partie prédicat est primitive. Une autre
partie déclare toutes les relations entre des sub-concepts déclarés (variables et sous
événements).
<condition>
content : (components, contraints)
</condition>
Component est une liste des événements :
<components>
content : (EventList)
</components>
« Contraints » et une liste des contraints atomiques. Une contrainte atomique peut être un
prédicat binaire, une contrainte de fonction ou un contraint de propriété. Par exemple :
<orion:BinaryRelation>

<orion:binaryPredicate rdf:resource="&space;inside"/>
<orion:argument1 rdf:resource="#p"/>
<orion:argument2 rdf:resource="#z"/>
</orion:BinaryRelation>
est une contrainte atomique de prédicat binaire. Un autre exemple de contraint atomique de
fonction est :
<orion : OccurenceNumberOfEvent >
<orion: eventName rdf :resource="#e"/>
<orion: occurenceNumber rdf:datatype="&xsd;integer">4
</orion : OccurenceNumberOfEvent >
Maintenant, un complexe prédicat, l’événement Changes_zone est représenté comme cidessous :
<orion:Process>
<orion:predication>
<orion:Event rdf:about="#Changes_zone">
<orion:arguments rdf:parseType="Collection">
<orion:Arg rdf:about="#p"/>
<orion:Arg rdf:about="#z1"/>
<orion:Arg rdf:about="#z2"/>

TIEU LUAN MOI download :


25
</orion:arguments>
</orion:Event>
</orion:predication>
<orion:condition>
<orion:components rdf:parseType="Collection">
<orion:State rdf:about="#Inside_zone">
<orion:arguments rdf:parseType="Collection">

<orion:Arg rdf:about="#p"/>
<orion:Arg rdf:about="#z1"/>
</orion:arguments>
<orion:atInterval rdf:about="#t1"/>
</orion:State>
<orion:State rdf:about="Inside_zone">
<orion:arguments rdf:parseType="Collection">
<orion:Arg rdf:about="#p"/>
<orion:Arg rdf:about="#z2"/>
</orion:arguments>
<orion:atInterval rdf:about="#t2"/>
</orion:State>
</orion:components>
<orion:constraints rdf:parseType="Collection">
<orion:BinaryRelation>
<orion:binaryPredicate rdf:resource="&space;before"/>
<orion:argument1 rdf:resource="#t1"/>
<orion:argument2 rdf:resource="#t2"/>
</orion:BinaryRelation>
</orion:constraints>
</orion:condition>
</orion:Process>

TIEU LUAN MOI download :