Ni Le 14 octobre 2014 14:38, Christian Quest <cqu...@openstreetmap.fr> a écrit :
> Pour moi pas de relation, *:wikipedia possible et *:wikidata préféré. > Ni l'un ni l'autre. Juste - "wikipedia=code-langue:Article" (pour la langue par défaut, généralement ça suffit pour trouver les infos Wikidata associées via ses liens interlangue pour Wikipédia, il n'est pas utile alors de multiplier les liens vers les autres éditions linguistiques) - "wikidata=Qnnn". Avantage: stabilité en cas de renommage/fusion, et Wikidata peut gérer les ancres dans les articles liés si nécessaire, ou bien référencer un lien de redirection vers une ancre d'un autre article qui a été fusionné localement dans Wikipédia sans avoir à mettre à jour Wikidata qui contient le no, d'article actuel. Inconvénient, cela demande plus de contrôle, on n'est pas à l'abri d'une faute de frappe sur un chiffre et la seule façon de la vor c'est consulter la fiche Wikidata et aller chercher son nom descriptif (s'il est disponible) ou des liens Wikipédia dedans; sinon des liens Commons (pages de galeries) sinon des liens de catégories. Les tags "*:wikipedia"=* n'existent pas, et "*:wikidata"=* non plus. En revanche on a bien des "wikipedia:*"=* (avec un code langue Wikimédia en suffixe). Attention car certains codes langue wikimédia sont non standards, mais certains controbuteurs d'OSM importent ces codes langue tels quels dans les tags "name:*"=* destinés aux traductions/transcriptions de noms ou descritions d'objet. Ces cintrobuteurs OSM font ces imports "foireux" uniquement parce qu'il existe par exemple des éditions linguistiques de Wikipédia utilisant encore ces codes ou des codes de variantes linguistiques non normalisés et spécifiques à Wikipédia dont la migration prend du temps, tels que "simple" ou "roa-rup" alors que "name:*" devrait toujours utiliser des codes BCP47 standards (donc "en" et pas "simple", ou "gsw" et pas "als"; "sr-latn" et pas "sr-el", ou "yue" et pas "zh-yue", ou "nan" et pas "zh-,in-nan"; ou "lzh" et pas "zh-classical"...). Nombreux sont ceux qui croient () tord) que les codes wiki des éditions linguistiques d'un projet Wikimédia sont des codes standards et ne font pas la distinction (alors que la distinction est en revanche demandée dans les traductions présentées dans le Wiktionnaire, en y utiisant les codes BCP47 standards...) Et la plupart confondent les codes BCP47 avec les codes ISO639 (alors que tous les codes ISO sont instables, ambigus, parfois obsolètes/dépréciés, voire même interdits dans BCP47, ou d'usage privé purement local au projet wiki, selon ses propres conventions, et non destinés à être interopérables d'une base de données à l'autre ou d'un site web à un autre) au carrément de format invalide pour BCP47 (exemple "roa-tara" pour la variété régionale tarandine de l'italien, qui n'a aucun code dans ISO639 ni dans la base IANA standard pour BCP47 ). Bref dans OSM on peut avoir - "wikipedia = roa-tara:Artcile en Tarandino" mais pas (dans les données de traductions optionnelles) - "wikipedia:roa-tara = Artcile en Tarandino" ni non plus - "name:roa-tara = Toponyme en Tarandino" Pour ce dernier mauvais tag faudra plutôt écrire - "name:it = Toponyme en Tarandino" ou mieux (si c'est diférent de l'italien standard) - "name:it-x-tara = Toponyme en Tarandino"(utilisation conforme de l'extension privée pour BCP47) ou - "alt_name:it = Toponyme en Tarandino" Les mêmes contributeurs parfois oublient de regarder dans quelle langue est réellement écrite la page, et importent aussi des éléments des noms de page qui ne sont là que pour désambiguer les homonymies (ces précisions n'ont pas leur place dans OSM où on utilise des tags séparés si nécessaire et la géolocalisation et la géométrie des objets comme discriminant). De même ils n'hésitent pas à importer des noms vernaculaires comme si c'était les noms officiels, ils importent des abréviations (souvent non homogènes ou encore plus ambigus et parfois aussi les fautes d'orthographe ou mauvais caractères). Enfin certains articles de Wikipédia portent sur des groupes d'objets codés séparément dans OSM (la pertinence des liens Wikipédia n'est pas toujours à 100%; au moins avec Wikidata on relève plus précisement les distinctions d'objets groupés dans le même article Wikipédia... jusqu'à ce que l'article devenu trop gros et indigeste soit restructuré et scindé en plusieurs sujets, par exemple pour séparer les éléments polémiques et présentant les avis et contre-avis dans des pages différentes ou des wikis différents) Notez qu'en cas de renommage d'un article, Wikidata est mis à jour mais la référence Qnnn est conservée. Cependant c'est plus co,pliqué à aller chercher et contrôler (sur Wikipédia les noms d'articles restent descriptifs et assez précis; sauf quand un article a été renommé avec une précision pour lever une ambiguité : Les outils de qualité d'OSM pourraient détecter les liens Wikipédia pointant maintenant sur une page d'homonymie pour trouver le nouveau nom; Wikidata a aussi ses propres outils de veille qualité des liens Wikipédia pointant sur des pages d'homonymies ou de redirection). Osmose pourrait aller chercher des références Wikipédia et proposer de les convertir en ré Wikidata; et pourrait aussi utiliser la base Wikimédia contenant les articles géolocalisés (Wikipédia utilise cette base pour ajouter sur le fond de carte OSM des POIs géoréférencés par l'article. Cela permettrait de proposer des intégrations, éventuellement précatégorisées poru générer quelques tags; à partir d'autres données de Wikidata (impossible de le faire fcilement depuis les articles et difficile à faire en interprétant les données des modèles d'infobox insérées dans les pages). Une autre analyse destinée à l'intégration sur Wikipédia ou Commons (catégories de lieux; ou pages de galeries) pourrait aussi ajouter générer des listes de pages à géolocaliser (par nsertion du modèle de géolocalisationà en affichant la géolocaisation trouvée dans OSM. LA collaboration peut se faire dans les deux sens (pas automatiquement, mais par des listes de proposition à contrôler/affiner. Cela demande de créer des filtres de recherche sur la base OSM (par exemple des requêtes overpass) générant des pages de liste dans un "wikiprojet" avec les liens des articles à créer ou modifier avec quelques données venues d'OSM, et en machant le travail de wikification. Ainsi on trouve dans Wikipédia, Commons, Wikinews des groupes de travail thématique dansun wikiprojet avec des contributeurs actifs pour intégrer/controler/améliorer/préciser/mettre à jour des données présentées dans les articles. Mais de plus en plus on va aller vers l'intégration non pas directement dans les pages Wikipédia, mais dans Wikidata (les pages Wikipédia iront lire Wikidata pour afficher les données par des modèles d'interrogation spécialisés selon le thème). Les utilisateurs participants de ces wikiprojets développent toute sortes de modèles/scripts Lua et gadgets assistants de modification, ils ont souvent les mêmes sources que les particpants OSM sur les mêmes sujets, et un certain nombre d'utilisateurs participent plus ou ,oins parallèlement aux deux projets OSM et Wikipédia pour croiser les infos et dénicher de nouvelles références et données libres. Jusqu'à encore pas si longtemps c'était Commons qui organisait la catégorisation entre les projets Wikimédia (après avoir été longtemps la Wikipédia anglophone), mais on va aller douvement mais surement de plus en plus vers Wikidata. Les possibilités d'intercations entre OSM et Wikimédia sont certainement plus aisées avec Wikidata qu'avec Wikipédia (dont les contenus ne s'organisent pas exactement de la même façon selon les éditions linguistiques, du seul fait qu'il n'est pas possible pour toutes les langues de développer autant de pages wiki que les grosses Wikipédies avec des centaines de millions de locuteurs de leur langue et des dizaines de milliers de contributeurs actifs chaque mois et encore plus de relecteurs qui font des contributions occasionnelles). Sinon au sein même de chaque Wikipédie (et même d'autres projets dont Commons qui est intéressé), il est fortement question de lui adjoindre une base Wikiata locale pour ses propres besoins. Et une première utiliation sera sans doute de faciliter la ,aintenance des catégories, voire même d'en générer le contenu et leur faire adopter diverses présentations avec des listes dynamiques multicritères, et un meilleur support linguistique dans la langue préférée du visiteur, même si le corps des articles (hors appels de modèles) n'est écrit que dans une langue et nécessite des auteurs et traducteurs qu'un robot ne pourra pas remplacer (mais les robots peuvent assister ce travail, notamment avec les outils de traduction en cours de développement et déploiement assez lent, et les améliorations des moteurs de recherche intégrés à MediaWiki, plus neutres et plus exhaustifs que les moteurs de recherche commerciaux meˆme s'ils proposent un filtre de "pertinence" par site).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
