Denelezh 2.0, a transitional version

At the beginning of April, a new version of Denelezh, a tool to explore the gender gap in the content of Wikadata and Wikimedia projects, was released. This post explains what led to this new version, including the choice of a new methodology to generate the metrics, and what you can expect in future releases. Finally, a technical overview of the tool is provided.

What’s new

A 4th dimension

Since its inception, Denelezh provides multidimensional analysis. You can explore the gender gap in Wikidata by several dimensions: the year of birth, the country of citizenship, and the occupation of a human. It is possible to combine these dimensions, for example to have metrics on the gender gap for French politicians born in 1901.

The most visible improvement in this new version of Denelezh is the addition of a fourth dimension: the Wikimedia project. All projects that have at least one page about a human according to Wikidata are included: not only the English Wikipedia, but also the young Atikamekw Wikipedia, Wikimedia Commons, Wikispecies, the Polish Wikiquote, …

Data is still extracted from Wikidata using its weekly dump. Thus, you can go back in time to observe the evolution of metrics you are interested in. For example, the French Wikipedia had 16.0 % of its biographies about women in January 2017, 16.3 % in July 2017, 16.6 % in January 2018, and is now, in April 2018, at 16.8 %. It seems encouraging but, in the meantime, 33,107 biographies about men were added in the French Wikipedia and only 11,202 about women.

A new methodology

Although it is less visible, the most important improvement in this version is the new methodology to generate the statistics. The idea is to generalize the statistics produced in the first version of the tool.

In the previous version, only around 50 % of humans in Wikidata were kept, mainly in the hope that keeping only humans with all studied dimensions would improve the quality of the metrics provided by the tool. The problem is that this hypothesis was never confirmed (nor contradicted). Now, all data available is used, and in particular:

• Items with several best values for the property instance of are not discarded anymore (they are representing humans as long as one of these values is human).
• Humans born before 1600 are not discarded anymore.
• All normal and preferred values of the property country of citizenship are used; humans are not limited to one country of citizenship anymore.

The tool does not try anymore to provide statistics about biases by introducing new biases 🙂

Other improvements include:

• Parent occupations are deduced using the property subclass of. In this way, the tool directly provides metrics about general occupations, like politician or scientist.
• All sitelinks are used, and not only a (buggy) subset of them.

Future

Main features

Even if they need to be clearly defined, the main new features will be:

• the addition of a fifth dimension (external IDs, but it is still needed to check that it will possible),
• the introduction of charts to track changes over time,
• the ability to compare sets.

It will also be the transformation of Denelezh into a more general tool, as explained in the next section.

Data quality

I already worked on data quality in Wikidata, for example by cleaning BnF IDs (in French) or by contributing to Wikidata about the members of the French parliament with Dicare (in French). In this last case, a dedicated dashboard (in French) provides statistics on the data held by Wikidata about members of the French National Assembly, legislature by legislature, and insights on what needs to be improved.

The idea is to provide, with Denelezh, a general dashboard to help Wikimedians to contribute about humans, with not only data on the gender gap but also other metrics, like missing properties (number of people without a gender, without a date of birth, …).

Usability

Usability is an important topic that needs to be covered. For example, the form needs to be more understandable and to have a dedicated documentation. A lot of little things can drastically improve the tool, like to provide links to Wikidata items, links to the Wikidata Query Service to have live results, exports in CSV format… Finally, Denelezh needs internationalization: it’s quite ironic to have an application about gaps only available in English!

Technical overview

Architecture

The tool is still divided in three parts:

• A Java project, using the Wikidata Toolkit (0.8.0), to extract data from Wikidata weekly JSON dumps. It generates several CSV files in a format intended to be easily loaded into a relational database.
• A PHP script, which purpose is to generate SQL queries. These queries load the data from the CSV files into a MySQL database and compute it (in summary, it aggregates the data for the multidimensional analysis).
• A website, to display the data.

