Wikidata

Wikidata:Bistro/Archive/2016/08

< Wikidata:Bistro‎ | Archive
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Lieu de naissance d'André Goustat

Bonjour. Je reprends ici ce que je viens d'écrire sur la page de discussion de l'article André Goustat sur Wikipédia en français.

Suite au décès d'André Goustat (Q2847867), sa fiche Wikidata a été mise à jour notamment au niveau de son lieu de naissance : Badefols-sur-Dordogne, d'après l'article de Sud Ouest qui lui est consacré, ce qui entraine l'apparition de cette information dans l'infobox de l'article sur Wikipédia.

Or, jusqu'à présent, l'article indiquait une naissance en 1935 à Mauzac, information notamment relatée dans le Dictionnaire biographique du Périgord de l'historien local Guy Penaud (Q3122065) (Guy Penaud, Dictionnaire biographique du Périgord, Éditions Fanlac, 1999, ISBN 2-86577-214-4, p. 455).

Devant ce problème, j'ai téléphoné à la mairie de Mauzac-et-Grand-Castang (commune actuelle, dont M. Goustat fut maire de 1973 à 2007), où une femme m'a répondu qu'ayant vu à plusieurs reprises l'acte de naissance de M. Goustat, elle était certaine de sa naissance à Mauzac-et-Saint-Meyme-de-Rozens (nom de la commune avant 1973, où M. Goustat fut maire en 1971-1972).

Est-ce que cela suffit pour rectifier le lieu de naissance sur Wikidata ? --Père Igor (talk) 16:24, 29 July 2016 (UTC)

Sur Wikidata, quand plusieurs sources donnent des informations contradictoires, on ne "rectifie" pas une déclaration, on en rajoute une avec chaque source (pour un acte de naissance, il faut créer un nouvel élément pour ce document je pense). La "bonne" source est à indiquer par un rang particulier, le rang privilégié, et les sources erronées, si il est prouvé qu'elles sont erronées, sont à indiquer comme obsolètes. Après si polémique il y a on pourra réexaminer le cas. author  TomT0m / talk page 17:03, 29 July 2016 (UTC)
@TomT0m: bonjour. J'ai donc ajouté Mauzac-et-Saint-Meyme-de-Rozens comme autre lieu de naissance, mais le système ne m'autorise pas à entrer la source (Guy Penaud, Dictionnaire biographique du Périgord, Éditions Fanlac, 1999, ISBN 2-86577-214-4, p. 455), car le bouton enregistrer n'existe pas dans ce cas. Est-ce que tu sais faire ? Père Igor (talk) 09:18, 30 July 2016 (UTC)
@Père Igor: Oui. Sur Wikidata, les données ne sont pas du texte formaté. Le dictionnaire biographique du périgord doit avoir un élément, qui s'avère déjà exister : Q25080222     . Les références sont de la même nature que les qualificateurs, des paires "propriété/valeur". Tu dois choisir une propriété, pour citer cet ouvrage la propriété idoine est "affirmé dans", puis tu pourras entrer les premières lettres de Dictionnaire biographique du Périgord. Il est inutile de rentrer le nom de l'auteur, l'éditeur etc. vu que ces informations sont déjà entrées via l'élément. Il ne te reste alors qu'à rajouter la page grace à la propriété "page" de la même manière que tu as ajouté "affirmé dans". author  TomT0m / talk page 11:08, 30 July 2016 (UTC)
@TomT0m: merci pour le conseil et la mise à jour. --Père Igor (talk) 09:29, 31 July 2016 (UTC)
@Père Igor: j'ai ajouté le rang privilégié, pour que l'infobox récupère uniquement la « bonne » valeur. Sinon, sur le fond, vu que les deux communes citées sont limitrophes et qu'il y a eu pas mal de modifications territorio-administratives dans le coin (je vois aussi que la commune limitrophe de Drayaux a fusionné avec Lalinde), est-ce que lieu où André Goustat est né ne serait pas passé d'une commune à une autre entre 1935 et 1973 ? (improbable mais sait-on jamais) Il faudrait peut-être aussi contacter Sud-Ouest pour savoir d'où vient leur information. Cdlt, VIGNERON (talk) 09:01, 1 August 2016 (UTC)

ALERTE ROUGE : Longueur dix fois moindre

Bonjour. Dans l'incapacité où je suis d'écrire sur la page de discussion de Xmlizer, je viens lui signaler ici que la longueur d'un cours d'eau de 41,4 km ne veut pas dire 414 km : voir Glane (affluent de la Vienne) (Q20677716), un des rares éléments de Wikidata que j'ai en suivi. Ce genre d'erreur, répété souvent, peut facilement désorganiser le savoir. Attention donc. --Père Igor (talk) 10:05, 30 July 2016 (UTC)

Alerte ! Le problème est bien plus grave. Idem avec Lorze (Q670886), entré à 307 km au lieu de 30,7 km. Comme Xmlizer est capable de mettre à jour chaque minute de 10 à 30 éléments, je suppose qu'il s'agit d'un bot. Merci à celui qui pourra l'arrêter, en attendant une vérification sérieuse de ses autres mises à jour. C'est du vandalisme ou de l'inconscience ? --Père Igor (talk) 10:15, 30 July 2016 (UTC)
C'est un problème dans un script je pense. J'ai laissé un message au contributeur. --Zolo (talk) 10:04, 31 July 2016 (UTC)
J'aurais du réagir quand j'ai vu que la longueur du torrent Baye de Montreux était de 998 km sur Wikidata [1] mais de 9,98 km sur fr-WP. J'ai l'impression que le script oublie le séparateur décimal. --Jmh2o (talk) 10:14, 2 August 2016 (UTC)

Infobox biographie : renommé pour

Bonjour, existe-t-il une propriété équivalente à Renommé pour des infobox biographiques. Exemple : Albert Einstein renommé pour la Relativité générale. Je ne trouve pas grand chose dans la liste des propriétés des personnes, à part peut-être notable work (P800). Une idée ? Reptilien.19831209BE1 (talk) 08:40, 2 August 2016 (UTC)

@Reptilien.19831209BE1: Tu peux changer ton point de vue: au lieu de chercher à mettre toutes les inventions ou découvertes sur l'élément de l'inventeur, tu peux rechercher tous les éléments qui reconnaissent une même personne en tant qu'inventeur à l'aide de creator (P170). Exemple : general relativity (Q11452), creator (P170) -> Albert Einstein (Q937). Snipre (talk) 11:28, 2 August 2016 (UTC)
Oui, aussi, je n'y avais tout simplement pas pensé. Merci Snipre. Reptilien.19831209BE1 (talk) 11:54, 2 August 2016 (UTC)

Règles pour les versions d'un logiciel

Bonjour,

Sur l'élément Django (Q842014) et d'autres, certains contributeurs suppriment les entrées de software version identifier (P348) pour ne faire figurer sur l'élément que les dernières versions du logiciel (voir l'historique de l'élément). Il me semble que c'est incorrect et que nous devrions conserver tout l'historique des versions (par exemple pour produire des diagrammes, etc.) mais je n'ai rien trouvé à ce sujet dans l'aide...

Savez-vous ce qu'il en est ? Merci d'avance. Cdlt. Peter17 (talk) 07:23, 2 August 2016 (UTC)

@Peter17: La réponse est dans Help:Ranking. On garde les version antérieures en rang normal, et on met la dernière en rang privilégié. author  TomT0m / talk page 11:26, 2 August 2016 (UTC)
J’ai fait une proposition sur Wikidata talk:WikiProject Informatics/Software pour que ce genre d’erreurs (suppression d’entrées de software version identifier (P348) ou changement du rang en déprécié à la place de normal pour les anciennes versions) puisse diminuer. La méthode de TomT0m est bonne mais incomprise par certains éditeurs et parfois difficile à appliquer lorsqu’il y a plusieurs branches, des version différentes selon le système d’exploitation, ou un mélange entre versions stables, version bêta, versions alpha, versions rc, versions en support à long terme, etc. — Metamorforme42 (discussion) 01:52, 3 August 2016 (UTC)

Projet photographique lié aux vacances

Bonjour à vous. Suite à une discussion initiée sur le Bistro Wikipédia francophone, je me demandais s'il n'existait pas un projet à destination des touristes à l'étranger, qui répertorie les photos manquantes et désirées pour illustrer des articles concernant des pays lointains. En y réfléchissant, Wikidata est sans doute la solution, mais je ne connais pas assez la structure des données. Est-il possible de créer une requête qui :

  1. Répertorie les éléments (espèces de plante, types de minéral, montagne, volcan, mine, route, panneau de signalisation, etc.) liés à un pays ou une zone géographique donnée (à choisir) ?
  2. Pour lesquels il n'y a pas de photo sur Commons ?
  3. Avec un tri/filtre par nature d'élément ?

Ainsi, au départ en vacances, il est possible d'extraire une liste de photos à prendre et à déposer sur Commons au moment du retour. Pensez-vous que ce soit faisable ? Merci. --Consulnico (talk) 09:16, 3 August 2016 (UTC)

Bonjour Consulnico,
Il n'existe pas (à ma connaissance) de projet sur le sujet (sauf pour des cas spécifiques sur des sujets précis comme WLM, WLE, l'Été des régions).
Il est tout à fait possible de faire une requête sur les données de Wikidata, par exemple :
#Élément Wikidata sur une église situé en France et sans image (et avec les coordonnées si elles existent)
SELECT distinct ?item ?itemLabel ?coord WHERE {
	?item wdt:P31 wd:Q16970 ; wdt:P17 wd:Q142 .
	minus { ?item wdt:P18 ?image }.
	optional { ?item wdt:P625 ?coord }.
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}
Try it!
ou pour une région infra-nationale :
#Élément Wikidata sur une église situé en région Bretagne et sans image (et avec les coordonnées si elles existent)
SELECT distinct ?item ?itemLabel ?coord WHERE {
	?item wdt:P31 wd:Q16970 ; wdt:P131+ wd:Q12130 .
	minus { ?item wdt:P18 ?image }.
	optional { ?item wdt:P625 ?coord }.
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}
Try it!
Tu peux remplacer church building (Q16970), France (Q142), Brittany (Q12130) selon tes besoins. Il est possible d'afficher les résultats sur une carte (en cliquant sur 'Display' puis 'Map', cela ne fonctionne que quand les coordonnées sont renseignées évidemment).
Attention, il s'agit des éléments pour lesquels une image n'est pas renseigné ; cela ne veut pas dire qu'il n'existe pas d'image sur Commons, une vérification s'impose avant de faire des kilomètres pour rien (expérience douloureusement vécue).
Cdlt, VIGNERON (talk) 09:58, 3 August 2016 (UTC)
Merci beaucoup pour ces requêtes et tes conseils, je vais pouvoir travailler avec ! A bientôt. --Consulnico (talk) 12:42, 3 August 2016 (UTC)

