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.
RSS 2.0