Le 7 novembre 2012 20:01, sly (sylvain letuffe) <li...@letuffe.org> a écrit : > Le mercredi 07 novembre 2012 19:38:33, f.dos.san...@free.fr a écrit : >> Pour supprimer les infos nominatives y compris de l'historique. > > Là, comme ça, c'est triste à dire, mais il me semble que compte tenu de la > difficulté à censurer l'historique,
Faux, quelle difficulté ? La fonctionnalité existe déjà et est même abondamment utilisée ! > il me semble peu probable qu'ils le fassent. > >> C'est l'exemple parfait de réutilisation du mécanisme du "redaction bot". Effectivement car le RedactionBot sait masquer des éléments de l'historique et c'est d'ailleurs ce qu'il a fait (il n'a pas fait de suppression réellement, mais a rendu ces données inaccessibles pour qu'elles ne soient plus diffusées publiquement), en utilisant une API avec un accès privilégié et authentifié. Un tel mécanisme de masquage existe aussi dans MediaWiki. Dans les deux cas il faut un compte administrateur habilité pour rendre un élément invisible dans l'historique (sans pour autant avoir besoin de modifier directement dans la base de données avec un accès SQL direct, ce qui n'est normalement utilisé que pour des opérations très précises de réparation et maintenance de la base de données, directement par quelques administrateurs systèmes désignés par la Fondation qui ont le devoir de limiter très strictement leurs opérations, ou alors de ne faire des suppressions physiques QUE suite à un ordre imposé, ou résoudre des problèmes techniques tels que des doublons empêchant la génération d'un index unique, sachant aussi que s'agissant des violations de lois d'auteur ou d'autres règles légales comme la protection de la vie privée dans les éléments publiés, la loi peut imposer à la Fondation de conserver des traces à disposition des autorités judiciaires au cas où elle recevrait des plaintes de victimes de ces violations), mais pas pour un bot qui interviendrait hors des période de sauvegarde pour archivage. Ce n'est que lorsque les données pour les archives légales sont sauvegardées ailleurs (sur un support inaccessible au public) que la base de données peut éventuellement être purgée des infos masquées (et la consultation des archives reste alors une opération privilégiée) : Cela pourrait être fait dans l'actuelle base il me semble sur les données CC-BY-SA non compatibles ODBL et sur leurs contributeurs, maintenant que ces données ont été toutes sauvegardées dans une archive contenant les données CC-BY-SA, afin de se prévenir d'un éventuel retour parasite de ces anciennes données, mais pour l'instant on en est encore à l'étape masquage, car certaines des données masquées n'étaient en fait pas la propriété de ceux qui les ont importées, mais d'une source qui a été reconnue comme compatible ODBL, et on assiste à quelques "résurrections" de données par endroit (après avoir obtenu un accord de la source initiale) Mais au lieu de les "ressusciter" des données par démasquage, on pourrait procéder par réimportation depuis les anciennes archives, avec les mêmes règles que pour les importations de données provenant d'une autre base, donc avec aussi des fusions et une supervision humaine (une fois qu'un extrait intéressant et compatible de l'ancienne base archivée sera rendue disponible à une telle réimportation, en ayant toutefois modifié l'indication de la véritable source autorisée, et non la source de l'ancien contributeur qui n'était pas titulaire des droits et n'a pas pu concéder lui-même une licence valide sur ces données). _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
