Retour sur l’identifiant unique
C’est l’été, et manifestement des stagiaires ont été embauché(e)s pour « rendre le projet SIG Inspiro-compatible » (je cite). Je m’en réjouis, d’autant qu’aujourd’hui ils sont (un peu) rémunérés. Plusieurs questions portent sur les métadonnées.
Avertissement : je ne cache pas les limites de mes propres compétences : c’est pourquoi j’ai mis à jour le Wiki avec les éléments tirés de ce billet. De plus praticiens que moi sauront compléter ou corriger ce qui doit l’être.
La question, d’ailleurs bien documentée (c’est pour cela que la citation est longue), était la suivante.
J’étudie actuellement l’aspect de la normalisation des données et notamment des identifiants. Pour structurer les identifiants, je me suis basé sur mes différentes lectures et voici ce que j’en ai retenu :
- l’identifiant doit être unique mondialement
- Le consensus « français » semble se faire sur une intégration du code FR-n°SIREN-identifiant interne au producteur
J’aimerais connaître votre avis concernant notre solution pour structurer nos identifiants. Pour le moment nous nous dirigerions vers une structuration type suivante :
Exemple utilisé pour des données appartenant au SIG pour le suivi de l’entretien des rivières :
[ codeETAT.codeSIREN.Schéma.Thème.SousThème-XX.codeHydro ]
Avec Schéma = ENV (acronyme du thème Environnement);Thème = RIV (acronyme du thème Rivière); SousThème = STR (acronyme du thème Structure en charge de l’entretien); XX = ex. 01, 02, 03… (Identifiant variant de chaque tronçon); codeHydro = code hydro contenu dans la BD Carthage ex. M—009- (voulu par les services internes)
Dans la discussion téléphonique qui a suivi, j’ai émis les quelques conseils suivants :
- Conserver autant que possible l’identifiant du producteur original (pour le suivi des mises à jour, par exemple). Dans le cas d’une densification d’une base de donnée externe, essayer de conserver les données séparées. Seules les vôtres porteront votre n°SIREN.
- Nous savons que la suggestion française (sous l’égide du CNIG) rappelée ci-dessus pourrait être meilleure, et qu’il serait utile de les compléter par un code « lot » et un code « objet ». Ce n’est pas loin de la forme proposée dans la question. Toutefois, nous sommes en attente d’une proposition de la Commission européenne et nous ne pouvons pas préconiser une solution purement française.
- Par contre, l’identifiant interne du producteur peut tout à fait intégrer spontanément ces compléments. La seule précaution (impérative, selon moi) est d’avoir la capacité d’extraction/insertion de telle ou telle chaîne de caractère afin de se mettre en conformité, si besoin, par une simple moulinette.
- Le même travail d’experts recommandait d’éviter tout code signifiant, par exemple l’acronyme d’un service. L’identifiant est un code informatique interne, un acronyme n’apporte rien. Par contre, il est probable que personne ne le corrigera dans l’identifiant à chaque évolution de l’organisation…
- Il y avait une tentative de coder la généalogie de la donnée dans la métadonnée. C’est une dérive : il y a des champs pour cela.
- Notez que le code Etat sera soit FRE, soit FRA (le combat ISO 639-T vs ISO 639-B continue), mais pas FR.
Ce blog est suspendu pour 15 jours et pour perfectionner mon épanouissement personnel. En cas d’urgence, merci de poser vos questions sur la liste Géomatique…
Tags: CNIG, généalogie, identifiant, INSPIRE, métadonnées, producteur