Couche Intermédiaire (serveur)

La Couche Intermédiaire établit le partage d’information entre la Couche Applicationet la Couche de Données.

Cette couche est basée sur les spécifications du SQI (Simple Query Interface) (Simon et al., 2005). Fondamentalement, SQI a été conçu pour faciliter l’exécution des requêtes dans des milieux hétérogènes, en mettant l’accent sur l’interopérabilité. Nous avons choisi

Implémentation de la contribution : prototype d'annotation d'images

SQI pour la force (les avantages) de ses deux composantes principales : Simple Command

Set and Extensibility and Command-Query Separation. La première composante réduit le

nombre de paramètres des méthodes au lieu de réduire le nombre de méthodes. Ainsi, des extensions peuvent être facilement introduites en ajoutant de nouvelle méthodes, sans né- cessiter de modifier celles qui existent déjà. Par conséquent, toute application « client » qui utilise SQI n’est pas affectée par des modifications éventuelles. La deuxième composante impose que chaque méthode soit une commande qui effectue une action (par exemple, définir un paramètre) ou bien une requête qui restitue les données au client (exécuter la re- quête), mais pas les deux en même temps. Cela conduit à une conception d’interfaces plus claires et plus compréhensibles. Par conséquent, deux phases sont mises en évidence : une phase de configuration de la requête et une phase d’exécution de la requête. Dans notre cas, ces deux phases dont mises en œuvre à travers deux services distincts : Service de

Configuration et Service d’Annotation.

1. Service de Configuration.

Ce service a pour but de configurer la requête pour le Service d’Annotation. Il crée un identifiant de session et lui associe un ensemble de paramètres de recommandation (par exemple, la distance, le temps. . . ). Il est composé des huit méthodes suivantes : a) String createAnonymousSession()

Cette méthode est appelée par le client avant que toute communication ait lieu. Elle renvoie un identifiant (c.-à-d. sessionID) qui est utilisé par l’application cliente lors de la requête de la Couche Intermédiaire. Sa valeur identifie la session de commu- nication en cours.

b) void destroySession(String sessionID)

Cette méthode a pour but de supprimer l’identifiant de la session en cours. Elle est appelée par le client à la fin de la session de communication. Elle prend en entrée l’identifiant de la session à supprimer.

c) void setDistance(String sessionID, double radius)

Cette méthode permet de filtrer une collection d’images selon un rayon fixe (en mètres), r, par rapport à une image-requête. Ce rayon délimite la zone circulaire à partir de laquelle les images supposées être similaires à une image-requête sont col- lectées. La valeur par défaut pour ce rayon r est établie à 300 mètres (pour laquelle de bons résultats ont été obtenus dans nos expérimentations).

d) void setNumberOfThreads (String sessionID, int threads)

Cette méthode permet au client de configurer le nombre de cœurs/CPU logique uti- lisés pour le processus d’annotation. Tenant compte du fait que chaque dispositif informatique a au moins un cœur, la valeur par défaut de ce paramètre est1. Dans

5.2. Architecture du prototype d'annotation d'images AnnoTaGT

le cas des dispositifs avec plusieurs cœurs la valeur par défaut peut être augmentée afin de réduire le temps de calcul.

e) void setSigma(String sessionID, double sigma)

Cette méthode permet au client de configurer le coefficient d’interpolation σ. Ce coefficient est utilisé par les fonctions Kernel employées dans le modèle probabiliste de classement présenté dans la section II.3.2.2. Nous établissons la valeur par défaut de ce coefficient à 2 (pour laquelle nous avons obtenu les meilleurs résultats). f ) void setStartDate(String sessionID, long startDate)

Cette méthode a pour but de configurer le filtre temporel utilisé par le Service

d’Annotation pour trouver les images similaires du point de vue temporel (c.-à-d.

les images prises dans la proximité temporelle de l’image-requête) à une image- requête. Pour une valeur de ce paramètre non nulle, seules les images prises après une startDate serons considérées comme similaires. Dans le cas contraire, aucun filtre startDate n’est appliqué.

g) void setEndDate(String sessionID, long endDate)

Cette méthode configure un filtre temporel, similaire au précédent. La différence principale réside dans le fait que la recherche d’images similaires se fait dans une proximité temporelle de l’image-requête avant une date de fin fixée (quand la va- leur du paramètre endDate est non nulle). Une valeur nulle de cette variable signifie qu’aucun filtre endDate n’est appliqué. En outre, si les valeurs startDate et endDate sont nulles, aucun filtre temporel n’est pas appliqué, ce qui signifie que toute la col- lection est prise en compte dans le processus d’annotation. De plus, si les valeurs startDate et endDate sont définies, seules les images qui se trouvent entre l’inter- valle délimité par les deux valeurs sont considérées similaires à une image-requête. h) void setAnnotateModel(String sessionID, String method)

Cette méthode permet à un client de préciser l’approche de classement des tags qui sera utilisé par le Service d’Annotation. La valeur par défaut c’est le modèle proba- biliste présenté dans la section II.3.2.2. D’autres valeurs sont possibles pour le para- mètre de cette méthode, reprenant chacune des approches de classement des tags que nous avons présenté dans la section II.3.2.1.

Mentionnons que la seule méthode à appeler obligatoirement par le client est la mé- thode creatAnonymousSession(), les autres sont facultatives. Une fois cette méthode appelée, le Service de Configuration assignera les valeurs par défaut pour les paramètres d’annotation correspondant à la sessionID générée. Pour changer les valeurs par défaut des paramètres, les autres méthodes doivent également être appelées par le client. Une fois la configuration faite, le client peut appeler la méthode du Service d’Annotation afin d’obtenir les descripteurs textuels (tags) pour une image-requête donnée.

Implémentation de la contribution : prototype d'annotation d'images

Par la suite, ces valeurs sont stockées dans une table de session dans la base de données de la Couche de Données. De plus, elles sont utilisées par le Service de Configuration afin de configurer le processus d’annotation. Parmi ces valeurs de session, trois sont directement accessibles à l’utilisateur via l’interface graphique du prototype AnnoTaGT : distance, stratDate et endDate. Les autres sont définies dans le code en fonction de leurs valeurs optimales déterminées expérimentalement.

2. Service d’Annotation

Ce service est composé d’une méthode appelée String annotate(String sessionID, double latitude, double longitude, long takenDate). Les paramètres d’entrée : latitude, longitude et takenDate représentent la requête, en analogie avec la représentation de la requête textuelle dans SQI. Tout comme dans le cas de SQI, nous les avons choisis en tant que paramètres d’entrés pour le Service d’Annotation et pas pour le Service de

Configuration.

Une fois la méthode annotate(String sessionID, double latitude, double longitude, long takenDate) appelée, elle interroge d’abord la table de session correspondant à la sessionID donnée en entrée afin de récupérer les paramètres de configuration qu’elle utilisera dans le processus d’annotation. Ensuite, le modèle d’annotation choisi à tra- vers la méthode setAnnotateModel est appliqué et les tags sont retournés par cette mé- thode sous forme d’une chaîne de caractères. Ces tags sont par la suite fournis à l’utili- sateur par l’intermédiaire de l’interface graphique AnnoTaGT.

L’algorithme 1 présente le pseudo-code du modèle de classement probabiliste, qui est le modèle d’annotation implémenté par défaut dans le prototype AnnoTaGT.

L’avantage de cette couche est que le client peut être écrit dans n’importe quel langage de programmation (par exemple, java, c++, python. . . ).