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:

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

Other improvements include:

Future

Main features

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

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:

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:

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

Type Name Description
Core feature Evolution Each metric should be traceable over time. Example: evolution of the gender gap on English Wikipedia for the last two years, with a value every month.
Core feature Comparison The metrics from two sets should be comparable. Example: compare occupations from two Wikipedias.
Metrics Base metrics The following statistics should be available for each set:

  • total number of humans
  • number of humans with exactly one gender [already exists]
  • number of females, males, and others [already exists]
  • number of humans with at least / exactly one distinct year of birth (at preferred rank)
  • number of humans with at least / exactly one distinct year of death (at preferred rank)
  • number of humans with at least / exactly one distinct place of birth (at preferred rank)
  • number of humans with at least / exactly one distinct place of death (at preferred rank)
  • number of humans with at least one country of citizenship (at preferred rank)
  • number of humans with at least one occupation (at preferred rank)
  • number of humans with at least one image (at preferred rank)
  • number of humans with at least one given name (at preferred rank)
  • number of humans with at least one family name (at preferred rank)
Metrics External ID metrics External ID should be another available dimension (in addition to year of birth, country of citizenship, occupation, and project). Note: very expensive, may need optimization (probably architecture change) or features limitations (removal of another dimension, drill down limited to N levels, …).
Metrics Fictional content Exploration of instances of fictional human (Q15632617), in addition to human (Q5), should be possible.
UI/UX Internationalization The application should be available in more languages than just English.
UI/UX Sub-occupations Display sub-occupations deduced by the subclass of property to facilitate the study of a set and drill down.
UI/UX Set of projects Metrics should be available by set of projects (i.e. all Wikipedias, all Wikisources, …).
UI/UX Time intervals Improve time intervals display: show metrics year by year, decade by decade, century by century, etc. in accordance with the size of the time interval chosen.
UI/UX Links to Wikidata Each concept should be linked to its Wikidata item.
UI/UX Links to projects Each project should be linked when cited, with a friendly name (not its code).
UI/UX Links to WDQS Each set should be linked to a SPARQL query to retrieve live data.
API API Provide an API so the data could be used by third-parties.
API Export Statistics should be available in CSV format.
Other Cleaning Provide a list of barely used countries and occupations.

Technical

Category Name Description
Bug Graphics artifacts Sometimes, there is a blank area between the orange (female) and green (male) areas, even when there is no human with other gender in the set.
Optimization Database schema optimization In the database, BIGINT should be replaced by INT in many places (in Wikidata, the ids are far from the INT limit of 4,294,967,295).
Optimization Labels import optimization Only load into database the labels that are used (at the end of the Wikidata Toolkit job, generate a second label.csv file with only useful labels before loading them into database).

Bilan de Dicare

Dicare Ă©tait un site web consacrĂ© aux dĂ©putĂ©s de la Ve 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 Ve 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 Ve RĂ©publique. Tous les mandats Ă©taient renseignĂ©s pour la prĂ©cĂ©dente et l’actuelle lĂ©gislatures (14e et 15e), ainsi que pour l’ensemble de la Ve 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 11e 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 14e et 15e 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 :

Tranche d’Ăąge Nombre de dĂ©putĂ©s Avec un compte Twitter Part
39 ans et moins 17 17 100 %
40 — 49 ans 83 76 92 %
50 — 59 ans 181 158 87 %
60 — 69 ans 189 140 74 %
70 ans et plus 102 58 57 %

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 :

À 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 :

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 :

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 🙂