In order to have reproducible results, the Wikidata Query Service is not used anymore (it was only used for labels in the previous version).

Some metrics

Denelezh is installed on a dedicated server with an i5-3570S CPU, 16 GB of RAM, and a slow hard disk, running Debian 8 (Jessie) as the operating system, nginx as the web server, and MySQL 5.7 as the relational database. The processing of the most recent dump (2018-04-09) takes around 11 hours:

• about 4 hours and 15 minutes for downloading the dump,
• more than 2 hours for the processing of the dump by Wikidata Toolkit,
• about 4 hours and 30 minutes for the loading and computing into MySQL.

From this dump, 29,338,817 sets with at least one human were generated. The corresponding MySQL data file is about 2.7 GB. Data from each dump is stored in a separate MySQL partition to improve performance and to ease maintenance.

Feedbacks

Feel free to send feedbacks, by email (envel -at- lehir.net) or on my Wikidata talk page.

The following list is a synthesis of possible evolutions of the tool, collected from the Wikimedia community, both online (including on Wikimedia projects like Wikidata, English Wikipedia, French Wikisource, etc. but also on social networks like Twitter or Telegram) and offline (for instance at Wikimania, WikidataCon, volunteers meetings, etc.).

Features

Technical

Bilan de Dicare

Dicare était un site web consacré aux députés de la V^e République française. Un de ses objectifs était de mettre en valeur les projets Wikimedia, en montrant qu’il est possible de réutiliser leurs contenus dans d’autres projets. Ainsi, les données structurées de Dicare provenaient de la base de connaissance Wikidata et les images de la médiathèque Wikimedia Commons.

Dicare

Le cœur de Dicare était l’historique des mandats de la députés de la V^e République (avec pour chacun : député, législature, circonscription électorale, dates de début et de fin). Avant 2016, les informations de Wikidata sur ce sujet étaient parcellaires. Depuis son ouverture en avril 2016,  le site m’a permis de suivre mes contributions sur ce thème. À son terme, Dicare disposait de données sur plus de 2500 députés de la V^e République. Tous les mandats étaient renseignés pour la précédente et l’actuelle législatures (14^e et 15^e), ainsi que pour l’ensemble de la V^e République pour de nombreux départements (dont tous les départements bretons). En plus de cet historique, plusieurs sujets ont été explorés.

Le premier a été la longévité des députés à l’Assemblée nationale. Ainsi, on peut noter quelques records, à commencer par celui de Didier Julia, qui a passé plus de 44 ans sur les bancs de l’Assemblée. D’autres sont restés moins longtemps : une journée pour Catherine Pen, dans l’incapacité de remplacer la députée dont elle était suppléante ; quelques jours pour de nombreux suppléants, remplaçant des députés nommés au gouvernement juste avant les élections législatives ; etc.

Un deuxième sujet a été l’égalité femme-homme. Ce n’était évidemment pas une découverte, la parité n’a jamais existé à l’Assemblée nationale, même si elle s’améliore sensiblement depuis la 11^e législature en 1997. Auparavant, il y avait toujours eu moins de 10 % de femmes à l’Assemblée nationale !

Un troisième sujet a été l’usage de Twitter par les députés. J’ai pris le temps, pour l’ensemble des députés des 14^e et 15^e législatures, de vérifier s’ils avaient un compte Twitter (et le cas échéant de le renseigner dans Wikidata). Voici, en février 2017, le nombre de députés avec un compte Twitter, en fonction de leur tranche d’âge :

Suite aux élections législatives de juin 2017, les chiffres se sont nettement tassés (pour chaque tranche d’âge, au moins 70 % des députés avaient un compte Twitter), probablement car la communication sur les réseaux sociaux faisait partie des stratégies de campagne de bon nombre de candidats.

Enfin, un bot Twitter souhaitait chaque jour l’anniversaire des députés avec un mandat en cours, ce qui a pu mener à quelques discussions amusantes, comme celle-ci.

