User talk:Verdy p

From Wikidata
Jump to: navigation, search
Logo of Wikidata

Welcome to Wikidata, Verdy p!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

  • Introduction – An introduction to the project.
  • Wikidata tours – Interactive tutorials to show you how Wikidata works.
  • Community portal – The portal for community members.
  • User options – including the 'Babel' extension, to set your language preferences.
  • Contents – The main help page for editing and using the site.
  • Project chat – Discussions about the project.
  • Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards!

 — billinghurst sDrewth 00:17, 1 November 2013 (UTC)

"comprend" n'est pas inverse de "sous-classe de"[edit]

Salut, je te contacte pour te dire que tu as fait une utilisation malheureuse de la propriété "comprend" dans l'élément "région française". Il est assez malheureux d'utiliser "comprend" pour dire que les instance d'une sous-classe de la classe sont des instances de la classe parente (cf Help:BMP et Help:Classification). Il faudrait plutôt utiliser une propriété dont j'ai proposé la création (et qui tarde malheureusement à venir : Wikidata:Property proposal/Generic § subclass : comprend ne devrait être utilisé, principalement, que pour dire des trucs comme "la france comprend Paris". N'hésite pas à supporter la propriété. author  TomT0m / talk page 15:29, 22 February 2016 (UTC)

j'avais déjà corrigé avant ton message dans les régions concernées... Verdy p (talk) 15:31, 22 February 2016 (UTC)
OK j'ai mal compris ton message. Effectivement c'est "comprend", faute de mieux pour l'instant, car on n'a pas encore "sous-classes". Mais si justement ça fait "gueuler" l'analyseur, ça motivera la création de cette propriété.
Mais tout le monde n'est pas d'accord sur la distinction entre "objet" et "classe" (voire "métaclasse", "méta-métaclasse", etc.) hérité du C++ ou Java, alors que d'autres languages considèrent que tout objet est lui-même une classe capable de s'instancier en objet dérivé (par exemple Javascript), car ils ne discriminent pas les données et méthodes (ce sont des propriétés), en revanche ils peuvent inclure la notion d'objet "abstrait" (auquel certaines propriétés ne sont pas implémentées mais nécessaires et utilisées par les méthodes de l'objet):
  • En JavaScript (ou Lua) cette notion d'"objet abstrait" n'existe pas non plus (toute propriété a un nom, si elle n'est pas implémentée, elle a simplement une valeur "nulle" de type "nul"), donc Javascript n'a pas de classe, métaclasse, etc. Tout objet déjà instancié peut lui-même se surcharger avec des propriétés supplémentaires, chose impossible en C++ et Java.
  • C++ et Java distinguent "classe" et "objet" (et métaclasse, classe abstraite, etc.) car ils utilisent un typage fort (statique) et n'autorisent pas de changer le type des propriétés définies, ce qui interdit de changer une propriété d'un objet instancié :
    • d'un type "nul" en un type de méthode, ce qui ne survient qu'avec la dérivation d'une classe abstraite en classe concrète, ou
    • d'un type "nul" en un type de données (impossible sans définir d'abord une classe dérivée qu'on instancie ensuite en un objet).
    Ces deux languages utilisent une résolution de type statique à la compilation. Ils ajoutent la complexité supplémentaires des "méthodes virtuelles" (en Javascript toutes les méthodes sont virtuelles un objet peut lui-même remplacer une de ses méthodes par une autre, même venant d'un autre objet, ou peut la supprimer en la remplaçant par une valeur "nulle", en C++ on ne supprime pas une propriété, tout au plus on peut la masquer pour la rendre inaccessible par certains autres objets).
    Il faut des prouesses en C++ et Java pour leur faire gérer un typage dynamique comme Javascript, en définissant une classe utilitaire particulière contenant un dictionnaire interne de propriétés, deux méthodes de type "accesseur", getProperty et setProperty, et une méthode ou un champ "prototype" pour connaitre l'objet parent: cette classe utilitaire est prédéfinie comme parente de tous les objets en Javascript, y compris les types de données les plus simples comme les nombres et chaines.
Si on sort du domaine de la programmation, "classe" et "objet" ne sont pas pertinents dans Wikidata (on se restreint à une description façon C++ ou Java). Le concept plus général de Wikidata est celui d'élément (façon Javascript ou Lua) muni de propriétés. Dans ce cas "X comprend Y" et "a comme sous-classe Y" sont des notions équivalentes. Vouloir distinguer "classe" et "objet" dans Wikidata nous obligera à ajouter la même complexité que C++ avec des types abstraits, des métaclasses, des propriétés "virtuelles", etc. et une inférence de type fort, et on aura bien des difficultés à tout modéliser.
Je suis donc partisan d'une vision plus généraliste (façon Javascript/Lua), et de supprimer de WikiData la distinction entre "classe" et "instance" (donc "isA"/"isInstanceOf" et "isPartOf" sont selon moi équivalents). N'oublions pas que Wikidata ne contient que des données (aucune méthode) dans ses propriétés. Ce qui revient alors à ne garder que les propriétés "nature de l'élément" (isA) et "comprend" (includes), mais éliminer "sous-classe de" (qui n'est qu'une restriction façon C++ de "nature de l'élément"), et donc pas besoin alors d'une autre propriété "a comme sous-classes".
Reste à savoir alors comment dans Wikidata les propriétés d'un élément parent sont héritées par l'objet enfant. Pour moi, toutes les propriétés sont héritées à moins qu'elle soient surchargées (redéfinies) dans l'objet enfant, et dans ce cas Wikidata utilise la transitivité par défaut (sinon il faut l'éliminer explicitement par un qualificateur "sauf"/"except" dans l'élément parent, ou par une propriété explicitement de valeur "nulle" dans l'élément enfant si la propriété parente n'est pas applicable à l'objet enfant, ce qui dès lors en fait un type en fait différent et pas une réelle instance compatible avec l'objet parent, ce n'est pas une vraie dérivation)
"X est un Y" est alors partiellement faux si Y annule une propriété dérivée de X, et donc X est plutôt un "pseudo" Y ! A mon avis on évitera les problèmes en créant un autre élément parent commun P pour X et Y, en disant "X est un P" et "Y est un P" et en n'y mettant que les propriétés pertinentes, sans mettre alors aucune relation entre X et Y.
En disant les choses plus simplement, nous contenter uniquement de décrire des ensembles, et inclusions d'éléments ou d'ensembles dans des surensembles, tout élément X étant lui-même un ensemble se contenant lui-même et contenant tout autre élément Y qui affirmerait "Y:nature de l'élément:X" ou (transitivement) tout élément Z affirmant "Z:nature de l'élément:Y" (les propriétés inverses avec "comprend" seraient également transitives)
On fusionnerait aussi "est une partie de" et "nature de l'élément" (pour les distinctions éventuelles, utiliser plutôt un "qualificateur" de "domaine" afin de pouvoir choisir entre plusieurs jeux de parcours dans un même "domaine", aussi bien dans le sens descendant que le sens inverse), en une seule propriété "est".
Plein de propriétés dans Wikidata sont redondantes (exemples : Pays, localisation administrative, sous-classe de, nature de l'élément, partie de...) et ne sont qu'une seule et unique propriété "est"/"partie de", mais spécialisées dans des "domaines" différents : "pays" et "localisation administrative" sont dans le même domaine "division administrative", qui est à distinguer cependant du domaine "division électorale" et du domaine "division territoriale/géographique/lieu" (qui lui-même contient des sous-domaines spécialisés liés à un événement qui se passent dans un lieu: "lieu de résidence", "lieu de naissance", etc.), et à distinguer aussi des domaines "nationalité" et "citoyenneté" (lié au droit d'une personne) ou du domaine "lieu d'activité/de travail" (lié non pas à la personne même mais à une autre personne qui l'emploie).
Verdy p (talk) 14:10, 25 February 2016 (UTC)
Tu n'y est pas du tout à mon avis.
J'y suis parfaitement, et tu le démontres toi-même ci-dessous avec l'exemple des couleurs : Verdy p (talk) 13:36, 25 February 2016 (UTC)
La notion de "classe" existe depuis bien longtemps en dehors de la programmation, en philosophie par exemple, et est très utile dans le cas de Wikidata parce qu'elle permet de donner une fondation solide à Wikidata et a son ontologie. Le principe de distinction classe/jeton ( https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction ) est super utile et fournit des réponses à des questions qui sont sinon matière à opinion (cf. Are colors instance-of or subclass-of color ) et donc soumises au sens du vent et des retournement de mode communautaire.
Il vaut mieux partir sur des principes solides (...)
Il n'y a rien de plus solide que la théorie des ensembles (dont tous les éléments ne sont QUE des ensembles même réduits à un singleton. Dans Wikidata, il suffit de dire qu'un "élément" représente aussi l'ensemble initialement singleton, qui le contient, mais qui peut en contenir d'autres.) Verdy p (talk) 13:36, 25 February 2016 (UTC)
(...) vu qu'il sera de toute façon hyper difficile de revenir sur les erreurs initiales pour des tas de raisons, il s'agit de rendre l'ensemble prédictible et lisible à mon avis.
Tout le monde peut comprendre la théorie des ensembles (dont l'équivalent dans MediaWiki est celle des catégories, sauf que les catégories de Mediawiki n'ont actuellement pas de "qualificateur"). Celle de "classe" et d'instance n'est PAS du tout pertinente (je l'ai démontré plus haut, cela apporte une complexité énorme qui revient à faire de la programmation C++ ou Java dans Wikidata, alors que ce n'est PAS du tout nécessaire !)
La théorie des ensembles répond de façon exacte et prédictible à toutes les questions (surtout ici dans Wikidata où on ne traite que d'ensembles discrets et finis). Verdy p (talk) 13:40, 25 February 2016 (UTC)
Les problèmes de programmations ne sont à mon avis pas du tout pertinent vu qu'on est dans la pure modélisation, et certainement pas dans le code sur Wikidata. author  TomT0m / talk page 13:18, 25 February 2016 (UTC)
C'est ce que j'ai dit plus haut ! C'était ma conclusion: j'ai pris la comparaison entre Java/C++ et Javascript/Lua pour montrer en quoi la notion de classe est inutilement complexe pour les données et qu'en terme de modélisation de données, c'est la vision comparable à Javascript qui est pertinente: tout élément est aussi une classe sans avoir à le préciser. J'ai bien parlé de modélisation. Si tu veux avoir des classes dans Wikidata tu te retrouveras à gérer la même complexité que C++ en voulant faire du typage fort et parler de métaclasses, méta-métaclasses, etc. C'est insoluble dans C++ et Java, qui pour les cas complexes en viennent à faire du typage dynamique comme Javascript pour lever les contraintes insolubles et ensuite permettre aux objets de déclarer eux-même s'ils supportent ou pas une propriété affirmée dans un objet parent (on a dans Wikidata le qualificateur "sauf" dans le sens parent vers enfant, équivalent à l'opérateur "moins" en théorie des ensembles, mais heureusement pas dans l'autre sens!). Verdy p (talk) 13:36, 25 February 2016 (UTC)
Sinon dans Wikidata on a la notion de "sous-propriété" qui est très utile et qui n'existe pas du tout dans (bien des) langages de programmation. Si tu t'intéresse à la question tu peux aussi lire Help:Classification écrit par mes soins que j'ai proposé comme politique de projet (commentable sur Adopt_Help:Classification_as_an_official_help_page si ça t'intéresse, commentaires souhaités bien entendu) et aussi les articles de frame language (Q13405544) View with Reasonator View with SQID qui fournissent un histo du point de vue programmation mais côté IA, pas côté POO qui ont suivi des voix parallèles mais distinctes. author  TomT0m / talk page 13:22, 25 February 2016 (UTC)
Les sous-propriétés sont inutiles, ce ne sont que des combinaisons de propriétés simples côte-à-côte (y compris pour les propriétés utilisées comme qualificateurs, il suffit de mettre plusieurs qualificateurs). Verdy p (talk) 13:36, 25 February 2016 (UTC)
D'ailleurs je ne suis pas le seul à penser que ta volonté de distinguer classes et instances sera vaine. Le standard RDF ne te suit pas là-dessus. Et la page de discussion que tu cites en vient à discuter de l'ambiguité ou l'impossibilité de dinstinguer des affirmations devant distinguer "est une instance de" de "est une sous-classe de". C'est une complication totalement inutile. Restons en à la très solide théorie des ensembles avec "est un"/nature de l'élément" et son inverse "comprend"/"contient"/"inclut" pour ne pas tomber dans les piège des classes abstraites (comme C++ ou Java) ou métaclasses, méta-métaclasses (insoluble dans C++). C++ ou Java l'ont fait pour empêcher un objet (une instance) de pouvoir s'instancier lui-même en un autre objet et devenir le "type" des objets instanciés, et on n'a strictement aucune raison de mettre ce type de restriction dans Wikidata où tous les éléments doivent être "dérivables" au sens POO.
Donc oui, je soutiens la vision RDF (comparable à celle de JavaScript, Lua, et même PHP, même en ne parlant que des données et pas de méthodes qui sont en fait des pseudo-données un peu spéciales qui ne se valorisent qu'après les avoir exécuter mais dont il est impossible de faire une inférence autre car c'est opaque, non instanciable, immutable et non dérivable et il est impossible d'en connaitre des propriétés autres que celle de dire "c'est du code", à moins que ce code expose son propre source et que le langage permette de modifier ce source à la volée et le rendre à nouveau exécutable dans sa forme modifiée). Dans RDF il n'y a aucune classe, il n'y a que des éléments qui sont aussi, chacun, l'ensemble qui le contient. Et c'est très solide (merci à la théorie des ensembles, qui permet une résolution rapide, précise et prédictible de toutes les questions en un temps fini, dans le cas des ensembles discrets et finis (ce qui est le cas de Wikidata qui a un nombre discret et fini d'éléments).
Je vote donc pour la suppression de la propriété "sous-classe de"
Et ne garder que "nature de l'élément"/"est un" et son inverse ("comprend")
Ou quand il s'agit de partie uniquement (inclusion partielle) "compose" et son inverse "est composé de" : ce sont des propriétés similaires, sauf qu'il y a une restriction sur la partie incluse, qui pourrait s'exprimer là aussi avec un qualificateur de quantification et se résoudre alors avec une seule paire de propriétés inservisibles et non deux:
  • La propriété "compose/partie de/appartient à" est identique à la propriété "nature de l'élément" munie du qualificateur (de quantification) "inclusion: partielle"
  • La propriété inverse "comprend/possède/est composé de" est identique à la propriété "comprend" munie du qualificateur (de quantification) "inclusion: partielle"
  • La propriété "nature de l'élement/est un/est une sous-classe de/est une instance de" a pour qualificateur (de quantification) implicite (par défaut) "inclusion: en totalité".
  • La propriété inverse "a pour sous-classe/a pour instance" a pour qualificateur (de quantification) implicite (par défaut) "inclusion: en totalité".
Voilà qui est clair ! Verdy p (talk) 14:28, 25 February 2016 (UTC)
Ça ne tient pas du tout la route. Comprend (composé de) est l'inverse de partie de. Du coup si l'univers comprend la terre, ce sur quoi on devrait être d'accord, de tes axiomes on déduit la terre est une instance de l'univers, ce qui n'a aucun sens. author  TomT0m / talk page 14:39, 25 February 2016 (UTC)
Ca tient la route car tu oublie la quantification ! (réponse: "la terre est une instance **partielle** de l'univers": "inclusion: partielle"; bien que je n'aime pas le mot "instance" ici, pas plus que le mot "classe", je lui préfère les termes plus généraux de la première paire, avec leur qualificateur: "la terre compose **partiellement** l'univers"). De plus je n'avais pas mis un certain nombre de synonymes dans ce contexte, chose rectifiée (sans ces synonymes, tu ne pouvais pas conclure ta phrase). Bref tu ne veux pas lire ou pas comprendre. Verdy p (talk) 14:44, 25 February 2016 (UTC)
Réponse globale : hum, tu plaisantes ? Je ne vois aucune cohérence dans ton message. Faire une distinction classe/instance c'est faire une distinction sous-ensemble/élément à la base de toute théorie des ensemble digne de ce nom. Et le système de catégorisation est un bien pâle ersatz pour une théorie des ensemble, il est moins fort que la théorie naïve des ensemble. author  TomT0m / talk page 14:16, 25 February 2016 (UTC)
Parler de classe et d'instance est incompatible avec la théorie natïve des ensembles. N'oublie pas en plus qu'ici on parle d'ensembles discrets et finis (même s'ils sont extensibles ici bien entendus).
L'ersatz n'a pas une pale couleur dans ce contexte, on est exactement dans le même cadre: ensembles discrets et finis (et je ne parle pas du tout des articles ou fichiers qu'on met dans les catégories, mais juste des catégories elles-mêmes qui forment une hiérarchie avec recouvremements de branches communes et plusieurs racines, exactement comme les ensembles discrets et finis en général). Si on ajoute les autres pages, là ce ne sont que des éléments terminaux qui ne sont pas des ensembles (ou alors juste l'ensemble singleton qui contient chacune de ces pages, mais ces ensembles ne sont pas extensibles, au contraire des éléments de Wikidata qui peuvent toujours devenir "parents" d'autres éléments, dans de nouveaux triplets de connaissance, ces éléments Qxxx ou Qzzz sont à droite ou à gauche dans des triplets Qxxx:Pyyyy:Qzzz , l'élément central Pyyy est une "propriété", les noms des éléments sont des triplets Qxxx:name-lang:"chaine", les descriptions sont des triplets Qxxx:description-lang:"chaine", les alias sont des triplets Qxxx:alias-lang:"chaine", les références wikipédia/autres sont des triplets Qxxx:wiki-lang:"nom d'article", les catégories sont Qxxx:wiki-lang:"Catégorie:nom de catégorie", etc.). Verdy p (talk) 15:47, 25 February 2016 (UTC)
Ça n'a rien du tout à voir avec l'aspect discret et fini ou pas des ensembles. Dans toute théorie des ensemble, il y a une relation d'appartenance fr:Appartenance_(mathématiques) dont "instance de" joue le rôle, et une relation de sous-ensemble fr:Inclusion_(mathématiques) dont "sous-classe de" joue le rôle. Les deux non rien à voir avec le fait que mon bras fait partie de mon corps. Bien qu'on puisse exprimer ça sous la forme "mon bras appartient à l'ensemble de mes membre" si on veut, mais c'est pas la manière la plus naturelle de faire. author  TomT0m / talk page 16:02, 25 February 2016 (UTC)
Non je ne plaisante pas. C'est toi qui complique les choses (et est totalement incohérent dans les tentatives de justrifier "sous-classe de" dans la page de discussion: tout le monde te démontre que tu introduits des contradictions insolubles) ou ne veux pas lire. D'ailleurs plein de gens sont opposés à toi dans la page de discussion sur "sous-classe de" (qui à mon avis ne sert strictement en rien modélisation de données (c'est juste une notion pour du code et uniquement dans certains languages POO qui se "sont pris les pieds" dedans avec des questions insolubles).
Tu me parles plus haut de "classe en philosophie" mais c'est hors sujet (et impossible de faire des décisions ou répondre à des questions en philosophie, donc ce n'est pas pertinent pour Wikidata, la philosophie s'attarde à chercher des éléments de comparaisons entre des choses différentes, en faisant la même chose que la religion ou la mythologie avec les allégories).
J'ai donné le système de catégorisation de MediaWiki comme exemple de base, car c'était justement et totalement exactement le même que celui de Wikidata, avant l'introduction des qualificateurs (qui permettent d'inclure une restriction, mais ne sert pas du tout à vouloir discriminer classes et instances): les qualificateurs de Wikidata correspondent en théorie des ensembles à la même chose que l'opérateur "moins" (il permet de ne pas inclure la totalité d'un ensemble indiqué mais de soustraire une partie en intersection, par exemple souscrire du territoire totale d'un pays celui qui n'était pas dans les dates données dans un qualificateur de date).
Verdy p (talk) 14:38, 25 February 2016 (UTC)
Les qualificateurs ne changent rien au fond du problème. Appliquer un qualificateur revient à changer complètement la sémantique de la propriété, donc ne lève en rien une confusion, ça ne fait que la reporter.
Dans ton système, comment modéliserait tu les proposition suivantes :
  • ton bras fait partie de ton corps
  • ton bras est un bras.
  • Les bras d'adultes sont une partie des bras humains
On a dans Help:BMP, qui est largement consensuelle comme page, les réponses "classiques" de l'ontologie à ces questions.
D'un autre côté tu restes bloqué sur des questions ultra classique de "is a" https://en.wikipedia.org/wiki/Is-a d'un côté et tu ne comprend pas que la relation "sous-classe de" est analogue de la relation de sous-ensemble entre deux ensemble, bien que tu invoque la théorie des ensembles. Invoquer la théorie des ensemble n'est pas du tout un argument pour la supprimer, au contraire. C'est à se demander si tu tiens vraiment à une cohérence de discours. author  TomT0m / talk page 15:35, 25 February 2016 (UTC)
Je veux bien qu'on adopte les "classes" mais à la seule condition de supprimer les "instances". Bref n'avoir QUE des classes et sous-classes (pas besoin des instances, chacune définit sa propre classe, initialement un singleton jusqu'à ce qu'on crée un nouvel élément). Bref pas la peine de chercher si X est une sous-classe de Y ou si X est une instance de Y ce sera toujours les deux en même temps. Pas besoin de dinstinguer instances et sous-classes. Tout est classe. Pas besoin de méta-classe alors. Bref cela ne change pas mon discours, mais tu a introduit un nouveau vocabulaire en cherchant à le distinguer du sens courant. Les éléments de Wikidata sont aussi des classes comme tu l'entends, mais ne sont pas restreints à être juste des instances et encore moins restreints à ne pas être dérivables/sous-classables.
  • "ton bras":"est un":"ton corps" (quantification: "inclusion":"partielle"), donc aussi son inverse, "ton corps":"comprend":"ton bras" (quantification: "inclusion":"partielle")
  • "ton bras":"est un":"bras" (quantification: "inclusion":"totale"), donc aussi son inverse, "bras":"comprend":"ton bras" (quantification: "inclusion":"totale")
  • "bras d'adulte":"est un":"bras humain" (quantification: "inclusion":"totale"), donc aussi son inverse, "bras humain":"comprend":"bras d'adulte" (quantification: "inclusion":"totale")
Je dois ajouter je pense (tu l'as oublié je pense):
  • "ton bras":"est un":"bras d'adulte" (quantification: "inclusion":"totale")
Mais même avec ça on ne peut pas encore conclure que "ton bras" est partie de "corps humain" (ni partiellement, ni totalement) ; il faut ajouter
  • "corps humain":comprend:"bras humain" (quantification: "inclusion":"partielle") donc alors son inverse, "bras humain":"est un":"corps humain" (quantification: "inclusion":"partielle")
Après ça même sans tenir compte des qualificateurs on peut faire une conclusion:
  • "ton bras":"est un":"corps humain", mais il manque la quantification, pour ça il faut une règle de composition des quanfifications en chaine:
  1. "inclusion:totale" + "inclusion:totale" = "inclusion:totale"
  2. "inclusion:totale" + "inclusion:partielle" = "inclusion:partielle"
  3. "inclusion:partielle" + "inclusion:totale" = "inclusion:partielle"
  4. "inclusion:partielle" + "inclusion:partielle" = "inclusion:partielle"
  • et ajouter que la quantification par défaut pour "inclusion:" est "totale" (il n'y a pas "inclusion:vide") si une affirmation ci-dessus (sur les bras, etc.) ne le précise pas.
Alors tu conclus finalement : "ton bras":"est un":"corps humain" (inclusion:partielle), ou son inverse "corps humain":"comprend":"ton bras" (inclusion partielle)
Les relations inverses conservent leur quantificateur (ou autre qualificateur) à l'identique.
C'est cohérent ! Pas besoin de distinguer classes et instances, pas besoin de sous-classes.
En revanche, il faut ajouter à la base de connaissance des règles d'inférence sur les qualificateurs (dont les quantificateurs) pour leur composition en chaine (ces règles sont ausi des triplets dont les 3 éléments sont ordonnés, il n'y a pas de commutativité de l'opérateur "+" ci-dessus (ou alors il faut préciser cette commutativité en qualificateur pour l'une ou l'autre des propositions 2 et 3 ci-dessus, ce qui peut réduire le nombre de règles nécessaires quand le nombre de valeurs possibles à combiner est supérieur à 2). Verdy p (talk) 16:12, 25 February 2016 (UTC)
(edit conflict) (ahah) Alors : 1. tu maintiens une distinction entre les deux relations, tu le fais juste d'une manière différente et non orthodoxe, différente des orientations communautaires depuis le départ. Ça fait beaucoup d'inconvénients et pas d'avantage. Le côté non orthodoxe fait qu'on a probablement des contradictions cachées et peu de littérature. 2. tu pars du français. C'est pas dit du tout que ça se transfère dans d'autres langues. Du coup ce ne serait un avantage hypothétique que pour les français (et encore je suis pas sur que parler d'inclusion partielle, en admettant la cohérence de ta proposition, soit bien intuitif en français). 3. Je vois pas bien l'intérêt de vouloir à tout prix faire disparaître la notion d'instance. author  TomT0m / talk page 16:21, 25 February 2016 (UTC)
Il n'y a strictement rien ci-dessus qui s'appuie sur le français. C'est un raisonnement purement abstrait, traduis les mots comme tu veux dans les règles ci-dessus, ce sera exactement la même chose (Wikidata raisonnne non pas avec les mots mais avec les identifiants Qnnn et Pnnn, les noms ne sont que les valeurs de leurs propriétés "nom-langue", ici "name-fr".
C'est orthodoxe, on ne s'appuie que sur les triples RDF de base, plus les qualificateurs qu'on a déjà dans Wikidata pour apporter des restrictions ensemblistes, au sens de l'opération E-F entre deux ensembles E et F). On reste totalement dans la théorie des ensembles discrets et finis. Verdy p (talk) 16:34, 25 February 2016 (UTC)
Jusqu'à ce que tu aies démontré le contraire, ça n'apporte rien. L'orthodoxie de triplets RDF "de base" mais pas de base du tout parce qu'il faut rajouter des qualificateurs est plus que douteuse. author  TomT0m / talk page 16:49, 25 February 2016 (UTC)
D'ailleurs en parlant de rdf, rdf:type est assez analogue à "instance de", même si évidemment instance de sur Wikidata ne se traduit pas du tout comme ça dans l'export RDF. author  TomT0m / talk page 16:50, 25 February 2016 (UTC)
Ce que je veux éviter dans Wikidata c'est de se retrouver bloqué sur des affirmations comme "A est instance de B, B est instance de C", et se poser alors la question si B est une classe (1re affirmation) ou pas (2e affirmation) et ne pas pouvoir alors dire que A est instance de C. On pourra le dire en ne distinguant pas "a pour sous-classe/a pour classe dérivée" de "a pour instance/inclut", et en ne distinguant pas "est une sous-classe de/est un/est de type" de "est membre de/fait partie de". Car ces notions ne se distingue pas qu'en terme de différence POO de type "classe-instance" ou de composition, mais sur des qualificateurs de restrictions, et notamment des quantifications, dont la complexité dans le monde plus général de la connaissance est bien plus élevée que cette seule notion POO simpliste de classe-instance (qui par ses insuffisances conduit à des contrdictions ou des bloquages ou à complexifier à outrance les problèmes en parlant de méta-classe, classe abstraite, instance virtuelle, et autres règles de masquage de visibilité publique/protégé/privé pour bloquer certains héritages transitifs : les qualificateurs ou quantificateurs de Wikidata peuvent faire la même chose, mais en mieux).
Après ça, définir un vocabulaire avec "classe" et instance" est possible, mais ce ne sont que des "alias" comprenant chacun une propriété et un qualificateur (restriction ensembliste, dont fait partie les quantificateurs, mais extensible à divers domaines de qualification):
Entre une "classe" et l'une de ses "instances" et le qualificateur est un quantificateur "inclusion:totale", l'instance possède toutes les propriétés de sa classe, la transitivité des propriétés s'applique à moins qu'on ait employé un qualificateur "sauf:élément" dans "identifiant de classe:a pour instance:identifiant d'instance" ou dans la relation inverse "identifiant d'instance:a pour classe:identifiant d'instance". Exemple, "humain:a pour instance:toi" (sauf:jambe), dans le cas où tu portes une jambe de bois, et son inverse "toi:est un:humain" (sauf:jambe), parce que la base de connaise dit "humain:comprend:jambe" (tous les humains ont une jambe, en général, mais il faut une exception pour toi).
On voit que dans ce cas se restreindre aux notions de classes et instance est bloquant (le piège de C++ ou Java), alors que cela se résoud très bien en faisant de tous les objets également des classes (comme le fait Javascript ou Lua), et en utilisant les qualificateurs (purement ensemblistes) de Wikidata (seulement là où c'est nécessaire pour apporter une restriction), qui peuvent être des quantificateurs génériques, ou des qualificateurs spécialisés (cas de la jambe, partie du corps humain) adaptés aux connaissances qu'on veut modéliser.
Bref je ne vois encore strictement rien qui différencie "nature de", "est de type", et "sous-classe de", et rien non plus qui différencie "comprend" et "a pour sous-classe".
Enfin je n'ai pas dit qu'il "faut" ajouter des qualificateurs. Il n'en faut que là où il y a une restriction de sens ou de portée des propriétés du parent vers l'enfant. C'est une restriction d'héritage (ce qu'on ne peut pas faire du tout en C++, qui ne permet QUE le masquage de visibilité, ou la surcharge de méthodes virtuelles pour que l'objet enfant garde en toute circonstance son comportement d'enfant sans parfois avoir les propriétés et méthodes du parent selon la façon dont on s'adresse à lui); un défaut qui en terme de base de connaissance conduirait aussi à des fausses conclusions sur l'enfant, dans Wikidata puisqu'on n'a pas de méthodes virtuelles ni de masquage, ce qui le remplace ce sont les qualificateurs apportant des restrictions, mais il nous manque la possibilité de faire de l'inférence sur les qualificateurs, en intégrant des connaissances sur leur combinaison.
Ce qui est mal compris dans Wikidata c'est le sens de "comprend": dans un cas c'est une inclusion partielle (exemple restriction à une partie du territoire), dans d'autres c'est une dérivation (le sens POO que tu soutiens) avec inclusion totale des propriétés de la classe parente dans la sous-classe, plus des propriétés additionelles: il manque des qualificateurs pour l'inférence, les termes comme leur définition sont ambigus. Idem pout le sens donné à "nature de". Et ce ne sera pas plus simple pour autant en ajoutant "instance" au vocabulaire (et encore plus compliqué à traduire et faire comprendre). Alors qu'avec des qualificateurs c'est tout de suite compréhensible car explicite et l'inférence est possible. Verdy p (talk) 17:07, 25 February 2016 (UTC)
La réponse est pourtant claire, on ne déduit jamais. Sinon on se retrouve avec des absurdité comme dire que Paris est un type de division administrative. Donc tu essayes de résoudre un problème qui n'existe pas. author  TomT0m / talk page 17:18, 25 February 2016 (UTC)
Non, on déduit des tas de choses dans Wikidata, qui a des propriétés décrites comme "transitives". Wikidata n'est pas qu'un amas d'informations isolées. L'exemple type est "partie de", l'autre exemple type est "est un" (sous-classe de).
D'autre part "l'absurdité" que du mets à la fin sur Paris est parce que tu as encore une fois ignoré les qualificateurs et fait des inférences incorrectes sur des qualifications différentes !
Bref tu passes encore à côté avec des conclusions hâtives et fausses ignorant les règles d'inférence. Verdy p (talk) 18:06, 25 February 2016 (UTC)
On va nulle part, je parlais évidemment pas de ta solution mais de "instance de". Tu dois en passer du temps à rédiger ces bêtises. Fin de la discussion. author  TomT0m / talk page 19:24, 25 February 2016 (UTC)
Déjà tu ne parles pas français, et je n'accepte pas de telles insultes. Simplement tu ne veux rien comprendre ou ne comprends rien (pas plus moi que les autres qui pourtant te démontrent que tu vas dans le mur alors qu'ils te démontrent les incohérences et contradictions que cela entraine car tes règles de base sont contradictoires, par exemple dans Help:BMP, ou fondées sur rien d'autre que ce que permet le C++).
Tu persistes à vouloir appliquer un modèle C++, fait pour le code avec un typage fort, à Wikidata qui ne contient que des données (pas de code) et pas de typage fort. Hors ce modèle n'est absolument pas nécessaire, le modèle C++ est une restriction du modèle général, absurde dans le monde réel, uniquement fait pour la compilabilité de son code et de son typage fort. Verdy p (talk) 19:29, 25 February 2016 (UTC)
Tu as tout faux, ma référence en matière de langage, c'est plus OWL que C++, et c'est un langage spécialement fait pour. Et j'ai essayé de te montrer que la notion de classe dépasse largement le strict cadre de la programmation, mais tu n'as pas eu l'air de relever, ce qui ne m'incite pas à te prendre au sérieux. author  TomT0m / talk page 19:57, 25 February 2016 (UTC)
J'ai tout bon, tu es tombé toi aussi dans le piège des classes, métaclasses, méta-métaclasses et j'en passe pourtant adopté dans OWL (inclus pas réellement por modéliser la connaissance mais approcher ce que font les langages informatiques type C++ à typage statique fort). Et nous voilà donc à vouloir tenter de distinguer classes et instances, et tomber dans les restrictions stupides d'OWL (ou C++ ou Java dont cela vient) telles que "une instance ne peut pas faire partie d'une classe (ce qui est même faux déjà dans C++ et s'avère également faux dans bien des cas dans le monde réel aussi).
OWL n'en a pas fini et on se rendra compte assez vide qu'OWL finalement se réduit à RDFS sans distinguer classes et instances, mais en faisant de tout les objets des classes (pour les réelles distinctions, c'est le rôle des quantificateurs ou qualificateurs).
Mais tu as un parti pris, et tu n'en démords pas, puisque tu est encore persuadé qu'OWL est "idéal" et résoud tout (OWL a ses détracteurs et ce standard est encore bien jeune mais va souffrir comme C++ ou Java des mêmes défauts). Rien n'a en fait été fait correctement dans OWL pour les métaclasses (c'est une extension encore expérimentale, plus ou moins intégré dans son modèle "Full", sensée résoudre les insuffisances, mais en fait elle ne marche déjà pas).
OWL (la copie directe du "modèle" C++) a des alternatives qui ne nécessitent absolument aucune distinction entre classe et instance (ou entre classe et métaclasse, etc.), et qui sont en plus totalement compatibles RDF et compatibles également avec les languages fonctionnels : si ça te dit quelquechose, le but c'est de ces langages c'est de produire des preuves en un temps fini (contrairement aux langages impératifs et séquentiels comme C++ ou l'algorithmique séquentielle classique dont la prouvabilité butte sur des tas de problèmes "NP-complets", insolubles en temps fini).
Bref OWL ne retrouve incapable de garantir la moindre preuve à ses réponses ou celles obtenues par ses "algorithmes" de recherche; certaines questions posées n'auront jamais de réponse et il faudra arrêter le système qui part dans des recherches combinatoires qui explosent de façon exponentielle (cela parce qu'OWL ne peut pas modéliser ses propres règles d'inférence, pas plus que C++ pour prouver que le typage fort peut être totalement vérifié à la compilation, on aura des violations de type à l'exécution, sinon on ne pourra même pas exprimer la question).
Sinon tu m'as parlé des langages à cadres (j'ai toujours lu "languages à frames" sans traduire le dernier mot), je connais depuis plus de 25 ans, c'est un échec total (impossible de faire la moindre inférence pour prouver un problème, les cadres isolent tout et bloquent la simple inférence transitive, pourtant essentielle pour obtenir des preuves: j'ai fai un compilateur pour un tel langage, la moindre application la plus simple avait un code énorme à cause de l'explosion combinatoire des conditions et qu'il fallait spécialiser/générer du code pour chaque combinaison de conditions). L'idéal ce sont les langages fonctionnels qui permettent d'exprimer toutes les contraintes, et même de les utiliser dans les inférences.
OWL est jeune, il a du mal encore à s'imposer comme réel successeur de RDFS, même si les autres extensions de RDFS ne sont pas compatibles entre elles (car elles utilisent des règles d'inférence différentes).
Il y a eu des tas d'autres langages développés pour modéliser la connaissance en IA. OWL n'est qu'une étape (toute jeune, et peu adoptée en fait) mais certainement pas la plus aboutie (elle est même moins expressive que Prolog qui a pourtant pas loin d'un demi-siècle maintenant, ou que Lisp qui a presque trois quarts de siècles), son seul intérêt est qu'elle est facile à mettre en oeuvre (avec des langages impératifs comme C++ ou Java ou même juste C sans aucune extension objet). L'expression d'OWL sérialisée en XML est également relativement facile à faire et lisible, elle est assez proche de celle nécessaire uniquement pour RDF.
Mais XML n'est pas non plus un schéma idéal pour les données complexes. Je lui préfère nettement Turtle, moins verbeux et avec moins de risques d'erreurs, et sans avoir à utiliser des schémas externes. De plus XML ne permet pas d'exprimer les structures de données récursives, y compris les graphes en général (dont le plus simple est le graphe orienté reliant deux points chacun de l'un à l'autre), puisque XML ne représente que des arbres avec une seule racine. (XML est totalement incapable de le faire sans y spécialiser certains attributs dans tous les objets pour la référence, un attribut totalement ignoré par le validateur du DOM, qui connait bien xml:id="" mais pas xml:ref="", un comble! l'alternative en XML c'est de créer une liste de noeuds dans un ordre arbitraire, et l'accompagner par une matrice d'adjascence : pour N noeud, on obtient une matrice à N² cellules booléennes). En RDF en revanche, c'est très simple (juste la liste de triplets, dans un ordre non significatif, pas de matrice d'adjascence)! Verdy p (talk) 00:09, 26 February 2016 (UTC)
Mmm je vais pas répondre à tout vu que ça part dans tous les sens. Tes critiques sont douteuses et/ou non légitimes et n'engagent que toi. On se fiche pas mal d'XML ou de turtle qui ne sont que des formats d'exports qu'on est très loin de manipuler et qui n'ont pas d'importance dans l'établissement du modèle de données Wikidata. Dernière chose : distinction classe/token. Je ne vois pas ce que tu lui reproche pour vouoir à tout prix la gommer. author  TomT0m / talk page 13:11, 26 February 2016 (UTC)
C'est toi qui est parti dans tous les sens: j'ai répondu par exemple à ta demande d'exemple en français et tu me l'as ensuite reproché parce que c'était formulé en français. Tu n'a jamais cessé de te contredire et ignorer volontairement des restrictions en simplifiant ou déformant ce que j'ai écrit. Tu est parti avec une idée préconçue et penses encore qu'OWL est universel alors qu'il est très jeune et n'est qu'une des très nombreuses étapes de l'histoire de la modélisation des concepts en IA. OWL n'est pas défendu par tout le monde, même si c'est un standard (mais loin d'être le seul, et même pas fini en plus, là on est en train de discuter dans un domaine qui est encore à l'état d'ébauche et qui n'est présent que dans une partie non normative et expérimentale du standard, et qui est encore régulièrement modifié et mis à jour car en pleine discussion: les notions de "classe" et "instance" ne font absolument pas encore partie du profil de base d'OWL). Bref je ne suis pas tout seul. Sors un peu de tes préjugés et ton univers (juste parce que tu as lu un article ou un bouquin il y a un an ou deux), un peu de culture sur tout ce qui s'est fait dans les dernières décennies et sur l'état des discussions en cours ne te fera pas de mal (déjà commence par les références externes citées par OWL lui-même). Verdy p (talk) 13:21, 26 February 2016 (UTC)
Tu ne répond pas, encore une fois. author  TomT0m / talk page 13:27, 26 February 2016 (UTC)
Je viens de te répondre, mais toi pas du tout, puisque tu me fais juste des reproches sur mes réponses que tu m'as directement sollicitées. J'insiste: sors un peu de ton moule restrictif. Mes exemples ne viennent pas au hasard et sont justifiés même par le contenu actuel d'OWL que tu prends à tord comme un modèle abouti sensé répondre à tous les problèmes (même OWL ne prétend pas cela). Verdy p (talk) 13:34, 26 February 2016 (UTC)
Tu me fais dire des trucs que je n'ai pas dis. Et tu réponds toujours pas :p author  TomT0m / talk page 14:01, 26 February 2016 (UTC)
Je ne réponds pas ? Quelle est ta question réelle, parce que j'ai répondu à ce que tu demandais.
Note: Wikidata n'a pour l'instant pas pris la décision de coller directement à OWL (ou pas pour tout), il n'y a qu'un effort pour tenter de le rendre seulement davantage compatible avec lui, mais il n'y a eu aucune décision, que je sache, pour aussi inclure les extensions non normatives ou expérimentales d'OWL et OWL n'est pas le seul candidat. On sait déjà qu'il y a des ambiguités ou des cas qui causent des violations des règles énoncées dans cette partie d'OWL, et ce sont ces exceptions qui sont intéressantes et qui vont influer fortement sur la modélisation. Wikidata en revanche s'appujie maintenant fortement sur les qualificateurs et ça ne rentre pas dans le moule d'OWL. Il va falloir reformuler ça et ne pas tenir compte de toutes les violations relevées par les contraintes actuelles de cette extension expérimentale d'OWL. Je pense sincèrement que la notion de classe/instance d'OWL n'est pas pertinente, ou ne l'est que dans des sous-domaines plus limités que ce que tu crois. Il faut comprendre l'historique d'OWL et le fait que cela reste un standard en chantier (comme aussi l'est Wikidata qui propose une modélisation plus large, mais différente dans certains aspects). Trouver des équivalences ne sera pas facile et nécessitera des discussions, à condition de rester assez ouvert et ne pas se limiter uniquement à la vue que tu sembles vouloir imposer (avec des termes crus très malvenus comme "stupide" que tu as employés un peu vite). Verdy p (talk) 14:31, 26 February 2016 (UTC)
Une remarque tout de même par rapport à la distinction protoype / typage par classe : ça n'est à mon avis pas pertinent du tout. En l'occurence, tu peux obtenir quelque chose d'extremmement similaire en disant "soit X la classe des éléments ont les même propriétés que cet élémént précis", et hop, tu as définis une classe à l'aide d'un prototype. En javascript, un objet est considéré comme une instance, SAUF SI il est utilisé comme prototype d'une classe. On retrouve donc quelque chose de très similaire à la notion de classe qui ne sont pas des instances. Donc en gros ... c'est totalement interchangeable. D'ailleurs la notion d'instanciation existe aussi en javascript. Je sais un peu de quoi je parle, c'est juste que vu comment ça balaie de partout, j'ai pas spécialement envie de me laisser entraîner dans des discussions annexes distrayantes. D'ou mes tentatives qui échouent perpétuellement de recentrer le sujet. author  TomT0m / talk page 15:25, 26 February 2016 (UTC)
Tu viens de le dire toi-même: la distinction entre classe et instance n'est PAS pertinente car un objet peut être les deux à la fois (cas de Javascript pour tous les objets, qu'ils aient d'ailleurs un "prototype" ou pas d'ailleurs! Et dans Wikidata c'est déjà le cas, y compris pour la propriété "partie de", compliquée par des contraintes inutiles tentant sans succès de distinguer les deux et générant des tonnes de violations de contraintes). Cette distinction n'a de sens que pour des langages comme C++ ou Java, et ne fait pas non plus partie du modèle de base d'OWL (elle n'y est encore qu'expérimentale et ne fonctionne pas bien dans le domaine de l'IA et des connaissances en général; il y a un grand débat tournant autour des métaclasses, des parties partagées entre plusieurs instances d'une classe, c'à-d. les parties "statiques" en C++ ou Java, et c'est tout le problème; les métaclasses n'ont pas été approuvées, pas plus que les méta-métaclasses, et autres similaires qui ne font que repousser le problème pour le résoudre seulement en partie et pas de façon générale). Verdy p (talk) 15:36, 26 February 2016 (UTC)
Je ne te suis vraiment pas. Tu me dis qu'on parle pas de programmation mais tu en reviens constamment à c++ ou le concept 'n'existe pas (bien qu'on y fasse de la mzta programmation avec les template très couramment) en ne parlant pas de python par exemple ou il est présent des le modèle, tu ne parle pas de rdf ou il y a des classes de classe, et pour owl LE punning EST bel et bien dans owl2 (certains documents sont pas à jour) Par ailleurs la question sur "partie de" n'a rien à voir avec les métaclasses. author  TomT0m / talk page 11:24, 29 February 2016 (UTC) author  TomT0m / talk page 11:24, 29 February 2016 (UTC)

Description de « partie de »[edit]

Bonjour,

Tu as modifié la description de part of (P361) au début du mois mais celle-ci me semble globalement incompréhensible (en plus de contenir une faute d'orthographe). Est-ce que pourrais essayer de la rendre plus claire (et corriger la faute par la même occasion).

Cdlt, VIGNERON (talk) 10:46, 25 February 2016 (UTC)

Je ne vois strictement aucune faute d'orthographe dans "Le sujet est une partie de l'objet. Cette propriété est transitive : il n'est utile d'inclure que les objets dont le sujet fait directement partie, pas les objets dont font eux-mêmes partie les objets listés comme parties du sujet.", juste une faute de frappe "fartie" au lieu de "partie", que j'ai corrigée.
Comment vois-tu une reformulation de "transitive" ? J'ai pris les termes déjà employés ailleurs ("partie", "objet", "sujet"), et la première partie de la phrase "il n'est utile d'inclure que les objets dont le sujet fait directement partie" est alors très claire dans ce contexte. Verdy p (talk) 11:08, 25 February 2016 (UTC)
J'ai remplacé "le sujet" par "cet élément" (équivalent à mon avis) si ça semble plus clair. Mais la formulation reste la même (et l'explication en est donnée dans la page de discussion de la propriété documentant les contraintes associées). Verdy p (talk) 11:11, 25 February 2016 (UTC)
En réfléchissant un peu (avec la contrainte des 250 caractères...) ça donne : "L'objet indiqué est une partie de cet élément. Cette propriété est transitive : il n'est utile d'inclure que les objets dont cet élément fait directement partie, pas ceux qui sont eux-mêmes partie des objets indiqués comme parties de cet élément." C'est plus clair ? Verdy p (talk) 11:17, 25 February 2016 (UTC)
Oui, je parlais bien de la faute de frappe. Merci pour la correction.
Pour « transitive », c'est impossible à reformuler (on perdrait sans doute beaucoup le sens avec un synonyme) mais est-ce bien nécessaire de le préciser en description ? (aucune des autres langues ne fait cette précision et c'est déjà indiqué plus bas en propriété).
Ce n'est visiblement pas indiqué, il faut interpréter le détail de la page de discussion (en anglais) pour le savoir. Verdy p (talk) 12:07, 25 February 2016 (UTC)
La phrase « il n'est utile d'inclure que les objets dont cet élément fait directement partie, pas ceux qui sont eux-mêmes partie des objets indiqués comme parties de cet élément » est par contre à la fois longue (la contrainte de 250 caractères me semble déjà trop haute) et peu claire. Une tournure doublement négative avec les mêmes mots revenant dans le désordre. Même pour moi qui connaît un peu le fonctionnement de cette propriété, cela m'embrouille et je ne suis pas sur de comprendre le message que cette phrase veut faire passer ; je plains la personne qui n'y connais pas grand'chose au sujet.
Je plains surtout la personne incapable de lire la page de discussion en anglais ! la description doit servir à faire un résumé succint de l'usage, et distinguer des éléments ou propriétés homonymes, elle ne change pas le nom, elle précise le sens contre l'ambiguité. Verdy p (talk) 14:59, 25 February 2016 (UTC)
En repartant de la description originale (et cohérente avec celles allophones), est-ce que l'on ne pourrait pas simplement remplacer « le sujet est une partie de l'objet » par « le sujet est directement une partie de l'objet » ?
En tout cas, cette propriété étant fortement et lourdement utilisée (plus de 180 000 utilisations), il faudrait normalement passer par la page de discussion avant d'opérer des changements aussi conséquents.
Enfin, il faudrait rendre cohérente la description de la propriété inverse has part (P527) pour utiliser les mêmes termes.
Je suis d'accord. Verdy p (talk) 12:10, 25 February 2016 (UTC)
Cdlt, VIGNERON (talk) 11:46, 25 February 2016 (UTC)
Si on ne met pas que la propriété est transitive, on se retrouve avec des objets surchargés de pleins de parties déjà incluses dans d'autres plus générales (je peux donner des exemples par exemple avec les villes, citées comme parties de plein de choses, difficile de faire le tri ensuite et savoir si on est exhaustif). Mais le terme "transitif" n'est pas compris du tout par quiconque n'a pas de notions mathématiques (et en particulier ici la théorie des ensembles)... Faire le ménage des propriétés inutiles, car implicites par transitivité, prend un temps fou. Verdy p (talk) 11:55, 25 February 2016 (UTC)
Je reprends ton idée de "directement partie", et j'élimine alors une négation, ça donne: "L'objet indiqué fait directement partie de cet élément. Il est inutile d'inclure les objets qui font eux-mêmes déjà partie d'autres objets indiqués comme parties de cet élément." (plus court). Tu préfères encore "sujet" à "cet élément" ? Verdy p (talk) 12:00, 25 February 2016 (UTC)
Tu as des exemples qui montrent que c'est utile d'indiquer ça dans la description ? C'est pas nécessairement à donner des instructions que les descriptions servent, et c'est un principe généralement très consensuel que tout le monde comprend intuitivement. Je pense qu'en l'abscence d'exemple concrêt d'éléments bourrés de parties redondantes il est inutile d'inscrire ça dans la description, plutôt que de pointer vers une page d'aide le nouveau égaré qui s'y prendrait ... author  TomT0m / talk page 13:27, 25 February 2016 (UTC)
La description est lue furtivement mais pas affichée dans les pages de propriétés des éléments. On ne la voit que si on survole le lien ou si on clique dessus. Sinon on ne le voit pas du tout et on voit encore moins ce qui est dans la page de discussion associée. Comment expliquer un terme qui est fréquemment mal compris ou oublié? Si on met "transitif", personne ne comprend (et encore moins les francophones qui ne savent pas lire la page de discussion en anglais et n'ont pas envie non plus de lire des pages et des pages). J'ai essayé de faire court dans la description, mais je n'ai pas renommé la propriété. Pas évident j'admets. Verdy p (talk) 14:56, 25 February 2016 (UTC)
Il est plus pertinent de lire Help:BMP qui traîte de ces sujets, comme d'ailleurs du sujet au dessus. author  TomT0m / talk page 15:28, 25 February 2016 (UTC)
Cette page est bourrée de contradictions et d'affirmations gratuites, justement quand elle affirme (elle a tord) qu'une instance ne peut pas être une partie d'une classe. La réalité montre le contraire, quand toutes les instances partagent la même partie. En C++ on a pour ça des membres statiques de classe, mais vite ça butte sur son unicité car on voudrait avoir différentes classes comportant des éléments partageables différents. C'est pour ça que certains ont proposé les métaclasses. Qui ne marchent pas si bien que ça car on a ensuite besoin de méta-métaclasses, etc. La distinction entre classe et instance dans cette page est purement artificielle et sans objet réel.
Cela réduit le nombre d'exmples utiles dans cette page qui pourrait se résumer non pas à 3 mais 2 propriétés, en oubliant la distinction classe/instance sur ce qu'il est possible d'écrire.
La page d'ailleurs est hautement discutée. Vite les restrictions indiquées aboutissent à des bloquages. Deux propriétés suffisent pour tout ce qui est cité: "nature de" (inverse: a pour instances) et "partie de" (inverse: comprend/est composé de).
De même il n'y a aucune contradiction dans "<Chine> est une partie de <Chine>", ou son inverse <Chine> se compose de/comprend <Chine> car "<pays> est un <pays>" et "<pays> se compose de <pays>" (cette aide n'indique aucunement que les parties listées doivent être mutuellement exclusives, ni qu'elles doivent être distinctes de l'objet principal, ni qu'elles doivent former une partition totale de l'objet principal, autrement dit que l'objet principal est égal à l'union de toutes les parties listées et que les parties listées ont entre elles des intersections vides, ni que 'comprend' ou 'partie de' doivent être restreints à des subdivisions directes, chose souhaitable, mais pas encore vrai dans Wikidata).
Si on prend l'exemple des pays, chacun clame des parties mais il y a des revendications mutuelles entre certaines parties communes, les pays ne forment pas une partition de l'ensemble des pays.
La <Chine> elle-même est bien une classe qui comprend la Chine à diverses époques et les deux actuelles républiques... mais est aussi une instance de la classe <pays>. Là on bloque sur la distinction classe/instance qui n'est pas possible selon les règles énoncées. Alors la <Chine> est-elle une sous-classe ou une instance de <pays>? Pourquoi pas les deux en même temps dans Wikidata?
La <Chine> est pourtant une partie de l'<Asie>, l'<Asie> elle-même partie de l'<Eurasie>, elle-même partie de l'<Eurafrasie>: lequelles de ces dernières sont des instances ou des sous-classes de <continent> ?
Tu admets: <instance> partie de <instance>, et <classe> partie de <classe>, mais pas <instance> partie de <classe> (la Chine en tant qu'instance de pays, ne serait pas partie de la classe continent, mais l'Australie en tant qu'instance de pays est aussi instance de continent), ni <classe> partie de <instance> (la Chine en tant que classe des deux républiques qui en sont les instances, ne peut pas être partie de l'Asie en tant que continent). Hmmmm.... des contradictions comme ça on en aura partout dans Wikidata.
Pourquoi toutes les instances Y d'une classe X ne seraient-elles pas elles-même des sous-classes Y de la classe X ??? On ne fait pas du C++ ou du Java dans Wikidata on n'a pas à subir les conséquences des restrictions imposées aux instances dans ces langages (et notamment pas la non-dérivabilité et non-instanciabilité des instances d'une classe, des restrictions qui n'existent pas si tout est classe. Toutes les données de Wikidata peuvent rester elles-mêmes des types dérivables (même le "simple" nombre 1, qui a des sous-classes "1 cursif", "1 gravé", "1 décoré de fioritures", "1 gras", "1 italique", "1 en exposant", etc.) ! Les propriétés "instance de" (type/nature de l'élément) ou "sous-classe de" peuvent rester équivalentes.
Bref là encore une propriété en trop (ou trop de restrictions non nécessaires sur ces propriétés, mais alors ambiguité de choix et donc redondance dans Wikidata et des tas d'erreurs dans les rapports cherchant à vérifier les règles énoncées dans la page BMP).
D'autres exemples sont dans la page de discussion concernant les quarks et les particules élémentaires. Verdy p (talk) 18:01, 25 February 2016 (UTC)
En revanche on peut définir dans Wikidata des restrictions d'usage sur les valeurs V admises pour les propriétés P ou pour les qualificateurs Q, en leur imposant d'être des sous-types (des sous-classes ou des instances si tu veux) d'un type de base (une classe si tu veux) donné T. En fait ce type de base T est un élément Wikidata normal: ses sous-types sont d'autres éléments Wikidata normaux, décrits (transitivement) comme des sous-types (sous-classes si tu veux) d'un autre élément Wikidata et en remontant la chaine des parents, soit on tombe sur l'élément T, ou si le dernier élément parent n'a plus d'autres propriété le citant comme un sous-type (sous-classe ou instance on s'en fout) de quelquechose, alors la valeur donnée à la propriété P ou le qualificateur Q n'a pas le type T attendu. L'inférence de type est classique, c'est celle normale de dérivation des classes mais on n'a jamais à savoir si on a affaire à une instance ou à une classe. Verdy p (talk) 18:34, 25 February 2016 (UTC)

Property:P22[edit]

Bonjour Verdy p,

C'est un exemple intéressant. Est-ce que l'inversion des deux est voulue? Personnellement, j'hésite un peu à mettre ce type d'exemple.
--- Jura 12:43, 26 February 2016 (UTC)

Certes le sujet est très politique, mais c'est surtout pour mettre en avant la confusion facile des noms homonymes.
Ai-je fait une inversion des deux ? Je ne crois pas. Correction: je me suis planté aussi, comme quoi l'exemple est plus que pertinent !
Il y a d'autres exemples tout autant politiques ou orientés, cela dépend dans quel pays on se situe, mais ce sont des personnes très connues. Peu importe qu'on soit d'accord ou pas avec elles. Verdy p (talk) 12:47, 26 February 2016 (UTC)
Je pensais à l'aspect de les inverser juste pour l'exemple. Peut-être une paire politique déjà décédée est moins sujet à froisser, p.e. Q11816/Q11806.
--- Jura 13:02, 26 February 2016 (UTC)
Je cherchais un exemple frappant d'homonymie suffisamment connu dans diverses langues. Pas nécessairement dans le monde politique.
Peut-être Alexandre Dumas (père et fils), mais sont-ils assez connus internationalement ? Verdy p (talk) 13:05, 26 February 2016 (UTC)
C'est pas mal. S'il y a un qui me vient à l'esprit, je le changerai. Toutefois, je ne suis pas certain que les deux ait besoin d'être connus. Sur [1], il y a Q36949.
--- Jura 13:38, 26 February 2016 (UTC)
A noter que d'après Help:Label, la "disambiguation" ne devrait pas se faire par l'adjonction d'éléments dans le libellé. Mais bon, en v.en. le texte n'est pas le même qu'en v.fr.
--- Jura 14:04, 26 February 2016 (UTC)
Je suis assez d'accord, mais le suffixe "fils" est également connu et utilisé dans plein de langues justement pour lever l'ambiguité.
Cela méritrait une propriété séparée pour indiquer le nom officiel (mais aussi une autre pour le nom de naissance, souvent dans le cas des femmes, cas d'Indhira Gandhi, née Nehru), puisque le libellé est uniquement le nom le plus courant par lequel une entité est connu aujourd'hui. Ce nom officiel est en principe non traduisible (il n'est pas officiel dans toutes les langues, sauf ici Indhira Gandhi qui a deux noms officiels en Hindi et en anglais). Le libellé en revanche n'a pas besoin d'être restreint à un nom officiel (c'est le cas aussi des toponymes, dont la plupart sont officiels dans une seule langue, le libellé traduit reste informel). Verdy p (talk) 14:23, 26 February 2016 (UTC)

actor (Q33999)[edit]

Please stop changing labels of actor (Q33999)! These edits break thousands of currently working articles. Use Lua instead for female and gender neutral forms. --Lockal (talk) 15:05, 26 February 2016 (UTC)

I replied on the talk page of this element. Clearly something is wrong with the property "female form..." where what should be used is standard subclassing: those subclasses will have translated names coherently. We shoulkd not even need to add multiple values, one per language. But only list the two subclasses for males and females. Lau modules of some Wikipedia are definitely not relevant in Wikidata. Those modules will need to be corrected to use subclasses distinction instead. Anyway those modules do not (or should not) use the Wikidata labels, they are using names relevant directly for their own language. Verdy p (talk) 15:10, 26 February 2016 (UTC)
Note that even before your revert on labels (my changes were genuine), I add already talked about the modelisation problem.
With the current masculine name (which also miwxes in fact all feminine forms in it) data is ioncorrect in Wikidata, and categories of most Wikipedias and Commons do not match correctly (they are currently restricted to the male sex).
We still need a really gender-neutral version of Q33999. As you persist in wanting Q33999 to be masculine only, this means we'll need to remove completely the feminine aliases from it. But then we'll need to create instead the gender-neutral form (declaring its two masculine/feminine subclasses, and correctly sorting/distinguishing the other properties). Consider what I wrote in the talk page of Q33999 this is really meaningful.
The way by which the current Lua modules in a few Wikipedias are written, are definitely not relevant in Wikidata !!! Verdy p (talk) 15:18, 26 February 2016 (UTC)

VIAF[edit]

Voyez Property_talk:P214 s.v.p. LeadSongDog (talk) 16:42, 4 March 2016 (UTC)

Je ne comprend pas le problème évoqué qui n'a rien à avoir avec la propriété elle-même.
Je pense qu'il y a confusion entre la propriété (qui a un nom dans plein de langues) et le sujet (lié aux articles Wikipédia, où on ne voit actuelelment que ceux en français et anglais).
Je vais regarder plus en détail comment le tout est lié. Verdy p (talk) 18:57, 4 March 2016 (UTC)

Registre (Q21081127)[edit]

About your edit, homonyms are not "specific per language" that use the same alphabet so is correct to have the same string for all the latin language. We have hundreds of thousands of item compiled in this manner. I rollback your modify. --ValterVB (talk) 13:10, 10 April 2016 (UTC)

"Register" or "Registry" is NOT an homonym of "Registre". This creates many conflicts. They are "translations", not the same thing at all ! Translations have their own set of homonyms, but we cannot solve them correctly if you mic the orthographies.
In addition there are OTHER disambiguation pages for "similar" terms. No, they do not use the same string at all. Those that I removed were effectively DIFFERENT. Verdy p (talk) 16:19, 10 April 2016 (UTC)
The fact that these have been mixed in Wikipedia befoire they were imported in Wikidata, is causing lots of problems. Each set of homonyms must be distinguished by name (the only allowed variations are various minor differences that are considered equivalent orthographically in each language such as different kind of apostrophes, or differences related only to the addition of disambiguation suffix (in parentheses or after a comma in English) in a Wikipedia article. The exact name leads everything.
And there are already correct distinctions specifically for "register" and "registre" (that must not be merged, and cannot be merged because some Wikipedia are distinguishing them in the same language)!
Consider the case of city names, we have exactly the same problems. The set of homonyms are too large.
You are trying to mix disambiguation pages (that exist only becaues how the titles are written, but are related to different/urelated entities/objects/elements) and the classification of wikidata elements (that have real article pages, or properties. Elements in a disambiguation page have NO properties except saying that they are homonyms only in specific languages (the languages for which we list the Wikipedia pages) or projects.
These names are NOT translatable and MUST NOT be translated. Verdy p (talk) 16:47, 10 April 2016 (UTC)
Register" or "Registry" is NOT an homonym of "Registre: exactly and we don't mix they in disambiguation item, we have Register (Q217425), Registry (Q847805) and we have Registre (Q21081127) for "Registre" every one must have the same label for all the language like all the disambiguation, we don't care about the meaning we have also a separated item for Registro (Q4038899). You said "This creates many conflicts" but wich? In item Q21081127 there are 2 sitelink ca:Registre and fr:Registre same word, if on en.wikipedia they create a disambiguation page called "Registre" where must be connected? and what will be the label? The answer is that they connect the page in Q21081127 and the label will be "Registre" so I don't see conflict. I revert again. If you want more info about disambiguation you can ask in WikiProject Disambiguation pages. --ValterVB (talk) 17:22, 10 April 2016 (UTC)
The label for English would then be "Registre" not "Register", and in that case there would be an English entry in Q21081127 (for now there's only French and Catalan there, the other additions are for wrong languages not using "Registre".
Conflicts are created exactly when we attempt to add a wikipedia link from Wikipedia or attempt to define the label, Wikidata rejects the addition because of conflicting entries in another Wikidata element for disambiguation pages. That's where I detected that, and I could add the correct entries only after removing the extra incorrect intries in "Registre" so that I could add it to "Register".
French makes a disticntion between "Registre" the common term, and "Register" (using for artwork titles in fact in English, but having an entry in Wikipedia, but where there's NO case of homonymies mixing the two cases).
In other words: it is normal to split Wikidata elements that are about distinct sets of homonymies, we don't keep the same entries ion two distinct entries.
Don't reimport data that has been correctly separated (those legacy links from Wikiepdia have created lots of problems, we are slowly separating them, but we don't need to anticipate possible but not effective additions, until there's a true disambiguation page created in relevant wikis for linking the extra terms; for all other cases, adding labels just adds more confusion when searching in Wikidata opr when trying to define labels for actual elements that are needed!) Yes there are conflicts even we attempt to create labels or attempt to change them, when the descriptions given are identical (Wikidat rejects those additions, we need each time to cleanup the extra entries that were added elsewhere on other elements).
Yes there's lot of work to do to separate things with many incorrect data that was imported from Wikipedia but they were actually not homonyms (this includes splitting also what remains in "Register" (including in non Latin scripts). Verdy p (talk) 18:48, 10 April 2016 (UTC)
But you have checked the original item? In item Q21081127 the English label was "Registre" not "Register", exactly like you said where is the problem? You said: "Conflicts are created exactly when we attempt to add a wikipedia link ...." but isn't correct. All the disambiguation item have the same description, if you create an item with label "Register" and standard description the software warning you that already exist and you must merge in the other item, is a feature to find existing item, if you delete label you can create hundreds of duplicates. I revert for last time, if you revert again I ask to another admin to take action. If you aren't agree you wikidata rules you must write in WikiProject Disambiguation pages. --ValterVB (talk) 19:06, 10 April 2016 (UTC)
Look at the history: I first detected the confglict when trying to add an entry to "Register": this conflicted immediately because of a superfluous entry in "Registre". I had to perform the cleanup of all unnecessary entries (that were actually NOT linked to any article in the relevant language). Those old entrioes are legacy ones. Once we separate the sets of homomyns, we need to cleanup the old entries to prevent those conflicts.
We never need additional labels in non-relevant languages. Sets of homynms are only relevant for languages that actually have disambiguation pages in the associated wikis.
All other entries are sooner or later creating conflicts, and they complicate the searches in all languages as they return unrelated elements (not intended for the language we are searching for because there's actaully no disambiguation in those languages). And you've first broken the rule of 3 reverts. Your last revert was abusive (now you've made it 5 times, you refuse to understand anything when these entries were correctly separated).
Look also at property checks and constraint reports, and why those (legacy) additional entries are bad and MUST be cleaned. Verdy p (talk) 19:12, 10 April 2016 (UTC)
Can you tell me where is the conflict? Because for disambiguation, conflict mean 2 thing: we must merge item or we must split item no other possibility exist. In wikidata is fundamental to have label for all the language and disambiguation is the more simple case to manage. --ValterVB (talk) 19:21, 10 April 2016 (UTC)
No these additions are never needed, they do not make things simpler because you are predicting things about non existent data that may be arranged differently in other languages.
Wikidata rejects any addition of a "name/description" pair that conflicts with another pair for another element. This is blocking, and each time this occurs we must first cleanup the incorrect entries (this is the case of those that were cleaned from Wikidata "Registre" to avoid the conflicts with entries in "Register".
This is a frequent case of confusion and those additions are blocking the actual corrections that must be made elsewhere when splitting the disambiguation pages.
You've first abused the revert by using it 5 times (ioncluding the unjustified deletion of a relevant data linking to at least one source Wikipedia, which is relevant here for elements about Wikimedia disambiguations). Verdy p (talk) 19:27, 10 April 2016 (UTC)
Please look at the MANY conflicts reported about legacy disambiguations initially imported automatically friom Wikipedia. There's an extensive cleanup to perform there, this includes separating setys and dropping data for NON-RELEVANT languages (if and when they will be relevant in Wikimedia pages, the necessary entries will be added automatically, before that don't predict the future, as they may also never exist or could be renamed or a disambiguation may not be relevant when articles are merged). Before that we don't even need any description: the single property is sufficient to show what it is, and the name is automatically the same by default as the name used in existing listed wikilinks (which should be identical with minor differences such as capitalisation of their title or disambiguation suffixes added to their titles). Verdy p (talk) 19:34, 10 April 2016 (UTC)

comprend, contient les subdivisions territoriales administratives[edit]

Non. Juste non. J'ai supprimé toutes ces assertions dans les classes des divisions administratives françaises, pour lesquelles tu n'en as fait qu'à ta tête sans discussion préalable, et où l'on se retrouvait donc par exemple avec une classe région qui contains administrative territorial entity (P150) toutes les régions, ce qui par transitivité impliquait que chaque région comprenait elle aussi toutes les régions dont elle-même. Et vu que la classe comportait le générique "département", chaque région comportait aussi l'entité "département".

Invention ou tu as mal interprété les classes correspondantes. La transitivité dont tu parles ne se fait pas du tout pas le même niveau ni les mêmes types de relations. Bref, tu brodes... Verdy p (talk) 11:19, 8 September 2016 (UTC)

Jusqu'à preuve du contraire, la région Île-de-France (Q13917) n'est pas comprise dans la région Provence-Alpes-Côte d'Azur (Q15104), ni dans elle-même.

Je ne sais pas d'où tu sors ça, pure invention, ou bien ça vient d'autres utilisateurs. Verdy p (talk) 11:18, 8 September 2016 (UTC)

Je crois qu'il est grand temps que désormais, avant chaque altération aussi minime soit-elle de l'ontologie administrative géographique française, tu proposes ta modification ET sa justification sur la page de discussion du Projet Wikidata sur la France ; et que tu attendes un avis favorable du reste d'entre nous - je pense à @VIGNERON, Ash Crow, Zolo:, …

Il me paraît raisonnable de te le demander pour chaque nouvelle classe, pour chaque modification d'une classe (y compris un ajout, modification, ou suppression d'assertion ou de qualificateur), et chaque ajout ou retrait de classe pour une entité ou un ensemble d'entités.

Tu inventes une règle. Wikidata n'a jamais fonctionné comme ça. Il se construit de façon incrémentale par modif successives (s'il y a des discussions elles se font au fur et à mesure et je ne suis pas reponsable non plsu des mauvaises utilisations faites par d'autres après (surtout quand tu parles de "transitivité" qu'il m'est impossible de prédire à l'avance (les règles de transitivité ne sont pas non plus clairement établies ou ont pu changer depuis, il y a des tas d'assertiosn dans les "propriétés" de Wikidata qui sont fausses avec des tas d'exceptions non résolues et à un moment donné les rapports de Wikidata soulèvent ces problèmes entre assertions contradictoires, mais n'indiquent pas non plsu que l'une ou l'autre des anomalies relevées sont des erreurs: les ambiguités restent à résoudre en les topologies; il y a aussi des tas de situations transitoires et des tas de données manquantes, et des tas de confusion dans Wikidata entre éléments très similaires). Verdy p (talk) 11:42, 8 September 2016 (UTC)

Et si tu reproposes d'ajouter des instances comme subdivisions administratives ou parties des classes auxquelles elles appartiennent, même si ces instances sont des génériques, c'est d'emblée non pour ma part.

Alphos (talk), désespéré d'avoir une ontologie propre, 05:25, 7 September 2016 (UTC)

Que d'agressivité, ton message n'a ni queue ni tête et tu inventes des règles tout seul et profères des tas de mensonges sur ce que je suis supposé avoir fait. Wikidata ne fonctionne pas comme ça ! Tu ne démontres rien du tout d'une part et je ne suis pas tout seul non plus ! Verdy p (talk) 11:16, 8 September 2016 (UTC)
De rtoute façon tu viens maintenant après des mois et des mois passés, sachant que derière ça il y a eu des tas d'autres modifs par d'autres.
De plus cela a été discuté à l'époque. Tu me renvoies maintenant à une nouvelle page projet qui n'existait pas à l'époque, où était quasiment pas référencée.
Visiblement tu ne tiens pas compte de l'historique, ton message viens comme un cheveu sur la soupe et tu n'as rien cherché du tout. Tu t'es contentés de lire des infos partielles sur quelques pages de ton choix, où il n'y a même pas eu de réel consensus non plus. Verdy p (talk) 11:40, 8 September 2016 (UTC)
Oui, j'ai sûrement rêvé. Ou pas.
Mon agressivité reflète la perte de patience que j'éprouve à corriger ces erreurs. C'est bien gentil de vouloir compléter Wikidata. Mais encore faut-il ajouter de bonnes informations.
Sur ce diff par exemple, la transitivité de contains administrative territorial entity (P150) implique que toutes les anciennes régions françaises ont comporté Nord-Pas-de-Calais (Q16987) entre le 5 juillet 1972 et le 1er janvier 2016 (cf qualificateurs), puisqu'elles sont toutes des instances de former French region (Q22670030).
Tu peut me dire où est l'erreur ??? Le Nord-Pas-de-Clais n'aurait jamais existé comme région française entre ces dates ? 14:46, 10 September 2016 (UTC)
L'exemple se répète à l'identique pour chacune des régions. Autant dire que tout est tout, et tout est dans tout. Ou, en fait, autant ne rien dire.
Même TomT0m te l'a fait remarquer. Mais déjà lors, tu as fait ta tête de mule et refusé de comprendre. J'agis de la sorte pour protéger la qualité des données sur Wikidata. Ça te déplaira peut-être, mais ce n'est pas mon problème.
Alphos (talk) 13:53, 10 September 2016 (UTC)
Encore de l'agressivité inutile dans tes mots (je te renvoies à "tête de mule"). Non je n'en fais pas qu'à ma tête et j'en discute quand le peux mais je ne suis pas forcément les choses pendant des mois. Il y a des tonnes de problèmes dans Wikidata, souvent à cause justement de la transitivité qui est mal décrite et de la polysémie qui fait qu'on change subtilement d'une sujet à l'autre parce qu'il manque des qualificateurs pour restreindre les choses.
Mais je ne vois aucun problème dans ce que tu dis et je ne suis pas le seul en cause car la transicité concerne aussi des tas d'autres objets dont je ne suis pas le spécificateur. Méfiance avec la transitivité, elle fait souvent des déductions fausses mais ce n'est souvent pas le dernier qui a touché un objet (correctement) qui est en cause puisque l'erreur se situe ailleurs, ou simpelment parce que les propriétés actuelles de Wikidata sont ambigues et autorisent déjà plusieurs interprétations et il y a des nombreux changements qui surviennent ensuite dans les règles ou les spécifs des propriétés ou qualificateurs. Tu ne peux pas accuser une seule personne pour des modifs faites il y a des mois quand il n'y avait pas d'erreurs relevées (et souvent il n'y en a toujours pas).
Je crois que tu fais une fixation inutile et que tu t'en prends à moi plutôt que de discuter dans les autres endroits appropriés où il y a des changements (et toujours des tas de problèmes non résolus). Verdy p (talk) 14:46, 10 September 2016 (UTC)
Quant à conclure "ce n'est pas mon problème", visiblement si c'est ton problème puisque tu fais un tel scandale ici. Calme-toi et considère déjà que bon nombre de propriétés sont très confuses et que leurs règles changent sans arrêt ou ne sont que des ébauches voire des essais en attendant de séparer les problèmes. Et au vu de ton agressivité inutile ici, je me permets de me répondre: tu me fais ch... et tu n'a pas compris comment on essaye de faire ou décrire les choses ici (rien que ton interprétation transitive de "contient les subdivisions admisnitratives" est complètement stupide alors qu'il y amême des règles explicites que tu veux ignorer (alors qu'ells ont bien précisées). Si tu manques de patience, Wikidata n'est pas du tout un projet pour toi, Wikidata ne sera jamais terminé et est sans cesse en train d'ajouter des données qui sont sans cesse requalifiées en cas de problèmes (mais pas tant qu'on n'analyse pas réellement ce que sont les problèmes et pas tant qu'il n'y a pas de règles claires et qu'on n'a pas levé les ambiguités qui sont un peu partout). En plus dans la version française les noms données à certaines propriétés ne correspondent pas aux définitions des mêmes propriétés en anglais et il y a aussi une forte résistance à utiliser des clairs précis et utiliser le langage courant qui est largement ambigu (et dès qu'on commence à comparer avec les langages de programmation objets, on nous répond que c'est hors sujet, alors que c'est tout le sujet quand toi tu veux parler de transitivité qui est une notion très théorique et qui nécessite des définitions précises et des restrictions que tu ignores an appliquant bêtement la transitivité la plus simple (A->B, B->C, donc A-C mais en oubliant les restrictions qualifiant les deux premières ou implicites par les autres règles et la typologie décrivant ces relations avec des types d'objets différents mais admis simultanément).
Une complication inutile est venue de la volonté de séparer instances et classes, alors qu'en fait tout est classe (surtout dans Wikidata où tout objet de connaissance peut être spécialisé dans d'autres domaines avec des tas d'autres propriétés complémentaires pour les enrichir à tout instant). Cette distinction n'existe que dans les anciens langages objet (pour simplifier leur compilation mais qui ne simplifie pas du tout l'évolutivité et la maintenance). si je prend l'exemple d'un région française, elle a deux comportements selon qu'on parle de collectivité locale ou de déconcentration de l'Etat: les subdivisions d'une région ne sont pas les mêmes selon l'axe choisi. Pareil pour les départements, les communes et c'est encore pire depuis qu'on a des statuts très diversifiés avec des tas de transferts de compétence de nature différente entre état et collectivités ou selon les services de l'état ou des collectivités. Tout ça donne des choses imprécises qui finalement conduit à dupliquer inutilement des objets et créer des classes, au lieu de s'en tenir à une seule classe et au schéma plus simple, plus souple, et plus facilement maintenable de dérivation des classes. Alors quand je vois certains vouloir introduire maintenant des métaclasses et autres choses encore plus absconses en voulant imiter le C++ (un des langages objets les plus horribles qui soient) je me pose la question de la pertinence de ces distinctions inutiles dans Wikidata et qui compliquent les choses et nécessitent même des tas de nouvelles règles que toi tu veux en plus ignorer avec ta méthode d'inférence basique sur la transititivé inconditionnelle (alors que même Wikidata contient explicitement des conditions de transitivité)... Verdy p (talk) 14:49, 10 September 2016 (UTC)
human (Q5) ne has part (P527) pas Wolfgang Amadeus Mozart (Q254). has part (P527) ne sert pas à donner des exemples, mais à indiquer des sous-ensembles.
Quant au fait que le fait que ça te déplaise n'est pas mon problème, je le maintiens, c'est une manière de te prévenir que je ne me préoccuperai nullement de te convenir.
Alphos (talk) (qui répond en un seul diff) 10:39, 11 September 2016 (UTC)
Ces règles que tu cites ont changé (partiellement) mais le problème de la relation inverse n'est toujours pas réglé et l'ensemble est toujours ambigu. Rien n'a été en fait décidé, et de fait je n'ai pas à subit un tel assaut aussi grossier de ta part, surtout des mois après et quand dès le début tu ne précises même pas correctement ce que tu critiques (et tu ne fais pas que critiquer, tu passes tes nerfs: Wikimedia n'accepte pas de tels comportements, et je n'ai pas à subit tes ordres sur des choses qui ne sont pas clairement tranchées quand il y a plein d'autres problèmes que celui-là). Je comprend la volonté de pouvoir faire de l'inférence par transitivité, mais actuellement ça ne marche pas. Et en plus ce que tu cites est faux puisque tu ne tiens pas compte des restrictions inscrites dans la typologie des objets: c'est ton inférence qui est déjà "foireuse" dès le départ. Bref il n'y avait AUCUNE anomalie, c'est toi qui interprète mal (et incomplètement) les données!
Donc ça suffit ! Si tu ne te calmes pas, je demande une sanction contre toi. Tu n'es pas propriétaire de Wikimedia et d'autres aussi ont droit à leur avis (la complexification de la typologie dans Wikidata est franchement critiquée par énormément de monde, elle n'a rien résolu en fait car elle a été faite sur une base purement informatique (issue des vieux langages objets), et non en fonction de la modélisation de conaissances plus générales. Ce modèle qui veut aribtrairement séparer classes et instances est stupide, le modèle plus simple (plus général) est celui qui fait de tout objet une classe et de toute classe un objet, et où les concepts d'instanciation et dérivation sont en fait complètement identiques (d'autant plus que dans Wikidata on a les moyens de préciser les choses grace à l'introduction des qualificateurs, dont tu ne tiens pas compte du tout: clase et él"ment dans Wikidata sont la même chose: des "éléments"): (argumentation en dessous). Verdy p (talk) 12:54, 11 September 2016 (UTC)
D'une relation R liant deux éléments A et B (A:R:B) qualifiée par un ensemble de qualificateurs Q1: "A:R:B/(Q1)", et
de la même relation R entre B et C qualifiée par Q2: "B:R:C/(Q2)",
l'inférence n'est PAS une relation "A:R:C" seule mais la relation qualifiée "A:R:C/(Q1 et Q2). L'ennui c'est que tu oublies complètement les qualificateurs, bref tes inférences par transition sont fausses!
Et on n'a même pas besoin dans Wikidata des notions de classes, ou instances (sauf pour modéliser des concepts informatiques). Wikidata ne manipule pas des triplets (A:B:C) mais des des quadruplets (A:R:B/Q), ça fait une grosse différence, mais c'est beaucoup plus général et adapté au fait que Wikidata est ouvert à de nombreux domaines d'utilisation où la polysémie des termes est absolument partout et l'usage de qualificateurs est un besoin général. Au début il n'y avait pas les qualificateurs et ça a "merdé" complètement. Certains veulent forcer la modélisation en séparant classes et instances (et en introduisant la complexité des méta-classes, méta-métaclasses, etc.) mais c'est incompréhensible et en fin de compte on se retrouve dans l'impossbilité de nommer correctement les objets pour les distinguer, et on crée des tonnes de propriétés similaires, voire jouant les mêmes rôles, et trop d'erreurs partout. LA modélisation se fige aussi et ne permet plus d'étendre les données (par exemple pour tous les domaines liés à des articles de Wikipédia ou du Wikitionnaire (où polysémies, homonymes pulullent dans le langage courant): Wikidata devient incompréhensible; et puisqu'on ne peut plus faire d'inférence entre relations, on en arrive à devoir définir des tonnes de propriétés, objet par objet (le modèle avec des classses a un sérieux plomb dans l'aile: Wikidata est utilisé comme si on construisait un programme en C++ ou en Java et s'avère incapable aussi de modéliser correctement les relations inverses (ce qui complique fortement les requêtes les plus simples où on s'attendrait à voir des listes de propriétés dérivées, et des listes de propriétés héritées).
Ca c'est mon avis. Rien n'est encore tranché mais les problèmes sont devenus monstrueux dans Wikidata car on n'est pas parti sur les bonnes bases et qu'on a introduit des complexités inutiles et nuisibles. Verdy p (talk) 12:53, 11 September 2016 (UTC)
Tu me fais directement penser à une blague politique dont la chute est "Et le chaos, qui c'est qui l'a créé ?!".
Je n'ai jamais rien dit qui puisse laisser penser que je me considère le propriétaire de Wikidata. J'essaye juste de te sortir de l'illusion que tu l'es, en te demandant de proposer tes modifications aux autres participants avant de les effectuer, pour recueillir leur avis.
Tu veux demander mon blocage pour quel motif, au juste ? Parce que je te fais "chier" ? Si ça c'est pas une preuve que tu te crois ici un peu trop chez toi, je ne sais pas ce que c'est.
Tu utilises toi-même la transitivité des propriétés (quand bien même on ne parle pas de propriétés transitives au sense d'OWL) ici par exemple. Et avant que tu me demandes une preuve que c'est bien toi qui as ajouté cette assertion, je la donne.
Alphos (talk) 14:37, 11 September 2016 (UTC)

Bonjour, Verdy p, je ne suis pas spécialiste de wikidata, mais j'ai une tendance à croire Alphos quand il affirme que tu as fait des erreurs de façon répétées. Si c'est le cas, sa demande de demander l'avis de quelqu'un d'autre avant de faire une modification qui a beaucoup d'impact ne me parait pas démeusurées. Be bold n'a jamais signifié ne pas tenir compte des remarques que l'on te fais. Xavier Combelle (talk) 14:33, 11 September 2016 (UTC)

Si cela avait autant d'impact qu'il le dit, il ne viendrait pas des mois ou des années après qu'il y ait eu des tas de changements ensuite (et toujours pas de solution réellement adoptée). Avec son langage usurier dès les départ (et aucune explicaition avant d'avoir suelmeent poussé sa "gueulante", je n'ai rien à retenir de son intervention. Qu'il aille passer ses nerfs ailleurs, je n'ai rien fait de mal. Mais tenté de démêler des problèmes ou compléter des données manquantes dans des règles qui au départ étaient tout à fait permises. Je ne suis pour tien si ensuite vous introduisez de nouvelles règles (toujours tout aussi contradictoires, entre elles !).
J'ai donné mon point de vue: l'introduction des distinctions de classes/instances est un artifice de programmation qui cadre très mal avec ce que Wikidata veut représenter, et en fait même c'est un très vieux modèles de modélisation objet qui n'était adapté à l'époque qu'à ce qu'on savait faire en terme d'inférence de types; aujourd'hui on est passé largement à un autre niveau et Wikidata n'a pas à modéliser que des objets type C++: les connaissances qu'il accumule ne sont pas aussi cadrées, elles sont changeantes, elles ont toutes des conditions variables d'application qu'ont ne peut pas ignorer. Verdy p (talk) 18:25, 11 September 2016 (UTC)
OK, j'ai pas le droit d'avoir des soucis de santé qui me préoccupent plus que tes maladresses, je note. C'est sûr, si personne ne s'est plaint de tes modifications dans les 5 jours ouvrés (et au passage, si, quelqu'un s'en est plaint dans les 5 jours ouvrés), c'est forcément que c'est bon. Et si tu te mêlais de ce qui te regarde ? Alphos (talk) 19:24, 11 September 2016 (UTC)
Je ne me suis pas mêlé de ce qui ne me me regardait pas. D'où tu sors ton excuse sur ton état de santé que je n'ai pas invoqué et qui en l'occurence n'a rien à voir ici ? Et puis question maladresse, je m'excuse, mais elles sont moins grace que ton agression ici, venue comme un cheveu sur la soupe. Et dans les nombreuses dicussions autour de Wikidata, beaucoup se plaignent de la complexité imposée par quelques-uns un peu trop actifs qui imposent des schémas inadaptés aux sciences humaines et veulent systémtatiser des traitements automatiques en oubliant de formaliser les raisonnements ou en les faisant de façon approximative.
Je maintiens que ton raisonnement ci-dessus était faux, et qu'il n'y avait pas d'erreur au vu des propriétés spécifiées et que les vraies questions sont non pas les prétendues erreurs d'utilisation (qui ne sont que les conséquence des spécifs indiquées au moment où on met des données), mais le contexte changeant et les imprécisions. Qu'il y a it des imprécisions c'est possible mais elles sont dans les spécifs techniques ou dans les docs, et dans le fait qu'avec ce qui est fait l'inférence est conduit partout à des incongruités. Wikidata pour l'instant ne supporte pas les inférences transitives simples. Il n'y a qu'à voir les très nombreuses listes d'exceptions qui ont été ajoutées un peu partout pour juste "éliminer" certains signalement automatiques trop nombreux mais sans résoudre les vrais problèmes: que les utilisateurs utilisent les données sans connaitre les règles d'inférence, qui ne sont même pas compatibles entre elles et ont de nombreuses contradictions même quand on essaye d'en ternir compte. LE cas des relations inverses est symptomatique des problèmes de cohérence, et ceux qui font une seule des interprétations possibles mais veulent feinfre d'ignorer les autres interprétations pourtant permises et largement utilisées, ont AMHA un parti pris, une orentation, non neutre où ils suppose que leur modèle et carré et peut régler tous les cas (ce n'est pas possible en géographie). Comment démêler tout ça? Simpliofier le modèle au lieu de chercher à le compliquer encore plus (et ensuite venir se plaindre et engueuler les autres qui ont fait l'interprétation autre qui ne correspond pas à ce que veulent imposer quelques uns (et qui ne marche pas non plus).
Mais là encore tu es parti sur le terrain de l'agression. Ce qui ôte ta crédibilité. Et tu n'as encore rien montré de ce qui était pour toi erroné. Car tu as raisonné trop vite sur des prémisces fausses, et choisi le parti prix d'ignorer totalement ce qui est pourtant bien spécifié et regarder un point local pour conclure tout sur le reste. Verdy p (talk) 22:26, 11 September 2016 (UTC)
Non, il ne s'agit certainement pas de programmation objet. Cf. w:Type–token distinction ou dans les langages d'ontologies qui n'ont absolument rien à voir avec la programmation objet comme w:fr:Web Ontology Language, ou a des définition comme "une voiture est un véhicule motorisé à quatre roue" (classe) et des objets qui sont des exemples d'objets qui collent avec la définition (instance). cf. Help:Classification. author  TomT0m / talk page 18:47, 11 September 2016 (UTC)

@Verdy p je trouve, tes accusations d'agressivité à ton encontre de la part de Alphos. On ressent une grosse irritation dans son discours à ton encontre, mais il n'est pas agressif et reste courtois dans son discours. par contre ton discours à son encontre est émaillé de phrases que je considère comme agressif: "Invention" "Tu inventes une règle. Wikidata n'a jamais fonctionné comme ça." "Visiblement tu ne tiens pas compte de l'historique, ton message viens comme un cheveu sur la soupe et tu n'as rien cherché du tout." "je me permets de me répondre: tu me fais ch..." "je n'ai pas à subit un tel assaut aussi grossier de ta part," " tu passes tes nerfs" "c'est ton inférence qui est déjà "foireuse" dès le départ. Bref il n'y avait AUCUNE anomalie, c'est toi qui interprète mal (et incomplètement) les données!" " son langage usurier". Je reconnais pour ta défense, que c'est beaucoup plus facile de ressentir de l'agressivité des autres à son endroit que la sienne propre à leur endroit. Xavier Combelle (talk) 10:39, 12 September 2016 (UTC)

Mon langage a été adapté à son discours. En plusieurs phases et franchement je me suis retenu, par ce que ce n'était pas approprié de justement venir passer ses nerfs pour une question de détails après des mois où il s'est passé plein de choses et je ne suis pas le seul concerné dans l'histoire. Oui on a des désaccords techniques, mais ce n'est pas nouveau et surtout cela ne concernait rien de récent et une toute petite partie des données (alors qu'il y a tant à faire et pleins de questions non résolues). Je reste convaincu que Wikidata s'égare dans des "solutions" techniques imposées de fait par quelques uns, mais qui le renddent de plus en plus incompréhensible pour la plupart des gens (un problème général de Wikimedia dont l'audience mais surtout le nombre de contributeurs ne fait que baisser, avec des tas de gens découragés par la façon dont quelques uns (qui peuvent tout décider) traitent les autres, car ils sont enfermés dans leurs bulles techniques: on les écoute uniquement car ils ont à leur disposition des moyens techniques, qui font une partie significative du travail, mais qui reste très éloignée de ce qui a été voulu dans Wikimedia: l'ouverture.
Et ce n'est pas parce qu'on pense qu'il y a des erreurs qu'on doit sermonner ceux qui les font. Alors que c'est de l'incompréhension dont l'origine est à la base des choses mal spécifiées et mêmes admises dans leur diversité depuis longtemps (et ce n'est pas une solution technique qui du jour au lendemain changera les choses pour tout le monde et sur tous les sujets. Les solutions techniques c'est bien quand on fait un programme et qu'on veut qu'il se compile sans produire des erreurs fatales, mais ici cela ne reste qu'une aide; la diversité est nécessaire ici pour prendre en compte plus de choses Wikiata est une collections de liens entre lesquels on peut naviguer mais avec malgré tout des raisonnements automatiques qui sont difficiles à justifier: le regard humain est nécessaire, mais cela doit rester compréhesible pour le plus grand nombre et pas créer de nouvelles ambiguités ou problèmes encore plus graves qui figent les données dans un état qu'il devient impossible de faire évoluer graduellement: Wikidata doit pouvoir fonctionner sans les outils techniques/bots imposés par quelques uns qui en ont les moyens, mais qui pourraient aussi les utiliser pour faire leur propre base correspondant à leurs souhaits et ce qui les intéresse, et où ils pourront à loisir éliminer ce qui ne les intéresse pas). On peut essayer de faire converger un peu les points de vue mais ils seront incapables par des méthodes trop systématiques de tout modéliser dans tous les domaines comme ils le souhaitent et doivent accepter alors ce fait. Wikidata est un moteur trouvant des tas de choses mais le regard humain doit voir ce qu'il en tire. Quant aux ontologies web, là aussi c'est un gros chantier en évolution, elles ne résolvent pas tout et il y a plein de choses qui doivent fonctionner avec autre chose. Verdy p (talk) 11:06, 12 September 2016 (UTC)