Topic on Wikidata:Bistro/Archives des discussions structurées

question au mauvais endroit suggérant de changer la présentation des pages de propriété

I really suggest changing the presentation of Wikidata pages to help distinguishing immediately that we are on a "Property" page (Pnnn), whose creation is restricted (and where there should be no other wiki article associated to them), and not on an entity page (Qnnn), whose creation is free (and can list wiki articles about roughly the same topic as the item described in Wikidata).

There are frequent errors where properties of properties are added/modified/deleted that should instead be done in properties of the associated item.

A "Property" page (Pnnn) should have a distinguishing background color (e.g. light blue instead of white), and its "associated Wikidata item" property should be at top of the list of properties (it should be ranked highest within the set of properties we should give to any well-defined property "Pnnn"), just below the translated labels, then followed by constraints (that should be ranked second within the set of properties we can give to a property).

Ranking properties of defined "Pnnn" properties can be based on a specific Wikidata item "Qxxx" (labelled "Wikidata property") describing how Wikidata properties can be specified (i.e. the list of properties each property must, should, or may have). "Qxxx" should have itself the "nature of item"="property" (qualified with "of"="Wikidata") where "property" is also another Wikidata item (not a property), or "Qxxx" can be a "subclass of"="property" (another Wikidata item whose "nature of item"="entity" or one of the subclasses of "entity" which is more specific)

All the other properties of properties "Pnnn" are just informative (but may be checked) to subclassifies the set of all properties (i.e. for handling metaclasses as entities, whose properties are refereing to the "Pnnn" properties that indicate which "Qnnn" item can use that property and which value we can assign to them).

Tu es sur le bistro en français ici, je te suggérerai de poster cette requête aux développeurs sur WD:DEVS ou sur https://phabricator.wikimedia.org/  :)

Désolé pour toi, mais Wikidata est international et il faut accepter TOUTES les langues et on peut répondre à ce sujet (qui concerne toutes les langues aussi) dans la langue de son choix, et le bistro (dédié à n'importe quelle langue) serait trop exclusif sur Wikidata si on ne devait y discuter que dans une seule alors qu'on traite un sujet tout aussi important pour toutes les langues. D'autant plus qu'ici je l'ai fait en tant que référence, avec un post aussi dans la section anglaise !!! Car cela s'adresse surtout les développeurs et admins (anglophones pour la plupart) de Wikidata, mais que sinon cela concerne aussi TOUS les autres utilisateurs et contributeurs de Wikidata (pas seulement les admins et développeurs!) qui ont leur avis aussi.

Sinon ce Bistro n'a plus aucune raison d'être et ne devrai plus parler QUE des SEULS libellés en français de Wikidata (et sinon de la poignée de liens vers les éditions francophones des projets wiki), puisque tout le reste (propriétés, valeurs, contraintes, etc.) est dans n'importe quelle langue et traduit dans n'importe quelle autre. Hors je parle de choses très générales concernant Wikidata lui-même et sa structure (et la façon d'éviter des confusions lors des modifs), et pas du tout des libellés qui ne sont pas structurants du tout.

Oula je m’attendais pas à une telle réaction en fermant ce sujet ! On est ici sur le bistro francophone, dont la principale raison d’être est de discuter entre francophone d’un peu tout ce qu’on veut. Il y a bien un espace plus ou moins central et international qui est Wikidata:Project chat sur lequel tu as posté ton commentaire, qui correspond à ce que tu décrits.

J’ai fermé le sujet d’une part parce qu’il était rédigé en anglais, d’autre part parce qu’il ne semblait pas vraiment destiné aux contributeurs qui n’ont pas vraiment de prise sur ce que tu suggères. D’autre part il n’y a pas eu de réactions ici … Bref je ne compte pas discuter davantage et je te suggère de le laisser ouvert si tu le souhaite mais je ne pense pas qu’il y ait grand chose à gagner à ne pas le fermer.

Je pense que justement les francophones ont un avis (et ils ne sont pas les seuls non plus), la question concernant en fait TOUS les contributeurs et tous les visiteurs qui ont peine à distinguer les pages de propriété et les pages d'éléments (parmi lesquelles ont a aussi les pages de catégories de Wikimédia, les pages de lexèmes, et les pages de sujets; ces dernières pouvant traiter de concepts, mutuellement associés à des pages de propriétés et souvent avec les mêmes noms).

Parmi les pages de propriétés on trouve aussi des "qualificateurs" (certains sont associés à des pages de sujets, liés sur les wikis, et sont éventuellement liés à une page de catégorie aussi; d'autres qualificateurs peuvent aussi être utilisés comme propriétés... un vrai "foutoir", alors que les qualificateurs devraient aussi avoir leur propre espace, séparé des pages d'items/sujets et des pages de propriétés

Mais le modèle RDF est très permissif et général et permet de mettre n'importe quel type dans chacun des éléments des triplets (verbe, sujet, objet), afin créer des "méta-modèles" avec des ontologies plus complexes: Wikidata représente par exemple un qualificateur par un triplet (verbe, qualificateur, valeur) et le référence à la place du verbe d'un triplet normal de propriété, il représente aussi les libellés comme le triplet (verbe-fixe-interne, langue, libellé), et listes de liens externes tels que les wikis part le triplet (verbe-interne-fixe, langue, lien) lui aussi utilisé à la place du verbe d'un triplet de propriété (ces "verbes-internes" ne sont pas éditables dans Wikidata, ce sont des URL propres à Wikidata distinguant propriétés normales (nommées), et autres propriétés étendues (non nommées: libellés, et liens externes).

Chacun des éléments de ces triplets RDF peut être de n'importe quel type, mais Wikidata restreint les deux premiers éléments d'un triplet à seulement des URL, les valeurs constantes comme chaines/nombres/dates n'étant possibles que dans le troisième (alors que RDF n'a pas cette contrainte; Wikidata reconnait certaines URL comme "internes" pour lier ses propres triplets entre eux, les autres URLs sont des URLs complètes, ou des URL abrégées à seulement le nom d'article dans le cas des liens wikis de Wikimedia et les autres URLs sont traitées toutes comme des chaines avec une contrainte de forme valide, et des filtres anti-spam et de sécurité contre certains domaines ou protocoles).

Tout cela manque de clarté pour plein de monde et l'interface de Wikidata ne facilite pas du tout les choses pour différencier le tout (on doit suivre chaque lien pour voir ce qu'il en est réellement).

La saisie de données dans Wikidata n'est pas facile: on tape un libellé et le moteur de recherche nous propose n'importe laquelle de ces pages, et il n'est pas facile de choisir sur la base des descriptions (souvent très insuffisantes) et pour peu qu'on fasse juste [Entrée] pour essayer, on se retrouve avec une sélection arbitrairement remplacée par un "synonyme" qui n'est pas ce qu'on a choisi et n'est synonyme QUE dans son contexte.

Bref il y a des améliorations aussi à faire dans le rendu du moteur de recherche de Wikidata (surtout lors de la saisie) pour distinguer clairement les types de résultats et pouvoir choisir sereinement. Souvent aussi, si le moteur de recherche ne trouve qu'une seule page, il n'affiche rien du tout et nous laisse valider sans savoir, puis il remplace les synonymes et là cela ne veut plus rien dire! Il aurait du proposer plutôt de créer la page manquante (ou aller faire une proposition de création de page de propriété manquante)

Tout cela ne gène pas du tout les robots (qui eux ne travaillent sur sur les triplets RDF pour faire des inférences et contribuer en masse), mais bien les seuls utilisateurs humains qui en premier lieu sont confrontés à l'interface assez confuse de Wikidata qui ne présente pas clairement les distinctions! Bref les humains s'y perdent et confondent trop facilement, ils sont peu aidés, malgré le fait qu'on a mis en place des "contraintes" (pour détecter certaines confusions et les signaler) et tout un tas de rapports automatiques (qui vont vérifier certaines règles et trouver les endroits où ces règles sont soient violées, soient insuffisantes pour gérer des exceptions ou bien pour les revoir avec une meilleure ontologie) mais que la plupart des utilisateurs ne savent pas lire (ils sont beaucoup trop longs et mal présentés aussi et n'exposent aucune solution de correction possible).

Je te conseille de lire les ressources introductives à Wikidata pour te clarifier les idées, parce qu’il y a effectivement pas mal de confusion dans ton message :) Je ne suis pas spécialement sur que ça vienne de Wikidata mais j’ai l’impression que ça vient plus de ta perception des choses - par exemple, il n’existe pas de « modèle RDF » en l’occurrence. Il existe un modèle « wikibase » dont une des formes, mais pas la seule possible, est une « ontologie OWL » https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/docs/ontology.owl . Mais tout ça, le contributeur « de base » n’a pas besoin de le savoir, il faut essentiellement comprendre Wikidata:Introduction/fr . L’ontologie commence à être utile si on veut se servir du moteur de requête.