Qualité des données

Les données de Wikidata étaient importées ponctuellement dans Dicare. Plusieurs méthodes m’ont permis de m’assurer de la qualité des données présentes dans Wikidata avant ou après leur import dans Dicare :

• lors de l’import, quelques données étaient filtrées (par exemple parce qu’elles n’avaient pas le format attendu ou la précision nécessaire) ;
• après l’import, le site web listait les députés ne respectant pas certaines règles (données manquantes comme une date de naissance non renseignée, ou données incohérentes comme le chevauchement dans le temps des mandats de deux députés dans la même circonscription) ;
• sans lien avec les imports, une page web de statistiques indique le nombre de députés ne respectant pas certaines règles, avec la possibilité de les lister. Le premier intérêt de cette page est que le contrôle se fait directement sur les données Wikidata (grâce au endpoint SPARQL), sans nécessiter d’import. Le second avantage est que l’affichage est optimisé pour le sujet (par exemple, les listes sont découpées par législature). C’est pour moi le meilleur moyen de contrôler la qualité des données de Wikidata sur ce sujet, plus puissant que les listes d’erreurs des contraintes Wikidata (limitées dans leurs possibilités) et plus ergonomique, avec une visualisation immédiate des problèmes et des liens vers les sources les plus communes sur le sujet.

À noter que le gadget checkConstraints de Wikidata est également excellent, mais utilisable sur un seul élément Wikidata à la fois (et avec toujours les limitations de l’expressivité des contraintes).

J’ai rapidement testé le moteur de règles JBoss Drools, mais il s’est avéré assez peu adapté dans mon cas : développement dans un second langage de programmation par rapport au site web, nécessité de répliquer le modèle de données, etc. L’usage du framework est plus approprié pour des problématiques plus complexes et avec une homogénéité dans les choix techniques.

Enfin, je n’ai pas encore eu le temps d’essayer ShEx.

Fin et suite

Le site a fermé en mars 2018. Toutefois, rien n’est perdu. Les données restent disponibles dans les projets Wikimedia : les données structurées dans Wikidata et les images dans Wikimedia Commons. Les projets Élus et Parliamants sont toujours actifs sur Wikidata. Par ailleurs, le code source du site est disponible sous licence libre (AGPLv3) sur GitHub. Les outils associés (Dicare Tools) sont toujours disponibles et leur code source est sur GitHub.

Nettoyage de l’identifiant BnF dans Wikidata

Wikidata est une base de connaissance, structurée, multilingue et libre. Elle centralise des informations utiles aux projets Wikimedia, dont le plus connu est l’encyclopédie Wikipédia. Wikidata regroupe ainsi des données sur de nombreux sujets : entités géographiques, personnalités de tous domaines, œuvres d’art, articles scientifiques, etc. Une entrée dans la base de données de Wikidata est appelée un « élément », Wikidata en comptant près de 40 millions aujourd’hui.

Logo de Wikidata.

Un des intérêts de cette base de connaissance est de faire le lien avec d’autres sites et d’autres bases de données. Par exemple, à partir de l’élément Wikidata consacrée à Cécile Corbel, on peut naviguer vers son profil Instagram, sa fiche sur l’Internet Movie Database (IMDb), ou encore vers la notice correspondante dans le catalogue général de la Bibliothèque nationale de France (BnF). Nous allons voir ici comment sont fait ces liens et comment en améliorer la qualité.

Identifiants

Dans une base de données, chaque entrée possède un identifiant unique qui permet de distinguer de façon certaine une entrée des autres. Par exemple, le mot « Aube » peut désigner un cours d’eau, un département ou encore des communes de la Moselle et de l’Orne, etc. Il est donc nécessaire de pouvoir différencier ces concepts, ce que l’ont fait grâce à un identifiant. Cet identifiant est immuable, c’est-à-dire qu’il n’évolue pas, même si l’entrée à laquelle il est rattaché change de nom. Il ne porte également pas d’information. Enfin, le format d’un identifiant est propre à chaque base de données.

