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