La notion de « synonyme » n’existe pas, il y a juste un libellé préféré en français pour un élément, et des « alias », mais ce qui sert à identifier un sujet c’est l’élément lui même, peu importe son libellé et ses alias à la rigueur.

OWL s'appuie sur les triplets RDF, tu fais une tautologie pour pas grand chose...

Les moteurs exploitant ou interrogeant les données de Wikidata obtiennent des listes de triplets RDF même si leur validité est contrainte par OWL (qui en est juste une utilisation possible). SPARQL par exemple n'est pas limité à seulement OWL. Et on peut tout interroger sur Wikidata avec SPARQL.

Les "synonymes" sont bien la façon dont l'interface Wikidata traite les "alias": la substitution est automatique, Wikidata ne demande rien du tout. L'utilisateur lui voit juste l'élément, rarement l'identifiant interne (Qnnn ou Property:Pnnn) mais un libellé quelconque (pas unique et traduit) éventuellement avec une description sensée lever l'ambiguité.

Alors non je ne fais aucune confusion dans mon message, et mes termes sont choisis correctement et ils sont appropriés à ce que voient les utilisateurs réels (pas les robots). Ce sujet est entièrement dédié à ce que propose actuellement (très mal) Wikidata dans son interface à destination des utilisateurs.

De plus je ne suis pas d'accord avec toi: tout utilisateur est directement confronté à l'ontologie, chaque fois qu'il veut (et même doit) utiliser une propriété (comment la choisir, quelle valeur lui donner et souvent il tape une chaîne et le moteur lui retourne n'importe quoi, notamment parmi les homonymes). Un cas fréquent: l'utilisateur tape un code langue unique et valide à deux ou trois lettres, appuie sur TAB pour aller renseigner une valeur, et c'est un autre code langue qui est utilisé (car il fait fait un "match" partiel sur le libellé de la langue et a décidé lui-même que c'était mieux que le "match" sur le code complet, et que l'utilisateur voulait taper un morceau de libellé, mais l'interface ensuite n'affiche que le code langue et il voit vite que Wikidata a fait une inférence automatique fausse, s'il ne s'en aperçoit pas, l'utilisateur va entrer involontairement des données fausses ! Ce genre de cas est fréquent avec l'interface actuelle).

Je viens de regarder un peu ton historique, par curiosité, et je crois qu’effectivement un peu de lecture sur les bons usages de Wikidata ne te ferai pas de mal. Par ex dans ce diff : https://www.wikidata.org/w/index.php?title=Q1053064&diff=786525530&oldid=676257352&diffmode=source il semble que le libellé en français que tu as positionné ne soit pas conforme : tu as positionné des parenthèses de désambiguation comme si c’étaient des articles de Wikipédia. Ce n’est pas l’usage du libellé, cf. Label .

Est-ce pas ignorance des usages ou par volonté de pousser ton point de vue de mettre le maximum d’information pour l’utilisateur de Wikidata comme tu sembles le suggérer dans ces discussions ? Si c’est le cas tu dois être au courant qu’il n’est pas nécessairement bien vu de faire des éditions qui ne respectent pas les règles dans ce but.

