cdn.media.ccc.de/.../wikidatacon2019-9-eng-Data_quality_panel_hd.mp4

Panel sur la qualité des données

Bonjour à tous, bienvenue
au groupe Qualité de Données.

La qualité de données est importante
car de plus en plus de gens

se basent sur nos bonnes données
et donc, nous allons parler de qualité.

Il y aura quatre orateurs qui
présenteront des introductions

sur des sujets concernant la qualité
de données suivies de questions-réponses.

Le premier est Lucas.

Merci.

Je m'appelle Lucas et je vais
commencer par une vue générale

des outils de qualité de données
que nous possédons déjà sur Wikidata

et sur les prochaines nouveautés.

Je les ai regroupés par thèmes :

rendre les erreurs plus visibles,
les problèmes actionnables,

avoir plus de vues sur les données
pour que les problèmes soient remarqués,

remédier aux sources communes d'erreurs,
maintenir la qualité existante

et le référencement humain.

Et ce qui est actuellement disponible
commence par les contraintes de propriété.

Si vous êtes sur Wikidata,
ceci vous est sûrement familier.

Des icônes vérifiant
la cohérence interne des données

sont parfois présentes.

Par exemple,
si un événement en suit un autre,

cet autre devrait aussi
être suivi par celui-ci,

ce qui n'est apparemment pas
sur l'item WikidataCon.

Je ne suis pas sûr, cette fonction
date que quelques jours.

Et si ceci est trop limité
ou simple pour vous,

vous pouvez utiliser n'importe
quelle vérification grâce à Query Service,

ce qui est bien sûr très pratique.

Mais vous pouvez aussi l'utiliser
pour déterminer les erreurs.

Si vous avez remarqué une erreur,

vous pouvez regarder

si d'autres erreurs similaires
ont été commises

et les trouver avec le Query Service.

Vous pouvez également
combiner les deux

et rechercher
des violations de contrainte,

par exemple, uniquement
celles dans une zone particulière

ou un WikiProject qui vous est pertinent.

Malheureusement, les résultats
ne sont actuellement pas complets.

Il existe la notation de révision.

Provenant des changements récents,

vous pouvez aussi avoir
une évaluation automatique :

cette édition est-elle faite
de bonne ou mauvaise volonté

et peut-elle être préjudiciable ou non.

Voilà les deux dimensions.

Vous pouvez si vous le voulez,

vous concentrer sur les éditions
néfastes mais de bonne volonté.

Si vous êtes dans une humeur
particulièrement amicale et accueillante,

vous pouvez dire à ces éditeurs :
« Merci pour votre contribution,

vous auriez dû le faire comme ça,
mais merci quand même. »

Si vous n'êtes pas dans cette humeur,

vous pouvez examiner les éditions
préjudiciables de mauvaise foi

et inverser le vandalisme.

Il y a aussi la notation d'entité.

Au lieu de noter une édition,
la modification apportée,

vous notez la révision complète

et je pense que c'est
la même mesure de qualité

que Lydia mentionne
au début de la conférence.

Cela nous donne un script d'utilisateur
et un score de un à cinq, je pense,

de la qualité de l'item actuel.

L'outil des sources primaires s'utilise
pour toute base de données à importer,

mais n'est pas d'assez bonne qualité que
pour être ajouté directement à Wikidata.

Il doit donc être ajouté
à l'outil des sources primaires

pour que les humains puissent décider

d'ajouter ces énoncés individuels ou non.

Afficher les coordonnées
sous forme de cartes est pratique,

mais peut aussi
servir de contrôle qualité.

Si vous voyez que les coordonnées
du bureau de Wikimedia Germany

se trouvent quelque part
dans l'océan Indien,

vous savez que quelque chose ne va pas

et cela se remarque plus facilement
que simplement avec des chiffres.

C'est un gadget appelé
« l'indicateur de complétude relative »

qui vous montre cette petite icône ici

vous donnant son estimation
de complétion de l'item

ainsi que les propriétés manquantes,

ce qui est très utile
si vous éditez un item,

que vous êtes dans une zone peu familière

et que ne savez pas quelles sont
les propriétés correctes à employer,

c'est alors un gadget très utile.

Il y a aussi les « Shape Expressions ».

Andra et Jose nous en parleront davantage,

mais c'est en gros, un moyen puissant
de comparer les données

par rapport au schéma,

comme quel état devrait
avoir certaines entités,

à quelles autres devraient-elles se lier
et à quoi devraient-elles ressembler,

vous pouvez ainsi trouver les problèmes.

Ce n'est pas fini.

« Integraality » ou
tableau de bord de propriété.

Il vous fournit une vue rapide
de vos données existantes.

Par exemple, ceci provient
du WikiProject « Red Pandas »

et vous pouvez voir que le sexe ou genre

de presque tous les pandas sont assignés.

La date de naissance varie selon leur zoo

et heureusement, il n'y a
presque aucun panda mort.

Ils sont trop mignons.

Ceci est donc aussi utile.

Voilà. Voyons maintenant
ce qui va arriver.

Wikidata Bridge, connu antérieurement
sous le nom de l'édition client ;

donc éditer Wikidata
à partir des info-boxes Wikipedia

qui d'une part, permettra
plus de vues sur les données

car plus de personnes peuvent les y voir,

en espérant que cela engendrera
un emploi plus important de Wikidata

et que plus de gens peuvent voir

si par exemple, certaines données sont
dépassées et doivent être mises à jour

au lieu de seulement
les voir sur Wikidata.

Il y a aussi les références contaminées.

L'idée est que si vous modifiez
une valeur de relevé,

vous pourriez également vouloir
mettre cette référence à jour

à moins que ce ne soit juste
une erreur de frappe.

Cette référence contaminée
dit aussi aux autres éditeurs

quelles modifications de relevé
de valeur ont été faites

qui n'ont pas mis la référence à jour.

Vous pouvez alors remédier à cela
et décider si...

Est-ce que vous devez en faire plus

ou c'est bien comme ça, il n'y a
pas besoin de mettre la référence à jour.

Cela concerne les relevés signés
originaires d'un souci

de certains fournisseurs de données...

Il y a un énoncé que l'UNESCO a référencé

qui a été vandalisé

et ils sont donc inquiets qu'il semblerait

que cette organisation, l'UNESCO
aurait validé cette valeur vandalisée.

Mais grâce aux énoncés signés,

ils peuvent le faire
de manière cryptographique

sans empêcher les modifications ;

