[OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.

Ven 28 Juin 17:59:13 UTC 2013

En quoi ton ID est meilleur ou constitue une référence stable ? Alors que
tu en es le seul auteur (même si tu utilises un algorithme, il va générer
un ID dans une base qui n'est pas réputée stable, ni utilisable à aussi
grande échelle que les IDs des instituts nationaux officiels (qui ont
démontré les employer et les maintenir depuis des années).

Le seul vrai problème des ID officiels est qu'ils omettent souvent de
mentionner leur année de référence. Mais quand ils l'indiquent, on omet
encore de mentionner cette date.

Et c'est là qu'il suffirait de compléter ces IDs avec la date (au moins
l'année) où on les a obtenus pour savoir s'ils correspondent encore à
quelquechose, et vers quel(s) autre(s) objets avec d'autres IDs ils ont
évolués  (pour peu que la source maintienne des infos sur les
transformations survenues, et qu'on puisse consulter ces historiques pour
trouver  des correspondances (de 1 vers 1 l'ID est conservé, mais de N vers
1, ou de 1 vers N, ou de N vers M c'est plus compliqué, mais on a tout de
même réduit l'espace de recherche pour se resynchroniser entre deux dates
de référence : l'indication de l'année permet de savoir où des ambiguités
sont apparues, et facilitera tout de même les rapprochements en réduisant
le nombre de vérifications à faire sur le terrain).

C'est là que:
- "ref=<ID>" peut devenir "ref:2000=<ID>", ou bien "ref=<ID>:2000" (plus
ambigu à interpréter selon les formats d'<ID> des sources) indiquées.
- "ref:<source>=<ID>" devient aussi "ref:<source>:2000=<ID>", ou
"ref:<source>=<ID>:2000" (même remarque)

La stabilité est ici apportée par l'année indiquée (si elle suffit à
déterminer une version). C'est ce qui permet de suivre les évolutions. Peu
importe l'année indiquée d'ailleurs tant qu'elle tombe dans la tranche de
date où l'identifiant à été constaté comme valide, mais si on veut
contrôler plus tard, on peut toujours vouloir mettre à jour cette date en
indiquant la date de dernière vérification.

Certaines bases de référence sont versionnées non pas par année mais par
numéro de version majeure (un changement de version majeure peut entraîner
parfois un changement de format de l'identifiant):
- "ref=<ID>" peut devenir "ref:v:<version>=<ID>", ou bien
"ref=<ID>:<version>" (plus ambigu à interpréter selon les formats d'<ID>
des sources) indiquées.
- "ref:<source>=<ID>" devient aussi "ref:<source>:v:<version>=<ID>", ou
"ref:<source>=<ID>:<version>" (même remarque)

(La remarque s'applique aussi aux tags similaires mentionnant des
identifiants, par exemple les codes ISO 3166 qui ont actuellement des tags
non préfixés par "ref:")

Le 28 juin 2013 16:49, Ista Pouss <istaous at gmail.com> a écrit :

> Le 28 juin 2013 16:18, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
>> Je suis aussi d'avis que ces IDs générés en interne par une base privée
>> sont du même type que ceux généras par un des nombreux services de type
>> TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
>> ni même librement utilisables (et sans suivi de leur utilisation par un
>> tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
>> données modifiées de son choix dans le trafic).
>>
>>
> Oui, bien sûr, ok, mais le mien ?? Moi c'est vachement mieux :-)
>
>
>
>> Si des IDs stables doivent exister pour référencer des objets OSM, ils
>> doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
>> des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
>> identifiants INSEE par exemple, librement vérifiables).
>>
>>
> Je n'empêche personne de procéder ainsi.
>
> Il me semble, toutefois, que la création de tels identifiants, nécéssite
> de poser le même genre de questions que celles que j'essaie de proposer :
> qu'est-ce qui caractérise un objet ? Qu'est ce qui permet de le reconnaître
> ? Qu'est ce qui définit leur égalité ? Comment les hasher ?
>
> Mais enfin, on verra.
>
>
> La "stabilité" des IDs est très relative : elle n'est garantie que si ils
>> sont datés avec leur date de validité, les objets référencés pouvant à tout
>> moment changer de statut. Si un ID stable devait être utilisé, il devrait
>> au minimum inclure l'année de leur création
>> - soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
>> ref:INSEE=35238),
>> - soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
>> d'avoir une autre clé pour d'autres années après un changement de l'objet
>> référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
>> autre voisine).
>> Ensuite à charge pour les outils de recherche et de mise en relation avec
>> d'autres bases de faire les correspondances avec ces IDs stables, en tenant
>> compte de l'année s'il y a des IDs différents pour la même base de
>> référence (ici celle de l'lNSEE).
>>
>>
> Oui, enfin bon, OK. La stabilité comme tu dis des ID est effectvement un
> problème, puisque l'objet peut se modifier de toutes formes.
>
> Mais, à l'inverse, on peut dire que les risques de modifications
> permanentes rendent plus intéressantes encore l'existence d'un ID :-)
>
>
>
>>
>> Les IDs externes ne sont utiles que si la base externe est bien la source
>> de référence principale et fiable de vérification des données (cette
>> fiabilité pouvant être garanti par la loi quand elle oblige une entité à
>> s'inscrire dans un registre officiel reconnu, dont le nombre est
>> relativement limité). S'il s'agit par exemple d'un point géodésique en
>> France, la base de référence française est bien connue et c'est d'elle
>> qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
>> ou d'un établissement de cette société, il n'y a que les identifiants au
>> RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
>> datés), mais on peut ajouter le numéro fiscal européen.
>>
>>
> Donc... les IDs externes sont bien intéressants, si je résume bien ta
> pensée ?...
>
> Merci :-)
>
> Cordialement.
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20130628/cc634115/attachment.html>