Je ne sais pas du tout ou cette discussion est supposée aller, alors je vais m’arrêter là.

C'est toi qui l'a fait dévier, je n'ai pas dit qu'il y avait "des modèles RDF", mais il y bien "un" (et un seul) modèle RDF qui ne décrit rien d'autre que des ensembles non ordonnés de triplets, mais qui "permettait de créer des modèles", et j'avais fait ça en aparté bien distingué (tu semble nier que RDF, dérive en RDFS, qui dérive en OWL, qui dérive en Wikidata schema, mais au final ce sont des requêtes RDF qu'on fera et le reste ne sont que des restrictions ajoutées pour interpréter ce qui est entièrement décrit en RDF, et pour faire des inférences selon chaque niveau; RDF est toujours à la base même s'il ne sait pas ce qu'est une propriété ou un item Wikidata, et OWL lui non plus!) Je ne parle pas non plus des questions de syntaxe (on en a diverses possibles pour tous les niveaux (que ce soit basé sur XML le plus verbeux ou Turtle et dérivés, le schéma conceptuel à chaque niveau reste identique, et la base de données Wikidata au final n'a besoin de stocker QUE les triplets RDF, tous uniques, et une requête n'est qu'une succession de filtres sur l'ensemble non ordonnée des triplets avec des opération aussi simples que l'union, l'intersection, la soustraction ou la disjonction de sous-ensembles, et éventuellement un critère de tri). On n'interroge pas directement les données Wikidata on fait des inférences sur l'existence de triplets RDF dans des sous-ensembles de triplets stockés dans Wikidata, qu'on les former en combinant et échangeant les rôles entre les trois membres (verbe/prédicat, sujet, objet) et en faisant des filtres de sélection simples sur la totalité des triplets de Wikidata (les filtres portent un des trois termes, ou deux ou les trois) ou sur un sous-ensemble provenant d'un filtre précédent, et des opérations simples (union, intersection, disjonction, différence) sur les ensembles (SPARQL sert à ça, même s'il semble "comprendre" une partie du vocabulaire OWL, mais a un comportement erratique quand il ya des exceptions partout; au final OWL ne sert à rien sur Wikidata, il est inutilisable!).

J'ai fait à la base une demande concernant les utilisateurs et l'interface confuse de Wikidata (entre différents types d'entités) et le fait que cela concerne tous les utilisateurs, même si ce sont les développeurs qui sont les seuls à pouvoir s'en occuper, mais ils ont besoin de nos avis, donc la question ne s'adressait pas qu'à eux, et j'ai été gentil d'aviser ici que j'avais posté la demande d'avis ailleurs (en anglais oui, mais pour que les devs et admins puissent la lire). Ce qui fait la force de Wikidata c'est que son schéma est extensible mais pas facile à rendre cohérent (et que l'interface de Wikidata n'aide pas les utilisateurs à le respecter puisqu'il impose des choix arbitraires et souvent faux, ce ne sont même pas des heuristiques avec un bon degré de fiabilité car Wikidata viole constamment même les règles OWL, ce qui rend presque impossible de l'utiliser avec des outils OWL ou RDFS, et que seules les outils basés sur RDF peuvent arriver à faire le ménage et voir tout ce qui est réellement dans Wikidata et pas ce qui est supposé y être selon nos "contraintes" et notre "ontologie" qui n'est nulle part impérative; on a le même phénomène sur tous les wikis, et sur OSM avec un "schéma" de base permettant absolument tout, même en violation des règles écrites ou supposées correctement formulées, et ça se voit dans la liste des exceptions qu'on met partout sur Wikidata pour bon nombre de nos "contraintes": bon nombre de ces exceptions ne sont même pas nécessaires si les entités étaient correctement décrites; ça se voit aussi dans le nombre de propriétés "symétriques" qu'on doit ajouter de façon reondante dans les objets liés pour tenter de consolider le tout malgré les exceptions, comme le fait que justement on confond un peu partout les entités, les classes, les propriétés, les métaclasses et j'en passe... et que Wikidata ne s'en plaint pas du tout mais viole lui-même notre propre modèle par des choix automatiques basés sur des pseudo-heuristiques extrêmement aléatoires..)

Ce n'est pas une critique de Wikidata (son ouverture a du bon en terme d'extensibilité, de même que l'ouverture d'OSM, mais le comportement devient imprédictible et encore plus difficile pour les utilisateurs, et cela demande un travail de maintenance manuelle particulièrement lourd, dans lequel les retards s'accumulent de plus en plus massivement). On peut éviter cette croissance explosive de mainteannce en retard, en aidant davantage les contributeurs pour éviter des confusions entre les objets demandés.

Tu n’y es toujours pas. Tu peux facilement obtenir le « jeu de donnée » associé à un élément Wikidata sous forme de json par exemple qui n’a rien à voir avec du RDF ou même du json-ld. On les récupère dans un objet lua analogue quand on code des modules lua.

Par ailleurs te sembles avoir raté le fait que Wikibase implémente maintenant nativement un système de contrainte (molles) Help:Property constraints portal totalement ad-hoc et n’ayant rien à voir avec RDF(s) ou une ontologie OWL qui obéit à sa propre logique (et qui promet une gestion communautaire assez compliquée qui me laisse un poil sceptique pour l’instant - bon courage pour comprendre pourquoi tel ou tel truc est supposé être autorisé ou pas, on va des des « autorisations » de trucs particuliers juste pour faire passer une déclaration sans aucune cohérence avec le reste …). Si tu as vu des petites icônes « ! » sur une déclaration, c’est lui. Il a d’ailleurs été suggéré de s’appuyer sur ces contraintes pour faire des suggestions de valeurs pour les éditeurs, cf. la consultation en cour et les propositions de développement.

