Skip to content

La confiance dans les données et la structure de Wikidata

11/04/2016

Statistiques en RDF ?

Il y a quelque temps, je me suis intéressé à la mise en RDF de données statistiques, dont la faisabilité me laissait perplexe.
En effet, quand on veut dire qu’une Université a 26.000 étudiants, il suffit de trouver la propriété adéquate (ou de l’inventer) puis on génère le triplet.

billetWikidata-schema1

Et voilà.

Mais comment fait-on ensuite pour préciser que cette valeur est vraie pour la période 2015-2016 ? Je ne peux pas ajouter une propriété à la chaîne de caractères « 26000 ». Il est impossible d’écrire :

billetWikidata-schema2

car le sujet d’un triplet doit être une URI (sinon, il faudrait imaginer que cette affirmation ci-dessus est vraie pour toute occurrence du nombre 26000, dans n’importe quel contexte – enfin bref, ça ne veut rien dire)

Les sources dans Dbpedia ?

A un autre moment, je m’interrogeais sur la perte d’informations dans DBPedia, par rapport à Wikipedia. En effet une des grandes critiques faites à Wikipedia est de dire qu’elle est écrite par des amateurs, que les données n’y sont pas fiables, etc. (cf. encore ce billet récent d’Emilien Ruiz sur Wikipedia en Licence).

Et la manière qu’a eu la communauté des wikipédiens de répondre a été de réclamer des sources : Wikipedia doit s’appuyer sur des documents publiés, et les citer pour que les informations dans les articles puissent être contrôlées par leurs lecteurs.

billetWikidata-schema3

Or cette pratique de la citation se perd dans Dbpedia : ce sont les « faits bruts » qui y sont récupérés. Comme si, une fois les données de Wikipedia versées dans Dbpedia, les faits recensés devenaient strictement objectifs.
C’est d’autant plus embarrassant que c’est contradictoire : une fois mise en triplets déréférençables, l’information ne peut plus être déréférencée (le triplet n’a pas lui-même d’URI propre, donc ne peut faire l’objet d’assertions).

Les sous-champs dans les notices Marc

Je vais prendre un dernier exemple, pour vous montrer combien ce sujet vous concerne (vous, bibliothécaire).
Mettre en RDF une notice MARC est assez compliquée (pour le faire d’une manière  intellectuellement – et non seulement techniquement – satisfaisante) : comment rendre compte du fait que deux sous-champs s’appliquent au même champ ?

Ainsi si vous avez une notice avec un indice Dewey (zone 676$a en Unimarc), le sous-champ $v vient préciser la version Dewey utilisée. Et rien n ’empêche que deux champs distincts indexent l’ouvrage selon deux indices différents de deux versions différentes de la Dewey.
A la valeur de la CDD « 850.3 » (chaîne de caractères) il faut donc pouvoir ajouter l’information : « d’après la Dewey version 22 »).

676 $a850.3$vv. 22

Le principe : une URI supplémentaire

La solution devient au bout d’un moment assez évidente, même si elle peut sembler un peu lourde au premier abord : on a besoin de générer une étape intermédiaire dans le graphe.

Au lieu de

billetWikidata-schema1

on aura

billetWikidata-schema4

On peut donc ainsi ajouter d’autres informations pour qualifier cette « affirmation » (ou statement dans Wikidata). Par exemple sa source.

billetWikidata-schema5

Une autre manière de procéder aurait pu être la réification du triplet initial. C’est-à-dire utiliser un système qui permette de considérer le triplet

http://mon-univ.fr lully:nombreEtudiants "26000"

comme un objet auquel ajouter des propriétés. Mais la réification est souvent considérée comme un écart par rapport aux principes « stricts » (ou purs ?) du modèle RDF.

Comment réifier un triplet : on lui attribue une URI par lequel le désigner — le triplet devient ainsi quadruplet. On verra peut-être cela une autre fois.

Et donc, concrètement, dans Wikidata ?

Dans Wikipedia, la ressource qui structure l’encyclopédie est la page : celle du joueur de foot, d’un événement militaire ou d’un concept théologique.

Dans Wikidata, tout se structure autour des statements (ou affirmations).

