Wikidata:Bistro/Archive/2016/10

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Maires de France

Bonjour à tous,

Pensez-vous envisageable l'import des maires des communes françaises depuis Wikipédia ? Ils sont généralement recensés avec le modèle Élu. Il faudrait donc créer des éléments pour les noms de maires n'ayant pas d'article. Dans le modèle est renseigné :

Il existe également un fichier sur data.gouv.fr (Liste des maires au 17 juin 2014) qui permettrait l'ajout de date of birth (P569), sex or gender (P21) et éventuellement occupation (P106) aux maires actuels.

Tubezlob (🙋) 19:23, 2 October 2016 (UTC)

Mise à jour infobox après modification sur wikidata

Bonjour,

Suite à la nouvelle version de GNU MPFR, j'ai ajouté la nouvelle version 3.1.5 sur l'élément wikidata Q1881759, puisque l'infobox se base dessus. Mais après plusieurs jours, la page Wikipédia GNU MPFR indique toujours 3.1.4 dans l'infobox. Que faire pour que la mise à jour se fasse sur la page Wikipédia? Vincent Lefèvre (talk) 09:19, 3 October 2016 (UTC)

J'ai trouvé. Je pensais que la sélection de la version se faisait sur la date la plus récente. En fait, il fallait modifier les rangs de manière à ce que la dernière version soit de rang « préféré » (rang privilégié), et seulement celle-ci. Vincent Lefèvre (talk) 11:26, 3 October 2016 (UTC)

4e anniversaire de Wikidata

Bonjour le bistro,

Vous avez peut-être vu passer mon message sur le Project Chat, mais je vous le refais en français rien que pour vous ;)

Comme vous le savez, Wikidata fêtera ses quatre ans le 29 octobre, et pendant toute la semaine suivante, on célèbrera ça avec différents évènements en ligne et IRL.


Les évènements dans la vraie vie

On organise une soirée dans les locaux de Wikimedia Deutschland, à Berlin, le vendredi 4 novembre. C'est l'occasion de rencontrer d'autres contributeurs, de fêter l'anniversaire, de jouer à des jeux de société et de manger du gâteau. La liste d'inscription est par ici.

Si vous ne pouvez pas venir à Berlin, pas de problème, n'hésitez pas à créer votre propre rencontre ! Il suffit de trouver d'autres contributeurs à Wikidata, ou personnes qui apprécient le projet, et de créer votre propre évènement. Pas besoin de prévoir quelque chose de très complexe, une date et un lieu (bar, lieu accessible au public...) suffisent pour lancer les invitations. Si vous avez besoin d'aide, n'hésitez pas à me solliciter. Toutes les rencontres sont listées ici.


Les histoires de contributeurs

Cette année, au lieu d'un long éditorial, nous aimerions collecter de nombreuses courtes histoires racontées par les contributeurs, décrivant leur vision de Wikidata ou quelque chose de particulier qui vous est arrivé en contribuant.

Vous pouvez vous inspirer d'une de ces questions :

  • Comment as-tu commencé à contribuer sur Wikidata ?
  • Quel est le projet le plus cool auquel tu as participé sur Wikidata ?
  • De quel accomplissement es-tu le-la plus fier-fière ?
  • A l'inverse, un échec qui était intéressant et qui t'a appris quelque chose ?
  • Quel est le meilleur moment communautaire que tu as vécu sur Wikidata ?

Plein de formats sont possibles : texte court, post de blog, planche de BD, vidéo... l'anglais est préféré, mais bien sûr vous pouvez aussi écrire en français et demander de l'aide pour la traduction.

Vous pouvez publier le contenu dans une sous-page de votre PU, ailleurs sur le web, ou encore me l'envoyer par mail. Toutes les histoires seront ajoutées sur la page de l'anniversaire.

La date limite pour partager vos histoires est le 28 octobre. Si vous avez des questions, n'hésitez pas !

Enfin, je me permets de dénoncer notifier des contributeurs dont je sais déjà qu'ils ont des histoires à raconter, qu'ils publient sur un blog ou non. Si vous aviez un peu de temps pour pondre une broutille, ce serait vraiment chouette :) @Harmonia Amanda, Ash_Crow, Alphos, Poulpy, Coyau, Shonagon: @Dachary, Tpt, VIGNERON, Envlh:

Merci beaucoup, Lea Lacroix (WMDE) (talk) 10:58, 5 October 2016 (UTC)

Creative Commons 4.0

Hello! I'm writing from the Wikimedia Foundation to invite you to give your feedback on a proposed move from CC BY-SA 3.0 to a CC BY-SA 4.0 license across all Wikimedia projects. The consultation will run from October 5 to November 8, and we hope to receive a wide range of viewpoints and opinions. Please, if you are interested, take part in the discussion on Meta-Wiki.

Apologies that this message is only in English. This message can be read and translated in more languages here. Joe Sutherland (talk) 01:34, 6 October 2016 (UTC)

Naissance et mort d'un langue

Bonjour, quelles propriétés utiliseriez-vous pour renseigner les dates de naissance et de mort d'une langue, afin de coder une partie des informations de w:en:List of languages by time of extinction. Cordialement, --Gloumouth1 (talk) 11:51, 22 September 2016 (UTC)

