cdn.media.ccc.de/.../wikidatacon2019-6-eng-GLAM_panel_hd.mp4

Panel GLAM

GLAM : galeries d'art,
bibliothèques, archives et musées

Bonjour à tous.

Bienvenue à notre panel GLAM.

Avant de commencer,
j'ai deux annonces à vous faire.

La première : n'hésitez pas à utiliser
notre Etherpad pour prendre des notes.

La deuxième annonce s'adresse
à ceux qui nous regardent de chez eux,

ou bien où qu'ils se trouvent :

si vous avez des questions,

vous pouvez également
les noter sur l'Etherpad,

et nos bonnes âmes de la salle
pourront suivre vos interrogations.

Nous avons donc décidé
pour le panel de cette année,

après avoir vu toutes les contributions,

que nous nous concentrerions
sur le rôle de Wikidata

dans les écosystèmes de données

qui vont au-delà
des projets Wikimedia en cours,

ce qui est également en phase

avec la nouvelle statégie
de la fondation Wikimedia.

Et nous sommes accompagnés,
aujourd'hui, de quatre membres du panel.

Trois plus un.

Je vais donc vous demander
de monter sur scène

afin que je puisse
vous présenter à l'assemblée.

(bruits de pas)

Nous avons donc Susanna Ånäs.

Susanna milite depuis très longtemps
pour la liberté du savoir,

est engagée dans de nombreux WikiProjects,

et aujourd'hui,
elle nous fera le compte-rendu

d'un projet en coopération

avec la Bibliothèque
nationale finlandaise.

Ensuite, j'ai à côté de moi
Mike Dickison,

qui interviendra en deuxième.

Il est conservateur de musée
et est originaire de Nouvelle-Zélande.

Il est également zoologue
et rédacteur en chef de Wikipédia.

Il a été le premier Wikipédien
néo-zélandais en résidence

en 2018 et 2019,

et il nous parlera
de son expérience dans ce rôle,

et ce que cela a fait de travailler
pour Wikidata dans ce contexte.

Nous avons ensuite Joachim Neubert

du centre d'information de Leibniz
pour l'économie à Kiel et Hambourg.

Il travaille à rendre

les plus grandes archives publiques
de la presse au monde

plus accessible au public,

et il utilise Wikidata à cette fin.

J'interviendrai en dernier.

Je m'appelle Beat Estermann.

Je travaille pour l'Université de Berne
des sciences appliquées, en Suisse.

Je promeus depuis très longtemps
l'OpenGLAM en Suisse et en Autriche,

et je ferai aujourd'hui
un compte-rendu de mes activités

en relation avec le mandat

de l'Association canadienne
des organismes artistiques,

à savoir les arts du spectacle,

pas nécessairement
par le biais de Wikidata,

mais vous verrez qu'il commence
à jouer un rôle dans ce domaine.

À présent, la plupart d'entre nous
allons prendre place ici,

et je vais donner la parole à Susanna.

(Susanna) Bien.

Bonjour, je m'appelle Susana Ånäs,

et je travaille à temps partiel
pour Wikimedia Finlande

en tant que coordinatrice du GLAM,

et je suis également consultante
dans le domaine des savoirs libres,

Alors, ça peut être
un discours [inaudible],

j'ai donc participé à la réalisation

d'un groupe...

d'un groupe de données géographiques du...

je n'ai pas vérifié le terme en anglais,

mais, c'était à l'initiative
du gouvernement royal finlandais

au nom du patrimoine culturel.

Il s'agit donc de noms de lieux

et de la manière dont ils sont représentés

dans différents référentiels
du secteur des GLAM en Finlande,

comment les GLAM essaient
de rassembler ces différentes sources,

et comment les lieux sont décrits
par le biais de la modélisation

dans Wikidata et ailleurs.

On retrouve ici les trois sources
principales du projet YSO Places

faisant partie de l'ontologie générale.

AHAA désigne les archives finlandaises,

Melinda, les bibliothèques finlandaises,

et KOOKOS, les musées finlandais.

Il existe donc trois systèmes
de gestion de contenu

réunis dans le projet YSO Places.

Des échanges entre Wikidata
sont déjà en cours,

ainsi qu'un projet de toponymie
pour le Service National Cartographique.

Et puis, il existe un troisième projet,
les archives de toponymie finlandaise,

qui n'y contribue pas encore,

mais c'est en prévision.

L'un des points clés de la modélisation
dans cette problématique

est que trois types d'éléments
de la toponymie des lieux

sont représentés dans ce projet,

l'un d'eux étant le lieu,
son emplacement géographique,

un autre étant le nom du lieu,

le dernier étant les sources,
c'est-à-dire les documents

d'où ces deux premiers
éléments sont tirés,

ou encore, étayés.

Le projet YSO Places,

ici, en haut à droite,
on retrouve les mêmes diagrammes

ce projet YSO se concentre
principalement sur les lieux.

Ce projet est sous la houlette
de la Bibliothèque nationale de Finlande,

et du projet Finto.

Il compte à présent plus de 7 000 lieux
en finnois et en suédois,

et plus de 3 000 en anglais,
sous licence CC0.

On retrouve ici le service Finto.

Et j'ai choisi pour lieu Sevettijärvi,

qui fait désormais partie
de notre projet linguistique

aux côtés des Skolt Sámi..

Sevettijärvi est un lieu situé
dans l'extrême nord de la Finlande,

habité par les Skolt Sámi.

On peut donc voir ici
le lieu qui appartient à...

enfin... voilà les données
concernant cet endroit.

On peut voir qu'il est
relié à un Wikidata,

et retrouver les données
du Service National Cartopgraphique.

On voit ici plus en détail ces éléments.

Les données sont également hiérarchisées

dans ce référentiel.

En réalité, ce lieu n'est pas affiché ici,

mais on le retrouve
sous cette municipalité,

ainsi que sa région,

et la Finlande en tant que pays,
et les pays nordiques,

comme région frontalière.

On peut voir ici
que beaucoup de ces données

ont été associées
avec Wikidata auparavant,

par le biais d'un Mix'n'Match,
et il en reste encore à associer.

Cependant, la quantité d'entrées
n'est pas si élevée :

il y a un peu moins de 5 000.

Il existe également cet autre référentiel

du projet de plateforme
géospatial finlandaise,

les Place Names Cards.

Ce sont tous les noms de lieux
qui figurent sur les cartes finlandaises.

