Verdy p

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, don't hesitate to ask on Project chat. 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"

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 :

   Under discussion

Description	MISSING
Data type	MISSING
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING

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

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(s) (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

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)

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

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)

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

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 the 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 the 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(s) (P527) pas Wolfgang Amadeus Mozart (Q254). has part(s) (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)

Demande de source

Bonjour,

Aurais-tu une source pour le official name (P1448) de Brittany (Q12130) ? (Special:Diff/306528295) Je voudrais notamment vérifier si le nom officiel contient vraiment « Région ».

Cdlt, VIGNERON (talk) 15:27, 18 October 2018 (UTC)

Pas de réponse, j'ai donc changer pour uniquement le nom « Bretagne » avec (faute de mieux) l'ISO 3166-2 en source. Cdlt, VIGNERON (talk) 12:20, 20 November 2018 (UTC)

"contrainte de format" de la propriété "version logicielle"

Bonjour,

Ta modification semble faire échouer des numéros de version simples tel que "1", "1.0" ou "1.0.0". Pourrais-tu y jeter un œil ? Merci ! Jona (talk) 15:54, 6 November 2018 (UTC)

Ce n'est PAS le cas, le rapport généré est obsolète (regarde la date du rapport). C'est déjà discuté dans la page de discussion de la propriété qui détaille cela. Verdy p (talk) 22:52, 20 November 2018 (UTC)

Modifications non consensuelles

Bonjour,

Pour le fond :

• Pour le Rhône, merci de ne pas supprimer une valeur correcte, quand bien même serait-ce pour mettre un valeur tout aussi correcte (ce qui reste à prouver). Et vu la situation particulière merci de fournir des sources. Voir aussi la discussion sur le bistro : Topic:Uty1juj5jnzwpn41
• Pour le piment de Cayenne, merci de lire en:Cayenne pepper (qui indique avec moultes sources que l'antonomase est du nom commun vers le nom propre et non le contraire) et les multiples attestations dans la langue anglaise (au hasard l'entrée du dictionnaire Webster).

Sur la forme, réverter ainsi sans fournir la moindre source ni tenir compte du fonctionnement du projet est plutôt malvenu sur un projet collaboratif.

Cdlt, VIGNERON (talk) 15:59, 10 February 2019 (UTC)

Sur la forme, tu joues les maîtres autoritaires et n'admets aucune contradiction et tu te trompes ici en plus ! Tu ne veux pas lire les sources, l'nsee est claire, le code COG n'est pas un code pour les collectivités et le département du Rhône est une collectivité qui ne correspond PLUS DU TOUT au code 69.

Partout sur l'Insee les données associées au 69 sont pour la circonscription toute entière, il y a des pages séparées pour les données par collectivités et 69D est bien utilisé pour le département, distinctement du 69M, pour les rares données où il faut faire la scission sans regrouper les deux. Verdy p (talk) 16:58, 10 February 2019 (UTC)

« l'nsee est claire » peut-être, je n'en ai aucune idée, tu ne fournis aucune source ! Je constate que le lien https://www.insee.fr/fr/statistiques?geo=DEP-69D n'existe pas contrairement à https://www.insee.fr/fr/statistiques?geo=DEP-69

« ne correspond PLUS DU TOUT au code 69. » plus ou pas ? Si tu retires le code 69, cela veut dire que ce code 69 n'a jamais été le code du Rhône.

Idem pour le piment de Cayenne, as-tu une source qui capitalise la majuscule ? (de mon côté, j'ai fournis plusieurs sources - et je peux en rejouter des dizaines sur demandes - et toi aucune, qui utilise l'argument d'autorité ici ?)

Cdlt, VIGNERON (talk) 17:22, 10 February 2019 (UTC)

Le lien ne fournit PAS des statistiques par "département" (au sens légal) mais par territoire (au sens du COG, peu importe son statut actuel) selon les divisions et la déconcentration de l'Etat. D'ailleurs le COG contient encore les codes des "anciennes communes" qui existent encore quand elles sont en fusion partielle (dans une commune nouvelle ou un groupe de communes associées): la géographie n'a pas changé et persiste quelles que soient les personnes morales qui gère tout ou partie des domaines d'adminsitration par transfert de *certaines* compétences (mais pas toutes, sinon ce serait évidemment des états indépendants). Une fois ce transfert réalisé, rien n'interdit une collectivité d'avoir ses propres subdivisions/délégations (à condition de pouvoir désigner l'entité qui en serait délégataire, mes ces subdivisions ne sont pas toujours des personnes morales et n'ont pas d'identité juridique: le "69" n'a plus aucune identité juridique c'est juste une entité territoriale servant en interne à l'Etat à déconcentrer certains de ses services).

Les subdivisions de déconcentration ne sont d'ailleurs pas toujours les mêmes selon les domaines (exemple les "régions" au sens de la défense, ou les "départements" au sens de la police, ou les "académies". Le COG ne codifie pas tout, c'est juste un codage géographique pratique, mais qui ne désigne aucune entité ou statut précis ayant un sens légal. Le terme "code département" ne signifie pas que le code désigne un "département" légal, c'est une terminologie propre au COG et aux méthodes d'analyse et de travail de l'Insee: c'est un niveau de nomenclature uniquement pour faciliter les recherches et rapprochements mais peut contenir des données agrégées (l'aggrégation statistique est parfois obligatoire au plan légal pour préserver le secret des personnes ou le secret commercial, c'est au coup par coup mais cela ne change rien au statut légal des entités incluses dessous). Verdy p (talk) 17:38, 10 February 2019 (UTC)

Note: je retire le "69" car il n'a cependant *jamais* désigné l'actuel département du Rhône dans ses nouvelles frontières mais ces frontières n'ont pas de code à deux chiffres dans le COG. Et là l'entité Wikidata désigne distinctement le département (actuel) et pas l'ancien département (actuelle circonscription) qui a toujours son code "69" (et son historique mentionne son ancien statut de département jusqu'en fin 2015). Bref je n'ai rien "retiré". J'ai éliminé le doublon du code "69" qui ne peut pas désigner les deux objets (erreur d'unicité), et qui correspond exactement au regroupement utilisé par l'INSEE (voir lien ci-dessus) et nulle part sur le site de l'INSEE l'actuel département légal. Verdy p (talk) 17:43, 10 February 2019 (UTC)

Sinon si le lien **généré** est faux, c'est le module qui se trompe en générant ce lien à tord. Le lien en question "qui marche" ne donne pas les infos du "département" mais de la circonscription entière. Verdy p (talk) 17:45, 10 February 2019 (UTC)

Et encore du charabia sans source... Peux-tu fournir ne serait-ce qu'une seule source ?

Et du coup, sur quel(s) élément(s) placerais-tu le code 69 ?

Sur "circonscription départementale" (terme aujourd'hui légalement utilisé, à la place de département maintenant réservé pour le nouveau département du Rhône bel et bien codé "69D").

Le 69 n'a pas disparu en tant que division administrative déconcentrée du territoire pour l'Etat, mais a disparu en tant que département. Les URL de l'Insee "par département" ne marchent peut-être pas pour le "69D" mais pour le "69", mais ce sont des statistiques par circonscription départementale et non plus par département (l'Insee pourtant génère pourtant aussi des statistiques par département comme pour les autres collectivités, mais c'est un autre lien; le 69D et le 69M figurent souvent, pas partout, dans plusieurs états statistiques de l'Insee en tant que regroupement supplémentaire dans la circonscription 69, pour indiquer des sous-totaux utiles et pertinents aux collectivités départementales; de même 2A et 2B qui ne sont plus des "départements" mais des "circonscriptions départementales" de l'Etat au même titre que le "69"). Verdy p (talk) 19:26, 19 April 2020 (UTC)

Cdlt, VIGNERON (talk) 17:54, 10 February 2019 (UTC)

Encore une agression de ta part ("charabia" = terme d'agression). Les sources sont là (depuis leur seule source officielle, l'INSEE partout sur son site, tu as le choix des pages) tu ne veux pas en tenir compte du tout ! On a deux objets bien distincts dans Wikidata, et chacun a "son" code distinct approprié. Je n'ai RIEN supprimé puisque l'entité wikidata ici est nouvelle depuis 2016) et celle qui était là avant depuis toujours a toujours son code 69, mais sa propriété de "statut" juridique a changé (avec l'historique ui l'indique avec les dates de validité). C'est toi qui insiste pour y inclure ce qui était avant 2016 (mais ne l'a jamais été dans Wikidata!) en confondant les deux éléments. Verdy p (talk) 18:00, 10 February 2019 (UTC)

