maxlath
commented
4 years ago tickets de la catégorie Wikibase-Quality-Constraints sur Phabricator
tickets particulièrement intéressants :
Open benbober opened 4 years ago
maxlath
commented
4 years ago tickets de la catégorie Wikibase-Quality-Constraints sur Phabricator
tickets particulièrement intéressants :
maxlath
commented
4 years ago Début de réponse point par point :
ex chaîne de caractère au lieu d’une date ou format de date non respecté [ex AAAAMMJJ]
Ce type de blocage est déjà intégré dans le Wikibase, que ce soit coté client ou via l'API, le serveur rejetera, par exemple, une date mal formatée ou des coordonnées géographiques invalides.
ex identifiant mal formé au vu des règles à observer
Ce type de validation n'est pas intégré aujourd'hui dans Wikibase mais il a été discuté de faire usage des expressions régulières renseignés sur les propriétés (P1793 sur Wikidata) (ticket Phabricator non retrouvé : s'il n'existe pas, on pourrait le créer)
ex date de mort antérieure à date de naissance
Ce type de validation n'est pas aujourd'hui intégré nativement à Wikibase mais a été modélisé comme une contrainte d'écart de valeurs (Q21510854 sur Wikidata, que l'on peut observer 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 ). C'est donc pour le moment une validation a posteriori.
Ce qui se rapproche le plus de ce besoin aujourd'hui dans Wikibase serait l'extension PropertySuggester : cette extension permet de suggérer des propriétés au moment de la séléction d'une propriété (voir capture d'écran si dessous prise sur une œuvre littéraire dans wikidata déjà assez complète et proposant donc des propriétés encore manquantes)
On est néanmoins encore loin d'un template. Ce type de template existe déjà, mais à l'extérieur de Wikidata, par exemple sur Inventaire où l'on propose des templates de création d'entités :
avec à chaque fois des propriétés spécifiques. Exemple ci-dessous pour la création d'une œuvre :
La création se fait ici dans la base de donnée d'Inventaire, mais il serait tout à fait possible d'utiliser le même type de template pour créer des entités typés de la sorte sur un Wikibase via un outil comme wikibase-edit (compétences requises : JS ou autre language disposant d'une telle lib) et un serveur gérant la connexion via OAuth.
Alternativement, de nouvelles pages Special pourraient être créés à l'intérieur même de Wikibase via une extension (tout comme Wikidata.org a sa propre extension), avec l'énorme avantage qu'il n'y aurait pas besoin de gérer l'authentification, les requêtes se faisant depuis Wikibase (compétences requises : PHP)
Dans les deux cas, il y a du travail sur la réalisation de l'interface graphique (compétences requises : HTML, CSS, JS), même si, pour l'option page Special, il devrait être possible de ré-utiliser des composants de l'interface graphique standard de Wikibase (?)
N'existe pas dans Wikibase et aucun ticket ne semble exister sur Phabricator, mais il serait concevable d'en créer un : on pourrait par exemple imaginer 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). Mais le problème est loin d'être trivial : il faut être capable de pré-générer des listes d'entités étant une valeur valide pour une propriété donnée, de garder ces listes à jour (idéalement automatiquement et avec aussi peu de délai que possible (?)). On pourrait imaginer de s'inspirer de ce qui a été fait pour l'extension PropertySuggester, laquelle crée une table wbs_propertypairs dont elle ce sert ensuite pour proposer des suggestions (source : setup).
Ce ticket permet de synthétiser en un seul l’ensemble des tickets qui ont trait aux règles métier, aux contraintes et à leur implémentation dans le FNE (validation à l’import et à la création, formulaires,…) Il s’agit des tickets #79 , #96 , #63 , #80 , #78 , #77 , #76 , #57 , #161, #162 . En amont du rapport final qui devra donner un avis spécifique sur chacune de ces fonctionnalités, l’objet du présent ticket est de fournir des orientations de plus haut niveau sur ce qu’il conviendrait de faire pour répondre aux besoins spécifiques du POC sur cette question des contraintes.
L’avis portera plus particulièrement sur les 3 points suivants