Wikidata:Bistro

Bienvenue sur le Bistro ! Un endroit pour discuter des différents aspects de Wikidata : projet, demandes d'aide, règles et propositions, problèmes techniques, etc. Jetez un œil aux questions fréquemment posées. Les instructions pour fusionner deux éléments sont disponibles à Aide:Fusion. Pour de l'aide avec une requête SPARQL, essayez Wikidata:Request a query. Les demandes de protection (vandalisme...) peuvent se faire à Wikidata:Requêtes aux administrateurs Les demandes de suppression peuvent être faites à Wikidata:Demandes de suppression. Canal IRC : #wikidata-frconnect

Nouvelle discussion

• Afrikaans
• العربية
• беларуская
• беларуская (тарашкевіца)
• български
• Banjar
• বাংলা
• brezhoneg
• bosanski
• català
• کوردی
• čeština
• словѣньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
• dansk
• Deutsch
• Zazaki
• dolnoserbski
• Ελληνικά
• English
• Esperanto
• español
• eesti
• فارسی
• suomi
• føroyskt
• français
• Nordfriisk
• galego
• Alemannisch
• ગુજરાતી
• עברית
• हिन्दी
• hrvatski
• hornjoserbsce
• magyar
• հայերեն
• Bahasa Indonesia
• interlingua
• Ilokano
• íslenska
• italiano
• 日本語
• Jawa
• ქართული
• қазақша
• ಕನ್ನಡ
• 한국어
• kurdî
• Latina
• lietuvių
• latviešu
• Malagasy
• Minangkabau
• македонски
• മലയാളം
• मराठी
• Bahasa Melayu
• Mirandés
• مازِرونی
• Nedersaksies
• नेपाली
• Nederlands
• norsk bokmål
• norsk nynorsk
• occitan
• ଓଡ଼ିଆ
• ਪੰਜਾਬੀ
• polski
• پنجابی
• português
• Runa Simi
• română
• русский
• Scots
• davvisámegiella
• srpskohrvatski / српскохрватски
• සිංහල
• Simple English
• slovenčina
• slovenščina
• shqip
• српски / srpski
• svenska
• ślůnski
• தமிழ்
• తెలుగు
• ไทย
• Tagalog
• Türkçe
• українська
• اردو
• oʻzbekcha / ўзбекча
• Tiếng Việt
• Yorùbá
• 中文

Edit

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/05.

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days.

Q7325

Bonjour, je découvre avec stupeur et consternation cet élément. Il n'y a pas d'élément pour "Chrétiens" et pour cause... Les propriétés associées sont tout aussi dommageables. Cgolds (talk) 18:17, 3 May 2024 (UTC)

Il y a bien Christian (Q106039) mais ce n'est pas exactement le même chose que pour Jewish people (Q7325) (le premier concerne uniquement la religion alors que le second est aussi un groupe technique/culturel).

Après, sur l'élément d'une personne, la plupart du temps on utilisera plutôt religion or worldview (P140) = Judaism (Q9268) ou = Christianity (Q5043).

Cdlt, VIGNERON (talk) 06:35, 4 May 2024 (UTC)

Pour son existence il y a pas grand chose à faire il est lié à pleins d'articles dont fr:Juifs. Pour les déclarations par contre oui le "sous-classe de : sémite" est contestable et dispensable par contre. Et son utilisation en valeur de déclarations également est probablement rarement une bonne idée. author  TomT0m / talk page 11:53, 7 May 2024 (UTC)

Bug de fusion

Bjr, je ne parviens pas à fusionner list of ambassadors of Russia to Antigua and Barbuda (Q6561160) avec list of ambassadors of Russia to Antigua and Barbuda (Q113411873) ni à faire de modif au sein de Q6561160. Bouzinac ^{💬●✒️●💛} 11:06, 5 May 2024 (UTC)

Étrange, la fusion a bien fonctionné mais elle ne semble pas avoir été bien comprise pour Wikidata et effectivement cela empêche (temporairement ?) de modifier list of ambassadors of Russia to Antigua and Barbuda (Q6561160). Cdlt, VIGNERON (talk) 11:38, 5 May 2024 (UTC)

Les identifiants MatchID sont modifiés !