Dans Wikidata, l’identifiant d’un élément débute par la lettre « Q », suivie d’un nombre. Par exemple, l’identifiant de l’élément sur Frédéric Courant est « Q3089735 ». L’identifiant d’une propriété, qui permet de caractériser les éléments, débute par la lettre « P », suivie d’un nombre. Ainsi, la propriété « identifiant Bibliothèque nationale de France », qui lie un élément Wikidata à une entrée du catalogue de la BnF, a pour identifiant « P268 ».

Dans le catalogue de la BnF, les identifiants sont au format Archival Resource Key (ARK). Par exemple, l’identifiant de l’entrée sur Frédéric Courant est ark:/12148/cb14089584s. En simplifiant :

• ark correspond au protocole utilisé ;
• 12148 est l’identifiant de l’autorité qui émet l’identifiant (Name Assigning Authority Number ou NAAN, voir ce précédent billet, en anglais), ici la BnF ;
• cb correspond au catalogue de la BnF ;
• 14089584, une série de 8 chiffres, est l’identifiant de l’entrée en elle-même ;
• s, le dernier caractère, est une clé qui permet de vérifier la cohérence de l’identifiant.

Une explication détaillée sur le format ARK est disponible ici (en anglais).

Wikidata stocke les deux dernières informations dans sa propriété P268. Ainsi, l’élément « Q3089735 » de Wikidata a pour la propriété « P268 » la valeur « 14089584s ».

Qualité des données

À l’occasion de la WikidataCon, Alessandro Piscopo a présenté, lors de sa conférence intitulée « Wikidata quality: a data consumers’ perspective », différentes dimensions possibles pour évaluer la qualité des données :

• exactitude (absence d’erreur) ;
• objectivité (absence de biais) ;
• réputation (confiance) ;
• cohérence ;
• à jour ;
• complétude ;
• interprétabilité  ;
• chaînage (liens avec d’autres bases de données).

Comme on va travailler sur la propriété qui fait le lien entre Wikidata et la BnF, la dernière dimension citée est la première concernée. Toutefois, l’approche va se faire essentiellement par la première dimension, l’exactitude, en détectant des erreurs dans Wikidata.

À chaque propriété Wikidata est associé un ensemble de « contraintes ». Une contrainte est la formalisation d’une règle que doit suivre chaque utilisation d’une propriété. Par exemple, un être humain doit avoir sa date de naissance antérieure à sa date de décès. Chaque propriété dispose d’un rapport de violations de contraintes, complété automatiquement, pointant vers chaque élément ne respectant pas une contrainte donnée. Voici le rapport de violations de contraintes de la propriété P268 sur Wikidata.

On va toutefois aller plus loin que ce rapport, qui présente certaines limites. Pour cela, on va utiliser le service de requêtes SPARQL de Wikidata, qui dispose d’une aide détaillée. Celui-ci permet d’interroger le contenu de Wikidata, avec des demandes qui peuvent être complexes.

Règles

Éléments Wikidata avec un format de l’identifiant BnF incorrect

La première chose à faire est de vérifier que le format de l’identifiant BnF est respecté. Il doit pour cela vérifier l’expression régulière \d{8}[0-9bcdfghjkmnpqrstvwxz] (8 chiffres suivis du caractère de la clé). Voici la requête SPARQL listant tous les éléments Wikidata ne respectant pas cette règle :

SELECT ?item ?bnf
WHERE {
  ?item p:P268/ps:P268 ?bnf .
  FILTER (!REGEX(?bnf, "\\d{8}[0-9bcdfghjkmnpqrstvwxz]")) .
}

Requête #1 : format de l’identifiant BnF incorrect (valeur)

Toutefois, cette requête, tout comme le rapport de violations de contraintes, ne vérifie le format de l’identifiant BnF que lorsqu’il est utilisé comme valeur directe d’une propriété. Il faut donc vérifier son format lorsqu’il est utilisé respectivement en qualificatif et en référence d’une déclaration :

