Salut,
j'ai découvert les propriétés inverse label item (P7087) et inverse of (P1696) sans comprendre quelle est la différence des deux.
Si quelqu'un a la réponse, merci d'avance !
Topic on Wikidata:Bistro/Archives des discussions structurées
Peut-être commencer par lire Property talk:P7087 avant de supprimer sans comprendre .
Les suppressions sur les propriétés père et mère n'ont rien à voir avec cette question, mais je peux les justifier ici.
Dire que père est la propriété inverse de enfant pose un soucis car pour tout couple de personne x et y, ça veut dire que si x est l'enfant de y, alors y est obligatoirement le père de x. Or, la propriété enfant possède deux inverses : père et mère. On a donc y qui est le père et la mère de x. La réelle propriété inverse à enfant serait parent.
De manière similaire, on ne peut pas dire que fille ou fils sont les inverses de parent, voire même de mère ou père.
La suppression de la propriété a été faite apparemment sans en comprendre la fonction. En plus, la suppression a été répétée sans fournir d'explication et sans en comprendre la fonction.
La lecture de la page de discussion ne m'a pas permis de comprendre la différence d'utilisation entre les deux propriétés. Jura1, peut-être pourrais-tu être plus précis pour nous aider à comprendre.
Il me semble que Pasleim l'explique plutôt bien .. je ne saurais faire mieux.
Du coup, trois choses :
- ma question initiale ne porte nullement sur les propriétés father (P22) et mother (P25), mais bien sur la raison d'existence de deux propriétés inverses.
- pouvez-vous m'indiquer comment mettre un résumé de modification quand je fais quelque chose sur wikidata ?
- si ce n'est pas une propriété inverse, dans ce cas, il ne faut l'appeler propriété inverse.
D'accord, donc c'est bien un problème de terminologie. Je me suis donc permis de renommer la inverse label item (P7087) pour que ça soit complètement compréhensible en français. C'est un moyen d'indiquer le nom de la propriété inverse. Dans ce cas, pourquoi décorréler la propriété inverse de son nom ?
Bonjour....
Alors, si j'ai bien compris (merci de corriger, stp, @Jura1, inverse label item (P7087) sert pour stocker, sur les propriétés qui ''n'ont pas de propriété inverse dans wikidata'', le libellé que prendrait cette propriété inverse si elle existait, car certains outils calculent et affichent les données comme s'il y avait une propriété inverse, et ont donc besoin de libellés dans différentes langues...
c'est bien ça ?
Bonjour @Hsarrazin,
c'est également ce que j'ai compris, mais dans ce cas, la présence du label pour la propriété n'a toujours pas de sens, car enfant n'est pas la propriété inverse de père.
on est d'accord, c'est "parent", sauf s'il y a un calcul prenant en compte le genre du parent concerné :)
C'est ça. :)
En prenant le premier exemple de père(P22), la question est:
Que peut-on afficher sur Henry Fonda (Q19155)?
c'est bien "enfant" = Jane Fonda (Q41142).
Je suis d'accord, mais en n'ayant que "Jane Fonda est l'enfant de Henry Fonda" est rien d'autre, que peux-tu conclure ? Rien d'autre que "Henry Fonda est un parent de Jane Fonda".
Je pense pas que Property:P22#P7087 ait une fonction pour d'autres cas de figure que de ceux de Property:P22#P1855
ça sert à stocker le libellé pour l'afficher si besoin .. ça marche avec le gadget "relateditems" qui se trouve sur Special:Preferences#mw-prefsection-gadgets
Effectivement, merci. C'est bien ce que j'ai compris finalement. Mais je ne suis toujours pas d'accord sur ça. "Propriété inverse" a un sens très précis dans les ontologies et je trouve ça assez trompeur utilisé tel quel. Peut-être faut-il également changer le propriété dans le label de la propriété. Est-on déjà d'accord que père et enfant ne sont pas inverses l'une de l'autre ?
Il faut voir que dans Wikidata il n’y a pas vraiment de formalisation des ontologies et que dans bien des cas la définition des notions est assez laxiste. Il ne faut pas s’attendre à ce que des axiomes soient respectés ni même définis dans bien des cas.
Je ne pense pas que inverse of (P1696) a une utilité dans le fonctionnement de Wikidata ..
Peut-être faut-il aussi mentionner Help:Property constraints portal/Inverse/fr qui ne demande pas que ça soit réciproque.
J'ai pas compris. Qu'est qui doit-être réciproque ? La relation inverse ? Si c'est ça, c'est marqué sur la première de la page donnée.
Il n'y a pas besoin d'avoir la même contrainte sur les deux propriétés.
je pense que P1696 est utile quand on utilise l'interface "humaine" de Wikidata (quelqu'un qui lit le contenu d'un item est informé de son inverse).
Oui, effectivement...
Les contributeurs utilisant des outils automatisés ou semi-automatisés ont tendance à oublier qu'il y a aussi beaucoup de contributeurs "humains"... et un inverse relativement ''évident'' dans une langue peut ne pas l'être dans une autre.
Par ailleurs, P1696 a été mise en place, si mes souvenirs sont bons, bien avant qu'on puisse encoder des contraintes sur les propriétés ;)
Dans Wikidata, je ne sais pas. Mais si jamais du contenu de Wikidata est transféré dans une ontologie (propriétés + éléments), ça permet de faire des requêtes. Après ce n'est pas un problème, par exemple dans SPARQL (le seul que je sais utiliser), car l'ordre des requêtes peut-être inversé facilement. Du genre, on peut écrire ?a P1 ?b ou ?b P2 ?a sans problème. Le truc c'est que sous Protégé par exemple (l'un des logiciels standards dans la conception d'ontologie), on ne peut pas faire ça. En suivant le même exemple que précédemment, on ne peut pas utiliser ?a, il est donc nécessaire d'avoir accès à la propriété inverse.
Ça n’a pas vraiment de sens ce que tu racontes. Je suis très surpris par exemple quand tu opposes protégé et sparql parce que la compatibilité est bien évidemment de mise. Protege est basé sur les standards du web sémantique/des données.
C’est plutôt l’inverse, en l’occurrence les propriété inverses posent problème sur l’usage dans Wikipedia en lua/wikitext vu qu’on a pas accès à une api sparql.
Ok, mon message était pas très clair. Mais je ne parlais pas du requêteur SPARQL de Protégé, je parlais plutôt de la définition des classes notamment. Dans ce cas là, le premier argument de la propriété est la classe (ou une de ses instances) dans laquelle on écrit l'axiome. Et dans ce cas là, la propriété inverse (ou la fonction inverse() si la propriété inverse n'existe) peut-être très utile.
Je comprends toujours pas bien. Tu parles de définition de classe dans un langage comme OWL dans protege ?
J’ai un peu l’impression qu’on a pas vraiment besoin d’avoir la propriété inverse explicitement dans wd, il suffit de la déclarer en tant qu’inverse dans l’ontologie OWL elle même, pour pouvoir l’utiliser dans la définition de la classe. Il y a peut-être d’autres solutions.
En y réfléchissant un peu, dans OWL, il suffit pas de déclarer la propriété avec un domaine et un codomaine, et simplement en utilisant cette propriété, une valeur devient une instance de la classe ? Par exemple si on s’intéresse à l’hypothétique propriété inverse de « père », qu’on souhaite ne pas nommer explicitement, on peut dire un truc du genre: « le domaine de père est "parent masculin", sont codomaine est « humain » »
Le raisonneur OWL pourra inférer toute entité qui a une déclaration « père » comme un « parent masculin ». On déclare la classe « parent masculin » comme sous classe de « humain », ce qui fonctionne dans une certaine mesure. Après ça ne suffit pas pour dire que "parent masculin" a nécessairement un enfant, juste que toute personne a un parent masculin. Je sais pas si c’est faisable en OWL effectivement.
Oui, je parle de définitions de classes dans Protégé.
Mais le problème initial n'est pas tant là. Il est surtout sur la définition des inverses. Mais @Jura1 semble être d'accord avec ça, vu qu'iel n'a pas révoqué ma suppression des inverses.
En fait, en ayant R et R' deux propriétés inverses, tu as pour tout a et b : aRb <=> bR'a. Or en considérant que R est la relation enfant et que cette propriété a deux inverses (père et mère, comme c'était le cas), tu te retrouves avec : "a est l'enfant de b" => "b est le père de a" et "b est la mère de a". De là, tu peux faire deux choses. Soit tu dis que les relations père et mère sont équivalentes et donc interchangeables, soit, comme c'est notre cas ici, tu ne veux pas qu'elles soient équivalentes. Et dans ce cas, tu es dans une situation d'inconsistance (ou incohérence). En fait, ce qu'on veut, c'est une relation inverse à "enfant" et cette relation ne doit pas tenir compte du genre du parent. Il faut donc une relation "parent". Relation "parent" que tu pourras sous-spécifier par "père" et "mère". Et en OWL, tu pourras même dire que "si a est le parent de b et que a est un homme, alors a est le père de b" (raisonnement équivalent pour la mère).
Voilà, j'espère avoir été clair. Si c'est pas le cas, n'hésitez pas à reposer des questions.
C'est plutôt que ça m'est égal ..
Ceci dit, c'est souvent étrange quand le gens commence à essayer faire des modifications sur base d'une fonction supposée d'une propriété Wikidata d'après un équivalent que quelqu'un a rajouté une fois ..
Oui, c’est la propriété inverse d’une propriété « parent », plutôt. Et encore, c’est compliqué avec les histoire de parent biologique/légal/…). C’est un peu pour ça que Wikidata a été conçu pour ne pas être trop sensible à une forme de « logicisme », on va sinon peiner à représenter la réalité sans que la communauté soit noyée sous les soucis pour des notions communes comme la parenté, cf. cet article.
Et si il n’y a pas d’opposition forte sur ces éditions, c’est que rien de crucial ne repose sur ce genre de déclaration (bon courage pour essayer de se reposer sur les propriétés Wikidata pour essayer de former une ontologie OWL cohérente, d’une manière générale :) )
La propriété "parent" est bien l'inverse de "enfant" et s'intéresser aux parents biologiques ou légaux constitue déjà une spécification de la propriété. Une bonne astuce, c'est de rester générique si il y a un problème. Et les notions devraient être communes et comprises de la même manière par tout le monde, faute de quoi on aura un usage multiple d'une même propriété. Je trouve ça dommage d'utiliser un outil sans vouloir l'utiliser proprement, pour créer quelque chose de beau à la fin. En toute logique, étant donné le travail de représentation fait par toutes et tous ici, c'est mieux si c'est cohérent et correctement exploitable. J'entends bien qu'il n'est pas possible d'ajouter l'aspect logique de OWL, mais la cohérence du modèle ne dépend que des concepteurs. :)