Topic on Wikidata:Bistro/Archives des discussions structurées

procédure lorsqu'un site web change ses identifiants externes ?

11
Simon Villeneuve (talkcontribs)

Bonjour,

L'Union des artistes a changé son site web et n'a pas mis en place de redirections des anciens identifiants vers les nouveaux. Je crois qu'il faut adapter la propriété reliée en conséquence, mais je veux bien faire les choses. Il faudrait donc me pointer, si elle existe, la procédure à suivre dans ce genre de situation. @Fjjulien:

Hsarrazin (talkcontribs)

bonjour Simon

pour ce que j'en ai vu, l'Identifiant lui-même n'a pas changé, puisque quand j'entre "109866" sur le nouveau site, j'obtiens bien la notice de "Rebecca Makonnen"... reste à voir comment l'adresse est impactée...

l'adresse telle qu'elle est actuellement définie échoue effectivement... faut-il passer par une adresse de recherche ?

Simon Villeneuve (talkcontribs)

Coucou,


Les fiches sont désormais accessibles à l'adresse https://bottin.uda.ca/artists/$1 où $1 est sous la forme "prenom-nom" de l'artiste (exemple : https://bottin.uda.ca/artists/rebecca-makonnen). Mon plan était de mettre la nouvelle adresse de base dans la propriété, de mettre l'ancienne adresse en rang obsolète et d'ajouter les nouveaux identifiants sur les éléments concernés tout en mettant l'ancien identifiant obsolète. Mais avant de ce faire, je voulais savoir la procédure à suivre dans ces situations. Puisque cela arrive souvent, je me suis dit qu'il y avait forcément eu des discussions sur la manière de faire dans ces situations.

Hsarrazin (talkcontribs)

Bonjour Simon,

pour moi, l'ancien identifiant n'est pas "obsolète", au sens où c'est bien toujours le "matricule UDA" des artistes dans la base... et que si on l'entre en recherche, on tombe bien sur la page de l'artiste concerné : simplement, ça n'est plus ce qui sert à former l'url visible... ce qui est légèrement différent d'obsolète... - il se peut que, comme pour Agorha, l'ID soit masqué, mais toujours pertinent...

la méthode change généralement pour chaque base, car les cas varient énormément : par exemple, pour Leonore, on a dû créer un 2e identifiant, qualifié de "web" en PLUS de l'ID Léonore, qui est la cote permanente des dossiers aux AN (et qui donc n'est pas obsolète du point de vue des dossiers matériels)...

quand à la méthode suivie pour mettre à jour, elle dépend bien sûr de chaque cas... - ce qui n'est évidemment pas très satisfaisant...

combien y a-t-il d'éléments concernés ?

Simon Villeneuve (talkcontribs)

environ 3 200.


J'ai peine à croire qu'on en soit encore à traiter ce genre de problème au cas par cas. Il y a certainement une page anglo qui décrit les bonne pratique (Q830382) non ?

Simon Villeneuve (talkcontribs)

exemple : dans la description anglo de format de l'URL (P1630), on dit de mettre l'ancienne valeur obsolète si le site est mort, et la nouvelle valeur en rang préféré s'il y a eu migration.

Jahl de Vautban (talkcontribs)

C'est possible de jouer avec le rang des URL uniquement si les identifiants ne changent pas, ce qui n'est pas le cas ici. "https://bottin.uda.ca/?term=109866" ça reste faux et j'imagine mal quelqu'un se dévouer à corriger les 3000+ éléments concernés pour les rendre conforme. Comme dit Hsarrazin la procédure standard c'est de créer une nouvelle propriété.

Simon Villeneuve (talkcontribs)

c'est facile à corriger. Mon fichier .csv est prêt depuis avant-hier. J'attendais juste de voir ce qui sortirait de cette conversation. Pour le moment, je ne suis pas beaucoup plus avancé. Personne ne m'a pointé de discussion sur le sujet. Hsarrazin est de bonne foi et si elle accepte de continuer à discuter, on devrait arriver à arrimer nos conversations.

Quant à elles, vos déclarations péremptoires n'arrivent qu'à m'irriter.

Hsarrazin (talkcontribs)

Bonjour Simon,

Désolée si je ne t'ai pas pointé vers des discussions sur le sujet... celles que je connais concerne des cas particuliers (comme Leonore) : si on traite en "cas particuliers" c'est en partie parce que chaque cas est particulier : certains sites cassent tout et obligent clairement à une désactivation pure et simple, et la création d'un nouvel id... ce qui est la procédure la plus simple.

d'autres masquent l'identifiant, qui n'apparaît plus dans l'url, mais l'id reste pertinent, et les liens sont redirigés (une fois qu'on a trouvé la bonne "racine" de lien à appliquer) -> c'est le cas pour Agorha -> il suffit alors de trouver ladite bonne racine...

ça se complique quand l'identifiant qui n'apparaît plus conserve un sens (comme la "cote Leonore", ou le "matricule UDA" comme ici) : la désactivation pure et simple de l'ID existant ferait perdre une information qui reste pourtant pertinente, puisqu'on peut continuer à utiliser l'identifiant en question pour faire des recherches (à défaut de faire un lien direct)...

comme le cas me paraît au moins similaire à Leonore, même si l'ampleur des dégâts n'est pas la même (plus de 380000 identifiants), je te pointe sur ladite discussion et la solution qui a été mise en place : renommage de cote Léonore(P640) en "cote Leonore" au lieu d'ID Leonore + ajout d'un nouvel identifiant identifiant web Léonore(P11152) après que les alignements aient été fournis par un contributeur des AN -> discussion en PDD de P640 qui renvoie vers les Bistro adhoc.

comme Leonore dépend des Archives nationales de France, il a fallu plus d'un an pour trouver une solution, car nous espérions que le pb serait réglé sur le site, par une éventuelle redirection... je te laisse lire les débats depuis mai 2021 à octobre 2022...

Bon courage !

Simon Villeneuve (talkcontribs)

Merci pour ton temps. J'ai corrigé l'URL de base et les liens sont redevenus en partie fonctionnels. Quant à la création d'une nouvelle propriété et l'association des nouveaux identifiants, disons que nos échanges avec l'UDA ont refroidis nos ardeurs.

Merci encore!

Jahl de Vautban (talkcontribs)
Reply to "procédure lorsqu'un site web change ses identifiants externes ?"