Accueil > Code > Réutiliser le contenu libre des projets Wikimedia

Réutiliser le contenu libre des projets Wikimedia

mardi 5 avril 2011, par Nicolas

Introduction

Les projets Wikimedia sont sous une licence très claire. La plupart des textes sont sous licence Creative Commons CC-BY-SA, qui permet une réutilisation du contenu de façon simplifiée, ou les éléments sont dans le domaine public (nombreux textes sur Wikisource ou media sur Commons notamment) [1].

La réutilisation de ces données est donc possible juridiquement [2]. Cependant une réutilisation automatique est bien plus compliquée à mettre en œuvre.

Récupérer le contenu

Il est bien sûr possible de récupérer manuellement des données et de les traiter. Ceci se heurte rapidement à de nombreux obstacles : problématique de la mise à jour, volumes de données à traiter, systématisation [3].

Il existe deux [4] façons de récupérer de façon automatisable le contenu :

  • réutiliser les dumps de base
  • appeler les APIs

Réutiliser les dumps de base

Wikimedia met à disposition des dumps de base, qui permettent de recréer le contenu textuel des projets à un instant donné. Mises à jour régulièrement, ces copies fournissent toutes les informations nécessaires : contenus textuels [5] bruts, mais aussi éléments calculés comme liens entre pages, catégories, utilisations des templates, etc.

Les noms des fichiers générés sont calculables automatiquement à partir du projet et de la date, et leur récupération se fait donc facilement.

Les fichiers sont des dumps faits via mysqldump et donc simplement importables dans une base MySQL [6]. La seule exception est le fichier contenant les contenus des articles, qui est un format XML qui peut être importé dans MediaWiki. Une description plus complète est disponible sur la page associée.

Il est possible à partir de ces fichiers soit de reconstruire le contenu textuel, soit d’extraire des données statistiques sur les articles [7].

A priori seul le fichier XML contenant les articles est à importer pour reconstituer le contenu, mais cette opération est très coûteuse vu le volume de données et les traitements à faire [8], et il faut une installation MediaWiki disponible pour l’import, ce qui implique un serveur Web, une base de données, PHP.

Il est bien sûr possible de traiter les fichiers SQL pour extraire des informations sans importer via MySQL, ou de traiter le fichier XML avec un parseur spécifique, mais cela implique un développement sur mesure.

Appeler les API

Les projets Wikimedia exposent, via les API de MediaWiki, la quasi-totalité des données du projet : contenus, liens entre pages, catégories, utilisation des media, etc.

Utilisant un format d’appel (GET ou POST) et de réponse (XML) assez simple, ces APIs bien documentées permettent de consulter [9] les données réelles, sans délai, des différents projets.

À peu près toutes les informations que l’on pourrait vouloir sont ainsi exposées.

Il subsiste une question sur la limite d’utilisation des API, en nombre par seconde, en nombre par jour, un délai entre des requêtes, etc. Il ne semble pas y avoir d’information générale officielle, donc une zone d’ombre subsiste.

Exploiter le contenu

Une fois les informations (liste d’articles par exemple) obtenues se pose le problème de leur utilisation effective.

Si le but est de faire des statistiques ou traitement généraux sur les articles [10], la récupération décrite ci-dessus donne probablement tous les éléments requis. En revanche si l’objectif est de réutiliser le contenu textuel [11], au-delà de la simple mise à disposition via un wiki MediaWiki, les difficultés ne sont pas terminées.

Le contenu textuel d’une page MediaWiki peut être récupéré sous deux formats :

  • le markup brut MediaWiki ; c’est le format récupéré depuis le dump XML des articles, ou à travers l’une des API de consultation
  • du code HTML, récupéré via un appel à index.php en spécifiant action=render

Sur le papier, les balises du markup de MediaWiki ne sont pas trop compliquées à traiter [12]. Il y a cependant le choix de l’apostrophe comme marqueur pour italique et gras qui donne du fil à retordre pour interpréter correctement ’’’Mais qui a eu l’’’idée’’ d’utiliser l’apostrophe ?’’’. Mais il est simple de tout bonnement réutiliser le même algorithme que MediaWiki lui-même.

MediaWiki lui-même utilise toute une batterie de tests afin de vérifier le traitement, tests qui peuvent être utilisés pour faire un parseur compatible.

Les modèles utilisés dans les pages rajoutent une première difficulté, surtout avec les paramètres facultatifs ou les imbrications.

Le problème majeur à mon sens vient des nombreuses extensions utilisées, notamment les expressions logiques. Interpréter {{Formatnum:12345}} implique de traiter les modèles sous-jacents et de reproduire les extensions utilisées pour bien rendre le contenu. Pour correctement traiter n’importe quelle page, il faut donc simuler la plupart des extensions [13], y compris les exotiques comme l’affichage des hiéroglyphes.