mais au moins,
si quelqu'un vandalise l'énoncé

ou le modifie de quelque façon,
la signature n'est alors plus valide

et on peut voir que ce n'est pas
ce qu'a dit l'organisation,

et il se peut que ce soit une bonne
modification qui devrait être resignée,

mais qui pourrait aussi
devoir être annulée.

Une chose excitante

est que Wikipedia comprend
ce système étonnant appelé « Citoid »

où on peut coller une URL,
un identifiant ou un ISBN

ou un ID Wikidata ou pratiquement
n'importe quoi dans le Visual Editor

qui retourne une référence bien formatée

avec toutes les données possibles,
c'est très gai à utiliser.

Pour comparer avec Wikidata,
si je veux ajouter une référence,

typiquement, je dois ajouter une URL,
un titre, nom d'auteur,

date et lieu de publication,

dates de récupération,
au moins tout ça et c'est embêtant.

On peut espérer que l'intégration de
Citoid dans Wikibase améliorera la chose.

Je crois que c'est tout pour moi.

Je passe la parole à Cristina.

Comment améliorer la gestion
de qualité de données ?

(applaudissements)

Bonjour, je suis Cristina.

Je suis chercheuse scientifique
à l'université de Zurich

et je suis aussi une membre active
de la communauté suisse.

Quand Claudia Müller-Birn et moi-même
avons présenté ceci à WikidataCon,

ce que nous voulions,
c'est continuer la discussion

commencée au début de l'année

avec un atelier sur la qualité de données
et des sessions dans Wikimania.

Le but de cette conférence
est de parler des pensées

réunies de la communauté et de nous-mêmes

et de continuer cette discussion.

Nous aimerions beaucoup
continuer cette interaction avec vous.

Nous pensions qu'il est très important

de toujours demander à tous
les types d'utilisateur de la communauté,

quels sont leurs besoins et problèmes
concernant la qualité de données ;

non seulement les éditeurs,
mais aussi les codeurs

ou les consommateurs de données

et également les chercheurs qui
utilisent toute cette historique d'édition

pour analyser les événements.

Nous avons donc examiné
à peu près 80 outils de Wikidata

et les avons alignés aux différentes
dimensions de qualité de données.

Ce qu'on a réalisé, c'est que

nombre d'entre eux
surveillent la complétion,

mais certains d'entre eux
permettent l'interconnexion.

Mais il y a un grand besoin pour
des outils travaillant dans la diversité,

ce qu'on peut en fait avoir dans Wikidata,

spécialement dans
son principe de conception

où la pluralité et les relevés
différents contenant différentes valeurs

provenant de différentes sources

peuvent exister.

Parce que la source est secondaire,
nous n'avons pas vraiment d'outils

qui nous disent réellement
quelle est la pluralité d'énoncés,

combien nous pouvons améliorer
et de quelle manière

et nous ne connaissons
pas non plus vraiment

les raisons de cette pluralité.

De ces réunions de communauté,

nous avons discuté les défis
qui demandent de l'attention.

Par exemple, le fait d'avoir ces
communautés de production participative

est positif car différentes personnes

avec des connaissances de base différentes

attaquent les différentes parties
des données ou du graphe ;

mais en réalité, il est difficile
de tout aligner de manière homogène

car différentes personnes utilisent
différentes chose de façons différentes

et s'attendent aussi à différentes
choses venant des descriptions d'entité.

Les gens ont aussi dit
qu'ils ont besoin de plus d'outils

qui donnent une meilleure vue d'ensemble
du statut global des choses.

C'est donc ce qui manque aux entités
en termes de complétion,

mais aussi sur quoi les gens
travaillent-ils maintenant

et ils ont aussi mentionné maintes fois
d'avoir une collaboration plus étroite

entre non seulement, les langages,
mais aussi WikiProjects

et les différentes
plateformes de Wikimedia.

Nous avons publié tous
les commentaires transcrits

de toutes les discussions
dans les liens de Etherpads

et dans la page wiki de Wikimania.

Certaines solutions pointaient

vers le fait de plus partager
les bonnes pratiques

qui sont développées
dans différents WikiProjects,

mais il y a aussi une demande pour
des outils qui facilitent l'organisation

de travail dans les équipes
pour savoir qui fait quoi

et également, pour plus de vitrines

et de modèles pour aider à mieux créer.

D'après le contact que nous avons

avec les Open Governmental
Data Organizations,

et particulièrement,

je suis en contact avec
le canton et la ville de Zurich,

ils sont très intéressés
de travailler avec Wikidata

parce qu'ils veulent
leurs données accessibles à tous

dans les endroits où les gens
consultent et accèdent aux données.

Ce qui peut être intéressant pour eux

serait d'avoir un genre
d'indicateurs de qualité

à la fois dans le wiki,
ce qui est valable actuellement,

mais aussi dans les résultats SPARQL,

afin de savoir s'ils peuvent faire
confiance aux données communautaires.

Ils veulent aussi savoir

quelles parties de leur propre ensemble
de données sont utiles pour Wikidata

et aimeraient un outil qui peut les aider
à évaluer ça automatiquement.

Ils ont aussi besoin
d'une méthodologie ou outil

pour les aider à décider s'ils doivent
importer ou connecter leurs données,

car dans certains cas,

ils ont aussi leurs propres ensembles
de données ouverts couplés ;

ils ne savent donc pas s'ils doivent
juste ingérer des données

ou continuer de créer des liens
des ensembles de données vers Wikidata

et le contraire.

Et ils veulent aussi savoir où est
référencé leur site web dans Wikidata.

Quand ils introduisent
une telle demande dans le service,

ils sont souvent mis en attente,

nous devrions donc
peut-être créer plus d'outils

pour les aider à répondre à ces questions.

Et de plus, (craquements)

nous, les chercheurs wiki,

manquons d'information
dans les résumés d'édition.

Je me souviens que quand nous travaillions

à comprendre les différents
comportements des éditeurs

avec outils ou bots,
utilisateurs anonymes et que sais-je,

il nous manquait par exemple,

une manière standard de tracer
les outils qui étaient utilisés.

Certains outils font déjà cela,

comme PetScan et plein d'autres.

Nous devrions peut-être
plus discuter en communauté

comment enregistrer ceux-ci
pour une origine peaufinée.

De plus,

nous devons penser à des dimensions
de qualité de données plus concrètes

qui sont reliées aux données couplées,
mais non à tout type de données.

Nous avons donc travaillé sur certaines
mesures pour accéder au gain d'information

