Jump to content

User:Jumtist/exploration wikibase

From mediawiki.org

Retours d'exploration Wikibase 2019

[edit]

Ce document mi-généraliste mi-technique est un retour d'expérience effectué par Maxlath et Jumtist. Il propose des explications non-exhaustives de certaines fonctionnalités majeures de Wikibase comme la recherche, les contraintes ou les groupes, avec également des détails sur la configuration et l'administration des services via l'image wikibase-docker.

Il s'adresse aux personnes qui souhaitent en savoir plus sur les possibilités pour charger et éditer des données dans un service Wikibase. Ce document n'a pas vocation a être une documentation officielle. Les fonctionnalités décrites ici en 2019 sont issues de la version 1.33 de Wikibase et ont vocation à évoluer, ainsi les descriptions ci-dessous peuvent devenir obsolètes avec le temps.

Définitions

[edit]

Wikidata : lancé en 2012 avec pour mission initiale d'être une base de données structurées au service des autres projets Wikimédia, Wikidata a progressivement étendu cette mission pour en intégrer d'autres, notamment en devenant un centre pour bases de données de part le web (lire: Wikidata: The New Rosetta Stone). Wikidata n'est donc pas une base de données d'autorité mais une base de données secondaire. Dans l'idéal, chaque déclaration doit être associée aux sources qui la supporte, en connection avec d’autres bases de données. Wikidata utilise Wikibase pour implémenter son service.

MediaWiki : MediaWiki est un logiciel libre de wiki aux fonctionnalités riches, et pouvant soutenir une forte charge. Le développement de MediaWiki est supervisé par la fondation Wikimedia. MediaWiki est principalement écrit en PHP, complété par du JavaScript pour gérer les interactions dans le navigateur. MediaWiki sauvegarde ses données dans une base de données MySQL et s'appuie sur une autre base de données (ElasticSearch) pour effectuer des recherches.

Wikibase : Wikibase est une extension du logiciel MediaWiki qui permet de créer, gérer et partager des données structurées de manière collaborative. Wikibase a été initialement créé pour les besoins de Wikidata. Son développement est supervisé par Wikimedia Deutschland, le chapitre allemand de Wikimedia. Comme toute extension MediaWiki, Wikibase est principalement écrit en PHP et JavaScript. Tout comme MediaWiki, Wikibase peut être lu et écrit soit via l'interface graphique dans le navigateur, soit de manière programmatique via l'API. L'API est le moyen primaire d'extraire des données de Wikibase mais est limité pour tout ce qui concerne les relations entre entités, d'où le besoin de compléter cette API par un Query Service.

Spécificité du modèle : Par rapport à d'autres modèles de données structurée, Wikibase se distingue par les concepts suivants, attribuables à chaque déclaration :

Les extensions : MediaWiki possède un éventail d'extensions qui le rend hautement paramétrable. Si l'extension possède une partie graphique, elle est souvent accessible par une page spéciale. Wikibase est aussi une extension de Mediawiki, mais qui organise bien plus qu'une page spéciale. Cette architecture d'extension permet à Wikibase de bénéficier des nombreuses fonctionnalités de collaboration de MediaWiki, notamment la conservation d'un historique des modifications.

Configuration : La configuration de Wikibase s'effectue principalement via le fichier LocalSettings.php. Il permet notamment d'installer les extensions, de configurer les groupes utilisateurs, de définir les espaces de nom, etc. Une sélection des configurations des projets Wikimedia est disponible, on y trouve notamment la configuration de Wikibase, qui devrait être très proche de la configuration de production de Wikidata.

Installation Docker

[edit]

Cette exploration a permis d'implémenter l'image Docker proposée par Wikimedia Deutschland wmde/wikibase-docker. L'utilisation de Docker nécessite un certain temps d'apprentissage et ajoute une certaine complexité. Il est possible de se passer de cette couche logicielle. Nous pensons néamoins que la valeur apportée par l'usage de Docker est supérieure à son coût en complexité.

Quelques liens sur wikibase et docker :

Bon à savoir :

  • Ne pas oublier de définir la variable $wgServer dans la config, sinon wdqs-updater qui utilise la même image que le container wikibase ne saura pas qui est qui.
  • Par défaut, les Dockerfile iront toujours télécharger la dernière version en date sur les repo, ce qui peut poser quelques problèmes à certain.e