L’autre solution pour récupérer le contenu textuel est simplement de le récupérer directement depuis les serveurs MediaWiki via index.php, par exemple l’accueil. Ceci a l’avantage de permettre de récupérer la dernière version du texte, et de s’affranchir des problèmes de traitement du markup. Cependant encore une fois les limites admises par Wikimedia ne sont pas clairement définies — est-il acceptable de télécharger 10 000 pages par jour ? 100 par minute ?

Une dernière problématique est le « filtrage » des éléments textuels récupérés. La plupart des pages [14] comportent des bandeaux à différents endroits, des infobox à droite, des références, bref de nombreux éléments que l’on peut vouloir nettoyer pour une raison ou une autre, ou organiser autrement. Autant il est simple de nettoyer les liens d’une page, autant ce nettoyage d’éléments est rendu complexe par leur diversité, leur identification. Sur certains projets les éléments ont des classes CSS associées [15], permettant leur détection automatique. Par contre sur d’autres projets c’est moins systématique. Exemple au hasard, cette page Wikibooks n’identifie pas la table d’entête, d’où la nécessité de mettre une règle manuelle excluant la première table. Sauf que cette règle n’est pas valide pour cette autre page, d’où le besoin d’une différenciation de traitement.

Bien sûr encore une fois pour un petit volume de données la tâche n’est pas insurmontable, mais pour traiter 10, 50 000 pages, cela devient vite casse-tête de correctement filtrer.

Conclusion

Au final, la réutilisation systématique et automatique des contenus textuels n’est pas une mince affaire. De nombreux éléments peuvent être automatisés, mais doivent être ajustés à la main.

Pire, la cible est plutôt mouvante, car les usages des modèles, infobox, les classes indiquant divers éléments évoluent avec le temps, en conséquence de quoi les ajustements doivent régulièrement être vérifiés.

Il faut de plus souligner la difficulté de vérifier de façon automatique le résultat des traitements. Un indicateur comme une longueur de texte vraiment courte est un indice potentiel de problème sur un article, et donc sur un traitement, mais à part vérifier à la main tous les contenus extraits il est impossible de certifier qu’un élément n’a pas été mal traité à un moment ou un autre.

Bref, pour une réutilisation sérieuse, il faut semble-t-il engager des moyens assez lourds en termes de ressources.


[1Il y a bien sûr plus de licences que cela mélangées, voir sur chaque élément particulier sa licence respective.

[2Sous réserve de respecter les clauses des licences bien sûr.

[3Par exemple récupérer tous les articles consacrés à la mythologie grecque.

[4Ce sont les deux que je vois, mais bien sûr il en existe peut-être d’autres que je serais ravi de découvrir.

[5Les fichiers comme images, sons, vidéos ne sont pas fournis en téléchargement « paqueté », sans doute à cause du volume que cela représente. Il est par contre possible de les récupérer directement depuis les serveurs Wikimedia.

[6Peut-être le format est-il compatible avec d’autres bases comme PostgreSQL, selon les options utilisées.

[7Par exemple nombre moyen de liens vers ou depuis un article, nombre de contributeurs, ce genre de statistiques.

[8Reconstituer les différentes tables comme liens internes et externes, catégories, etc.

[9Les API permettent une interaction assez complète avec les projets, notamment les contributions, la consultation des listes de suivi, etc. Cette partie est ignorée ici car ce n’est pas le sujet de ce billet.

[10Nombre moyen de liens, nombre moyen d’articles par catégories, permettre une navigation par catégorie, etc.

[11Les contenus media comme sons, images, vidéos sont plus simples à traiter, car il « suffit » de récupérer les fichiers désirés, dont le nom est calculable facilement à partir d’une liste de pages media. Il faut bien sûr faire attention à la licence de ces fichiers, ce qui peut impliquer un traitement du contenu textuel pour récupérer le nom de l’auteur ou autre information...

[12Il est d’ailleurs probablement possible d’utiliser le propre parseur de MediaWiki pour produire le texte voulu. Ceci implique l’utilisation de PHP pour ce traitement.

[13Bien sûr, si le but est de dupliquer un projet MediaWiki, rien de plus simple que d’installer toutes ces extensions.

[14Sur les projets de Wikimedia. D’autres sites utilisant MediaWiki n’auront pas forcément ce problème.

[15Ainsi sur Wikipédia les bandeaux d’information ont semble-t-il la classe « bandeau », certaines infoxbox une classe « infobox_v2 », etc.