[OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

Dim 7 Aou 17:56:12 UTC 2016

Le 07/08/2016 à 17:37, Christian Quest - cquest at openstreetmap.fr a écrit :
> Le 7 août 2016 à 13:31, <osm.sanspourriel at spamgourmet.com 
> <mailto:osm.sanspourriel at spamgourmet.com>> a écrit :
>
>     L'idée c'est de remplacer les ref:FR:CUB par exemple par des
>     ref:Q1117116
>     L'avantage c'est qu'à périmètre constant (ce qui est le cas de la
>     CUB devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.
>
>
> Est-on sur de la stabilité, non pas des ID wikidata, mais que 
> lorsqu'il y a des évolutions sur les entités qu'ils représentent on 
> garde bien le meme ID ?
>
> D'autres exemples que la CUB pour valider ?
Oui, c'est le principe : l'identifiant Wikidata doit être stable dans le 
temps.
Deux en un : je réponds en même temps à Alain en donnant l'exemple qui 
nous a fait parler des Wikidata.
Toute page Wikipedia a un numéro wikidata associé.
Prenons Enedis https://fr.wikipedia.org/wiki/Enedis.
Dans la colonne de gauche tu vois Élément Wikidata 
<https://www.wikidata.org/wiki/Q3587594>.
Christian, la stabilité vient du fait que la page ERDF a été renommée en 
Enedis :

  * (actu
    <https://fr.wikipedia.org/w/index.php?title=Enedis&diff=128241462&oldid=126688849>
    | diff
    <https://fr.wikipedia.org/w/index.php?title=Enedis&diff=126688849&oldid=126679567>)
    1 juin 2016 à 15:51
    <https://fr.wikipedia.org/w/index.php?title=Enedis&oldid=126688849>‎
    Gustave2001 <https://fr.wikipedia.org/wiki/Utilisateur:Gustave2001>
    (discuter
    <https://fr.wikipedia.org/wiki/Discussion_utilisateur:Gustave2001> |
    contributions
    <https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Contributions/Gustave2001>)‎
    m . . (30 973 octets) (0)‎ . . (Gustave2001 a déplacé la page
    Électricité Réseau Distribution France
    <https://fr.wikipedia.org/wiki/%C3%89lectricit%C3%A9_R%C3%A9seau_Distribution_France>
    vers ENEDIS
    <https://fr.wikipedia.org/w/index.php?title=ENEDIS&action=edit&redlink=1> :
    changement du nom de l'entreprise) (annuler
    <https://fr.wikipedia.org/w/index.php?title=Enedis&action=edit&undoafter=126679567&undo=126688849>)

Donc un ref:wikidata:Q3587594 aurait été une référence d'ERDF et 
maintenant d'Enedis.
Par contre ça n'aurait pas résolu la découpe PTT en La Poste et France 
Télécoms.
D'ailleurs vous voyez que l'entreprise est.... Groupe La Poste !
*Et là ça se complique car Groupe La Poste Q373724 a remplacé La Poste 
Q20746370 qui a remplacé...*

Donc l'intérêt des Wikidata me semble moindre car l'identifiant peut 
changer même à périmètre constant.

> Dans le cas contraire, on perd ce qui me semble etre le principal 
> avantage à l'usage de wikidata et on complexifie énormément la lecture 
> pour les contributeurs...
On a bien le principal avantage de wikidata... dans les bons cas et non 
on ne complexifie pas si comme je dis on mène un chantier pour adapter 
les outils.
Maintenant si on a une base de ref:*:* et des outils pour changer 
ref:FR:ERDF en ref:FR:Enedis... c'est peut-être plus simple.

Dans le fil consacré aux wikidata, j'avais aussi envisagé d'ingérer 
certaines parties des Wikidata (ici id, noms) afin d'avoir des sortes de 
métadonnées car on ne doit pas avoir des la poste, La poste, La Poste, 
Groupe La Poste, etc...
Car même si on n'utilise pas les Wikidata, la saisie de tout texte libre 
est sujette à caution. OK, ici c'est en clé pas en valeur mais une 
référence à Groupe La Poste doit suggérer brand=La Poste.
D'une manière générale on a pas mal de choses dans la wiki qui 
pourraient être stockée plus judicieusement au niveau de la base : par 
exemple les références qui proviennent de l'opendata (ou autre) : par 
exemple comment savoir où récupérer les ref:FR:LaPoste ?
C'est juste un exemple. Ou que les bal de ref:FR:LaPoste ont pour 
brand="La Poste".

Jean-Yvon

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/41d70e05/attachment.htm>