fournis par les liens, ce qui veut dire

que quand nous connectons Wikidata
à d'autres ensembles de données,

nous devrions aussi envisager

le gain de classification des entités

dans la description, mais aussi
dans les vocabulaires utilisés.

Pour vous donner un exemple,

dans le cas de Wikidata

ou du centre de données externe
lié à Wikidata,

nous avons l'entité d'une personne
appelée « Natasha Noy »,

nous avons l'affiliation
et d'autres choses

et nous décidons de connecter
à un endroit externe

où cette entité a aussi ce nom,
mais la valeur reste la même.

Il serait alors mieux de connecter
à quelque chose qui a un nom différent

qui est toujours valide car cette personne
peut écrire le nom de deux manières

ainsi que d'autres informations
non disponibles dans Wikidata

ou dans l'autre ensemble de données.

Mais ce qui est encore préférable,

c'est d'examiner
l'ensemble de données cible

pour voir qu'il a aussi de nouvelles
façons de classifier l'information.

Ce n'est donc pas juste une personne,
mais dans l'autre ensemble de données,

ils parlent aussi en termes de femme
et autre forme de classification.

Et si l'autre ensemble de données
utilise différents vocabulaires,

cela aide dans la récupération
des données.

Je voudrais encore ajouter

que nous sommes capables de mieux
mettre en valeur les requêtes fédérées

car quand nous consultons le journal
de requêtes fourni par Malyshev et al.,

nous constations que
parmi les requêtes organiques,

il y a très peu de requêtes fédérées.

Et en fait, un des avantages clés
des données couplées est la fédération ;

il se pourrait donc que la communauté
et les gens qui utilisent Wikidata

devraient avoir plus
d'exemples à ce sujet.

Et si on lit la liste
des points finaux utilisés,

celle-ci n'est pas complète,
nous en avons bien d'autres.

Bien sûr, ces données ont été analysées
à partir de demandes jusqu'en mars 2018,

mais nous devrions revoir la liste
des points finaux acquis

pour décider si
nous les utilisons vraiment.

J'ai deux questions pour l'audience

que nous pouvons peut-être
utiliser pour la discussion ultérieure :

« À votre avis, quels sont les problèmes
de qualité de données à adresser

dépendant de vos besoins ? »

et « Où avez-vous besoin
de plus d'automation

pour vous aider dans les éditions
et les patrouilles ? »

Ce sera tout, merci beaucoup.

(applaudissements)

MERCI !

(Jose Emilio Labra)
Je vais maintenant vous parler

des outils de Shape Expressions
que nous sommes en train de développer.

Je suis Jose Emilio Labra,

mais tous ces outils ont été
construits par des personnes différentes

principalement connectées à W3C ShEx,
Groupe de Communauté Shape Expressions.

Groupe de Communauté ShEx.

Le premier outil dont j'aimerais parler
est un outil général : le RDFShape ;

car Shape Expressions convient
non pas seulement pour Wikidata,

mais constitue un langage
qui valide RDF en général.

Je suis l'acteur principal
du développement de cet outil

qui valide RDF en général.

Si vous voulez connaître ou valider RDF

ou les points d'extrémité SPARQL
pas seulement dans Wikidata,

je vous conseille d'utiliser cet outil.

Il est également bon pour l'enseignement.

J'enseigne à l'université

et je l'emploie dans mon cours
de Web sémantique pour le RDF.

Je crois donc que c'est un bon outil
si vous voulez apprendre le RDF.

Voici en exemple, une visualisation
d'un graphe RDF avec l'outil.

Mais avant de venir ici,
au cours du mois dernier,

j'ai commencé une fourchette de RDFShape
juste pour Wikidata car je croyais...

Je l'ai présenté hier à Wikidata,
elle s'appelle « WikiShape ».

Ce que j'ai fait...

j'ai retiré tout ce qui
ne concernait pas Wikidata

et implémenté d'autres choses codées
en dur comme l'extrémité Wikidata SPARQL,

mais on m'a demandé maintenant
si je pouvais faire de même pour Wikibase.

Ce qui est très facile à faire.

L'outil WikiShape est
relativement nouveau.

La plupart des fonctionnalités
sont opératives,

mais il est possible
que certaines ne fonctionnent pas

et si vous voulez les améliorer,
s'il vous plaît, dites-le moi.

C'est donc [des captures Science Script],
mais on peut essayer.

Voyons si cela marche.

Je dois d'abord sortir de...

Ici.

D'accord, voici l'outil.

Ce que vous pouvez faire
avec l'outil par exemple,

c'est vérifier des schémas d'entité.

Vous savez qu'il y a un nouvel
espace de nommage : « E que sais-je »,

si vous commencez par écrire « humain »,

son auto-complétion
vous permet de vérifier,

par exemple,
le Shape Expressions d'un humain

et voici ici le Shape Expressions.

Et vous remarquez que l'éditeur
possède une coloration syntaxique ;

mais l'écran est peut-être trop petit,

je vais essayer de l'agrandir.

Vous voyez peut-être mieux maintenant.

Voici la surligne syntaxique de l'éditeur,

celui-ci provient du même code source

que le service de requête de Wikidata.

Si vous passez la souris ici,

vous pouvez voir les étiquettes
des différentes propriétés.

Je pense que c'est très utile car

les schémas d'entité présents
dans Wikidata sont juste du texte simple,

cet éditeur est donc meilleur
car il comprend l'auto-complétion

et aussi...

par exemple, si vous voulez
ajouter une contrainte,

vous dites : « wdt: »,

écrivez juste « auteur »,
vous cliquez sur Ctrl+Space

et différentes suggestions apparaissent.

Cette fonction est similaire
au service de requête Wikidata,

mais adaptée pour Shape Expressions.

Il me semble que créer
des Shape Expressions

n'est pas plus difficile que d'écrire
des requêtes SPARQL.

Certaines personnes pensent
que c'est sur un même niveau,

mais je pense que c'est plus facile

car telle était notre intention
quand nous avons conçu Shape Expressions.

Cet éditeur est l'une des premières choses

disponibles dans Shape Expressions.

Il existe aussi
la possibilité de visualiser.

Dans Shape Expressions,
prenons par exemple,

« travail écrit » qui est
une belle Shape Expression

car elle exprime une relation
entre différentes choses.

Et ceci est la visualisation
UML de travail écrit.

Dans un UML, il est facile
de voir les différentes propriétés.

En faisant l'essai
avec plusieurs personnes,