Note: le terme précis qu'utilise l'INSEE dans le COG c'est "zonage d'étude", cela n'a rien à voir avec la nomenclature des collectivités (où l'INSEE les fournit uniquement par SIREN, mais il permet de chercher une collectivité par zone; ce zonage purement statistique n'établit pas du tout un statut aux territoires concernés et ne donne aucune signification sur leurs compétences et les domaines d'activité concernés), il est purement géographique et ne rient pas compte des changements administratifs sauf quand l'Etat lui-même le demande. Les collectivités peuvent ne pas tenir compte de ce zonage tant que c'est dans leurs compétences et que cela n'entre pas en conflit avec la loi, elles peuvent se regrouper ou se subdiviser et s'organiser localement comme elles le veulent, et négocier avec l'état des aménagements de statut ou des transferts ou fusions. L'Insee en revanche a pour mission de maintenir une continuité statistique avec le temps, elle supprime en fait rarement des éléments du COG et y fait des changements mineurs peu signifiants au plan statistique sauf si elle ne peut plus faire autrement (et dans ce cas elle va annoter ses statistiques pour indiquer le biais ou expliquer un brusque changement, ou va tenter de créer des données par estimation au moins pendant plusieurs années afin de permettre de faire un suivi au moins décennal des évolutions, avant de rendre certains zonage obsolètes et plus maintenus ni estimés quand aucune politique publique ou commerciale n'en aura plus besoin car elles auront perdu de leur pertinence). Verdy p (talk) 18:13, 10 February 2019 (UTC)

Sign of directions

Can you please give me an example of such signs? I suspect them to be of very narrow and conditional use. Because in mathematics we don't care if z-axis is directed "up" and x-axis is directed "forward" (or "right"?) --Infovarius (talk) 12:25, 20 May 2019 (UTC)

The conditions are the most common and explicitly indicated with another property speaking about "direct" (or "positive") bases or reference frame. This is absolutely not a narrow use. The narrow use is the opposite sign within indirect/negative bases or reference frames.

Note: this has nothing to do with a linguistic definition (like script directionality) which is unrelated (I think you were supposing this could have been what I assumed); but only based on the most common definition in physics (mecanics) and it is culture-neutral. These items are mostly based on physics definition.

This is also needed for the correct definition of physical fields (like the orientation of the magnetic field depending on the orientation of the current and of the elctric field). Those properties are all related to the definition of a direct base or direct frame of reference: you cannot arbitrarily choose the sign in a direct base, unless you switch to an indirect base. Note that all these "up/down/left/right/forward/backward" directions are directly attached to a physical frame of reference (centered on the physical "observer"), which MUST be oriented with significant signs on all 3 axis.

As well these items are NOT based on mathematics (vectorial spaces that define no "left/right/up/down/forward/backward" directions and can freely use direct or indirect bases, because the directionality of bases is always arbitrary but is defined ONLY within a separate projection to a physical frame of reference). Verdy p (talk) 17:09, 20 May 2019 (UTC)

partial function (Q1756942)

Hi! Let f in A x B be a binary relation (like f: A -> B). Then left-totality means for each a in A there is some b in B such that (a, b) is in f. But it exactly means that function is defined everywhere, thus it is not a partial function, but a common function. See [2], for example. Wikisaurus (talk) 18:25, 19 April 2020 (UTC)

• And another question. There are three notions:
  1. multivalued function (Q629085) = left-total (there is a value for each domain element)
  2. partial function (Q1756942) = right-unique (at most one value for each domain element)
  3. function (Q11348) = left-total + right-unique (exactly one value for each domain element)
• Strangely, every (3) is (1) and (2), not vice versa, as one would expect. Here you changed the meaning of (3) to (2), but it was wrong, ok? See here, for example. Wikisaurus (talk) 18:42, 19 April 2020 (UTC)

Initially I trusted the definitions given in English, but after thoughts you were correct. Anyway this means that "partial function" is just the same as "function", as "total functions" are just a subset of "partial functions" (those that are left-total).

For the "multivalued functions", they are also partical kinds of functions, but their domain is a compound made of an ordered tuple of sets. It may be ambiguous with functions that are in fact relations where there are multiple values in the same same codomain

E.g., the longitude or latitude, or any "pseudo-function" returning a polar coordinate (such as the "argument" of a complex number), or a tuple of coordinates, because in fact there are multiple choices for the target value, all of them having the same source point. Longitudes for example are a set of angles equal modulo 360 degrees or could be the whole set of real numbers for points on the polar axis; latitudes are a set of angles that are either equal modulo 360, or equal to 180 degrees minus the angle modulo 360 degrees. You can reduce these "pseudo-functions" (actually relations) to total functions (and even bijections) by adding restrictions: longitudes could be restricted in a smaller codomain by defining the result only in [-180, +180) (when defined in degrees) or to be defined as {0} on the polar axis; latitudes would be restricted to the codomain [-90, +90] (when defined in degrees).

But you can as well define the longitude, latitude, and other polar functions as returning a single subset of real numbers (including the whole set) and then you have a total (and injective) function, which is "single valued" (there's only one subset returned), but still not a bijection (not all subsets of real numbers are mapped from a single point, only some subsets; and the whole set of real numbers is then the image of two distinct points on a sphere).

Verdy p (talk) 19:03, 19 April 2020 (UTC)

L291067

Bonjour,

invalid ID (L291067) est-ce vraiment un lexeme ? La nature grammaticale indiqué me laisse plutôt pensé qu'il s'agit d'une erreur. Qu'en est-il ?

Cdlt, VIGNERON (talk) 20:07, 19 May 2020 (UTC)

Effectivement c'est une erreur (et il n'y a de toute façon **aucune** nature grammaticale indiquée, contrairement à ce que tu dis, ni aucune autre propriété en dehors de cette seule expression orthographiée en français uniquement). Voir plutôt Q88909747... (Je me demande comment c'est arrivé, alors que j'ai créé ou modifié l'entité homonyme, et non le lexème et pas non plus une propriété). Verdy p (talk) 02:51, 20 May 2020 (UTC)

Ok, je vais en demander la suppression. Et si, il y a bien une nature grammaticale Wikidata property for items about organizations (Q18608993), c'est justement comme cela que j'ai repéré cet élément . Cdlt, VIGNERON (talk) 08:00, 20 May 2020 (UTC)

Je ne dit pas qu'il n'existe pas une telle propriété, mais juste que le lexème n'en fait pas usage du tout (ce lexème est vide et ne référence aucune propriété et en tout cas pas celle que tu indiques). Tu confonds avec le lexème inutile (Lnnn) avec l'élément homynme et utile (Qnnn) qui, lui, fait usage d'une propriété (Pnnn) dont la valeur est Wikidata property for items about organizations (Q18608993) (mais n'a rien à voir avec aucun lexème)...

