[OSM-talk-fr] Vérification des tags wikipedia et nettoyage ?

[Philippe Verdy]

Je ne vois que des avantages à Wikidata... sauf que pour contribuer à OSM
alors les conditions d'utilisation OSM ne sont plus suffisantes, il faut
aussi contribuer à Wikimedia et accepter aussi les termes Wikimedia et y
disposer d'un autre compte. ensuite il faut aussi se former aux outils
Wikimedia et apprendre à utiliser Wikidata (ce qui est beaucoup moins
simple que pour Wikipédia).
Il faudrait que les outils OSM fassent comme Wikipédia: inclure les
"moulinettes" qui permettent de contribuer indirectement à Wikidata de
façon plus simple que par l'interface Wikidata par défaut. Il faudrait
aussi que les éditeurs OSM incluent la création ou la connexion à un compte
Wikimedia et l'acceptation de ses propres conditions d'utilisation. Ensuite
ces outils OSM n'ont pas besoin de générer toutes les données Wikidata,
juste celles qu'OSM va utiliser: il semble suffisant que cet éditeur puisse
trouver les articles Wikipédia (dans n'importe quelle langue) puis leur Id
Qnnnn Wikidata et aussitôt alors proposer de mettre ce Wikidata et se
passer de Wikipédia dan les données OSM.

Les noms par défaut et traductions peuvent être trouvées aussi dans
Wikidata et on doit pouvoir y contribuer directement avec son compte
Wikimedia (de préférence un compte SUL, mais attention car certains comptes
Wikimedia n'on pas pu être unifiés et les noms d'utilisateurs peuvent être
différents selon les wikis : l'utilisateur Wikipédia et l'utilisateur
Wikidata n'est pas toujours le même, surtou si ce sont des comptes anciens
mais toujours actifs, datant d'avant les logins unifiés, et la fusion n'a
pas toujours été possible si les comptes en conflits étaient actifs tous
les deux et aucun n'a accepté de changer son nom d'utilisateur local car
Wikimédia n'a pas voulu ni obligé personne à abandonner son nom
d'utilisateur actif au profit d'un autre, sachant que le renommage de
comptes pose des tas de difficultés, demande des ressorues importantes sur
les serveurs pour modifier des tas de pages, et que tout n'est pas toujours
trouvé à cause des modèles ou des préférences locales des utilisateurs,
dont les javascripts utilisateur dans leurs pages personelles que Wikimedia
s'interdit d'altérer au risque de créer des problèmes de sécurité sur les
PC de ces utilisateurs; enfin de tels renommages nécessitent un procvessus
complexe d'approbation et une surveillance par les admins qui doivent être
mis au courant des problèmes ultérieurs que cela peut provoquer, afin
d'éviter des usages abusifs ou de bloquer un utilisateur pour une mauvaise
raison liéé à une confusions entre utilisateurs différents pour des actions
réalisées à des dates d'avant ou après le renommage; il y a le risque que
durant la migration cela ouvre la porte à des spammeurs et toutes sortes
d'abus: le processus de renommage n'est pas sans risque en terme de
sécurité individuelle ou collective et il y a aussi des problèmes de
gestion des droits, notamment du droit d'auteur et des licences accordées
qui pourraient s'avérer invalides après; de tels renomages doivent donc
être historisés de façon fiable pour résoudre correctement tout conflit
ultérieur, et éviter qu'une nouvelle demande de vérification de droits à un
utilisateur aboutisse à la mauvaise personne qui ne répondra pas ou
répondra à mauvais escient, puis au retrait illégitime des droits et la
suppression d'anciennes modifs pourtant tout à fait valides sans avoir
avisé l'auteur initial à son nouveau compte).

Ceci dit, quand Wikidata est activé sur les éléments qu'on cherche, il
devrait servir de base et au lieu d'ajouter ou modifier des traductions
dans OSM, on pourra le faire sur Wikidata à la place et cela doit être
automatisable, même au sein des éditeurs OSM, devenus des éditeurs
OSM+Wikidata, sans même avoir ensuite à utiliser l'interface web de
Wikidata. Des bots OSM peuent aussi trouver les redondances et pourront
nettoyer OSM de ce qui n'est plus nécessaire après avoir vérifié les
redondances restantes et l'absence de conflits. Pour le reste les bots
peuvent lister les problèmes trouvés et les inscrire dans une
"maproulette", où selon le cas il faudra modifier soit les données OSM soit
celles de Wikidata par des outils d'édition plus avancés et distinctifs,
que des utilisateurs plus avancés maitrisant chaque environnement pourront
aller "nettoyer" à la main.

Note: il y a aussi du nettoyage à faire dans Wikidata, mais Wikidata a
aussi ses bots de vérification et ses longues listes de tâches à faire (les
modèles de données évoluent aussi, des éléments dont lobjet de fusion ou
scission et de désambiguisation, il y a aussi des entrées en doublon non
fusionnées automatiquement à cause de conflits internes à Wikidata). Ce
n'est pas simple non plus, et les utilisateurs avancés de Wikidata ont même
du mal à s'y retrouver car parfois les décision prises sont contradictoires
ou non coordonnées. Cela ne se rédout pas facilement et rapidement malgré
la bonne volonté de tout le monde, et parfois il y a des désaccords forts
venant de certains autres wikis qui ne veulent pas du changement proposé
(mais n'ont pas pu en discuter dans leurs langue quand on leur a imposé
cela dans unen discussion technique en anglais qu'ils n'ont pas compris ou
pas réussi à expliquer aux autres membres de leur communauté locale,
ceraines décisions étant perçues comme "politiques" ou "non neutres" masi
pas comprise non plus par les anglophones et notramment les techniciens
Wikimedia expérimentés qui sont souvent assez pauvres en terme de
connaissances linguistiques; et il y pour nombre de langues assez peu de
ressources de la part des traducteurs peu nombreux capables de comprendre
aussi et expliquer les implications techniques, les techniciens Wikimédia
faisant assez peu d'effort pour donner des explications didactiques et
s'enfermant trop dans leur jargon et leurs procédures les plus courantes et
pas très adaptées à la coordionation avec les "petites" commmunautés, et ne
faisant pas assez appel aux "ambassadeurs Wikimedia" pour tenter de mieux
expliquer ce qu'ils font et décident et la portée des changements
strictement nécessaires et ceux qui peuvent rester facultatifs; souvent les
techniciens sont aussi trop pressés de valider des solutions qui n'ont été
validées que dans les langues majeures et pour les "gros" wikis ayant un
nombre important d'admins et coordinateurs, en nombre suffisant pour
classer chaque problème et les gérer d'une façon ordonnée qui génèrera le
moins de conflits et le moins de travail ensuite pour les autres
contributeurs locaux).

Wikidata cependant a grandement aidé à coordonner les wikis entre eux et
consolidé leurs relations. Ce qui a été fait pour coordonner ces wikis
Wikimedia peut donc maintenant s'ouvrir à la coordination avec OSM. Mais il
manque encore un vrai espace de coordination Wikimedia/OSM: cet espace est
très réduit et OSM est encore vu par beaucoup de Wikimédiens comme un
acteur externe tentant d'imposer ses solutions. Enfin il y a une très forte
résistance de la part de Wikipédia anglophone qui a développé ses propres
"standards" et les impose quasiment de force à Wikidata, contre même l'avis
des autres Wikipédias (et encore plus contre OSM). L'influence de Wikipédia
anglophone est beaucoup trop déterminante et radicale sur tous les wikis
(et pas question de leur faire changer d'vis qi on ne maitrise pas
parfaitement la langue anglaise et son jargon technique local inapdaté aux
autres langues du monde: Wikipédia anglophone est extrêmement fermé, mais
c'est aussi le cas de la "communauté" OSM anglophone qui met des
résistances énormes contre ce que voudrait les autres communautés OSM
locales).

Le problème est donc moins technique que politique: les coordinations
interprojets ne fonctionnent pas assez bien et il y a un manque de volonté
d'accepter de réouvrir les espaces de décision, et encore plus à rouvrir ce
qui est pris comme une décision passée "'définitive" alors qu'elle n'a pas
fait l'objet d'une coordination assez étendue et assez de connaissance des
difficultés du terrain extérieur. Pourtant toute politique même ancienne
devrait être rediscutable à tout moment et amendable sans déclencher les
"foudres" immédiates (voire les actions répressives) des admins des projets
anglophones (notamment Wikipédia anglophone et OSM anglophone) et la
crainte pour leurs admins "qualifiés" d'y voir des "attaques" contre leur
privilèges qu'ils considèrent comme "acquis" et indiscutables, et la totale
opposition de leurs part de changer leurs méthodes ou ralentir certain de
leurs procédés ou les modifier, puisque selon eux, cela "marche bien dans
99,9% des cas" (ceux qu'il peuvent voir étant donné les limites qu'ils ont
imposé aux projets, car il y a des tas de problèmes qu'ils sont incapables
de voir mais que les utilisateurs réels voient bien mais sont incapables de
défendre leur position à cause des limites posées et contrainte techniques
qui empêchent de reproduire les problèmes à leur vraie origine). Et
impossible d'en discuter si on n'a pas le bagage bilingue suffisant ou si
la langue non-anglaise se plie assez mal au jargon anglophone utilisé et
aux méthodes typiquement anglo-saxones (qui d'une certaine façon crée un
"élitisme" voire même constitue une forme d'exclusion et de dédain, assez
proche du racisme même si ces techniciens en petit comité fermé, et
disposant de moyens élevés y compris au plan financier ou dans certaines
aires politiques clairement orientées, ont du mal à l'admettre : ils sont
aussi sous influence et ont des tas de préconceptions sur la façon dont
"tourne le monde" qu'ils méconnaissent ou ne perçoivent pas comme il est
réellement). C'est dur de faire évoluer ces préconceptions. Et cela relance
sans arrêt les besoins d'une coordination interprojet qui ne soit surtout
pas fondée sur les seules considérations techniques ou sur ce qui marche
aactuellement (selon les statistiques collectées uniquement dans l'intérêt
des techniciens pour faire valider automatiquement leurs propres choix et
rejeter les autres possibilités)

Heureusement Wikidata continue à s'enrichir et à faire connaitre aux
techniciens de plus nombreux cas qu'ils doivent apprendre à gérer, même si
ça correspond à 0,1% des cas: prendre en compte ces cas rares permet
aussitôt devoir les statistiques changer et finalement confirmer que ce qui
passait pour une "lubie" de certains était une attente réelle obéissant à
ses propres règles bien fondées. Les modèles anglophones devront donc
ensuite s'adapter, et cela enrichira la concertation vers plus de monde
avec des moyens techniques différents et plus limités, et ensuite réviser
de façon fondée (et moins hostile) ce qui semblait une politique définitive
et inaltérable et revoir les méthodes de travail qui étaient bel et bien
inadaptées, radicales et donc obsolètes (et également source d'exclusion et
d'effritement progressif de la base d'utilisateurs excédés de voir leurs
efforts mal récompensés et partis ailleurs faire d'autres projets
indépendants, ou partis vers des plateformes commerciales, y compris les
réseaux sociaux ou moteurs bien connus, peut-être "fermées" mais qui elles
ont pris mieux en compte les besoins d'autres communautés dédaignées sur
Wikimedia ou OSM: que ce soit Google, Apple, Bing ou Baidu).

Le jeu. 28 nov. 2019 à 08:49, Topographe Fou <letopographefou at gmail.com> a
écrit :

> Bonjour,
>
> Tout à fait d'accord avec Yves : c'est même la raison d'être de wikidata,
> pas de remplacer wikipedia mais d'être une porte d'entrée vers les sites
> wikipedia, wikivoyages, wikinews... en plus d'être une base de données
> puissante, peu importe la langue et avec une promesse de maintenance
> réduite (tant qu'un Qxxxxx reste valide). De même que de pouvoir
> s'interfacer avec d'autres bdd qui utiliseraient cette clé publique comme
> osm. Ayant moi-même développé des moulinettes alliant wikipedia, wikidata
> et osm je vois bien la différence entre les deux clés. Et à ceux qui comme
> moi contribuent à Wikidata la mine d'information est énorme.
>
> Donc je pense qu'il faut encourager l'usage de cette clé, de manière
> consciente (je saisie le Qxxxx) comme de manière sympathique (petit moteur
> de recherche wikidata à condition que ce soit simple de vérifier si un item
> correspond bien à ce que l'on veut, car il y a bcp d'homonymes).
>
> Ceci étant dit il y a en effet fort à faire je pense niveau validation de
> tags wikipedia.
>
> Et pourquoi pas lancer un maproulette pour les erreurs détectées ?
> D'expérience c'est plus lent mais permet de détecter et corriger d'autres
> erreurs sur le même objet / à proximité. Effet de bord tirant la qualité
> vers le haut.
>
> LeTopographeFou
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20191128/d0f3f629/attachment.htm>