Date de début et date de fin. Avec le degré de précision qui s'impose bien sûr. --Harmonia Amanda (talk) 12:13, 22 September 2016 (UTC)
start time (P580) et end time (P582) ne sont-elles pas censées être des qualificateurs ? --Gloumouth1 (talk) 19:09, 22 September 2016 (UTC)
@Gloumouth1: pas nécessairement, voir Baroque (Q37853) par exemple. Pamputt (talk) 21:03, 22 September 2016 (UTC)
@Pamputt, Harmonia Amanda: ok, va pour end time (P582), merci. Mais c'est quand même étrange qu'on ait des propriétés assez spécialisées (par exemple dissolved, abolished or demolished date (P576) pour les bâtiments et les organisations) et qu'on utilise dans d'autres cas des propriétés génériques (par exemple end time (P582) pour des mouvements artistiques). --Gloumouth1 (talk) 08:40, 23 September 2016 (UTC)
On crée des propriétés spécialisées quand on en a besoin. La date de dissolution d'une organisation n'est pas forcément sa date de fin, certaines avaient de fait cessé d'exister bien avant, d'autres ont subsisté, etc. On crée quand la propriété générique ne suffit pas. Dans le cas des langues, je ne vois pas en quoi les propriétés actuelles ne suffisent pas mais si jamais le besoin s'en fait réellement sentir, propose une nouvelle propriété. En sachant que nous nous efforçons toujours de généraliser les propriétés. Par exemple j'avais besoin de propriétés pour gérer le nombre de chiens dans un attelage au début et à la fin d'une course ; suite à discussions, nous avons réussi à généraliser pour que les propriétés englobent aussi le nombre de joueurs au début et à la fin d'un match... --Harmonia Amanda (talk) 08:50, 23 September 2016 (UTC)
@Gloumouth1: Utilise significant event (P793) avec le qualificateur point in time (P585). Il te faut trouver par contre l'élément qui décrive correctement la naissance/mort d'une langue. Plus on avance, plus le concept de propriétés spécialisées est à revoir. Snipre (talk) 08:57, 23 September 2016 (UTC)
@Snipre, Jura1: Même problème que j'ai porté sur WikiProject Names il y a quelque jour Plutôt que d'utiliser évènement clé j'aurai plutôt utilisé
⟨ langue ⟩ instance of (P31) View with SQID ⟨ langue morte ⟩
start time (P580) View with SQID ⟨ '2016' ⟩
. Clairement les langues mortes sont une classe de langue qu'on peut définir par langue dont il n'y a plus de locuteur vivant. Ça n'empêche sans doute pas de définir évènement clé mais ça rend je pense les choses moins immédiates à comprendre. author  TomT0m / talk page 13:59, 24 September 2016 (UTC)
@Gloumouth1, Harmonia Amanda, Snipre, Jura1: start time (P580) et end time (P582) est une façon simple d'indiquer la date de naissance et de mort d'une langue mais une ou plusieurs propriétés *en plus* serait utile. Une propriété spécifique statut de la langue pourrait être utile, par exemple cela ne répond pas exactement au besoin exprimé mais il existe la classification de Atlas UNESCO des langues en danger dans le monde de l'UNESCO (ledit Atlas ayant déjà 3 éditions papier : 1996, 2001 et 2009 ainsi qu'une édition interactive en ligne régulièrement mise à jour). Sinon, il y a aussi number of speakers, writers, or signers (P1098) (quand ledit nombre est de 0, on peut considérer la langue comme morte, même si la mort d'une langue ne survient pas exactement au moment de la mort du dernier locuteur). Cdlt, VIGNERON (talk) 17:14, 25 September 2016 (UTC)

Je ne vois pas trop pourquoi je me fais pinger sur ce sujet .. mais bon .. voici mon avis:
<langue> significant event (P793) Q27031182 statement is subject of (P805) <entité de la personne>.
--- Jura 11:53, 26 September 2016 (UTC)

J'ai finalement opté pour la solution impliquant l'ajout de point in time (P585), comme par exemple avec Klallam (Q33404) (il faudra que je généralise l'approche à toutes les langues de la liste). Maintenant, j'arrive à construire la liste des langues mortes (tester la requête), mais je n'arrive pas à construire la liste des langues mortes par ordre de disparition (tester la requête). Une idée ? --Gloumouth1 (talk) 11:27, 6 October 2016 (UTC)
@Gloumouth1: Yep, une idée : [%20%0A%20%20%20%20%20%20ps%3AP1098%20%3Flocutors%20%3B%0A%09%20%20pq%3AP585%20%3Fdate%20%0A%20%20%20%20%0A%20%20%09FILTER%20%28%3Flocutors%20%3D%200%29%20.%0A%09SERVICE%20wikibase%3Alabel%20{%0A%09%09bd%3AserviceParam%20wikibase%3Alanguage%20%22fr%22%20.%0A%09}%0A%0A}%0AORDER%20BY%20DESC%28%3Fdate%29%0ALIMIT%20300 cette requête] qui marche. J'ai utilisé la syntaxe des "blank node" que j'ai découvert récemment dans des requêtes de je sais plus qui, qui peut de manière fort commode permettre de filter les décarations en fonction des valeurs de qualificateurs sans avoir à créer de variable pour récupérer la structure de donnée rdf de la déclaration : ?item p:P17 [ pq:qualif1 ?val1 ; pq:qualif2 ?val ; ... ; ps:P1098 ?la_valeur_principale] . Du coup on utilise que des couple et plus des triplets à l'intérieur des crochets. author  TomT0m / talk page 17:10, 6 October 2016 (UTC)
@TomT0m: Super ! Merci. --Gloumouth1 (talk) 10:51, 7 October 2016 (UTC)

Aide date

Bonjour,

J'aimerais indiquer que la peinture Q3443335 a été conçue durant la "seconde moitié du XIIIe siècle". Pour le moment j'ai juste pu mettre "date de confection = 1250s", mais ce n'est pas exactement ce que je veux. Quelqu'un pourrait-il m'expliquer comment faire ? Merci, Binabik (talk) 20:29, 28 September 2016 (UTC).

@Binabik: Il n'est pour l'instant pas possible de rentrer des précisions entre la décennie et le siècle - même si le moteur peut stocker des choses plus précises - Davec l'interface. On a pour contourner ce problème les propriétés earliest date (P1319) View with SQID and latest date (P1326) View with SQID à utiliser en qualificateur. Du coup tu peux mettre des précisions sur les bornes :) author  Binabik / talk page 20:46, 28 September 2016 (UTC)
Merci @TomT0m:, ce n'est pas idéal mais j'ai implanté cette solution pour le moment ! Binabik (talk) 20:21, 29 September 2016 (UTC)
Bonjour Binabik. Je déterre ta question sur la date de création de Heiji Monogatari Emaki (Q3443335) correspondant à la seconde moitié du 13e siècle. Après maints questionnements et pratiques différentes, un consensus se dégage aujourd'hui : inception (P571) 1275 précision siècle avec en qualificateur earliest date (P1319) 1250 et latest date (P1326) 1300. Ces deux dernières propriétés ont été précisées initialement comme à n'être utilisées qu'uniquement en qualificateur ; ce qui en pratique est le cas dans 99.6% des utilisations. Une petite nuance où certains vont mettre 1250 précision siècle, mais personnellement et comme d'autres, je prends l'année du milieu de la période qui est la plus approximative et qui place au mieux pour les tris chronologiques. Quant à la précision elle se ferait plutôt sur la période couverte, donc ici le siècle. Bien à toi --Shonagon (talk) 22:22, 7 October 2016 (UTC)
@Binabik comme le précise TomT0m Wikibase permet de stocker directement des dates avec précision de période, mais cela n'apparait pas dans l'interface et ne peut être renseigné que par script (il y a un ticket Phabricator sur le sujet). En fait, je me rends compte que c'était le cas pour cet élément dont j'avais édité la date il y a deux et demi avec mon bot : https://www.wikidata.org/w/index.php?title=Q3443335&diff=118402273&oldid=98764814 il s'agissait de 1250,precision=8,after=5 (restitué en 50 ans). Théoriquement c'était donc bien la deuxième moitié du treizième siècle qui était stocké dans Wikidata mais personne ne le voyait dans l'interface (même si par ailleurs je réutilisais cette information)... J'ai abandonné cette pratique pour celle décrite précédemment. --Shonagon (talk) 23:12, 8 October 2016 (UTC)
@Shonagon: merci pour toutes ces précisions Shonagon ! Binabik (talk) 17:49, 9 October 2016 (UTC)

Lieu et anachronisme

Bonjour,

Hier soir a eu lieu un atelier Wikidata à Rennes et alors que je faisais une démonstration, je me suis une réflexion : comment gérer les localisations dans des lieux anachroniques. Typiquement, il y a 14 467 personnes nées dans une commune of France (Q484170) avant 1789 : 

SELECT ?item ?itemLabel ?date ?placeLabel
WHERE
{
	?item wdt:P27 wd:Q142 ; wdt:P19 ?place .
	?item wdt:P569 ?date FILTER (?date < "1789-01-01T00:00:00Z"^^xsd:dateTime) .
    ?place wdt:P31 wd:Q484170.
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}
ORDER BY ?date
Try it!

Idem, 4 191 personnes pour décédées avant 1789.

Inversement, j'ai trouvé très peu de personnes avec pour lieu (de naissance ou de décès) un lieu qui existait à l'époque (54 sont nés et 5 sont morts en Gaul (Q38060), 2 sont mort à Lutetia (Q270273), 1 né et 1 mort à Lugdunum (Q665), 7 nés et 4 morts à Veldidena (Q877413), tout dans l'antiquité, rien au Moyen Âge/Renaissance...)

Clairement, il me semble que l'on ne peux pas retirer la plupart de ces déclarations (qui sont souvent sourcées tel que d'ailleurs) mais formellement, c'est faux ou tout au moins anachronique et ça me gêne un peu de laisser les données ainsi. Un point évident serait de commencer par rajouter le lieu existant à l'époque, mais ensuite ? faut-il mettre le rang privilégié au lieu de l'époque ?

Le sujet a-t-il déjà été abordé quelque part ? Avez-vous des idées, avis, commentaires ?

Cdlt, VIGNERON (talk) 08:43, 6 October 2016 (UTC)

Ajouter les bons lieux puis changer le rang des déclarations pour « déprécié » avec le qualifier reason for deprecated rank (P2241) : anachronism (Q189203) (ou peut-être place of birth wrong (Q23646697) ou quelque chose du genre) ? — Metamorforme42 (talk) 20:40, 6 October 2016 (UTC)
Moui, je suis moyennement convaincu. Un paquet de communes sont des paroisses, des villes ou des bourgs qui existaient avant 1789, c'est juste qu'elles n'ont pas le P31 correspondant. -Ash Crow (talk) 09:10, 9 October 2016 (UTC)
@Ash Crow: Je ne suis pas complètement sûr non plus, d'où mes questionnements et ma demande d'avis
Techniquement, selon les diverses lois et décrets de novembre-décembre 1789, *toute* commune est issue d'une (ou plusieurs) ville, bourg, paroisse, communauté, etc. Si certaines communes ont d'autres valeurs en instance of (P31), ce qui rend la déclaration moins anachronique, ce n'est pas toujours le cas. Les communes ayant parfois jusqu'à une dizaine de instance of (P31), n'est-ce pas un signe qu'il faudrait séparer cet élément en plusieurs sous éléments ? (parfois, on ne sait plus trop à quoi font référence les autres déclarations, typiquement à quoi correspond Q90#P571 ? et je suis ravi d'apprendre que Anne Hidalgo est un évêque, ou en tout cas le chef de l'exécutif d'un évêché :P). En plus, il ne s'agit pas uniquement de juste avant 1789 mais dans l'absolu de tout date entre le big bang et le présent ; je prenais l'exemple des communes de France avant 1789 car il est à la fois relativement simple, représentatif d'autres cas et avec de nombreux cas d'utilisations anachronique. Le même problème se pose en théorie avec La Chapelle-aux-Saints 1 (Q2117305) - qui a country (P17) = France (Q142), 60 000 ans la création de France (Q142) - mais c'est un cas rare et trop extrême pour être vraiment pertinent. On voit bien que pour l'Antiquité, il y a visiblement eu quelques essais, est-ce une pratique à encourager ? En plus pour les grandes villes, les paroisses sont plus petites donc plus précises, cela me semble donc une situation doublement gagnante.
@metamorforme42: pourquoi pas... l'avantage de ta méthode est que l'on peut mettre reason for deprecated rank (P2241) mais je trouve ça tout de même un peu violent, même si un anachronisme est techniquement une erreur, ce n'est qu'une erreur par rapport à l'époque où l'on se place ; il n'est pas inhabituel de voire des tours de passe-passe comme « né à l'emplacement actuel de XXX » pour éviter l'anachronisme. Au final, le rang privilégié n'est-il pas plus adapté, non ? (le choix du rang est toujours cornélien...).
Cdlt, VIGNERON (talk) 09:34, 10 October 2016 (UTC)
Le problème c'est que "Machin est né à Truc en 42" peut vouloir dire plusieurs choses
  1. Truc existait en 42 ; son territoire géographique et celui actuel ont au moins en commun le lieu exacte de naissance de Machin
  2. Truc existait en 42 ; son territoire d'alors englobe le lieu de naissance de Machin, mais pas son territoire actuel (possiblement, car Truc n'existe plus, car remplacé par Bidule)
  3. Truc n'existait pas en 42 ; toutefois, son territoire actuel englobe le lieu de naissance de Machin.
Perso, je ne suis pas pour utiliser place of birth (P19) pour le cas 3, je pense que c'est mieux de limiter au cas 2, et que les requêtes cherchant à répondre à 3 passent par une propriété "partage une partie du territoire" entre Truc et Bidule (je crois que cette propriété vient d'être créée en plus non ?). Léna (talk) 14:38, 10 October 2016 (UTC)
  • Il y a aussi
4. Truc existait déjà en 42, mais s'appellait Trouc et l'entité pour Truc, couvre aussi Trouc.
On pourrait rajouter d'autre variantes, p.e. sur les P31 à utiliser pour l'un ou l'autre.
--- Jura 15:09, 11 October 2016 (UTC)

Championnat du monde de vitesse moto

Bonjour,

J'ai, depuis quelques temps, une nouvelle marotte à mon actif : le Grand Prix motorcycle racing World Champions by year (Q16225427) (surtout, je dois l'avouer, les dernières occurences).

Bref, j'ai vu le boulot abattu sur les saisons du Tour de France (Q33881), et je me demandais si un pro de la propriété pourrait m'aider à compléter aussi bien que cela les différentes saisons et courses, car c'est un peu un sac de noeuds et que le fait que chaque Grand Prix est composé de 3 courses sur 3 catégories différentes (actuellement MotoGP, Moto2 et Moto3) n'aide pas à clarifier le sujet.

Merci d'avance ! Amicalement. --Indeed [knock-knock] 10:59, 6 October 2016 (UTC)