Note: les lexèmes existent peut-être dans Wikidata mais ils sont difficiles à utiliser: pas moyen de les sélectionner correctement soit avec leur ID, soit leur URL (les deux ne sont pas reconnus) ni avec leur libellé. Et c'est encore pire avec les formes/"forms" (Lnnnn-Fnnnn) et sens/"senses" (Lnnn-Snnn). Ces entités sont encore très mal gérées par l'UI de Wikidata, très compliquée à utiliser. Bref ces lexèmes/formes/sens sont encore ne bêta et il y a des bogues, ils peuvent apparaitre de façon aléatoire sans qu'on le sache. Et je pense que 'lUI de Wikidata n'est pas du tout adaptée et que la source encore des données c'est avant tout via un Wiktionnaire (où c'est là encore que c'est le mieux organisé, les Wiktionnaires cherchant toutefois à transférer une partie des données vers Wikidata pour faire les rapprochements entre eux). Mais Wikidata pour gérer les traductions entre Lexèmes/Formes/Sens est vraiment très mal conçu et les données sont très fortement non pas unifiées, mais dédoublées avec une très forte redondance dans le modèle utilisé, qui rend ces données finalement inutilisables car totalement incohérentes.

J'ai essayé avec une seule entrée (pour le mot "first" L2) avec une traduction française, et bien c'est beaucoup trop compliqué et inutilisable dans l'état actuel. Mieux vaut encore rester sur le Wiktionaire et tenter plutôt de rendre les Wiktionnaires cohérents entre eux avec leurs propres outils, quitte à intégrer une Wikibase sur chacun d'eux et non centraliser une Wikibase commune sur Wikidata. a mon avis l'intégration des lexèmes/formes/sens sur Wikidata est une erreur, cela n'aurait pas du avoir lieu avant d'avoir cherché d'abord à développer un modèle sur quelques Wiktionnaires de test. pour voir ensuite ce qu'on pouvait unifier et fusionner sur Wikidata (à mon avis pas grand chose, ou même rien du tout: beaucoup trop de redondance et gestion des langues totlement inefficace: Wikidata n'est pas du tout encore prêt à gérer les traductions sans aucune langue de référence, alors que sur chaque Wiktionnaire au moins on a une langue de base: une Wikiabse sur le Wiktionnaire aurait du sens pour améliorer les modèles existants et formaliser son contenu : au lieu d'éditer des pages wiki avec des modèles complexes, les pages wiki référenceraient des données Wikibase locales modifiées dans des formulaires simplifiés, et la conversion des contenus peut se faire de façon automatique sur le wiki local). Sur chaque wiktionnaire aussi on peut lister les traductions vers les autres wikis (liens interwikis) et ensuite commencer à songer à unifier ces liens interwiki en formalisant des transferts partiels vers Wikidata sur ce qui peut être commun. Mais sur Wikidata l'intégration est précipitée et ces données inutilisables seront nettoyées: elles sont incohérentes, donc inutiles. Verdy p (talk) 02:26, 23 May 2020 (UTC)

Pavé trop long que je ne comprends pas, notamment à cause de certaines erreurs (ce lexème avait bien une nature grammaticale erronée - comment diable l'aurais-je trouvé sinon ? - ou un lexème n'a pas de libellé par exemple). Si tu as des remarques constructives sur l'amélioration de l'interface, n'hésite pas à les adresser à qui de droit. Cdlt, VIGNERON (talk) 13:44, 23 May 2020 (UTC)