Tu n'y es pas non plus, j'ai écrit que les questions de syntaxe étaient hors de propos et toi tu me parles de JSON ou Lua qui ont leur syntaxe de présentation des données elles-mêmes mais n'en changent pas le modèle assez basique (des listes de triplets). Tout est centré ici sur la modélisation et la présentation de cette modélisation dans l'interface (pour guider l'utilisateur) et pas du tout sur la façon de coder les données.

Tu supposes aussi (à tord) que je ne connais pas ces icônes "!". Bien sûr que je les ai vues, tout le monde les a vues (ça c'est la toute petite partie visible, plein de choses importantes sont cachées et ne devraient pas l'être, à commencer par la typologie Wikidata des données, par exemple déjà par la distinction entre une propriété Pnnn et un item Qnnn rendus exactement de la même façon!). Bref là tu ne m'apprends rien, ni à personne d'autre.

Et non, je n'ai pas du tout raté (relis bien et pas en diagonale ce que tu veux!) le fait que Wikidata a son système de contraintes, ni le fait qu'OWL a sa propre logique (plus stricte) que Wikidata justement ne respecte pas en utilisant la sienne (donc en admettant les exceptions partout, des exceptions qu'au final on accumule de façon exponentielle alors que bon nombre d'entre elles pourraient être évitées en guidant les utilisateurs, ne serait-ce que par la présentation de l'interface). Ce que fait Wikidata c'est en théorie seulement vouloir reproduire un peu (émuler) ce que fait OWL, mais au final il ne l'utilise pas du tout pour ses propres contraintes mais les réécrit complètement, en se passant à la fois de OWL et de RDFS, mais à la base en n'utilisant plus que le modèle RDF de base (ce qui permet de le faire fonctionner avec SPARQL quand même qui n'a pas besoin d'autre chose.

Sur Wikidata on ne peut absolument pas raisonner en terme OWL ou RDFS, mais uniquement en terme de triplets RDF, y compris pour comprendre le système de contraintes de Wikidata (qui sont en fait des pseudo-contraintes puisque admettant tout le temps des exceptions pour tout (ce qui empêche justement d'utiliser les outils basés sur RDFS ou OWL pour exploiter les données Wikidata, mais a des conséquences car on a beaucoup de lourdeurs et une inférence bien plus limitée, mais aussi des tas de redondances à gérer, et aussi des conflits entre ces redondances qui finissent par se contredire entre elles: et ça c'est ce que voient les utilisateurs et complique pas mal de choses car ça donne des listes de maintenance interminables sur Wikidata pour chercher les raisons des incomplétudes, exceptions, contradictions, redondances, etc.)

En revanche l'utilisateur est directement exposé aux "homonymes" (conflits d'interprétation très mal résolus par Wikidata qui n'aide pas l'utilisateur à choisir et qui décide un peu n'importe quoi à sa place en faisant en plus sa propre interprétation de ce qui est "synonyme"). L'utilisateur ne voient pas la différence entre deux homonymes et comme il n'est exposé directement qu'aux "labels" plus ou moins traduits de façon souvent ambiguë, il doit jongler entre les langues pour tenter de comprendre, ou aller fouiller lui-même les propriétés des objets liés pour savoir si ce le bon objet qu'il manipule ou désigne; et pourtant Wikidata pourrait lui montrer directement des propriétés importantes (fondamentales même sur Wikidata qui tente de faire entrer les données dans son modèle très relâché de "pseudo-contraintes", et qui applique alors ses propres règles de façon aléatoire/imprévisible, en modifiant directement et automatiquement ce que l'utilisateur a entré lui-même).

Alors, une fois pour toute : le modèle de données Wikidata est indépendant de RDF, il est décrit ici : https://www.mediawiki.org/wiki/Wikibase/DataModel. Il existe une représentation du modèle de Wikidata qui utilise les technos web sémantiques, qui est utilisé pour le modèle sparql. Ce qui est soit dit en passant faisable pour quasi (absolument?) tous les modèles de données.

A partir de là, la représentation dans les technos du web sémantique du modèle Wikidata est donnée https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/docs/ontology.owl et elle ne raisonne pas en terme de triplet RDF, elle raisonne sur des notions de « déclarations » qui sont soutenues par des « sources », d’ « éléments » et de propriété. Ces déclarations étant représentées (instanciées si on veut) par un ensemble de triplets RDF. Effectivement, la sémantique contenue dans le modèle OWL est assez pauvre et nécessite d’être complétée si on veut utiliser un raisonneur OWL pour raisonner sur les données Wikibase … mais c’est pas spécialement simple de coller une sémantique ne serait-ce que pour une raison basique : la diversité des points de vues représentés, parfois contradictoire, qui font qu’on est de toute façon conceptuellement obligé de tenir compte des sources qui déclarent telle ou telle choses avant d’en envisager les conséquences. Des trucs existent pour gérer ça dans le monde du web sémantique, cf. https://lists.w3.org/Archives/Public/semantic-web/2018Sep/0001.html. Avec en plus le fait que oui, le système de contrainte de Wikibase n’est absolument pas défini en terme de OWL.

Tu commence à te contredire, tu soutenais plus haut que Wikidata était fondé sur OWL et maintenant tu admets le contraire. Je pourrais aussi te montrer ques les "déclarations" de Wikidata ne sont pas conformes non plus à l'ontologie affirmée dans ton lien qui n'est utilisée que comme heuristique (vers la quelle on tente d'aller) et pas comme des règles absolues: les déclarations et contraintes de Wikidata ne sont pas absolues, elles peuvent se contredire entre elles (ce qui n'est pas possible avec une vraie ontologie, mais possible si on en revient au modèle de base: les triplets RDF, qui n'ont strictement aucune obligation à être sémantiquement liés entre eux; Wikidata se contenant juste de garantir que les triplets sont identifiables et uniques dans sa base, et de permettre de former des liens quelconques entre eux, pour former un graphe orienté quelconque, sans aucune contrainte réelle). Et effectivement on ne peut alors pas utiliser directement un raisonnateur OWL, il aboutit à des contradictions un peu partout (on est donc obligé pour toute utilisation d'ajouter à chaque étape des vérifications pour éliminer un peu arbitrairement une partie des données obtenues ou de gérer spécialement les exceptions dans un raisonnement séparé aboutissant à des conclusions différentes, en nombre en fait illimité)

Euh, désolé mais je pense que tout ce que tu dis dans ce dernier commentaire est faux. Je crois que j’avais raison de douter que cette conversation allait quelque part quelques posts plus haut, je me demande vraiment comment j’ai pu me laisser embarquer là dedans.

Laisse tomber, c'est toi qui a voulu rentrer là dedans et qui tu bornes à une théorie peut-être voulue mais n'est pas celle qui fonctionne en pratique. J'ai fait une proposition sensée plus haut, et là tu entres dans des questions de jugements personnels qui sont hors de propos. Tu es convaincu que Wikidata utilises un modèle sémantique, ce n'est pas vrai, il cherche juste à y parvenir, ce qui est très différent (et il se met même à fonctionner de moins en moins bien). Il faut admettre que Wikidata ne permet pas de raisonner, sauf sur une petite partie (non identifiable donc choisie arbitrairement) de ses données RDF (si, si, j'insiste: RDF seulement, juste des collections de triplets, où un triplet = une déclaration Wikidata, il n'y a pas de sémantique absolue entre ces déclarations, que ce soit les propriétés Pnnn qu'on a attachées à un item Qnnn, ou entre les propriétés Pnnn elles-mêmes, ces déclarations sont toutes séparées et indépendantes sur Wikidata; c'est bien ça le problème car Wikidata cherche à créer un modèle sémantique mais n'aide pas suffisamment à le faire).

Oui bien sur, si on me donne des convictions que je n’ai pas et qu’on relance en permanence une conversation que j’ai indiqué vouloir ne pas avoir à plusieurs reprises et qu’on m’accuse de faire dériver la conversation alors que c’est toi qui met tout un tas de sujets sur la table quand bien même ça n’a rien à voir avec ta demande initiale, après avoir posté en anglais sur un forum francophone en ayant surtout défendu son approche quand on t’a gentillement fait remarquer que ce n’est peut être pas approprié et rouvert le sujet, c’est que le problème vient de moi et pas une volonté de polémiquer. J’y crois.

Je cherche à faire revenir le sujet et toi tu cherches seulement des raison de me contredire avec des arguments faux (sur une théorie fausse, qui n'est qu'une intention des auteurs de Wikidata, tout à fait bonne, mais qui manque encore d'outils techniques pour la faire appliquer: ne pas montrer clairement les éléments fondamentaux voulus c'est ce qui est dans le premier message, Wikidata masque trop de choses et est difficile à naviguer pour tout le monde, ça demandes des tas d'explorations manuelles, souvent bien plus que nécessaire pour se rendre compte que ce qu'on a saisi sous forme de "déclarations" n'est pas ce qu'on voulait déclarer; on procède sans arrêt par "tatonnement": on essaye, on va voir ailleurs si on trouve, on corrige ensuite éventuellement, on annule au besoin ou on ajoute une redondance contradictoire pour "palier"; au final le raisonnement sur Wikidata ne va pas beaucoup plus loin qu'un ou deux niveaux, il se contente de présenter un item isolé avec quelques propriétés très vagues, et on a du mal à aller plus loin sans aboutir très vite à des aberrations dans les conclusions tirées; pour aller plus loin il faudrait mieux aider les utilisateurs en lui montrant quelques niveaux d'inférences possibles pour les aider à choisir la bonne déclaration à utiliser, c'est à dire la plus appropriée dans l'état actuel des connaissances, ou l'aider à savoir s'il doit créer une nouvelle entité et ne pas réutiliser une autre existante pour créer une nouvelle contradiction/exception). C'est là que la question de la présentation sur Wikidata est importante! Et je reviens donc sur le sujet initial tu as voulu m'écarter, comme si ce n'était pas le premier problème sur lequel on doit améliorer les choses. Tu as voulu aussi m'écarter du fait que je l'ai posté en anglais mais je l'ai fait ici en courtoisie, car ça concerne tout le monde dans toutes les langues, y compris en français (donc cela a bien sa place dans ce bistro et dans les autres aussi, ce n'est pas que pour les développeurs, la langue utilisée pour en parler n'est pas le sujet!). J'ai donné des exemples pratiques bien réels de ce que cela provoque (dans le message dont tu dis que c'est une dérive, je pense que c'est au contraire une preuve parmi d'autres de l'existence de ce problème et que cela vient justement d'une incompréhension de ce que n'est pas wikidata et dont tu es visiblement convaincu, totalement à tord)

> cela vient justement d'une incompréhension de ce que n'est pas wikidata et dont tu es visiblement convaincu, totalement à tord

Je ne comprends rien à ce charabia. Je ne suis toujours pas convaincu que quoi que ce soit dans ce fil soit exploitable, je vais donc ne plus te relancer !

Je te laisse aussi ton expresssion de "charabia" car tu admets toi-même que tu ne comprends pas du tout ce qu'est réellement Wikidata: tu confonds ce qui est juste une volonté (ce à quoi il voudrait aller) et ce qu'il fait réellement: Wikidata n'a aucune sémantique (au sens plus strict donné par OWL) permettant des inférences, il produit seulement des heuristiques plus ou moins fiables (il n'y a encore strictement aucun moyen de délimiter un jeu partiel de données disposant de règles sémantiques strictes).

Et je pense même qu'il n'y en aura jamais car Wikidata ne veut pas s'enfermer dans un tel modèle sur toutes ses données et doit permettre des évolutions/extensions, même non vérifiées et pas encore renforcées, la plus grande partie des donénes n'étant que des assertions vraies le plus souvent mais pas toujours).

Si on voulait des modèles d'inférence stricts, il faudrait admettre l'existence de plusieurs modèles ayant chacun leur jeu de contraintes, donc admettre l'existence de nombreux homonymes, mais il faudrait aussi interdire la fusion d'éléments en apparence synonymes (et même souvent homonymes) mais basés sur des contraintes incompatibles entre elles. Hors strictement rien dans Wikidata ne permet actuellement de vérifier par exemple qu'une fusion d'éléments (construits chacun sur des modèles sémantiques stricts, différents et indépendants) ne va pas entraîner l'existence de contraintes contradictoires (et casser les deux modèles sémantiques en même temps, en y introduisant des contradictions dans les deux).

Alors oui tu te fais des idées fausses sur Wikidata, qui n'est pas du tout une "base sémantique" au sens d'OWL et qui admet les contradictions absolument partout, et ne permet pas du tout de garantir qu'un sous-ensemble au moins de ses données permet de faire des inférences fiables. Ses inférences sont relâchées (floues, pas binaires avec des réponses oui/non permettant des enchainements ilimités dans le raisonnement) exactement au même titre qu'une inférence déduite d'un hyperlien sur le web (ça s'est un peu amélioré avec l'introduction récente des "lexèmes" sur Wikidata pour éviter les pièges de la linguistique et des traductions, et notamment en ayant mis les données issues du Wiktionnaire vers ces nouveaux types d'entité et non plus dans les items classiques, mais il y a beaucoup de travail concernant la classification des articles et sujets sur Wikipédia ou Commons, qui ont aussi sont mal délimités, les sujets d'un article sur un wiki n'étant sémantiquement pas strictement équivalents sur un autre wiki).

Tout cela en fin de compte c'est une question d'objectif: qu'appelle-t-on "sémantique" sur Wikidata ? Un raisonnement purement binaire (oui/non) ? On n'a même pas intégré du tout la logique floue dans Wikidata, on n'a aucune qualification relative (=pourcentage estimé ou taux d'incertitude) de la vérité d'une assertion trouvée dans un triplet RDF=déclaration Wikidata (actuellement on n'a qu'un "rang" de priorité, qui ne sert qu'à trier les réponses possibles... si on demande le tri ou si on utilise ce rang comme filtre). On ne peut donc pas non plus indiquer à Wikidata que des règles sémantiques OWL ou RDFS strictes sont absolues, elles ne sont pas plus binaires que le reste des données, rien ne les protège d'une fusion puisque leurs propres contraintes ne seront pas vérifiées comme compatibles entre elles avant la fusion.

