Wikidata:Bistro

From Wikidata
Jump to navigation Jump to search
Bienvenue sur le Bistro !
Un endroit pour discuter des différents aspects de Wikidata : projet, demandes d'aide, règles et propositions, problèmes techniques, etc.

Jetez un œil aux questions fréquemment posées.
Les instructions pour fusionner deux éléments sont disponibles à Aide:Fusion.
Pour de l'aide avec une requête SPARQL, essayez Wikidata:Request a query.
Les demandes de protection (vandalisme...) peuvent se faire à Wikidata:Requêtes aux administrateurs
Les demandes de suppression peuvent être faites à Wikidata:Demandes de suppression.

Canal IRC : #wikidata-frconnect
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/07.

Ordre du prénom et du nom dans les catalogues Mix'n'match

[edit]

Bonjour ! Dans ce catalogue, le nom précède malheureusement le prénom. Cela empêche de créer plusieurs éléments d'un coup, car il faut rectifier chaque libellé. Y aurait-il moyen de faire autrement ? Merci d'avance ! Maxime 17:44, 5 July 2024 (UTC)[reply]

Euh, avant de répondre à la question, comment peut-on associer un quelconque élément avec un simple nom ? Il n'y a pas de date de naissance, pas de profession et aucun des liens dans les fiches ne fonctionnent (ex: https://archives.sciencespo.fr/archive/catalogue/persname/achille-fould-aymar)... Ayack (talk) 18:10, 5 July 2024 (UTC)[reply]
@Ayack, Maxime Ravel: en plus du nom, on sait que ce sont des personnalités politiques de la Ve République (donc françaises) et sans avoir de date de naissance/mort, on a quelques dates et lieux comme indice. C'est loin d'être idéal mais ce n'est pas rien ; c'est suffisant pour certains match évidents (par exemple tout les députés ?), par contre c'est effectivement sans doute trop peu en soi pour créer un élément (il faudrait au minimum une autre source). Cdlt, VIGNERON (talk) 10:14, 6 July 2024 (UTC)[reply]
Je suis bien d'accord. Quant aux fiches inaccessibles le problème semble aléatoire, c'est peut-être dû au navigateur qu'on utilisé (?). Cordialement, Maxime 10:49, 6 July 2024 (UTC)[reply]

N. B., j'ai fait remonter le problème à Odile Gaultier-Voituriez(104129136). Cordialement, Maxime 12:37, 8 July 2024 (UTC)[reply]

Celle-ci vient de me dire que le problème était résolu, cela venait de liens ARK dysfonctionnels. VIGNERON et Ayack, puis-je vous laisser le soin de vérifier ? Cordialement ! Maxime 08:47, 12 July 2024 (UTC)[reply]

Question OpenRefine

[edit]

Bonjour, je suis en train d'essayer de réconcilier une liste de personne avec OpenRefine sur la base de leur nom et de leur date de naissance (au format date dans OpenRefine). Je fait la réconciliation avec des éléments de type être humain (Q5) et j'ajoute la date de naissance comme colonne supplémentaire. Mais OpenRefine ne semble pas utiliser la date de naissance, puisqu'il me sort avec un score identique tous les éléments dont le nom correspond, quelle que soit leur date de naissance... Quelqu'un saurait-il comment résoudre ce problème ? Ayack (talk) 08:16, 9 July 2024 (UTC)[reply]