Bonsoir, j'ai perdu la presque totalité des identifiants MatchID introduits par mes soins dans Wikidata (un travail énorme). Ceux-ci ne sont plus les mêmes car changés sur le site [1]. C'est très récent, 24 ou 48 heures au maximum IMHO. Probablement pendant la mise à jour du site le 4 mai dernier. Ce n'est pas un souci d'API.

EDIT : le souci est général, ça ne touche pas que les identifiants MatchID introduits par mes soins. Je dirais que cela touche à vue de nez environ 80 à 90 % des identifiants MatchID. Il me semble que cela continue à se propager au moment où j'écris ces lignes. Cela commence à ressembler à un souci de sécurité comme une faille sur une machine, exploitée depuis l'extérieur.

Un exemple : l'élément Wikidata Q3288655 avait pour identifiant " RD1SQr0-ijle " et désormais, c'est " v32Go_26oQZY ". Idem avec l'acteur François Périer (élément Q1451173). Ancien identifiant : " qw5w3BeriNVf " et désormais " qs_IZiI5W93l ". Avez-vous les mêmes soucis ? Avez-vous une explication ? Par avance merci pour vos explications.

EDIT : la conversation est entamée sur le bistro de WP:fr

Cordialement, Tontonflingueur (talk) 22:35, 5 May 2024 (UTC)

un ticket a été déposé sur le github de matchID. Pyb (talk) 08:08, 7 May 2024 (UTC)

Bonjour, oui, l'identifiant " TONTONFLINGUEUR " sur le GitHub MatchID, c'est moi. J'en ai profité à l'instant pour mettre à jour le lien désormais expiré posté hier par l'identifiant " Ayack " ici : [2] Cordialement, --Tontonflingueur (talk) 12:55, 7 May 2024 (UTC)