j'ai réalisé quelles trouvaient
des erreurs dans leur Shape Expressions

car les propriétés manquantes
sont faciles à détecter.

L'autre possibilité ici

est la validation ; je crois que la voilà.

Je crois qu'elle était dans une étiquette,
je l'ai peut-être fermée.

Mais vous pouvez par exemple,
cliquer ici sur Validate entities.

Par exemple,

« q42 » avec « e42 » qui est auteur.

Avec « humain », je pense
qu'on peut le faire avec ça.

Et puis,...

Cela prend un peu de temps
car les requêtes SPARQL s'effectuent

et pour le moment,
il y a défaut de réseau, mais...

Vous pouvez l'essayer.

Continuons la présentation
avec d'autres outils.

Dites-moi si vous voulez l'essayer
et si vous voulez un retour.

Poursuivons la présentation.

Voici donc WikiShape.

Je l'ai déjà dit,

l'Éditeur Shape Expressions
est un projet indépendant dans GitHub.

Vous pouvez l'utiliser
dans votre propre projet.

Si vous voulez utiliser
un outil Shape Expressions,

vous pouvez l'intégrer
à n'importe quel autre projet,

il est dans GitHub, utilisez-le.

Le même auteur qui est un de mes élèves

a aussi créé un éditeur
pour Shape Expressions

inspiré également
du service de requête Wikidata

où vous trouvez dans une colonne,

cet éditeur plus visuel de requêtes SPARQL

où vous pouvez introduire
ce genre de choses.

Ceci est une capture d'écran.

Vous pouvez voir
la Shape Expressions dans le texte,

mais celle-ci est basée sur formulaire,
ce qui prendrait un peu plus de temps

et vous pouvez placer les différentes
rangées sur différents champs.

Ensuite, il y a ShExEr

qui a été conçu par un doctorant
à l'université de Oviedo ;

il est présent et peut
donc nous présenter ShExEr.

(Danny) Bonjour, je suis Danny Fernández,

je suis doctorant à l’université d'Oviedo
et je travaille avec Labra.

Vu que nous n'avons pas
beaucoup de temps, je serai bref.

Je ne vais pas faire de démonstration,
mais juste imprimer des copies d'écran.

La façon usuelle de travailler avec
Shape Expressions ou tout autre langage

est d'avoir un expert de domaine

qui définit une priorité sur ce
à quoi devrait ressembler un graphe,

de définir des structures

et d'utiliser ces structures
pour valider les données réelles.

Cet outil, tout comme
ceux présentés par Labra

est un outil polyvalent pour
n'importe quelle source RDF

et est conçu pour travailler à l'envers.

Vous avez déjà des données,

vous sélectionnez les noeuds
dont vous voulez avoir la forme

et vous extrayez ou inférez
cette forme automatiquement.

Donc, même si cet outil est polyvalent,

ce qu'on a fait pour WikidataCon
est ce joli bouton

qui une fois pressé,

fait apparaître de nombreux
paramètres de configuration

et fait une configuration qui va
à l'encontre de l'extrémité Wikidata

[qui se termine], désolé.

Une fois que vous pressez le bouton,
c'est ce que vous obtenez.

Après avoir sélectionné
quel genre de notes,

quel genre d'instances de notre classe,
ou quoi que vous recherchiez,

vous obtenez un schéma automatique.

Les contraintes sont classées d'après
la quantité de modes qui s'y conforment

et vous pouvez filtrer ceux
qui sont moins communs, etc.

Il y a un poster en bas à ce sujet

et je serai en en bas et en haut

et un peu partout toute la journée.

Donc, si vous êtes
intéressés par cet outil,

venez me trouver.

Je repasse maintenant
le micro à Labra, merci.

(applaudissements)

(Jose) Poursuivons
avec les autres outils.

Le suivant est le ShapeDesigner.

Andra, veux-tu en parler maintenant

ou plus tard ou dans l'atelier ?

Il y a un atelier...

Cet après-midi, il y a un atelier
spécifiquement pour Shape Expressions.

L'idée était de faire
plus de travail pratique,

donc si ça vous tente,
vous pouvez le faire là.

L'outil est ShEx et
comme Eric est présent,

il peut nous en parler.

(Eric) Je voulais juste dire rapidement

que vous avez probablement
déjà vu l'interface ShEx

qui est adaptée pour Wikidata.

Elle a vraiment été dépouillée
et conçue spécifiquement pour Wikidata

car celle qui est générique a plus
de fonctions, mais il faut mentionner

le fait que l'une d'entre elles
est particulièrement utile

pour déboguer les schémas Wikidata.

Si vous sélectionnez le mode Slurp,

il va dire que lorsque je valide,

je veux rabattre tous les triples,
ce qui veut dire

que si j'ai un paquet d'erreurs,

je peux les examiner et dire :

« OK, quels sont
les triples présents ici »,

désolé, les triples sont là en bas,

ceci est simplement un registre
de ce qui s'est passé.

Vous pouvez ensuite
jouer avec en temps réel

comme vous le faites
avec quelque chose qui change.

C'est donc une version plus rapide
pour faire tout cela.

Ceci est un formulaire ShExC

que Joachim a suggéré

qui pourrait être utile pour
remplir des documents Wikidata

basé sur une Shape Expression
pour ce document.

Ceci n'est pas conçu pour Wikidata,

mais c'est simplement pour dire
que vous pouvez avoir un schéma

et des annotations

précisant la manière
dont le schéma est rendu ;

le formulaire est ensuite construit

et si vous avez des données,
elles peuvent même peupler le formulaire.

PyShEx [inaudible]

(Jose) Je crois que c'est le dernier.

En effet, PyShEx est le dernier.

PyShEx est une implémentation
Python de Shape Expressions.

Si vous voulez ce genre de choses, vous
pouvez aussi jouer avec Jupyter Notebooks.

OK, le sujet est bouclé.

(applaudissements)

(Andra) Je vais parler d'un projet
spécifique dans lequel je suis impliqué

appelé « Gene Wiki »

où nous avons aussi affaire
aux problèmes de qualité.

Mais avant de parler de qualité,

je vais rapidement
vous présenter Gene Wiki.

Nous venons juste de publier
un document récemment rédigé

qui explique les détails de ce projet.

Je vois les gens prendre des photos,
mais ce que fait Gene Wiki en gros,

c'est essayer d'obtenir des données
biomédicales publiques pour Wikidata ;

et nous suivons un modèle spécifique
pour inclure ces données dans Wikidata.

