Wikidata:Bistro

From Wikidata
Jump to navigation Jump to search

Propriété inverse (bis)

[edit]

Après la discussion Wikidata:Bistro/Archive/2024/06#Propriété inverse qui n'est pas une propriété ("Les relations ne sont pas sensées être faites dans les deux sens (quand le lien existe dans un sens, il est trivial de remonter dans le sens inverse automatiquement dans la plupart des cas, inutile de stocker l'information deux fois pour la même chose)."), j'ai le cas suivant :

J'ai retrouvé et complété Dreams in Stone – the palaces of King Ludwig II of Bavaria: Neuschwanstein, Linderhof and Herrenchiemsee (Q64825541) (qui existait en tant que site de la liste du patrimoine mondial, et que j'ai relié à un article sur Vikidia et à une catégorie Commons). Il avait déjà has part(s) (P527) Neuschwanstein Castle (Q4152) (et trois autres). Je complèterait bien sur l'élément de ces monuments : part of (P361) Dreams in Stone – the palaces of King Ludwig II of Bavaria: Neuschwanstein, Linderhof and Herrenchiemsee (Q64825541), mais du coup j'hésite ! Quelle est la bonne pratique ici ? Astirmays (talk) 13:10, 8 September 2024 (UTC)[reply]

@Astirmays: formellement ce n'est pas obligatoire mais c'est possible (la propriété existe cette fois). Cdlt, VIGNERON (talk) 09:35, 10 September 2024 (UTC)[reply]
@Astirmays, VIGNERON: bonjour. La remontée en sens inverse me parait au contraire indispensable : si on consulte le plus connu Neuschwanstein Castle (Q4152), on saura alors qu'il fait partie de Dreams in Stone – the palaces of King Ludwig II of Bavaria: Neuschwanstein, Linderhof and Herrenchiemsee (Q64825541), ce qui permettra éventuellement aux petits curieux d'en savoir plus sur les autres châteaux. Père Igor (talk) 09:59, 11 September 2024 (UTC)[reply]
@Père Igor: l'information est utile et importante, je suis d'accord. Par contre stocker la donnée en double (dans les deux sens) est redondant et donc la cause de multiples problèmes (à commencer par l'incohérence entre les deux sens). Cdlt, VIGNERON (talk) 11:45, 11 September 2024 (UTC)[reply]
@VIGNERON, Père Igor: je vois la logique, mais l'implicite, ou ce que ça implique/suppose, c'est qu'on consulte Wikidata essentiellement sous forme de requêtes, pas en "péon" ou comme moi qui fait occasionnellement une requête avec l'assistant, le reste en navigation web (avec des aller-retours avec Wikipédia et Commons...). Et puis il faut tomber juste dans ses requêtes non ? Il faut penser à has part(s) (P527), peut-être que quelqu'un fera chou blanc si sa requête utilise une autre propriété ? Astirmays (talk) 16:36, 11 September 2024 (UTC)[reply]
@Astirmays: désolé mais moi, c'est uniquement en péon que j'interviens sur Wikidata. Penses-tu que je sois le seul ? Père Igor (talk) 09:38, 12 September 2024 (UTC)[reply]
@Père Igor: je t'ai notifié, mais je répondais plutôt au message de VIGNERON ! Astirmays (talk) 20:06, 12 September 2024 (UTC)[reply]

Bonjour, après avoir importé des données altimétriques sur des communes française, je suis pris d'un doute sur le qualificatif à utiliser. Laquelle des deux déclarations ci-dessous vous semble être correcte ?

1. avec object of statement has role (P3831) suivant l'exemple donné sur elevation above sea level (P2044)

elevation above sea level (P2044)
Normal rank 162 mètre
object of statement has role lowest point
0 references
add reference


add value

2. avec applies to part (P518)

elevation above sea level (P2044)
Normal rank 162 mètre
applies to part lowest point
0 references
add reference


add value

Par ailleurs, quel élément utiliseriez-vous pour indiquer l'altitude moyenne ? average (Q202785), mean (Q2796622), average (Q54835811) ou un autre élément existant ou à créer ?

Merci par avance, Ayack (talk) 12:30, 11 September 2024 (UTC)[reply]

@Ayack: bonnes questions.
Pour object of statement has role (P3831) ou applies to part (P518), les deux me semble assez équivalent sur le principe, je serais bien en peine de choisir avec certitude. Il me semble que object of statement has role (P3831) est la nouvelle méthode et applies to part (P518) l'ancienne, mais c'est plus subtil que cela. Il faudrait poser la question en page de discussion de la propriété.
Pour "altitude moyenne" (ce qui de prime abord ne veut rien dire en soi) il faudrait regarder ce que dit la source exactement (le RGC en l'occurrence si j'ai bien compris, je me souviens vaguement d'un savant calcul plus poussé qu'une simple moyenne, au moins une weighted mean (Q729113) et plutôt à utiliser avec determination method (P459) d'ailleurs).
Cdlt, VIGNERON (talk) 16:53, 11 September 2024 (UTC)[reply]
@VIGNERON merci pour ta réponse. Tu penses à la page de discussion de quelle propriété ? elevation above sea level (P2044), applies to part (P518) ou object of statement has role (P3831) ?
Pour l'altitude moyenne, la source est Geofla® Communes. Elle est décrite comme : "Altitude moyenne de la commune généralisée, calculée à partir de 20 points régulièrement répartis sur la surface de la commune." ([1]).
Tu modéliserais ainsi :
elevation above sea level (P2044)
Normal rank 185 mètre
determination method average (ou un autre élément)
0 references
add reference


add value
Merci. Ayack (talk) 17:19, 11 September 2024 (UTC)[reply]
@Ayack: je pensais plutôt à elevation above sea level (P2044) (parce que cette propriété est sûre alors que le qualificatif à choisir est incertain). Cdlt, VIGNERON (talk) 16:07, 15 September 2024 (UTC)[reply]

En forme de banane

[edit]

Bonjour, vous mettriez quoi comme named after (P138) quand un lac comme Lac Banane (Q114473123) a été nommé parce que ça forme rapelle une banane?. Fralambert (talk) 20:43, 13 September 2024 (UTC)[reply]

@Fralambert: bonne question... Peut-être avec has cause (P828) en qualificatif ? Cdlt, VIGNERON (talk) 16:09, 15 September 2024 (UTC)[reply]
en première idée Q503 tout simplement :) avec qualificatif descripteur de contenu (sûrement à améliorer) : forme
autre idée : créer un item pour le concept "en forme de banane" mais c'est très proche voir identique au concept "arc de cercle" ~~~ Marc wik (talk) 23:30, 15 September 2024 (UTC)[reply]

retable en doublon

[edit]

Bonjour. Je suis en train ce créer des nouveaux éléments concernant des retables inscrits ou classés au titre des monuments historiques. Il y a apparemment un doublon entre retable (Q46686) et retable (Q3714446). Père Igor (talk) 14:18, 16 September 2024 (UTC)[reply]

@Père Igor: pas de doublon, ce sont deux concepts très proches mais différents (les Wikipédias en anglais et en italien notamment ont deux articles distincts). Par contre, c'est effectivement un peu le bazar et perturbant, difficile de faire la distinction entre les deux éléments actuellement (et sans compte le troisième élément altarpiece (Q15711026) encore différent). Il faudrait au moins améliorer la description, mais je ne suis pas assez spécialiste pour m'y risquer (@Shonagon: qui pourra peut-être en dire plus).
Au passage, c'est un bon exemple qui montre qu'il ne faut pas se fier uniquement aux libellés (jusque là j'utilise les exemples "tortue = turtle/tortoise" ou "owl = hibou/chouette").
Cdlt, VIGNERON (talk) 14:30, 16 September 2024 (UTC)[reply]
Bonjour Père Igor. Comme VIGNERON je trouve que que c'est un sacré nœud cette affaire. De ce que je comprends en français cela s'apparente en effet à un doublon, d'autant plus que les définitions étaient identiques et les liens vers des référentiels francophones peuvent entretenir la confusion. En revanche dans d'autres langues (allemand, anglais ou italien) les distinctions existent. Pour corser l'affaire, on pourrait y ajouter en effet altarpiece (Q15711026) et aussi Retablo (Q2396988). Les 4 ont des entrées spécifiques dans le référentiel Art & Architecture Thesaurus (Q611299). Difficile d'y voir clair car en français on utlise "retable" pour les 3 (Retablo (Q2396988) m'est assez obscur). D'accord, sur le fait que l'on peut au moins revoir les définitions, en s'appuyant sur les définitions du Art & Architecture Thesaurus (Q611299), qui demeure le référentiel le plus utilisé dans le domaine , et basculer certains liens de référentiels. J'ai aussi enlevé altarpiece (Q15711026)AAT/300075940 part of (P361) reredos (Q46686) AAT/300075947 qui conduisait à une classification récursive que l'on ne retouve pas dans le Art & Architecture Thesaurus (Q611299). Bien à vous --Shonagon (talk) 20:09, 16 September 2024 (UTC)[reply]

Deux entrées société de commandite par action

[edit]

Bonjour. Je ne m'occupe pas souvent des interwikis peu clairs. Mais là je pense que c'est régularisable. Il y a Kommanditgesellschaft auf Aktien (Q19823288) où je ne peux pas ajouter la traduction Société en commandite par actions à cause de Q837619. Je crois que la fautive est la wikipedia en polonais qui a une entrée avec le nom polonais et un autre article avec le nom allemand de ce type de société. Traumrune (talk) 19:50, 16 September 2024 (UTC)[reply]

@Traumrune: humm, cas intéressant mais complexe. Sauf erreur, il s'agit de deux concepts différents : la forme juridique en général (indépendamment du sujet) et celle spécifique à l'Allemagne. Il me semble que la Wikipédia en polonais a raison de distinguer les deux et en tout cas, sur Wikidata on ne peut pas les confondre. Pour la traduction, société en commandite par actions ne peut pas convenir, il faudrait plutôt quelque chose comme Société en commandite par actions en Allemagne ou Société allemande en commandite par actions. Cdlt, VIGNERON (talk) 08:48, 17 September 2024 (UTC)[reply]

Enki , extension Firefox pour le site des Collections du Louvre s'appuyant sur Wikidata

[edit]

Bonjour.

Pour celles et ceux et que ça intéresserait, j'ai développé une extension Firefox pour le site des Collections du Louvre qui apporte des informations via Wikidata et fait surtout vers des renvois de resssources ou des requêtes : https://github.com/zone47/enki/blob/main/README.md . Comme indiqué sur la page, l'objectif est de donner seulement quelques informations et liens complémentaires potentiellement pertinents et utiles aux internautes.

Bien à vous, Shonagon (talk) 20:24, 16 September 2024 (UTC)[reply]

Super, merci @Shonagon: ; j'avais déjà eu un aperçu mais c'est vraiment un bel exemple de la puissance du web sémantique.
Je me demande dans quelle mesure ce serait adaptable à d'autres musées, et vaudrait-il mieux créer des extensions séparées ou essayer de gérer plusieurs musées dans Enki ?
Cdlt, VIGNERON (talk) 08:50, 17 September 2024 (UTC)[reply]
Hello VIGNERON Merci pour le retour positif. Le contexte du site unique et de la faible disponibilité, seulement Firefox et pas dans le store, en limite néanmoins le potentiel d'usage. Sur l'approche, je me suis posé la même question que celle que tu poses : spécifique ou générique.
L'extension spécifique a un grand intérêt éditorial mais l'usage ne pourrait être que de niche. Dans le cas présent, la sélection des données a clairement été taillée sur le complément utile pour le site Collections du Louvre.
Une extension plus générique serait autrement puissant pour un usage que l'on pourrait envisager plus large. La dimension éditoriale pourrait créer un peu de bruit que l'on pourrait limiter en se concentrant sur le domaine. Par contre je ne suis pas en capacité de développer une telle extension :/.
Ce qui me semble sûr dans les 2 cas, c'est qu'une dimension de sélection éditoriale est souhaitable. Coller Reasonator en volet latéral, ça ferait un wouaouh inutilisable. Avoir une extension pour un musée ou pour des musées (voire un extension pour des livres, des films ou autres) en ne gardant que les données généralement utiles à un domaine pourrait apporter sans surcharge d'informations un complément appréciable sur bien des ressources en ligne. Bien à toi --Shonagon (talk) 19:26, 17 September 2024 (UTC)[reply]