SELECT ?item ?property ?bnf
WHERE {
  ?item ?property ?statement .
  ?statement pq:P268 ?bnf .
  FILTER (!REGEX(?bnf, "\\d{8}[0-9bcdfghjkmnpqrstvwxz]")) .
}

Requête #2 : format de l’identifiant BnF incorrect (qualificatif)

SELECT ?item ?property ?bnf
WHERE {
  ?item ?property ?statement .
  ?statement prov:wasDerivedFrom/pr:P268 ?bnf .
  FILTER (!REGEX(?bnf, "\\d{8}[0-9bcdfghjkmnpqrstvwxz]")) .
}

Requête #3 : format de l’identifiant BnF incorrect (référence)

À noter que ces requêtes ne vérifient pas la validité de la clé associée à l’identifiant.

Éléments Wikidata avec plus d’un identifiant BnF

Chaque élément Wikidata représente un seul concept, auquel ne devrait être associé qu’un seul identifiant BnF (il peut toutefois y avoir des cas à la marge qui sont discutables, mais ce n’est pas l’objet de ce billet). Cette requête, qui se limite aux être humains, nous montre pourtant que ce n’est pas le cas :

SELECT ?item (COUNT(DISTINCT ?bnf) AS ?count)
WHERE {?item wdt:P31 wd:Q5 ; wdt:P268 ?bnf . }
GROUP BY ?item
HAVING (?count >= 2)
ORDER BY DESC(?count) ?item

Requête #4 : éléments Wikidata avec plus d’un identifiant BnF

Identifiants BnF utilisés plusieurs fois

Un même identifiant BnF ne devrait être utilisé que par un seul élément Wikidata. Cette requête, également limitée aux êtres humains, nous montre que ce n’est non plus pas le cas :

SELECT ?bnf (GROUP_CONCAT(?item) AS ?items) (COUNT(*) AS ?count)
WHERE { ?item wdt:P31 wd:Q5 ; wdt:P268 ?bnf . }
GROUP BY ?bnf
HAVING (?count >= 2)
ORDER BY DESC(?count) ?bnf

Requête #5 : identifiants BnF utilisés plusieurs fois

Éléments Wikidata avec la valeur de l’identifiant BnF utilisé dans une autre propriété

Lorsque les informations sur un élément Wikidata sont saisies à la main, une erreur de copier-coller peut facilement arriver, et parfois le même identifiant est utilisé pour deux propriétés différentes. Il est facile de lister ces cas avec cette requête :

SELECT ?item ?property
WHERE {
  ?item wdt:P268 ?id ; ?property ?id .
  FILTER(?property != wdt:P268) .
}
ORDER BY ?property

Requête #6 : identifiant BnF utilisé dans une autre propriété

Éléments Wikidata avec un identifiant BnF et une déclaration sourcée par un autre identifiant BnF

Lorsque l’on source une déclaration dans Wikidata, c’est une bonne pratique de renseigner l’identifiant externe utilisé lorsque le cas s’y prête. En effet, cela permet, lors de la correction d’un identifiant externe, de nettoyer l’élément en repérant facilement les déclarations sourcées avec cet identifiant erroné et donc à corriger. Toutefois, il peut y avoir des oublis. Voici la requête, limitée aux être humains, qui permet de les repérer (avec potentiellement des faux positifs) :

SELECT ?item ?itemLabel ?property ?bnf_s ?bnf_r
WHERE {
  ?item wdt:P31 wd:Q5 ; wdt:P268 ?bnf_s .
  ?item ?property ?s . ?s prov:wasDerivedFrom/pr:P268 ?bnf_r .
  FILTER(?bnf_s != ?bnf_r) .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" . }
}
ORDER BY ?item ?property

Requête #7 : éléments Wikidata avec un identifiant BnF et une référence utilisant un autre identifiant BnF