Bonjour @Tontonflingueur, permettez-moi de vous indiquer que je trouve votre message sur Github légèrement agressif. MatchID est géré de manière bénévole (cf. https://deces.matchid.io/about#qui-sommes-nous) et par conséquent les développeurs n'ont aucune obligation, ni de résoudre les bugs, ni de s'engager sur des délais de résolution. Ayack (talk) 13:12, 7 May 2024 (UTC)

Bonjour @Ayack, tout cela, je le sais parfaitement. Me pensez-vous totalement idiot ou inculte ? Ce message n'a aucune agressivité. Il met à jour votre lien expiré (cela vous a peut-être froissé et ce n'était pas l'objectif poursuivi). Il pose deux questions et n'exige rien en retour. Cordialement, --Tontonflingueur (talk) 13:32, 7 May 2024 (UTC)

Non, rassurez-vous, je ne suis nullement froissé et vous remercie de cette correction. J'exprimais juste mon ressenti, pensant que vous n'étiez pas au courant du caractère bénévole du projet (ce qui ne suppose rien vous concernant). Puisque ce n'est pas le cas, inutile de s'appesantir davantage sur ce sujet. Ayack (talk) 13:44, 7 May 2024 (UTC)

Il y a malheureusement beaucoup de bruit sur ce sujet. Quelques conseils dans ce genre de cas :

• Ne pas lancer simultanément deux discussions
• Les liens morts ça arrive assez fréquemment. Plusieurs solutions :
  • demander aux gestionnaires des données concernées si c'est un problème temporaire ou non
  • si c'est définitif, leur demander s'ils comptent mettre en place des redirections des anciens liens vers les nouveaux
  • s'il n'y aura pas de redirections, leur demander de nous fournir une table de correspondance entre l'ancien identifiant et le nouveau

Pyb (talk) 22:14, 7 May 2024 (UTC)

Bonjour, tout est rentré dans l'ordre. Voir la discussion de cette nuit avec Rhanka sur le Bistro WP:fr du 6 mai et sur le GitHub MatchID. Cordialement, --Tontonflingueur (talk) 04:19, 8 May 2024 (UTC)

Pierre Puyenbroeck

Bonjour, j'ai créé un élément Q125790664 pour Pierre Puyenbroeck alors que celui-ci existe déjà sous Q96612866 ... Pourriez-vous fusionner ces deux éléments ou supprimer celui que j'ai créé ? Merci. Cordialement, Foscolo (talk) 11:01, 6 May 2024 (UTC)

@Foscolo:, voir Help:Merge/fr pour les explications sur la fusion. Cdlt, VIGNERON (talk) 15:12, 6 May 2024 (UTC)

@VIGNERON:, merci pour ton aide efficace. Cordialement, --Foscolo (talk) 17:58, 6 May 2024 (UTC)

Export sous une autre forme que le triplets

Est il possible d'avoir avec query, un export de résultats sous une autre forme qu'un seul élément par ligne (qui apparaît meme dans le json) ou est ce que quelqu'un a bidouille un code pour que les propriétés ayant plusieurs éléments soient concaténées dans une liste ?

Pierre Martins (talk) 10:52, 7 May 2024 (UTC)

@Pierre Martins Pas certain de bien comprendre la question, il existe de multiples formats pour consulter Wikidata. On peut avoir tout un élément en format json simplement avec une url : comme celle ci, en utilisant Special:EntityData/Q42.json par exemple. C'est tout un élément et ça utilise pleins de lignes. C'est pas non plus du tout sous forme de triplets.

Si c'est pour du SPARQL tu peux peut-être utiliser des agrégations et la fonction "group concat" pour afficher plusieurs valeurs pour une déclaration sur une même ligne, un exemple qui recherche les éléments avec plusieurs noms courts qui sont concaténés avec " ;;" tout sur une même ligne :

select ?item (group_concat (?nom;separator=" ;;") as ?noms) {
  ?item wdt:P1813 ?nom .
  
} group by ?item having (count(?nom) > 2) limit 5

Try it!

Sinon peux-tu préciser la question ? author  TomT0m / talk page 11:21, 7 May 2024 (UTC)

Merci

cela réponds à mon besoin mais la sortie va être un peu cracra.

je vais le coder en python. Pierre Martins (talk) 11:34, 7 May 2024 (UTC)

Je sais pas ce que tu entends par "cracra" mais tu peux récupérer ça en json avec un parser json tout ce qu'il y a de plus propre, ou en TSV / CSV en version tout ce qu'il y a de plus standard aussi. C'est largement plus complexe de redévelopper un outil pour économiser quelques caractères sur la sortie. author  TomT0m / talk page 11:49, 7 May 2024 (UTC)

ok Pierre Martins (talk) 15:05, 8 May 2024 (UTC)

Azulejo

Bonjour. Il y a eu des contributions qui sont à annuler sur Q189046  et Q3179385, mais une imbrication mutuelle empêche le retour aux versions correctes. Quelqu'un sait-il faire ? Cordialement. Ikmo-ned (talk) 06:46, 8 May 2024 (UTC)

Bonjour @Ikmo-ned: c'est corrigé (j'espère, ce genre de cas est toujours compliqué). La difficulté est de trouver le bon ordre d'annulation pour éviter les conflits (un même lien ne pouvant se trouver sur deux éléments). Cdlt, VIGNERON (talk) 09:45, 8 May 2024 (UTC)

Parfait. Merci @VIGNERON:. Ikmo-ned (talk) 13:23, 8 May 2024 (UTC)

Expression des intervalles de temps

Bonjour, J’ai une interrogation un peu théorique sur les formats de dates ; ce n’est pas spécifique à Wikidata, plutôt lié au mode de représentation des dates en XML. Wikidata ne prend pas en charge la précision d’une date en dessous de la journée, cependant dans les déclarations de dates on a quand même l’heure 0 qui est ajoutée. Par exemple si on écrit 30 janvier 1830, dans le code on va avoir 1830-01-30T00:00:00Z. Là où ça m’interpelle c’est quand on a des intervalles de temps.

Imaginons quelque chose qui a une durée annuelle : par exemple un registre ou un journal annuel qui comprend des entrées horodatées du 1er janvier 2023 0:00 au 31 décembre 2023 23:59. Je vais écrire 1 janvier 2023 en date de début et ça sera transcrit 2023-01-01T00:00:00Z dans le code, jusque-là pas de problème ; pour la date de fin je vais écrire 31 décembre 2023 et ça va être transcrit 2023-12-31T00:00:00Z et là en revanche je bugue un peu. En effet pour moi T00:00:00Z ne comprend que la première minute du 31 décembre, du coup si une entrée de notre journal a été faite le 31 décembre à 17:59 ne sera t-elle pas exclue ? Et du coup pour exprimer une durée annuelle ne faudrait-il pas écrire date de début : 1 janvier 2023 et date de fin 1 janvier 2024 ? Runi Gerardsen (talk) 08:41, 8 May 2024 (UTC)