Les données qui y sont reliées,
sont sous licence CC BY 4.0.

Ce sont 800 000 étiquettes de cartes
en finnois, suédois,

et dans les trois langues sámi
que l'on parle en Finlande.

Et il existe deux types d'entités :

certaines sont des lieux,
et les autres des noms de lieux.

Et elles ont toutes deux
leur adresse PURL.

Par exemple, ici, ce même Sevettijärvi,
apparaît en finnois, à la première ligne,

puis dans les trois langues sámi,

ainsi que ses données géographiques,
et davantage d'informations

comme le type de lieu, et ainsi de suite.

Voici le tableau pour cette toponymie
ayant son propre URI.

Désolé, apparemment,
ça n'est pas traduit en anglais...

Il semblerait que le multilinguisme
ne couvre pas l'ensemble du projet.

Nous arrivons ensuite
à l'archivage des toponymes finlandais.

Il s'agit d'un projet mené par
l'Institut de langues de Finlande,

qui ne traite ni des lieux,
ni de leur toponymes,

mais des sources de ces derniers.

Il s'agit donc de trois millions
de notes sur le terrain des noms de lieux,

et il s'agit d'un projet Wikibase.

Ces données sont dans une Wikibase,

principalement en finnois,
certaines en suédois,

dans quantité de langues sámi d'intérêt,

et elles sont sous licence CC BY 4.0,

ce qui représente également un défi
du point de vue Wikidata,

mais s'il existait
une Wikibase locale finlandaise,

nous serions peut-être en mesure
de les travailler en premier.

Voici donc une capture d'écran

montrant qu'il y a des informations
concernant le lieu, les cartes...

et des anciennes cartes
que les collectionneurs utilisaient,

ainsi que des cartes générées
sur la base des données récoltées.

Voici donc une de ces cartes

générée sur base des données.

Nous avons également ce projet

mené par le Laboratoire des humanités
numériques d'Helsinki

et le groupe de recherche en sémantique
informatique de l'université d'Aalto,

en partenariat avec l'Institut
de langues de Finlande,

le projet Names Sampo.

Et il s'agit d'une interface
de recherche agrégée

selon plusieurs sources de toponymie.

Ici, on peut voir nombre de sources
à gauche de l'écran,

et on peut générer
différentes représentations

sur la base de ces données.

Et... oui, c'est ça.

J'ai donc évoqué cette idée
de modélisation d'une Wikibase locale

que nous pourrions réaliser
avec ces données.

Mais lorsque nous évoquons
ces questions de modélisation,

ou comment modéliser,

il y existe différentes
manières de procéder.

Et donc...

Oui.

Ce qu'il y a de bien,

c'est que cela pourrait
servir les langues minoritaires

avec très peu d'efforts.

Très bien, nous avons
donc ici deux options :

le modèle SAPO, c'est-à-dire l'ontologie
spatio-temporelle finlandaise,

et le modèle Wikidata.

On peut voir ici que les éléments
Wikidata ont tendance à...

eh bien, dans l'idéal, rester identiques
avec des propriétés changeantes,

alors que, dans le modèle SAPO,
ces éléments deviennent nouveaux

lorsqu'il y a un changement,
comme un changement de zone ou de nom.

Revenons à ce schéma divisé

entre ces trois différentes dimensions.

Ainsi, devrions-nous faire
de ces toponymes

des entités ou des propriétés ?

Wikidata utilise des propriétés,

tandis que le Service National
Cartopgraphique parle d'entités.

Ou devrions-nous en faire des lexèmes ?

Wikidata a choisi de travailler
avec des propriétés textuelles

pour les toponymes plutôt que des lexèmes.

Je suis désolée, c'est l'inverse.

Donc, les noms sont...

des propriétés, pas des lexèmes.

Bien.

Je dirais que la faiblesse de la Wikibase

est peut-être l'absence de
données topographiques

comme dans la configuration de base,

il faudrait donc rendre
le système plus performant

pour pouvoir utiliser
les topographies locales.

Et une fédération
serait vraiment la bienvenue

pour pouvoir profiter du corpus Wikidata.

Donc, je crois bien être arrivée
à la fin de la présentation !

Merci !

(applaudissements)

(bruits de pas)

Bien.