Écoutes, tu parles tout seul et tu me fais parler, ça suffit. Je n’apprécie pas ce mode de « communication ».

Tu es venu ici tout seul. Tu as voulu fermer le sujet abusivement pour un mauvais prétexte. Alors que c'est une question très intéressante plus de monde que toi tout seul, et qu'au départ je ne t'ai pas nommément invité. Je te laisse à tes certitudes ou ton obstination à croire à des chimères. Tu confonds objectifs légitimes de Wikidata (mais pas absolus, concernant l'envie de rendre ces données plus "sémantiques") et faits réels (où existe aussi la volonté manifeste de maintenir le "modèle" ouvert à des sémantiques non absolues et révisables). Wikidata est ouvert à des sémantiques floues (mais ne permet pas encore de les préciser et n'aide pas non plus à faire les bon choix dans ce qu'on y met). Visiblement la subtilité de cette question t'échappe totalement.

Tu continues à parler tout seul … je te laisse à tes considération sur mes opinions que je ne confirme ni n’infirme !

Non tu as affirmé des choses ici, et je t'ai montré que tes certitudes étaient infondées. Wikidata est plus ouvert que tu le crois, ça augmente les difficultés mais il lui manque des outils pour gérer l'incertitude, et cette incertitude intrinsèque est malheureusement cachée à l'utilisateur, puisque toutes les déclarations et modélisations de Wikidata sont de même degré partout alors qu'il faut pouvoir choisir (et que sur Wikidata on a le choix et le choix est vaste, ce qui devrait bloquer certains automatismes actuels abusifs de l'interface Wikidata qui ne les montre pas clairement mais décide un peu trop souvent à la place de l'utilisateur sur un raisonnement, dont on sait déjà à l'avance qu'il peut être faux). Intégrer la logique floue est pourtant possible en RDFS (donc aussi sur Wikidata), mais cela obligerait à revoir un peu le fonctionnement de SPARQL pour ne pas avoir à faire des requêtes trop lourdes, cherchant à trouver les déclarations de taux de certitude associées à chaque déclaration de fait (et sinon assigner un taux de certitude par défaut, paramétrable requête par requête) puis modifier le comportement des opérations élémentaires comme "ou" dans les union, "et" dans les intersections, "non" pour les disjonctions ("ou exclusif") et différences. A ma connaissance SPARQL ne dispose pas d'extension spécifique pour la logique floue (fuzzy logic) facilitant l'écriture des requêtes et permettant de calculer et classer des probabilités dans les réponses (par exemple faire une requête fournissant les résultats classés par "pertinence").