@Ayack: étrange, normalement OpenRefine utilise bien les colonnes supplémentaires (et même parfois un peu trop, par exemple pour "toto" avec le code INSEE "35238", il réconcilie bien avec Rennes (Q647) même si les chaînes de caractères n'ont rien à voir). Est-ce que utilises bien la colonne supplémentaire ? (voir https://openrefine.org/docs/manual/reconciling#reconciling-with-additional-columns pour la documentation de cette fonctionnalité). Est-ce que la date est au bon format ?
Je viens d'essayer avec un exemple simple nom et année de naissance : un csv contenant "John Smith, 1798 ; John Smith, 1938" et la réconciliation associe bien le premier à John Smith (Q3182477) et le second à John Smith (Q332377). Peut-être pourrais-tu partager un extrait de ton fichier pour que je vérifie de mon côté.
Cdlt, VIGNERON (talk) 08:30, 9 July 2024 (UTC)[reply]
@VIGNERON Hello, je viens de mettre quelques lignes sélectionnées ici : https://bpa.st/JYYQ. Chaque ligne me renvoie plusieurs résultats qui ont quasiment tous le même score de 71. Ayack (talk) 08:50, 9 July 2024 (UTC)[reply]
@Ayack: effectivement il y a quelque chose de bizarre, et cela semble venir du format des dates (pas surprenant, le formatage des dates est un piège tellement courant). Quand je garde tes dates complètes, aucune reconciliation automatique (score de 71) ; alors que quand j'extrais seulement l'année, 3 personnes sont automatiquement matchées (score 100) et pour les 3 autres (score 71), là c'est normal car il n'existe pas de dates correspondantes.
Je notifie quelques autres personnes francophones utilisant OpenRefine qui pourront peut-être en dire plus : @Pintoch, Fralambert, Bouzinac, Daieuxetdailleurs:.
Cdlt, VIGNERON (talk) 09:04, 9 July 2024 (UTC)[reply]
@VIGNERON, Ayack: Visiblement ça marche si les dates ont la forme 1976-01-18 mais pas si elles ont la forme 1976-01-18T00:00:00Z. On pourrait suggérer une amélioration pour que les deux formats soient supportés. − Pintoch (talk) 18:09, 9 July 2024 (UTC)[reply]
D'ailleurs, je me souviens que OR gère parfois mal les dates, par exemple avec le bouton "convertir en date" il se mélange les pinceaux entre les mois et les jours (entre les formats américains et européens par exemple) + parfois il ajoute une journée lors de la conversion, ce qui rajoute de la confusion Bouzinac💬✒️💛 06:40, 10 July 2024 (UTC)[reply]
@Pintoch Ah curieux, dans mon fichier elles ont la forme 1976-01-18T00:00:00Z parce que je les ai converties en date avec OR. C'est le comble qu'il faille les conserver au format 'string' pour que ça marche !
@Bouzinac Oui, j'ai rencontré le même problème, il faut utiliser toDate pour que ça marche. Ayack (talk) 07:31, 10 July 2024 (UTC)[reply]

Nouvel outil

[edit]

Sur Wikidata, il faut aller sur deux pages distinctes pour avoir l'ensemble des déclarations impliquant deux éléments donnés.

Relationships permet de synthétiser l'ensemble de ces déclarations sur une seule page.

Par exemple, on peut regarder l'ensemble des déclarations impliquant Bernard Arnault et LVMH : https://observablehq.com/@pac02/relationships?item1=Q504998&item2=Q32055&lang=en

Est ce que vous connaissez des outils qui font déjà ce genre de choses ? PAC2 (talk) 21:15, 10 July 2024 (UTC)[reply]

Outil qui permet de comparer deux éléments : Wikidata Diff (avec l'exemple de deux anciennes députés). — Envlh (talk) 20:12, 11 July 2024 (UTC)[reply]
Trop bien @Envlh.
C'est un peu différent de mon outil parce que tu regardes toutes les déclarations alors que je me concentre sur les déclarations communes aux deux entités.
J'ai ajouté une lien vers ton outil dans Relationships. PAC2 (talk) 05:56, 14 July 2024 (UTC)[reply]

Règle encyclopédique pour la propriété de conjoint ?

[edit]

Bonjour,

Je suis récemment tombé sur la biographie de Susan Fleming (Q7647833).

Celle-ci a deux propriétés de conjoint:

  • Harpo Marx entre 1936 et 1964 (date de la mort d'Harpo)

et

  • Harpo Marx à partir de 1936.

Il y a donc une propriété de trop mais quelle est la règle encyclopédique ?

Doit-on considérer que le fait d'avoir un conjoint s'arrête à la mort de celui-ci (1e forme) ? Cependant cette forme est ambigüe car on ne sait pas si l'arrêt est dû au décès du conjoint ou à un divorce/séparation.

Ou si le survivant ne s'est pas remarié (ce qui semble être le cas), faut-il utiliser la 2e forme (qui n'indique pas que le conjoint a pu décéder) ?

Merci Hum6hum4 (talk) 20:41, 11 July 2024 (UTC)[reply]

j'ai rajouté comme qualificatif "motif de fin" = "mort du conjoint ou de la conjointe". Pyb en résidence (talk) 06:29, 12 July 2024 (UTC)[reply]
Merci, cela clarifie la situation! Hum6hum4 (talk) 20:41, 12 July 2024 (UTC)[reply]

Les suppléant(e)s des élu(e)s dans Wikidata ?

[edit]

Bonjour,

En consultant la liste des nouvelleaux député(e)s français(e)s, je me suis dit qu'il pourrait être intéressant de les référencer dans Wikidata. La même réflexion peut porter sur les suppléant(e)s des conseiller(e)s départementaux. Qu'en pensez-vous ? Maxime 09:38, 12 July 2024 (UTC)[reply]

Bonjour. Un(e) suppléant(e) n'a d'intérêt qu'en cas de démission/décès/appel à d'autres fonctions du/de la titulaire. Auxquels cas, il/elle devient alors intéressant(e) pour notre base de données. Père Igor (talk) 15:59, 12 July 2024 (UTC)[reply]
Ce n'est peut-être pas l'information la plus essentielle mais ce n'est pas à rejeter non plus. Je vois au contraire des idées de requêtes très intéressantes, comme : quel pourcentage d'élus ont été suppléants avant d'accéder à la fonction ? (je soupçonne que ce soit un nombre important) qui a été le plus souvent suppléant sans jamais accéder à la fonction ? etc.
C'est aussi une intéressante question de modélisation, à laquelle je n'ai pas forcément de réponse pour le moment (de but en blanc et au doigt mouillé, je dirais que plutôt c'est une information à mettre sur le député lui-même mais cela pourrait aussi avoir sa place sur l'élément du suppléant...).
Cdlt, VIGNERON (talk) 17:42, 13 July 2024 (UTC)[reply]
Comme VIGNERON, je vois un intêret à créer ces éléments de suppléants, surtout pour les requêtes: on pourrait en déduire la parité homme/femme/x des suppléants, générale ou par parti. on pourrait également déduire de ces données le pourcentage des binomes HH, FF ou différent. Un truc important à mon sens est le sourçage: il y a souvent bien moins d'infos disponibles sur les suppléants. Donc faire attention, et ne pas hésiter à ajouter les sources aux items. Par contre, pour la modélisation, aucune idée. Peut être créer un élément "suppléant d'une député français", qui hériterait de la propriété substitute deputy (Q99343473), et on le mettrait en fonction. --Deansfa (talk) 16:33, 15 July 2024 (UTC)[reply]

Retrait des libellés en français (et d'autres langues)

[edit]

Salut,

Je suis récemment tombé sur un contributeur dont les contributions semblent se concentrer sur la suppression de tous les libellés qui ne sont pas anglais dans les items Wikidata de personnes: Un exemple ici.

Son argument, que je comprends, est qu'à partir du moment où le libellé existe en anglais, il n'y a aucun raison qu'il ne soit défini dans les autres langues. Je comprend le point de vue, et ne suis pas en désaccord théoriquement. Le problème est que, dans le même temps, des centaines voire des milliers de contributeurs, bots, etc, font le truc inverse, en ajoutant les libellés dans les autres langues. À titre personnel, j'ajoute toujours le libellé en français, car sinon, l'interface Wikidata montre un petit message "anglais" en italique.

Avis? Est-ce une nouvelle convention? -Deansfa (talk) 13:39, 14 July 2024 (UTC)[reply]

@Deansfa: ces modifications sont prématurées tant que le code "mul" n'est pas encore disponible (cf. Help:Default values for labels and aliases), une fois le système en place alors oui ce deviendra la norme et la façon correcte de faire. Cheers, VIGNERON (talk) 13:51, 14 July 2024 (UTC)[reply]
Merci pour la réponse @VIGNERON:. C'est bon à savoir. J'ignorais qu'il y avait cette nouvelle fonctionnalité en projet, qui je l'espère sera disponible bientôt. Ok, donc pour le moment je fais comme avant, et je switcherais quand ce sera implémenté. --Deansfa (talk) 13:56, 14 July 2024 (UTC)[reply]
@Deansfa: ce n'est qu'un conseil et non une obligation mais en attendant le nouveau système et pour permettre une transition plus douce, le mieux serait d'arrêter dès maintenant de dupliquer les libellés identiques. Cdlt, VIGNERON (talk) 09:17, 15 July 2024 (UTC)[reply]
@VIGNERON: Entendu, je ferais ça. La réalité cependant, c'est que la plupart du temps, dans mes créations d'item sur des personnalités, je ne duplique pas les libellés (un exemple ici). Et quand je le fais, je le limite au français (ca vient surtout du fait que ma langue par défaut est le français, donc il me propose de remplir le libellé en français à la création de l'item. et ensuite je met le libellé en anglais). Dans certains cas, pour les noms de famille, il y a un gadget qui ajoute en masse les libellés et les descriptions. Probablement dans l'avenir ce gadget devrait être modifié. --Deansfa (talk) 15:46, 15 July 2024 (UTC)[reply]