Exemple d’exécution

Dans cette section, nous présentons un exemple montrant comment trans-former une application Web en une application Web sémantique. En particulier, mapper des documents HTML vers des triplets RDF. Comme le montre la Figure 6.1, l’objectif est de générer pour chaque document HTML un fichier RDF, dont les triplets sont construits à partir des éléments de données HTML, tels que les listes, les tableaux, etc.

Figure 6.1 – Transformation des documents HTML en fichiers RDF

La Figure 6.2 montre la transformation d’une liste HTML en RDF. Le côté (a) de la figure représente un aperçu du navigateur internet contenant une liste de données. Le côté (b) montre le triplet RDF correspondant à cette liste (côté (a)) que nous visons à obtenir automatiquement par un processus de transformation.

Chapitre 6. Approche I

Figure 6.2 – Exemple de transformation

Notons que dans cet exemple, les éléments HTML, notamment les listes, re-présentent des modèles portant des données. Ces données seront représentées en format RDF. Il est clair que chaque fois qu’une transformation de données HTML en RDF est souhaitée, les mêmes règles de transformation sont appli-quées, quelles que soient les données à transformer, que ce soit des tables, des listes ou des liens.

Donc, nous avons comme modèle d’entrée (listes, tableaux et liens) qui subira à un processus de transformation pour obtenir un modèle de sortie (RDF). Cette idée est similaire au paradigme IDM (Ingénierie Dirigé par les Modèles). Il re-pose sur la définition des méta-modèles source et cible, et sur un ensemble de règles de transformation. Dans notre cas, il faut généraliser nos modèles d’entrée et de sortie pour construire deux méta-modèles : un méta-modèle source pour représenter les modèles d’entrée HTML, et un méta-modèle cible pour les mo-dèles de sortie RDF.

Dans la suite du document, ces méta-modèles et ces règles de mappage (trans-formation) sont détaillés, et reposent tous sur des paramètres d’ingénierie pilotée ou dirigée par les modèles (IDM).

6.3 Approche proposée

Nous avons proposé un processus composé de trois étapes, comme illustré dans la Figure 6.3. La première étape est dite prétraitement ou extraction de données. Cette étape a pour objectif de préparer les données candidates à l’étape suivante. Ces données sont extraites et représentées dans un format approprié. La deuxième étape constitue le noyau du système qui est le processus de trans-formation basé sur les modèles. La dernière étape est le raffinement du résultat obtenu par l’étape précédente. Dans la suite, nous allons détailler le rôle et le contenu de chaque étape.

Figure 6.3 – Architecture du système

6.3.1 Étape de pretraitement

Dans cette étape, notre système prend en compte les pages HTML. Cette étape est composée de deux sous-étapes, à savoir l’extraction et l’adaptation. Le prétraitement des données vise à préparer les données pour alimenter l’étape suivante du processus.

Nous pouvons résumer cette tâche en trois mots : extraire et adapter pour construire ! ! ! Alors on extrait quoi ? Nous adaptons pour construire quoi ? La réponse à ces questions est plus facile à ce que vous pensez.

• L’extraction signifie que nous ne prenons que des éléments (balises) HTML contenant des données, comme <table> .... </table>, <ol> ... </ol>, <ul> ... </ul>et <dd > ... </dd>, car ces éléments contiennent des données provenant souvent de bases de données cachées. Les autres éléments comme <img>, <frame>, <span> etc. sont ignorés et supprimés des pages HTML.

• Adapter pour construire signifie que le résultat de l’étape d’extraction est ajusté pour être conforme au méta-modèle source qui sera défini à l’étape suivante. Par exemple, l’élément <ol> .... </ol> est transformé en <list> ... </list>.

Nous prenons maintenant l’exemple présenté dans la section précédente (section 2), et nous expliquons comment l’étape d’extraction et d’adapta-tion des données est effectuée. La Figure 6.4 affiche l’étape de prétraite-ment.

Chapitre 6. Approche I

Figure 6.4 – Prétraitement : Exemple d’extraction et d’adaptation des données

Comme le montre la Figure 6.4 la partie supérieure (a) affiche le code HTML de l’exemple de déroulement, sur lequel nous appliquons le processus de prétrai-tement, à savoir l’extraction et l’adaptation des données. Le résultat est montré dans la partie (b) et (c) de la Figure 6.4. Le langage (tags) utilisé pour l’adaptation est défini par le méta-modèle source qui sera détaillé dans la section suivante. Le résultat de l’étape de prétraitement sera automatiquement transmis à l’étape suivante.

6.3.2 Étape de réingénierie basée sur l’IDM

Cette deuxième étape constitue le noyau du système. Elle est basée sur l’in-génierie dirigée par les modèles (IDM), et se compose de trois couches définies selon les exigences de l’IDM (Figure 6.5). La couche M0 contient le fichier d’en-trée reçu de l’étape précédente (prétraitement) et le fichier de sortie (fichier RDF) que nous voulons créer par ce système. La couche M1 comprend trois fichiers, notamment deux méta-modèles (MM), l’un pour définir le MM source et l’autre pour le MM cible, et le troisième fichier représente le moteur de transformation. Enfin, la dernière couche (M2) est constituée du méta-méta-modèle de tous les fichiers définis dans la couche précédente (M1). Nous allons discuter et décrire en détail ces couches dans les sous-sections suivantes.

Figure 6.5 – Processus de réingénierie basé sur les modèles

La couche M0

Dans la couche M0 correspondant au monde réel, il y a deux fichiers : le fichier d’entrée et le fichier de sortie (fichier résultant) :

• Le premier fichier (fichier d’entrée) représente le résultat obtenu de l’étape de prétraitement. Il contient des données que nous souhaitons transformer en données sémantiques. Ce fichier est un ensemble de balises définies dans le méta-modèle source ; il constitue donc son instance. Ces balises transportent les données à transformer en triplets RDF.

• Le second fichier (RDF) est celui qui sera obtenu en appliquant les règles de transformation sur le fichier d’entrée. Les deux contiennent les mêmes données, mais dans des représentations différentes. Avec le format RDF, les données deviennent accessibles et compréhensibles, et donc exploi-tables par machine.

La couche M1

C’est la couche des méta-modèles. Dans notre système, cette couche contient deux méta-modèles : source et cible, et le fichier qui contient les règles de trans-formation.

Les méta-modèles sont écrits en langage Ecore [Jouault 2008], qui est un lan-gage de méta-modélisation basé sur des notations assez similaires à celles du diagramme de classes UML. En fait, Ecore est une implémentation d’Eclipse du standard MOF (Meta Object Facility). Notez que Ecore est défini par lui-même. Ecore est le noyau de l’EMF (Eclipse Modeling Framework) [Steinberg et al. 2003] qui permet aux utilisateurs de créer facilement des langages de conception.

Chapitre 6. Approche I

Le fichier de règles de transformation est écrit en langage ATL (Atlas Transforma-tion Language)[Jouault 2008]. ATL est un langage de transformation des modèles basé sur une syntaxe textuelle concrète. ATL fournit les moyens pour corres-pondre chaque élément du méta-modèle source avec un élément du méta-modèle cible.