Donc, quand nous avons un nouveau
répertoire ou ensemble de données

qui qualifie pour
être inclus dans Wikidata,

la première étape est
l'engagement communautaire.

Il n'est pas nécessaire que ce soit
directement vers une communauté Wikidata,

mais une communauté de recherche locale.

Nous nous rencontrons en personne
ou en ligne ou sur une autre plateforme

et essayons de trouver
un modèle de données

qui fait le pont entre leurs données
et le modèle Wikidata.

J'ai ici une photo d'un atelier
de l'année dernière

qui s'est concentré sur
un ensemble de données spécifique,

et vous pouvez voir les discussions,

pour l'aligner avec schema.org
et d'autres ontologies existantes.

À la fin de la première étape,
nous avons un dessin de tableau blanc

du schéma que nous voulons
implémenter dans Wikidata.

Ce que vous voyez ici est simple,

il se trouve là à l'arrière

pour que nous puissions faire des schémas
dans ce panneau même aujourd'hui.

Une fois que ce schéma est en place,

il faut ensuite essayer de rendre
cette machine schéma lisible

car il faut avoir des modèles actionnables
pour importer les données

de toute base de données biomédicale
dans Wikidata.

C'est ici que nous appliquons
Shape Expressions

parce que celle-ci nous permet de tester

si l'ensemble de données...
non, d'abord de voir

si les données déjà existantes dans
Wikidata suivent le même modèle

qui a été atteint dans
le processus précédent.

Avec le Shape Expression,
nous pouvons donc vérifier

si certaines données dans Wikidata
doivent être nettoyées

ou si nous devons adapter notre modèle
à celui de Wikidata ou vice versa.

Une fois que tout est décidé et
que nous commençons d'écrire des bots,

ceux-ci sèmeront les informations

qui se trouvent dans
les sources primaires de Wikidata.

Quand ces bots sont prêts,

nous les écrivons

à l'aide d'une librairie Python
appelée « Wikidata Integrator »

qui est née de notre projet.

Une fois que nous avons nos bots,
nous utilisons une plateforme

appelée « Jenkins »
pour une intégration continuelle.

Avec Jenkins,

nous mettons sans arrêt à jour
les sources primaires dans Wikidata.

Voici un diagramme pour
le journal mentionné précédemment.

Ceci est notre environnement actuel.

Chaque boite orange est
une ressource primaire sur les drogues,

protéines, gènes, maladies,
composants chimiques avec interaction

et bien que ce modèle
soit trop petit pour être lisible,

voici la base de données, les sources
que nous traitons dans Wikidata

et connectons aux sources primaires.

Voilà le flux de travail.

Un de nos partenaires
est L'ontologie des Maladies

qui est une ontologie CC0 ;

celle-ci a son propre cycle de curation.

L'Ontologie des Maladies est
continuellement mise à jour

pour refléter l’espace maladie
ou l'interprétation des maladies.

Il existe le cycle de curation Wikidata
également sur les maladies

où la communauté Wikidata surveille
en permanence ce qui s'y passe.

Nous avons deux rôles

appelés familièrement
« gardien d'accès »

qu'un collègue et moi-même
assumions il y a cinq ans

où nous nous contentons de surveiller
Wikipedia et Wikidata sur nos ordinateurs

pour voir si un problème était
signalé à la communauté primaire,

dans quel cas ils examinaient
l'implémentation et décidaient :

« OK, pouvons-nous faire confiance
à cette entrée Wikidata ? »

Si oui, elle intègre le cycle

et la prochaine itération fait
alors partie de l'Oncologie des Maladies

et alimente Wikidata.

Nous faisons de même pour WikiPathways.

WikiPathways est inspiré du chemin
MediaWiki et du chemin répertoire.

De même, il y a déjà différents
chemins de ressources sur Wikidata.

Il peut y avoir des conflits
entre ces chemins de ressources

et ceux-ci sont signalés

à cette communauté
par les gardiens d'accès,

ce qui maintient les cycles
de conservation individuelle.

Mais si vous vous souvenez
du cycle précédent,

ici, je ne mentionne que
deux cycles, deux ressources,

nous devons faire cela pour
chaque ressource que nous avons

et nous devons gérer ce qui se passe

car quand je parle de « curation »,

je veux vraiment dire : consulter
les premières pages de Wikipedia

pour essayer de le faire.

Ce qui n'est pas faisable
pour nos deux gardiens d'accès.

Lors d'une conférence en 2016

où Eric a présenté Shape Expressions,

j'ai pris le train en marche
en disant : « OK,

Shape Expressions peut nous aider
à détecter les différences dans Wkikipedia

ce qui permettra aux gardiens d'accès
de faire un rapport plus efficace. »

J'ai été ravi par l'entité
schéma cette année

parce qu'on peut maintenant
stocker ces systèmes sur Wikidata

en elle-même, alors
qu'auparavant, c'était sur GitHub.

Et comme ceci s'aligne
sur l'interface Wikidata,

nous avons donc
des discussions de document,

mais aussi des révisions.

On peut donc tirer parti
des premières pages et des révisions

pour discuter du contenu de Wikidata

et celui des ressources primaires.

Ce que Eric vient de présenter
constitue déjà un bon bénéfice.

Ici, nous avons fait une Shape Expression
pour le gène humain

que nous avons soumise à un simple ShEx
et comme vous pouvez le voir,

nous avons déjà...

Un problème à surveiller

est quand un item
ne correspond pas à ce schéma,

vous pouvez créer déjà une sorte de
rapports de curation d'entités de schéma

et les envoyer aux différents
rapports de curation.

Mais le ShEx.js est
une interface construite,

voyez ici, je n'en fais que dix,

mais nous en avons des dizaines
de milliers, ce qui est démesuré.

À présent, le Wikidata Integrator
supporte aussi ShEx,

nous pouvons donc boucler
les circuits d'items

en disant : « Oui-Non, Oui-Non,
Vrai-Faux, Vrai-Faux ».

Cela augmente à nouveau

l'efficacité de la gestion des rapports.

Mais cela s'appuie
sur le Wikidata Query Service

et donc récemment,
nous nous voyons limités

à cause de ce manque d'ajustement.

Donc, la gestion des modèles sur Wikidata
est une procédure en cours.

ShEx est non seulement intimidant,

mais est d'une trop grande échelle
pour pouvoir le gérer.

J'ai donc commencé à travailler
avec un outil appelé « yED »

qui est ma première preuve
de concept ou exercice

en dessinant ces Shape Expressions