Je pense qu'il faudrait relancer le projet Wikidata:WikiProject Sport results pour que les avancées faites dans chaque sport/événement sportif soient profitables à tous. Tubezlob (🙋) 16:15, 6 October 2016 (UTC)
Il me semble que @Harmonia Amanda: a fait face aux mêmes questionnements quand elle a traité les courses de chiens de traîneau, elle pourra peut-être apporter des éclaircissements. -Ash Crow (talk) 10:33, 9 October 2016 (UTC)
Ça prend du temps. En premier lieu il te faut établir une documentation qui va lister les propriétés qui sont utilisables et comment elles le sont. Si tu as un doute sur la manière d'utiliser une propriété, tu peux demander à @TomT0m:. Quand c'est bon, tu peux ensuite en discuter avec d'autres locuteurs qui travaillent sur le thème et si vous vous entendez bien ça progressera bien et ta charge de travail sera diminuée. Avec le temps, tu verras que tu auras surement besoin d'éléments précis à utiliser comme qualifiants. Jérémy-Günther-Heinz Jähnick (talk) 17:48, 9 October 2016 (UTC)
@Indeed: : j'ai listé pas mal de choses dans le Wikidata:WikiProject Sled dog racing. Par exemple la Finnmarksløpet 2008 (Q18644876) a pour instance of (P31) Finnmarksløpet (Q649930) et has part(s) (P527) Q18645381 et Q18645138... Il faut construire une arborescence : tous les prix sont-ils subdivisés en différente courses ou pas, par exemple. Mais a priori je dirais qu'effectivement ton travail va beaucoup ressembler au mien, avec des saisons sportives, des courses qui sont parfois subdivisées. N'hésite pas à me contacter sur ma pdd si tu as des questions plus précises, et n'hésite pas à explorer aussi bien l'onglet sur les propriétés que l'onglet "todo" du projet sur les courses de chiens de traîneau. --Harmonia Amanda (talk) 09:37, 10 October 2016 (UTC)

@Tubezlob, Ash Crow, Jérémy-Günther-Heinz Jähnick, Harmonia Amanda: merci pour vos conseils et suggestions, j'ai commencé ici User:Indeed/moto, vos avis sont les très bienvenus. Amicalement. --Indeed [knock-knock] 13:00, 10 October 2016 (UTC)

Bug de l'interface ?

Bonjour,

Quelqu'un sait-il pourquoi, parfois, quand je clique sur modifier pour changer un label/description/alias, je tombe sur la page Special:SetLabelDescriptionAliases au lieu de modifier directement sur la page de l'élément ? (cela survient apparemment de façon aléatoire, cela disparaît généralement quand on re-clique une deuxième fois et ce n'est généralement pas gênant sauf quand l'on veut modifier plusieurs langues ne même temps).

@Lea Lacroix (WMDE):

Cdlt, VIGNERON (talk) 15:02, 11 October 2016 (UTC)

Ouaip, ça arrive quand le javascript de la page n'est pas totalement chargé : c'est l'interface pour ceux qui ne veulent pas de js. author  TomT0m / talk page 15:08, 11 October 2016 (UTC)
(tiens, tant que Léa est notifiée, j'ai créé il y a quelques temps un modèle {{Ping devteam}} pour notifier l'équipe de dev. Mais je sais pas trop comment le maintenir et qui inclure dedans ... c'est possible que tu t'en charges ? (et en fasse la pub si tu penses que c'est approprié). author  TomT0m / talk page 15:10, 11 October 2016 (UTC)
Salut @TomT0m: et merci pour l'info. Je vais en parler à mes collègues, dans un premier temps je me disais que ce n'était pas forcément nécessaire puisqu'il y a déjà la page de contact de la devteam pour les bugs, et que les gens peuvent me ping directement et je transmets ensuite l'info, mais si l'on pense à plus long terme, un modèle peut en effet être intéressant. Je te tiens au courant :) Lea Lacroix (WMDE) (talk) 09:04, 13 October 2016 (UTC)

Création d'une propriété

Bonjour à tous,

J'aimerais créer une nouvelle propriété pour l'infobox biographie, mais pour tout dire je suis tout à fait béotien sur wikidata, et j'ai eu beau essayer de suivre la marche indiquée, m'arracher les cheveux, je rends les armes : c'est complètement hermétique et décourageant pour les non initiés ! Voici le problème que j'aimerais résoudre : Dans l'infobox biographie2, il existe la propriété "monture" (P3091), utile pour les cavaliers et les jockeys. Mais on ne peut pas remplir le champ "monture" pour les entraîneurs de chevaux, lesquels ne montent évidemment pas leurs protégés... Ne faudrait-il pas créer aussi une propriété "chevaux associés", plus logique ? Voire, remplacer plus simplement "monture" par ce "chevaux associés" ? Ce serait vraiment plus clair.

J'ai déjà demandé de l'aide ici, en vain malheureusement. Aussi, si quelqu'un avait la bonne grâce de me donner un coup de main sur ce sujet, je lui en serais très reconnaissant. Merci par avance, Glissando (talk) 23:43, 14 October 2016 (UTC)

@Glissando: Si vous pensez qu'il faut une nouvelle propriété, le meilleur serait de faire une demande de propriété comme sur Wikidata:Property proposal/Person. Le mieux est d'argumenter le plus possible en quoi votre propriété est différente des existantes. Après que la discussion semble faire consensus vers sa création, vous pourrez demander à un créateur de propriété de la créer pour vous. --Fralambert (talk) 01:18, 15 October 2016 (UTC)
Lors du débat, on risque de te faire valoir qu'il n'y a pas que des chevaux qui sont parfois étroitement associés à des humains. Dresseurs, soigneurs ont affaire à des ours, des tigres, etc. En fait il faudrait peut-être élargir partner in business or sport (P1327) aux animaux. Thierry Caro (talk) 06:43, 15 October 2016 (UTC)

Extraction de la liste de communes de France

Bonjour, j'essaye d'extraire la liste des communes de France à l'aide de la requête ci-dessous (initialement écrite par Ash Crow), mais elle tombe à chaque fois en timeout... Auriez-vous une autre solution svp ? 

SELECT ?commune ?communeLabel ?insee {
  ?commune p:P31 ?statement .
  ?statement ps:P31 wd:Q484170 . 
  FILTER NOT EXISTS { ?statement pq:P582 ?x } .
  ?commune wdt:P374 ?insee .
  
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "fr" .
  }
}
Try it!

Merci. — Ayack (talk) 09:41, 14 October 2016 (UTC)

Bon, j'ai fini par y arriver en découpant en paquet à l'aide d'un FILTER REGEX(?insee, "^(3|4|5)") .. C'est pas très propre mais au moins ça fonctionne... — Ayack (talk) 16:32, 14 October 2016 (UTC)
@Ayack: c'est étrange la taille de l'ensemble requêté est pourtant assez faible, il ne devrait pas y avoir de timeout...
Encore plus bizarre, la requête fonctionne très bien sans le service label. Peut-être est-ce juste un problème temporaire de query... J'ai essayé avec une autre méthode pour récupérer le label, cela fonctionne (c'est tout de même étrangement long) :
SELECT ?commune ?communeLabel ?insee {
  ?commune wdt:P374 ?insee .
  ?commune p:P31 ?statement ; rdfs:label ?communeLabel.
  ?statement ps:P31 wd:Q484170 . 
  FILTER NOT EXISTS { ?statement pq:P582 ?x } .
  FILTER (lang(?communeLabel) = "fr"). 
}
Try it!
Cela ne change rien au fond du problème mais pour optimiser le temps de réponse d'une requête, il vaut mieux mettre les parties dont on sait qu'elle génère moins de résultats en premier. En l'occurrence, mettre le P374 au tout début diminue un peu le temps de réponse (pas suffisamment pour éviter le timeout ceci dit).
Cdlt, VIGNERON (talk) 17:24, 14 October 2016 (UTC)
Merci, mais chez moi ta query tombe aussi en timeout... — Ayack (talk) 08:03, 15 October 2016 (UTC)

Quelle propriété utiliser ?

Hello,

je cherche depuis tout à l'heure quelle propriété utiliser pour indiquer la date approximative d'une publication. Dans le cas du Taiheiki, la BNF indique les années 1370. Comment indiquer ça dans l'entrée sur Wikidata ? Cdlt, XIIIfromTOKYO (talk) 16:52, 15 October 2016 (UTC)

@XIIIfromTOKYO: Date de publication est faite pour ça. Il n'y a pas de trucs spécifiques pour les dates approximatives, tu peux fixer une précision personnalisée pour la date en cochant la casé "définir manuellement" quand le focus est sur la valeur de la date. "Décennie" est un des choix proposé donc ça pose pas de problèmes. Dans le cas de valeurs plus délicate on utilise des propriétés "date (limite inférieure)" et "date (limite supérieure)" en attendant qu'on puisse utiliser d'autres valeurs de précisions. author  TomT0m / talk page 16:59, 15 October 2016 (UTC)
Ok merci, c'est réglé. Cdlt, XIIIfromTOKYO (talk) 17:14, 15 October 2016 (UTC)

Retour sur les populations des communes françaises

Bonjour à tous (dont @Zolo: et @Ash Crow:.

Très peu de données de population sont renseignées pour les communes françaises dans Wikidata. Et celle qui sont renseignées sont dans la plupart des cas pas ou mal sourcées (par exemple avec " imported from French Wikipedia" ou pire " imported from Dutch Wikipedia"). La raison est, pour partie, liée à la difficulté pour prendre en compte le nouveau mode de recensement depuis la réforme de 2004 (voir ici).

Pour rappel, depuis janvier 2004, les communes de moins de 10 000 habitants sont recensées exhaustivement tous les cinq ans par roulement, et les communes de 10 000 habitants ou plus font l’objet d’une enquête par sondage tous les ans, 40 % de leur population étant recensée au bout de cinq ans. La première population légale issue de ce nouveau mode de recensement a été publié en 2006.

Si on veut que les données puissent être ultérieurement utilisées dans la WP francophone et remplacer les modèles actuels, il faut qu'elles soient correctement formatées dans Wikidata et ... (non le moindre) que soient développés des modèles de récupération des données WD et d'affichage en tableau ou graphique, en respectant la charte du projet "Communes de France".

Pour celà il est essentiel de saisir, pour chaque valeur de population (d:Property:P1082) de commune, codée par son code Insee (d:Property:P374), les propriétés et qualificateurs suivants :

Propriété Qualificateur
Nature Code Code Commentaires
Criterion used criterion used (P1013) municipal population (Q15715409) Il existe trois types de données de population en France : la population municipale, la population comptée à part et la population totale. Seules les populations municipales sont indiquées dans Wikipédia.
Point in time point in time (P585) valeur de l'année
Determination method determination method (P459) survey (Q3490295)
census (Q39825)
ou ?		 Recensement réel (d:Q39825) : pour 1/5 des communes < 10 000 habitants
Estimation (code à définir) : interpolation ou extrapolation pour 4/5 des populations < 10 000 habitants),
Sondage (d:Q3490295) : pour toutes les communes => 10 000 habitants.