L'image docker installe notamment les services suivants :

  • MediaWiki
  • Query Service : un service fait de plusieurs composants :
    • une interface graphique (initialement nommé wikidata-query-gui, nommé wdqs-frontend dans wmde/wikibase-docker)
    • Blazegraph : base de données dérivées des données primaires, optimisé pour les requêtes par graphe de données, via le langage SPARQL
    • un serveur Nginx utilisé pour restreindre les droits d'accès à BlazeGraph -- autrement très permissif -- et servir les fichiers HTML, CSS et JS de l'interface graphique
    • wdqs-updater : un programme chargé de demander régulièrement à Wikibase la liste des changements récents pour tenir la base de données de BlazeGraph à jour. Peut parfois jouer des tours lors d'une nouvelle installation.
  • Quick Statements

Comment recharger les paramètres

[edit]

Par les volumes

[edit]

Une fois le LocalSettings.php (spécifique à l'instance) créé dans le dossier wikibase-docker/wikibase/, il peut être injecté dans wikibase en ajoutant un volume docker ici bloque l'initialisation de mediawiki au moment de sa première exécution.

Au premier lancement, le processus d'installation de wikibase va vérifier la présence de ce fichier LocalSettings.php et ne lancer l'installation initiale de wikibase que si ce fichier n'est pas présent. Un fichier LocalSettings.php est alors créé par wikibase à la fin de l'installation. Le présence de ce fichier permet alors à wikibase de savoir si il doit ou pas exécuter son installation (opération qui ne doit être réalisé qu'une seule fois).

Pour éviter de perturber ce processus d'installation, les développeurs de wikibase ont prévu d'exécuter un éventuel script en amont du setup de la première installation ici dans le fichier entrypoint.sh, et aussi en aval de l'installation ici.

Il est alors possible de charger LocalSetting.php custom dans un autre emplacement ex: /var/www/html/LocalSettings.custom.php pour ne pas gêner la première exécution. Monté en volume :

  • le fichier extra-install.sh :

cp /var/www/html/LocalSettings.custom.php /var/www/html/LocalSettings.php

  • le fichier entrypoint-run-first.sh : cp /var/www/html/LocalSettings.custom.php /var/www/html/LocalSettings.php

Le second fichier ne s'exécute uniquement si /var/www/html/LocalSettings.php est déjà existant (donc qu'une première installation s'est déjà déroulée).

Par une reconstruction du container

[edit]

Une manière simple de prendre en compte les changements effectués dans un LocalSettings.php custom, notamment si des extensions sont installées, est de rebuild de l'image wikibase. Cela peut se faire en modifiant directement le Dockerfile pour charger le fichier au bon moment.

La fin du Dockerfile, après la copie des extensions peut ressembler à : 

COPY LocalSettings.php.wikibase-bundle.template /LocalSettings.php.wikibase-bundle.template
COPY LocalSettings.php.custom.template /LocalSettings.php.custom.template
COPY extra-install.sh /
COPY extra-entrypoint-run-first.sh /
RUN cat /LocalSettings.php.wikibase-bundle.template /LocalSettings.php.custom.template >> /LocalSettings.php.template && rm /LocalSettings.php.wikibase-bundle.template

Une fois un premier build long, la mise en cache des étapes ne changeant pas permet un démarrage très rapide : pour prendre en compte de nouvelle modifications de LocalSettings.php.custom.template, il suffit de dedémarrer avec le flag --build 

docker-compose up --build -d

Il est aussi possible de rebuild localement pour vérifier si la configuration ne comporte pas d'erreur :

cd wikibase/1.33/bundle && docker build wikibase:foo . --rm=false

puis de relancer le tout docker-compose up

Recherche

[edit]

Par défaut, dans MediaWiki, la recherche s'organise principalement autour de deux bases de données :

  • La recherche simple en haut à droite de chaque page s'effectue directement sur la base de données primaire (MySQL)
  • Tandis que la recherche avancée (la page de résultat de la recherche simple) s'effectue sur la ElasticSearch (base de données secondaire)

MediaWiki accède à ElasticSearch via l'extension CirrusSearch. Cette extension permet également de mettre à jour et de supprimer les indexes ElasticSearch. Wikibase utilise aussi l'extension CirrusSearch par défaut.

La recherche plein texte évoqué ci-dessus avec ElasticSearch reste très limitée pour chercher dans un graphe de données. Pour palier à ce défaut, les équipes de Wikidata ont développé un service externe de requête d'entité en graphe appellé Wikidata Query Service.

Adaptable sur Wikibase et intégré à l'image wikibase-docker, il permet une recherche en graphe performante et très fine. La contrepartie de la recherche en graphe vient des limites du Query Service à rechercher des valeurs -- chaînes de caractère, expressions régulières. C'est pour cela qu'il est complémentaire à la recherche plein texte d'ElasticSearch.

Recherche simple

[edit]

La recherche simple correspond au champ de recherche en haut à droite de toutes les pages. Elle permet de chercher des termes et des identifiants facilement. Exemple sur Wikidata : recherche simple de "Jean Jacques Rousseau"

Ce champ de recherche envoie des requêtes à l'API via l'action wbsearchentities. L'API Wikibase fait ensuite une requête SQL pour chercher les entités correspondantes, cette requête s'effectue sur les termes de l'entité, dans la langue de l'utilisateur.

Recherche avancée

[edit]

L'extension AdvancedSearch permet d'étendre certaines fonctionnalités avancée de Wikibase et permet une recherche par mot ou par phrase :

Exemple sur Wikidata avec la recherche "rita mitsouko"

Exemple sur Wikidata avec la recherche "Rita Mitsouko haswbstatement:P31=Q215380"

Une désindexation d'ElasticSearch est possible via l'extension CirrusSearch puisqu'elle permet de supprimer des pages d'ElasticSearch.

Recherche par déclaration

[edit]

Pour pouvoir effectuer des recherches sur des déclarations, Wikibase a besoin de l'extension WikibaseCirrusSearch.

WikibaseCirrusSearch est une extension dédiée à la recherche avancée sur Wikibase. Bien qu'utilisée par Wikidata, cette extension n'est pas installée dans l'image wikibase-docker fournit par Wikimedia.

Alors que WikibaseCirrusSearch permet de chercher n'importe quelle déclaration, elle ne permet pas de chercher de qualificateur ou de référence.

Ces recherches plus approfondies sont possibles grâce à l'indexation des déclarations sous forme de mots-clés indéxés dans la variable statement_keywords(source). Cette indexation de valeurs est accessible via l'action ?action=cirrusdump sur chaque entité. Par exemple https://www.wikidata.org/wiki/Q27777556?action=cirrusdump

Voir le ticket Phabricator sur le sujet

Recherche par facettes

[edit]

La création de facettes (inexistantes aujourd'hui sur Wikibase) suppose une indexation additionnelle, via des agrégateurs. Ces agrégations pourraient ensuite être interrogées par la page spéciale pour générer l'interface initiale. Un point d'API dédié pourrait permettre de mettre à jour les résultats selon les facettes sélectionnées.

Quelques lectures sur le sujet :

Pertinence

[edit]

Les résultats de recherche sont, par défaut, triés par pertinence. La pertinence est une théorie en soi, comme le montre Theory Behind Relevance Scoring. De manière générale, améliorer la pertinence d'Elasticsearch, en fonction des indexations, signifie une génération de requêtes boosts.

API

[edit]

L'API de recherche utilise le protocole HTTP. Elle est accessible sans authentification. Différents points d'accès sont disponibles sur l'API pour la recherche :

L'API permet de facilement faire des exports de recherche dans les formats suivant : json, jsonfm, php, phpfm, rawfm, xml, xmlfm

Suggestions

[edit]

Le champ de propriété des déclarations peut proposer des suggestions de propriétés. Cette réalisation est possible sur Wikibase en installant l'extension PropertySuggester.

Par exemple, l'œuvre littéraire Q1513820 sur Wikidata, déjà assez complète, propose des propriétés encore manquantes :

L'interface d'édition des déclarations qui ont une entité en valeur -- propriétés de types WikibaseItem et WikibaseProperty -- propose aussi des suggestions parmi les éléments et propriétés existantes. Aucune catégorisation n'est faite aujourd'hui : une déclaration qui accepterait un élément en valeur se verrait suggérer n'importe quel élément.

MediaWiki propose des opérateurs logiques. Exemple de requête sur Wikidata, avec la recherche reclus -elisée

Export

[edit]

Des exports de données partiels sont réalisables via l'API et le Query Service en différents formats : * API : JSON, XML, HTML, PHP * Query Service : JSON, CSV, TSV

Les exports de données complets (dump) peuvent se faire en différent format RDF (NT, TTL), JSON, XML via des scripts PHP. Il faut donc un accès au serveur Wikibase pour les générer. Libre ensuite aux administrateurs système d'en donner l'accès via un serveur HTTP comme c'est le cas pour les dumps Wikidata.

Voir la documentation sur le dump RDF.

Contraintes

[edit]

Historiquement, le logiciel MediaWiki, ainsi que son usage par la communauté Wikimedia, s'est largement appuyé sur des principes de confiance a priori. Sur Wikipedia comme sur Wikidata, (presque) toutes les modifications du contenu peuvent être réalisées par n'importe quel utilisateur, charge à la communauté de corriger ensuite les erreurs ou les actes de vandalisme. Pour ce faire, la communauté a développée de nombreuses pratiques de relectures ainsi qu'un large éventail d'outils de révision.

En introduisant des données structurées dans ce qui était précédemment des documents textuels faiblement structurés par un langage de balise (le wikicode), Wikibase a dû introduire une première couche de validation a priori des contributions. Cette première couche est limitée à la validation du format des données. Il n'est, par exemple, pas possible d'entrer une date dans un format invalide, mais rien n'empêche aujourd'hui d'entrer une date valide mais aberrante pour une entité donnée.

Quelques liens vers Phabricator des principaux tickets sur le sujet : * Tickets de la catégorie Wikibase-Quality-Constraints sur Phabricator * Check constraints before saving statements * Support complex constraints * Request for new constraint types * et aussi la documentation sur les contraintes dans Wikibase

WikibaseQualityConstraints

[edit]

Ces trois dernières années, d'importants efforts ont été entrepris pour mettre en place des contraintes a posteriori, notamment avec les développements de l'extension WikibaseQualityConstraints, qui reste encore très couplé à Wikidata.

Cette extension permet notamment d'éditer des rapports de violations de contraintes sur la page de discussion des propriétés. Cette page de discussion intègre une section documentation qui semble être générée automatiquement via un canneva dans lequel figure un lien vers la page Wikidata:Database_reports/Constraint_violations de la propriété en question.

Ces pages sont maintenues automatiquement par des programmes, DeltaBot étant l'un des plus utilisés. Ce dernier génère les pages de violations de contraintes à partir des résultats de requêtes SPARQL qui reproduisent les contraintes. Par exemple, voici la requête générée par DeltaBot pour identifier toutes les erreurs de formatage d'identifiant BnF (P268) dans Wikidata.

WikibaseQualityConstraints a été installé en suivant ces étapes : - rebuild de l'image wikibase après éditer le Dockerfile est les quelques autres fichiers nécéssaire pour installer l'extension - redémarrage de wikibase (sans avoir supprimé les volumes) - adaptation de la documentation de l'installation de l'extension à notre cas particulier, avec exécution des commandes suivantes : 

# Depuis le container wikibase
# mise à jour des tables mysql
php maintenance/update.php --quick

# création des propriétés et éléments nécessaire à la modélisation des contraintes
# et écrasement des valeurs déclarées en dur dans
# extensions/WikibaseQualityConstraints/extension.json en ajoutant les identifiants fraîchement
# générés à LocalSettings.php
php extensions/WikibaseQualityConstraints/maintenance/ImportConstraintEntities.php | tee -a LocalSettings.php

# installation de jq si manquant
apt-get install jq
# pour pouvoir facilement customiser la valeur du endpoint SPARQL
cat extension.json | jq '.config.WBQualityConstraintsSparqlEndpoint.value = "https://poc-fne-query.abes.fr/proxy/wdqs/bigdata/namespace/wdq/sparql"' > extension.json.updated
mv extension.json.updated extension.json
  • docker-compose restart wikibase pour prendre en compte ces nouvelles valeurs
  • test en ajoutant une contrainte sur une propriété (inspiration sur Wikidata)
  • mettre à jour BlazeGraph

Données non conformes

[edit]

Type de données non conforme exemple : chaîne de caractère au lieu d’une date ou format de date non respecté

Ce type de validation est déjà intégré dans Wikibase. Coté client comme via l'API, le serveur rejetera, par exemple, une date mal formatée ou des coordonnées géographiques invalides.

Forme de données non conforme exemple : identifiant mal formé au vu des règles à observer

La validation de format de donnée se fait aujourd'hui a posteriori via les contraintes de propriété (contrainte de format (Q21502404) avec le format spécifié en qualificateur via la propriété expression régulière (P1793)).

L'usage de ces expressions régulières pour valider les entrées avant la sauvegarde a été discuté au sein de la communauté, mais n'a pour le moment pas donnée suite. Cette discussion s'intègre dans une discussion plus large sur la validation des contraintes a priori. Confère le ticket Phabricator a ce sujet : Check constraints before saving statements.

Données incohérentes exemple : date de mort antérieure à date de naissance

Certaines données incohérentes sont aujourd'hui détectées par Wikibase et font l'objet de rapport de violation de contraintes a posteriori. Ainsi, il est possible d'entrer une date de naissance postérieure à une date de décès, mais la déclaration fera l'objet d'un rapport sur l'élément.

La modélisation de contrainte sur Wikidata, comme par exemple un écart de valeurs, peut s'observer sur cet élément ainsi que sur la propriété de date de décès P570 et sur sa page de rapport de contrainte, dans la section "Diff within range" violations.

Schémas de données

[edit]

L'espace de nom entitySchema a récemment été ouvert sur Wikibase (juin 2019) basé sur le langage ShEx. Ces éléments Wikibase permettent uniquement de publier et d'élaborer de nouveaux schémas.

Plusieurs outils de validation de l'intégrité via des schémas d'entité existe en tant que service externe.

Ces trois outils sont capables de travailler sur n'importe quelle instance Wikibase pourvu qu'ils y aient accès.

Au vu de la nouveauté des schémas d'entité sur Wikibase, on peut s'attendre à certains développements pour que ces outils puissent à l'avenir faire partie intégrante de Wikibase via des pages spéciales et/ou des extensions. Une veille sur la page de projet Wikidata Shex est conseillée.

Un outil pourrait être développé pour appliquer des actions sémantiques (semantic actions en anglais) et ainsi pouvoir comparer des dates par exemple. Cette spécification a par ailleurs son ticket dans les spécificité du langage Shex lui-même. L'interprétation de ces actions sémantiques doit être faite à partir du langage utilisé par l'outil Shex en question (js: pour shex.js, scala: pour Wikishape etc.).

Listes de valeurs contrôlées

[edit]

Aucune liste de valeur n'existe aujourd'hui dans Wikibase, en dehors de cas très particuliers comme la sélection du calendrier à utiliser pour la saisie d'une date.

Le concept d'une liste de valeurs contrôlées semble assez éloigné des pratiques de Wikibase, où les listes de valeurs suggérées sont, selon les types de propriété, les résultats de requêtes -- propriétés de type WikibaseItem, WikibaseProperty -- ou un champ libre sans proposition de valeur -- Quantity, Time, GlobeCoordinate, URL, String, ExternalId. A l'exception de certaines suggestions, basées sur des contraintes de propriété. En l'occurence, "one-of constraint" et "allowed qualifiers constraint" suggérent des valeurs lors de l’édition des déclarations.

Il serait concevable de créer un ticket sur Phabricator, qui définirait, par exemple, que seules des langues soient suggérées pour les propriétés de langue -- dans Wikidata : P37, P103 -- ou que seuls des pays soient suggérés pour une propriété tel que pays (P17). Cependant le problème est loin d'être trivial, car Wikibase doit être capable de pré-générer des listes d'entités valides pour une propriété donnée, et de garder ces listes à jour automatiquement et avec peu de délai.

Gestion utilisateur

[edit]

Création d'utilisateurs

[edit]

Il est possible de créer des comptes utilisateurs par lot via l'extension MediaWiki ImportUsers, qui est non-maintenue mais fonctionnelle. Elle permet notamment d'importer des comptes utilisateurs depuis un fichier CSV.

Gestion des groupes

[edit]

Le paramétrage des groupes d'utilisateurs et des droits de chaque utilisateur est suffisemment fin pour créer des profils de producteurs et d'en restreinte la capacité de production.

Sur une instance MediaWiki, la liste des groupes utilisateur est consultable sur la page spéciale ListGroupRights. Un groupe ne peut être créé que via la configuration du fichier LocalSettings.php, notamment grâce à la variable $wgGroupPermissions, détaillée dans le cas d'usage.

L'appartenance de chaque utilisateur à des groupes peut être consultée et paramétrée via la page spéciale UserRights. Un script de maintenance (createAndPromote) permet de facilement changer les utilisateurs de groupes.

Restrictions

[edit]

A la lecture

[edit]

Empêcher la consultation des entités est grossièrement possible via la restriction de pages entières pour les utilisateurs non-authentifié (désigné ci-dessous par le caractère *).

Il s'agit de s'assurer d'abord que l'accès à l'édition des données aux utilisateurs anonymes est interdit :

$wgGroupPermissions['*']['editpage'] = false;

Interdire l'accès à la lecture de la page aux utilisateurs anonymes avec la ligne :

$wgGroupPermissions['*']['read'] = false;

Avec ces deux lignes ci-dessus, les utilisateurs peuvent toujours se créer un compte. Considérer alors la possibilité d'interdire la création de compte :

$wgGroupPermissions['*']['createaccount'] = false;

A l'écriture

[edit]

La création, la modification et la suppression de pages dans MediaWiki -- et donc dans Wikibase -- est possible par n'importe quel utilisateur qui en a les droits, tous paramétrables indépendamment.

La restriction de modification d'entité se fait via la protection de la page de l'entité. Par exemple, une fois authentifié en tant qu'administrateur, la propriété Identifiant ISNI (P1) peut être rendu éditable uniquement par les administrateurs via le lien Protéger. Cette fonctionnalité issue de MediaWiki est aussi accessible via la variable de configuration $wgRestrictionLevels.

Doublons

[edit]

Grâce aux qualificateurs, la granularité du modèle de données permet de créer des éléments qui ont pour but de marquer des doublons. Ainsi, Wikidata a la capacité de marquer des doublons grâce à une déclaration "instance de" (P31) "Wikimedia duplicated page" (Q17362920). Cette dernière reçoit également un qualificateur avec une propriété "de" (P642) et une valeur avec l'élément doublon en question. Ainsi on peut voir que l'élément "Guerre russo-turque" (Q743046) est un doublon de "Russo-Turkish War" (Q6895581).

Une fois ce modèle définit, il est possible d'automatiser l'attribution de doublon. C'est précisément ce que fait le script markasduplicate qui, comme son nom l'indique, "marque" comme doublon un item en lui attribuant une déclaration de qualificateur.

A noter également la propriété Wikidata élément doublon permanent utilisée pour indiquer que des éléments sont identifiés comme des doublons mais ne peuvent être fusionnés pour différentes raisons.

Wikibase n'opère aucun contrôle a priori qui puisse comparer des propriétés. Il semble difficile de pouvoir contrôler a priori la création de d'éléments doublons. En effet, ce défi imposerait de vérifier des centaines millions de déclarations en l'espace d'un temps acceptable pour l'utilisateur.

Il est à noter que Wikibase restreint la création de doublon sur les termes d'une entité. A la création d'un élément avec un label et une description déjà utilisé, un message d'erreur s'affiche.

Alignement

[edit]

Il existe des outils externes d'alignement et de réconciliation, largement utilisés par la communauté Wikidata :

Ces outils sont intégrables à n'importe quelle instance Wikibase grâce openrefine-wikibase, mixnmatch_wb) et pourraient faire l'objet d'interface dédiée pour produire des alignements.

Fusion

[edit]

La fusion est possible sur Wikibase via la page spéciale MergeItems, elle n'est réalisable que si :

  • une seule entité possède une affirmation à valeur unique OU les affirmations ont une valeur similaire (ex: seules les entités Wikidata ayant la même affirmation de P31 (instance of) peuvent être fusionnées.)
  • les descriptions sont similaires (les alias et les libellés peuvent être différents)

Une documentation exhaustive de fusion d'entité est disponible sur cette page.

Quelques spécifications à noter lors d'une fusion :

  • L'entité cible est maintenue, l'entité de provenance devient une redirection.
  • Le libellé de l'entité fusionnée devient l'alias de l'entité cible.
  • Les alias des deux entités sont regroupés et dédoublonnés.
  • Lorsque deux entités ont une affirmation identique, une affirmation unique dans la déclaration est maintenue.
  • Lorsque deux entités ont une affirmation dont la valeur est différente, l'entité fusionnée possède une déclaration à plusieurs valeurs. Sauf si les deux valeurs originales étaient identiques (casse non prise en compte).
  • Le fusion n'a pas de conséquence sur le rang de l'affirmation. La fusion produit alors une déclaration avec deux affirmations de rang différents.

Le processus pour annuler une fusion est décrit sur cette page de documentation.

Journalisation

[edit]

MediaWiki journalise toutes les modifications des données, c'est l'une de ses fonctionnalités centrales. Chaque modification est associée soit à un compte utilisateur, soit à l'IP d'un contributeur qui ne serait pas connecté (si cela est autorisé).

Les listes suivantes sont consultables pour plus de détails :

  • les modifications récentes effectuées sur toutes les pages
  • l'historique de révision : tous les changements effectués sur une page spécifique
  • les contributions d'un utilisateur particulier
  • les pages nouvellement créées

La page spéciale Special:RecentChanges permet un affinage avec différents filtres, et notamment des filtres par étiquettes (tags). Cela permet également de lister toutes les modifications faites par une application tierce donnée. Par exemple avec la liste des modifications récentes réalisées avec l'application author-disambiguator sur Wikidata.

Wikibase ajoute à cela que les modifications se voient attribuer un sommaire automatique selon la partie de l'entité modifiée dans l'historique de l'élément. Cet historique permet d'établir les motifs de révisions (Affirmation ajoutée :) suivi du libellé et de l'identifiant de la propriété concernée.

En plus de s'afficher dans la page spéciale RecentChanges, les suppressions de pages sont listées dans le journal des suppressions.

Import de données

[edit]

Plusieurs outils permettent de charger des données dans Wikibase en masse, notamment :

  • wikibase-edit : bibliothèque en NodeJS pour lire et écrire sur Wikibase
  • wikibase-cli : interface en shell, construit au dessus de wikibase-edit
  • QuickStatements : interface graphique très populaire pour importer des données en masse mais moins complète que wikibase-edit. Le service est intégré à l'image wikibase-docker.
  • WikidataIntegrator: bibliothèque python pour lire et écrire sur Wikibase

Recherche un import est une fonctionnalité native de MediaWiki -- et donc de Wikibase -- qui propose un historique de contributions par utilisateur. Lors de l'import, il est possible de signer les modifications avec une chaîne de caractère.

Cette fonctionnalité pourrait être complétée par une instance d'EditGroups qui n'est pas encore compatible avec d'autres instances Wikibase que Wikidata, même si son évolution semble aller vers une implémentation sur d'autres wikis de Wikimedia.

Statistiques

[edit]

Certaines pages de statistiques sont disponibles à l'intérieur de Wikibase, notamment via la page spéciale Special:Statistics.

D'autres outils statistiques existent à l'extérieur de MediaWiki, sans pour autant pouvoir identifier l'origine du code source :

Applications tierces

[edit]

Lecture

[edit]

De nombreuses applications font la preuve de la possibilité de récupérer les données d'un Wikibase et ainsi servir de front-end alternatif à l'interface Wikibase. Voici quelques exemples qui récupèrent les données de Wikidata :

Toutes ces interfaces alternatives utilisent l'API Wikibase -- notamment le point d'accès wbgetentities pour récupérer les données de l'entité à afficher, ainsi que leurs entités liées -- et/ou le Query Service.

Scholia fait notamment un usage important des pages embed du Query Service, lesquelles permettent d'intégrer facilement les résultats d'une requête SPARQL à une page.

Ecriture

[edit]

Plusieurs applications font la preuve de la possibilité pour les applications tierces de modifier une instance Wikibase :

Ces applications tierces utilisent l'authentification via OAuth permis par l'extension OAuth. Voir aussi la documentation OAuth pour les développeurs d'application tierces. Les applications qui utilisent le protocole OAuth sont publiques et listées sur Wikidata via la page spéciale OAuthListConsumers.

Standards

[edit]

Il est possible de spécifier la licence désirée dans les options du serveur Wikibase via les options.

Exemples d'URLs pour lier à la licence à utiliser pour les données :

Par ailleurs, l'extension PerPageLicense permet d'afficher différentes licences par espace de nom ou par page.

Espaces de travail et tableaux de bord

[edit]

Les espaces de travail et tableaux de bord dans MediaWiki et Wikibase se limite à des pages qui sont pour la plupart générées en wikicode et/ou grâce à des templates écrits en Lua grâce à l'extension Scribunto soit manuellement par des contributeurs, soit à l'aide de programme (bot) qui automatisent la mise à jour.

Des pages wiki non-structurées en entité -- page wiki classique éventuellement regroupées au sein d'un espace de nom dédié -- peuvent être utilisées pour effectuer des sauvegardes de lot d'entités.

De tels listes sont nombreuses sur les différents projets Wikimedia. Dans Wikidata, on peut notamment noter les listes générées automatiquement par des programme (bot) tel que DeltaBot (décrit plus haut).

Tous les espaces de collaboration se font par des pages de wiki éditées manuellement, ou automatiquement grâce à un programme (bot). Par exemple avec la page de requête aux administrateurs de Wikidata ou encore la page des demandes de suppression.

Un outil de suivi des chantiers existe, mais il est aujourd'hui fortement couplé à Wikidata : Integraality. Un générateur de tableau de bord de la couverture en propriétés pour un domaine de Wikidata (exemple : dashboard de complétion des éléments de peintures dans Wikidata, par collection)

Fédération, références et liens externes

[edit]

Wikibase offre de larges possibilités pour lier des ressources documentaires, que ce soit directement dans les déclarations -- avec une propriété de type Url ou ExternalId -- dans les qualificateurs des déclarations ou bien dans leurs références. Alternativement, les liens de sites (sitelinks), implémentés nativement dans Wikibase, pourraient également permettre de lier de la donnée externe via des URL/URI.

La possibilité de créer des liens ou de partager des données avec d'autres référentiels externes n'est possible que si une forme de fédération est implémentée dans Wikibase ce qui n'est pas le cas à l'heure actuelle.

Limite de chaine de caractère

[edit]

Les valeurs de déclarations ont par défaut une limite que Wikibase. Il est possible de modifier cette limite avec les paramètres suivants : 

$wgWBRepoSettings['string-limits'] = 2000;

Sur d'autres versions de Wikibase ces paramètres semblerait fonctionner : 

$wgWBRepoSettings['string-limits.monolingualtext.length'] = 2000
$wgWBRepoSettings['string-limits.string.length'] = 2000

Voir aussi les tickets Phabricator sur le sujet.

Namespace par défaut

[edit]

Pour configurer les Item comment entity par défaut, considérer ajouter ces lignes au LocalSettings.php (source) : 

# Setting up items in the main namespace
${DOLLAR}baseNs = 100;
# Define the namespace indexes
define( 'WB_NS_PROPERTY', ${DOLLAR}baseNs + 2 );
define( 'WB_NS_PROPERTY_TALK', ${DOLLAR}baseNs + 3 );
# Define the namespaces
${DOLLAR}wgExtraNamespaces[WB_NS_PROPERTY] = 'Property';
${DOLLAR}wgExtraNamespaces[WB_NS_PROPERTY_TALK] = 'Property_talk';
# Assigning the correct entity types to the namespaces
${DOLLAR}wgWBRepoSettings['entityNamespaces']['item'] = NS_MAIN;
${DOLLAR}wgWBRepoSettings['entityNamespaces']['property'] = WB_NS_PROPERTY;

Pour continuer

[edit]

Bibliographie

[edit]
Retrieved from "https://www.mediawiki.org/w/index.php?title=User:Jumtist/exploration_wikibase&oldid=3883673"