et en régénérant ce schéma

en ce format adjacent
des Shape Expressions

qui s'ouvrirait déjà à l'audience

qui est intimidée par
les langages Shape Expressions.

Mais il y a en fait un problème
avec des descriptions visuelles

car ce schéma a aussi été dessiné
dans yED par quelqu'un.

Il y en a un autre qui est splendide.

J'adorerais l'avoir sur mon mur,
mais il n'est pas encore interopérable.

Je voudrais donc clore mon discours

avec cette diapositive que
j'ai « empruntée » pour la première fois.

Nous sommes honorés
de l'avoir dans l'audience

et j'aime beaucoup ceci :

« Les gens pensent que RDF
est trop compliqué à utiliser.

La vérité est pire, c'est tellement simple

parce que vous devez travailler
avec des problèmes de données réels

qui sont horriblement compliqués.

Bien que vous pouvez éviter RDF,

il est plus dur d'éviter des données et
des problèmes d'ordinateur compliqués. »

On parle ici de RDF, mais je pense
que cela s'applique également au modelage.

Ce que je veux dire :

« Comment lancer la modélisation ? »

En discutant de ShEx ou
des modèles visuels ou autre...

Comment continuer ?

Merci de m'avoir écouté.

(applaudissements)

(Lydia) Merci beaucoup.

Pouvez-vous venir à l'avant

comme cela, nous pouvons
recevoir les questions de l'audience.

Il y a des questions ?

Oui.

Et pour la caméra, nous devrions...

(Lydia rit) Oui.

(Personne du public)
Une question pour Cristina.

Vous avez mentionné le terme
« gain d'information »

dans le cadre de connexion
avec d'autres systèmes.

Il y a une mesure théorique d'information

qui utilise statistique et probabilité
appelée « gain d'information ».

Avez-vous la même...

Parliez-vous de cette mesure,

du gain d'information
de la théorie de probabilité

de la théorie d'information

ou simplement d'un concept de mesure de
gain d'information d'une certaine façon ?

Non, nous avons en fait défini
et implémenté des mesures

qui utilisent l'entropie Shannon,
c'est à prendre dans ce sens.

Je ne voulais pas rentrer dans
les détails des formules concrètes...

(Personne du public) Non bien sûr,
c'est pour ça que j'ai posé la question.

Merci.

(Personne du public) C'est plus
un commentaire qu'une question.

(Lydia) Allez-y.

(Personne du public) Il y a eu beaucoup
d'attention au niveau de l'item

concernant la qualité et la complétion ;

ce qui me préoccupe est que nous ne
faisons pas de même pour les hiérarchies

et je crois que souvent,
notre hiérarchie n'est pas bonne.

Nous prévoyons que
cela va être un réel problème

avec la recherche des communs et autre.

Ce que nous pouvons faire
est importer de l'externe.

La façon dont les thésaurus externes
structurent leurs hiérarchies

en utilisant le qualificateur
de concept plus large P4900.

Mais ce qui serait plus utile
serait l'emploi de meilleurs outils

afin d'importer une hiérarchie
de thésaurus externe.

Incorporons ça dans nos items Wikidata.

Une fois que ces qualificateurs
P4900 sont en place,

vous pouvez faire de
la bonne requête avec SPARQL

pour voir si notre hiérarchie
diverge de cette hiérarchie externe.

For exemple, vous savez peut-être
que [Paula Morma], utilisatrice PKM

travaille beaucoup dans la mode.

Nous utilisons cela pour extraire la
hiérarchie du Europeana Fashion Thesaurus

et celle du thésaurus de mode Getty AAT

et nous voyons alors où sont
les espaces dans nos items haut niveau,

ce qui représente pour nous
un vrai problème car souvent,

ce sont des choses qui n'existent que
dans les pages de désambiguïsation,

ce qui fait que de nombreux articles de
haut niveau manquent dans nos hiérarchies,

c'est un problème que nous devons adresser
en termes de qualité et de complétion,

mais ce qui aiderait vraiment,

ce sont de meilleurs outils que
la jungle de scripts que j'ai écrits...

Si quelqu'un pouvait entrer cela
dans un notebook PAWS dans Python,

afin de prendre la hiérarchie
d'un thésaurus externe,

ce qui pourrait être disponible
en tant que données couplées ou pas,

et ensuite, de les placer dans les valeurs
P4900 en relevés rapides.

Et après,

quand notre représentation se complète,
mettre ces P4900 à jour,

parce qu'au fur et à mesure que
nos représentations deviennent obsolètes,

deviennent plus denses,

les valeurs de ces qualificateurs
doivent changer

pour représenter le fait qu'on ait plus
de leur hiérarchie dans notre système.

Si quelqu'un savait faire cela,
ce serait très utile.

Nous devons aussi
envisager d'autres approches

pour améliorer la qualité et
la complétion au niveau hiérarchique

et non simplement au niveau item.

(Andra) Je peux ajouter quelque chose ?

Oui, on fait déjà cela

et je recommande de regarder
la Shape Expression faite par Finn

avec les données lexicales
où il crée des Shape Expressions

et s'appuie sur les expressions d'auteur

pour obtenir un concept de
Shape Expressions liées dans Wikidata

et spécifiquement, si je comprends bien,

le cas d'utilisation est exactement
ce que l'on fait dans Gene Wiki.

Vous avez donc l’Ontologie de Maladies
placée dans Wikidata

et quand les données de maladie arrivent,
nous appliquons les Shape Expressions

pour voir si cela correspond
à ce thésaurus.

Il y a d'autres thésaurus et ontologies
pour les vocabulaires contrôlés

qui doivent toujours intégrer Wikidata

et c'est exactement pour cette raison
que Shape Expression est si intéressante

parce qu'on peut en avoir une
pour l'Ontologie de Maladies,

pour MeSH,

on peut dire : « OK, je veux
maintenant vérifier la qualité. »

Parce que dans Wikidata,
on aussi le contexte

où dans le cas d'un vocabulaire contrôlé,
vous décidez de la qualité en fonction de,

mais votre communauté
peut ne pas être d'accord.

L'outillage est donc en place,
il faut maintenant créer ces modèles

et les appliquer aux différents
cas d'utilisation.

(Personne du public)
La Shape Expression est très utile

une fois que l'ontologie externe
est cartographiée dans Wikidata,

mais mon problème est

de figurer l'ontologie externe
qui n'est pas déjà présente dans Wikidata

et de situer les espaces ;

et c'est là que le fait
d'avoir des outils plus robustes