Réponse aussi un peu théorique : en principe on doit tenir compte des précisions pour faire les comparaisons de date (en pratique on le fait effectivement pas toujours, ça compliquerait pas mal les choses dans une requête par exemple et c'est pas toujours très utile), et si on a un jour introduction de précisions sur les minutes les deux dates seront incomparables directement sans tenir compte de l'intervalle, l'une des date aura le jour en précision et l'autre la minute.

En pratique actuellement on ne peut pas rentrer les minutes donc la question ne se pose pas trop.

Pour répondre à ta question sinon, je ne vois rien comme convention dans Help:Date, faudrait tenter une discussion sur le chat international du projet ou une RfC, ou mettre une ligne dans Help:Date pour régler ça. Mais mettre la date du jour d'après n'est pas la seule solution, on peux potentiellement garder "31 décembre" et dans une requête filtrer sur l'intervalle en faisant un truc (pseudo code) style filter(?date > "1 janvier 2023" && ?date < "31 décembre 2023" + "1 jour"), en rajoutant un jour à l'instant de la date de fin vu que c'est une précision du jour et qu'il faut donc compter le jour lui même dans l'intervalle. C'est une question de convention de gestion des précisions, en fait. author  TomT0m / talk page 09:40, 8 May 2024 (UTC)

Bug

A partir de la page d'accueil, la coche à gauche sur Service de requête aboutit sur cette page d'erreur https://www.wikidata.org/wiki///query.wikidata.org/ Bouzinac ^{💬●✒️●💛} 06:05, 9 May 2024 (UTC)

cela ne figure pas dans MediaWiki:Sidebar, doit donc falloir passer par Phabricator. Vu que ça touche l'interface en anglais, le problème devrait vite être détecté Pyb (talk) 10:40, 9 May 2024 (UTC)

Un étang n'est pas un lac

Bonjour. Je suis surpris sur le fait que l'étang des Landes (Q49316685), créé par Bot, soit considéré comme un lac (Q23397) (avec référence GEOnet Names Server) et non comme un étang (Q12719646), alors que toutes les occurrences de cette étendue d'eau font référence à l'étang : réserve naturelle nationale de l'étang des Landes (Q2371227), Étang des Landes (ZNIEFF), Étang des Landes (Natura 2000), ruisseau de l'Étang de Landes, Bassin versant de l'étang des Landes. Père Igor (talk) 16:24, 10 May 2024 (UTC)

@Père Igor: la différence entre un étang est un lac est grandement arbitraire et subjective, les humains confondent souvent les deux (on peut penser à l'étang de Berre qui malgré son nom n'est pas un étang et qui est plus grand que bien des lacs alors que les étangs sont sensés être plus petits que des lacs :/), ce n'est pas étonnant qu'un bot fasses aussi la confusion.

Il faudrait regarder exactement ce que dit la source (Geographic Names Server (Q1194038) encode les informations de façon assez opaque de prime abord) et : soit le bot a mal interprété la source et on corrige directement "lac" en "étang", soit cette source dit bien que c'est un lac et on ajoute que c'est un "étang" au rang privilégié et avec d'autres sources.

Cdlt, VIGNERON (talk) 17:25, 10 May 2024 (UTC)

Je viens de vérifier desig_cd: LK veut bien dire que le Feature Designation Code est un lake (voir cette liste des codes). J'ai donc adopté la deuxième solution et ajouté "étang" en plus (sans source, car je n'en ai pas encore trouvé de fiable pour le moment, je me base sur le nom pour le moment).

Au passage, je note que le code Natura 2000 sur Landes pond (Q49316685) devrait être retiré et déplacé sur un élément sur la zone naturelle elle-même.

Cdlt, VIGNERON (talk) 17:50, 10 May 2024 (UTC)