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)