pour voir les parties manquantes
des ontologies externes

devient très utile.

Le plus grand problème

est non pas l'outillage,
mais les licences.

Mettre les ontologies dans Wikidata
est en fait un jeu d'enfant,

mais la plupart des ontologies ont...
comment dire ça poliment,

...des licences restrictives et donc,
non compatibles avec Wikidata.

(Personne du public) Il y a un grand
nombre de thésaurus de secteur public

dans les champs culturels.

- (Andra) On doit alors en discuter.
- (Personne du public) Pas de soucis.

(Andra) On doit en parler.

(Personne du public) Mon commentaire
est en fait une réponse à James.

Les hiérarchies font des graphes

et quand tu veux...

Je veux dire que le problème
commun des hiérarchies

sont les hiérarchies circulaires,

elles reviennent l'une vers l'autre
quand il y a un problème,

ce qui ne devrait pas arriver.

Curieusement, cela arrive fréquemment
dans les catégories de Wikipedia,

elles sont souvent circulaires,

mais la bonne nouvelle est que...

Techniquement, c'est impossible à trouver
car c'est un problème complet PMP

et facile si on construit
un graphe à cet effet.

Mais il y a de nombreuses manières
qui ont été développées

pour trouver les problèmes
dans ces graphes hiérarchiques.

Comme ce document
appelé « Finding cycles...

Breaking cycles in Noisy Hierarchies »

qui a été utilisé pour aider
la catégorisation de Wikipédia Anglais.

On peut appliquer cela
aux hiérarchies dans Wikidata

et ensuite, trouver
ce qui est problématique

et supprimer les causeurs de trouble

et trouver les problèmes.

C'est juste une idée pour vous...

(Personne du public)
Tout cela est bel et bien,

mais je crois que vous sous-estimez

le nombre de relations défaillantes
entre les sous-classes que nous avons.

C'est comme avoir
une ville dans le mauvais pays

et il existe des outils
géographiques pour cela.

Nous devons avoir de bien
meilleurs outils en hiérarchies

pour identifier l'item manquant

ou s'il a été en fait sous-classé

à un élément qui ne veut pas dire
quelque chose de tout à fait différent.

(Lydia) Je pense que
tu as mis le doigt dessus.

Mon équipe et moi-même
avons les mêmes retours des gens

qui réutilisent nos données ;

Un point de donnée
individuel peut être intéressant,

mais s'il faut examiner l'ontologie, etc.,

cela devient très...

Je pense qu'un des grands problèmes
pourquoi cela se produit

est que nombreuses éditions dans Wikidata

s'effectuent sur base
d'un élément individuel,

on modifie cet item

sans réaliser que cela peut avoir
des conséquences globales

sur le reste du graphe, par exemple.

Si les gens avaient des idées
sur comment rendre plus visibles

les conséquences d'une modification
locale individuelle,

il faudrait prendre la peine
de les explorer

pour mieux montrer aux gens

quelles sont les conséquences
de leur édition,

même si celle-ci est de bonne foi.

Commençons par ici,
oui, vous, puis vous et vous et vous !

(Personne du public) Après la discussion,

simplement pour exprimer
mon accord avec James.

Il semble que la chose
la plus dangereuse est la hiérarchie,

pas la hiérarchie, mais en général,

les sémantiques des relations
entre sous-classes dans Wikidata,.

J'ai récemment étudié les langages
en vue de cette conférence

et par exemple, vous trouvez plein de cas

où le langage fait partie
des sous-classes.

On peut alors dire
qu'on a une ontologie flexible.

Parfois, Wikidata vous donne
cette liberté d'expression.

Parce que par exemple,

cette ontologie de langages est
aussi politiquement compliquée, pas vrai ?

Il est même bon d'être en position
d'exprimer un niveau d'incertitude.

Mais imaginez quelqu'un qui veut faire
de la lecture automatique à partir de ça.

C'est vraiment problématique.

Et de nouveau,

je ne pense pas que cette ontologie
a été importée de quelque part

c'est quelque chose qui
originairement nous appartient.

Je dirais que c'est récolté
de Wikipédia au tout début.

Donc, je me demande...
Cette Shape Expressions est super

et le fait de valider et rectifier
l'ontologie Wikidata

par des ressources externes, belle idée.

À la fin,

terminerons-nous en réfléchissant sur
les ontologies externes dans Wikidata ?

Et aussi, à ce que nous faisons avec
la partie centrale de notre ontologie

qui n'est jamais récoltée
de ressources externes,

comment résoudre cela ?

Et je pense que ce sera
un problème en soi.

Nous devrons nous concentrer
sur cela indépendamment du fait

de valider l'ontologie
avec un élément externe.

(Personne du public) Les contraintes
et formes ainsi que leurs usages

sont vraiment impressionnantes,

mais le point principal n'est pas clair

car nous pouvons maintenant rendre
nos attentes des données plus explicites.

Avant, chacun devait écrire
ses propres outils et scripts

pour qu'ils soient plus visibles
et accessibles de discussion.

Mais il ne s'agit pas
de ce qui est juste ou non,

il s'agit d'une attente

et il y aura différentes
attentes et discussions

sur comment modeler dans Wikidata

et ceci...

L'état actuel est simplement
un pas dans la direction

parce qu'à présent,

il faut une grande expertise technique
pour s'impliquer

et nous devons avoir de meilleurs moyens
pour visualiser cette contrainte ;

de peut-être la transformer en un langage
naturel pour une meilleure compréhension,

il ne s'agit pas de juste ou faux.

(Lydia) Oui.

(Personne du public)
Concernant les problèmes de qualité,

j'ai trouvé que nombreux problèmes
que j'ai rencontrés consistaient

en une différence d'opinion entre
« instance de » comparé à « sous-classe ».

Dans ces situations, je dirais
que ce sont des « erreurs »

et les trouver est
une procédure chronophage.

Ce que j'ai trouvé est : « Oh, si
je trouve des articles de haute qualité

qui sont...

pour ensuite utiliser toutes les instances
sous-classe et leurs relevés dérivés »,

c'est une manière utile
de chercher ces erreurs.

Mais je me demandais si Shape Expressions,

s'il y a...

si elle peut être utilisée comme outil
pour aider à résoudre ces problèmes...

(Personne du public)
S'il y a une empreinte structurée

que l'on peut...
qui est en sorte falsifiable,

on peut l'examiner et
reconnaître qu'elle est fausse,

alors oui, on peut le faire.

