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)