(s'exprimant en maori)

(Mike) Bienvenue à tous.

Je m'appelle Mike Dickison.

Et durant un an,

j'ai été un wikipédien
néo-zélandais en résidence.

Vous vous demandez peut-être
ce qu'est un wikipédien en résidence,

parce que si vous cherchez,
vous ne trouverez rien à ce sujet,

comme on peut le voir ici.

C'est un terme que j'ai inventé
dans la proposition de subvention,

ce que la fondation
a semblé beaucoup apprécier.

Et donc, nous avons gardé ce terme.

Durant un an, je suis passé par
35 institutions différentes,

les résidences qui, pour la plupart,
organisaient des sessions de formation,

des événements publics,
et essayaient de développer

une stratégie Wikimedia,
chacune de leur côté.

Ça a été une expérience très intéressante,

où j'ai découvert un large éventail
de projets et de personnes,

et j'aimerais passer en revue
quelques-uns des différents projets

qui portaient sur Wikidata,

d'une manière intéressante,
ou tout au moins éclairante,

dont les gens pourront débattre.

Le projet était axé sur Wikipedia...

Le projet était initialement
estampillé Wikipédia

simplement parce que les gens
étaient familiers de Wikipedia,

et nous avons donc organisé
de multiples événements différents

lors d'edit-a-thons traditionnels
sur les écarts entre les sexes...

[dont beaucoup ont été très fructueux],

ainsi qu'une série recrutement
de rédacteurs en chef tout aussi réussie.

Nous avons effectué des téléchargements
en masse vers les Commons.

En l'occurrence ici, une collection
de plus de 1 000 œuvres d'art originales

de l'illustrateur
entomologiste, Des Helmore,

qui se trouvait sur un disque dur,

qui correspondait
à une décennie de recherche,

et nous avons pu obtenir
l'autorisation de les publier

le tout sous licence CC BY.

Donc, de petites victoires que nous avons
pu montrer aux gens de là-bas.

Tout le monde peut comprendre
des images de coléoptères.

Tout le monde peut comprendre

les ateliers consacrés à la réduction
de l'écart entre les sexes.

Mais Wikidata est beaucoup plus
difficile à vendre

aux personnes du secteur GLAM,

ou toute personne extérieure
de notre mouvement.

J'ai donc commencé à réaliser que Wikidata

allait devenir une voie
de plus en plus importante

dans ces projets
de wikipédiens en résidence.

Ainsi, au fur et à mesure
que nous avancions,

cette composante a pris de plus en plus
d'importance dans mon travail,

et j'ai commencé à essayer d'en apprendre
plus sur Wikidata moi-même,

parce que je commençais
à en comprendre l'importance.

Donc, voici un projet...

le kakapo est un perroquet grimpeur
endémique de Nouvelle-Zélande.

Nous avons travaillé en partenariat
avec le Ministère de la conservation,

dont le travail est de sauver
cette espèce de l'extinction,

et l'idée était :

« Et si nous référencions
chaque kakapo dans Wikidata ? »

Cela peut sembler risible,

mais c'est en fait
un projet parfaitement réalisable.

Quelques-uns d'entre eux y sont déjà.

Un élément clé à noter ici
est qu'il n'y a très peu de kakapos.

C'est donc une tâche gérable.

Il y en existait 148 quand j'ai commencé,
un est mort depuis,

et la dernière saison
de reproduction a été bonne

puisqu'on en dénombre 213 à présent.

C'est formidable car on n'avait pas
atteint ce nombre depuis plus de 50 ans.

Ça a été une grosse affaire,

ça faisait les manchettes
tous les jours en Nouvelle-Zélande.

Et... oui ?

(intervenant·e 1) Même le New York Times !

(Mike) Vraiment ? Merveilleux.

Oui, ça a eu une ampleur nationale,
tout le monde aime ces oiseaux.

Mais ce qui les rend intéressants,

c'est que, contrairement aux espèces
qui sont plus peuplées,

chaque kakapo a un nom
et un numéro d'identification propre,

et on dispose souvent
de données biographiques complètes

sur le lieu et la date de leur naissance,

où ils ont été couvés,
qui étaient le père et la mère,

quand ils sont morts, s'ils sont morts.

Il existe donc une base de données
au Ministère de la conservation

qui répertorie toutes ces informations.

Et l'un des plus célèbres kakapos,
bien entendu, est Sirocco,

qui, comme vous pouvez le voir,
est nommé d'après le vent.

Sirocco a un compte Twitter,

avec lequel Wikidata
rencontrait quelques problèmes,

parce que, apparemment,

ils ne peuvent tout simplement
pas avoir de compte Twitter, bref.

Il a même fait la couverture
d'un album, et cetera.

Il y a donc eu de multiples
propriétés à cela,

à probablement
l'un des plus célèbres kakapo.

J'ai donc proposé
au Ministère de la conservation :

« Pourquoi n'essayons-nous pas
de faire cela avec chacun d'entre eux ? »

Alors, il leur a fallu réfléchir
à combien des données biographiques

pourraient être rendues publiques,

et ils ont présenté une liste.

Et maintenant nous en avons,
je crois, 212 ou 210...

je crois qu'un couple est mort...

kakapo vivants qui sont
à présent tous candidats.

Et ils ne reçoivent un nom
que lorsqu'ils se couvrent de plumes,

un code leur donné tant qu'il sont bébés.

Donc, une fois la récolte
de données complète,

nous allons créer un Wikidata complet...

l'espèce entière sera
référencée dans Wikidata.

Mais on doit arriver
à une propriété pour DOC ID...

En fait, j'aimerais évoquer
ce sujet avec vous :

devrions-nous utiliser
une identification très spécifique

ou devrions-nous trouver
une identité qui fonctionnerait

pour tous les oiseaux, plantes ou animaux
sujets de projets scientifique ?

C'est une bonne question.

Le deuxième projet concernait
la galerie d'art de Christchurch.

Il y existe très peu de peintures
de Colin MacCahon,

c'est l'un des plus célèbres
artistes de l'existence.

Voici un dessin qu'il a fait
pour le New Zealand School Journal,

financé par le gouvernement de l'époque.

Il fait donc partie
des archives de Nouvelle-Zélande

qui en détiennent les droits d'auteur.

C'est une situation très inhabituelle.

J'ai donc travaillé avec
la galerie d'art de Christchurch,

qui, avec la galerie d'art d'Auckland,

posséde un site appelé
« Trouvez des artistes néo-zélandais »,

dont la tâche est de garder
une trace des exploitations...

de chaque institution possédant
des propriétés d'artistes néo-zélandais,

soit une base données
d'environ 18 000 artistes,

dont la majorité est très peu documentée.

Nous avons donc procédé
à une sorte de Mix'n'Match standard.

Nous avons exporté
les données ayant au moins

une date de naissance ou de décès,
ou un lieu de naissance ou de mort.

Donc, le champs était large.

Or, même là, on en a extrait peu,

mais aujourd'hui,
nous en avons environ 1 500

reliés à des artistes connus
dans Wikidata,

ce qui est bien.

Mais ce qui les intéressait...

Voici leur site web,

qui ne fait que répertorier
les liens d'exploitation,

sachant qu'il créent manuellement
ces données biographiques

pour chaque artiste,

eh bien, l'acte d'exporter
et la mise en place d'un Mix'n'Match

a mis en lumière de nombreuses coquilles
et toute sorte d'erreurs,

qu'ils n'avaient pas remarquées.

Et ce n'est que qu'en traitant
les données dans un Excel

que les erreurs ressortent.

Et ils ont tout à coup réalisé
la valeur de Wikidata

quand je leur ai dit :

« Il vous suffit de pomper
ces informations de Wikidata ».

Ça leur a ouvert les yeux.

Je pense donc que c'est
un des arguments vendeurs.

Lorsque vous avez un site web
soigneusement créé à la main,

avec 18 000 entrées pleines d'erreurs,

et qu'on vous dit qu'il existe
un autre moyen,

que d'autres personnes peuvent vérifier
et corriger pour vous les informations,

c'est là que l'idée fait son chemin.

Et puis, je leur ai lancé l'idée
de « Wikidatafier » l'intégralité ce livre

sur l'histoire des artistes néo-zélandais
à Christchurch dans les années 30,

et de passer en revue chaque personne,
lien, lieu, exposition, et cetera.

C'est un projet de taille raisonnable,
et ils sont très enthousiastes.

Et troisièmement, je voulais vous montrer
le projet des rubriques Maori.

Waka est le nom maori
qui désigne un certain type de canoë,

un canoë de guerre.

Ainsi, à la Bibliothèque nationale
de la Nouvelle-Zélande,

il existe une entrée pour waka,

parce que la Bibliothèque nationale
a en réalité son propre dictionnaire

des rubriques Maori, en langue maori.

Donc, ici, il définit le waka
en maori et en anglais.

Mais il comporte également
beaucoup de termes maoris...

on peut voir ici, sur le côté,
une taurapa maorie typique.

La définition apparaît
d'abord en maori, puis en anglais.

Ce qu'on voit ici,
c'est un étambot sculpté.

En français, on appellerait
cela « étambot »,

mais on ne peut pas utiliser
le mot « étambot » pour une taurapa,

car on ne voit la taurapa

que sur certains types
de canoës de guerre.

Donc, il n'existe pas
d'équivalent en français.

Et j'ai soudain réalisé qu'il y avait ici

toute une ontologie
de termes spécifiques à la culture

qui ont été soigneusement
répertoriés et vérifiés

par la Bibliothèque nationale
avec les Maoris,

régulièrement mis à jour et suppléés
par des définitions et des descriptions,

en anglais et en maori.

Vraiment passionnant !

J'ai soudain pensé que nous pourrions
injecter tout cela dans Wikidata,

en maori d'abord,

puis traduits en anglais,
selon les besoins,

ça change un peu, n'est-ce pas ?

Voici la licence de droit d'auteur.

Et malheureusement, elle en empêche
l'exploitation commerciale.

Je dois reprendre les échanges avec eux :
pourquoi ont-ils choisi cette license ?

Peut-être parce qu'ils ont
[négocié] avec les Maoris,

qui ont accepté la diffusion
de ces informations

à condition qu'aucune de ces informations
ne soit utilisée à des fins commerciales.

C'est donc l'un des aspects
les plus frustrants de cette tâche :

se heurter à ce genre de restrictions.

Voici donc les trois projets
que je voulais mettre en avant

et ouvrir à la discussion.

Répertorier une espèce entière
dans Wikidata,

ce qu'il faut pour changer la vision
d'un conservateur de galerie d'art

sur la valeur des Wikidatas,

et que faire lorsque nous voyons
une ontologie entière

dans une autre langue qui,

malheureusement, est freinée
par une licence Creative Commons.

Je vous remercie.

(applaudissements)

Faire don de données à Wikidata :

première expérience
avec les archives de presse du 20e siècle.

(Joachim) Bonjour !
Je m'appelle Joachim Neubert.

Je travaille pour la ZBW,

c'est-à-dire le centre d'information
pour l'économie à Hambourg,

en tant que développeur
de logiciels scientifiques.

Et une de mes tâches l'année dernière

a été de préparer
un don de données à Wikidata.

Je voudrais donc faire un compte-rendu
de cette première expérience

de don de métadonnées
des archives de presse du 20e siècle.

À notre connaissance,

il s'agit des plus grandes archives
de presse publiques dans le monde.

Elles ont été collectées
entre 1908 et 2005,

et ont été obtenues de...

de plus de 1 500 journaux
et périodiques d'Allemagne,

mais aussi à l'échelle internationale.

Et elles couvrent tout ce qui pourrait
présenter un intérêt

pour Hambourg...

pour les hommes d'affaires de Hambourg

qui voudraient développer
leur commerce à travers le monde.

Comme vous pouvez le constater,

les contenus ont été découpés des journaux
et fixés sur des feuilles,

puis rassemblés dans des dossiers,

comme ici, on aperçoit
une partie d'une pièce d'archive,

et, de même, l'information
qui a été collectée des entreprises,

sur des sujets généraux, sur...

(bafouillements)

sur tout ce qui pourrait être intéressant.

Ces dossiers ont été scannés

jusqu'à l'année 1949 environ,

dans le cadre d'un projet financé
par la DFG de 2004 à 2007.

Par conséquent, jusqu'à présent,
ce sont 25 000 dossiers thématiques

de cette époque qui ont été scannés.

Les archives contiennent
un peu plus de 2 millions de pages,

et on peut les retrouver sur Internet

grâce à l'application développée
à l'époque par ZBW,

qui semble aujourd'hui un peu dépassée,
n'est pas très agréable à regarder,

mais plus qu'un programme,

c'est une application qui a été construite
avec une architecture Oracle,

elle a été construite sur ColdFusion,
elle fonctionne sur des serveurs Windows,

elle n'est donc pas
très viable à long terme.

Nous nous sommes demandés
si nous devions la migrer

vers une application de données
ouvertes liées plus sophistiquée,

ou si nous devions
prendre des mesures radicales

et mettre toutes ces données
en consultation libre.

Nous avons attribué
une licence CC0 à ces données

et nous déplaçons
actuellement certaines...

certaines couches -- principale
et primaire -- de découvertes...

vers des données ouvertes liées

là où...

cela a le plus de sens d'intégrer
des métadonnées dans Wikidata,

et afin de s'assurer que tous les dossiers

des collections sont reliés à Wikidata

pour qu'ils soient trouvables,

et que toutes les métadonnées
concernant ces dossiers

soient également transférées sur Wikidata.

Elles pourront donc y être utilisées,
et éventuellement enrichies,

des corrections pourront être
apportées à ces données.

Mais ZBW continuera de gérer l'application

et prendre en charge
le coût de stockage des images

auxquelles nous ne pouvons pas,
de quelque manière que ce soit,

attribuer de licence,

parce qu'elles restent la propriété
de leurs créateurs d'origine.

Mais nous veillerons
à ce qu'elles soient accessibles

à certains fichiers de métadonnées
via DFG Viewer

à l'avenir par les manifestes de l'IIIF.

Et nous allons mettre en place
quelques pages d'atterrissage statiques

qui serviront de point de données
de référence pour Wikidata,

tout en continuant
à mettre à disposition des données

qui ne s'intègrent pas bien dans Wikidata.

Pour nous, il s'agit de la migration
et du don de données à Wikidata

grâce notre infrastructure sur mesure
de points de terminaison SPARQL

de ces données,

et nous avons essentiellement
utilisé des requêtes fédérées

entre les points de terminaison
et le service de recherche Wikidata

pour créer des déclarations concordantes

au travers de [résultats] concaténés

dans les requêtes SPARQL elles-mêmes,
ou transformés par un script,

ce qui a également généré
des références pour ces déclarations

et on a ensuite intégré cela
aux QuickStatements du code

pour les utiliser en ligne.

Enrichissement Wikidata
en metadonnées PM20.

Voilà donc ce que nous obtenons.

Il ne s'agit pas uniquement
de données simples

comme les dates de naissance, mais...

oups, pardonnez-moi...

mais aussi de déclarations complexes

sur des éléments déjà existants,

comme par exemple,
si cette personne est un superviseur

membre du conseil
d'administration de ladite société

durant cette période,

et est référencé dans...

(hésitation)

utilisé dans un contexte scientifique.

Première étape du don de données ZBW :

L'archive personnelle - achevé

La première étape de ce don
de données a été achevée.

Les archives personnelles
sont entièrement reliées à Wikidata.

C'est aussi devenu
un outil d'informations.

Beaucoup d'éléments qui ont déjà été...

n'avaient pas de références externes.

Et nous avons généré
un peu plus de 6 000 déclarations,

maintenant sourcées
dans les métadonnées de cette archive.

Le prochain grand défi.

Eh bien, c'était la partie la plus facile,

parce que les personnes sont facilement
identifiables dans Wikidata.

Plus de 90 % d'entre-elles
y existaient déjà,

donc nous pouvions
relier les informations.

Nous avons créé une centaine
d'articles pour ces derniers,

et pour ceux qui manquaient.

Mais à présent,

nous travaillons
sur le reste des archives,

notamment sur les sujets
des archives,

ce qui signifie cartographier
un système historique

pour l'organisation du savoir
sur le monde entier,

matérialisée sous forme
de coupures de presse sur Wikidata.

Pour vous expliquer simplement,
les archives de pays et de sujets

sont organisées
selon une hiérarchie de pays

et d'autres entités géographiques,

et sont traduites en anglais,
ce qui rend les choses plus faciles.

Et la langue allemande
s'est profondément imbriquée...

profondément imbriquée
dans la classification des sujets

Et cette combinaison définit un...

un (s'exprime en allemand)

Donc, nous souhaitons à présent
les faire correspondre

à une structure de Wikidata,
et d'intégrer les données.

Merci !

Et je veux vous inviter

à participer à ce beau défi

en termes d'organisation des savoirs.

Il s'agit donc d'un projet Wiki
dont la progression est suivie,

et vous pouvez le suivre
ou y participer.

Voilà, merci beaucoup.

(applaudissements)

Amenons donc maintenant
les arts du spectacle dans Wikidata,

et donc dans le cloud lié,

en créant un écosystème de données
ouvertes liées pour les arts de la scène.

Et la question à laquelle
j'essaie de répondre,

et j'espère que vous m'y aiderez,

est : « Quelle place donne-t-on
à Wikidata, et cetera ? »

Mais permettez-moi de partager
d'abord mes expériences de cette année,

durant le premier semestre de l'année,

quand j'ai eu le plaisir
de travailler avec la CAPACOA,

qui est l'Association canadienne
des organismes artistiques,

à l'initiative d'un projet appelé
« Un avenir numérique lié ».

Pour que l'ensemble
des arts de la scène canadiens

adoptent les données ouvertes liées.

Ils ont lancé cette initiative
en partant de l'observation

qu'au cours des cinq dernières années,

la problématique principale
des arts du spectacle

était que les métadonnées n'étaient pas
disponibles en qualité suffisante

ni interconnectées,
ni même interopérables.

C'est pourquoi certaines représentations,

ou événements, ne sont pas
si simples à indexer

par Google et des assistants
numériques, et cetera.

Ainsi, la vision
que nous avons eue ensemble,

était de disposer
d'une base de connaissances

pour de nombreux acteurs simultanément.

Nous avons donc examiné l'ensemble
du réseau de valeurs des arts de la scène,

nous y avons identifié
les principaux acteurs,

nous avons passé en revue
les scénarios d'utilisation

que nous souhaitions implémenter,

et l'avons en quelque sorte cartographié
à l'ensemble de l'architecture

d'une telle base de connaissances,

ou des différentes plateformes
qui s'y trouvent,

ce qui est, évidemment,
une architecture distribuée,

et pas un seul grand monolithe.

Je vais simplement survoler cette partie
car nous disposons de dix minutes chacun,

mais je pense que nous aurons du temps
pour approfondir cela ce soir ou demain,

si des personnes veulent
en savoir un peu plus.

Nous sommes donc partis de ce réseau
de valeurs des arts de la scène

ce qui, curieusement,
a été publié l'année dernière,

nous avons donc eu la chance de pouvoir
nous appuyer sur des travaux antérieurs,

par exemple, on a la chaîne de valeur
primaire des arts du spectacle au milieu,

et les différents acteurs autour.

Au total, nous avons identifié
20 groupes d'acteurs,

que nous pouvons ensuite rassembler
en sept grandes catégories.

Pour chacun des groupes d'acteurs,

nous avons en quelque sorte
formulé le type de besoins

qu'ils auraient
d'une telle infrastructure,

ce qu'ils seraient en mesure
de réaliser si le tout était interconnecté

et que les données
étaient accessibles au public.

On peut donc voir ici les types...

les différents types : Production,
Présentation et promotion,

Couverture et réutilisation, le Live,
Consommation en ligne, Héritage,

Recherche et éducation.

Et après avoir rassemblé cela en un tout,
dont on peut voir la première partie ici,

nous avons pu, disons, comparer, examiner

quel type de données ont été utilisées
dans l'ensemble du tableau,

par les différents groupes d'acteurs.

Et la base de données
qui leur est commune est plutôt importante

et c'est bien là que ça a du sens
d'incorporer et de garder...

de conserver ces données ensemble.

Donc, lorsque l'on parle
de l'architecture de la plateforme,

on peut voir que nous avons
quatre couches ici.

En bas, apparaît la couche de données,

bien évidemment, Wikidata y joue un rôle,

mais aussi de nombreuses
autres bases de données distribuées

qui peuvent publier des données
via des points de terminaison SPARQL.

Le nuage jaune au milieu
est la couche sémantique,

c'est notre langue commune
pour décrire les choses,

pour créer des déclarations

autour des arts de la scène,
de l'ontologie.

Nous avons ensuite
une couche d'application

qui se compose de différents modules,
par exemple, l'analyse des données,

l'extraction de données,

comment transformer des données
non structurées en données structurées,

comment assister
cette tâche par des outils.

Puis, évidemment,
il y a la visualisation des données,

par exemple, s'il existe
de grandes quantités de données,

vous voudrez les visualiser
d'une manière ou d'une autre.

Et au sommet, vous avez
la couche de présentation,

c'est ce avec quoi les gens ordinaires
interagissent quotidiennement :

les moteurs de recherche,
les encyclopédies, les agendas culturels,

et tout un tas d'autres services.

Nous ne partons pas de zéro.

Certains travaux ont déjà
été menés dans ce domaine.

Je me contenterai de citer
quelques exemples de projets

auxquels j'ai participé,

ainsi que d'autres sujets.

J'ai donc débuté dans ce domaine

avec les Archives suisses
des arts du spectacle.

En plus de la construction d'une base
de données sur les arts de la scène,

nous en avons créé l'ontologie,

qui est actuellement implémentée en RDF,

et on dispose déjà
d'une base de données

regroupant 60 à 70 ans
d'histoire du spectacle Suisse,

c'est donc quelque chose
qui peut servir de base,

et ça a été transformé en RDF.

Et il y existe déjà une plateforme
où ces données peuvent être consultées.

Alors nous avons fait
plusieurs injections dans Wikidata,

en partie de la Suisse,

mais aussi des instituts
des arts du spectacle.

Bart Magnus a par exemple
participé à ce projet.

Il en a été le moteur.

Il y existe aussi des éléments
de Wikimedia Commons,

mais qui ne sont pas très bien
reliés au reste de nos métadonnées,

et évidemment,
en procédant à cette injection,

nous avons pu aussi implémenter
une partie de ce modèle dans Wikidata.

L'un de nos partenaires Canadien
est Culture Creates.

Ils gèrent une plateforme qui récupère
les données des sites web des théâtres

et les injectent
dans un graphique de connaissances,

pour ensuite l'exposer
aux moteurs de recherche

et d'autres dispositifs de recherche.

Et là encore,

nous avons en quelque sorte implémenté
et étendu ce système à l'ontologie.

Et comme on peut le voir
sur la diapositive,

il y a encore beaucoup d'espaces vides,
mais il y a aussi des chevauchements,

et un chevauchement important qui est
évidemment la langue commune partagée,

ce qui nous aidera à interconnecter
les différents ensembles de données.

Il est également important

d'utiliser les même registres de base
et fichiers d'autorité,

et Wikidata joue un rôle important
dans ce domaine

en interconnectant.

J'aimerais maintenant vous faire part
des recommandations

par le comité consultatif de l'initiative
« Un avenir numérique lié »,

tout du moins, des deux premières
recommandations.

Donc, pour les Canadiens,
il est désormais crucial de remplir

leur propre graphique des connaissances
sur les arts du spectacle,

car, contrairement aux Archives suisses
des arts du spectacle,

ils n'ont pas une base de données
déjà existante,

mais ils peuvent la créer,

et il est absolument crucial
d'y avoir des données.

Et deuxièmement,
comme vous pouvez le voir,

cela concerne Wikidata.

Wikidata, aux yeux du comité consultatif,

a été considéré comme source
complémentaire à Artsdata.ca,

ce graphique de connaissance,

et, par conséquent,
des efforts devraient être faits

pour contribuer à sa population

par le biais de données relatives
aux arts du spectacle.

Et c'est à ces fins que nous allons œuvrer
au cours des mois et des années à venir,

et c'est aussi pourquoi
je suis un peu à l'affût

de voir qui d'autre
se joindra à cet effort.

Wikidata et le WD classique
sont complémentaires.

Donc, évidemment, actuellement,
nous les disons complémentaires.

Nous devons donc réfléchir

aux avantages et inconvénients
de chacune des approches,

et on peut voir ici une comparaison

entre les approches Wikidata
et les données ouvertes liées classiques.

Je serais heureux d'approfondir
le sujet avec vous,

quelles expériences vous avez de cela,

mais mon point de vue est
que Wikidata est un atout considérable,

parce que c'est une plateforme
de crowdsourcing,

et qu'il est facile d'inviter
d'autres acteurs à y contribuer.

Le point négatif, évidemment,
est la perte de contrôle :

les propriétaires de données
doivent abandonner le contrôle

de leurs graphiques,

de la qualité et l'exhaustivité
des données.

Il est plus difficile d'effectuer
un suivi sur Wikidata

que si vous en aviez le contrôle.

Une autre force de Wikidata
est que ça exige

une intégration immédiate
dans ce graphique mondial,

et vous pouvez le faire...

pas à pas par rapport
à d'autres bases de données,

ce qui peut également être vu
par certains comme un avantage,

mais bien sûr, si vous cherchez
de l'intégration et de l'interopérabilité,

Wikidata vous oblige
à aller le chercher depuis le début.

Et puis, évidemment, l'harmonisation
des pratiques de modélisation des données

pose problème dans les deux options.

Mais cela peut vous sembler
plus facile, au début,

de le faire dans votre propre silo,

parce qu'à un moment donné,
vous en aurez terminé avec cette tâche,

sinon ça resterait
une tâche en cours sur Wikidata.

Ainsi, lorsqu'il s'agit de définir
les données à injecter en priorité,

voici les règles,
que je vais passer en revue.

Tout d'abord, on injectera les données

là où l'autorité naturelle
n'est pas clairement définie,

il s'agit donc évidemment de données
qui seront gérées de manière partagée.

On injectera des données

là où nous voyons un potentiel élevé
de crowdsourcing.

On injectera des données

là où elles sont susceptibles
d'être réutilisées

dans le contexte de Wikipédia.

Et il y a aussi un espoir qu'une partie
de la coordination internationale

autour de l'ensemble
de la modélisation des données,

autour de la normalisation,

puisse avoir avoir lieu
directement sur Wikidata,

si ce n'est ailleurs,

parce que cela force les gens à interagir

s'ils injectent leurs données
dans un même endroit.

Et j'aimerais maintenant aborder

les registres de base
et les fichiers d'autorité

car ils nous aident en quelque sorte
à créer des liens

entre les différentes données
et des vocabulaires contrôlés

comme une extension
de l'ontologie existante.

Il nous reste donc à voir
deux autres diapositives.

La prochaine étape consiste
à passer de la « somme des GLAM »

et à « Wiki aime les arts du spectacle ».

Cela signifie que nous décrivons
les lieux et organismes

et essayons d'envoyer
ces données dans Wikipedia

sous forme d'infoboxes et infobulles.

L'autre projet que je vais mener
est le COST Action,

que nous présenterons l'année prochaine

autour de cet écosystème de données
ouvertes liées pour les arts du spectacle.

COST est un programme européen

qui soutient les activités
de mise en réseau,

et les sujets à traiter sont énumérés ici.

J'en ai souligné deux d'entre eux :

l'un d'entre eux traite de la question
de fédération entre Wikidata

et une approche de données ouvertes liées.

Et l'autre est également
très important à mon sens,

et présente un énorme potentiel,

il s'agit de mettre en œuvre
des campagnes internationales

pour suppléer les données sur Wikidata.

Eh bien, voilà !

Je vous remercie de votre attention.

Maintenant, je vais demander
à mes collègues de me rejoindre.

Pour le panel, nous aurons peut-être
des microphones également.

Et puis j'aimerais...

vous donner la possibilité
de poser des questions,

et bien sûr demander à mes collègues

s'ils ont des questions
les uns pour les autres.

Alors, avons-nous une question du public ?

(rires)

(un·e intervenant·e parle sans micro)

(rires)

(intervenant·e 2) J'aimerais demander
à chacun d'entre vous

où vous traceriez la ligne...

en gros, comment vous définiriez

le moment où il est nécessaire
de gérer votre propre Wikibase,

et ce vous mettriez sur Wikidata ?

Est-ce qu'il y a une délimitation claire
derrière la mise en ordre ?

Je peux répondre en premier
parce que j'ai le micro.

Donc, je pense que l'un des enjeux
est la notoriété.

J'y réponds dans un autre projet.

Et je pense que la licence
pourrait en être un aussi,

parce que vous pouvez imposer
vos propres conditions

dans votre propre base de données,
lorsque c'est possible.

Et troisièmement,
je dirais qu'il faut avoir un bac à sable,

pour préparer l'injection
des données dans Wikidata.

Voici les trois idées
qui me viennent pour l'instant,

mais je peux en trouver d'autres.

Pour moi, les droits seront
toujours un problème.

Donc, si la Bibliothèque nationale
voulait se diriger vers une Wikibase,

cela leur permettrait de continuer
à contrôler l'octroi des licences

pour le travail qu'ils ont accompli
sur les termes en langue maori.

La base de données kakapo
ne contient que des données

que le Ministère de la conservation
a estimé pouvoir rendre publique,

mais s'ils le voyaient en état de marche,

ils pourraient être tentés
d'utiliser une Wikibase privée

pour gérer leur propre base de données,

tout bonnement à cause de certains
des outils de visualisation

qui pourraient être appliqués
et seraient bien plus efficaces

qu'un système de tableur Excel
qu'ils utilisent actuellement.

Eh bien, je pense que cela dépend
beaucoup du type de données.

Avec les archives de presse,
nous avons été assez chanceux,

en ce sens qu'il s'agissait
d'un support qui a été publié...

qui a été publié à l'époque,

mais sa publication a été coûteuse.

Donc, c'est assez simple.

Je pense aussi que les projets...

et c'était un projet classique :

il a été financé pendant un temps donné,
puis le financement a pris fin,

et puis les données
ont été enfermées dans un silo,

au sein de certains logiciels
qui ne sont pas éternels.

Et donc, cela fait
absolument sens à mes yeux.

À l'époque, Wikidata n'existait pas,
mais maintenant il est là,

et c'est tout à fait logique
pour notre projet

d'en discuter la viabilité

dans un contexte où la question est
l'intégration à un écosystème plus vaste

comme Wikidata,

et ce que c'est exactement,

en discuter avec la communauté Wikidata,

quel en est l'aspect notable
et quel sens ça a de l'ajouter à Wikidata,

et quel sens ça a de le conserver
sous forme de propriété,

peut-être sous une forme plus simple
qu'une application sophistiquée,

mais de le rendre accessible
et le relier au cloud de big data

au lieu d'investir beaucoup d'argent

dans un silo qui ne tiendra pas.

Comme je l'ai déjà dit
dans le projet que j'ai présenté ici,

comme les dualités entre Wikidata
et les données ouvertes liées classiques,

il ne s'agit donc pas tant
de la mise en place d'une Wikibase privée.

Nous avons également fait face
à un défi, dans Wikidata :

lorsqu'on injecte ses propres données,
on doit également faire un peu de ménage,

et nettoyer ce qu'ont fait
les autres, en réalité.

Ça peut en décourager certains,

ou bien ça veut dire
qu'on va devoir s'en occuper pas à pas.

Il y aura donc, dans un premier temps,
une base de données vivant

dans un Web de données classique

qu'on commencera à relier à Wikidata,

et il s'agit d'un processus continu
pour déterminer pour quels domaines

les données de références
vivront finalement sur Wikidata,

et pour quels domaines elles vivront
sur d'autres bases de données.

Il est évident que nous aurons
des défis à relever

concernant la synchronisation,

comme nous l'avons probablement tous
au travers de ce champ de Web de données.

où il nous faut encore négocier
à qui l'on peut se fier,

qui possède les droits, sur quoi.

(assistant·e) D'autres questions ?

(intervenant·e 3) Merci.

Alors, je suis tout à fait d'accord
avec cette question de...

déterminer où placer la limite

entre les raisons pour lesquelles
nous mettons des données sur Wikidata,

ou pourquoi on les garde,
on les crée, les gére et les met à jour

dans les bases de données locales
et à quelles fins.

Et je pense qu'il s'agit d'un grand débat

qui va au-delà du simple enthousiasme

de mettre des données sur Wikidata
parce que c'est public,

parce qu'il sert l'humanité, parce que...

ou qu'il possède des outils sympas,

et les choses sont plus compliquées
dans la vie réelle, je pense.

Eh bien, malgré cela,
c'est un débat assez intéressant.

Et il y a un autre problème
qui est débattu

dans cet événement
où l'on présente différents panels :

d'un côté, vous avez
votre propre base de données,

quelle que soit la technologie,

et vous publiez des choses sur Wikidata,

ou vous construisez votre propre système

en termes de création
et de gestion de l'information

à partir de la technologie Wikibase.

Et ensuite, vous synchronisez
ou je ne sais quoi...

fédérez ou bien autre chose ;

il s'agit toujours d'une question
de technologie utilisée,

et le fait que vous utilisiez Wikidata
juste pour la publication,

ou l'infrastructure
qui se trouve sous Wikidata

pour créer et gérer vos données.

Donc...

(hésitation)

Je veux dire que nous avons
eu une discussion

sur le panel de la Wikibase,

et il y aura d'autres débats ici,

mais je pense qu'il y a
différents niveaux.

Vous réagissez certainement à ce débat
sur Wikibase ou Wikidata...

Je pense que c'est problématique
de tant nous concentrer

sur cette infrastructure Wikibase,

parce qu'il existe
d'autres infrastructures,

comme dans le domaine
des arts du spectacle.

Nous avons une communauté
complémentaire supplémentaire

qui est MusicBrainz,

qui tourne sur sa propre plateforme,
qui fournit des données ouvertes liées

et tel que je le comprends,

il existe un accord
au sein de la communauté Wikidata

qui dit que nous n'allons pas
doubler toutes les données...

nous n'allons pas copier
toutes les données,

mais nous acceptons
qu'ils soient complémentaires.

Alors, que se passera-t-il

lorsqu'on commencera à intégrer
ces données dans Wikipédia ?

les infoboxes, par exemple.

Serons-nous en mesure
d'extraire ces données

directement à partir
de leur points de terminaison SPARQL ?

Ou serons-nous obligés
de copier toutes les données,

et quel type de processus
cela fait appelle ?

(intervenant·e 4)
Le débat est ouvert, je pense,

parce que dans le cadre de cet événement,

vous avez ces communautés intéressées...

celles qui s'intéressent à Wikibase,

celles qui s'intéressent à Wikidata,

et celles qui s'intéressent aux deux.

Oui, mais nous n'allons pas
les obliger à aller vers Wikibase.

- (i. 4) Pas nécessairement.
- MusicBrainz ne tourne pas sur Wikibase.

(i. 4) Non,
je voulais simplement dire

que ce sont des problèmes bien distincts.

Parfois, ils sont reliés, parfois non,
ils sont complètement séparés.

Et j'avais une autre question ou remarque

concernant la gestion des hiérarchies
dans les vocabulaires contrôlés,

comme la source, comme vous dans Finto.

Vous avez les lieux...

et les maoris...

les rubriques maories...

Eh bien, ils doivent faire face
à la gestion des concepts

dans la hiérarchie.

Quelle est votre opinion

sur la possibilité de gérer ce contrôle...

de l'organisation des connaissances
dans les Wikidata ?

Je pense que dans le cas
des lieux Finto et YSO,

le référenciel sera une collection

de plusieurs sources, à terme.

Il est de toute façon en pleine mutation.

Donc, nous n'avons pas besoin de...

Bon, je ne représente pas
la Bibliothèque nationale,

mais dans ce projet potentiel,

nous n'aurions pas à entretenir...

ou plutôt, lutter
avec une structure existante.

Donc, en ce sens,

il s'agit d'un domaine
ouvert à l'exploration.

Les rubriques maories semblent
se prêter à la structure Wikidata,

mais la licence, bien sûr, l'interdit.

Si la licence était différente

et que les données
étaient mises dans Wikidata,

si quelqu'un décidait
qu'il n'en aimait pas la hiérarchie

et tentait de modifier quelque chose,

il y aurait un tollé immédiat
des personnes ayant travaillé très dur

pour créer cette structure

et on chercherait à obtenir
confirmation auprès des Maoris

que c'était bien la bonne hiérarchie.

C'est donc un problème
qu'il faut essayer de résoudre.

Je pense qu'en termes de connaissances
des systèmes d'organisation,

ils sont tous différents.

Et je ne suis pas certain
que ce serait une bonne idée

de représenter les différentes hiérarchies
dans Wikidata en tant que tel,

mais ça peut être intéressant
de réfléchir à des superpositions

des données,

et donc, de cartographier les contenus.

Par exemple, en tant que partenaire ZBW
pour le Thesaurus d'économie,

ce thésaurus établit sa propre hiérarchie,

et, bien sûr, il serait possible
de projeter la hiérarchie

de ce thésaurus en concepts Wikidata

sans pour autant stocker
ce type de structure

comme structure alternative
dans Wikidata

ce qui créerait beaucoup de confusion.

Mais je pense
que nous devrions voir Wikidata

comme un réservoir de concepts

qui seraient connectés
en couches extérieures,

et donneraient une autre vision du monde

mais qui ne feraient
pas nécessairement partie de Wikidata.

(assistant·e) Très bien.
D'autres questions ?

Sinon... d'accord.

(intervenant·e 6) Joachim, je voulais
juste donner suite à ce dernier point.

Donc, ces couches,
comme vous les imaginez,

seraient-elles maintenues à l'extérieur

et d'une manière
ou d'une autre intégrées...

à Wikidata, d'un point de vue Wikidata,

ou avez-vous réfléchi un peu plus

à la manière dont tout cela
pourrait être géré ?

En réalité, non, je n'ai pas...

J'ai fait des essais avec ZBW et Wikidata.

J'étais [inaudible] à Wikidata.

Mais je pense que c'est une nouveauté
tout à fait complexe,

et donc, c'est sujet à débat,
[de renoncer à beaucoup de contrôle]

pour faire une telle chose.

Mais il faudrait trouver une solution.

Encore une autre ?

(intervenant·e 5) Ah, super.

J'avais une question
concernant le projet kakapo.

Mmh-mmh.

(intervenant·e 5) OK, donc, avez-vous
reçu un refus de la communauté Wikidata

sur le fait de référencer
des individus de la faune ?

Pas encore.

(i. 5) Quelqu'un a-t-il entendu
parler de ce sujet auparavant ?

« Pas encore »

parce que personne
n'en a encore entendu parler ?

Ça fait déjà un certain temps
qu'on en discute...

avec des personnes intéressées
dans ce genre de choses dans Wikidata,

et nous semblons tous penser
qu'il s'agit d'une extension naturelle

d'accorder aux individus
des articles Wikidata

comme un cheval de course célèbre

ou le chat de quelqu'un, qui...
C'est assez bien modélisé.

Je pense que l'audace,
c'est d'y référencer toute l'espèce.

Mais je pense
que c'est tout à fait gérable.

N'essayez pas avec des chats
ou des chiens.

(rires)

(assistant·e) Parfait, je pense
que le temps est écoulé.

Merci beaucoup de votre présence.

Nous sommes toujours ouverts
aux questions durant la pause,

et amusez-vous bien.

Merci beaucoup.

(applaudissements)

WIKI DATA CON 2019
Wikidata et les langues