Mais si c'est pour l'associer
à des objets réels,

cela va demander beaucoup de cerveaux.

Bonjour, je suis Pablo Mendes
de Siri Knowledge de Apple.

Nous sommes ici pour découvrir
comment aider le projet et la communauté,

mais Cristina a commis l'erreur
de nous demander ce qu'on voulait.

(rire) Une des choses que j'aimerais voir,

c'est attacher de l'importance
à la vérifiabilité

qui est un des principes essentiels
du projet dans la communauté

ainsi que la fiabilité.

Tous les énoncés ne sont pas identiques,
certains d'entre eux sont très disputés,

certains d'entre eux
sont faciles à deviner

comme une date de naissance
qui peut être vérifiée,

mais comme vous l'avez vu dans Keynote,
la question de genre est plus compliquée.

Pouvez-vous nous parler davantage
de ce que vous savez au sujet

de la qualité de données
concernant la fiabilité et vérifiabilité ?

Et si ce n'est pas grand-chose,
j'aimerais en savoir plus. (rire)

(Lydia) Oui.

Apparemment, il n'y a
pas grand-chose à dire. (rire)

(Andra) Je pense que nous pouvons faire
beaucoup et j'ai discuté hier avec vous.

Mon exemple favori d'hier
qui est déjà obsolète

est que si vous allez
sur Q2 qui est la terre,

il y a une déclaration qui dit
que la terre est plate.

J'adore cet exemple

parce qu'il existe une communauté
qui déclare cela

et ils possèdent des sources vérifiables.

Je pense que ce cas est véritable,

qu'il ne devrait pas être déprécié
et devrait être dans Wikidata.

C'est une circonstance où
Shape Expressions peut être décisif

parce que vous pouvez dire

que vous êtes vraiment
intéressé par ce cas d'utilisation,

ou il se peut que
vous ne soyez pas d'accord,

mais ce cas d'utilisation pourrait
également vous intéresser.

Il y a aussi cet exemple
où vous dites que vous avez du glucose.

Mais quand vous êtes biologiste,

vous ne vous souciez pas des contraintes
chimiques de la molécule de glucose,

tout est pareil en ce
qui concerne le glucose.

Mais si vous êtes chimiste, vous grincerez
des dents en entendant cela,

vous avez 200...

Vous pouvez alors avoir
des Shape Expressions multiples,

d'un point de vue chimique,

j'appliquerai cela.

Mais d'un point de vue biologique,

j'appliquerai cette Shape Expression.

Et quand vous voulez collaborer,

parlez plutôt à Eric des cartes ShEx.

Mais cette aventure ne fait que commencer.

Et personnellement, je pense qu'il y aura
un rôle à jouer dans ce domaine.

(Lydia) OK. Ici.

(rire)

(Personne du public) J'ai eu plusieurs
idées en entendant les discussions,

je vais essayer de ne pas les perdre.

Basé sur ce que James a dit auparavant,

depuis le début, nous avons
un très gros problème dans Wikidata

pour l'ontologie supérieure.

Nous en avons parlé il y a deux ans
lors de WikidataCon

et nous en avons parlé à Wikimania.

Chaque fois que nous avons
une réunion Wikidata,

nous en parlons

car c'est un très gros problème
de tout premier abord ;

quelle est l'entité,quel est le travail,
quel est le genre, l'art,

ce sont les plus grands concepts.

Et c'est en fait un point très faible
de l'ontologie globale

parce que les gens essaient
de nettoyer régulièrement

et finissent par tout casser ;

je pense que certains se souviennent
peut-être du gars qui candidement,

a cassé toutes les villes du monde.

On n'était plus des items géographiques,
donc contraintes de violation partout.

Et c'était de bonne foi

parce qu'il apportait vraiment
une correction à un article,

mais tout s'est écroulé.

Je ne sais pas trop comment résoudre cela

parce qu'il n'existe pas
d'institution externe à copier

car tout le monde travaille sur...

Si je suis la base de données
d'art performant,

j'irai simplement à
l'étiquette d'art performant,

je n'irai pas sur le concept
philosophique de ce qu'est une entité

et c'est en fait...

Je ne connais aucune base de données
qui travaille à ce niveau,

mais ça, c'est le point
le plus faible de Wikidata.

Et il est probable que quand
nous parlons de qualité de données,

cela en constitue
une grande partie, donc...

Et c'est ce que nous avons
aussi mentionné dans...

Désolée, je change de sujet,

mais dans différentes sessions
concernant la qualité, nous avons remarqué

que certains d'entre nous
font un bon travail de modélisation,

de ShEx et autres choses.

Les gens ne voient pas ça dans Wikidata,
ils ne voient pas le ShEx,

ils ne voient pas le WikiProject
sur la page de discussion

et parfois,

ils ne voient même pas
les pages de discussion des propriétés

qui dit clairement :
a) cette propriété est utilisée pour cela.

La semaine dernière, j'ai ajouté
des contraintes à une propriété.

La contrainte était écrite explicitement

dans la discussion
de la création de la propriété.

J'ai juste créé la partie technique
d'ajout de contrainte et quelqu'un :

« Quoi ! Tu as cassé
toutes mes modifications ! ».

Et il se fait qu'il utilisait la propriété
incorrectement depuis deux ans.

Et celle-ci était en fait très claire,
mais il n'y a eu aucun avertissement ;

et c'est pareil pour Pink Pony,
nous avons dit à Wikimania

de rendre plus visible
le WikiProject ou ShEx, mais...

Et c'est ce qu'a dit Cristina.

Nous avons un problème de visibilité
concernant les solutions existantes.

Dans cette session,

nous parlons tous de
comment créer plus de ShEx

ou de faciliter les tâches
des gens qui font le nettoyage.

Mais depuis le premier jour de Wikidata,
nous nettoyons

et globalement, nous sommes
en train de perdre la partie parce que

je sais que les noms sont compliqués,

mais je suis la seule à nettoyer,

celui qui a ajouté le nom scripté latin

à tous les chercheurs chinois,

cela me prendra des mois pour nettoyer
et je ne peux pas le faire seule,

et de plus, il a fait un lot énorme.

Nous avons vraiment besoin...

Notre problème de visibilité est
plus important de celui des outils

car nous avons de nombreux outils.

(Lydia) Malheureusement,
on me fait signe (rit),

nous devons donc terminer.

Merci à tous pour vos commentaires.

J'espère voir la discussion se prolonger
au cours de la journée

et merci pour votre contribution.

(applaudissements)