(à noter que dans Wikipedia, les ressources ont un identifiant de type "Romain_Gary". Wikidata est multilingue, alors que chaque Wikipedia a une langue propre. L’identifiant des ressources dans Wikidata sont donc numérotées sous la forme Q986962. De même, les propriétés ne sont pas sous la forme "wikidata:nombreEtudiants" ou "wikidata:numberOfStudents", mais "wikidata:P2196".)

billetWikidata-schema6

 

Et le truc particulièrement sympa dans la structuration des données de Wikidata, c’est que parfois on se contrefout d’avoir la source — et c’est prévu. Grosso modo, si je veux récupérer la rapidement la liste des souverains des différents pays d’Europe, avec leurs dates de règne, de naissance et de mort, je sais que les données de Wikidata ont de fortes chances d’être bonnes, sans qu’il y ait besoin de vérifier chaque donnée.

Donc pour chaque souverain j’aimerais la propriété « Date » directement, et pas un statement qui me donne cette date avec la source de l’information. Et pour ça, Wikidata propose les propriétés en double :

Dans le SPARQL Endpoint de Wikidata, on peut donc au choix récupérer des valeurs directes (avec des propriétés dont l’URI commence par <http://www.wikidata.org/prop/direct/&gt;) ou les affirmations avec toutes leurs propriétés : source, date de validité, etc.

Ça simplifie considérablement la requête à écrire, lorsqu’on n’a pas besoin de passer par le statement pour récupérer la valeur souhaitée.

Plus de précisions sont données dans cet article [PDF – anglais – 16 p. – 2012]. Merci à Gautier pour ses explications (encore une fois !)

Ce qui me chiffonne un peu quand même… (mais peut-être parce que je n’ai pas tout compris)

Prenons un autre exemple : la page Wikidata de Beyoncé (Knowles). Elle s’est mariée lors d’une cérémonie assez confidentielle avec Jay Z. Voici le statement Wikidata.

Beyoncé

On apprend donc que la donnée est importée de la Wikipedia anglophone. C’est bien.

Mais dans la Wikipedia anglophone, cette information elle-même a une source :

beyonce_footnote

Et évidemment c’est bien l’article ici cité qui doit être considéré comme la source de l’information concernant le mariage de Beyoncé et Jay Z — et non Wikipedia, qui n’est qu’une source secondaire ou tertiaire, un moyen d’accéder aux sources primaires.

Bref, la structure des données dans Wikidata prévoit la mention des sources, mais celles-ci ne sont pour l’instant pas alimentées de manière extrêmement satisfaisantes. J’ignore si une récupération automatique d’au moins une partie des références (notes de bas de page) des différentes Wikipedia est une chose techniquement possible…

Les sources : une question de confiance

Wikidata s’efforce clairement dans sa structuration d’apporter une réponse à la question de la confiance, posée dès le début dans le schéma directeur du déploiement du web de données (je ne suis pas sûr que ce soit la bonne désignation de ce fameux schéma, mais c’est à peu près l’idée).

Semantic Web Layer Cake – source : https://www.w3.org/2001/sw/

Fournir la source d’une donnée, c’est permettre de vérifier qu’entre le moment où on la récupère et le moment où elle a été produite, rien n’est venu la modifier ou la travestir.

Ça ne garantit évidemment pas que l’information soit correcte. Ainsi, dans Wikidata Romain Gary (mort en 1980) se voit attribuer un site web officiel. Source de cette information : la Wikipedia russe (et elle seule). Mais en fournissant les sources pour des informations contradictoires, on offre notamment plusieurs possibilités :

  • choisir entre plusieurs infos en fonction de leur source, bien sûr
  • considérer qu’une info est d’autant plus fiable qu’elle est relayée par plusieurs sources
  • calculer une note de confiance en fonction du caractère erroné d’informations venant d’une même source (peut-être que la Wikipedia russe donne de nombreuses informations justes, mais moins fiables, du moins dans certains domaines, que d’autres Wikipedia).

Concernant la confiance, peut-être y aura-t-il dans les prochaines années des expérimentations autour de la technologie des blockhains. Le principe de la citation des sources consiste à pouvoir, en bout de chaîne d’information, vérifier la conformité entre la donnée finale et la donnée initiale. Celui des blockchains (si j’ai bien compris) permet de garantir qu’à aucun moment de la chaîne de traitement la donnée n’a été modifiée (donc pas besoin, d’une certaine manière, de revenir à la source). Cette technologie n’a rien à voir avec le linked data, mais on commence déjà à se poser des questions sur son apport en matière documentaire. Alors pourquoi pas…

 

9 commentaires
  1. doccg78 permalink
    11/04/2016 15:44

    bonjour cher collègue,

    pour clarifier le problème du sourçage de wikidata…

    en fait, beaucoup de données ont été importées depuis les infobox de wikipedia, et donc sans lien direct avec les sources citées par wikipédia.
    Donc beaucoup de Statements ont des sourçage de type « wikipédia en telle langue ». Il s’agit d’une première étape de sourçage, qui devrait permettre de reprendre ensuite les sources citées par wikipédia, comme je l’ai fait pour Beyoncé, mais cette étape étant extrêmement longue, elle se fait dans un 2e temps, petit à petit, des outils de travail étant en cours de mise en place pour faciliter le sourçage complet de chaque information.

    Le but est, bien entendu, de sourcer complètement chaque statement… mais ça prendra du temps, car l’info est structurée dans wikidata, pas dans wikipédia, ce qui impose généralement une étape de reprise manuelle individuelle des sources ….

    N’hésite pas à contribuer, à l’occasion, comme pour ce cas.

    très cordialement,

  2. 11/04/2016 18:46

    Merci beaucoup pour cet article qui pose bien l’enjeu de la qualification des données publiées dans le LOD – où on en effet l’approche de Wikidata est particulièrement séduisante – et qui évoque la question des références d’import de Wikipédia très présentes encore sur Wikidata.

    Juste pour le jargon Wikidata, « statement » est généralement traduit par « déclaration », « affirmation » correspondant plutôt à « claim » en anglais. Bref, un schéma en français https://commons.wikimedia.org/wiki/File:Wikidata_statement_fr.svg et sa correspondance en anglais https://commons.wikimedia.org/wiki/File:Wikidata_statement.png

    Concernant les références, pourquoi en effet ne pas pouvoir avoir directement la référence de la source d’import plus que le nom de la Wikipédia ?

    [Petit historique complétant doccg78] Le choix pour Wikidata a été fait de partir d’éléments vierges. Le remplissage s’est d’abord fait pour une large avec des imports massifs depuis les Wikipédias (pas seulement, l’édition humaine y a aussi une part essentielle, ne serait-ce que dans tout ce qui n’est automatisable, le comblement des manques ou l’élaboration de nouvelles structurations) fait par les contributeurs avec des outils semi-automatiques ou automatiques. Cela répond à un degré de contrôle par rapport à un autre choix qui aurait pu être de remplir d’emblée automatiquement avec toutes les données disponibles et de corriger après. Les bots qui œuvrent à ces versements massifs doivent être validés, leur travail est surveillé et si nécessaire suspendu, corrigé, repris. Permettre des imports depuis les Wikipédias était un choix évident dont il aurait été dommage de se priver puisque Wikidata gérant les interwikis, les alignements sont natifs et Wikipédia contient des données structurées avec les infobox et les catégories. Ainsi on a eu des imports massifs, souvent par domaine ou par propriété, avec des périmètres bien définis. Aujourd’hui on perçoit certaines limites de ces imports, comme c’est judicieusement relevé dans l’article. Toutefois passer par là a permis d’atteindre une masse critique de déclarations et donner un fort intérêt à Wikidata. C’était un choix pragmatique, qui se révèle a posteriori tout à fait pertinent : avoir une dynamique de contribution avec des contraintes modérées sur les références.

    Aujourd’hui, bien qu’encore jeune, Wikidata a bien grandi et s’est bien rempli au point que l’on est passé dans certains cas de rien à des affirmations contradictoires (un exemple croisé tout récemment https://www.wikidata.org/wiki/Q151290#P582 ), et que l’importance de références précises s’affirme toujours plus. Les bots qui œuvrent veillent désormais systématiquement à tenir compte des déclarations déjà présentes. [/Petit historique]

    Alors est-ce possible d’importer automatiquement les références depuis Wikipédia ? Pas encore à ma connaissance et certains l’ont encore demandé récemment https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Improve_bot_policy_for_data_import_and_data_modification#Bots_importing_from_wikipedia_should_wherever_possible_attempt_to_extract_the_original_source . Par ailleurs et pour répondre à ce besoin de référence sur les affirmations existantes, certains ont lancé des bots pour en ajouter et ainsi la date de naissance de Victor Hugo a 4 références https://www.wikidata.org/wiki/Q535#P569 . On peut aussi évoquer ce qu’a produit Addshore : un outil pour favoriser l’édition automatique de références à partir de microdata http://addshore.com/2015/12/wikidata-references-from-microdata/

    Un dernier paradoxe, il manque énormément de références aux affirmations de Wikidata et pourtant le projet est également en train de devenir un important agrégateur de références structurées.

  3. 12/04/2016 08:27

    @doccg78 et @shona_gon : merci beaucoup pour les compléments d’information. Pour ma part, j’ai découvert Wikidata un peu tardivement, en ayant longtemps du mal à le distinguer de DBPedia. Et ce n’est qu’en écrivant ce billet que je me suis attardé sur la structure, et sur la compréhension du projet (compréhension très incomplète encore, vous vous en êtes bien rendus compte).
    Donc si je résume, DBpedia est un export RDFisé de Wikipedia quand c’est possible, avec une DBpedia par Wikipedia.
    Et Wikidata est un wiki, donc alimenté de manière collaborative (grosse différence entre les deux : il y a un bouton « Edit » !), traitant toutes les langues, et initialisé avec les données de Wikipedia. Et maintenant, au boulot tout le monde🙂

    J’en profite pour signaler la requête élaborée par @sboissel pour afficher la liste des lieux où se tiennent des #NuitDebout (version avec commentaires par moi ici — sans erreur, j’espère).
    Plein d’illustrations intéressantes d’une requête SPARQL dans le sparql Endpoint de Wikidata. Notamment : la première ligne (option « affichage carto ») et l’avant-dernière (traduction simple des labels). Et l’info-bulle quand on passe la souris sur une propriété mystérieuse comme p:P276 ou une entité comme wd:Q23725830.

  4. B. Majour permalink
    19/04/2016 14:21

    Bonjour Lully

    « En effet, quand on veut dire qu’une Université a 26.000 étudiants, il suffit de trouver la propriété adéquate (ou de l’inventer) puis on génère le triplet. »

    Ce n’est pas aussi simple que ça.
    Quand on construit un arbre informatique (ou une base de données), il faut d’abord étudier quelle est la racine la plus profonde.

    Dans ton cas, tu vises directement le nombre d’étudiants, mais en regardant mieux tu t’apercevras que ce nombre d’étudiants fluctue avec le nombre des années. Il n’est pas constant.
    Idem, en l’an 1000, ton université n’existait peut-être pas.

    Si tu pars de la date (racine la plus profonde), tu obtiens

    Année ====> université ====> nb d’étudiants

    Qui est valable pour toutes les universités

    Ce qui pourrait donner le triplet suivant

    Année ==== (Promotion de l’université X) ====> nb d’étudiants

    Un triplet qui peut se lire dans un sens… et dans l’autre.

    En 2015 – à la promotion de l’université X – il y avait 26 000 étudiants.
    Il y avait 26 000 étudiants – à la promotion de l’université X – en 2015

    Et peut-être même dans tous les sens.
    C’est ce qui fait sa force.

    Tiens, je te partage ce que j’entrevois à l’instant.
    Tout triplet est comme un triangle (chaque élément est sur une pointe du triangle) avec dans l’idée que chaque pointe du triangle est prête à se connecter à un nouveau triangle, qui lui présente la même pointe (exemple : la même année).

    Sans réflexion hiérarchique qui va générer des liens forts entre les éléments, ta base de données va vite s’empâter, gonfler au risque de devenir incohérente.

    Mais pour réfléchir hiérarchique, il faut monter au cas le plus généraliste possible = Creuser la racine la plus profonde.

    En 2015…
    ——— de (1 à n) promotions d’universités
    ——————————– vont recevoir de (0 à n) étudiants.

    C’est ce qui se passe au niveau national. 🙂

    Bien cordialement
    B. Majour

  5. 24/04/2016 00:34

    Pas de rapport direct, mais tu as vu la structure de données utilisée par le projet Symogih pour sourcer les informations « atomiques »? http://symogih.org/?q=information-record/106106
    Il y a apparemment pas mal de projets de ce type en histoire

Trackbacks

  1. La confiance dans les données et la stru...
  2. La confiance dans les données et la stru...
  3. La confiance dans les données et la structure de Wikidata – Veille juridique
  4. La confiance dans les données et la stru...

Les commentaires sont fermés.

%d blogueurs aiment cette page :