Envel Le HirLe canal de Nantes à Brest
J’avais déjà passé un certain temps sur le sujet du canal d’Ille-et-Rance. Il s’agit d’un petit canal de navigation reliant Rennes à la Manche, construit au début du XIXe siècle sous l’impulsion de Napoléon Ier pour contourner le blocus maritime. La région Bretagne, qui en est aussi l’actuel gestionnaire, a amplement étudié l’objet et chaque écluse est inscrite à l’inventaire général. Certaines font même l’objet d’une protection au titre des monuments historiques. L’institution publique d’exploitation, Canaux de Bretagne, fournit des aides à la navigation, dont une liste exhaustive des écluses et la distance qui les sépare. L’IGN a aussi effectué un relevé altimétrique de quelques uns des limnimètres qui les équipent. Bref, ce fut un jeu d’enfant de croiser toutes ces informations dans un tableur, de créer tous ces éléments dans Wikidata et d’en faire quelques visualisations. C’est aussi une partie de plaisir que de partir en expédition pour aller photographier ces ouvrages d’art dans un environnement des plus bucoliques.
Le canal d’Ille-et-Rance.
Toutefois, le canal d’Ille-et-Rance, avec son unique bief de partage et ses 48 écluses, est bien petit à côté du canal de Nantes à Brest ; 3 biefs, 237 écluses, 5 départements traversés, c’est un ouvrage d’une toute autre ampleur. Et qu’en est-il sur Wikidata ? Rien, ou presque ! Le canal dispose d’un élément, mais pas la moindre écluse… C’est une feuille blanche qui ne demande qu’à être remplie !
Commençons par la modélisation : comment décrire un canal dans Wikidata ? Apparemment, peu se sont déjà adonnés à l’exercice et le canal d’Ille-et-Rance semble être le seul qui rassemble ses écluses en un ensemble cohérent. Comme souvent sur Wikidata, l’usage vaut règle : je choisis de reprendre la même structuration. Les écluses seront ”partie de” l’élément du canal, et réciproquement, avec mention de leur numéro d’ordre. La position dans la série et la distance à la première écluse seront quant à elles indiquées à l’aide de qualificateurs sur la propriété ”parcours le long de”. Les informations géographiques comporteront les coordonnées GPS, l’altitude et le lieu géographique, qui sera le cours d’eau qu’elles aménagent. La localisation administrative sera, sans surprise, la commune sur le territoire de laquelle elles se trouvent. Enfin, il sera fait mention de la protection patrimoniale, quand elle existe.
Mais à la différence du canal d’Ille-et-Rance qui emprunte essentiellement les cours canalisés de… l’Ille et de la Rance, le canal de Nantes à Brest compte trois longues portions artificielles : la jonction de Bout-de-Bois entre l’Erdre et l’Isac (8 écluses), la Jonction d’Hilvern entre l’Oust et le Blavet (53 écluses) et la Jonction du Coronc entre le Doré et l’Hyères (46 écluses). Le service de l‘inventaire les distingue du canal, mais il distingue également les biefs de partage (Tranchée de Glomel et Tranchée d’Hilvern) qui sont notables par l’ampleur des travaux de terrassement qu’ils ont nécessité. J’ai donc créé à part ces éléments, en réutilisant les coordonnées des écluses à chaque embouchure.
Les trois portions artificielles du canal.
Récupérons au passage l’identifiant des autres cours d’eau empruntés. Pour l’Erdre, l’Isac, l’Oust, le Blavet, l’Hyères et l’Aulne, c’est facile, il n’y a pas trop d’homonoymes ou d’ambiguïtés. Mais ça se corse pour le Doré : le cours d’eau est trop peu important pour avoir un article sur Wikipédia et la recherche sur le terme dans Wikidata retourne des centaines de résultats (les œuvres du peintre Gustave Doré, une variété de pomme de terre, une pléthore d’individus dont c’est le patronyme, un royaume toupouri — sans charre, une maison de disques, un chaussetier, une patrouille acrobatique…) En s’en tenant aux étendues d’eau, on réduit à une petite soixantaine, dont un bon paquet de lacs Doré — grâce à (ou à cause de) l’action conjuguée de Geonames, User:GZWDer, la Wikipédia en suédois et la monotonie de la toponymie québecoise. Las, pas de Doré breton, créons-le !
Les œuvres de Gustave Doré.
Les cours d’eau au libellé doré.
Le canal compte 237 écluses, cela fera autant d’éléments à créer. Avec le libellé et la description en français, la nature, « partie de » et sa réciproque, les localisations administrative et géographique, les coordonnées, « parcours le long de », le statut patrimonial et l’identifiant associé, il y aura jusqu’à treize assertions par écluse, soit environ 3 081 assertions. Quick Statements fera le travail.
La position de chaque écluse sur le canal peut être décrite avec la propriété « parcours le long de ». Avec les qualifieurs appropriés, on peut indiquer son numéro d’ordre et sa distance depuis une embouchure, mais aussi indiquer l’écluse précédente et la suivante. Pour construire tout cela avec Quick Statements, il faut connaître l’identifiant des éléments suivant et précédent. Quick Statements est fort, mais pas à ce point : il faudra procéder en deux étapes : créer toutes les écluses puis indiquer leur relation d’ordre. Nous y reviendrons.
Démarrons la construction des assertions dans Calc à partir des sources existantes. Canaux de Bretagne fournit un tableau PDF des écluses avec le numéro d’ordre (l’écluse de Saint-Félix à Nantes est considérée comme la première), la commune, le cours d’eau et la distance. Heureusement, le PDF a une couche texte qu’il est facile de réintégrer dans le tableau avec quelques retraitements manuels.
Il nous faudrait maintenant les coordonnées GPS de chaque écluse. Géoportail pourrait nous les donner mais son API ne semble pas permettre de retrouver facilement les écluses qui nous intéressent. En revanche, un coup d’œil sur OpenStreetMap nous apprend que chaque écluse dispose de coordonnées et que le canal est représenté par une relation qui court de bout en bout. Une écluse est représentée par une way avec un point pour chaque porte. C’est même trop précis pour nos besoins ! Les attributs comprennent le numéro, qui semble cohérent avec le tableau de Canaux de Bretagne, ainsi que le nom. Il sera facile de faire correspondre les deux listes. On utilise Overpass Turbo pour extraire une liste des ways de type écluse rattachées à la relation qui représente le canal. On demande à Overpass de ne renvoyer que le barycentre des points, bien que l’on aurait pu s’amuser à indiquer les coordonnées de portes amont et aval, en utilisant le qualifieur « partie concernée ».
Le résultat est presque complet, il ne manque que quatre écluses (n° 17 à Fégréac, n° 42 à Lanouée, n° 93 à Neulliac, n° 108 à Pontivy), dont certaines à la confluence de cours d’eau, dont l’absence est peut-être plutôt due à la requête. Les numéros d’écluse se suivent, ils sont cohérents avec le document de Canaux de Bretagne, l’alignement dans Calc est facile. Les quatre écluses manquantes sont complétées avec Géoportail. Pas de chance, contrairement aux écluses sur la Vilaine, l’IGN n’a pas relevé l’altitude du zéro des limnimètres, on ne pourra pas faire de profil altimétrique du canal. On trouve bien des repères mais ils ne sont pas placés de façon uniforme : parfois sur les bajoyers, parfois sur les murs aval ou amont, et aussi sur les maisons éclusières. Le changement d’altitude est trop faible d’une écluse à l’autre pour tolérer quelques décimètres d’imprécision. Le service d’estimation de l’altitude du Géoportail souffre des mêmes lacunes.
Les communes où se trouvent les écluses sont faciles à récoler : les dernières versions d’OpenRefine intègrent un nouveau service de réconciliation avec Wikidata. J’importe mon tableau dans OpenRefine, je réconcilie ma colonne « commune » (OpenRefine devine tout seul la nature correcte à partir de quelques échantillons), j’export le tout et le tour est joué.
Résultat de la réconciliation des noms de commune dans OpenRefine.
L’aspect « conservation du patrimoine » est plus compliqué. La région Bretagne a produit un très beau portail de consultation de l’inventaire du patrimoine de la région — qui répond au doux nom de Gertrude, très fouillé, bien documenté… mais difficilement liable depuis le reste des Internets et sans aucune API. Même la base Mérimée est plus accessible de ce point de vue : on peut au moins construire une URL vers un monument dont on connaît l’identifiant Mérimée ! Gertrude utilise quant à elle des GUID dans ses permaliens. On peut tout juste construire une requête au moteur de recherche qui précise un identifiant Mérimée, en espérant que le lecteur voudra bien cliquer sur le résultat de cette recherche.
En revanche, le service du patrimoine a réalisé une étude très fouillée du canal. Celui-ci est considéré par tronçons (on retrouve les canaux de jonction évoqués plus haut ainsi que les voies naturelles), puis par œuvre, avec quelques regroupements intermédiaires. Chacun de ces élément (tronçons et œuvres) dispose de son propre dossier, avec un identifiant à l’inventaire et un permalien. Mais sans moteur de recherche, comment retrouver l’identifiant de dossier de chaque écluse sans éplucher le site manuellement ? La structure des pages est homogène, un crawler assez simple devrait s’en sortir. Un coup de Google : l’état de l’art des crawlers DIY semble être Scrapy, une boîte à outils écrite en Python qui promet l’écriture de crawlers en quelques minutes. Résumons le besoin :
- Construire la liste des URL des pages de chaque écluse du canal.
- Trouver dans chacune de ces pages l’identifiant à l‘inventaire du dossier, qui se trouve toujours au même endroit.
La liste des URL se construit facilement à grands coups de copier-coller et chercher-remplacer, surtout à partir de cette page qui liste les sites d’écluse, plus quelques chaînes d’écluses supplémentaires. On extrait au passage le numéro de l’écluse pour raccrocher le résultat aux données existantes.
Le crawler s’écrit effectivement très facilement. Ce n’est pas très élégant d’écrire en dur les URL à crawler dans le code source, mais j’ai préféré faire l’économie d’une lecture de fichier ligne à ligne. Un sélecteur CSS assorti d’une expression régulière suffit à extraire l’identifiant de dossier. On obtient un fichier CSV, là encore facile à croiser car les résultats sont triés dans le même ordre qu’en entrée.
Peut-on tirer quelque chose de la base Sandre ? Le canal est un cours d’eau, effectivement présent dans la base, et son identifiant est déjà renseigné sur Wikidata. Mais seules quelques écluses sont identifiées dans la base des obstacles à l’écoulement et il n’y a pas de propriété pour cette base dans Wikidata. L’intérêt est plutôt limité, on n’approfondira pas le sujet.
Le fichier d’assertions est complet, on peut passer à Quick Statements. Problème : à ce jour, Quick Statements ne supporte ni les quantités ni les nombres décimaux : impossible d’indiquer que la distance qui sépare les écluses est exprimée en kilomètres ; il faudrait de plus convertir les distances en mètres pour retrouver des entiers, ce qui ne serait pas totalement respecter le degré de précision fourni par les sources. Patchons Quick Statements ! Quelques lignes de PHP et de Javascript plus tard, non dénuées de quelques bugs, Quick Statements supporte les quantités et les décimales.
Encore quelques manipulations de colonnes et le tableau Calc est prêt : allons-y !
Un contributeur avisé n’envoie pas toutes ses assertions d’un coup mais procède d’abord à quelques essais prudents. Un essai avec les premières lignes du tableau permet de remarquer l’oubli de guillemets autour des identifiants issus de Gertrude. Ce sera facile à corriger avec un deuxième lot de Quick Statements, à condition de retrouver les identifiants des éléments créés. Facile, il suffit de lister les écluses dans l’ordre. Facile ? Ce rang est la valeur d’un qualifieur, la requête SPARQL n’est pas si triviale.
Les écluses triées par leur rang depuis l’écluse de Saint-Félix à Nantes.
Une fois ces petits détails réglés, on peut créer les dernières assertions. On se rend compte — trop tard — qu’il subsiste un problème de traitement des nombres décimaux, malgré les précautions prises : une représentation du nombre en virgule flottante intervient quelque part dans la chaîne Quick Statements → Widar → API Wikidata et transforme, par exemple, « 363,7 » en « 363,69999999999998863131622783839702606201171875 ». Il faudra corriger manuellement.
La requête précédente permet de lister toutes les écluses créées et de réintégrer leur identifiant dans le tableau, pour passer à la deuxième phase : les lier entre elles avec les qualifieurs P155 (« précédé par ») et P156 (« suivi par ») sur la propriété P795 (« situé le long de ») déjà renseignée.
Et voilà ! Chaque écluse du canal apparaît sur la carte et un bot pourrait naviguer d’un bout à l’autre en suivant la propriété P795. Mais on pourrait aller encore plus loin : la base Gertrude comporte des informations qu’on a laissées de côté : année de construction, ingénieurs du génie civil… toutes choses qu’un crawler un peu raffiné pourrait extraire. Les écluses noyées de Guerlédan mériteraient aussi qu’on mentionne qu’elles ne sont plus en service. Certaines écluses disposent aussi d’une catégorie Commons et de photos, mais la couverture est loin d’être exhaustive : il y a là quelques sorties photos à organiser.
La Tranchée de Glome (vue prise du côté de Nantes) — Duclos, J., photographe installé à Quimper et à Lorient — Photographie provenant de l’Ecole nationale des Ponts et Chaussées.
Toutes les écluses du canal sur une carte. En rouge : pas de photo !
Et voici le code source du crawler et les requêtes citées dans ce billet :
Odonymie rennaise
Le fichier FANTOIR des voies et lieux-dits de janvier 2017 a été récemment publié sur data.gouv.fr. De valeureux camarades se sont amusés à importer le code Fantoir des rues rennaises déjà présentes dans Wikidata. Même si toutes les voies de communication ne sont pas là, et les lieux-dits non plus, on peut déjà commencer à jouer. Commençons par les compter :
À l’heure où j’écris ces lignes, on trouve un peu plus de 900 rues et une poignées de quais, places, boulevards et squares. Presque toutes les rues ont un code Fantoir, les autres voies restent à compléter. Avec un comptage grossier, Fantoir dénombre un peu moins de 2 000 voies à Rennes, il reste donc du travail pour être exhaustif.
La propriété Wikidata P138 permet d’indiquer en référence à quoi une entité est nommée. Ainsi, la rue Zénaïde Fleuriot est nommée en référence à la romancière bretonne Zénaïde Fleuriot. En référence à quoi nomme-t-on les rues rennaises ?
Cette première requête évalue les proportions relatives des natures des entités qui donnent leur nom aux voies de la ville. Premiers constats : la propriété P138 n’est pas renseignée pour un gros tiers des voies et les êtres humains forment la classe la plus importante pour les voies où elle est renseignée. Viennent ensuite les villes et les états, les lieux géographiques (montagnes et cours d’eau), les anciennes provinces et régions françaises et les bâtiments. Le goût du détail des wikidatiens ne permet pas d’avoir une vision en grandes masses : on trouve côte-à-côte des entités à la nature d’état membre de l’ONU, de l’OTAN ou du Conseil de l’Europe, d’état souverain, de pays sans accès à la mer, de nation constitutive… De même pour les villes, villes-districts, grandes villes, capitales, communes, communes déléguées, villes sous-provinciales…
Notons que parmi les noms de voies sans référence, on trouve de nombreux lieux-dits rennais, encore absents de Wikidata mais présents dans le Fantoir.
Qui sont les personnes qui donnent leur nom aux voies de la ville ? Wikidata est assez complet sur le genre et l’occupation des personnes, voyons ce que ça donne.
Aïe ! Les hommes, sans surprise, sont très majoritaires. Il serait très surprenant que le gros tiers de voies restant à renseigner change ce constat.
Et quelles sont les occupations de ces personnes ? Qui Rennes choisit-elle de mettre en avant ?
Qu’avons-nous là ? Des politiques, des artistes et des savants. Tout comme les batailles plus haut, les militaires ont le bon goût de se faire discrets : Rennes n’a pas la veine belliciste.
Pour finir, voici une dernière requête à l’usage de la commission d’odonymie : quelles pourraient être les candidates à donner leur nom aux voies de Rennes ? Faisons simple : il leur suffirait d’être nées, d’avoir vécu ou d’être décédées à Rennes — et de ne plus être de ce monde.
Alors, Rennes osera-t-elle donner le nom d’une fameuse tueuse en série à l’une de ses rues ?
Ce billet n’aurait pas existé sans le travail de la Non-cabale de l’Ouest et des contributeurs à Wikidata, Wikisource, Wikipédia et Wiki-Rennes Métropole : merci à tous ! Merci aussi à l’hôte de ces lieux pour ses nombreuses suggestions et adaptations. Merci enfin aux équipes de Wikimedia Deutschland pour leur célérité à intégrer ma pull request qui corrigeait un petit bug de rendu dans les treemaps du Query Service.
Les notices sur les rues de Rennes de Lucien Decombe et leur extension contemporaine sur le wiki de la ville ont été d’un précieux secours.
A tool to estimate gender gap on Wikidata and Wikipedia
Context
Last November, for the 10th anniversary of Wiki Brest, Florence Devouard gave a talk about wikis (« Les wikis et vous ? », “Wikis and you”). She of course mentioned gender gap on Wikipedia, that occurs on many levels: biographies on Wikipedia are mainly about men, Wikipedia contributors are mainly men (audience that day could not deny that with the row of Wikimedians composed exclusively of men), etc.
One difficulty is to measure those gaps and how they differ from gender gap in real world. As I contribute about French politicians on Wikidata, I had one example in mind where the gap on Wikipedia biographies was only a reflect of the real world: in French National Assembly, there are only 27 % of women and the gap has been slowly decreasing for only 20 years. But I had no clue for other professions or countries.
Wikidata is the central repository of Wikimedia projects for structured data. As of March 2017, it holds data about 25 million concepts (called items), including more than 3 million notable people. An idea was to use this huge content to have more statistics on gender gap. Three weeks ago, I started to work on a reporting tool to automatically compute data from Wikidata and display statistics about gender gap: Gender Gap on Wikidata. The tool is available since March 8th 2017.
Features
The tool provides indicators about:
- Humans in Wikidata,
- Humans in Wikidata linked to at least one wikipedia (it can be seen as the number of notable people, even though each wikipedia has its own notability rules),
- Links to wikipedias for humans in Wikidata (it can be seen as the number of biographies in wikipedias).
For each set, it displays data for three subsets: women, men and others. Others subset gathers humans whose gender is known but neither female nor male.
Each set can be aggregated by year of birth, country of citizenship and occupation, with all possible combinations.
Aggregated data can be downloaded as a CSV file from the About page.
An important point is that not all humans in Wikidata are used to produce these statistics. To sum up, only humans with gender, year of birth and country of citizenship are used. This is explained in the following section.
Methodology
Dump
Each week, Wikidata provides a full copy of its database (called dump). In the following sections, figures were made using the dump of March 6th 2017.
In a dump, data is structured in statements. A statement is a triplet item–property–value. An item can have several values for a given property. For example, a person can have more than one occupation. Another example is when sources disagree about an information.
Each statement has a rank: preferred, normal, or deprecated. The tool ignores statements with deprecated rank. When it looks for a single value of a property, it is done by looking first in the subset of statements with preferred rank for this property. If and only if this subset is empty, it looks in the subset of statements with normal rank.
Human
Rule 0: A human is an item with a single value of property instance of, equal to human.
There are 3,400,591 humans.
Gender
The tool aggregates humans by gender, in 3 subsets (females, males, and others). Each value which differs from female and male is considered as other.
Rule 1: Each human has a single value of property gender.
This has two effects:
- Humans with no gender (227,426) are discarded.
- Humans with more than one gender are discarded. It makes analysis easier (no subset shares element with another subset). It filters only 207 people, which is light compared to the set of humans with exactly one gender (3,172,958), but significant compared to the final size of others subset (156). Maybe those humans should be considered as others, instead of removing them?
Property values are not checked, meaning that some may be false. In the dump, gender values are:
| Value | Count |
|---|---|
| male | 2,645,020 |
| female | 527,692 |
| transgender female | 153 |
| transgender male | 45 |
| intersex | 24 |
| genderqueer | 15 |
| male organism | 4 |
| female organism | 2 |
| Hombre | 1 |
| kathoey | 1 |
| transgender | 1 |
There are only 7 obvious errors:
- Female organism and male organism are values reserved for non-human organisms,
- Hombre is an American magazine, which name means man in Spanish.
Other errors can still exist (for example, a man with female for its gender).
Year of birth
The tool aggregates humans by year of birth.
Rule 2a: Each human has a single value for its year of birth.
There are 2,635,804 humans with a single value for the property date of birth. When there are more than one value for it, the tool checks that all the values have at least yearly precision and that the year is the same for all the values. It allows to keep 9,204 extra humans. There are 2,617,321 humans with a year of birth.
Rule 2b: Year of birth can not be before 1600.
This is done to avoid working on nearly-empty sets. It filters 60,730 people.
Rule 2c: Year of birth can not be after the year of the dump.
This is done to remove wrong data (we don’t have time travel yet). It filters 1 person.
The tool assumes that all dates are represented in Gregorian and Julian calendars, without normalizing them.
Country of citizenship
The tool aggregates humans by country of citizenship.
Rule 3a: Each human has a single value for property country of citizenship.
Like rule 1, rule 3 has two effects:
- Humans with no country of citizenship (1,331,299) are discarded.
- Humans with more than one country of citizenship are discarded. It filters 77,156 people.
There are 1,992,136 humans with one country of citizenship.
Rule 3b: Humans from countries with less than 100 people are removed.
This rules is applied after all the other rules. It removes only 4,179 humans, including a lot of garbage (like values French instead of France).
Selection
Only humans meeting all preceding rules are kept. The goal is to remove people with few data (and therefore likely of poor quality). In the table below, you can see cardinalities of humans sets respecting each group of rules:
| Set | Cardinality | Ratio |
|---|---|---|
| Rule 0 (human) | 3,400,591 | 100.0 % |
| Rule 1 (gender) | 3,172,958 | 93.3 % |
| Rules 2a, 2b and 2c (year of birth) | 2,556,591 | 75.2 % |
| Rule 3a (country of citizenship) | 1,992,136 | 58.6 % |
| Rules 0 to 3b | 1,730,427 | 50.9 % |
In the end, 1,730,427 humans are kept, with 208 distinct countries of citizenship.
Occupations
The tool aggregates humans by occupation. All occupations with preferred and normal ranks are kept. A same person can therefore have 0 to several occupations.
Rules 4: Occupations with less than 100 people are removed.
This rule removes 4,577 distinct occupations. In the end, there are 638 distinct occupations. 2,154,559 occupations are associated to 1,730,427 people (1.25 occupations per capita). There are 240,723 people without occupation.
Analysis
The following is not an analysis of the data provided by the tool, but some elements that you should take into account before using it.
Gender gap over time
For humans born before 1850, gender gap is roughly stable, as women represent around 5 % of the population selected on Wikidata. For humans born after 1850, gender gap is regularly reducing, but still exists and remains important. You can see below the relative gender gap by decade of birth, from 1800 to 1999 (women are in orange on the left, men in green on the right):
Country of citizenship
You can’t directly compare figures from two countries as they don’t have the same history. For example, Russian Empire existed from 1721 to 1917, Soviet Union from 1922 to 1991 and Russia since 1990. As we saw before, gender gap is reducing over time after 1850, so you can’t directly compare those countries. You can see below the number of people born by decade, for those three countries of citizenship, in the selected set:
Occupation
The tool does not take into account inheritance offered by property subclass of. For example, someone with screenwriter occupation will not appear in the subset of writer if this second occupation is not explicitly stated.
Position held
I made a quick test in order to use position held property in the same way as occupation. It seemed less interesting as it is essentially positions as member of parliaments in North-American and European countries. A dedicated work for this subject should be done (I started for France).
Let’s play!
As you can see, there are a lot of tracks to improve or analyze data on gender gap on Wikidata and Wikipedia. If you don’t know where to start, a simple way to improve data on humans in Wikidata is to play Wikidata games, with dedicated games for each property: Person, Gender, Date (of birth), Country of citizenship, and Occupation.
Technical overview
The tool is a small project, that you can divide in three parts:
- A Java project. It uses Wikidata Toolkit to extract data from Wikidata weekly JSON dumps. It produces two CSV files with data about people and their occupations.
- A PHP script (mainly SQL and SPARQL queries). It loads data into a relational database and aggregates it. It also fetches countries and occupations labels from Wikidata Query Service.
- A website (accessible here) to display aggregated data.
Source code is available on GitHub, under AGPLv3 license.
Les visages du commissaire Maigret
Ce soir, France 3 diffuse une nouvelle adaptation télévisée du commissaire Maigret, personnage principal de nombreux romans et nouvelles de l’écrivain Georges Simenon. Si ce soir c’est Rowan Atkinson qui jouera le rôle du commissaire, le journal Le Parisien affirme que Maigret a connu 35 visages différents sur grand et petit écrans. Voici une requête SPARQL qui permet d’en retrouver quelques-uns, grâce à Wikidata et Wikimedia Commons :
#defaultView:ImageGrid
SELECT DISTINCT ?actor ?actorLabel ?image
WHERE {
?work p:P161 ?a .
?a ps:P161 ?actor .
?a pq:P453 wd:Q830561 .
OPTIONAL { ?actor wdt:P18 ?image . }
SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}
À noter qu’il manque quelques acteurs notables, comme Bruno Cremer, dont il ne semble pas exister de photo sous licence libre.
Wikidata fête ses 4 ans
Ce billet, par Envel Le Hir, Davy Defaud, M5oul et ZeroHeure, a été initialement publié le 29 octobre 2016 sur DLFP sous licence CC BY-SA, dans une version légèrement différente.
Wikidata est une base de connaissances, structurée, multilingue et libre. C’est un projet frère de Wikipédia, développé par Wikimedia Deutschland et hébergé par la Wikimedia Foundation. Le but est de centraliser les connaissances sourcées et utiles aux projets Wikimedia. Le projet fête son quatrième anniversaire le 29 octobre 2016.
Des rencontres ont lieu un peu partout dans le monde jusqu’au 5 novembre pour fêter cet évènement.
Une base reposant sur des standards ouverts
Wikidata utilise le logiciel libre MediaWiki, avec l’extension Wikibase pour gérer ses données. Toutefois, pour tirer pleinement parti des données liées, les données sont répliquées dans un triplestore Blazegraph, dont les caractéristiques sont développées ci‐dessous.
RDF
Les données sont stockées au format RDF, développé par le W3C. Chaque information a la forme d’un triplet élément-propriété-valeur. Par exemple, l’élément noyau Linux a une propriété créateur dont la valeur est Linus Torvalds. Wikidata étant une base multilingue, chaque élément et chaque propriété possèdent un identifiant unique (Q14579 pour le noyau Linux) et des libellés dans chaque langue (noyau Linux en français, Linux kernel en anglais, etc.). La valeur d’un triplet peut être une donnée simple (une date, un nombre, etc.) ou un autre élément (dans l’exemple précédent, Linus Torvalds est l’élément Q34253), ce qui permet de lier les éléments entre eux.
SPARQL
Le langage de requêtes SPARQL, également développé par le W3C, permet d’interroger les bases RDF et donc Wikidata. Une interface, avec auto‐complétion et de nombreux exemples, est disponible. La requête suivante liste les logiciels libres les plus récents :
SELECT ?item ?itemLabel ?date
WHERE {
?item wdt:P31 wd:Q341 .
?item wdt:P571 ?date .
SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" }
}
ORDER BY DESC(?date)
LIMIT 30
Le langage SPARQL ressemble au langage SQL des bases relationnelles. La clause SELECT permet de sélectionner les champs à retourner : ici, l’identifiant d’un élément, son libellé et une date. La clause WHERE permet de filtrer les éléments retournés. Ici, on ne retourne que les éléments dont la propriété nature de l’élément (P31) est un logiciel libre (Q341) et qui ont une propriété date de création (P571) renseignée. Le service wikibase:label permet de récupérer automatiquement les libellés des éléments, d’abord en français, puis en anglais s’ils n’existent pas en français. La clause ORDER BY permet de trier les résultats, ici par date de création. Enfin, la clause LIMIT permet de limiter le nombre de résultats, ici à 10.
Des données dans le domaine public
Les données de Wikidata sont sous licence Creative Commons CC0, ce qui fait qu’elles sont réutilisables par tous sans contrainte. Par exemple, le projet libre inventaire.io, reposant notamment sur Wikidata, permet de lister les livres de sa bibliothèque et de garder une trace des emprunts.
Un projet en développement
Wikidata est un projet jeune et encore largement en développement. Deux chantiers en cours sont l’intégration du Wiktionnaire (un dictionnaire collaboratif) et de Wikimedia Commons (une banque de fichiers libres) dans Wikidata, pour tirer parti des données structurées. L’intérêt est, par exemple, d’avoir des métadonnées fiables et avec une structure commune pour tous les fichiers de Wikimedia Commons, ce qui n’est pas le cas actuellement.
Se former à Wikidata
Ce billet, par Envel Le Hir, Trizek, Nicolas Vigneron et Wikimédia France, a été initialement publié le 11 octobre 2016 sur le blog de Wikimédia France sous licence CC BY-SA, dans une version légèrement différente.
Wikidata est une base de connaissances. C’est un projet frère de Wikipédia, développé par Wikimedia Deutschland et hébergé par la Wikimedia Foundation. Wikidata stocke des informations structurées, sourcées et réutilisables par l’ensemble des projets Wikimedia. Lorsqu’une information évolue, elle peut être reportée automatiquement sur l’ensemble des projets Wikimedia. Par exemple, lors de la mise à jour annuelle de la population d’une commune, l’information peut être mise à jour dans Wikidata et reportée automatiquement sur l’ensemble des wikipédias utilisant cette information.
Autre exemple de l’avantage de ce dépôt centralisé : Wikidata stocke les liens interwikis des projets Wikimedia. Auparavant, lorsque l’on changeait le nom d’une page Wikipédia, il était nécessaire de reporter ce changement manuellement sur toutes les autres versions linguistiques de Wikipédia et tous les projets Wikimedia. Aujourd’hui, le changement se fait à un seul endroit, avec une interface adaptée.
La traduction des articles est également simplifiée : un lien dans une langue est facilement identifiable dans une autre langue. Quand vous traduisez un article avec l’outil de traduction, vous gagnez en fluidité. Quand vous modifiez un article pour y insérer un lien vers un autre article, vous avez aujourd’hui une courte description illustrée issue de Wikidata vous permettant de faire le meilleur choix.
Wikidata est un projet encore jeune : il fêtera ses 4 ans en octobre prochain. Toutefois, si l’on regarde le nombre croissant d’ateliers Wikidata organisés chaque année dans la francophonie, l’intérêt pour ce projet se développe régulièrement. Le besoin de formation est donc réel, comme l’a montré l’atelier de formation à Wikidata lors de la Wikiconvention francophone et la série d’ateliers Wikidata organisés depuis l’automne dernier à Paris et cet été à Rennes. Tout d’abord, ces ateliers sont un succès certain — une trentaine de participants lors de la Wikiconvention (dont de nombreux nouveaux contributeurs), une quarantaine lors de l’atelier organisé à l’université Paris-Sud, une douzaine au total lors des ateliers rennais — et durable — les trois quarts des participants aux ateliers rennais ont pris part à au moins deux ateliers. Ensuite, ils permettent aux contributeurs, expérimentés ou non sur d’autres projets Wikimedia, d’appréhender Wikidata et d’être autonomes dans son utilisation. Enfin, ils sont un vecteur d’émulation, comme en témoignent les outils de contribution et de visualisation créés lors de ces ateliers.
Si vous n’avez pas eu l’occasion de participer à un de ces ateliers, il est encore temps d’apprendre ! Par exemple, vous pouvez :
- découvrir l’introduction à Wikidata et les pages d’aide du projet ;
- poser vos questions sur le bistro de Wikidata ou la liste de discussions francophone ;
- participer à un des ateliers organisés tous les 3e vendredi du mois à Paris ;
- vous rapprocher de contributeurs expérimentés dans votre région ou même organiser un atelier Wikidata !
Wikidata étant un projet transverse à tous les projets Wikimedia, vous pouvez également trouver de l’aide sur chaque projet, par exemple sur le projet Wikidata sur Wikipédia ou dans la page d’aide sur Wikisource.
Google va fermer Freebase
Ce billet a été initialement publié le 22 décembre 2014 sur DLFP sous licence CC BY-SA, dans une version légèrement différente.
Freebase est un projet de base de connaissances libre. Il est public depuis 2007 et a été racheté par Google en 2010. Les données sont disponibles sous licence CC BY 2.5, ce qui en permet notamment un usage commercial. Google a annoncé le 16 décembre dernier la fermeture prochaine du projet.
Calendrier
Le 31 mars 2015, le projet passera en lecture seule : il ne sera plus possible de modifier la base, que ce soit via le site web ou les API. Le 30 juin 2015, le site web et les API du projet seront fermés. Le dernier dump du projet devrait rester disponible. Toutefois, les personnes intéressées par ces données sont invitées à se diriger vers Wikidata.
L’avenir : Wikidata
Wikidata est un projet équivalent, qui a fêté ses deux ans il y a peu : il a été démarré en octobre 2012, par Wikimedia. Son contenu est disponible sous licence CC0.
En même temps que la fermeture de Freebase, Google a annoncé vouloir fournir d’ici fin mars 2015 des outils pour aider à transférer les données de Freebase vers Wikidata. Un sous-projet de Wikidata a été créé pour gérer cette migration : WikiProject Freebase.