Wikidata

Wikidata:Bistro/Archive/2014/09

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

Grants to improve your project

Apologies for English. Please help translate this message.

Greetings! The Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. Your idea could improve Wikimedia projects with a new tool or gadget, a better process to support community-building on your wiki, research on an important issue, or something else we haven't thought of yet. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to hiring others to help you.

identifiant TNA

Bonjour, existe-t-il une propriété pour les identifiants (références) de The National Archives (Q392703) ? Cordialement, Reptilien.19831209BE1 (talk) 14:45, 5 September 2014 (UTC)

Je n'en trouve pas. LaddΩ chat ;) 11:44, 6 September 2014 (UTC)

Nouveau Wikiprojet : Names

Bonjour,

Je voulais annoncer que @Harmonia_Amanda: et moi-même avons lancé un nouveau projet sobrement intitulé « Names » centré sur les noms des personnes (pardon, des human (Q5)), avec pour but de mieux renseigner les différentes propriétés liées à l'identité des gens. J'en profite pour signaler que j'ai rédigé sur mon blog un billet donnant quelques explications sur la méthode à appliquer. -Ash Crow (talk) 17:45, 5 September 2014 (UTC)

Bonne initiative !
J'ai ajouté le prénom Pablo à Pau Casals (Q208537). Du coup, il a deux prénoms - tous les deux attestés dans les sources. C'est bon ? --El Caro (talk) 19:11, 5 September 2014 (UTC)
Pablo semble être son nom d'artiste et Pau son prénom de naissance. Un peu comme Plume Latraverse (Q3392637) dont son véritable nom est Michel Latraverse. --Fralambert (talk) 19:35, 5 September 2014 (UTC)
Je réalise qu'il ne semble pas avoir de propriété «nom d'artiste». Utile pour le milieu de arts et parfois de la politique. --Fralambert (talk) 19:44, 5 September 2014 (UTC)
@El Caro: Ce que tu as fait est bon, par contre l'entrée Pablo (Q2045138) devrait être scindée en deux voire trois entités entre prénom, nom de famille et probablement page d'homonymie... @Fralambert: si si, la propriété existe, elle s'appelle pseudonym (P742) (j'ai ajouté « nom de plume » et « nom d'artiste » en alias, du coup...) -Ash Crow (talk) 23:19, 5 September 2014 (UTC)
OK, merci. (Juste une petite précision pour Fralambert : Pablo/Pau n'est pas tant une histoire de nom d'artiste qu'une distinction entre le même prénom en version espagnole ou catalane). --El Caro (talk) 06:56, 6 September 2014 (UTC)

Propriété : classement

Bonjour,

Sur tous les monuments historiques que j'ai vu sur wikidata, la qualité Historical Monument (Q916475) était dans la propriété "nature de l'élément". Pas terrible à mon avis. Par exemple, la nature de Gare de Meudon (Q2848177) est bien d'être une gare, pas d'être un monument historique inscrit (Q10387575). N'existe-t-il pas une propriété "classement" ou aparentée ? Sinon, je pense qu'il faudrait la créer. --El Caro (talk) 06:53, 6 September 2014 (UTC)

@El Caro: on en parle justement en ce moment avec Fralambert et Ayack sur Property talk:P380 ! On a globalement le même avis que toi et on pense passer tout les instance of (P31) en heritage designation (P1435) (ce qui est mieux même si pas totalement satisfaisant selon moi). Cdlt, VIGNERON (talk) 07:43, 6 September 2014 (UTC)
L'un n'empêche pas l'autre, on en discute aussi (longuement) Wikidata:Bot_requests. En fait instance of (P31) est labellisée "nature" en français, mais c'est surtout une propriété, dans l'esprit, qui sert à lier un élément d'une classe d'objet ou d'éléments à une classe d'éléments qui ont la même propriété. Le fait d'être un monument historique ou de posséder un statut patrimonial peut être parfaitement légitime pour créer une classe, dans cet esprit. Dans cet esprit la propriété "statut patrimonial" peut être utilisée pour spécifié précisément le statut légal, et les différentes classes de monument historiques peuvent être utilisées pour classer les monuments historiques d'après d'autres critères, hiérarchiquement par exemple : monument classé (n'importe quel statut) français, ...
Les classes ont d'autres usages que de donner l'usage principal d'un bâtiment, par exemple, elles peuvent être utilisées pour définir quel type de valeur on attend pour une propriété donnée, ou sur quel type d'item on attend la présence d'une propriété. TomT0m (talk) 12:18, 6 September 2014 (UTC)
@TomT0m: effectivement, la formulation du label de instance of (P31) n’est pas très heureuse. Mais au-delà de ce « problème », P31 me semble problématique. Il semble indiquer qu'un élément est un monument historique. Alors qu'un élément *n'est pas* un monument historique ! Un élément est protégé au titre des monuments historiques, il y a appartenance et non identité (et en cela heritage designation (P1435) me semble faire la même confusion). Ce serait un peu comme de dire que Victor Hugo (Q535) est (instance of (P31)) Hugo (Q14626498) au lieu d'utiliser family name (P734)…
Il ne faut pas oublier que « monument historique » *est* d’abord un statut légal (4 statuts assez différents en fait) et qu’au final, ce sont quelques bouts de papier stockés dans une administration culturelle qui dit « l’État reconnait l’intérêt de X et lui octroie des droits et des devoirs en conséquence ».
Au passage, un grand nombre des Historical Monument (Q916475) ne sont pas vraiment des monuments (quelques exemples parmi de nombreux autres Général Leclerc (Q3123065) ou Pleumeur-Bodou satellite telecommunication centre (Q2945516)) et un certain nombre ne sont pas vraiment historique (~20 % ont moins de 100 ans) et on ne peut pas utiliser un système de classes ici sans générer plus de faux-positifs que de vrais résultats.
Cdlt, VIGNERON (talk) 13:02, 6 September 2014 (UTC)
J'ai créé Wikidata:WikiProject France/Monuments historiques (dont on parlais depuis des mois) et j'ai déjà lancé trois trolls discussions ; suite de la discussion là-bas. Cdlt, VIGNERON (talk) 15:58, 6 September 2014 (UTC)

Trouvaille: comment personnaliser la liste des langues de la section « Autres langues »

Je viens de trouver un truc que j'aimerais partager. Désolé pour ceux qui connaissaient l'astuce. Cette question a été posée par le passé et je n'avais à cette époque jamais vu de réponses. J'ai enfin trouvé comment personnaliser la liste des langues des libellés qui apparaissent en haut d'une entrée Wikidata (section intitulée « Autres langues »). C'est en général bien pratique pour mettre à jour en quelques copier-collers les libellés d'autres langues. Il suffit d'ajouter dans votre page utilisateur le modèle Babel avec les langues que vous souhaiter voir afficher dans chaque entrée Wikidata. Je ne parle par exemple pas un mot d'espagnol, mais le simple fait d'ajouter l'espagnol dans le modèle a automatiquement ajouté cette langue dans la section « Autres langues » de chaque entrée Wikidata. Voilà. Bonne continuation. --Deansfa (talk) 01:58, 9 September 2014 (UTC)

Change in renaming process

Single-user login (SUL) finalisation's goal is so that every Wikimedia editor has a single, recognized global account with one username across all projects. As you may know, after a long delay, it's now underway as an effort between bureaucrats, stewards, and Wikimedia Foundation engineers. This will also allow for development of cross-wiki tools like global notifications and watchlists. There is no set date for the completion of single-user login finalization at this time.

The process involves changing all rename processes into one global renaming process. The ability for local bureaucrats to rename users on this wiki will be turned off on Monday, 15 September 2014, as one of the first steps. Global renamers are in the process of being created to make sure projects and languages are represented by the time this occurs. I sent a note to every bureaucrat about this process three weeks ago with an invitation to participate and many have begun requesting to be a part of the group. Together with the stewards, the global renamers will be empowered to help editors work through the often difficult process of getting a global name.

In parting, visit Special:MergeAccount to unify your account if you have never done so. If your local pages about renaming still need to be updated, please do so and consider pointing people to m:SRUC for future rename requests, especially if this project does not have bureaucrats that hold global renamer permissions. If you have any questions, you can read more on the help page on Meta. You can also follow the technical progress on mediawiki.org. Contact me on Meta any time with questions as well. Thank you for your time.

-- User:Keegan (WMF) (talk) 16:23, 9 September 2014 (UTC)

  Voir une traduction au Bistro de Wikipédia. --Eric-92 (talk) 03:28, 10 September 2014 (UTC)

Pont des arts, un ou deux éléments

Je suis tombé sur un drôle de cas avec le pont des Arts (Q1329141). Le pont s'est effondré en 1979, puis a été reconstruit. Il paraitrait donc logique de faire deux éléments, un pour l'ancien pont, un pour le nouveau. Mais d'un autre côté, le pont est classé monument historique en vertu d'un arrêté de 1975. Du coup on se retrouverait un monument classé avant d'avoir été construit. On a le même problème pour official name (P1448). Du coup on fait quoi, un élément pour chaque point, plus un pour les deux à la fois ? Je ne suis pas sûr que ce soit très pratique. --Zolo (talk) 15:19, 12 September 2014 (UTC)

Bonjour Zolo,
Oulà, pas simple cette histoire. Surtout qu'à la lecture de l'article on apprend que le pont a été reconstruit à l'identique mais que des modifications assez importantes ont été apportées...
Je partirais quand même sur deux éléments car il y a des choses différentes à indiquer sur chaque élément (architecte, nombre d'arches, date de construction/d'inauguration, etc.).
Pour les déclarations communes aux deux versions du pont (notamment : protection, nom), je ferais un troisième élément chapeau pour y placer ces déclarations et qui je relierais à l'article WP (qui parle des deux versions du pont).
Je ne suis pas moi-même entièrement convaincu par ma proposition mais vu que le cas est très particulier, je ne vois pas mieux pour le moment.
Cdlt, VIGNERON (talk) 16:10, 12 September 2014 (UTC)
PS: c'est le genre de question qui aurait pu aller sur Wikidata talk:WikiProject France/Monuments historiques   (où justement un cas différent a été résolu de façon similaire).
On peut également faire une seule entrée mais avec des qualifieurs date de début/de fin sur les éléments qui varient. -Ash Crow (talk) 10:58, 13 September 2014 (UTC)
On pourrait mais il me semble que ce ne serait pas vraiment pratique et cela risque de générer des violations de contrainte (construire deux fois un pont ou avoir deux dimensions différentes ce n'est pas exactement « normal »). Cdlt, VIGNERON (talk) 13:03, 13 September 2014 (UTC)
Je serais enclin à proposer la création de deux items et :
  • soit d'un troisième item qui les fédère, un peu comme pour un cycle de romans :
    • sur le nouvel item : instance of series / qualifier of bridge / has part pont 1, pont 2
    • sur l'item de destination : series le nouvel item
  • soit de l'ajout de la propriété sur chacun des deux items said to be the same : l'autre poont
--Dereckson (talk) 13:28, 13 September 2014 (UTC)
Je rejoins Dereckson et VIGNERON qu'il devrait avoir deux éléments, soit pour l'ancien et le nouveau pont. Pour le classement, je le mettrais sur le pont de destination (même si ça fait ridicule). Pour l'ancien pont je mettrait à la limite le classement en valeur dépréciée. --Fralambert (talk) 15:56, 13 September 2014 (UTC)
Selon Property_talk:P1366, les deux items devraient être reliés par structure replaces (P1398) (pas de propriété inverse, contrairement à replaces (P1365) et replaced by (P1366)). LaddΩ chat ;) 19:09, 13 September 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Merci pour vos réponses. J'ai donc créé Q18048386 pour l'ancienne passerelle et Q18048389 pour la nouvelle. J'ai gardé Q1329141 avec les liens Wikipédia pour les deux à la fois. Je reste embêté pour le classement MH. @Fralambert:, mettre "monument historique, rang = déprécié", sur l'ancien monument me parait problématique. Le rang déprécié est normalement utilisé pour les affirmations fausses, pas pour les affirmations dépassées. "François Hollande : député de Corrèze" ne devrait pas avoir le rang déprécié, il devrait avoir le rang normal (contre "preferred" pour "président de la République), et une date de fin pour que l'on sache jusqu'à quand c'est valable. Et puis aussi, en y pensant, il n'y a eu qu'un seul arrêté de classement, donc logiquement, un seul monument historique. Du coup, peut-être qu'il faudrait mettre le classement MH sur l'élément chapeau ? --Zolo (talk) 14:41, 15 September 2014 (UTC)
Oh et puis complètement un autre sujet mais Wikipédia dit que les ingénieurs sont Louis-Alexandre de Cessart et Jacques Vincent de Lacroix Dillon alors que le dictionnaire administratif des rues de Paris, utilisé comme source ailleurs dans l'article parle d'un Demoutier. Mérimée ne parle de Dillon (et d'Arretche mais c'est le pont de 1984). Quelqu'un sait ? --Zolo (talk) 14:54, 15 September 2014 (UTC)

@Zolo: Dernier commentaires: j'ai ajouté un ou deux significant event (P793) sur les deux nouveaux éléments, plusieurs autres pourraient s'appliquer, voir la page de discussion de cette propriété. D'autre part, il faudrait lier les deux items à leur item "chapeau", Pont des Arts (Q1329141). Je suggère soit:
  1. d'en faire des spécialisations, en en faisant des subclass of (P279) Pont des Arts (Q1329141), ou
  2. d'en faire des parties, en en faisant des part of (P361) Pont des Arts (Q1329141), ce qui permet la relation inverse has part(s) (P527).
Il existe peut-être d'autres possibilités, ce n'est pas ma spécialité. Au choix. - LaddΩ chat ;) 02:35, 16 September 2014 (UTC)
Oui en fait je me demandais comment mettre le chapeau sur la tête des chapeautés. Si l'on considère que l'article général se réfère à un groupe de deux ponts, il faut certainement utiliser part of (P361), mais je me demande s'il ne faudrait pas voir les choses un peu différemment : les deux nouveaux éléments désignerait des structures architecturales alors que (Q1329141 désignerait une voie de communication qui existerait indépendamment des bâtiments individuels. La distinction peut paraître artificielle, mais ça me parait la manière la plus logique de justifier l'existence d'un pont des arts monuments historiques, même à l'époque où il n'y avait plus de pont, ou l'existence de cette fiche de la mairie de Paris qui parle du pont des Arts comme s'il n'avait jamais cessé d'exister depuis 1801. Dans ce cas, et même si ça parait un peu étrange, il me semble que la propriété à utiliser serait located on street (P669) (le pont des Arts est un bâtiment situé sur le pont des Arts...). --Zolo (talk) 07:10, 16 September 2014 (UTC)
part of (P361) me semble bien (et pas si artificiel). Personnellement, je pensais plutôt utiliser les propriétés replaces (P1365)/replaced by (P1366) (il faudrait uniformiser les noms d’ailleurs) mais la solution de Zolo me paraît aussi bien sinon meilleure (à moins que l’on applique les deux à la fois ?). En tout cas, subclass of (P279) ne me paraît pas adapté. De toute façon, la situation étant particulièrement compliquée, il n’y a pas vraiment de solution parfaite… Question un peu piège : lequel des trois éléments utilisés ailleurs dans Wikidata ? (par exemple, je vois que Jean Jules Henri Mordacq (Q784891) a été retrouvé mort sous ce pont) le chapeau ou le sous-élément spécifique ? Cdlt, VIGNERON (talk) 16:02, 16 September 2014 (UTC)
Pour Jean Jules Henri Mordacq (Q784891) c'est assez simple, il est mort sous le pont original. Il n'y a pas de solution miracle, mais l'avantage, est que il s'agit probablement d'un cas unique. La plupart du temps, la classement s’éteint avec la destruction du monument. Le seul autre exemple qui me vient à l'esprit est le Moulin à vent de Trois-Rivières (Q3325851) qui a été déménagé en 1975. Mais je ne pense pas que deux éléments soit nécessaire dans ce cas. --Fralambert (talk) 23:02, 16 September 2014 (UTC)
Mais si le classement s'est éteint avec le bâtiment original (ce qui paraitrait logique), comme le nouveau s'est-il retrouvé monument historique ? -Zolo (talk) 08:32, 17 September 2014 (UTC)
C'est le genre de truc qui me rappelle que le classement est un geste politique. En passant, j'ai trouvé un exemple québécois assez amusant, la maison de Saint-Hubert a été classée l'année même de sa reconstruction. :p --Fralambert (talk) 12:30, 17 September 2014 (UTC)
Zolo : la protection (classement ou inscription pour les MHs) s'éteint généralement mais pas toujours avec la disparition de l'objet protégé. C'est effectivement politique mais cela aussi un rôle (officieusement) dissuasif contre ceux qui voudraient détruire un MH. C'est pourquoi même une fois le bâtiment détruit, les contraintes (notamment urbanistiques) restent (si un vil promoteur voulait construire un immeuble moderne à proximité, c'est raté pour lui :P). Il y aussi souvent l'espoir de reconstruire « à l'identique » (je pense notamment au Pavillon Baltard (Q3373009) déconstruit et reconstruit plus loin). En l'occurrence, le pont n'a pas été totalement détruit, une (grande ?) partie du pont « version 1 » subsiste dans le pont « version 2 » (il y a d'ailleurs eu entre-deux une « version 1bis » intermédiaire). Cela explique le conservation de la protection.
D'ailleurs, il y a parfois des modifications importantes d'un bâtiment et pourtant la protection reste (pour les MHs en France, on peut notamment penser à Viollet-le-Duc). En France aussi on a des protections dans des temps très courts après la construction pour des raisons « politiques » (comme la Maison à Bordeaux (Q3278843) protégée 4 ans après sa construction).
@Laddo : après réflexion, il me semble que subclass of (P279) ne convient pas car l'élément « chapeau » n'est pas une classe.
Cdlt, VIGNERON (talk) 07:35, 18 September 2014 (UTC)

Un simple petite question proche du sujet: le Boucher-De Niverville Manor (Q3286114) comprend une protection area (Q17611549) de 152 m de rayon qui inclus au moins trois autres articles, soit la Assumption Cathedral (Q2942861), Édifice Ameau (Q16707849) et le Musée Pop (Q3330771). Donc j'imagine que je devrai créer un élément pour l'aire de protection relié le manoir avec part of (P361)/has part(s) (P527) et relié les autres bâtiments à l'aire de protection à l'aide de P1134 (P1134) (C'est la façon que je relie un monument à un site)? --Fralambert (talk) 04:00, 18 September 2014 (UTC)

Fralambert : oui, cela me semble la bonne façon de faire. Cdlt, VIGNERON (talk) 07:35, 18 September 2014 (UTC)
  Done VIGNERON fait avec 18076718‎ Je ne sait pas si j'ai bien fait, mais j'ai inversé part of (P361)/has part(s) (P527), étant donné que l'aire de protection est subordonnée au monument. --Fralambert (talk) 02:42, 19 September 2014 (UTC)
@VIGNERON: ok, ça me conforte dans l'idée que le classement MH devrait aller à l'élément chapeau, et que celui-ci devrait désigner autre chose qu'un groupe de pont.
@Fralambert:. Si Boucher-De Niverville Manor (Q3286114) ne se réfère qu'au bâtiment, je ne pense pas qu'on puisse dire que l'aire de protection du manoir soit une partie du manoir. Une partie doit être plus petite que le tout. En fait je pense qu'il vaut mieux n'utiliser has part(s) (P527) que pour donner une liste complète des parties de l'élément (donc dans ce cas, ce serait composé de manoir + aire de protection sans le manoir). --Zolo (talk) 07:16, 19 September 2014 (UTC)
@Zolo: Je pense finalement que tu as raison, je me suis rappelé que les maisons de la rue Jeanne-Mance à Montréal (groupe de 16 inscriptions individuelles) bénéficie toute de la même aire de protection. --Fralambert (talk) 13:08, 19 September 2014 (UTC)
@Fralambert, Zolo: l'aire n'est pas vraiment une partie du manoir (encore que…) mais elle en est très certainement issu. On n'a pas une propriété comme « issu de » ou « généré par » ? Cdlt, VIGNERON (talk) 08:43, 20 September 2014 (UTC)

Pays Loire-Angers

Bonjour. Peu coutumier de Wikidata, question à propos d'une intercommunalité française (Maine-et-Loire) : le syndicat mixte Pays Loire-Angers a changé de nom en 2013, pour être maintenant dénommé Pôle métropolitain Loire Angers (voir sur fr.wikipedia). Question, la donnée Q3373327 (Pays Loire-Angers) doit-elle être changée, ou une nouvelle créée ? Cordialement --Franck-fnba (talk) 17:50, 12 September 2014 (UTC)

C'est un simple changement de nom ou y a t il également transfert de compétences ? --Dereckson (talk) 00:55, 13 September 2014 (UTC)
Bonjour Dereckson. C'est juste un changement de nom, ce pourquoi la page wp-fr avait été renommée. Cordialement --Franck-fnba (talk) 04:53, 13 September 2014 (UTC)
Bonjour Franck-fnba : dans ce cas, il « suffit » de « renommer » l’élément, c'est-à-dire de changer le label. Tu peux aussi ajouter une propriété pour indiquer l’ancien nom officiel (official name (P1448)). Je te conseille d'essayer Wikidata:Visites guidées pour mieux découvrir Wikidata).
@Dereckson : même avec transfert de compétence, je ne vois pas trop ce que cela change (pas de séparation en plusieurs éléments contrairement au cas de la section ci-dessus).
Cdlt, VIGNERON (talk) 09:21, 13 September 2014 (UTC)
Bonjour Dereckson & VIGNERON. …il « suffit », même après le tuto, j'ai pas tout compris. Si vous voulez bien faire la manip, je la regarderais avec beaucoup d'attention. Merci à vous. Cordialement --Franck-fnba (talk) 11:30, 13 September 2014 (UTC)
Je viens de faire ça ainsi que quelques autres ajouts rapides. Si tu as des questions, n'hésite pas ! Cdlt, VIGNERON (talk) 12:43, 13 September 2014 (UTC)
Je visais :
  • le cas simple de création de nouvelles entités qui remplacent les anciennes, dont une correspond quasi à une des anciennes ;
  • le cas plus complexe d'une mutation par exemple pour des entreprises par fusion / acquisition (je n'ai pas d'exemple précis pour des institutions publiques, fusion de communes mis à part, où là on tombe dans le cas précédent), où il pourrait être plus pratique de créer un nouvel élément plutôt que de garder le même élément, pour pouvoir parler de la notion d'avant la fusion, et celle d'après. Même si c'est toujours le même élément, il pourrait s'agir de deux notions différentes.
Franck-fnba, comme tu le remarques d'après dans ce diff de VIGNERON, pour renommer un article tu modifies le label tout en haut : [1]. Si tu n'as pas accès au label en français, tu peux :
  • soit passer via la barre du haut la langue en français (ou rajouter ?setlang=fr dans l'URL) ;
  • soit rajouter {{#babel:en-3|fr}} sur ta page utilisateur (où tu remplaces en-3 par ton niveau d'anglais, m:User language pour la documentation) pour avoir accès au label français si tu préferes garder l'interface de Wikidata en anglais
--Dereckson (talk) 13:21, 13 September 2014 (UTC)

@ Dereckson & VIGNERON. Merci de vos retours/manips/explications. Après avoir regardé attentivement tous les diff j'y vois maintenant bien plus clair. Je garde tout ça sous le coude pour les prochaines fois. Bien cordialement à vous deux --Franck-fnba (talk) 13:57, 13 September 2014 (UTC)

Fusion Art olmèque

Bonjour j'aimerai fuionner Q16488887 (Arte olmeca(es)) dans Q2864715 (Art olmèque(fr)), malheureusement il existe un lien entre "Art Olmèque(fr)" et "Rostros de bebé(es)". Ni les modifications de liens, ni les suppressions, ni les déplacements (move), ni les fusions (merge) ne fonctionent ou du moins je n'arrive pas à les faire fonctionner. Quelq'un pourrait-il m'expliquer comment faire?
Merci --Domingue (talk) 15:20, 14 September 2014 (UTC)

Ah, tu viens de trouver un cas où par le biais de redirections ou de choix maladroits d'interwiki, un item de Wikidata parle de deux notions. Ici, l'art olmèque d'une part, les Rostros de bebé d'autre part.
Dans ce genre de cas, il faut scinder les deux notions, un item pour l'art, un autre pour le type de figurines.
La marche à suivre est de retirer les liens hors sujet de l'un pour les rajouter sur l'autres. Et d'ensuite vérifier les labels dans chaque langue.
--Dereckson (talk) 15:53, 14 September 2014 (UTC)
Vu l'identifiant Freebase /m/01xht5 qui correspond à en:Olmec figurine, le plus simple ici est d'utiliser Olmec figurine (Q2864715) pour le type de figurines et Olmec art (Q16488887) pour l'art olmèque. --Dereckson (talk) 15:55, 14 September 2014 (UTC)
Voilà, je m'en suis chargé. Dans la foulée, j'ai décrit les divers items sur les types d'arts précolombiens. --Dereckson (talk) 20:35, 15 September 2014 (UTC)
Ah, au fait, Rostros de bebé est sur un item à part, Olmec "baby-face" figurine (Q18048233), subclass of Olmec figurine (Q2864715). --Dereckson (talk) 20:38, 15 September 2014 (UTC
Merci. Il n'y avait plus de lien sur la page Rostros de bebé alors qu'il existait un lien sur la page Olmec figurine qui renvoyait à Rostros de bebé; je l'ai recréé. --Domingue (talk) 14:06, 17 September 2014 (UTC)

Fusion

Bonsoir, je n'arrive pas à fusionner l'id Q16946812 vers Q940025 (même personne), à chaque essai j'ai le message suivant : « Impossible de fusionner les éléments. L'erreur suivante s'est produite : <Conflicting labels for language ht> ». Merci d'avance si vous pouvez m'indiquer ce que je dois faire pour que ça fonctionne --Arsendis (talk) 19:08, 14 September 2014 (UTC)

@Arsendis:. J'ai terminé la fusion même si il semble que tu avais presque réussi. Je ne sais pas ce qui a pu posé problème. Pamputt (talk) 19:48, 14 September 2014 (UTC)
merci --Arsendis (talk) 20:03, 14 September 2014 (UTC)
La difficulté venait apparemment de l'existence de libellés différents en langue "ht", l'outil ne savait pas laquelle choisir. @Pamputt, Fralambert:, maintenant que c'est possible il vaut mieux rediriger les éléments en doublon plutôt que de les supprimer. -Zolo (talk) 07:27, 16 September 2014 (UTC)
Digression @Zolo: pourquoi est-ce mieux de rediriger ? Les redirections servent habituellement à retrouver une page malgré des titres multiples mais les alias assurent déjà ce rôle sur Wikidata. Y a-t-il une autre utilité ? Cdlt, VIGNERON (talk) 16:08, 16 September 2014 (UTC)
@VIGNERON: Les items de redirections sont complètement vides, donc à peu près invisible depuis Wikidata. En eux mêmes ils ne servent à rien, mais les données de Wikidata sont faites pour être utilisées par d'autres sites, et on ne sait jamais exactement ce qu'ils utilisent. Si quelqu'un quelque part utilise Q16946812, supprimer l'élément peut lui poser des problèmes, alors que le rediriger en pose beaucoup moins. Par exemple je crois que VIAF envisage de lier ses entrées avec celles de Wikidata, si elle lie à un élément en doublon, et qu'on le supprime au lieu de le rediriger, ça ne va plus marcher. --Zolo (talk) 17:11, 16 September 2014 (UTC)
@Zolo: ah ok évidemment ; merci de ta prompte et éclairante réponse. Question subsidiaire : comment fait-on une redirection dans l'espace principal ? Cdlt, VIGNERON (talk) 17:48, 16 September 2014 (UTC)
tout à fait, même si VIAF, tout comme la BNF, et d'autres bases d'autorités ne se gênent pas, eux, pour supprimer les identifiants une fois qu'ils ont fusionnés des valeurs (clusterisé en jargon VIAF) - ce qui impose de faire le ménage des valeurs devenues invalides ;) --Hsarrazin (talk) 20:42, 16 September 2014 (UTC)
@VIGNERON:. Il faut utiliser le gadget merge. Dans le menu de fusion, il y a une option "créer une redirection" à cocher (en fait il faudrait peut-être qu'elle soit cochée par défaut). --Zolo (talk) 07:22, 17 September 2014 (UTC)
@Zolo: ok merci (du coup, je vais toujours utiliser le gadget Merge même pour les cas triviaux, ce sera plus simple). Il y a une autre façon de faire ? (par exemple pour revenir sur les éléments déjà supprimés ?). Cdlt, VIGNERON (talk) 09:53, 17 September 2014 (UTC)
@VIGNERON: en fait, les redirects ne peuvent pour l'instant être créés que pour l'API, pas par l'utilisateur normal. Du coup il faut passer par des gadgets comme merge. La gestion des redirects doit être un jour intégrée à l'interface standard, mais en pratique, je ne pense pas que ça changera grand chose par rapport à merge. Pour revenir sur les éléments déjà supprimés, je pense qu'il faut d'abord les restaurer. On peut imaginer un bot-admin qui les fasse tous, mais ce n'est pas forcément évident. --Zolo (talk) 10:01, 17 September 2014 (UTC)

Merci pour toutes ces précisions ; j'ai plusieurs cas similaires de doublons transformés en redirection sur htwp, impossibles à fusionner sur Wikidata. J'ai testé la redirection avec le gadget merge, ça fonctionne et c'est très simple à utiliser. Encore merci, --Arsendis (talk) 10:05, 17 September 2014 (UTC)

Les séries télévisées

Salut, Je voulais sur l'article principal de la série insérer les différents liens vers les articles Saison X de XY. Sauf que je ne trouve rien qui me permettrait de l'insérer. Pour les albums de musique, il existe liste des chansons. Ce serait histoire ici de liste des saisons. --Mikani (talk) 14:16, 16 September 2014 (UTC)

@Mikani: Je ne pense pas qu'une nouvelle propriété soit nécessaire. L'ajouterais has part(s) (P527) (faire une liste des saisons) et part of (P361) de la saison vers la série. --Fralambert (talk) 14:26, 16 September 2014 (UTC)
Merci Fralambert. --Mikani (talk) 14:56, 16 September 2014 (UTC)
J'allais répondre quasiment la même chose. Le même schéma est applicable pour série / saisons et pour saison / épisodes. Cdlt, VIGNERON (talk) 15:03, 16 September 2014 (UTC)
Nickel ce que tu as fait pour les saisons. En revanche, l'item concernant la liste des épisodes n'est pas une partie de la série. Essaye de raisonner en terme d'objets et de containers, pas d'articles WP :
La série a plusieurs parties, correspondant à chaque saison. La liste des épisodes ne s'ajoutent pas à la chose.
(en règle générale, sur le projet fiction, les items liste d'un projet Wikimedia et pages d'homonymie ne servent pas de propriété pour décrire l'univers ou l'œuvre de fictio
En revanche, il est possible de décrire la liste pour indiquer qu'elle contient des épisodes de la série grâce à is a list of (P360) et le cas échéant, à of (P642) comme qualifier, cf. ce diff.
--Dereckson (talk) 11:47, 17 September 2014 (UTC)
C'est un peu compliqué pour utiliser liste de étant donné que dans un certain idéal liste de est supposé être utilisé pour les articles de listes, qui sont (dans l'idéal) être supposés être des artefacts wikipédiens.
Pour les saisons, j'ai tenté de pousser la création d'une propriété sous suite de, parce que si une série est constituée d'une séquence d'épisode, une saison est une partie de cette série, sans succès pour l'instant mais je désespère pas :)
Sinon la convention adoptée jusqu'à présent pour les séries c'est d'utiliser les qualificatifs précédé par/suivi de dans l'affirmation partie de. J'aime pas trop cette solution personnellement parce que j'aurais préféré que part of (P361)/has part(s) (P527) soient réservés pour les parties d'objets concrêts, et d'avoir d'autre propriétés pour les séries, mais j'ai pas eu de succès non plus. TomT0m (talk) 15:55, 17 September 2014 (UTC)
Nous sommes d'accord : l'utilisation de liste de concernait list of Desperate Housewives episodes (Q756833), une liste sur un projet Wikimedia justement. --Dereckson (talk) 14:06, 20 September 2014 (UTC)

parfois Wikidata est obtus...

Merci de fusionner Q3560947 et Q604261, "c'est la même chose" et l'outil Merge est récalcitrant, m'opposant un message 

Error while "Attendez...":
Un conflit a été détecté sur frwiki: Q604261 avec frwiki:Oncovirus, Q3560947 avec frwiki:Virus oncogène

à la lecture duquel je ne vois d'autre réponse qu'un petit message communautaire !?
Merci à tout Wikidata-gestionnaire qui pourrait soulager cette petite contrariété. Cordialement --BonifaceFR (talk) 16:37, 16 September 2014 (UTC)

En l'occurrence, le problème ne vient pas vraiment de Wikidata mais de la Wikipédia francophone qui possède deux entrées : w:fr:Oncovirus et w:fr:Virus oncogène. Le premier est une redirection mais Sk!dbot a crée l'élément par erreur.
J'ai fusionné à la main (il suffit de retirer le bon lien placé au mauvais endroit et de le mettre à la place de la redirection sur la bon élément), si un admin pouvait supprimer oncovirus (Q3560947) (à moins qu'il ne faille faire une redirection comme Zolo indique plus haut mais je ne sais pas faire non plus…).
Cdlt, VIGNERON (talk) 17:03, 16 September 2014 (UTC)
Fait (après avoir enlevé les libellé de Q3560947 pour aider l'outil. --Zolo (talk) 17:14, 16 September 2014 (UTC)
Merci à vous --BonifaceFR (talk) 09:50, 17 September 2014 (UTC)

Instance of for periodic events

Euh pardon, je pensais être sur le Project Chat anglophone... Du coup je laisse le titre comme panneau indicateur au cas où :). -Zolo (talk) 08:27, 17 September 2014 (UTC)

traduction de "business division"

Quelqu'un sait comment on traduit business division (P199). C'était "secteur d'activité", mais ça ne veut pas dire la même chose. Du coup, j'ai mis "division commerciale", mais je ne pense pas que ce soit très bon non plus. -Zolo (talk) 08:30, 26 September 2014 (UTC)

Peut-être des idées sur linguee.fr Pamputt (talk) 08:46, 26 September 2014 (UTC)
branche ? voir par exemple http://compta.over-blog.com/article-structure-de-l-entreprise-39729384.html TomT0m (talk) 10:09, 26 September 2014 (UTC)
Le grand dictionnaire terminologique de l'Office québécois que la langue française ne connait pas la loucation « business division » mais traduit « division » par « division » dans le domaine administratif/économique. « Division commerciale » me semble pas mal (en tout cas, mille fois mieux que « secteur d’activité ») mais est apparemment quasiment inutilisé (sauf en Suisse apparemment). « Direction » est apparemment plus courant en France.
Je ne suis pas sur que l’adjectif « commercial » soit nécessaire dans le label (au contraire, il tend à générer une confusion avec la division/direction en charge du commerce comme on dit « direction financière » pour celle en charge des finances).
Cdlt, VIGNERON (talk) 11:35, 26 September 2014 (UTC)

Traduction automatique via Wikidata ?

Voyant la complexité liée à la gestion des modèles de traduction comme Template:Occupation, je me demandais si on ne pourrait pas les gérer à travers Wikidata. On pourrait en effet créer les propriétés de type texte monolingue "masculin", "féminin", "masculin pluriel" et "féminin pluriel" qui stockeraient les différents genres du mot, et les récupérer automatiquement dans le modèle.

Par exemple, pour actor (Q33999), on aurait :

  • masculin :
    • acteur (français)
    • actor (anglais)
  • féminin :
    • actrice (français)
    • actress (anglais)
  • masculin pluriel :
    • acteurs (français)
    • actors (anglais)
  • féminin pluriel :
    • actrices (français)
    • actresses (anglais)

Comme j'ai un peu la flemme et manque de compétences pour développer une argumentation en anglais, je souhaite avoir vos avis dans un premier temps avant d'aller plus loin, surtout si ça s'avère une mauvaise idée (notamment par rapport à la future intégration du Wiktionnaire). Merci par avance. — Ayack (talk) 19:49, 26 September 2014 (UTC)

Je n'ai pas trop suivi les discussions sur le Wiktionnaire, mais il me semble que la façon la plus simple de procéder serait quelque chose comme :
actor (Q33999) :
Property: mot utilisé:
lien vers entrée Wikitionnaire XX : "actor (mot anglais)"
lien vers entrée Wikitionnaire XXY : "acteur (mot français)" (ou peut-être deux liens "acteur" et "actrice")
Les informations grammaticales sur chacun des mots seraient seulement stockées sur le Wiktionnaire. Les mettre dans Wikidata me parait assez encombrant (déclinaisons...) et pas forcément solide conceptuellement. Il n'y a pas toujours de bijection entre le mot et l'élément, du coup quand un mot traduit plusieurs concepts, il faudrait dupliquer toutes les informations grammaticales, et quand plusieurs mots peuvent exprimer un même élément, ce serait un peu bordélique. --Zolo (talk) 06:52, 27 September 2014 (UTC)
Je dis peut-être une bêtise mais le plus simple ne serait-il pas tout simplement d’intégrer les mots magiques plural et gender dans le label ? (ou sinon un système équivalent)
@Zolo : je comprends ton idée de la problématique du langage naturel mais je ne suis pas que pour Wikidata ce soit problématique, plusieurs mots peuvent être utilisés pour un concept mais sur Wikidata on part de concepts et non des mots. Par exemple, le pluriel de « œil » peut-être « yeux » ou « œils » selon le concept dont on parle (respectivement eye (Q7364) ou Q3594081). Et plutôt que de dupliquer l’information, il y a quelques moyens simples de procéder, par exemple il faudrait un moyen d’indiquer « pluriel régulier » plutôt que de récrire le même mot avec un « s » à la fin (idem pour les déclinaisons qui sont régulières, il suffit de connaître la racine et le suffixe, c'est ainsi que l'on procède sur les wiktionnaires). Au final, aurais-tu un exemple vraiment problématique ?
Cdlt, VIGNERON (talk) 07:38, 27 September 2014 (UTC)
@VIGNERON: Ce que je voulais dire c'est que si on a deux mots, et qu'on doit pour chacun donner les informations grammaticales correspondantes, ça devient un peu compliqué :
mot français
masculin: homme politique, politicien
féminin: femme politique, politicienne
Avec ça, c'est difficile d'être sûr que "femme politique" est le féminin de "homme politique" plutôt que de politicien". Et ajouter les informations grammaticales rend les choses plus compliquées encore. Utiliser des codes pour les formes régulières simlifierait un peu les choses, mais ça resterait encore un peu complexes et plein d'exceptions. Il y auraut sans doute moyen de se débrouiller mais vu que le Wiktionnaire wikibase devrait être conçu spécifiquement pour gérer ça me parait mieux de gérer ça là bas, et de se contenter d'ajouter des liens sur Wikidata.--Zolo (talk) 08:40, 27 September 2014 (UTC)

Demande de fusion

Est-il possible de fusionner Q613865 et Q14566565. Merci. 78.238.225.248 21:48, 26 September 2014 (UTC)

  Done --Fralambert (talk) 01:25, 27 September 2014 (UTC)

Duplication d’informations

Bonjour à tous,

Le message ci-dessus d’Ayack me fait penser que cela fait un certain temps que je souhaite mettre sur la table le sujet de la duplication d’informations.

Je pars d’un constat : on dit et re-dit régulièrement qu’il ne faut pas dupliquer l’information mais simultanément on duplique déjà une énorme partie de l’information. Le cas le plus flagrant sont les propriétés symétriques (typiquement father (P22), mother (P25) et child (P40) pour les plus courantes mais Special:WhatLinksHere/Template:Constraint:Inverse en liste une trentaine d'autres). Heureusement, la contrainte Constraint:Inverse permet de suivre assez efficacement le problème mais fondamentalement quelque chose me gêne à dupliquer l'information. Ensuite, il y a les duplications plus sournoises, par exemple head of government (P6) ou P7 (P7)/P9 (P9). Et là, pour le moment et sauf erreur de ma part, on n'a aucun moyen de suivre et vérifier cela.

Parfois, je me demande s'il n'y a pas eu erreur de conception à la base de Wikidata. La plupart des informations sont « bidirectionnelles », par exemple si « A est X de B » alors « B est Y de A » avec Y l'inverse de B. Cela veut dire que tout propriété est potentiellement duplicable (je vous laisse imaginer ce que cela donnerait avec les propriétés de lieux ou de date, chaque département aurait la liste de sa centaine de commune, chaque année la liste des événements de l'année, etc. là ce serait vraiment ingérable). Heureusement, pour la plupart des propriétés, il y a un des deux sens qui est plus courant/logique/utilisé (Victor Hugo (Q535) est mort en 1885 (Q7821)) mais l'autre sens n'est pas faux, ni non-pertinent dans l'absolu (il n'y a qu'à voir les pages d'éphéméride sur les wikipédias).

Je vois plusieurs solutions potentielles : refondre la base du système de Wikidata (oublions je pense) ou bien choisir arbitrairement un des deux sens (on choisit d'indiquer les enfants et non les parents ; éventuellement avec un bout de script pour présenter l’information inverse dans l’autre élément).

Voilà. Je réfléchis à cela depuis plusieurs jours et je tourne un peu en boucle, j'ai peut-être fait des erreurs d'appréciations et vos rectification/corrections/avis/commentaires/suggestions/idées/whatever seraient les bienvenus.

Cdlt, VIGNERON (talk) 08:08, 27 September 2014 (UTC)

Salut VIGNERON, ce problème est bien connu et est visé indirectement par certains éléments du plan de développement, par exemple les simple queries ou access to data from arbitrary items. Sois conscient que WD fut d'abord conçu pour fournir des infos aux autres projets, en particulier à la Wikipédia. C'est d'abord un dépôt de données, qui se développe graduellement des caractéristiques de base de données.
Pour le problème que tu soulignes, l'idée circule de permettre un type de propriété "virtuelle" (connais pas le terme exact) qui serait associée à un item mais dont la ou les valeurs serait le résultat d'une requête "immédiate et permanente" de la WD elle-même. Par exemple, (voir bugzilla 47930) sur common sunflower (Q171497), accéder directement le botanist author abbreviation (P428) de Carl Linnaeus (Q1043) (qui est son taxon author (P405)). De la même façon, les frères et sœurs pourraient êtres disponibles via un attribut qui serait une requête sur les items partageant les même parents. Il suffit d'être patient avec la petite équipe de développeurs et ces fonctions seront éventuellement disponibles. LaddΩ chat ;) 14:46, 27 September 2014 (UTC)
Merci beaucoup LaddΩ pour ces explications (dans Wikidata:Development plan, je n'avais pas vraiment fait le lien et compris à quoi cela faisait vraiment référence). Cdlt, VIGNERON (talk) 19:48, 27 September 2014 (UTC)
En fait, je ne pense pas que les requêtes règleront vraiment le problème, parce que celles-ci ne s'effectueront pas "à la volée". Par exemple, les requêtes permettront d'obtenir une liste des communes tchèques (éléments avec instance of (P31): municipality of the Czech Republic (Q5153359)), mais pour cela, il faudra créer une page spéciale, sur l'espage de nom réservé aux requêtes. Il y aura alors une page "Query:Commune tchèque" qui se mettra à jour automatiquement. Donc si on veut faire la même chose pour retrouver les frères et soeurs de XX, il faudra d'abord créer la page de requêtes "éléments ayant pour parents les parents de XX", ce qui parait un peu difficile à gérer à grande échelle.
L'"accès arbitraire" est déjà déployé sur Wikidata, mais pas sur Wikipédia. Ca a beaucoup d'applications, par exemple, formater les sources données en référence, ou faire des pages comme Template:Artwork/testcases, mais ça n'évite pas les duplications dues aux propriétés symétriques. --Zolo (talk) 21:45, 28 September 2014 (UTC)
C'est vrai, je n'ai pas vu de discussions récentes sur des propriétés-requêtes "à la volée" - mais encore tout récemment, WD ne pouvait pas être client de lui-même... Mais je me rappelle de telles discussions il y a environ 2 ans si je ne m'abuse. Je vais reposer la question sur Wikidata:Project chat, histoire d'avoir des nouvelles... LaddΩ chat ;) 02:22, 30 September 2014 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Bistro/Archive/2014/09&oldid=2029381807"