L'auteur de la donnée (P50) n'a pas été ajouté, car l'url permet d'identifier clairement l'auteur (l'Insee). Deux sources sont données :

  • L'url donnant la donnée de la commune en question (par exemple cet url pour L'Abergement-Clémenciat (d:Q204388))
  • l'url donnant le calendrier du recensement

Afin de faciliter la tâche, j'ai préparé les données pour l'année 2007. Vous pouvez les trouver à cette adresse.

Il suffit donc de, sauf erreur de ma part de :

  • Créer le qualificateur manquant,
  • Charger les données sur WD à partir du fichier joint.

Mais je ne suis pas un expert en WD, s'il y a un pb merci de m'en faire part. S'il n'y a pas de pb, je communiquerai ultérieurement les données pour 2006, 2008, 2009, 2010, 2011, 2012 et 2013. (Et bientôt celles de 2014 qui paraîtront le 1er janvier 2017).

Pour les modèles d'affichage ... on verra plus tard!! Cordialement.Roland45 (talk) 17:02, 15 October 2016 (UTC)

Merci, je pense que pas mal de dresseur de bots sauraient charger les données à partir de l'Excel. Pour les interpolations et extrapolations, on a mathematical interpolation (Q187631) et mathematical extrapolation (Q744069).
Le gros point de blocage jusqu'à maintenant c'est les questions de droit. La "licence ouverte" des administrations françaises n'est pas nécessairement compatible avec le CC0 de Wikidata (du coup on en arrive à une situation assez absurde, où on ça passe quand on siphonne de manière approximative mes données de l'INSEE à partir de Wikipedia plutôt que d'aller directement à la source). Si quelqu'un peut obtenir une autorisation écrite de l'INSEE pour utiliser leurs données, ça clarifierait bien les choses. -Zolo (talk) 12:55, 16 October 2016 (UTC)
La licence ouverte est compatible d'après Wikidata:Bot requests/Archive/2015/07#License faisant référence à fr:WP:Legifer/mars 2016#Changement de licence et c:Commons:Village pump/Copyright/Archive/2016/03#"Open License" and CC-0. Le problème est plutôt le manque de dresseurs de bot intéressés ou le manque de clarté de la description de la tâche. Oliv0 (talk) 15:00, 16 October 2016 (UTC)
La description de la tâche est assez simple : importer les données à partir du fichier Excel listant les populations pour une année donnée (2007 pour l'instant). Si on utilise mathematical interpolation (Q187631) et mathematical extrapolation (Q744069) comme qualificateurs manquants, il faudra que je modifie en conséquence le fichier, ce n'est pas un pb. Si cet import à partir d'Excel pose un pb, je peux le transformer en .txt avec un séparateur à définir entre chaque champ. Il y a peut-être par ailleurs un pb lorsque la donnée existe déjà, mais sans qualificateur et sans source ou avec une source mais non correcte. L'import devra pouvoir gérer ce genre de pb. Cordialement.Roland45 (talk) 17:27, 16 October 2016 (UTC)
Si on est clair sur la q° de droit ça va bien simplifier les choses mais user:Oliv0, je vois que la conversat° à laquelle tu lis a été close pour cause de licence incompatible. Donc même s'il n'y a aucun problème juridique, il y aura un travail de communication à faire (au moins si on veut passer par une demande de bot standard)
On manque de dresseurs de bot sur Wikidata, mais pour ce genre de chose, à partir du moment où on a le fichier Excel, je pense qu'on peut trouver. Je pense que mathematical interpolation (Q187631) et mathematical extrapolation (Q744069) sont ok (Après il y a peut une particularité technique des données démographiques que je n'ai pas vue et qui justifierait d'utiliser quelque chose d'autre) . Pour le passage en csv, je pense que le dresseur de bot saura le faire. --Zolo (talk) 19:40, 16 October 2016 (UTC)
@Roland45: Tu auras plus de succès avec les dresseurs de bot si tu arrives à réduire ton fichier excel au minimum. Rien de tel pour un opérateur externe au sujet que de devoir passer du temps à comprendre les données que tu lui donnes:
Il doit y avoir 3 groupes de colonnes:
* un groupe pour la déclaration proprement dite
* un groupe pour les qualificatifs
* un groupe pour la source
Pour la déclaration, une colonne avec le numéro INSEE, une colonne avec la valeur de la population, une pour l'incertitude et une pour l'unité.
Pour les qualificatif, une colonne pour l'année, une colonne pour la méthode. Je ne comprends pas l'utilité de la propriété P1013, mais bon.
Pour la source, il faut choisir si on veut utiliser la structure site Web avec toutes les données ou si on utilise un élément. Si on utilise le site web, il faut une colonne pour l'adresse URL, une colonne pour le nom du document de référence (en général, le titre du lien qui permet d'accéder au fichier et dans le cas extrême, même un fichier excel à un nom de fichier), une colonne pour la date de publication des données voire d'autres informations décrites sous Help:Sources/fr#Page_web. Il ne peut y avoir 2 URLs, à moins que les 2 URLs sont des documents différents qui donnent les mêmes valeurs. Snipre (talk) 19:55, 16 October 2016 (UTC)
Merci @Snipre:, @Zolo: et @Oliv0: pour ces éléments qui me font progresser dans la compréhension de Wikidata. Quelques éléments explicatifs ou de questionnement complémentaires :
Sur le groupe "déclaration" : es-tu sûr qu'il faille indiquer l'unité ("habitants") car sur aucune fiche WD de commune je ne vois cette information ? Concernant l'incertitude, il va falloir que je relise les méthodes de calcul, car ce n'est pas si simple. On voit quelquefois apparaître l'information sur WD +/- 1, mais je ne crois pas que ce soit si simple. Seuls les recensements réels sont exacts. L'idéal serait de ne pas donner la valeur de cette incertitude (d'autant qu'on n'aura jamais de source spécifique sur cette info).
Sur le groupe "qualificatifs" : la propriété P1013 me semble nécessaire. Il y a en effet trois types de populations en France depuis la réforme : municipale, comptée à part et totale. On affiche actuellement la population municipale, avant 2006 (à savoir jusqu'en 1999), c'était la population totale.
Sur le groupe "source" : Il faut bien comprendre que le fichier que j'ai mis en ligne n'est pas un fichier natif de l'Insee, mais un fichier composite créé par croisement du fichier de l'Insee des valeurs légales de populations de l'année 2007 et du calendrier de recensement donnant les années de recensements réels (autre fichier de l'Insee), ce qui permet de déterminer la nature de la donnée (réelle, estimation, sondage). En toute logique, il faut donc deux sources : celle donnant les valeurs de population et celle donnant le calendrier. Comment gérer ce problème ? Sinon, j'ai bien noté que le format de la source reprend les éléments du modèle "lien web" de WP.
Merci pour tes réponses. Cordialement.Roland45 (talk) 07:24, 17 October 2016 (UTC)
@Roland45:
Effectivement pour population (P1082) l'unité (habitant) est implicite et ne doit pas être indiquée. Pour l'incertitude, formellement il y a toujours une incertitude ; si la donnée est exacte, cela veut juste dire que l'incertitude est de 0 .
Pour les qualificatifs, effectivement la distinction entre les différentes populations est importante mais quelle est la propriété la plus adaptée ? criterion used (P1013) peut convenir mais est-ce que applies to part (P518) ne convient pas mieux ? Comment font les autres pays ? (avoir différents types de population n'est pas spécifique à la la France)
Pour les sources, pas de problèmes à indiquer plusieurs sources (au contraire) et le format « lien web » n'est pas une obligation (plutôt une facilité).
Cdlt, VIGNERON (talk) 08:12, 17 October 2016 (UTC)
Sur la question de la "précision", Wikidata reste je crois dans un grand flou (ça veut dire quoi exactement la "précision" de données obtenues par inférence statistique ?. Si l'INSEE donne un chiffre, mais ne donne pas de marge d'erreur, je pense qu'il faut mettre "précision +/- 0" pour dire que l'INSEE donnne des résultats précis à l'unité près. Ca ne veut pas forcécement dire que ce chiffre correspond exactement à la réalité. --Zolo (talk) 08:39, 17 October 2016 (UTC)
Les résultats précis à l'unité près ne sont que les recensements réels. Pour les estimations (interpolations ou extrapolations) le calcul se fait pas croisement du dénombrement du dernier recensement réel avec le nombre de résidences principales de l'année pour laquelle la population est estimée (issu du fichier des taxes d'habitation). Ainsi l'incertitude initiale porte sur le nombre d'habitants par résidence principale (qui est variable selon les régions et les zones d'habitation) (on ne tiendra pas compte de l'incertitude ... liée à ceux qui ne déclarent pas leurs impôts!!) et l'incertitude finale est proportionnelle au nombre de ces résidences principales (et donc au nombre d'habitants de la commune), mais aussi au nombre de décimales retenues pour faire les calculs de proportionnalités. Ainsi cette incertitude finale est-elle très variable et en tout cas très supérieure à 1. Il n’empêche, incertitude mathématique ou pas, la population légale est un nombre entier sans décimale et sans incertitude donnée par l'Insee. Donc autant ne pas préciser cet indicateur.Roland45 (talk) 09:33, 17 October 2016 (UTC)
On est obligé de mettre une précision, c'est prévu comme ça dans la structure des Wikidata. Lorsqu'on fait les modifs à la main et qu'on met un chiffre sans décimal, ça met "précision = 1". Si on ne sait pas la précision, le plus simple me parait de mettre "précision = 0". Si on a une idée de la précision, on peut aussi avoir quelque chose comme "population = 12 325, précision = +/-50" et afficher ça simplement comme "12 325" sur Wikipédia. --Zolo (talk) 10:26, 17 October 2016 (UTC)

Bon, j'ai modifié le fichier en conséquence. Le lien pour y accéder est toujours le même. Quelques précisions :
Concernant les sources : notez que l'url que j'indique pour chaque donnée renvoie vers la page htm spécifique de la commune sur le site de l'Insee et non vers un fichier global type Excel listant toutes les communes. Même si ce n'est pas le cas, j'aurais très bien pu reconstituer le fichier global avec un bot qui lirait toutes ces pages communales et récupèrerait l'info. Ainsi l'utilisation de cette info s'apparente, me semble-t-il, à la récupération de n'importe quelle information factuelle sur n'importe quel site.
Concernant la précision, j'ai retenu l'indicateur 1. Il s'agit en effet d'une population légale, officielle donc et intangible, authentifiée dans le mois de janvier de l'année qui suit la publication par un décret dans lequel aucune incertitude n'est donnée.
Merci de m'indiquer si la nouvelle forme du fichier convient. Un essai préalable sur quelques communes serait utile. Cordialement.Roland45 (talk) 14:39, 17 October 2016 (UTC)

@VIGNERON: C'est moi qui avais proposé la création criterion used (P1013), justement pour être utilisé pour les données démographiques (Wikidata:Property_proposal/Archive/16#P1013).
applies to part (P518) n'a pas ce sens là "part of the item for which the claim is valid". P518 aurait du sens pour désigner la partie de la commune prise en considération. Du genre : "population : 1082, s'applique à : partie insulaire". --Zolo (talk) 20:20, 17 October 2016 (UTC)
Merci Zolo, effectivement, vu comme cela c'est plutôt logique (je voyais le « population municipale » comme une partie de la population dans l'absolu mais finalement cela me semble moins évident). Cdlt, VIGNERON (talk) 15:14, 18 October 2016 (UTC)
@Roland45: Il est possible de trouver une formule de l'INSEE pour la précision des recensements. J'ai plus le lien mais j'avais trouvé un pdf que j'avais lié sur un projet par ici (commune de france ?) il y a pas mal de temps. author  TomT0m / talk page 18:06, 18 October 2016 (UTC)
Concernant la précision des données du recensement, les formules sont dans ce document. Comme je le disais cette précision est variable selon le nombre d'habitants. Il n’empêche que les données publiées sont des populations légales, sans précision donnée dans le décret authentifiant ces populations. La population française 2013 publiée le 31 décembre 2015 est de 65 564 756 habitants, sans ajout de texte du style ... "à + ou - 500 habitants", il s'agit d'un nombre exact. D'où ma position ci-dessus, à savoir de retenir l'indicateur "1". Cordialement.Roland45 (talk) 20:25, 18 October 2016 (UTC)
L'indicateur "1" n'est pas pertinent s'il s'agit d'un nombre exact, il faudrait préférer l'indicateur "0". Tout le monde sait pertinemment qu'il ne s'agit pas d'un nombre exact mais d'un chiffre officiel, par ailleurs, et Wikidata peut tout à fait stocker ce nombre précis tout en le nuançant par une précision. Actuellement l'interface ne fait rien du nombre précis que l'arrondir, mais ce n'est pas un problème conceptuel mais plus d'affichage de l'information connue. Par ailleurs le document sur la précision est tout à fait officiel : http://www.insee.fr/fr/ppp/bases-de-donnees/recensement/resultats/doc/pdf/fiche-precision.pdf et c'est clairement une information utile, je vois donc pas pourquoi on s'en priverait. Je vais ajouter une requête de nouvelle fonctionnalité dans le phabricator avec ce cas d'utilisation - chiffre précis publié mais dont la précision est connue histoire que ce soit officiel. (pour historique je l'avais utilisé pour rajouter la population de Paris, c'est là que je l'ai retrouvé). author  TomT0m / talk page 09:09, 19 October 2016 (UTC)
Tracked in Phabricator
Task T148617
.
Sur les licences, le texte de l'Insee est clair sur les droits, clairement compatibles avec la licence CC0 de Wikidata. A fortiori pour les populations légales, objet du présent import, qui sont des données publiques, publiées au JORF (voir le décret authentifiant les populations légales 2013 publié le 31 décembre 2015), donc correspondant à la licence CC0, me semble-t-il.Roland45 (talk) 06:58, 19 October 2016 (UTC)
Sinon, Le fichier peut-il sous cette forme être traité par un bot ?Roland45 (talk) 06:58, 19 October 2016 (UTC)
@Roland45 "La population française 2013 publiée le 31 décembre 2015 est de 65 564 756 habitants, sans ajout de texte du style ... "à + ou - 500 habitants",..." Il faut être cohérent avec les sources: soit tu utilises les documents de l'INSEE et donc il y a une incertitude donnée par l'INSEE (à calculer), soit tu utilises le décret official qui ne considère aucunement la réalité statistique des chiffres. Snipre (talk) 11:39, 19 October 2016 (UTC)
@Snipre, Tu n'as pas lu l'article 2 du décret : "Les chiffres de la population municipale et de la population totale des communes, des cantons et des arrondissements sont arrêtés aux valeurs figurant dans les tableaux consultables sur le site internet de l'Institut national de la statistique et des études économiques (www.insee.fr)." Ainsi les populations légales définies dans le décret sont bien celles publiées par l'Insee. En donnant comme source des url de l'insee, on est cohérent avec cet article 2. Mais par contre l'incertitude n'est elle pas sourcée ni sourcable d'ailleurs. Car si on lit le document en question sur les calculs d'incertitudes le tableau donnant les incertitudes par tranches de populations (variable de 1 à 8 %) est issu d'une étude sur les données du recensement principal de 2006 (la phrase est "Le tableau suivant montre la précision indicative obtenue pour différents effectifs d’une variable du RP2006 en commune de 10 000 habitants ou plus."). Rien ne dit que pour 2007 et a fortiori pour les dernières données de 2013 voire au-delà ces valeurs soient les mêmes. D'où l'intérêt de ne pas indiquer une valeur d'incertitude qui ne serait pas sourcée.Roland45 (talk) 12:45, 19 October 2016 (UTC)
Pour info. J'ai remplacé "1" par "0" dans le fichier en ce qui concerne l'incertitude de la donnée.Roland45 (talk) 15:44, 19 October 2016 (UTC)

Si j'ai bien compris, il s'agit d'importer la population d'une année. J'ai peur qu'importer toutes les années empêche de consulter les fiches des communes les plus longues. Pyb (talk) 08:54, 21 October 2016 (UTC)

C'est effectivement cela. Le fichier mis en ligne correspond aux données de populations de l'année 2007. Pour une commune normale, 42 valeurs annuelles au maximum devront être stockées (1793, 1800, 1806, 1821, 1831 etc jusqu'à 1999, puis une valeur annuelle à partir de 2006) (au maximum, car certaines communes n'ont pas de données pour certaines années). Cela risque certes d'allonger les fiches des communes. Mais n'est-ce pas le but de Wikidata : stocker des données. Si cela pose un pb, peut-être qu'un espace spécifique aux données de population peut être envisagé ou des sous-pages, mais je ne sais pas si l'architecture de WD le permet! Cordialement.Roland45 (talk) 13:10, 21 October 2016 (UTC)
@Pyb, Roland45: En effet, cela pourra poser un léger problème (qui ne va quand même pas nous empêcher de contribuer). Mais, comme Roland45, je pense qu'il ne faut pas hésiter à importer les valeurs, même si cela rallongera considérablement les pages. Il y aura sûrement une solution trouvée si cela pose vraiment un problème (boîte déroulante quand il y a beaucoup de valeur, par exemple). Tubezlob (🙋) 14:52, 22 October 2016 (UTC)

Doublons d'éléments sur les reliefs des astres sur Système solaire

Bonjour,

Hier, il existait deux éléments sur Wikidata pour un même relief sur Titan. Un bot italien a créé des éléments en complétant une partie des propriétés (il ajoute aussi le lien vers l'article de la Wikipédia en italien). C'est lui qui a créé ce doublon. J'ai fusionné ces deux éléments en un seul.

Plusieurs formations géologiques extraterrestres ont encore des doublons sur Wikidata. Je cherche à détecter. Y existe-t-il un moyen pour retrouver sur WD les éléments sur des formations planétaires qui ne possèdent pas de lien vers la WP en italien mais qui ont un synonyme qui en a un ? Merci d'avance. :) Feldo (talk) 13:52, 18 October 2016 (UTC)

Bonjour Feldo,
C'est une requête possible mais plutôt complexe et sans doute trop large pour être réalisable, cela risque de donner un timeout (« ne pointent pas vers la WP en italien » cela veut dire « n'a pas de lien ou a au moins un lien vers un des 800 projets autres que la WP italien » soit 95 % des éléments Wikidata et les requêtes sur les labels sont généralement trop dispendieuses). Plus restreint, voici déjà la liste des 7 114 éléments situés sur un corps astronomique et ayant un lien vers la WP en italien.
Une bonne idée pour repérer les doublons est d'utiliser le rapport de violation de contrainte de Gazetteer of Planetary Nomenclature ID (P2824) (qui par nature ne devrait être présent que sur un élément) : Wikidata:Database_reports/Constraint_violations/P2824 ; actuellement, il y a un seul faux-doublon donc soit cela veut dire qu'il n'y a effectivement pas de doublons (improbable), soit que l'un des deux éléments du doublon n'a pas la propriété Gazetteer of Planetary Nomenclature ID (P2824) (probable mais sans doute assez peu courant les membres du projet astronomie fait généralement attention à indiquer cette donnée pivot justement pour éviter ce genre de doublon). Une autre solution est peut-être tout simplement de regarder parmi Special:Contributions/ValterVBot (et plus précisément création à partir de début juin) et/ou de voir avec ValterVB.
Sinon, autre angle d'approche, j'ai regardé les éléments ayant located on astronomical body (P376) mais pas Gazetteer of Planetary Nomenclature ID (P2824) (252 résultats, qui sont pour la plupart à corriger d'une façon ou d'autre autre), j'y ai trouvé le doublon Hotei Arcus (Q114738) / Hotei Arcus (Q25907715) que j'ai fusionné.
Cdlt, VIGNERON (talk) 15:06, 18 October 2016 (UTC)
En procédant complètement différemment (en prenant les 8 426 résultats de la requête sur les labels en français - ou sinon en anglais - de tout les éléments ayant located on astronomical body (P376) puis en listant les doublons avec Libre Office Calc), j'obtiens les listes suivantes :
Bon courage pour faire le tri ;) En regardant rapidement, j'ai l'impression que ce sont surtout des faux-positifs (et étonnamment des redirections sont apparus dans la requête SPARQL, étrange...). Cdlt, VIGNERON (talk) 15:56, 18 October 2016 (UTC)
Désolé, je ne parle pas français, seulement italien ou en anglais :( mais si je peux aider, je le fais volontiers (google translate) --ValterVB (talk) 16:05, 18 October 2016 (UTC)
Hi ValterVB sorry for the French, to sum it up quickly : Feldo is saying that your bot created some duplicates of alien places (based on it.wp) and want a request to find them. Sadly, this is not trivial and I gave some leads to begin with. Cdlt, VIGNERON (talk) 16:19, 18 October 2016 (UTC)
@VIGNERON, ValterVB:
Français :
Pour information, les éléments originaux que j'ai corrigé sont utilisés depuis leur création pour des articles sur Titan (Q2565) et étaient pratiquement sans aucune propriété (ils n'avaient donc pas Gazetteer of Planetary Nomenclature ID (P2824)) bien que souvent liés à des articles des différentes Wikipédias. Je pense que c'est pour cela que le bot ne les a pas détecté. Peut-être est-il plus facile de détecter ces doublons en prenant en compte cela ?
English:
If it can helps, the original elements/queries I fixed were used since their debut for articles about Titan (Q2565) features and without pretty much any property (without Gazetteer of Planetary Nomenclature ID (P2824) then) while linked to various Wikipedia language versions. I think it's why the bot didn't notice them. Maybe it would make easier to detect these duplicates by using this knowledge? Feldo (talk) 16:46, 18 October 2016 (UTC)

copier-coller une propriété (et ses qualificatifs) d'un élément à un autre

Bonjour,
Il existe un gadget ou autre javascript/truc pour copier-coller une propriété et ses qualificatifs d'un élément à un autre ? Simon Villeneuve (talk) 15:09, 19 October 2016 (UTC)

j'aimerais bien, car quand je traite des poèmes extraits d'un recueil, je dois reprendre à la main toutes les infos de publication dans... idem pour les articles de la Revue des Deux mondes. :/ - merci de me notifier si la réponse est oui --Hsarrazin (talk) 10:15, 22 October 2016 (UTC)

Des éléments sans labels en français potentiellement intéressants

Cette requête liste des éléments qui n'ont pas de libellés en français. Il y en a plein, donc un filtrage peut s'avérer intéressant.

L'idée initiale c'était de faire un truc similaire à la catégorie de maintenance w:fr:Catégorie:Page_utilisant_des_données_de_Wikidata_à_traduire, qui donne les articles qui affichent des numéros Q sur frwiki, et de croiser avec petscan pour faire un compte pour prioriser ceux qui sont utilisés dans pleins d'articles. Finalement j'ai laissé tomber le croisement avec petscan pour l'instant et j'ai juste compté les déclarations des éléments qui ont un article en français qui contiennent un élément sans libellé donné.

Pour l'instant j'ai trouvé des éléments sur les systèmes autoroutiers des états des USA et des types d'organes des champignons. Ça donne ça : 

select (count(?item) as ?num)  ?val  where {
  select ?item ?val {    
    ?article schema:about ?item .
    ?article schema:inLanguage "fr" .
	
    ?item ?prop ?val filter not exists { 
      ?val rdfs:label ?label filter (lang(?label) = "fr") .
    }    
    ?mprop a wikibase:Property .
    ?mprop wikibase:propertyType wikibase:WikibaseItem .
    ?mprop !(wikibase:novalue|wikibase:reference|wikibase:claim) ?prop . 


  } limit 2400 

} group by ?val having (?num>4) limit 25
Try it!
Merci TomT0m ! Ce genre de requête est toujours utile ; par contre, on avait pas déjà quelque chose de similaire quelque part ? Et sinon, où signaler les traductions compliques ? Je pense notamment à batter (Q29493) qui est très diversement traduit en français selon le contexte (de « panure » à « pâte » en passant par « préparation » ou « appareil »...). Cdlt, VIGNERON (talk) 12:29, 22 October 2016 (UTC)

Items en double

Bonjour à tous,

Il y a un problème de doublon sur deux items concernant la Norvège médiévale indépendante avant l'Union de Kalmar : Q2196956 (Hereditary Kingdom of Norway) et Q2269971 (Norwegian Empire during the Middle Ages).

Cependant, ce n'est pas très simple à résoudre car :

  • il y a deux articles de Wikipédia en anglais, mais Hereditary Kingdom of Norway correspond au régime monarchie en Norvège et non au royaume de Norvège du Moyen-Âge
  • ils ont chacun des catégories différentes

Il y a aussi l'élément Q1576537 Empire colonial norvégien à considérer.

En espérant être assez clair dans mes explications (n'hésitez pas à me demander de ré-expliquer un peu mieux), que pensez-vous qu'il faut faire ?

--Mywiz (talk) 14:58, 20 October 2016 (UTC)

@Mywiz: Mmm je trouve plutôt Kingdom of Norway (Q22969571)  View with Reasonator View with SQID plutôt que Q2269971  View with Reasonator View with SQID qui n'a rien à voir, et le titre de l'article en anglais est w:en:Norwegian expansion during the Middle Ages - mais le RI mentionne Hereditary Kingdom of Norway et donc pourrait être un simple doublon de w:en:Hereditary Kingdom of Norway ... Par ailleurs, il y a un bandeau TI sur le premier, donc j'envisagerai de proposer une fusion quelque part sur enwiki - si tu veux pas le faire je le ferai. Sinon on peut considérer un truc comme
⟨ Kingdom of Norway (Q22969571)  View with Reasonator View with SQID ⟩ part of (P361) View with SQID ⟨ Q2269971  View with Reasonator View with SQID ⟩
,
⟨ Kingdom of Norway (Q22969571)  View with Reasonator View with SQID ⟩ facet of (P1269) View with SQID ⟨ Q2269971  View with Reasonator View with SQID ⟩
ou
⟨ Kingdom of Norway (Q22969571)  View with Reasonator View with SQID ⟩ part of (P361) View with SQID ⟨ histoire du royaume héréditaire de Norvège ⟩
. author  TomT0m / talk page 17:18, 20 October 2016 (UTC)
@TomT0m: : pour l'erreur sur Pas de libellé défini, c'est une erreur de ma part quand j'ai copié le numéro, celui qui tu as retrouvé est le bon. Ensuite, je pense qu'il faudrait en quelque sorte fusionner Kingdom of Norway (Q2196956)  View with Reasonator View with SQID et Kingdom of Norway (Q22969571)  View with Reasonator View with SQID, mais que l'article anglais Hereditary Kingdom of Norway en soit "exclu" car il correspond à un article général sur la politique historique de la Norvège et non seulement le royaume médiéval. --Mywiz (talk) 17:32, 20 October 2016 (UTC)
✓ Done J'ai corrigé ce problème en fusionnant les éléments. --Mywiz (talk) 09:08, 21 October 2016 (UTC)
@Mywiz: Euh, tu as fais ça sans consulter un minimum en dehors d'ici et en laissant un article orphelin sans élément ? On peut pas vraiment dire que ce soit une solution ... author  TomT0m / talk page 09:11, 22 October 2016 (UTC)
✓ Done J'ai créé un élément Hereditary Kingdom of Norway (Q27502010) contenant un lien vers w:en:Hereditary Kingdom of Norway, relié à politics of Norway (Q1153694) par la propriété history of topic (P2184) --Mywiz (talk) 09:27, 22 October 2016 (UTC)

Barre de recherche

Bonjour, lorsque je fais une recherche d'un élément depuis la barre de recherche qui se trouve en haut à droite, la page de résultat me renvoie uniquement vers des résultats sur les propriétés (exemple avec ce que j'obtiens lorsque je cherche « un test »). Or, je voudrais qu'il recherche par défaut dans les éléments. Y a-t-il un réglage pour cela quelque part ? Pamputt (talk) 08:04, 22 October 2016 (UTC)

@Pamputt: Il y a des options dans Special:Search pour choisir de chercher par défaut dans certains espace de nom, et une case à cocher en bas de ces options pour qu'il se souvienne de ces choix pour les recherches subséquentes (cela dit perso je me sers très rarement de la page de recherche, surtout depuis qu'on peut glisser/déplacer directement depuis les suggestions parce que les URLs sont prises en charge par les éléments de l'interface.) author  TomT0m / talk page 09:15, 22 October 2016 (UTC)
@TomT0m: ah oui en effet, c'est là que ça se règle. Par contre, je n'ai pas compris la deuxième partie de ton message. C'est quoi ce glisser/déplacer ? Pamputt (talk) 09:18, 22 October 2016 (UTC)
@Pamputt: Un exemple sera peut être parlant : si je veux chercher un élément et l'insérer dans cette discussion, je vais dans la barre de recherche en haut à droite, mais généralement je ne valide pas. Je vien de taper "plop" et dans la liste des choix qui s'affiche, je clique sur le deuxième et je le déplace dans la zone de texte. L'url https://www.wikidata.org/wiki/Q1983241 s'affiche. Il se trouve que des modèles comme {{Q'}} peuvent directement utiliser cette url donc si je tape {{Q'| puis je fais glisser le résultat puis }} j'obtiens Plop (Q1983241)  View with Reasonator View with SQID ce qui est assez pratique dans une discussion. Depuis peu si on fait pareil avec un copier/coller - ou un glisser/déplacer mais ça a moins d'intérêt - quand on rentre une déclaration, ça marchera aussi, et c'est pas mal pratique. Du coup on peut aussi copier/coller directement les urls des pages wiki des éléments. author  TomT0m / talk page 09:31, 22 October 2016 (UTC)
ça, c'est un truc génial ! merci TomT0m ! --Hsarrazin (talk) 10:18, 22 October 2016 (UTC)

Prêtre : Occupation (Q12737077), Fonction (P39) ou bien encore Profession (Q28640) ?

Bonjour, je suis en train de renseigner plusieurs pages Wikidata de prêtres (catholiques), entre autres. Quelle est la bonne déclaration ? J'ai tendance à mettre occupation systématiquement car c'est la proposition automatique que me fait le système. Or, dans la description de "fonction" on mentionne bien "fonction occupée (politique, ecclésiastique, etc.)". Que faire ? Jusqu'à présent pour les pages de prêtres on trouve un peu de tout...--Gwendal (talk) 09:44, 25 October 2016 (UTC)

Salud dit Gwendal,
En préambule, il ne faut pas toujours faire confiance aux propositions automatiques du système (elles ne sont pas toujours logiques, hier j'ai eu sex or gender (P21) proposé pour une rivière !).
Pour les personnes ayant une fonction ou une dignité ecclésiastique, c'est généralement position held (P39) qui faut utiliser mais effectivement pour Catholic priest (Q250867) c'est occupation (P106) qui est est le plus courant (15 184 utilisations contre 13 seulement pour position held (P39)). Il y a sans doute eu des discussions à ce sujet mais je n'arrive pas à en retrouver de spécifique à la prêtrise...
Cdlt, VIGNERON (talk) 10:53, 25 October 2016 (UTC)
Fonction de ce que j'en comprend ce serait plutôt des trucs genre "évêque de Paris" ou prêtre du diocèse de jesaispkoi vu que c'est supposé relier à un siège précis genre "président de la RF" - plutôt que "président" qui ne lie pas à un poste particulier. author  TomT0m / talk page 12:27, 25 October 2016 (UTC)
Un peu difficile de caser prêtre. Ma proposition est de mettre profession: ecclésiastique pour tous les religieux, en passant du moine au pape via prêtre et évêque. Le problem est d'ensuite de considérer si Fonction peut server à distinguer entre les différents rangs. Une fonction est par définition un titre ou une responsabilité qui est lié à un poste alors que le titre de prêtre, évêque ou pape est independent de la position ou du poste de la personne. Donc occupation semble plus apte à régler ce problem. Snipre (talk) 14:20, 25 October 2016 (UTC)
TomT0m point de vue intéressant, je ne l'aurais pas du tout expliqué comme cela mais c'est plus ou moins ainsi que je voyais les choses (P106 pour les généralités et P39 pour des spécificités).
Snipre Euh... l'idée est assez confusément expliquée mais je pense être globalement d'accord avec quelques précisions/reformulations. Prêtre n'est pas un titre ni une fonction (les curés, les papes, les évêques, etc. sont des prêtres et tout prêtre à forcément une fonction même si elle est parfois plus de façade comme les fameux sièges titulaires) et n'engage à aucune responsabilité spécifique, c'est bien un métier et c'est déjà un terme très général et synonyme de « clerc », « membre du clergé » ou « ecclésiastique ». Typiquement, pour les prêtres dont parle Gwendal, on pourrait effectivement mettre occupation (P106) prêtre et position held (P39) recteur.
Après, il ne s'agit pas de tout bouleversé (surtout si la situation résulte d'une longue mûre réflexion comme le semble indiqué le ratio P106/P39, avant tout changement il faudrait retrouver lesdites discussions).
A gln, VIGNERON (talk) 16:03, 25 October 2016 (UTC)
Ah, effectivement, ce sont des propriétés ! Mon titre de sujet n'est donc pas exact. Merci pour vos réponses, je pense que ce qui est proposé par VIGNERON est cohérent et reflète bien l'usage actuel. J'ai eu beau chercher une discussion sur ce sujet, je n'ai rien trouvé non plus.--Gwendal (talk) 16:50, 25 October 2016 (UTC)

Sigurd Nilsson (Q1984417)

Bonjour, merci de retirer l'année de naissance de 1938 : il participe aux championnats du monde lors de cette année. Merci d'avance. 195.212.29.174 10:16, 25 October 2016 (UTC)

Effectivement, Jura1 a visiblement confondu la date de naissance et le floruit... Cdlt, VIGNERON (talk) 11:01, 25 October 2016 (UTC)

Création d'une propriété

Bonjour. Dans les pages concernant les unités militaires (ex : Q711955, Q4630673), j'aimerais pouvoir indiquer la liste des commandants de l'unité, mais cette propriété ne semble pas exister (il existe Property:P598 commandement, qui permet d'indiquer la liste d'unités qu'un militaire a commandé, mais c'est la réciproque qu'il me faut). J'ai un peu regardé cette page Wikidata:Property proposal/Generic, mais je ne comprends pas grand chose. Si un généreux contributeur veut prendre le temps de le faire ou de m'expliquer comment le faire, je l'en remercie d'avance . Cdlt. --Julien1978 (d.) 10:47, 25 October 2016 (UTC)

Pourquoi as-tu besoin de cette propriété ? Y a-t-il un seul cas où commander of (DEPRECATED) (P598) ne suffise pas et qu'il faille impérativement stocker l'information deux fois ? --Harmonia Amanda (talk) 10:52, 25 October 2016 (UTC)
Pour chaque élément wikidata concernant une unité militaire. Il n'est actuellement pas possible d'indiquer la liste des commandants sur les éléments d'une unité militaire (pour être plus précis commander of (DEPRECATED) (P598) n'est utilisable (n'a de sens) que sur des éléments concernant des personnes, d'où la nécessité d'un réciproque à pouvoir mettre sur les éléments concernant les unités). --Julien1978 (d.) 11:00, 25 October 2016 (UTC)
La question d'Harmonia est pourquoi une propriété réciproque est-elle nécessaire ? La vaste majorité des propriétés n'a pas de propriétés réciproques (et c'est globalement bien mieux ainsi). Cdlt, VIGNERON (talk) 11:02, 25 October 2016 (UTC)
Je voulais dire que si l'information est déjà présente sur les éléments de personnes, pourquoi aurions-nous besoin de stocker aussi l'information sur les éléments d'unités ? Par exemple, la liste des rôles d'une actrice n'est pas présente sur l'élément de l'actrice, elle est requêtée à partir de tous les éléments qui ont distribution:cette actrice. Je ne vois pas en quoi il y a besoin de dédoubler pour le commandement militaire. --Harmonia Amanda (talk) 11:06, 25 October 2016 (UTC)
Il est plutôt pertinent de faire générer cette liste par une requête, genre mais là ça marche pas, si quelqu'un sait ce qui coince ne pas hésiter :
select ?chefLabel ?proprLabel where {
  ?chef ?prop wd:Q2817847 .
  ?chef wdt:P31/wdt:P279* wd:Q5 .
  ?propr wikibase:directClaim ?prop .
  
  SERVICE wikibase:label {
   bd:serviceParam wikibase:language "fr" .
  }
}
Try it!
Avec listeria ça donnerait un truc comme ça :

This list is periodically updated by a bot. Manual changes to the list will be removed on the next update!

WDQS | PetScan | TABernacle | Find images | Recent changes | Query: select ?chef ?propr where { ?chef ?prop wd:Q2817847 . ?chef wdt:P31/wdt:P279* wd:Q5 . ?propr wikibase:directClaim ?prop }
label
Hyacinthe de Quatrebarbes
Henri de Vernejoul
End of automatically generated list.
Cette propriété pourrait également servir sur les éléments concernant les batailles (et sans-doute sur d'autres) qui pour ce que j'ai pu constater n'indiquent pas les commandants (chefs) militaires. Sinon,
  • Il n'est peut-être pas utile de dédoubler quand l’information existe sur un élément qui existe, mais les éléments sur les commandants n'existent pas toujours  ; s'ils existent, l’information elle n'est pas forcement présente ou parcellaire ; et comme cela peut aussi dépendre de la manière dont on appréhende et saisi les éléments. Actuellement je crée des articles sur les unités sur Wkipédia, et donc je remplis manuellement l'élément correspondant sur wikidata. Je trouverais bcp plus simple de pouvoir saisir l'information depuis l'élément de l'unité (un peu à l'image du gadget pour saisir les infos sur wikidata concernant les biographies directement depuis frwikipédia, mais qui n'existe pas pour ce type d'élément). Il est quand même plus facile de pouvoir faire une saisie centralisée sur un élément que de devoir rechercher d'autres éventuels éléments et de devoir multiplier les saisies sur plusieurs éléments différents (ce n'est pas pratique et cela oblige en plus à multiplier les vérifications).
  • Dans la même logique, on a des propriétés qui permettent de préciser quelles sont les unités subordonnées qui composent l'unité considérée et de quelle unité supérieur fait partie l'unité considérée. Une même information semble donc pouvoir être référencées de manière réciproque sur plusieurs éléments.
  • Comment puis-je faire pour indiquer sur 7th Area Army (Q711955) par exemple le (ou les) nom de son commandant ? Et admettons que l'information soit présente sur l'élément d'un militaire, comment puis je faire pour répercuter l'information sur l'élément de l'unité ? Je viens par exemple d'indiquer sur Kenji Doihara (Q74296) qu'il est commandant de 7th Area Army (Q711955) via commander of (DEPRECATED) (P598), mais cette information n'apparait pas sur 7th Area Army (Q711955). Pour celui qui découvre/veut utiliser/ne considère que l'élément de l'unité, il ne peut savoir quels sont les commandants de l'unité, ni deviner que l'information est bien présente, mais sur un autre élément ; de ce point de vue, il me semble qu'il y a manque.
  • Toujours avec l'article Kenji Doihara sur wikipédia, ce dernier dispose du modèle Infobox Biographie2 donc sur ce dernier, 7th Area Army (Q711955) apparait bien, mais admettons que l'on crée un modèle similaire pour les unités, si Kenji Doihara (Q74296) n'est pas présent sur l'élément 7th Area Army (Q711955), pourra-t-il être appelé et présent sur l'article concernant les unités disposant d'un tel modèle alors qu'il n'est pas présent sur l'élément wikidata correspondant à l'unité ?
  • Ne pourrait-on pas disposer des deux propriétés en les liant, de manière à ce que si l'information est indiquée via commander of (DEPRECATED) (P598) sur un élément biographique, elle soit automatiquement transcluse sur l'élément de l'unité concernée, et vice-versa si l'on crée la seconde propriété ? Ce qui faciliterai énormément le travail en terme de saisie et surtout en récupérant des informations depuis un autre élément non encore présent sur le premier élément considéré et qui donc peut très bien être ignoré/inconnue de la personne qui saisit ou s’intéresse à l'élément? Cette automatisation de saisie entre propriété réciproque ou liée, ne pourrait elle pas être intéressante pour de nombreux éléments en dehors de ma demande spécifique ?
Cdlt. --Julien1978 (d.) 13:31, 25 October 2016 (UTC)
PS: Je viens de voir le dernier complément de réponse en publiant, mais je dois m’absenter sans avoir eu le temps de le comprendre. Je vous demande de m’excuser s'il répond déjà à une partie de mes questions ; je suis de retour dans la soirée. --Julien1978 (d.) 13:31, 25 October 2016 (UTC)
Alors rapidement :
  • pour les batailles on utilise généralement P:participant.
  • Il n'est jamais utile de dédoubler une information parfaitement symétrique, cela ne peut faire que générer des erreurs. Si l'élément du commandant n'existe pas, tu ne pourras de toute façon pas le lier à partir de l'unité, le problème est strictement le même. Je ne sais pas comment tu travailles tes ajouts de déclaration, mais il n'est absolument pas plus compliqué d'entrer les informations sur les éléments des commandants, à moins que tu ne fasses tout strictement à la main, ce que je n'espère pas.
  • Il y a des informations qui sont dédoublées, oui, quand elles ne sont pas strictement symétriques. Par exemple quelqu'un peut avoir "enfant:valeur aucun" donc les propriétés "père" et "mère" ne suffisent pas, il y a aussi besoin de "p:enfant". La question ici est : y a-t-il un tel besoin ? pour l'instant tu ne le montres pas.
  • le nom du commandant n'apparaît pas directement sur 7th Area Army (Q711955) en lecture de base. Il est présent dans les pages liées, dans les outils de visualisation comme Reasonator, requêtable, etc. Wikidata n'est pas faite pour être lue telle quelle, elle est faite pour être éditable. Pour la lire ou la question, on passe par des outils de visualisation et de requêtes. Qui indiquent sans aucune difficulté le nom du commandant actuellement.
  • oui il est possible d'appeler des éléments qui ne sont pas directement dans l'élément lié, c'est l'Arbitrary:Access.
  • Non. On a des propriétés réciproques mais aucune d'entre elle ne remplit l'autre de façon automatique, justement parce qu'on ne les utilise que lorsqu'elles ne sont pas strictement symétriques.
--Harmonia Amanda (talk) 13:45, 25 October 2016 (UTC)
Ma méthodologie est très basique. Je crée un article sur wikipédia, je le lie à son élément si l'article existe dans une autre langue ou je le crée s'il n'existe pas. Puis je rentre les infos dans l'élément une par une en regardant sur d'autres éléments similaires quelles sont les propriétés utilisables et intéressantes ; je ne sais pas faire autrement malheureusement. En tout cas merci beaucoup d'avoir pris le temps de me répondre, je pense avoir un peu mieux compris (les différents éléments ne sont pas vraiment indépendants, toute la base wikidata est plus ou moins liée comme un grand tout ? Alors que mon approche se fait élément par élément à l'image de ma manière de travailler sur Wikipédia.) . Cdlt. --Julien1978 (d.) 18:44, 25 October 2016 (UTC)
Oui, c'est exactement ça, les éléments sont conçus comme reliés ensemble. C'est d'ailleurs notre principal critère d'admissibilité : c'est admissible si un autre élément en a besoin pour être lui-même complet. Par exemple, pour compléter la filmagraphie d'un acteur connu, j'ai dû créer un élément sur un film très peu connu, et créer également l'élément du réalisateur dudit film. C'est une façon basique mais assez claire de voir les choses oui, de se rappeler que Wikidata fait sens par les liens qui unissent les entrées les unes aux autres, aussi bien sortants que entrants. --Harmonia Amanda (talk) 13:20, 28 October 2016 (UTC)

Vers un Wikibiblio ?

Bonjour,

J'ai eu un échange sur facebook. Il semble que des projets sont en cours :

  • le lancement de Wikicite en avril prochain
  • le développement de plusieurs projets d'extraction automatisé d'information comme Strephit (qui implique d'avoir un système de gestion bibliographique costaud)

Cela pourraient tendre vers un Wikibiblio ? Pouvez-vous m'en dire plus ? Bel bonjour, --Ambre Troizat (talk) 19:37, 26 October 2016 (UTC)

Wikicite évolue principalement hors des structures habituelles de WD: Wikicite dispose de ses propres conférences, de sa propre mailing list,... Bref, il existe des outils, mais ils sont souvent développés pour des langages spécifiques et pour des applications particulières. Le principal problème, c'est que WD n'a pas encore formalisé une structure définitive et suffisamment général pour les différents types de documents et les relations entre ces documents. Tant que cela n'est pas fait, les annonces externes n'engagent que ceux qui les font. Snipre (talk) 19:53, 26 October 2016 (UTC)
Merci, Snipre.
Une première édition de WikiCite a déjà eue lieux il me semble. Compte rendu : https://commons.wikimedia.org/wiki/File:WikiCite_2016_report.pdf (lien trouvé en traduisant la lettre Wikidata hebdomadaire sur fr:Projet:Wikidata pour ceux qui voudraient suivre l'actu WD). Sinon il y a un projet WikiProject Source Metadata et un projet WikiProject Books sur Wikidata. author  TomT0m / talk page 17:05, 28 October 2016 (UTC)

Question idiote...

Hello, j'aimerais pouvoir rajouter une déclaration au sujet d'une biographie (un lieu de décès...), ben euh.. je ne sais même pas comment on fait, ahem, help svp. Nonopoly (talk) 11:50, 28 October 2016 (UTC)

@Nonopoly: Bonjour, je te conseille de faire cette visite guidée interactive, ça ne dure que quelques minutes et on y apprend comment ajouter des déclarations.
Dans ton cas, c'est place of death (P20).
Tubezlob (🙋) 12:03, 28 October 2016 (UTC)
ahem... ok, quand j'y penserai... mais il n'y a pas d'onglet modifier sur les pages, d'où ma circonspection.. bref, faut que je me plonge dans le truc... (diantre....) Nonopoly (talk) 12:05, 28 October 2016 (UTC)
@Nonopoly: Dans ton cas, il faut cliquer sur « + ajouter » (après les déclarations déjà ajoutées), puis taper dans le champ « propriété » qui s'est ouvert « date de décès », cliquer sur la bonne proposition, puis ajouter dans le champ en face le nom du lieu en cliquant sur la bonne proposition.
Est-ce que c'est clair comme ça ?
Tubezlob (🙋) 12:21, 28 October 2016 (UTC)
c'est magique ! c'est ce que je cherchais sans trouver... mille mercis...(en l'occurrence, c'était le lieu, mais c'est pareil)... !!! Nonopoly (talk) 12:30, 28 October 2016 (UTC)
@Nonopoly: De rien ! Excuse-moi, j'ai confondu les deux en cours de route… Tubezlob (🙋) 12:35, 28 October 2016 (UTC)

CBC Television

Salut. J'ai remarqué lors de mon passage sur l'article francophone du diffuseur public canadien "CBC Television" que l'article n'avait aucun lien inter-wiki. Hé bien voilà, dans l'historique sur wikidata (Q1022955), ce certain utilisateur Solomon203 a flushé tous les liens, "libellés", et "descriptions" pour rattacher l'article anglophone du diffuseur canadien avec un article du wiki japonais sur une société du Japon sans aucun lien. Je ne sais pas trop comment m'y prendre pour rétablir le tout, mais c'est clair qu'un contributeur s'est donné du mal à vandaliser le tout alors qu'il aurait pu créer une nouvelle entrée pour la société japonaise. InMontreal (talk) 01:45, 29 October 2016 (UTC)

@InMontreal: C'est réverté à la version pré télé japonaise. --Fralambert (talk) 04:31, 29 October 2016 (UTC)
@InMontreal: La procédure pour annuler une fusion est sur Help:Merge (à dé-fusionner). author  TomT0m / talk page 09:05, 29 October 2016 (UTC)

"Deviné par le module carte "

Bonjour,

Des cartes et des modèles de géoloc sont en ce moment créé sur Wikipédia, et je suis en train de mettre à jour les articles pour qu'ils incluent les nouvelles cartes. Et je suis tombé sur cet article qui utilise cette infobox (qui récupère les info ici). Là on m'indique que la géolocalisation est "deviné par Module:Carte". Pour faire simple, comment dois-je faire pour que l'infobox aille chercher ce qui est dans cet élément (et dans d'autres, sachant qu'à court terme, toutes les préfectures japonaises devraient avoir un modèle de géoloc dédié).

J'ai par ailleurs demandé une infobox qui utilise Wikidata, et qui va aussi avoir besoin de chercher automatiquement le(s) modèle(s) de géoloc le(s) plus approprié(s). Le même problème risque donc là aussi de ce poser.

Cdlt, XIIIfromTOKYO (talk) 09:13, 30 October 2016 (UTC)

En effet dans fr:Module:Infobox/Espace vert la valeur par défaut du paramètre |géolocalisation= de ce geoloc de fr:Module:Infobox/Fonctions/Géolocalisation est devinée par guessmaps de fr:Module:Carte, c'est-à-dire comme je disais ici par des données stockées sur Wikipédia et pas sur Wikidata. Donc si tu veux utiliser Wikidata dans ce geoloc ce qui est certainement mieux, l'endroit où demander est par exemple fr:Discussion module:Infobox (normalement ce devrait être fr:Discussion Projet:Wikidata mais il faudrait d'abord transformer son archivage en quelque chose comme algo=checked+old de fr:Projet:Modèle/Demandes). Oliv0 (talk) 09:48, 30 October 2016 (UTC)
@XIIIfromTOKYO: ✓ Done, en tout cas pour Hiroshima Prefecture (Q617375). Pour les autres, tu auras deux choses simples à faire. D'abord, créer pour chaque préfecture une page comme Module:Carte/données/préfecture de hiroshima, que je viens de créer en recopiant servilement les paramètres déjà renseignés dans Modèle:Géolocalisation/Préfecture de Hiroshima, mais en prenant soin de changer l'identifiant en Q de l'élément cible pour celui de la préfecture concernée dans le champ wikidata =. Ensuite il faut ajouter pour chaque préfecture une ligne dans Module:Carte/données comme je l'ai fait là. Shukkei-en affiche bien, désormais, la carte de la préfecture préférentiellement à celle du Japon tout entier. Thierry Caro (talk) 09:02, 31 October 2016 (UTC)
@Thierry Caro: ok, j'ai testé sur la préfecture de Fukuoka, et ça a l'air de fonctionner. En tout cas, ça s'affiche sans problème sur Dazaifu Tenman-gū avec une infobox "sanctuaire religieux". Cdlt, --XIIIfromTOKYO (talk) 11:17, 31 October 2016 (UTC)
@Thierry Caro: Première grosse erreur avec Kōzan-ji : ce n'est ni la bonne préfecture... ni le bon pays qui s'affiche dans l'infobox. XIIIfromTOKYO (talk) 13:34, 31 October 2016 (UTC)
Vieux problème de la géolocalisation Wikidata, courant pour les régions qui ont des péninsules ou panhandles. Dans ce cas, on met en dur dans l'article géolocalisation=préfecture de Yamaguchi/Japon. Thierry Caro (talk) 13:38, 31 October 2016 (UTC)
Oui c'est ce que je dis juste au-dessus, actuellement dans les infobox ce n'est pas une géolocalisation (avec choix de carte selon données stockées sur) Wikidata mais Wikipédia. Pour que les données Wikidata du genre located in the administrative territorial entity (P131) soient utilisées pour ça sur Wikipédia, il faut demander sur Wikipédia (aux bons codeurs en Lua car ça ne va pas être très simple). Oliv0 (talk) 17:26, 31 October 2016 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Bistro/Archive/2016/10&oldid=2029381855"