S'il y en avait un ce n'est pas moi qui avait ajouté ça en propriété (j'ai regardé, il n'y en avait pas!); il n'y avait qu'un libellé et rien d'autre. Et puis "certaines erreurs", c'est très vague étant donné que le reste (à partir de Note) ce sont des remarques sur l'interface et l'intégration hasardeuse et très mal fichue des lexèmes sur Wikidata (oui l'interface ici est bel et bien inutilisable et a de nombreuses anomalies).

Verdy p (talk) 13:45, 23 May 2020 (UTC)

La nature grammaticale n'est pas une propriété, c'est directement dans la structure des lexèmes (qui n'ont pas de libellés, les libellés sont uniquement pour les éléments et les propriétés, par pour les autres entités Wikidata). On ne peut pas créer un lexème sans indiquer la nature grammaticale et en l'occurrence, tu avais indiqué Wikidata property for items about organizations (Q18608993).

Pour l'interface, si tu as des remarques, n'hésite pas à les partager aux développeurs (moi je n'y peux absolument rien ; d'autant moins que je l'utilise depuis 2 ans sans souci majeur).

Cdlt, VIGNERON (talk) 20:23, 23 May 2020 (UTC)

Non, je n'ai jamais sélectionné ça. Si tu avais lu l'historique avant tu aurais vu qu'un autre utilisateur avait ajouté cette propriété, pas moi.

Quant à la création de l'entité lexème ça ne peut être qu'un bogue car ce que j'ai créé c'était un élément (qui est toujours là d'ailleurs) et même pas avec cette propriété bizarre qui ne sert qu'à créer des propriétés pour organisations. Il y certainement un mélange de formulaires qui se sont télescopés. D'ailleurs c'est très peu de temps après (quelques minutes) que Wikidata s'est crashé et est resté bloqué (erreur serveur 500) pendant plusieurs heures. Verdy p (talk) 20:29, 23 May 2020 (UTC)

Dracula's Castle (Q3221360)

Bonjour,

Si tu convertis cet item en édition il faut retirer part of (P361), changer title (P1476) pour le titre en français, enlever l'un des deux isbn (ce n'est pas la même édition même si c'est le même éditeur), et recréer l'item original written work (Q47461344).

Ça doit être la première fois que je vois une page frwiki lié à une édition précise. A part l'infobox automatique celle-ci ne parle d'ailleurs pas d'une édition précise.

— eru ^{[Talk] [french wiki]} 20:58, 29 August 2020 (UTC)

Note: le wikipédia en français utilise "titre" pour indiquer la VO. La VO anglaise n'a actuellement aucune entité dans Wikidata (on ne peut donc que la citer par nom et non par référence, mais je n'ai pas trouvé les ISBN de l'édition originale, doinc la conversion est impossible).

Seule la version française est décrite (chez un seul éditeur en une seule langue mais en deux formats clairement distingués; cet éditeur a ensuite changé légalement quand Gallimard Jeunesse a été créé avec une nouvelle collection, mais je n'ai pas trouvé ce titre dans la nouvelle collection, donc il reste juste ces deux formats français.

J'avais bien appliqué toutes les distinctions nécessaires et le seul wiki qui y fait référence est la page wikipédia franocophone.

Mais là tu as supprimé tout ce qui permettait de distinguer (et même remis un ISBN invalide que j'avais corrigé, ar il y avait des chiffres faux, la clé finale de contrôle ne fonctionnait pas et on ne trouvait aucun des deux formats de cette édition: même texte, mêmes illustrations, même éditeur). J'ai tout vérifié, y compris l'entré BnF que tu as asusi saccagé.

Et j'ai pris le voin de lever toutes les alertes et ambiguités sur les contraintes.

Si tu lis la page ISBN, il est bien mentionné depuis longtemps qu'il peut y avoir plusierus ISBN pour une même oeuvre et il est possible de les distinguer sans avoir à recréer autant d'entité. C'est une demande constante. Les contraintes permettent d'avoir plusieurs ISBN à condition de mettre certains critères distinctifs (ce que j'ai fait correctement).

Si on n'indique pas une édition précise, alors aucun IBN n'est valide pour un grand nombre d'oeuvres. tu devrais t'intéressder de plus près à la norme BibTex qui tient compte de ces difficultés (note que certains catalogues en ligne, même chez les éditeurs eux-mêmes, ne sont pas exempts de clauses invalides, j'ai même trouvé des ISBN faux trouvé sur des "preprints" (facsimilés d'ébauches avant publication où le numéro affiché était faux et n'est même pas l'ISBN publié chez ce même éditeur). Bref cela demande des recherches longues et pénibles, mais là tu viens casser le résultat de ces recherches en enlevant tout et c'est abusif alors que tout ce que j'ai mis est vérifiable (pas ce qui était avant et que tu as remis abusivement). Verdy p (talk) 21:20, 29 August 2020 (UTC)

Note: il est possible qu'il y ait un troisième ISBN (après 2005) puisque la collction "Folio Juior" n'existe plus chez "Editions Gallimard" mais a été transférée chez "Gallimard Jeunesse" (dans le même groupe mais légalement séparé). Si Gallimard Jeunesse réédite l'oeuvre (et les droits de Gallimard lui ont été transférés chez lui), ou si un autre éditeur reprend les droits attachés à certains titres de la collection ou toute la collection, on pourra ajouter un troisième ISBN.

Le dépot légal ou consultable trouvé à la BnF n'a été fait que pour la version initiale de 1987 de la collection Folio Junior (format livre de poche uniquement chez Folio Junior, pas la version brochée à couverture rouge et vendue sous jaquette en format un peu plus grand; et sans doute avec une pagination différente, voire plus d'illustrations).

Il y a d'autres éditions en anglais et d'autres langues mais elles ne sont pas asusi connues et pour l'instant introuvables (il est possible même que tous les droits de l'oeuvre originale soient chez Gallimard au plan international, mêml si l'oeuvre originale est en anglais, les éditeurs se réserent ensuite le droit de publier où ils veulent dans les langues qu'ils veulents avec leurs éuipe éditoraile pour les traductions, illustrations ou choix de format, même s'il y a un doit limité de l'auteur sur le texte original. Les droits des traducteurs sont indépendants.

Les deux formats existants sont tous sur les mêmes auteurs, et mêmes droits, le contnu ne change que par la forme, la typographie, la qualité du support papier ou de la reliure, et éventuellement les enrichissements/addons.

Il peut exister d'autres formats maintenant, demandés par les éditeurs d'eBook qui veulent autre chose plus adapté qu'un simple facsimile, ou voudraitent en faire une édition "à épisodes" dans un périodique, ou au sein d'un ouvrage collector, ou voudraient en faire un "livre audio" ou une édition Braille. Verdy p (talk) 21:36, 29 August 2020 (UTC)

Casse du Module:Wikidata

Bonjour,

Tes modifications sur Module:Wikidata ont cassé ce module, du coup toutes les pages de discussions des propriétés sont elles aussi cassées (et sans doute bien d'autres page). Pourrais-tu réparer rapidement ou annuler tes modifications ? (une bonne pratique pour des modifications sur un module aussi utilisé est de travailler en brouillon sur un module test avant de toucher le module lui-même).

Cdlt, VIGNERON (talk) 15:56, 31 October 2020 (UTC)

Non. c'était DEJA cassé, je suis en train de pister ça ! Car il y a des trucs qui ne marchent pas (des valeurs nulles inattendues car l'ancien code modifie des tables en cours d'itération, et ça plantait déjà sur plein de pages). On n'a PAS le droit de modifier les clés d'une table en cours d'itération. Verdy p (talk) 15:58, 31 October 2020 (UTC)

Hier encore les pages de discussions de propriété n'avait aucun problème d'affichage. Le code n'était peut-être pas parfait mais il était fonctionnel, là cela ne fonctionne plus. Peu importe, merci de résoudre rapidement le problème, c'est très gênant. Cdlt, VIGNERON (talk) 16:04, 31 October 2020 (UTC)

Hier ça ne marchait pas, pas plus qu'aujourd'hui. Et j'en connais la cause, j'ai déjà corrigé plusieurs choses, mais il reste ce "args.property="*"' qui ne passe pas (dans les propriétés multiples) et je pense savoir pourquoi. Il y a eu un changement dans Lua, les itérateurs sont moins permissifs qu'avant (le code était déjà bogué depuis longtemps avec des manips interdites, non supportées par Lua même si ça marchait... parfois et plus du tout aujourd'hui). Verdy p (talk) 16:06, 31 October 2020 (UTC)

@VIGNERON: Ca y est c'est conforme (y compris la doc du module qui ne fonctionnait plus non plus du fait d'une mauvaise identification de la frame et que j'ai corrigée ensuite). Les cas de valeurs nulles sont résolus. C'est bien ce que j'avais trouvé: quand on fait une boucle for sur un itérateur pairs() ou ipairs() d'une table, on n'a pas le droit d'ajouter ou retirer des éléments à la table ou de changer la moindre clé (donc pas de table.insert, table.delete, table.sort... ni même table[k]=v même sans changer la clé k, si la valeur v peut être nil !). C'est quelquechose qui est renforcé dans Lua maintenant qui peut restructurer les tables (et dans Scribunto encore plus car il y a eu des optimisations mémoire pour le serveur qui lui permet de recompacter les tables à tout moment: les itérateurs de tables ne fonctionnent plus QUE sur des tables en lecture seule. avant ça marchait "parfois" car la restructuration ou compaction était exceptionnelle et cela ne cassait pas les références des itérateurs sur la table. Ce n'est plus le cas! Verdy p (talk) 16:59, 31 October 2020 (UTC)

Request for comments about Item documentation

Hello

You're an contributor to {{Item documentation}}. For your information, I've launched a request for comments about the topic : Wikidata:Requests for comment/How should we develop and deploy documentation for items ?. Feel free to give your advice. PAC2 (talk) 17:40, 10 January 2021 (UTC)

Edits in items about chemical elements

Could you explain why you have added: (1) French aliases as English, e.g. brome, technétium, cuivre (also German Kupfer) and many others, (2) misleading atom symbols with atomic numbers: 29Cu does not mean ${\ce {_{29}Cu}}$, it suggests an isotope ${\ce {^{29}Cu}}$, look at copper-70 (Q18844906), copper-76 (Q18844915), copper-75 (Q18844913) etc., which are properly symbolised as ${\ce {^{70}_{29}Cu}}$, ${\ce {^{76}_{29}Cu}}$ and ${\ce {^{75}_{29}Cu}}$, which can be shortened as ${\ce {^{70}Cu}}$ (70Cu), ${\ce {^{76}Cu}}$ (76Cu) and ${\ce {^{75}Cu}}$ (75Cu); there is no other Cu than ${\ce {_{29}Cu}}$, so 29Cu is not a proper alias. Wostr (talk) 12:36, 20 October 2022 (UTC)

They were unified with aliases also used in other elements, using a prefix which was already the atomic number, not the atomic weight of a specific isotope; isotopes are usually designed with a suffix in names (or aliases). Chemical notations require superscript/subscript notation for their prefixes, and this is not the case (and not even possible) for names/aliases.

Note that it is never possible to make any confusion between atomic numbers (superscript prefix in chemical notation) and atomic weights (subscript suffix in chemical notation): the former (which counts the number of protons only) is always lower than the later (which also adds neutrons, whose number can vary between isotopes, but articles cannot safely indicate a single isotope, so only the atomic number is relevant there for these items; some aliases also include names for some ions, but I did not remove them, before there's a separate item created for specific ions and each one of their possible isotopes).

Names/aliases are NOT the place to put exact chemical notations (which use specific properties) and these element items refer to all their isotopes, ions, and even any one of their state forms (as gases, liquids, cristalline or amorphe solids, plus other "exotic" forms like plasmas and hyperfluids), and "pure" molecular forms (excluding molecular forms combined with other elements). For that reason, these elements should be "classes" so that we can create separate items for any one of these forms, ions (or plasma, including the proton alone which is the monoatomic and fully ionized form of hydrogen). (Specific isotopes, ions and polyatomic forms should not be listed as names/aliases in items for elements: it will not be possible to use "70Cu" here as it would refer only to a specific isotope for a separate item).

As well aliases in French, German and Latin are very common in international litterature, scientific papers, or legal statements, including for articles written in English, or partially translated in English, and they were also used in various elements as well (they are listed as secondary aliases after the most common modern ones, but before historic names). I did not add any name borrowed from other languages (but there may be some historic exceptions for some elements wellknown since antiquity and that were studied by non-English speaking scientists whose papers have been kept as references, sometimes with a romanisation for example from Chinese or Arabic, while in Europe the old age of alchemy was prevalent, or other names with religious, paganist and cultural origins). Verdy p (talk) 14:17, 20 October 2022 (UTC)

Town

Boujour, Tu utilises quoi pour traduire vers town? Car ni le Grand distionnaire therminologique[3] ou Termium [4] utilise cette traduction. Fralambert (talk) 00:44, 30 October 2022 (UTC)

Catégories

Bonjour,

Cela n'a aucun intérêt de mettre aux acatégories des alias qui n'existent sur aucun wiki Médiawiki. Cela ne fait qu'alourdir inutilement la page wikidata.

Cordialement, Vargenau (talk) 14:30, 4 November 2022 (UTC)

Il n'y a pas que Wikipédia Francophone, mais aussi Commons multilingue, Wikivoyage, etc. Et unifier les noms possibles facilite grandement les recherches d'un Etat à l'autre. Verdy p (talk) 14:40, 4 November 2022 (UTC)

Bonjour,

Cette modification https://www.wikidata.org/w/index.php?title=Q26926679&diff=prev&oldid=1942837084 n'est pas bonne. L'intitulé d'une catégorie doit correspondre à la page du wiki.

Si vous pensez que le nom de la catégorie n'est pas le bon en anglais, il faut renommer la catégorie sur https://en.wikipedia.org/

Cordialement,

Re [5]

I had removed series ordinal (P1545) as a valid qualifier of instance of (P31), because it seems to me that information should be a main statement instead of a qualifier. Do you have an example of where it won't work as a main statement? I'm trying to query its uses but I'm getting a timeout. Thanks! Swpb (talk) 14:47, 21 August 2023 (UTC)

Of course there are plenty of examples, notably for many items that are part of an ordered collection, the collection is indicated a "nature/instance of" or in "subclass of"; there can be several distinct "nature/instance of" or several "subclass of" properties, each one with a different rank, when the item is part of several distinct collections, so the ordering rank value cannot be a main statement but only a qualifier for the indicated type (nature of item, or subclass of). The same is true for "previous" and "next" properties, that frequently can only be used as a qualifier and not a main statement, for exactly the same reason.

Of course when the item is only part of a single ordered counted collection, you can move the qualifier to a main statement, but this is not always possible, and a new collection may be added at any time needing its own rank as a qualifier and in that case the rank for the preexisting collection has to be moved from a main statement to a qualifier.

Examples include ranks for people that can be part of several ordered groups (n1-th King of X, n2-th Duke of Y, n3-th President of Z), chemical elements (n1-th Perfect gas, n2-th Element); those examples are extremely frequent in many domains (technical, scientific, historical, administrative, competitions, cultural, standards...) The rank of any given item is absolutely not unique, it is always relative to the specific ordered collection in which the item has been placed. Verdy p (talk) 17:36, 21 August 2023 (UTC)

Thanks, good explanation. Swpb (talk) 18:02, 21 August 2023 (UTC)

Note that the indicated rank for any item in a given collection may also depend on a sort criteria (which may also need another qualifier). But most collections have an implicit default sort order, so such qualifier is rarely needed, in fact it's better to define another collection if it has another sort criteria (e.g. different dictionaries of Chinese radicals, simply because not all radicals are part of all Chinese dictionnaries that define their own index; the same is true about competing standards that don't always include the same number of items, so the sets are generally different, and the index of their respective ordered list as well).

Finally I indicate "subclass of" as a possible alternate to "instance of": ordered sets can index subsets that are members of the set (these subsets may themselves be ordered or not); sets can then be both "instance of" (relative the parent set), or "subclass of" (because they contain many items that are "instances" of the type indicated by the subset). Items in Wikidata are not a pure dichotomy between "classes" and "instances", they can be both (notably subsets) . Some users assume that such possibility is wrong, but in my opinion every item in Wikidata is not a pure instance and can be a type of its own: I favor the view that every item in Wikidata is in fact a "class" and is derivable (that view is also used by Javascript, Lua, and various object models, except old models making that incorrect assumption like C++, and which is a cause of nightmare and complications in object design, requiring C++ to define ugly things like "metaclasses", "metametaclasses", ad absurbio infinitam and making type inference in C++ extremely complex and forcing duplication of code doing similar things; C++ resolved that partly, using "template classes"/"generics"; this is horrible; more modern languages have abandoned that design concept almost completely and for them every object is a class and is intanciable, where each instance is a derived class). Verdy p (talk) 18:13, 21 August 2023 (UTC)

@Swpb Actually there should be a link between the item and the sequence, something like with part of the series (P179) , this should be a qualifier of this kind of statements. This does make sense, otherwise it’s not clear which in which kind of series the rank is about. In general an item may be classified in several series, like a chemical element in the series of element ranked by atomic number, or in a sequence of metals or whatever. author  TomT0m / talk page 19:15, 21 August 2023 (UTC)

You don't need the "serie" qualifier for the rank, just to specify the same type indicated by the "instance of" or "subclass of" main property that every item should have. In addition with this idea ou'd also need to repeat that "serie" qualifier for the "next" and "previous" properties (that can as well be qualifiers of the item type indicated by "instance of" or "subclass of". I don't see any interest of the "serie", which duplicates what is already done (confusively twice!) by "instance of" and "subclass of". You'd just add a third property for essentially the same thing: indicating a type indicating the ordered list (which itself defines its applicable countability, and order criteria, plus optionally a reference to a "first" and "last" item if this cannot be deduced from properties of items of the list, notably if the list is circular or not bounded on one end so that the first item may have a predecessor in the list and the last item may still have a successor in the list, or if the list is fragmented and has holes for "missing" items). Verdy p (talk) 19:30, 21 August 2023 (UTC)

@Verdy p: An "instance of" value is not an ordered list, usually. If instances of a class are orderable, there might be several ways to order them. For natural numbers, for example, there exists alternative ways of ordering them : https://www.jstor.org/stable/27642424 . For Star Wars episodes, there is the story order, or there is the chronological original release ordering.

It just does not make sense to use several "instance of" statement for natural numbers to discriminate the different orderings. It make sense to use several "series" statements with qualifiers.

• ⟨ "Star wars episode 4" ⟩ series Search ⟨ Star wars sequence by chronological order ⟩
  series ordinal (P1545) ⟨ 1 ⟩
  previous Search no value Help
  next Search ⟨ "Star wars episode 5 ⟩
• ⟨ "Star wars episode 4" ⟩ series Search ⟨ Star wars story order ⟩
  series ordinal (P1545) ⟨ 4 ⟩
  previous Search ⟨ 3 ⟩
  next Search ⟨ "Star wars episode 5 ⟩

makes perfect sense. You cannot do this with "instance of" because "Star Wars episode 4" is definitely not an instance of, say "Star wars film sequence", nor a subclass. It would make better sense to use "part of" for this.

The duplication is a non issue if we just don’t put them as qualifier of instance of (P31) so I don’t get the argument.

It’s even worse for "subclass" because there is many ways to subclass something, and there is definitely no way to assume that different subclasses are linked or can be ordered or something by not refering to the way they are ordered somehow. And there is usually no "natural ordering". author  TomT0m / talk page 19:54, 21 August 2023 (UTC)

I did not say that every type is ordered. It is ordered only if the type defines a sort criteria. So basically "instance of" or "instance of" does not indicate that the referenced type is ordered, even if it has a "rank" qualifier, or a "next" or "previous qualifier" which would be valid only if the type is ordered (that assertion can be checked and asserted if we find a "order criteria" property in that type (i.e. the reference wikidata item), otherwie it is only assumed; but the same is true with the property "serie" that also makes an assumption (whose assertion cannot be checked unless the referenced "serie" also defines a sort criteria). So there's no difference: "serie" is potentially ontologically equivalent to "instance of" and "subclass of" in terms of "genericity" (where all objects are classes and all classes are objects). All contradictions and paradoxes in Cantor's set theory comes from the self-contrdaction introduced by the axiom: for every set S, is different from {S}; all these contradictions and paradoxes are solved when you jsut write the universal axiom S={S}, which means that every set is contained in itself, and that "member of" and "is part of" are exactly the same sentence. Another way to formulate it axiomatically is "every set is equal to the set of its parties" (and not just the set of its singleton members), so that we also have "1 = { 1 }", or "{} = { {} }". Full type inference is possible and much simpler with these definitions, But I must admit that this is a very debated subject, for mathematicians, sset theorists, ontologists and many users on Wikimedia that have still not understood the concept (which is not selft-contradictive, but where contradictions come only when we use the old Cantor system which is by itself self-contradicting and paradoxal in their theory, but absolutely not in the "generic" theory used by more modern OO languages that have abandoned the dichotomy between classes and objects). The simpler model also can be used to trivially prove the continiuty of the set of reals (something impossible to prove without contradictions in the Cantor's model, which is not general enough to represent all concepts and solve/prove them in a finite time). Verdy p (talk) 20:30, 21 August 2023 (UTC)

Anyway, you won’t get rid of "series", and my example shows that the "series" values are usually not the value of the class, they are sequences themselves. It does not really make sense in the Star Wars example to have a "instance of Star Wars movie in the story order". There might also be several order criteria on the class item.

On the second part, read fr:Axiome_d'anti-fondation. In that settings it just adds new sets, it does not imply that every sets belongs to itself. The natural number sets remains identical. But it’s not really relevant to the discussion, and we don’t have such axioms here. author  TomT0m / talk page 16:11, 22 August 2023 (UTC)

元に戻してください

Q7145340(Category:Unicode)とQ6988745(Category:Unicode blocks)とですが、特にWiktionaryに関しては同じ意味ですので、統合(merge)しなおしてください。実質的に同じです。不便になりました。統合(merge)してください。元通りに。-- Charidri (talk) 07:12, 24 September 2023 (UTC)

Wrong; Unicode is general about the standard, Unicode blocks are a tiny part of the standard, and even the sum of all Unicode blocks is NOT Unicode that includes much other things, including things that are not part of the Universal character set (UCS, also defined jointly with ISO 10646). Unicode blocks are just one type of UCS range, other types include isolated codepoints, planes. Unicode also include character properties, algorithms, encoding forms that are independant of "Unicode blocks" (which can also be called "ISO 10646 blocks": these are effectively the same)... Please read the standard ! Maybe you've merged articles in Japanese Wikipedia, this does not mean they are the same thing, so they must have separate entities in Wikidata. Verdy p (talk) 16:21, 24 September 2023 (UTC)

Category:UnicodeとCategory:Unicode blocksを別々にしていることは既に知っています。それには私も賛成しています。しかし、Q7145340とQ6988745とに言語間リンク(interwiki link)が分断されたことにより、sidebarにあるはすべきの、Wiktionaryなどの言語間リンク(interwiki link)が消えてしまい、不便になりました。Wikipediaのことではありません。Wiktionaryなどです。ラベルではなく各言語版の内容を見てください。それでもなお言語間リンク(interwiki link)をバラバラにしておくのですか？Wikipediaのことを言っているのではありません。Wiktionaryなどの言語間リンク(interwiki link)を問題視しているのです。これらWiktionaryのリンクは、カテゴリ名が「Unicode blocks」となっているだけでQ6988745に、「Unicode」となっているだけでQ7145340になってはいませんか？Wiktionaryなどの言語間リンク(interwiki link)をこのような状態に分断する意味があるのですか？--Charidri (talk) 14:20, 30 September 2023 (UTC)

About the Variant form

Please refer to item A00396-001 in dictionary; 労 (Q54884717) is the Variant Form of 勞 (Q109738399) (there are more than 20 variant forms). --白布飘扬 (talk) 07:06, 10 June 2024 (UTC)

No. UniHan and the reference dictionnary do not refer to this character. You are making a confusion with another unified ideograph for which the variant you want to add is defined in reference dictionnaries and UniHan. Wiktionnary is not a reference here. I checked it multiple times, and you are misreading it. Unicode variants are clearly defined. If you think there's an error in Unicode sources, you need to address this bug in the Unicode/UniHan report. Here we are about the Unicode character and its standard properties. I added the "Do not confuse" property instead. You are misreading the entry in dict.variants.moe.edu.tw, which is associated with ANOTHER unified ideograph. U+4292 refers to Taiwanese source "T3-2462" in UniHan which is encoded as a variant of another unified ideograph. Verdy p (talk) 07:10, 10 June 2024 (UTC)

Firstly in this case I refer to Taiwanese Official Dictionary (Dictionary of Variant Chinese Characters ID (P11475)) not the wiktionary.

As what I understood, CJKV variant character (P5475) are purposed to link all those variant form together with verifiable sources. And we should know the sources of Variant Form is not limited to Unihan. Wikidata should not be only a copy of Unihan Database. The variant forms are diverse and not limited to various of Standard Form between different areas. Unihan are more focus on the relation between Standard Forms and left out other non-standard variant. But We can do more as long as the reliable sources are provided, example, Kanjipedia (Q115296982), Digital Hanja Dictionary ID (P11461) & etc. 白布飘扬 (talk) 07:42, 10 June 2024 (UTC)

But what you add is superfluous, as the Taiwanese sources already consider it as a variant of another ideograph. UniHan, the IVD database, the Unicode charts list explicitly that your variant is strongly associated with another ideograph (and explicitly lists the variant selector associated). So your addition is at the wrong place. dict.variants.moe.edu.tw does not care, it is a mix that confuses everything here even if these two dozens are clearly distinguished in three distinct sets, whose base ideograph are NOT canonically equivalent. If we apply your rule, we would need to mix every variants used in different countries/regions and with different semantics, just like we could mix Latin A, Greek Alpha and Cyrillic A, just because of of their apparence (even if they have some common etymology and should not be mixed in localized texts with the expected recommended orthography). Variant selectors in the IVD are the best way distinguish effective variants when their base characters are not canonically equivalent and have no compatibility mapping (remember that compatibility ideographs are deprecated because they are canonically equivalent and can only be distinguish using variant selectors in registered variation sequences). Your dictionary source does not give any detail about these, it mixes everything with very weak/fuzzy definitions. There are officially recognized Taiwanese standards and reliable sources, and your dictionary is not among them because it is unable to track details and effective usages (too many standard distinctions are lost). Verdy p (talk) 10:47, 10 June 2024 (UTC)

Sematic variants also part of Variant defined in Unihan. For Example provided by Unihan where 𫢊 (Q109944598) is sematic variant of 錢 (Q109765123) under the kSemanticVariant criteria. Actually up to 70% of CJK Ideographes are variants form of others.

The point is, Unihan has no attempt to list out all the Variants but just on some point for introduction. They neither deny nor reject any unlisted Variant but just leave them for dictionary work. The Taiwanese dictionary mentioned above is one of the main data provider and maintainer of kIRG_TSource (Taiwanese Source for Unihan). No other source for Tradition Chinese character could better than that. 白布飘扬 (talk) 14:47, 16 June 2024 (UTC)

The point is that the Taiwanese dictionary you give as a T source for that is already listed in UniHan and Unicode charts with a reference directly associated with variation encoded for another encoded character. Your T sources does not make any distinction between what it considers "variants", whereas Unihan and Unicode have clearly made this clear (including for "semantic variants", or "kStrange variants"): see Unicode Annex 38 about how variants and sources are used and referenced in the UniHan database and then used in the encoding, there are defined properties for this, even if your dictionnary source does not use it). The same is true about Glyphwiki which gives many other glyphs for "related" characters, that are not unified and not "variants". Variants listed here should have at least one UniHan database, otherwise they can just be "related" in linked for example with "do not confuse with" (or with "See also" in Commons), because they are clearly distinctly encoded (either with a base unified ideograph, or an old compatilibility ideograph, and a specific variation selector. The character you cite is not linked to any one, it is not a recognized variant in standards even if it may be just "related": the "see also" or "do not confuse with" links are the most appropriate in that case (there's no canonical equivalence, no compatiblity equivalence for the base character). I then suggest again you report this issue to the UniHan/Unicode maintainers (in fact the IRG), if this was an omission. But the entry here is about the unified ideograph in the UCS, and variants should follow the UCS/Unihan/IRG standard strictly. Your referenced variant is already listed elsewhere as a variation of another unified character using the same Taiwanese dictionnary already as its source. Verdy p (talk) 15:35, 16 June 2024 (UTC)

Unihan has no attempt neither to verify nor reject any mentioned or unmentioned statement from any Source. Most of the Variant statement in Unihan based on Chinese-English and Cantonese-English dictionaries like those by kLau, kMeyerWempe, kMatthews which are more specified on Common-used Chinese characters (In fact, other non-Chinese-English-source data are lack or less-used in the database.)

Semantic or Simplified-Traditional Variants are not distinctively clear in real case. Actually all Simplified-Traditional Variants are part of Semantic Variant just like 猫 (Q3595003) and 貓 (Q109763233) do. CJKV variant character (P5475) in Wikidata itself doesn't differences those classification clearly (how to different between 猫 (Q3595003) and 貓 (Q109763233) for those characteristic?). Actually Semantic Variants (wide-sense of y-axis variants mentioned in Unihan) is the basic for all variant included those Simplified-Traditional pairs. Simplified-Traditional pairs listed in Unihan are almost based on the Standardization make by both Mainland China and Taiwanese governments just like what Table of General Standard Chinese Characters (Q14941454) and Chart of Standard Forms of Common National Characters (Q6498184) listed.

Anyhow, I suggest that we could highlight those Chinese Simplified-Traditional pairs and Japanese Sinjitai-Kujitai Kanji by the qualifier as now applied in CJKV variant character (P5475) (example 劍 (Q109738305)). And leave those pure-semantic variant pairs as qualifier-less but provided with sources-references (may give priority for Unihan). What we should prevent is those "Spoofing Variant" which are apparently incorrect in all senses. 白布飘扬 (talk) 05:21, 17 June 2024 (UTC)

Unihan and Unicode data are based on the work made by the IRG (Ideographic Reporter Group) and its work is definitely not done in English, but is a cooperation between China, Taiwan, Singapore, Japan, South and Norh Korea, and Vietnam, audited by the relevant ISO and Unicode technical comitees. Before the IRG was instituted, there was a mess and many missing sources, and the IRG focused on making those sources and variants properly ordered. This means also that the initial encoding of ideographs made in Unicode 1.0 has significantly been improved since Unicode 3.0, with the adoption or the Ideographic variant database (IVD), the encoding of variation selectors (later extended with 240 additional variation selectors), and the formal decision to no longer encode any new "compatiblity ideograph" after that. Ideographic varation sequences are the important step to disambiguate and finally correctlyunify all ideographs, avoiding duplicate encodings, preserving the compatiblity (including for canonical equivalences with help of variation sequences). Since then, all is clear: the former initial sources (including the Taiwanese source that you want) have been reviewed and formally ordered (even if these sources did not classify all these variants). What is important is to keep these variants corectly encoded and here we are in a category relevant to the UCS encoding. In a further step, Unicode 16.0 and UniHan will further improve this classification, with even more precise classification of radical/Stroke indices, and with the encoding of new radicals variants and new stroke types. UniHan (maintained by the Asian IRG) is a significant progress.

And various groups are working in this (including for finally designing a new way to make precise CJK fonts supporting all variants, and national standards, which will be much smaller, will support many more stroke style designs, will support also variable weight. OpenType is being worked on to support this. Stay tuned for Unicode 16.0 announcements and relevant changes that will occur in UniHan. All old sources are being scrupulously reviewed (and new tools to check them are already in development). The initial "fuzzy" encodings (and past errors) are solved. And all this has also cut down all past critics against the UCS and Unicode principles (they are character encodings, not glyph encodings, their goal is to preserve all linguistic semantics where they are relevant and long term compatiblity is ensured now).

Your old Taiwanese source does not have enough data about these variants: they are cited by Unicode/UniHan as initial sources, for historic reasons, but these sources have been unified by adding relevant properties. Many more sources have been considered (see the impressive list in Unicode Annex 38, which is a full normative part of the standard and not a mere "recommandation" or "best practice". Identifying variants correctly is absolutely necessary and Wikidata and Commons for UCS-encoded should follow these as much as possible. If you think that the IRG forgot to include some variants in the database, contact them to review again the old Taiwanese dictionnary, but your Taiwanese variant is already correctly identified, with the relevant unified ideograph (not the one you expected), and the relevant variant sequence. What you want add is a "fuzzy" variant, it may have limited use, and for now it is best only with "see also" or "do not confuse" links, unless the IRG updates UniHan by analyzing old sources (which did not offer a sufficient classification when this character was initially encoded in early stages of the UCS and obsolete Unicode version 1.0): we are not in 1992, there has been more than 30 years of work and many more CJK ideographs, many more sources have been added, and Unicode and the UCS made significant progresses (even if these old cited sources may stay "as is": your Taiwanese online source has not made any progress in its displayed data to disambiguate "variants", like what was made in UniHan, or GlyphWiki, or other databases also cited by Unicode). Verdy p (talk) 05:48, 17 June 2024 (UTC)

We should make clear that, unlike to Unicode character (P487), Unicode character name (P9382), Unicode code point (P4213) and Unicode block (P5522); CJKV variant character (P5475) is not directly tied to Unicode database since the beginning. CJKV variant character (P5475) are more similar to radical (P5280), stroke count (P5205), fanqie (P5523) which are more dependently on multi-sources for the completeness. Just like the first example given in CJKV variant character (P5475) since the first day, 楽 (Q54552723) as variant to 樂 (Q55634770) is based on the Table of Jōyō kanji (Q55502741) provided by Japanese governments , not given by Unihan database till nowadays. Unless everybody including the property creator has misunderstood since the beginning. --白布飘扬 (talk) 07:47, 17 June 2024 (UTC)

radical (P5280), stroke count (P5205) are clearly an umambiguously tied to the UniHan database (and seen as well in Unicode charts). Yes these are still not "normative properties" in Unicode because they are subject to changes and additions (via UniHan, managed by the IRG working group, but they are well maintained and have been considerably improved over time; they are taken into account by CLDR for collation, which also evolves accordingly also accordingto the Unicode standard about it). The IRG is multi-source. It also encodes what is now known as "ideographic variation sequences" (don't confuse "variation" and "variants": variations sequences are full part of the Unicode standard). UniHan clearly also documents "variants" for sources. Unicode 16.0 will soon further improve this tying between "variants" and "variations" (part of this is already visible in the standard IVS database from Unicode, which builds along with two other variation databases: legacy variations for compatiblity characters in any script, and emoji variation sequences: "variations" is meant for encoding and are standard; variants are informative properties needed for sources in UniHan; but UniHan now links these documented source variants to encoded variations). The next step in Unicode and UniHan will be refinement of the radical/stroke index (there will be a subindex for the first residual stroke; this is already visible in the beta, and in various working documents of the IRG, to improve UniHan and further refine compatibility with more uses and more sources; this is of course part of the huge work done for "unification" of CJK characters, and further improve the adoption of the UCS encoding, after the significant progresses made in China, Hong Kong, Japan and Taiwan to now align/synchronize their local standards with the international UCS). And this is not new! The path was traced nearly 30 years ago (at least since Unice 3.0, but it was clear since the synchronization of Unicode 1.1 with the ISO/IEC 10646, evne if variation sequence were rapidly formalized and standardized with Unicode 3.0), long before the KanjiVG, GlyphWiki and other related projects (tracked by Unicode in its online tools) existed. Verdy p (talk) 10:22, 17 June 2024 (UTC)

Alright, I also await for the application of IVS in near future. Anyhow, I wish to keep those existing dictionary terms as somehow useful information at the moment. I agree some of them looked a bit "fuzzy" and I believe more improvement work would be continuously implied in future. I also curious how to present if all the 130 tortoise variants are encoded. Hopefully it not come to messy. 白布飘扬 (talk) 06:56, 18 June 2024 (UTC)

The IRG and Unicode also agree that existing radical/stroke index are insufficient to classify variants. That's the purpose of the ongoing work which will start being documented in Unicode 16.0 (but still without data at that time, it will come later with UniHan update, and possibly a minor version of Unicode just to improve Unicode charts with the the new improved indices). What is projected is to include in Unicode charts the variant selectors (currently not shown, there are just technical IDs to sources, that are unfortunately incomplete: this is a huge work to complete and review the updated database; the first step will be to include the 1st stroke, and to complement the set of missing radicals and missing strokes to be encoded; but I will not expect before Unicode 16.1, as this set is not even ready for Unicode 16.0 and there are pending reviews; Unicode 16.0 will be released in next September but it is already in Beta review, without the needed additional strokes and radicals that would be necessary to complete the radical/stroke index with the 1st residual stroke, and that's why we know that this additional property data will not be ready, and that CLDR collation data will just include a new "placeholder" value "0" for this additional indexing property.) The IRG is working with maintainers of all existing cited sources to make sure that the additional properties will be coherent, or to locate and resolve some existing problems with conflicting interpretations (it is very likely that there will be already a large set of new ideographic variation sequences in Unicode 16.0, but this will not be the end of pending work). For now I trust the IRG work and the Unihan database, that are already much more reliable and more precise than the old sources cited in Unihan/Unicode (including your preferred Taiwanese online dictionary, which is only a part of what its authors have and are discussing with the IRG), that are all missing the needed relevant data. We cannot just use these old imprecise sources as is, especially their online versions that are too much limited (these sources have their own data, but they need to agree on licencing conditions and possibly fix what they privately have to make them coherent and interoperable with other sources considered by the IRG: that 's the whole work of what is called "Han unification": enormous progresses have been done since 30 years and your preferred Taiwanese online dictionary does not display anything about this work, even if its authors largely participated in the IRG works and discussions!). Verdy p (talk) 07:32, 18 June 2024 (UTC)

Q8201 English label

I've started a discussion on Talk:Q8201, please take a look. Remsense (talk) 21:39, 25 October 2024 (UTC)