Architecture générale

FIGURE4.4 – Architecture générale

Dans cette section, nous présentons l’architecture de l’approche proposée pour la génération semi-automatique des applications personnalisées basées sur des documents. Cette architecture est organisée en trois couches (figure4.4) : une couche “application” représente l’interface à partir de laquelle l’utilisateur interagit avec l’application et une couche “traitement” exécute les traitements définis par les DSLs qui sont construits dans la troisième couche de “conception”.

1. En premier lieu, les utilisateurs adressent des requêtes sous forme de documents (publications ou messages privés) à l’application cible via le Réseau Social ;

2. Seulement les documents pertinents mentionnant l’application cible sont pris en considération ;

3. Les patterns qui devraient être trouvés dans les documents pour décider leur perti-nence ou pas sont définis par le concepteur de l’application en utilisant le premier DSLapproprié qui communique avec un dictionnaire externe “BabalNet” ;

4. Les documents pertinents extraits à l’aide du premier DSL sont analysés en appli-quant différentes actions comme la sélection de concepts, l’agrégation et le calcul des fréquences des termes ;

5. Les actions de traitement sont définies par le concepteur de l’application en utilisant le deuxième DSL ;

6. L’exécution de ces actions nécessite éventuellement une communication avec le Système d’Information de l’application pour l’envoi et la réception des informations qui sont utilisées dans la synthèse des réponses adaptées ;

7. Les données extraites suite à l’application des actions ou fournies par le Système d’Information sont exploitées afin d’identifier les documents adéquats aux requêtes des utilisateurs qui sont adaptés à leurs intérêts. La technique de personnalisation est définie au niveau du deuxième DSL dont le but est d’appliquer la méthode de personnalisation basée sur les communautés d’intérêt ;

8. La personnalisation utilise des données qui sont stockées dans l’ontologie FOAF ;

9. Les données extraites lors de l’exécution de la personnalisation sont utilisées pour synthétiser des réponses personnalisées ;

10. Les réponses sont envoyées automatiquement aux utilisateurs cibles sous forme de documents à travers les Réseaux Sociaux.

Afin de faciliter la construction des applications interactives sociales, la solution pro-posée dirigée par les modèles est basée sur les DSLs. Dans la suite, nous détaillons les DSLs proposés.

4.3.2.1 DSL 1 : Reconnaissance des patterns

Afin de manipuler les documents pour extraire les patterns, nous avons construit un DSLdont le méta-modèle est présenté dans la figure4.5. Ce DSL est conçu de telle ma-nière qu’il soit générique. En effet, il peut être appliqué à diverses plateformes de Réseaux Sociaux.

Un pattern (classe “Pattern”) est composé de concepts (classe “Concept”), et dans sa forme la plus simple un concept est un ensemble de mots. Nous avons inclus des concepts

FIGURE 4.5 – Extrait du méta-modèle du DSL 1

spécifiques qui sont souvent utilisés dans les Réseaux Sociaux comme les URL, les noms des utilisateurs et les hashtags. Ce modèle est lié à un dictionnaire externe pour pouvoir re-chercher les relations des hiérarchies sémantiques des concepts. En effet, ils sont souvent liés par des relations sémantiques (synonymie, antonymie, etc.). Les patterns peuvent être définis par le concepteur ou extraits directement du dictionnaire “BabalNet”. La classe “Concept” hérite de la classe “Result”. Ceci permet d’envoyer les concepts identifiés dans les publications en tant que données externes afin de pouvoir les référencer dans les requêtes. En effet, les concepts sont séparés de leur utilisation dans “Pattern” afin de pouvoir les exploiter dans différents contextes. La classe “PatterConcept” est utilisée pour la configuration des concepts, comme par exemple, spécifier un concept comme facultatif dans le modèle. Cependant, les informations de méta-données présentes dans les publica-tions comme la date ou la géolocalisation peuvent être récupérées donc n’ont pas besoin d’être explicitement déclarées dans le modèle.

FIGURE 4.6 – Extrait du méta-modèle du DSL 2

4.3.2.2 DSL 2 : Exécution des actions et personnalisation

Un deuxième DSL pour la description des actions qui peuvent être effectuées sur les documents est montré dans la figure 4.6. Ces actions sont utilisées pour exécuter des requêtes et sélectionner des concepts à partir des documents pertinents obtenus lors de l’exécution du premier DSL. Les requêtes ont une syntaxe similaire aux requêtes SQL. Elles comprennent la sélection de concepts qui remplissent certaines conditions spéci-fiées. De plus, elles permettent d’obtenir certaines métadonnées contenues dans les docu-ments telles que la position géographique. Le DSL permet également la communication avec des systèmes d’information externes. Ceci est pris en compte en permettant la défini-tion de dépendances de données externes depuis ces systèmes. Ainsi, les données peuvent être introduites dans ces derniers ou en extraites. Des évènements asynchrones déclenchés par la source externe permettent de fournir des données au modèle.

Une fois les données sont disponibles à partir des requêtes, des documents de réponse sont composés et envoyés aux utilisateurs correspondants. Ceci est reflété par la classe “Action”. Ces documents peuvent être sous forme de “messages” publics ou privés. Des informations sur les communautés d’intérêt des utilisateurs sont représentées par la classe “Community_Of_Interest”. Elles sont extraites grâce à la communication avec l’ontologie

FOAF. Elles sont exploitées pour l’exécution de la méthode de personnalisation qui repose sur la technique de “Groupization” (classe “Query_Groupization”). Ainsi, des documents à contenus personnalisés sont envoyés aux utilisateurs. Une publication de réponse est envoyée lorqu’un déclencheur (classe “When”) prend la valeur “vrai”.

La fin de l’exécution de l’application est signalée (classe “EndingCondition”) suivant une condition qui peut dépendre de plusieurs facteurs. Ces derniers peuvent être le nombre de publications reçues dans un certain délai de temps.