Save/Publish

The Editing team is planning to change the name of the “Save page” button to “Publish page” and “Publish changes”. “Publish page” will be used when you create a new page. “Publish changes” will be used when you change an existing page. The names will be consistent in all editing environments.[2][3]

This change will probably happen during the week of 30 August 2016. The change will be announced in Tech News when it happens.

If you are fluent in a language other than English, please check the status of translations at translatewiki.net for “Publish page” and “Publish changes”.

The main reason for this change is to avoid confusion for new editors. Repeated user research studies with new editors have shown that some new editors believed that “Save page” would save a private copy of a new page in their accounts, rather than permanently publishing their changes on the web. It is important for this part of the user interface to be clear, since it is difficult to remove public information after it is published. We believe that the confusion caused by the “Save page” button increases the workload for experienced editors, who have to clean up the information that people unintentionally disclose, and report it to the functionaries and stewards to suppress it. Clarifying what the button does will reduce this problem.

Beyond that, the goal is to make all the wikis and languages more consistent, and some wikis made this change many years ago. The Legal team at the Wikimedia Foundation supports this change. Making the edit interface easier to understand will make it easier to handle licensing and privacy questions that may arise.

Any help pages or other basic documentation about how to edit pages will also need to be updated, on-wiki and elsewhere. On wiki pages, you can use the wikitext codes {{int:Publishpage}} and {{int:Publishchanges}} to display the new labels in the user's preferred language. For the language settings in your account preferences, these wikitext codes produce “Publish page” and “Publish changes”.

Please share this news with community members who teach new editors and with others who may be interested.

Whatamidoing (WMF) (talk) 18:02, 9 August 2016 (UTC)

Élaboration d'une structure de qualité des données

Bonjour à tous,

Alessandro Piscopo travaille sur l'élaboration d'un catalogue de critères pour évaluer la qualité des données de Wikidata. Il s'agit d'un projet mené par l'équipe "Web and Internet Science group" de l'Université de Southampton.

Vous pouvez trouver sa proposition ici. Le document est en anglais, nous avons préféré ne pas le traduire, vu le risque de déformer ou mal traduire les termes scientifiques utilisés. N'hésitez pas à donner votre avis, commenter, poser des questions.

Merci d'avance, Lea Lacroix (WMDE) (talk) 09:43, 12 August 2016 (UTC)

Cantons français

Bonjour,