Éléments Wikidata avec un identifiant Bnf et des propriétés manquantes

Chaque élément Wikidata devrait avoir l’une de ces deux propriétés renseignées : « nature de l’élément » (P31) ou « sous-classe de » (P279). Cela permet d’indiquer le type de concept représenté par l’élément. Par exemple, les être humains ont pour « nature de l’élément » la valeur « être humain » (Q5). Voici la requête qui liste les éléments avec un identifiant BnF et pour lesquels ces deux propriétés sont absentes :

SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P268 [] .
  FILTER NOT EXISTS { ?item wdt:P31 [] . } .
  FILTER NOT EXISTS { ?item wdt:P279 [] . } .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
}
ORDER BY DESC(xsd:integer(SUBSTR(STR(?item), 33)))

Requête #8 : éléments Wikidata avec un identifiant BnF et sans P31 ou P279

Écrivains français sans identifiant BnF dans Wikidata

On peut s’attendre à ce que tous les écrivains français soient présents dans le catalogue de la BnF et aient donc un identifiant BnF dans Wikidata. Sans surprise, ce n’est évidemment pas le cas :

SELECT DISTINCT ?item ?itemLabel
WHERE {
  ?item wdt:P31 wd:Q5 ; wdt:P27 wd:Q142 ; wdt:P106/wdt:P279* wd:Q36180 .
  MINUS { ?item wdt:P268 [] } .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" . }
}
ORDER BY xsd:integer(SUBSTR(STR(?item), 33))

Requête #9 : écrivains français sans identifiant BnF

À suivre…

Nous avons vu plusieurs moyens de détecter des erreurs dans Wikidata. Toutefois, il faut bien réaliser que seules certaines erreurs sont détectées. Par exemple, on ne peut pas se rendre compte qu’un identifiant est mal attribué, sauf s’il apparaît sur un autre élément. D’autre part, la correction des erreurs n’a été que survolée. Celle-ci est la plupart du temps triviale, mais peut nécessiter de fusionner des pages Wikipédia et des éléments Wikidata, ou au contraire de les séparer, etc. L’erreur peut également être du côté de la BnF (il suffit alors d’utiliser la fonction de signalement d’erreur disponible sur chaque notice). Il faudrait également mesurer le travail accompli : nombre total d’éléments Wikidata avec un identifiant BnF, nombre d’éléments détectés par chaque règle, nombre d’éléments corrigés, etc.

Par ailleurs, lancer ces requêtes manuellement peut être fastidieux et on peut imaginer des outils pour simplifier le travail. Ainsi, sur la thématique des députés, j’ai réalisé un tableau de bord qui donne des statistiques et vérifie une vingtaine de règles dans Wikidata. Les données sont mises à jour régulièrement et l’interface permet d’accéder rapidement aux éléments concernés, ainsi qu’aux autres bases de données de cette thématique.

Enfin, la Bibliothèque nationale de France organise un hackathon ce week-end des 25 et 26 novembre 2017, ce qui est une bonne occasion de découvrir et réutiliser ses données, notamment grâce à son nouveau portail api.bnf.fr 🙂

Welcome to my personal blog! I'm Envel Le Hir, a French Wikimedian.
Some posts may be written by guests.

Search

Last Posts

• [en] Denelezh 2.0, a transitional version
• [fr] Bilan de Dicare
• [fr] Nettoyage de l'identifiant BnF dans Wikidata
• [en] Weekend at the Museum (of Brittany)
• [en] The French Connection at the Wikimania 2017 Hackathon
• [fr] Neuf mois plus tard
• [fr] Le canal de Nantes à Brest
• [fr] Odonymie rennaise
• [en] A tool to estimate the gender gap in Wikidata and Wikipedia
• [fr] Les visages du commissaire Maigret
• → Archives

Some projects

• [en] MySQL Defaults Checker
• [en] Gender Gap in Wikidata
• [fr] Dicare