User:Jumtist/exploration wikibase

= Retours d'exploration Wikibase 2019 =

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.

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
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 :


 * Rang
 * Qualificatifs
 * Références
 * Sources

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. 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
Cette exploration a permis d'implémenter l'image Docker proposée par Wikimedia Deutschland. 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 :


 * Customizing Wikibase config in the docker-compose example
 * Creating a Dockerfile for the Wikibase Registry
 * Revisions Gist
 * wikibase-docker, Mediawiki &amp; Wikibase update

Bon à savoir :


 * Ne pas oublier de définir la variable  dans la config, sinon   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
 * avec les extensions suivantes (voir la page pour une liste exhaustive des extensions MediaWiki installées)
 * Wikibase, c'est à dire Wikibase_Repository, Wikibase_Client, WikibaseLib, et WikibaseView
 * CirrusSearch complété par WikibaseCirrusSearch
 * AdvancedSearch
 * EntitySchema
 * WikibaseQualityConstraints
 * Apache : le serveur en charge de l'execution des fichiers PHP de MediaWiki et de la gestion des requêtes HTTP
 * MariaDB : la base de données SQL utilisée par Wikibase pour le stockage des données primaires. Etant très proche de MySQL, ces deux termes peuvent être employés indifféremment dans ce document
 * ElasticSearch : une base de données dérivées des données primaires, optimisée pour la recherche plein texte
 * Query Service : un service fait de plusieurs composants :
 * une interface graphique (initialement nommé, nommé  dans  )
 * 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
 * : 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

Par les volumes
Une fois le  (spécifique à l'instance) créé dans le dossier , 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  et ne lancer l'installation initiale de wikibase que si ce fichier n'est pas présent. Un fichier  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  custom dans un autre emplacement ex:   pour ne pas gêner la première exécution. Monté en volume :


 * le fichier  :


 * le fichier  :

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

Par une reconstruction du container
Une manière simple de prendre en compte les changements effectués dans un  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, 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 &gt;&gt; /LocalSettings.php.template &amp;&amp; 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, il suffit de dedémarrer avec le flag

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

puis de relancer le tout

Recherche
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, 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
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 &quot;Jean Jacques Rousseau&quot;

Ce champ de recherche envoie des requêtes à l'API via l'action. 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
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 &quot;rita mitsouko&quot;

Exemple sur Wikidata avec la recherche &quot;Rita Mitsouko haswbstatement:P31=Q215380&quot;

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

Recherche par déclaration
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  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 (source). Cette indexation de valeurs est accessible via l'action  sur chaque entité. Par exemple

Voir le ticket Phabricator sur le sujet

Recherche par facettes
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 :


 * have been replaced by
 * unofficial article on How to create faceted/filtered search with Elasticsearch?

Pertinence
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
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 :


 * : permet une recherche sur les termes des entités, et est exécuté sur la base de donnée MySQL. Exemple : recherche des entités contenant &quot;balzac&quot; dans ses termes
 * permet une recherche sur CirrusSearch et, si installé, WikibaseCirrusSearch. Exemple : recherche des entités contenant &quot;balzac&quot; dans ses termes

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

Suggestions
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  et   -- 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

Export
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
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
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  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 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 :

php maintenance/update.php --quick
 * 1) Depuis le container wikibase
 * 2) mise à jour des tables mysql

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

apt-get install jq cat extension.json | jq '.config.WBQualityConstraintsSparqlEndpoint.value = &quot;https://poc-fne-query.abes.fr/proxy/wdqs/bigdata/namespace/wdq/sparql&quot;' &gt; extension.json.updated mv extension.json.updated extension.json
 * 1) installation de jq si manquant
 * 1) pour pouvoir facilement customiser la valeur du endpoint SPARQL
 * 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
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 avec le format spécifié en qualificateur via la propriété expression régulière).

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 et sur sa page de rapport de contrainte, dans la section.

Schémas de données
L'espace de nom  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.


 * ShEx2 Simple Online Validator outil très configurable et populaire
 * PyShEx
 * WikiShape

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 ( pour shex.js,   pour Wikishape etc.).

Listes de valeurs contrôlées
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,   -- ou un champ libre sans proposition de valeur --  ,  ,  ,  ,  ,. A l'exception de certaines suggestions, basées sur des contraintes de propriété. En l'occurence, &quot;one-of constraint&quot; et &quot;allowed qualifiers constraint&quot; 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.