M'occupant actuellement des communes de France, je suis tombé sur une classe canton français (à partir de 2015), s'ajoutant à la déjà existante canton français (jusqu'à mars 2015) (anciennement plus simplement "canton français"). La création de cette classe a été effectuée par Verdy_p. Ne serait-il pas plus utile d'avoir une seule classe canton français, comme c'était d'ailleurs le cas avant - et pour distinguer les cantons existant avant, après, ou de part et d'autre du redécoupage cantonal, apposer des qualificateurs date de début ou date de fin (là où ils s'appliquent) et/ou des propriétés date de fondation/création ou date de dissolution (là où elles s'appliquent).

Les communes françaises sont déjà passées à ce système, la classe "ancienne commune française" ayant disparu : il me semble logique d'en faire de même pour les cantons.

J'ajoute que les cantons prévus par le redécoupage ne sont pas encore tous créés, ce qui signifie que cette classe est en soi fautive : les futurs cantons n'existent pas tous depuis mars 2015, les anciens n'ont pas tous disparu en mars 2015.

Il apparaît qu'il existe 2048 "nouveaux" cantons (employant cette classe surnuméraire) et 4749 "anciens" cantons (utilisant l'ancienne classe, qu'ils existent encore ou non).

Je suis donc d'avis de fusionner ces deux classes dans l'ancienne, non sans avoir ajouté les dates de création (comme qualificateur de instance of (P31) et/ou comme propriété inception (P571)).

Alphos (talk) 13:15, 3 August 2016 (UTC)

Tu te trompes, tous les cantons d'avant 2015 ont disparu, d'il y a des cantons homonymes, ce ne sont plus du tout les mêmes, ils ont été entièrement recomposés. De plus la classe n'est pas fautive du tout, puisqu'en fait ces cantons ne sont pas classés de la même façon : ce ne sont plus des subdivisions des arrondissements, mais des subdivisions des départements (les cantons à cheval sur plusieurs arrondissements sont nombreux).
Bref "avant 2015" est une précision indispensable, d'autant que leur fonctionnement est radicalement différent. Malheureusement le terme a été gargé et il faut bien mettre une précision pour lever l'ambiguité.
Enfin le fait que tous les nouveaux cantons n'ont pas été créés dans Wikidata n'est pas un problème: ils sont à compléter oui. Il y a une liste à jour et complète dans OpenStreetMap (qui a terminé ça avant Wikipédia: Wikipédia est en retard sur des tas d'articles oui... Note: on pourrait avoir un nom "ancien canton" mais l'ennui c'est qu'on va avoir aussi des anciens cantons issus de l'actuel nouveau découpage, et qui pourtant ne seront pas des subdivisions des arrondissements). Si on voulait être clair on dirait "canton d'arrondissement" (avant 2015) en opposition à canton départementaux (depuis 2015). Mais il est préférable quand même de dire simplement "canton" pour les cantons actuels, puisque c'est la terminologie officielle.
Une chose est certaine on ne peut pas les mélanger. Verdy p (talk) 14:00, 3 August 2016 (UTC)
Ce sont les mêmes entités, avec des capacités différentes. C'est quelque chose qui s'indique dans la classe concernée en ajoutant des qualificatifs si nécessaire, pas en créant une nouvelle classe.
On parle toujours de "cantons", pas de "cantons (après 2015)". Leur liste, composition, et rôle ont pu changer, mais ce sont toujours des cantons. Alphos (talk) 14:50, 3 August 2016 (UTC)
Pourquoi avoir viré la classe "ancienne commune" ? author  TomT0m / talk page 14:21, 3 August 2016 (UTC)
Pour la même raison qu'on a pas de classe "ancien humain" pour les gens qui sont morts, ni de classe "ancien duché" pour les duchés disparus. Alphos (talk) 14:50, 3 August 2016 (UTC)
Voir Wikidata:Bistro/Archive/2016/07#Micmac départemental, ce genre de scission est pour moi totalement intenable à long terme. Mais bon... --Nouill (talk) 17:18, 6 August 2016 (UTC)
Je trouve bizarre que l'on crée des éléments pour chaque modification de status des cantons ou des départements, mais pas d'élément différents pour les différentes France. Pourquoi un élément différent pour canton français (à partir de 2015) et canton français (jusqu'à mars 2015) et pas pour France (Ire république), France (IIe république) ou encore France (sous de Gaulle) ou France (sous occupation allemande) ? Encore une fois, on ne crée pas un élément à chaque modification de la constitution, donc rien ne justifie une création d'un nouveau lorsqu'un changement organisationnel a lieu. Le changement de nom ne justifie pas plus la création d'un nouvel élément. Bref, il faut garder une certaine mesure et éviter la créationite elementicus aigüe. Snipre (talk) 12:24, 8 August 2016 (UTC)
@Alphos, Verdy p, Nouill: La problématique est complexe et je ne suis pas sur que le Bistro soit le meilleur endroit pour en discuter. Plus le temps passe et plus je me dis que la création de cette distinction de deux classes était une fausse bonne idée d'utiliser instance of (P31) pour gérer cette subtilité (les qualificatifs start time (P580) et end time (P582) sont une bonne idée mais sont-ils suffisants pour tout les besoins ?). Soit on crée 36 classes pour modéliser toutes les subtilités depuis 1790, soit on en garde une et on place la précision ailleurs que dans la classe, mais ce système bâtard avec deux classes est vraiment trop bancal.
Par contre, il ne pas juste voir pas le petit bout de la lorgnette ce qui est un exemple typique de la métaphore du cylindre, est-ce que l'on pourrait (enfin) avoir une discussion complète globale et même si possible exhaustive sur la modélisation, la structuration et la gestion des éléments sur les cantons (et de tout les cantons, pas juste de ceux actuels ou de ceux de juste avant 2015) et réfléchir à tout les aspects (et pas juste des arguments assez anecdotique comme « c'est le même nom » parce qu'à ce compte là, ad absurdum, on pourrait aussi fusionner avec les cantons suisses) pour avoir une granularité à la fois satisfaisante sans être ingérable... (vaste tâche comme aurait dit le Général). La meilleure façon de résoudre cela est de fournir des sources.
Snipre il ne me semble pas s'agir ici de « créationite » puisque avec une, deux ou 36 classes, le nombre d'élément total sera le même (sauf pour les éléments de la ou les classes évidemment mais bon même 36, sur 10 000 cantons, ça ne change pas grand'chose). En plus, la multiplicité des éléments a souvent bien des avantages (ne serait-ce que parce qu'il est plus facile de travailler sur un sujet limité plutôt que sur un sujet général, France (Q142) nous donne du fil à retordre sur la date de début - avec des divergences de plusieurs dizaines de siècles - alors qu'il n'y a aucun problème pour donner une date au jour près pour French First Republic (Q58296)) et sont même parfois nécessaires (typiquement, si j'ai un livre dont le sujet est « l'histoire X », il est structurellement d'avoir un élément sur ledit X).
TomT0m les classes « anciens quelque chose » sont assez artificielles et alambiquées (là typiquement, les qualificatifs de date suffisent généralement) et pour tout dire, un peu ridicule car ce qui est intéressant dans le concept décrit avec ce genre de classe, c'est justement à l'époque où il n'était pas ancien. Si on prend l'exemple du département français des Forêts (Q378004) après 1814 il a disparu et n'a plus qu'un intérêt limité (pour ne pas dire nul, déjà que l'époque de l'occupation française n'intéresse qu'un nombre assez faible de personne...).
Cdlt, VIGNERON (talk) 22:50, 9 August 2016 (UTC)
@VIGNERON, Verdy p: Mais tellement… Enfin, 36 ou plus. De même pour tous les trucs qui ont changé de composition (Assemblée nationale, dont la taille a varié), de territoire (France), de compétences (ben justement, cantons), de statut ("anciennes" communes), au fil du temps.
Soyons francs (huhu), je suis partisan de l'ontologie à une classe et des attributs, qui me semble la plus pragmatique : rien que pour une liste chronologique, la multiplication des classes rend les choses difficiles voire impossibles à maintenir, aussi bien pour le jeu de données que sur des requêtes effectuées dessus ; une classe unique et des éléments avec attributs permet tout ce que des classes multiples permettent, et plus : pourquoi s'en priver ?  
@Nouill: Si on faisait comme ça pour tout, on se retrouverait avec des gens nés en   Germany (Q183) ! Pauvre Gerhard Schröder (Q2530), quand même…
Alphos (talk) 13:07, 10 August 2016 (UTC)
@Alphos: si les deux systèmes sont si équivalents, pourquoi en choisir un plutôt que l'autre ? On ne peut pas décider juste sur des préférences personnelles et partisanes. « une classe unique et des éléments avec attributs permet tout ce que des classes multiples permettent » est-ce vrai ? j'entends régulièrement des remarques sur le fait qu'il n'est pas toujours possible de manipuler les qualificatifs (c'est une des raisons invoquées de l'existence du doublet start time (P580)-end time (P582) / inception (P571)-dissolved, abolished or demolished date (P576)), je n'aime pas trop l'idée de devoir niveler par le bas à cause de certains outils déficients mais si les remarques reviennent si souvent, cela vaut la peine de les écouter (si vous êtes dans ce cas, n'hésitez pas à développer ici ces remarques) ; rien ne sert de faire un outil si parfait qu'il en devient inutile et inutilisé.
Au-delà de cela, il y a une vrai question : quand, comment et pourquoi réunir ou scinder les classes ? pourquoi une séparation serait-elle justifié ou non ? Pourquoi est-ce que la distinction temporelle avant/après 2015 choque et pas celle spatiale entre canton français et canton luxembourgeois ?
Et puis bon, quand je vois les millions d'informations manquantes sur les cantons, je me dis que la question de la classe n'est pas forcément une priorité... Au final, un ou plusieurs classes plus ça va, plus je m'en fiche ; est-ce que l'on pourrait faire quelque chose pour vraiment améliorer les éléments des cantons ? (et pas juste un détail par-ci, par-là...).
Quant au point Godwin, je vais l'ignorer : d'abord parce que ce n'est pas tant le problème de Wikidata que celui du ré-utilisateur des données de Wikidata, ensuite et surtout parce que l'on a régulièrement la remarque inverse : « le nom du lieu de naissance à l'époque est X et pas Y qui est le nom actuel », et enfin Q183#P41.
Cdlt, VIGNERON (talk) 14:10, 10 August 2016 (UTC)
@VIGNERON: Parce que 2 systèmes impliquent à chaque fois de déterminer quelle structure est utilisée si on veut utiliser les données. Les humains sont intelligents, mais va demander à un bot de determiner lui-même quelle est la structure de données: cela est possible, mais demande de doubler tous les codes afin de pouvoir à chaque fois s'adapter à la bonne structure. Cela empêche la création d'outils généraux pour les requêtes, la recherche voire les applications genre timeline. Je ne suis pas un spécialiste, mais dire que les 2 systèmes sont équivalents est faux. Il y a des avantages et des désavantages en fonction du but de la base de données. C'est ce qu'il faudrait une fois analyser pour pouvoir faire un choix en connaissance de cause, mais là on part sur des questions d'ordre théorique.
Dernière chose, peux-tu me dire quelle application est limités pour l'utilisation des qualificatifs ? Parce que à ma connaissance, on peut utiliser le langage SPARQL avec des qualificatifs, donc il n'y a pas de limitations pour extraire les données actuellement. Cela à l'air d'être un reliquat du précédent outil de requête. Snipre (talk) 14:42, 10 August 2016 (UTC)
@VIGNERON: L'objectif fonctionnel des classes "ancien machin", et encore une fois c'est un peu inutile de raisonner en fonction du label qui est probablement mal choisi et qui peut être changé, c'est plutôt d'avoir quelque chose pour dire que cette entité n'est plus pertinente de manière contemporaine. On pourrait y inclure une classe "humain décédé" comme synonyme de "humain avec une date de décès" par exemple, et ça aurait aussi un sens (avec en plus un sens fonctionnel fort puisque ce n'est pas modélisé avec une date de fin mais avec une date de décès.) Ces classes, si on arrive à les maintenir correctement permettraient dans mon idée d'avoir une manière relativement simple de séparer le contemporain du non contemporain de la même manière qu'on a un moyen de séparer le réel du fictionnel avec la superclasse parente de tout ce qui est fictionnel. author  TomT0m / talk page 08:45, 11 August 2016 (UTC)
@Snipre: oui, avoir 2 systèmes présente des inconvénients, mais là, on a un seul système (à deux classes certes mais la structure est unique ou presque). De toute façon, même si on a une seul classe, il faudra mettre un peu d'intelligence dans le robot ou l'outil qui analyse la classe ; typiquement, avant 2015 il devra récupérer un seul élu par canton (ce qui était les élections cantonales) et deux élus après 2015 (ce qui est maintenant des élections départementales, dont un homme et une femme ; d'ailleurs pour l'anecdote, de facto, une personne de genre non-binaire ne peut plus être élu depuis 2015). Pour l'équivalence, je veux dire que toute information présente dans un système peut-être automatique (et assez trivialement) convertie dans le second système (après la maintenance, la gestion, la manipulation, etc. ne sont évidemment pas strictement équivalents). Pour les limitations, effectivement, peut-être les remarques que j'ai entendu sont-elles obsolètes, je ne sais pas (et peut-être que cela vient en partie de la méconnaissance de SPARQL ; de mémoire, il me semble que j'ai entendu Jura1 émettre ce genre de remarques).
@TomT0m: « humain décédé » (et « humain mort » aussi ?) me semble une mauvaise idée. Pourquoi mettre l'information non-non-A quand l'information A suffit ? C'est équivalent et la seconde façon me semble bien plus simple. Personnellement, je préfère user et abuser du principe de parcimonie : ne pas mettre plus d'informations que nécessaire (et donc éviter les redondances). En plus, cela oblige à changer de classe ou moment de la mort et/ou du décès de la personne (sachant que la vie est un état forcément temporaire chez l'être humain, la « classe "humain pas encore mort" » est forcément transitoire alors que la classe « humain » est pérenne, un humain a forcément une date de mort, si il est en vie cette date est juste temporairement inconnue mais dans l'absolu on sait avec certitude qu'elle existe néanmoins). Pourquoi utiliser une classe pour distinguer le contemporain du non-contemporain (dont la frontière est mouvante et subjective ; avec une classe basée uniquement sur le point de vue présent, comment avoir les éléments d'un point de vue passé ? par exemple si je veux la liste des personnes vivantes en 1496 ou bien des cantons existants en 1870 ? ad absurdum va-t-on finir par avoir des milliards de classes du style « humain décédé le 3 mars 1496 » ou bien avoir des qualificatifs et se retrouver finalement avec la même problématique qu'au début ?) quand d'autres propriétés permettent aisément de le faire ? (en l'occurrence la propriété date of death (P570) suffit généralement mais si on veut être sur et certain on peut aussi vérifier place of death (P20), date of disappearance (P746), manner of death (P1196), cause of death (P509), etc. voir une distance supérieure à 150 ans pour date of birth (P569) ou floruit (P1317) si on veut vraiment être précautionneux, bref : on a largement l'embarras du choix) Je ne dit pas que ce n'est pas nécessaire mais je doute de la pertinence d'ajouter de la complexité avec des nouvelles classes pour un gain que m'est invisible. Si certains d'entre vous sont à Paris dans 10 jours, je serais heureux d'en parler de visu ;) Pour le sujet initial lancé par Alphos, je suggère d'en discuter sur Wikidata talk:WikiProject France pour développer les arguments de chacun et analyser des exemples concrets avant de revenir sur le Bistrot avec une proposition bien ficelée.
Cdlt, VIGNERON (talk) 11:00, 11 August 2016 (UTC)
J'aime toujours pas les arguments du type "pente savoneuse", qui sont classés dans les arguments fallacieux :p et dont on use et abuse un peu trop sur les projets Wikimedia, et qui ont finalement assez peu de rapport avec la parcimonie. D'ailleurs je n'ai pas du tout proposé la création de la classe "humain pas encore mort". author  TomT0m / talk page 13:56, 11 August 2016 (UTC)
Pour référence, w:fr:Pente savonneuse. author  TomT0m / talk page 14:00, 11 August 2016 (UTC)
On souffre tous de biais cognitifs, mais je ne pense pas avoir utiliser la pente savonneuse (d'autant moins que ce n'était qu'une des deux alternatives d'un raisonnement ad absurdum qui repose donc sur le postulat que les « solutions » examinées sont absurde ; de toute façon, il est certain que Wikidata tend vers des milliards d'éléments, la problématique n'est pas tant leur nombre mais leur gestion). Mais si c'est le cas, je m'en excuse.
De toute façon, ce n'était qu'une argument parmi d'autres, faire une réduction en se focalisant sur un détail au lieu de l'ensemble est aussi un biais cognitif ;).
Cdlt, VIGNERON (talk) 15:50, 11 August 2016 (UTC)
ben en relisant, je vois pas vraiment d'autres arguments :) J'y vois un gain que tu ne semble pas reconnaître (tu dis que tu ne le vois pas) : ça permet de séparer à peut prêt clairement l'ensemble des élément concernant l'époque actuelle et les autres sans avoir à requêter de manière complexe et dépendantes du domaine d'application (personne avec une date de décès, entité détruites, concepts obsolètes) les entités qui ne sont pas "actuelles". La difficulté de maintenance, en ce qui concerne les entités administratives, me semble toute relatives : on peut classer toutes les entités obsolètes passées assez facilement, par exemple mettre "province romaine" en sous classe d'entité administrative ancienne ne demande qu'une seule déclaration. Même chose pour faire disparaître les anciens département si on crée de nouvelles entités pour les entités nouvelles / les nouveaux statuts d'entités. Un bot peut facilement se charger de classer les personnes décédées, ... author  TomT0m / talk page 17:41, 11 August 2016 (UTC)
@TomT0m: Ouch, merci pour mes autres arguments  .
Plus sérieusement, en quoi le 11 août 2016 est-il plus pertinent que le 10 août 2016 ou le 4 septembre 1496 pour faire une séparation ? effectivement, je ne vois et je ne comprends pas en quoi le présent serait pertinent (dans l'absolu, parce que pour les cantons, en 2015 il y a des changements assez importants qui là me semble mériter une distinction).
Les provinces romaines sont un cas particulier, le point intéressant n'est pas tant que ce soit une entité disparu (attention, tu dis « ancienne » mais ce qui est ancien n'a pas forcément disparu, l'Univers est âgé d'environ 14 milliards d'années mais il est toujours là  ) mais que ce soit une entité qui fait partie d'un système qui a disparu ; du coup, c'est un cas simple (toute les provinces romaines ont disparues) alors que pour les cantons, c'est bien plus compliqué (les trois-quarts ont disparus mais pas tous mais si tout les cantons ont changés en 2015, on peut dire que les cantons pre-2015 ont tous disparus *du point de vue de la structure de l'époque*).
J'ai l'impression que tu te contredis un peu, d'une part tu parle « requêter de manière complexe » mais tu conclus en disant « bot peut facilement »... Est-ce facile ou non ? Et plus important, la facilité est-elle critère un critère suffisant ou même nécessaire pour justifier de la classification ? Et accessoirement, qu'est-ce qui est le plus complexe entre un ou plusieurs classes pour les cantons ? avec un classe, il faut adapter la requête en fonction de l'époque alors qu'avec plusieurs classes, il faut adapter la requête en fonction de la classe, en terme de complexité cela me semble assez équivalent...
Cdlt, VIGNERON (talk) 20:36, 11 August 2016 (UTC)
@VIGNERON: Un bot va inscrire une fois pour tout cet état de fait dans la base de données, ce qui simplifiera le requêtage ensuite. Le choix est entre faire faire ça par un bot ou de réécrire de manière sempiternelles les mêmes clauses dans une requête qui de fait sera plus complexe. avec un classe, il faut adapter la requête en fonction de l'époque alors qu'avec plusieurs classes, il faut adapter la requête en fonction de la classe : pas vraiment, en fait je parlais ici de l'idée générale ici c'est d'avoir une superclasse de toutes les entités valable dans notre instant T. Du coup pour exclure les entités anciennes ça devient très simple : insérer un moins les instances de sous classe d'<entité ancienne> et tu auras virés d'un seul coup les entités administratives non pertinentes à notre instant T et les personnes décédées. avec un classe, il faut adapter la requête en fonction de l'époque => pas seulement. Il faut aussi adapter la requête en fonction du type d'ntité requêter puisqu'on a pas un moyen homogène de le modéliser. C'est ce à quoi j'aimerai remédier si possible :) author  TomT0m / talk page 16:33, 12 August 2016 (UTC)
Dans la série "ça n'a rien à voir avec la choucroute mais c'est quand même un peu connexe et la discussion est pas finie alors je pose ça ici", un article trouvé grâce à l'excellent blog passeur de sciences qui parle de la toute relative utilité pratique du principe de parcimonie en sciences : http://www.theatlantic.com/science/archive/2016/08/occams-razor/495332/ :) . author  TomT0m / talk page 17:21, 13 August 2016 (UTC)
Vous n'avez toujours pas compris que ce n'est pas qu'un changement de statut, c'est un changement de niveau administratif (les anciens cantons étaient des subdivisions des arrondissements, ce n'est plus le cas, les départements sont maintenant divisés **parallèlement** en cantons et en arrondissements (au même niveau). On ne peut plus rattacher aucun des nouveaux cantons à un arrondissement, alors que les arrondissements existent toujours. Il y a aussi les propriétés de niveau administratif qui ne sont plus les mêmes. Bref pas moyen d'être correct dans la représentation si on veut garder dans les wikis des références aux anciens cantons et aux nouveaux. Dans Wikipédia ils sont parfois traités dans le même article dans deux sections (quand ils ont le même nom, mais ce n'est souvent pas le cas). Dans Wikidata en revanche, on ne mélange pas, même si les liens Wikipédia mentionnés peuvent inclure une #ancre vers une section d'article (mais chaque wiki peut avoir plus ou moins de pages détaillées ou regroupées).
Le but est de se correctement les données (on ne peut pas se contenter juste des dates alors qu'en fait strictement aucun des nouveaux cantons ne correspond aux anciens).
Si une chose vous choque avec le suffixe "depuis mars 2015" dans le nom, on peut s'en passer pour les cantons actuels, mais alors pas dans les anciens, on ne peut pas les mélanger. Verdy p (talk) 02:16, 14 August 2016 (UTC)

Exemple de bizareries qui peuvent se produire

Un exemple de bizarerie qui pourraient se produire si on veut absolument y aller à faire de l'économie d'éléments : sur l'infobox de w:fr:Léonard Bourdon on voit dans l'infobox "député à l'assemblée ou à la chambre des députés". Quand on passe la souris dessus et qu'on attend la prévisualisation de l'article on peut lire Un député en France est l'élu qui siège à l'Assemblée nationale. Il est élu — en même temps que son remplaçant éventuel — au suffrage uninomimal universel direct dans le cadre des élections législatives qui se déroulent dans 555 circonscriptions en métropole et outre-mer. Clairement, c'est un anachronisme ... author  TomT0m / talk page 09:45, 14 August 2016 (UTC)

L'exemple me me semble pas très bon. D'abord, dans l'absolu, tu donnes un exemple de réutilisation, or les données de Wikidata ne doivent pas être structurées en fonction des réutilisations possibles (ces réutilisations sont infinies et potentiellement contradictoires ; après, il ne faut évidemment pas non plus agir totalement indépendamment des besoins). Ensuite, pour ce cas précis, l'anachronisme n'était qu'apparent, cela m'a pris quelques secondes pour que l'introduction reflète le contenu de l'article (il reste le problème de la formulation « député à l'assemblée ou à la chambre des députés » qui est étrange et incomplet mais rien d'insoluble là non plus).
Ceci dit, l'exemple reste intéressant et on revient encore et toujours à la même question : une ou plusieurs classes et surtout *pourquoi* ? Personnellement, je reste partagé, les deux possibilités ont des avantages et des inconvénients, et sans arguments clairs je préfère ne pas chambouler inutilement le statu quo.
Cdlt, VIGNERON (talk) 12:17, 14 August 2016 (UTC)
@VIGNERON: Si il n'y avait que le RI ... mais c'est tout l'article qui est tourné vers l'état actuel, à part une bien maigre section histoire. author  TomT0m / talk page 13:53, 14 August 2016 (UTC)
D'ailleurs c'est pas très compliqué de trouver des choses plus spécifiques, par exemple ne serait-ce qu'une catégorie : Category:Deputies of the 1st National Assembly of the French Fourth Republic (Q9693649)      même si c'est pas une correspondance exacte.
A part ça il y a quoi de pas clair dans les arguments ? author  TomT0m / talk page 13:59, 14 August 2016 (UTC)
Tu pointes, le RI, je corrige le RI (surtout qu' une bonne partie des lecteurs ne vont guère plus loin). Le reste de l'article est améliorable et sera amélioré, c'est un wiki. Le sujet de l'article c'est bien ce qu'indique le titre « député français » (et pas juste actuel).
Après, les projets Wikimédia ne sont pas la seule référence pour la création d'élément (cf. WD:N), il ne faut pas toujours chercher à y coller (ou à l'inverse à s'en éloigner). Du point de vue encyclopédique, un article peut traiter de deux concepts proche en même temps là où Wikidata a besoin de deux éléments (typiquement, il n'a qu'à voir la profusion d'élément sur des professions sans lien interwiki), et vice-versa.
Pour Category:Deputies of the 1st National Assembly of the French Fourth Republic (Q9693649), tu m'a perdu, quel serait le problème ? (si ce n'est que l'élément est quasi-vide...).
Au final, je ne vois quasiment aucun argument solide, ni pour la fusion des deux classes cantons, ni pour la scission de la classe député. Le seul argument que je retiens c'est celui de vouloir harmoniser pour simplifier les requêtes mais d'une part, je n'ai jamais trop aimé le normativisation, encore moins lorsqu'il s'agit de discrétisation d'un phénomène (plus ou moins) continu, cela ne mène souvent qu'à un appauvrissement alors que nos données sont déjà assez peu riches... ; d'autre part, je ne vois pas en quoi les requêtes ne sont pas déjà fort simples.
Par contre, il y a de nombreux outils externes qui reposent sur le schéma actuel (par exemple dicare de Envlh), c'est pourquoi je préférerais éviter de tout bouleverser pour un changement dont l'intérêt me semble méconnu si ce n'est inconnu.
Cdlt, VIGNERON (talk) 14:51, 14 August 2016 (UTC)
cela ne mène souvent qu'à un appauvrissement alors que nos données sont déjà assez peu riches => MMmmmm Reference needed ?? Je ne te suis mais alors pas du tout.
Le seul argument que je retiens c'est celui de vouloir harmoniser pour simplifier les requêtes mais d'une part, je n'ai jamais trop aimé le normativisation => C'est à dire que c'est le principe de structurer les données, leur donner une structure définie. Remplace "norme" par structure, et ta phrase devient complètement contradictoire avec Wikidata. Ça n'a aucun sens.
il y a de nombreux outils externes qui reposent sur le schéma actuel => C'est complètement contradictoire avec ce que tu disais avant. Il ne faut pas de norme, par contre il faut respecter le schéma tel qu'il existe ? On ne fournit pas de garantie de stabilité du modèle, et c'est complètement contre productif tant que les discussions sont vives puisque ça veut dire entériner les erreurs de jeunesse.
Quand au processus continu, il y a clairement des discontinuités entre les législatures, entre les constitutions qui changent le rôle des uns et des autres, entre les règles administratives qui changent et peuvent complètement changer la définition d'une entité, même si elle conserve son nom. Et ... 1 définition = 1 item. Sinon ne on sait pas simplement a quoi on fait référence et on a au final des items vagues ou pire ambigus.
d'autre part, je ne vois pas en quoi les requêtes ne sont pas déjà fort simples. => Des requêtes simples à porté limitées ne seront forcément pas bien complexes. Après il faut voir plus loin. On ne discute qu'entre francophones, sur un micro domaine (la politique). Il y a fort à parier que d'autres modèles pour d'autres pays soient/deviennent différents. Pour croiser les données entre domaines / pays ça risque de vite devenir assez complexe avec des bouts de copier coller moches dans tous les sens. author  TomT0m / talk page 15:21, 14 August 2016 (UTC)
Cette discussion commence à devenir un dialogue qui tourne en rond ; toi lecteur de ce bistro, n'hésite pas à donner ton avis.
1. Multiplier les éléments, c'est multiplier les risques d'incohérence entre les éléments. Si on a deux éléments sur un concept proche, cela augmente les risque qu'un seul des deux éléments soit compléter, améliorer, surveiller, utiliser, etc. Cela ne veut pas dire qu'il ne faut pas multiplier les éléments (au contraire) mais il semble qu'il faut le faire avec parcimonie, quand un besoin existe (par exemple, si on a des informations indépendantes). Pour les députés, avoir un seul élément me semble suffisant. On peut placer dans un seul élément toute les informations utiles et nécessaires pour décrire ce concept.
2. On entre dans des détails philosophiques mais pour moi, la modélisation des données dans Wikidata est (ou devrait être) plus descriptive que normative (termes plutôt issus de la linguistique ; en technique de l'information, on dirait peut-être plutôt « standardisation plus normalisation » mais je suis moins à l'aise et donc moins sur de ces désignations).
3. Problème de référentiel dialectique, un schéma n'est pas une norme. Le point important est que je veux éviter l’ad novitatem, la nouveauté ce n'est pas mauvais en soi, mais la nouveauté pour la nouveauté est une mauvaise direction ; inversement le statu quo ne doit pas devenir du conservationnisme. Bref, je ne suis pas contre le changement et l'instabilité, mais cela doit être justifié.
4. C'est le propre d'un continuum de contenir des discontinuités (sinon, cela ne serait pas un continuum mais une unité) ; toute la question est l'importance de ces discontinuités, sont-elles irréconciliables au sein d'un même élément ? (dans ce cas, on crée plusieurs éléments ; sinon, on en crée un seul). Pour le député, on a une définition unique correspondant à tout le continuum : « membre de la chambre basse du parlement français » (la description de Q3044918) et on a effectivement aussi des définitions plus précises quand on augmente le niveau de granulométrie (typiquement en fonction desdites chambres à travers le temps). Ces distinctions étant clairement séparées dans le temps, des qualificatifs me semble suffisant (et cela permet de simplifier la requête en n'interrogeant qu'un seul élément).
5. cf. ma parenthèse précédente, n'est-ce pas plus simple et de portée plus importante de n'interroger qu'un seul élément ? Quant aux autres pays, tout les députés font partie d'un même concept global (deputy (Q1055894)), je ne vois pas de problème pour faire une requête sur plusieurs systèmes parlementaires (dans la mesure où ceux-ci sont cohérents évidemment, impossible de savoir si les députés d'un pays A sont en moyenne plus âgés que les députés d'un pays B si on prend un pays B sans députés...).
Cdlt, VIGNERON (talk) 15:58, 14 August 2016 (UTC)
1. Ça me semble absurde. La portée d'un élément doit clairement être délimitée, ça fait partie de sa définition. Il n'y a donc pas vraiment de risque de confusion. D'autre part dans Wikidata on a le concept de superclasse parente qui doit recueuillir les informations communes aux éléments spécifique. Règle : on doit mettre les informations dans l'endroit le plus générique possible. Sinon c'est plus les incohérence inter éléments que tu risques, mais bien pire : les incohérences intra éléments.
2. On décide de créer des propriétés pour représenter certaines choses. On décide d'étendre leur portée. On se demande comment on peut représenter certaines choses et on essaye de se mettre d'accord. On ne part pas d'un langage préexistant qu'on essaye de décrire. On est dans la construction et on a la plupart des données entre les mains. On ne peut certes pas tout prévoir, mais en général on se demande quelle est la meilleure manière d'importer des données avant de le faire. Je ne sais pas si ça rentre dans ta grille de lecture.
4. C'est le propre d'un continuum de contenir des discontinuités : c'est complètement absurde, sinon un ensemble discret, qui par définition n'est pas un continuum, ne contient que des discontinuté, serait caractérisé par le fait d'être un continuum parce qu'il contient des discontinuités - il ne contient que des discontinuités ??? Le continuum de la droite des réels de 0 à 1 ne contient pas de discontinuité, c'est ce qui le définit : on peut aller de 0 à 1 sans lever le crayon. Contenir des discontinuité c'est certainement pas une propriété d'un continuum. Tu confond un peu le fait d'avoir une définition avec le fait que la définition peut correspondre à des définitions plus spécifiques (certains langages permettent même de décrire ces définitions avec des "déclarations"). Mais ça ne nous donne aucune clé sur quelles sont les définitions pertinentes à utiliser.
5. On a un concept très pratique qui s'appelle le sous classement. Si tu veux récupérer les instances d'une classe et de ses sous-classe tu fais du ?taclasse wdt:P279*/wdt:P31 wd:Q5 ce qui te permet d'adapter le niveau de détail en requêtant la classe la plus spécifique qui t'intéresse, et de ne pas lister toutes les classe. Plus souple et efficace, tu meurs ;) (effectivement si on est pas sur la même longueur d'onde sur ce principe on ne peux pas se comprendre). Ca veut dire qu'on peux classer de différentes manières sans perdre en souplesse en rigidisant le modèle, et sans se marcher sur les pieds. Tu veux parler de quels députés ? Les députés de la législature courante ? Dans ce cas tu vas t'amuser à devoir extraire les législatures en cours dans les autres pays ... sinon la question me semble pas très bien posée. L'age moyen des députés de la première assemblée française est sans doute très différent de l'age des député actuel, et il n'y avait rien en face ... author  TomT0m / talk page 16:27, 14 August 2016 (UTC)

Community communication sur Wikidata

Bonjour à tous,

Je m’appelle Léa, et aujourd’hui est mon premier jour chez Wikimedia Deutschland en tant que chargée de la communication avec les communautés pour Wikidata  

Vous m’avez peut-être déjà croisée sur les projets avec mon compte perso, Auregann. Je contribue sur Wikipédia en français, où j’ai notamment participé au projet d’accueil des nouveaux contributeurs, j’ai fait quelques imports sur Commons, et je suis membre active de la NCO, célèbre (refnec) groupe local où je contribue à organiser des rencontres entre contributeurs, des ateliers d’initiation et des partenariats avec des institutions culturelles depuis 2011.

Du côté pro, j’ai été développeuse web, j’ai travaillé sur un projet d’open data local, puis j’ai été formatrice aux outils numériques pour des bibliothécaires durant trois ans.


Je commence mon poste chez WMDE pour accompagner Lydia sur la communication auprès de la communauté de Wikidata ainsi que plusieurs projets d’intégration des donnés de Wikidata dans d’autres projets Wikimedia : je participerai aussi sur Wikipédia, Commons, le Wiktionnaire… Je suis là pour échanger avec les contributeurs des projets, récolter vos idées et vos suggestions, vous aider à résoudre les problèmes rencontrés et m’assurer que tout se passe bien et que l'on peut continuer à améliorer notre base de connaissances préférée dans une ambiance sympathique et constructive  

Je vais commencer par me familiariser avec les manières de travailler sur Wikidata, discuter avec vous et aider Lydia à répondre aux questions techniques. Je vais également travailler sur des projets en cours : faire le tour des outils de communication existants, continuer d’améliorer le processus de sélection des items de qualité, et organiser des trucs chouettes pour le 4ème anniversaire de Wikidata  


Si vous avez la moindre question, suggestion ou idée, ma page de discussion vous est ouverte et je vous répondrai dès que possible. Si vous avez besoin d’un conseil ou si vous voulez m’informer d’une discussion en cours, n’hésitez pas à me notifier. Vous pouvez aussi m’écrire un mail (lea.lacroix wikimedia.de) ou sur IRC (LeaAuregann_WMDE).

Je suis ravie de rejoindre l’équipe et j’ai hâte de commencer à travailler avec vous sur ces différents projets !

À bientôt, Lea Lacroix (WMDE) (talk) 18:28, 10 August 2016 (UTC)

Bienvenue et bon courage dans ta nouvelle tâche  . Pamputt (talk) 19:20, 10 August 2016 (UTC)
Bienvenue ! VIGNERON (talk) 09:24, 11 August 2016 (UTC)
\o_ author  TomT0m / talk page 14:46, 13 August 2016 (UTC)

Noms vernaculaires de plantes dans différentes langues

Bonjour,

J'ai découvert ce site donnant les noms vernaculaire de genre de plantes. Peut-être un robot peut-il en récupérer les données pour alimenter la propriété taxon common name (P1843) ? Cordialement. Gtaf (talk) 23:13, 13 August 2016 (UTC)

Bonjour Gtaf,
Avant tout import, il y a plusieurs questions à se poser (je résume) :
  • est-ce possible techniquement ? (question de format principalement)
  • est-ce possible légalement ? (question de licence, de la nature juridique des données, etc.)
  • est-ce souhaitable ? les données sont-elles fiables, manquantes, etc.
Là il me semble que le second point pose le plus de problème : on a des pages HTML où j'ai du mal à discerner un format facilement manipulable. Du coup, cela exclut des outils semi-automatiques habituels et il faudrait qu'un spécialiste de l'import se penche sur ce site.
Cdlt, VIGNERON (talk) 14:59, 14 August 2016 (UTC)
Bonjour Vigneron. Merci de ta réponse. Attendons l'avis du spécialiste. Cdt. Gtaf (talk) 16:21, 14 August 2016 (UTC)

Propriété non convertie en identifiant externe

Bonjour, je viens de voir que la propriété protected areas INPN Code (P1848) n'a pas été convertie en identifiant externe. Il y a quelqu'un qui connait la procédure convertir pour ce retardataire? --Fralambert (talk) 23:53, 14 August 2016 (UTC)

@Fralambert: Les débats de sélection des items de type "chaîne" à convertir en type "identifiant externe" sont en Wikidata:Identifier migration. protected areas INPN Code (P1848) se trouve pour le moment dans la section Wikidata:Identifier_migration/1#Mix_of_good_to_convert_and_disputed ("mélange de bons à convertir et de contestés"). Les conversions de types de propriétés se font à la pièce en ce moment; si tu trouves que l'unicité des identifiants est bien solide, les demandes se font en contactant les développeurs, voir cette récente requête: Wrong_datatype:History of Parliament ID. -- LaddΩ chat ;) 01:19, 15 August 2016 (UTC)

Gadget pour enlever les majuscules

Bonjour à tous,

Existe-t-il un gadget ou un script permettant d'enlever la majuscule du libellé (ou de la description ou des alias) d'un élément ? Je parle donc d'un outil pour le « cas par cas ».

Merci beaucoup, Tubezlob (🙋) 07:55, 17 August 2016 (UTC)

@Tubezlob: pas à ma connaissance et c'est bien dommage. Ceci dit, je fait énormément de retrait de capitale initiale en masse pour tout les cas évidents (j'ai fait 50 000 lacs la semaine dernière). Cdlt, VIGNERON (talk) 14:46, 17 August 2016 (UTC)
@VIGNERON: D'accord, merci. Pour tes lacs, tu utilises toujours la méthode que tu m'avais montré il y a quelques mois sur le bistro (requête → tableur → QuickStatements) ? Tubezlob (🙋) 08:29, 18 August 2016 (UTC)
@Tubezlob: tout à fait ; en l'occurrence, j'ai affiné la requête pour n'avoir que les éléments dont le label en français commence par « Lac » (et j'utilise la fonction REMPLACER plutôt que CONCATENER - trop lourde - de Calc) mais l'idée reste exctement la même. Cdlt, VIGNERON (talk) 08:44, 18 August 2016 (UTC)
@VIGNERON: OK, merci beaucoup ! Tubezlob (🙋) 08:47, 18 August 2016 (UTC)

Requête SPARQL

Bonjour, quelqu'un connaissant SPARQL pourait-il me fournir la requête permettant d'extraire toutes les valeurs de mean lifetime (P2645) de neutron (Q2348) dont la point in time (P585) ? En sortie, je voudrais que ça soit présenté de la manière suivante : « "year": P585,"mean": P2645,"lo": P2645 - incertitude,"hi": P2645 + incertitude}, » avec les années les unes à la suite des autres. Pour rendre les choses plus claires, je voudrais une requête qui me génère le code nécessaire à w:fr:Modèle:Désintégration du neutron libre/Durée de vie moyenne du neutron. Merci d'avance. Pamputt (talk) 10:20, 21 August 2016 (UTC)

@Pamputt: Je comprend pas tout. C'est les valeurs théoriques ou des valeurs d'une expérience ? Si je me fie a ton modèle wp, les années sont données en dur donc ça a l'air de se référer à une expérience donnée. Dans ce cas j'ai l'impression qu'il faudrait se référer à l'élément de l'expérience. Sinon si c'est les valeurs théoriques elles sont à calculer à partir d'une expression mathématique ? author  TomT0m / talk page 11:49, 21 August 2016 (UTC)
@TomT0m: en fait ces données sont des données évaluées tous les 2 ans par une organisation de physicien. Tous les deux ans, ces physiciens répertorient les résultats des expériencesdes dernières années et proposent une nouvelle valeur évaluée. Donc en gros, ce graph présente l'évolution des données évaluées en fonction de l'année. Pamputt (talk) 12:01, 21 August 2016 (UTC)
@Pamputt: Et c'est quoi les éléments concernés (les éléments dans lesquels il y a les déclarations) ? Les éléments des particules ? author  TomT0m / talk page 12:18, 21 August 2016 (UTC)
@TomT0m: non. Tout est dans neutron (Q2348). Je veux juste récupérer les valeurs de la propriété mean lifetime (P2645) de cet élément. Pamputt (talk) 12:22, 21 August 2016 (UTC)
@Pamputt: 
select ?date ?main_val ?upper ?lower where {
  wd:Q2348 p:P2645 ?measure_val .                   # get the set of all relevant statements of the relevant item, their values and qualifiers 
  
  ?measure_val psv:P2645 ?numeric_val .             # from the statement, get the detailed value (value, upper bound, lower bound and unit)
  ?measure_val pqv:P585 ?measure_date_val .         # get the date qualifier detailes value (date + precision + calendar)
  
  ?numeric_val wikibase:quantityUpperBound ?upper . # unpack the upper bound from the measure value
  ?numeric_val wikibase:quantityLowerBound ?lower . # same with lower
  ?numeric_val wikibase:quantityAmount  ?main_val .

  ?measure_date_val wikibase:timeValue ?date .

} order by ?date
Try it!

@TomT0m: Merci bien pour ton travail, ça fonctionne. Je vais maintenant essayer de récupérer ces valeurs pour créer automatiquement le graph. Pamputt (talk) 14:00, 21 August 2016 (UTC)

scenic viewpoint (Q6017969)

Bonjour. Comment relier un point de vue à ce qu'il permet d'observer ? Par exemple Washburn Point (Q26196531) → Half Dome (Q925252) ? Je crois qu'il n'y a pas de propriété mais je n'en suis pas sûr. Thierry Caro (talk) 16:46, 22 August 2016 (UTC)

Je suis assez sur qu'il n'y a pas de propriété sur le sujet. À ce que je vois, on aurait une propriété dont la nature de l'élément doit être un belvédère, une tour, un sommet ou un gratte-ciel ou l'un de leurs sous-classe et l'élément vu doit être un lieu ou une entité spatiale. J'imagine que c'est très faisable comme propriété. Si c'est refusé on peu toujours mettre: Washburn Point (Q26196531) instance of (P31) scenic viewpoint (Q6017969) --> de --> Half Dome (Q925252). --Fralambert (talk) 22:06, 22 August 2016 (UTC)
OK. Merci. Je n'avais même pas pensé à ta solution ! En effet. Je vais quand même songer à une nouvelle propriété. Thierry Caro (talk) 22:19, 22 August 2016 (UTC)
J'ai pensé que ça pourrait également être utile pour lier des extérieurs avec une pièce remarquable qui disposerait de fenêtres et donc j'ai élargi un petit peu avant de lancer Wikidata:Property proposal/offers view on. Merci encore. Thierry Caro (talk) 20:02, 23 August 2016 (UTC)
Il n'y a pas du tout de raison que ce soit refusé, c'est assez évident comme solution. La solution "nature de l'élément ... de ..." me semble assez mauvaise vu que c'est assez ambigu comme solution et que ce ne sera spécifié donc documenté environ nulle part. author  TomT0m / talk page 20:17, 23 August 2016 (UTC)

Liste de chefs d'État par année

Bonjour,

Voyant passer pas mal d'exemples super cool de requêtes SPARQL, je me suis dit que je m'y mettrais bien moi aussi. Après réflexion, mon choix s'est figé sur la réalisation d'une carte du monde montrant les divers chefs d'états pour une année donnée. Autrement dit, donner un visuel aux listes que l'on trouve dans w:fr:Catégorie:Liste_de_chefs_d'État_par_année.
J'ai vérifié que rien de similaire ne se trouve pas déjà dans mw:Wikibase/Indexing/SPARQL_Query_Examples ou Wikidata:List_of_queries.
Il ne me reste plus qu'à me lancer. Si jamais vous voulez participer ou juste donner des conseils, n'hésitez pas ! --Melderick (talk) 13:01, 26 August 2016 (UTC)

Yair rand en a fait un à Wikidata:Project_chat/Archive/2016/06#Which_countries_in_1754.3F. Actuellement il finit en timeout, mais il donne les éléments nécessaires. Peut-être en partent depuis mw:Wikibase/Indexing/SPARQL_Query_Examples#List_of_countries_in_1754
--- Jura 13:10, 26 August 2016 (UTC)
Oui j'avais vu cette requête, effectivement assez proche. Toutefois, je veux aller plus loin et récupérer les chefs de ces pays (et peut-être pas que des pays). Mais peut-être qu'en en demandant trop, ma requête va aussi finir en timeout ! --Melderick (talk) 13:41, 26 August 2016 (UTC)
Ii est partie des P39 .. mais comme il y a en a beaucoup, ça pourrait être plus simple de chercher d'abord les pays et ensuite les fonctions. Peut-être c'est même plus efficace de filtrer initialement sur les dates de décès des personnes que directement sur les dates de la fonction. Pour être certain qu'il y a un résultat, mieux vaut en saisir quelques-un avant.
--- Jura 13:50, 26 August 2016 (UTC)
Mes premières recherches montrent que j'aurai sûrement besoin de prendre à la fois les P39 et les P97, avec un filtre sur les fonctions (à voir quel filtre). Et entre la fonction et le pays/zone je pense utiliser P1001. Et oui, je sais déjà qu'il faudra compléter, remplir, lier pleins d'items avant que cela ne marche : même pas peur ! --Melderick (talk) 14:49, 26 August 2016 (UTC)
De mémoire, le query de Yair rand donnait un bon résultat. C'est juste devenu un problème de timeout.
--- Jura 15:45, 26 August 2016 (UTC)

Un élement wikidata curieux

Bonjour,

Je suis tombé sur une ville qui possède deux numéros Q, Grocka en Serbie. Les numéros sont Q2667895 et Q691992. En partant de la page en français (Q2667895), on peut passer de l'un à l'autre dans Wikipedia par l'anglais ou l'italien qui mènent au Q691992. Les autres langues semblent séparées et certaines mènent à des articles différents. Comment faire pour les fusionner (ou les séparer complètement) ? 


   ar غروتسكا
   bg Гроцка (община)
   bs Grocka
   de Grocka
   el Γκρότσκα
   en Grocka
   hr Grocka (općina)
   it Grocka
   ka გროცკის თემი
   ms Grocka
   nl Grocka
   no Grocka
   pl Grocka
   ru Гроцка (община)
   sh Opština Grocka
   sr Градска општина Гроцка
   tr Grocka
   zh 格羅茨卡

et 

   bg Гроцка
   fr Grocka
   hr Grocka
   ru Гроцка
   sh Гроцка
   sl Grocka
   sr Гроцка

Merci !

J'ajoute les langues visibles de la page Wikipedia en français : 

Български
Bosanski
Deutsch
English
Hrvatski
Italiano
Nederlands
Norsk bokmål
Polski
Русский
Srpskohrvatski / српскохрватски
Slovenščina
Српски / srpski
中文


et celles de l'anglais : 


   العربية
   Български
   Bosanski
   Deutsch
   Ελληνικά
   Hrvatski
   Italiano
   ქართული
   Bahasa Melayu
   Nederlands
   Norsk bokmål
   Polski
   Русский
   Српски / srpski
   Srpskohrvatski / српскохрватски
   Türkçe
   中文

Fortelle65 (talk) 13:08, 26 August 2016 (UTC)

Il y a Wikidata:Interwiki_conflicts pour y déposer ce genre de problème, notamment quand Help:Merge/fr n'aide pas.
L'approche générale est d'identifier les divers concepts qui pourraient être mêlés et de répartir les liens sur les éléments correspondants. Si besoin, en créer des nouvelles.
--- Jura 14:18, 26 August 2016 (UTC)
@Fortelle65: Grocka (Q2667895) est la localité, Grocka (Q691992) la commune : donc deux éléments Wikidata différents, et un problème fréquent qui empêche de passer de l'un à l'autre des articles Wikipédia quand certaines langues préfèrent avoir un article sur les localités et d'autres langues sur les communes (comportant souvent plusieurs localités). Oliv0 (talk) 12:46, 29 August 2016 (UTC)

Derniers éléments sans déclaration

Wikidata:Database reports/without claims by site/frwiki donne une liste des éléments les plus récents avec un lien à frwiki sans déclaration.

C'est un complément au rapport Wikidata:Database reports/items without claims categories/frwiki qui donne les catégories de tous les éléments liés à frwiki sans déclaration (actuellement 111 774 ou 5.2%).
--- Jura 12:19, 27 August 2016 (UTC)

Merci pour le partage ! Tubezlob (🙋) 08:32, 29 August 2016 (UTC)

Town, ville et bourg

Bonjour,

Pour je ne sais trop quelle raison, un interwiki et un schéma sans source sur WP:fr (aujourd'hui supprimé de Commons) traduisaient « town » par « bourg » alors que je n'ai rien trouvé de tel dans mes sources, qui m'indiquent, elles, « ville » (ou village, cas spécifique du Yukon). L'article « Ville » n'a pas été créé sur WP:fr car une page d'homonymie pour le statuts administratif/honorifique a été estimée suffisante (seul celui sur la ville en tant que milieu urbain existe). Cet interwiki a également provoqué un ajout des traductions de l'article « Bourg » sur en breton et en occitan sur Wikidata.

Comme cela ne correspond pas du tout aux sources, j'avais créé une entité séparée et ajouté l'article de WP:fr pour résoudre la confusion. Problème : les entités viennent d'être fusionnées sans prévenir et sans raison ! :/

J'ai un mal fou pour lire les diffs sur Wikidata. Quelqu'un peut-il me dire quelle est la justification pour cette fusion ? Et si il n'y en a pas de valable, comment rescinder les propriétés ? Feldo (talk) 12:02, 29 August 2016 (UTC)

Bonjour Feldo,
Le sujet semble subtil et complexe et je ne suis pas sur d'avoir tout compris (et j'imagine que le « fusionneur » non plus).
Ce qui est sur, c'est qu'il n'y a pas vraiment eu fusion (deux éléments fusionné en un seul) mais simplement retrait du lien vers la Wikipédia francophone (par toi) puis annulation de ce retrait (par Infovarius, avec un laconique commentaire « but where? » ; Infovarius can you elaborate on yout revert? It's strange but it seems that Feldo was right: this is two near but distinct concepts).
Une solution pour éviter que le lien vers fr:Bourg ne reviennent sur town (Q3957) est de lui créer un nouvel élément qui lui est propre.
Cdlt, VIGNERON (talk) 12:33, 29 August 2016 (UTC)
J'ai reverté Infovarius et créé large village (Q26714626). Oliv0 (talk) 13:14, 29 August 2016 (UTC)
Ok. Ce situation est dificile, je comprend. Faitez, que vous savez. --Infovarius (talk) 14:30, 29 August 2016 (UTC)
@VIGNERON, Oliv0: Il existait déjà un élément, town (Q13073067) (à l'époque "bourg"). N'était-il pas réutilisable ? Feldo (talk) 15:08, 29 August 2016 (UTC)
Je ne sais pas si town (Q13073067) était vraiment « bourg », il y avait juste un lien vers my:မြို့ (ne parlant pas le birman, difficile pour moi de dire si c'était plus « bourg » ou « ville »... en:wikt:မြို့ donne les deux...). Bon, en tout cas je me dis qu'il y a encore pas mal de boulot (je me rends compte qu'il y a énormément de termes qui sont plus ou moins proche, presque un millier en sous-classe de human settlement (Q486972) y compris des trucs qui me semble ne rien avoir à y faire comme olive grove (Q3350685)). Cdlt, VIGNERON (talk) 15:50, 29 August 2016 (UTC)

observatoire astronomique et observatoire

Bonjour.

L'article wiki en observatoire correspond exactement à l'article observatoire astronomique de la wiki fr. Or, ils se réfèrent à deux pages différentes sur wikidata, ce qui fait que les liens interwiki ne se font pas. Comment solutionner le problème ? Cordialement. Cedalyon (talk) 09:38, 21 August 2016 (UTC)

L'article anglais a été squatté par les volcanologues ..
--- Jura 10:43, 21 August 2016 (UTC)
@Cedalyon: L'article sur Wikipédia en anglais se réfère bien à la notion d'observatoire en général : il y a une partie sur les observatoires astronomiques, et une autres sur les observatoires volcanologiques (certes bien plus petite), alors que l'article en français ne parle que des observatoires astronomiques.
De notre côté, il ne faut donc rien fusionner : on a astronomical observatory (Q1254933) et volcano observatory (Q1778118) qui sont des sous-classes de observatory (Q62832).
Mais si c'était bien des articles désignant exactement le même sujet, il aurait fallu fusionner les éléments avec le gadget « merge » (voir les indications en haut de cette page, dans « Question fréquente »).
Tubezlob (🙋) 10:50, 21 August 2016 (UTC)
t Je suis extrêmement surpris que la wikipédia anglaise n'ai pas d'article dédié à la description des observatoires astronomiques. Ceci étant, l'article actuel en anglais correspondant tout de même à 95% à ce que dit le français, ne serait-il pas logique de les lier quand même ? Cedalyon (talk) 09:21, 22 August 2016 (UTC)
C'est pas surprenant du tout, c'est un symptome soit de al fusionnite, soit du "on ose pas créer un nouvel article", soit de la culture des wikipédias à limiter le nombre d'article (exemple, l'allergie aux articles courts). Vu que c'est pas du tout compatible avec Wikidata : 1 sujet = 1 élément, on se retrouve avec ce genre de souci. Sinon, il faut faire progresser WD:XLINK qui a pour but de trouver des solutions à ce type d'interwiki ;) . author  TomT0m / talk page 09:36, 22 August 2016 (UTC)
Oui, Wikidata n'est pas du tout adapté à la réalité de la connaissance humaine telle qu'elle est compilée par les différentes communautés humaines de part le monde. Mais ce n'est pas très surprenant, l'axiome 1 sujet = 1 élément est irréaliste dans le monde réel. Reste pour mon cas que vu l'état de l'article anglais, le mieux serait de faire quand même le lien avec le français, 90% du contenu correspond et cela éviterait l’aberration d'un article en français sur un sujet archi évident en impasse vers la wikipédia anglophone. Cette impasse est tout de même très gênante. Comment peut on faire ce lien ? A la main ? Cordialement. Cedalyon (talk) 06:46, 23 August 2016 (UTC)
l'axiome 1 sujet = 1 élément est irréaliste dans le monde réel => ça tombe bien, c'est pas le monde réel mais un modèle du monde. C'est pas irréaliste non, ça n'implique pas la complétude. Mais oui, tu peux toujours faire le lien à l'ancienne, c'est la solution préconnisée par les devs dans le plan initial. WD:XLINK propose d'automatiser un peu ça, mais ça manque de bras. author  TomT0m / talk page 18:29, 23 August 2016 (UTC)
Ah, on peut encore mettre des liens interwiki à la main, comme avant ? Je croyais qu'un bot les virais tous automatiquement. Cedalyon (talk) 06:42, 25 August 2016 (UTC)
@Cedalyon: Je suis pas au courant. Si c'est le cas faudrait peut être prévenir son dresseur :) Il y en a eu un pour la migration bien sur mais je crois que ça fait bien longtemps qu'il tourne plus. En tout cas ça me parait pas absurde de corriger les cas ou il y a redondances avec l'interwiki wd, mais dans le cas où il y a bien 1 élément pour l'article "source" de l'interwiki distinct de l'élément "cible" de l'interwiki, je crois pas que le bot puisse faire grand chose automatiquement. author  TomT0m / talk page 17:28, 25 August 2016 (UTC)

Je ne retrouve plus le modèle qui crée les liens interlangues dans les aide de wikipédia. Vous vous souvenez duquel il s'agissait ? Cedalyon (talk) 08:00, 29 August 2016 (UTC)

@Cedalyon: C'est sous cette forme :
[[en:Dog]]
[[de:Hund]]
[[la:Canis]]
On insère ce code en fin d'article.
Tubezlob (🙋) 08:29, 29 August 2016 (UTC)
Merci beaucoup. Cedalyon (talk) 15:56, 30 August 2016 (UTC)

Question sur les bases de données que l'on peut importer

Bonjour. J'ai apporté quelques contributions ces derniers temps dans le domaine de la généalogie des chevaux de sport. Je cherchais à savoir s'il est possible d'importer légalement certaines bases de données généalogiques équines :

La base de données Harasire est celle d'un organisme public (L'IFCE, Institut français du cheval et de l'équitation), mais je ne sais pas s'il est légal de les récupérer, là aussi :

(Note : si c'est possible, ce serait un superbe cadeau d'anniversaire en retard) D'avance merci pour la réponse, --Tsaag Valren (talk) 15:00, 29 August 2016 (UTC)

@Tsaag Valren: Bonjour. L'Ifce publie sur le site data.gouv.fr le jeu de données « fichier des équidés » qui a l'air de correspondre à ta recherche : équidés immatriculés en France depuis 1976 avec race, sexe, robe, date et pays de naissance, consommation humaine et date de mort ! De plus, ce fichier est mis à jour (dernière le 26 août). Il est disponible sous licence ouverte, donc les données peuvent être réutilisées.
Tubezlob (🙋) 16:18, 29 August 2016 (UTC)
Merci pour cette réponse très précise. Je ne vois pas l'utilité d'importer absolument toutes ces données sur WD, mais je pense que ce serait très utile pour avoir des informations fiables concernant les chevaux connus (de course, de sport, etc). Reste à savoir si l'on peut effectuer une distinction ? --Tsaag Valren (talk) 16:22, 29 August 2016 (UTC)
@Tsaag Valren:C'est vrai que le fichier présente plus de trois millions de chevaux. Je sais qu'il n'y a pas de limite de création d'élément sur Wikidata, mais créer trois millions d'élément risque de prendre beaucoup de temps (à vrai dire, je n'en sais rien). Pour faire la distinction, il n'y a pas d'informations supplémentaires sur les chevaux, donc cela me parait impossible.
J'ai l'impression que pour l'importation automatique, soit on fait tout, soit on fait rien.
Pour les autres bases de données, elles ont chacune des identifiants pour les chevaux que l'on pourrait créer comme propriétés.
Exemple avec Trêve (Q15052027) :
Tubezlob (🙋) 16:56, 29 August 2016 (UTC)
Aïe, le "tout ou rien" est assez dommage, car sur 3 millions de chevaux, il y en a peut-être que 100 000 de vraiment intéressants et/ou notables. Enfin, au choix, je préfère tout importer plutôt que rien. --Tsaag Valren (talk) 17:04, 29 August 2016 (UTC)
Salut Tubezlob et Tsaag Valren,
Déjà je rassure, l'import ce n'est pas tout ou rien ; on peut importer un peu ce que l'on veut comme l'on veut. Le problème de ne pas tout faire d'un coup, c'est que parfois il peut être compliqué de continuer après s'être arrêté (« qu'est-ce qui est déjà dans Wikidata ou non ? ») mais généralement rien d'insoluble (au pire, on a quelque cas que l'on n'exclut pour être traité à la main, et si ils sont nombreux on peu toujours se dire que tout ce qui est fait automatiquement n'est plus faire manuellement).
Pour les premières bases de données citées, les conditions d'utilisations ne sont pas claires, du coup, je crains que ce ne soit pas sous une licence compatible avec Wikidata. Si ces bases sont vraiment intéressantes, il y a effectivement la possibilité de demander la création d'une propriété identifiant externe pour faire un lien.
Je regarde de plus près le fichier IFCE qui semble prometteur mais je pense qu'il faudra quelqu'un de plus doué que moi en technique pour faire un import propre.
Cdlt, VIGNERON (talk) 17:26, 29 August 2016 (UTC)
Ordoncques, le fichier de l'IFCE est énorme (mon ordi a failli rendre l'âme plusieurs fois) mais finalement pas si énorme ; il y a un million de lignes (malgré les 3 millions annoncés, 1 048 576 exactement) mais seulement 8 colonnes. En plus, pas mal de cases sont vides (certaines lignes trop vides sont peut-être même à éliminer avant l'import).
De ce que j'en vois, ce sont des colonnes assez faciles à aligner avec Wikidata : nom dans le libellé, sexe dans sex or gender (P21), date de naissance dans date of death (P570), date de décès dans inception (P571), je ne vois pas de propriété correspondant pour la race et la robe mais cela doit pouvoir facilement se demander et s'obtenir ; à moins de mettre la race dans instance of (P31), je vois que c'est déjà parfois le cas (eg. Flambeau C (Q3073260)) mais je ne suis pas du tout sur que ce soit une bonne idée, je vois aussi une cinquantaine de chevaux avec color (P462) pour la robe mais là encore, je me demande si une propriété spécifique ne serait pas plus adaptée (et enfin, il y a les deux colonnes « Pays de naissance du cheval » et « Destiné à la consommation humaine » dont je ne vois pas trop l'utilité, la première me semble trop générale pour être pertinente et la seconde hors de propos... surtout que c'est presque toujours « oui » sauf pour 416 chevaux - tiens, pourquoi cela d'ailleurs ?). Le seul vrai problème que je ne vois pas trop comment résoudre est l'alignement les valeurs de la colonne race avec les identifiants Wikidata (ces valeurs sont-elles propres ? normalisées ?).
Cdlt, VIGNERON (talk) 17:57, 29 August 2016 (UTC)
@VIGNERON: Si il n'y a que 416 chevaux qui n'ont pas été envoyés à la boucherie, cela m'inquiète vraiment: les chevaux traités aux antibiotiques sont impropres à la consommation [4]. Or c'est le cas d'une grande partie des chevaux de course. Snipre (talk) 22:38, 29 August 2016 (UTC)

@Tsaag Valren, VIGNERON: Ça va être un sacré chantier, il va falloir mettre les moyens ! Tout d'abord, il faut faire une requête sur la page Wikidata:Bot requests en expliquant tout bien et en motivant ce choix pour que des utilisateurs expérimentés veuillent se mettre à la tâche. Les principaux problèmes actuels que j'ai trouvé sont :

  • la masse d'élément à créer (quand même un million)
  • comme le dit VIGNERON, faire correspondre le texte avec des éléments (ça va avec les robes et les pays, mais pour les races, c'est plus compliqué avec les abréviations)
  • les noms qu'il faut décapitaliser, et accentuer pour certains.

Enfin, je pense qu'il va falloir créer un WikiProjet sur les chevaux pour définir les lignes directrices et des actions coordonnées, parler des propriétés à créer, etc.

Pour la robe, je pense que l'on ne peut pas utiliser color (P462), étant donné que la robe est quand même quelque chose de bien spécifique (exemple : la robe « isabelle », c'est « des poils jaunâtres, des crins noirs, une peau noire et des yeux foncés. Le bas des membres, le bout du nez et le bout des oreilles sont noirs. ») qui peut être composée de plusieurs couleurs.

Pour ce qui est de la consommation humaine, je pense que ça n'a pas d'intérêt. Par contre, le pays de naissance me semble important d'être précisé (avec place of birth (P19)).

Pour les races, il va donc falloir établir un tableau à deux colonnes avec les abréviations du fichier de l'Ifce et leurs éléments Wikidata. Mais pour cela, je suppose qu'il faut bien s'y connaître en race de chevaux…

En tout cas, si le projet abouti, ce serait une sacrée réussite ! Tubezlob (🙋) 19:59, 29 August 2016 (UTC)

Ça marche. En effet la donnée "destiné à la consommation humaine" n'a aucun intérêt (cela signifie simplement que le cheval peut être abattu pour sa viande, pas qu'il l'a été), par contre je pense que la donnée pays de naissance peut être utile. Je m'y connais bien en races de chevaux, pas de soucis pour ça --Tsaag Valren (talk) 20:08, 29 August 2016 (UTC)
J'ai fait un essai sur Q26719877, voici le feedback :
  • On va avoir un problème pour définir la robe, en effet la nomenclature française (pour ne citer qu'elle) a évolué, et certaines dénominations ne sont plus utilisées. Par exemple, "Bai-brun" a été remplacé par "Noir pangaré". Il faudra bien distinguer le phénotype du génotype, car désormais les robes sont de plus en plus souvent décrites par génotype (ce qui a un intérêt évident puisqu'on peut prédire la robe du poulain à naître en fonction de celle de ses parents).
  • Pour les abréviations de races, ça se retrouvera très facilement car les sigles sont fixes : PS = Pur Sang ; SF = Selle français, etc. Il suffira de définir des équivalents.
  • A terme, l'un des buts serait de faire en sorte que la généalogie des chevaux soit entièrement gérée par Wikidata, afin qu'un changement ici se répercute sur toutes les versions linguistiques, bien sûr. J'imagine qu'il faudra créer un modèle. --Tsaag Valren (talk) 08:13, 30 August 2016 (UTC)
@Tsaag Valren, Tubezlob: donc je viens de regarder de plus près, en fait c'est juste que mon tableur bloque à un million, apparemment il y aurait 3,47 millions de lignes... Je voulais utiliser OpenRefine plutôt que le tableur Calc (qui est bien plus pratique pour manipuler ce genre de base de données) mais le fichier est trop gros, il va falloir que je fasses autrement (sans doute couper le fichier en sous-fichiers).
Tubezlob je suis d'accord avec la plupart de tes points (ah zut, les capitales, j'avais oublié ce point effectivement plutôt chiant) mais je suis pour la création d'un projet en premier pour discuter de la structure et faire des éléments showcase en exemple, ensuite la création des propriétés manquantes et enfin la demande d'import. Comme le dit Tsaag, je ne pense pas qu'il soit utile et pertinent de créer un élément pour chacun des chevaux, par contre, sur quel critère faire le tri ? Je me rends compte que le fichier data.gouv.fr ne contient pas les informations père/mère (qui sont elles pourtant très intéressantes, il faudrait voir si on peut les récupérer ailleurs). Il faudrait aussi en profiter pour faire une revue des 6642 chevaux ayant déjà un élément sur Wikidata.
Tsaag : j'ai regardé les valeurs de la colonnes races, ce n'est pas génial (des valeurs comme « *ANGLO-ARABE* » et « ANGLO-ARABE » - il y a une raison derrière cette distinction ou bien est-ce la même chose ? - ou « AUTRE QUE PS »... et tout un tas de sigles, genre « CAB. DEP. ESP. ») mais pas si terrible ; je me suis aussi rendu compte qu'il y a avait des ânes. Il suffira de faire un tableau pour faire la correspondance, il faudrait juste un projet pour en discuter et stocker les remarques. Idem pour les robes (d'ailleurs Tsaag, je n'ai pas bien compris ton interrogation, il suffit de suivre ce que dis la source, non ?).
Snipre tu confonds « destiné à la consommation » et « impropre à la consommation » (ce qui est proche mais qui en soi n'est pas incompatible), ceci dit cette colonne n'en reste pas moins très bizarre, l'exclure est plus prudent.
Cdlt, VIGNERON (talk) 08:39, 30 August 2016 (UTC)
Ha oui effectivement, j'avais oublié le coup des * et autres ajouts de lettres dans les noms... un *Anglo-arabe* est un cheval dont les ancêtres sont 100 % Arabes ou Pur-sang, sans aucun autre croisement. Par contre un Anglo-arabe sans les astérisques peut avoir été croisé avec autre-chose, ou ne dispose pas d'un pedigree connu sur suffisamment de temps. Il y a également une distinction Selle français A et Selle français, les premiers sont ceux qui n'ont jamais été croisés avec des chevaux d'origines étrangères depuis la création du stud-book en 1958. Autre que PS correspond à un stud-book, Q2873068. --Tsaag Valren (talk) 08:46, 30 August 2016 (UTC)
@Tsaag Valren, Tubezlob: Très bien. Créons donc en premier lieu le projet Wikidata:WikiProject Horses ! Le nom convient-il ? Sinon on pourrait mettre Wikidata:WikiProject Equids ou Wikidata:WikiProject Equidae (vu qu'il y aurait des ânes également). Tubezlob (🙋) 17:11, 30 August 2016 (UTC)
Je préfère personnellement Wikidata:WikiProject Equidae, mais les anglophones ont un projet intitulé Horses sur Wikipédia en. --Tsaag Valren (talk) 17:14, 30 August 2016 (UTC)
D'accord. Autant utiliser Horses, d'autant plus que les noms des projets sont traduisibles sur Wikidata. Tubezlob (🙋) 20:04, 30 August 2016 (UTC)
Je viens de faire des imports automatisés depuis fr:Modèle:Infobox Cheval : dates de naissance, propriétaires, images, etc. À noter qu'il existe Wikidata:WikiProject Q5/lists/riders and their horse grâce à la nouvelle propriété mount (P3091). Thierry Caro (talk) 21:43, 30 August 2016 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Bistro/Archive/2016/08&oldid=2029381850"