De telles extensions de SPARQL sont proposées (exemple: https://biblioteca.sistedes.es/submissions/uploaded-files/1498601637.pdf, ou https://link.springer.com/chapter/10.1007/978-3-642-35975-0_9, ou https://hal.inria.fr/hal-01290932/document, il y en a plein d'autres...), mais cela concerne plus généralement tout le domaine du web sémantique: la logique floue est une chose très étudiée pour les moteurs de recherche et les réseaux sociaux (dont les plus connus qui ont intégré non pas des degrés de "certitude" dans les connaissances qu'ils accumulent, mais des degrés cachés de "convenance" pour leurs objectifs commerciaux changeants, plus ou moins modifiés selon le profilage de leurs utilisateurs). Ces extensions s'appuient sur différents schémas RDFS proposés. Le principe est à chaque fois d'augmenter la base des assertions/triplets par d'autres assertions/triplets qualificatifs (sur les premières assertions) qui peuvent être évalués.

(Wikidata dispose déjà de la notion de "qualificateur" qui peut servir à ça, eux aussi construits sur des triplets RDF, sauf que ce ne sont pas des "déclarations" au sens propre de Wikidata, Wikidata diposant de plusieurs types bien distingués d'assertions: items Qnnn, propriétés Pnnnn, et qualificateurs attachés aux propriétés mais pas gérés sous forme de "pages wiki" autonomes différentes, donc pas directement référençables mais devant passer par un "chemin" RDF, partant de l'item Qnnn, et passant par la propriété Pnnn attachée avec une valeur).

Et Wikidata pourrait en tirer quelque chose et étendre son propre modèle et utiliser une version modifiée de SPARQL (comme FSA-SPARQL) pour en tenir compte sans alourdir les requêtes de tas de déclarations et de tonnes d'expressions (toujours les mêmes, elles sont bien connues et documentées) calculant les probabilités composées. Toutes ces extensions peuvent utiliser RDF pour représenter le tout, donc c'est compatible avec Wikidata qui est avant tout une base de données RDF (peu importe si ces données sont présentées sous forme XML, ou Turtle, ou table Lua, ou table HTML ou table d'une base de données ou un simple fichier CSV, ce ne sont toujours que des ensembles de triplets).

Que tu crois que je crois ! Tu nous fais de la logique modale en plus de la logique floue ?

Je te propose de coder une version SPARQL de blazegraph basée sur de la logique floue, tant qu’à faire de faire standardiser ça par le w3c, et de revenir voir l’équipe de dev avec un plan sur comment on évalue la vérité de chaque déclaration pour alimenter le moteur ! Trop facile ! Et on saura peut-être si tu veux vraiment aller quelque part.

Sinon, plus prosaiquement tu peux déja étudier comment fonctionne le moteur de suggestion, qui mange surement les fréquences d’utilisations des valeurs candidates dans le contexte des valeurs déja rentrées, et de voir si tu peux faire des suggestions d’amélioration.

J'ai avant tout demander que Wikidata clarifie (dans sa présentation visuelle) les types d'éléments pour éviter les erreurs les plus fréquentes (surtout concernant les homonymies de libellés) et qu'il revoit la présentation des résultats de son moteur de recherche (et qu'il arrête d'utiliser certains automatismes faux empêchant l'utilisateur de choisir sereinement entre plusieurs candidats possibles quand le moteur de l'éditeur visuel Wikidata choisit l'option qui s'avère en fait la moins pertinente: il ne sait pas du tout évaluer la pertinence, mais l'utilisateur le peut si on lui présente des éléments d'information essentiels actuellement cachés, comme si le choix était évident et toujours unique). Parmi les extensions de logique floue, je suis certain que le W3C est déjà en train d'étudier ça, ce n'est pas à nous de le faire, même si on peut décider d'en employer une, la standardisation d'une de ces extensions par le W3C, ce n'est pas de notre ressort. Note: la logique modale ne vient pas en plus de la logique floue, c'en est juste un cas particulier et plus limité (qualification seulement du "vrai"), Wikidata gère déjà aussi le faux (par exemple les données des listes d'exceptions connues et acceptées à une contrainte). La logique floue est plus générale et peut qualifier autre chose que seulement le degré de certitude (vrai/faux) selon des axes différents (j'aime pas/un peu/beaucoup/je préfère, jamais/rarement/fréquement/toujours rencontré; ami/proche de; hypothèse ou postulat non vérifié/postulat supposé vrai en attente de démonstration ou de preuve du contraire/résultat démontré; pas/peu/très utilisé; incertitude d'une mesure numérique; sondage d'opinion; données ou estimations statistiques; légalité; taux de risque; coût/bénéfice; quantité de ressources disponibles et nécessaires...).

Dis donc l’expert, tu l’as publié la manière dont tu réduis la logique modale à la logique floue ? Parce qu’en recherchant en deux secondes sur Google j’arrive à confirmer l’intuition qu’on peut faire des logiques modales floues, et que c’est un sujet qui a été étudié par les chercheurs dans la dernière décennie : https://ieeexplore.ieee.org/document/7095540 par ex. Si c’est utile de les combiner, j’ai pas l’impression que ce soit juste une question de « l’une est un cas particulier de l’autre » (surtout qu’il y a des tonnes de variantes dans les deux cas)

D'une, je ne suis pas abonné à l'IEEE, donc ton lien ne donne rien qu'on puisse lire. J'avais pris la peine de donner des liens lisibles (et une recherche sur fuzzy logic SPARQL donne déjà plein de choses et franchement pas grand chose sur modal logic SPARQL (et jamais en associant les deux à SPARQL, ce qui confirme mon intuition que modal logic a toujours été réducteur et que tout le reste a été étudié dans le cas de la logique floue qui a déjà repris la question. L'article que tu sites semble vouloir combiner les deux dans une modal fuzzy logic mais cela reste une fuzzy logic appliquée au cas du seul l'axe modal (vrai/faux), alors que la logique floue porte sur tous les axes possibles (servant à évaluer quelque chose, notamment les mesures numériques qui ne sont justement pas "modales"). Je reste convaincu donc que "modal logic" est un cas particulier, une application de la logique floue, et que c'est dans ce cadre que l'article que tu cites veut se concentrer (pour ne pas avoir à considérer d'autres termes, comme par exemple la notion de comparabilité qui amène à répondre à une question modale comme "a > b ?" ou même "a = b ?" quand les deux variables ne sont pas modales, mais floues).

Tu penses sans doute modal logic est aussi vaste que fuzzy logic, je pense le contraire et que toute extension du premier emprunte au second qui le contient déjà le premier. Il doit y avoir seulement une bataille d'écoles entre experts revendiquant la primauté d'un domaine sur l'autre (et de toute façon quels que soient les progrès faits dans l'étude de l'un cela bénéficie aussitôt à l'autre).

La logique floue va même très loin car elle cherche à évaluer les probabilités avec des distributions de probabilité (permettant de combiner les distributions et pas seulement donner une statistique unique comme la moyenne, l'écart type, une borne maximale ou minimale. C'est un pan tout entier des probabilités où on ne travaille pas que sur une quantité numérique unique mais sur des fonctions de distribution (avec leurs lois propres, dont quelques classiques comme: Poisson, Gauss, hystérésis, seuil, peigne de Dirac...). Les opérateurs logiques classiques (et, ou, non, puis ceux qui en dérivent directement comme la disjonction ou la différence) se réécrivent alors sous forme de combinaisons de fonctions de distribution: on ne peut alors pas répondre à "a > b?" mais donner une fonction de distribution dont on peut cependant donner certaines caractéristiques comme des moyennes et écart-types à partir duquel "a > b" est vrai selon les seuils propres à a et b.

Toute la logique floue n'est évidemment pas encore décrite et modélisable sous forme RDF (pas plus la question de la modalité) mais quelques modèles fonctionnent déjà pour donner quelques caractéristiques (à condition d'imposer le type de distribution supposé, par exemple gaussien). Les connaissances humaines pourtant portent sur des éléments qui n'obéissent pas tous aux mêmes types de distribution (les plus fréquents sont gaussiens, mais Wikidata contient des tas d'éléments qui n'ont pas ce comportement et en plus ils sont couvent corrélés et non indépendants mais on a du mal a connaitre leur degré de corrélation, par exemple avec un test du chi², valide pour un comportement gaussien, et donc aussi à modéliser la distribution de cette corrélation).

Même si on n'intégrait dans Wikidata des inférences de type "modal" uniquement, on ferait de sacrés progrès pour répondre à pas mal de problèmes. Mais j'en reviens aux articles initiaux qui eux voyaient cela comme des cas particuliers permettant de répondre aux question modales (à priori toutes...), mais pas seulement (non restriction à seul axe), toutefois avec un type de distribution limitée (exprimable sous forme d'un seul nombre et pas sous forme d'une fonction de distribution, donc facilement calculable et très facile à exprimer en RDF). C'est pour ça que j'ai cité FSA-SPARQL ou les autres liens (lisibles, eux!, pas juste un titre et un paragraphe de présentation).

Donc je te prends à vouloir encore dévier de la question initiale et vouloir compliquer le problème. Notre problème sur Wikidata reste le même: comment gérer l'incertitude (qui est asmises depuis le début, dès lors qu'a été prises la décision de ne justement PAS utiliser OWL mais rester assez proche du RDF et entièremetn compatible avec lui), et présenter cette incertitude (même si on ne sait pas encore l'évaluer et demandera d'autres développements et des avancées dans les standards dont dépend Wikidata, et des travaux certainement déjà en cours au W3C là-dessus car je ne doute pas du tout que ça intéresse bigrement, à commencer par Google et les réseaux sociaux qui se sont lancés dans l'IA et y mettent le paquet tant ils savent qu'ils vont y gagner beaucoup et ambitionnent de devenir les oracles du monde et indispensables pour diriger nos vies).

Bah écoute si t’en es convaincu c’est très bien pour toi, perso j’ai l’impression que tu ne sais tout simplement pas de quoi tu parles quand tu parles de logique modale. Je vois pas trop comment tu pourrais remplacer une modalité de croyance ou des notions de temporalité https://plato.stanford.edu/entries/logic-modal/#TemLog par des probabilité, ça n’a absolument rien à voir.

À part ça sachant qu’il n’y a déjà pas vraiment à l’heure actuelle d’inférence dans Wikidata, je vois pas trop à quoi riment tes digressions sur la logique floue.

"Il n'y a pas d'inférence dans Wikidata" ? Certes c'est une base de données, mais elle a tout autour (jusque dans son interface UI) des outils qui font directement des inférences., et interviennent pour modifier directement et automatiquement ce que l'utilisateur saisit (même en faisant des contre-sens). Affirmer qu'il n'y a pas d'inférence alors que Wikidata justement doit servir à ça, et qu'il essaye d'en faire lui-même, et même qu'il contient une bases de règles d'inférence, que l'UI de Wikidata (et certains bots intégrés en tâches de fonds) utilise également directement, c'est un comble !

Si je croyais à ton affirmation alors Wikidata n'est plus qu'une base de données relationnelle (très pauvre: une seule table à 3 colonnes formant un index primaire, et deux index secondaires pour former les relations ternaires, plus une table des entités, la même que la table des pages du wiki). Wikidata (ou Wikibase) c'est bien plus que cela!

Enfin tu digresses encore, car tu introduits maintenant la temporalité (logique temporelle) et tu la confonds avec une logique modale; et la modalité de croyance c'est une invention de ta part, ce qui existe c'est une logique des sondages (basée sur les probabilités et des tests sur des échantillons); les deux logiques temporelles et logiques des sondages sont là encore des applications de logique floue, et sinon dans les deux cas la logique s'appuie (pour l'évaluation des opérations logiques) sur les probabilités (des formules très étudiées et bien connues).

Et je n'ai JAMAIS dit que je les "remplaçais" par des probabilités, mais juste que la logique floue se base sur la création de règles d'inférence avec des opérations élémentaires dont l'évaluation "s'appuie" sur les probabilités. Bref tu lis en diagonale en fonction de ce qui t'arrange, et mal. Et en plus si tu croies connaitre les sujets de logique, franchement c'est aussi superficiel, et tu inventes aussi (donc tu ne sais pas de quoi tu parles, en tout cas pas pour me répondre). Tu n'a toujours pas compris ce qu'était réellement Wikidata.

Bref tu digresses, et cherche encore à sortir de mon sujet initial, comme si ma demande initiale était aberrante. Alors qu'elle est parfaitement fondée sur des problèmes constatés par tout le monde (qu'on peut expliquer mais qui en attendant sont pénibles et imposent une charge de maintenance croissante, et intenable à terme, dont une bonne part vient de bugs de Wikidata dans son UI et dans ses automatismes, et non de la faute volontaire des utilisateurs qui font honnêtement ce qu'ils peuvent face à cette interface confuse qui semble réagir comme bon lui semble, et qui les oblige à faire des tonnes de vérifications très lourdes).