Création d'utilisateurs
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
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. Un groupe ne peut être créé que via la configuration du fichier, notamment grâce à la variable, 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. Un script de maintenance permet de facilement changer les utilisateurs de groupes.

A la lecture
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 :

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

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 :

A l'écriture
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.

Doublons
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 &quot;instance de&quot; (P31) &quot;Wikimedia duplicated page&quot; (Q17362920). Cette dernière reçoit également un qualificateur avec une propriété &quot;de&quot; (P642) et une valeur avec l'élément doublon en question. Ainsi on peut voir que l'élément &quot;Guerre russo-turque&quot; (Q743046) est un doublon de &quot;Russo-Turkish War&quot; (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 qui, comme son nom l'indique, &quot;marque&quot; comme doublon un item en lui attribuant une déclaration de qualificateur.

A noter également la propriété Wikidata 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
Il existe des outils externes d'alignement et de réconciliation, largement utilisés par la communauté Wikidata :


 * Mixn'Match
 * OpenRefine

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
La fusion est possible sur Wikibase via la page spéciale, 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
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  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 suivi du libellé et de l'identifiant de la propriété concernée.

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

Import de données
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.
 * 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
Certaines pages de statistiques sont disponibles à l'intérieur de Wikibase, notamment via la page spéciale.

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


 * Statistiques de pages vues
 * Wikidata Navel Gazer

Lecture
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 :


 * Berlin sur Sqid
 * Berlin sur Reasonator
 * Berlin sur Inventaire
 * Berlin sur Scholia
 * La Vénus de Milo sur Crotos

Toutes ces interfaces alternatives utilisent l'API Wikibase -- notamment le point d'accès 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  du Query Service, lesquelles permettent d'intégrer facilement les résultats d'une requête SPARQL à une page.

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


 * Inventaire est capable, depuis son interface dédiée, de créer et d'éditer des entités Wikidata. Le service utilise la bibliothèque NodeJS.
 * Wikidata Game
 * QuickStatement
 * OpenRefine
 * et bien d'autres

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.

Standards
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 permet d'afficher différentes licences par espace de nom ou par page.

Espaces de travail et tableaux de bord
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 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
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  ou   -- 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
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
Pour configurer les Item comment entity par défaut, considérer ajouter ces lignes au  (source) :

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

Pour continuer

 * « Wikidata / Wikibase interest meeting at the National Library of Sweden », août 2019, https://docs.google.com/document/d/1ZYq5-H54K671zdqAoFUgROPzZsT4cfyP11nbdCS_KUw
 * Le projet NOEMI de la BnF -- notamment le retour d'expérience
 * Discussions tenues par différents acteurs intitutionnels lors des conférences Wikimania 2019 et WikidataCon 2019
 * Principaux canaux de communications de la communauté Wikibase

Bibliographie

 * D. Vrandecic, « The Rise of Wikidata », IEEE Intelligent Systems, vol. 28, 2013, p. 90–95 (ISSN 1541-1672, DOI 10.1109/MIS.2013.119)
 * Lydia Pintscher, Lea Voget, Melanie Koeppen, Elena Aleynikova, « Strategy for the Wikibase Ecosystem », août 2019, https://upload.wikimedia.org/wikipedia/commons/c/cc/Strategy_for_Wikibase_Ecosystem.pdf, dernière consultation le 14.11.2019
 * Jean Godby, Karen Smith-Yoshimura, Bruce Washburn, Kalan Knudson Davis, Karen Detling, Christine Fernsebner Eslao, Steven Folsom, Xiaoli Li, Marc McGee, Karen Miller, Honor Moody, Craig Thomas, Holly Tomren, « Creating Library Linked Data with WikibaseLessons Learned from Project Passage », OCLC, 2019, https://www.oclc.org/content/dam/research/publications/2019/oclcresearch-creating-library-linked-data-with-wikibase-project-passage-a4.pdf, dernière consultation le 14.11.2019
 * Giovanni Bergamin, Cristian Bacchi, « New ways of creating and sharing bibliographic information: an experiment of using the Wikibase Data Model for UNIMARC data », JLIS.it, vol. 9, 15 septembre 2018, p. 35–74 (ISSN 2038-1026, DOI 10.4403/jlis.it-12458), https://www.jlis.it/article/view/12458, dernière consultation le 14.11.2019