Identifiant permanent de la DEE Définition opérationnelle dans le cadre du SINP pour la thématique occurrence de taxon



Documents pareils
Je catalogue, tu FRBRises, il/elle googlise. L évolution des catalogues et les bibliothécaires Vendredi 29 mars 2013 Manufacture des tabacs

Présentation du SINP. DGALN/DEB/PEM4 mai 2014

Créez votre propre Archive Darwin Core

Le portail des MSH

Présentation générale du projet data.bnf.fr

Un exemple d'authentification sécurisée utilisant les outils du Web : CAS. P-F. Bonnefoi

Cours Base de données relationnelles. M. Boughanem, IUP STRI

Programmation Web. Introduction

Bien architecturer une application REST

Application des Spécifications détaillées pour la Retraite, architecture portail à portail

Mise en œuvre de l architecture SINP. Forum ATEN des TIC 4 juin Y. Lebeau MEDDE/DGALN/DEB/PEM4

Architectures web/bases de données

Les infrastructures de clés publiques (PKI, IGC, ICP)

4. SERVICES WEB REST 46

Le signalement des acquisitions numériques à l échelle nationale Le rôle du hub de métadonnées scénarios et prototype

Quel ENT pour Paris 5?

Appui SIE :Développement de services web ADES/SIE

L archivage pérenne du document numérique au CINES. CINES (O.Rouchon) JRES Novembre 2007

«Clustering» et «Load balancing» avec Zope et ZEO

Plateforme PAYZEN. Intégration du module de paiement pour la plateforme Magento version 1.3.x.x. Paiement en plusieurs fois. Version 1.

ACCORD-CADRE DE TECHNIQUES DE L'INFORMATION ET DE LA COMMUNICATION. PROCEDURE ADAPTEE En application des articles 28 et 76 du Code des Marchés Publics

Exploration des technologies web pour créer une interaction entre Mahara et les plateformes professionnelles et sociales

Compte Rendu d intégration d application

Les Architectures Orientées Services (SOA)

Annuaires LDAP et méta-annuaires

Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants

Créer et partager des fichiers

Dossier Technique. Détail des modifications apportées à GRR. Détail des modifications apportées à GRR Le 17/07/2008. Page 1/10

GEI 465 : Systèmes répartis

L optimisation d une PowerBoutique pour le référencement

WEB & DÉVELOPPEMENT LES BASES DU WEB LE LANGAGE HTML FEUILLES DE STYLES CSS HISTORIQUE D INTERNET ET DU WEB LES DIFFÉRENTS LANGAGES

Learning Object Metadata

Les documents primaires / Les documents secondaires

BES WEBDEVELOPER ACTIVITÉ RÔLE

Architecture Orientée Service, JSON et API REST

L archivage pérenne du document numérique au CINES. CINES (O.Rouchon) Rencontres RNBM 3 Octobre 2007

Brique BDL Gestion de Projet Logiciel

UE 8 Systèmes d information de gestion Le programme

Mise en œuvre des serveurs d application

Manuel d'installation de GESLAB Client Lourd

INTERNET est un RESEAU D ORDINATEURS RELIES ENTRE EUX A L ECHELLE PLANETAIRE. Internet : interconnexion de réseaux (anglais : net = réseau)

Manuel d utilisation du site web de l ONRN

La reconquête de vos marges de manœuvre

Eric Bertrand 08/11/06 Maître de conférence 1

Applications et Services WEB: Architecture REST

Gestion d identités PSL Exploitation IdP Authentic

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

Plateforme Systempay. Correspondance entre SP PLUS et SYSTEMPAY Paiement Simple et en plusieurs fois

Infrastructure / réseau / sécurité /support utilisateur

En quoi consiste le REFERENCEMENT de votre site?

Mercredi 15 Janvier 2014

GBIF Système mondial d'information sur la biodiversité

Mise en place d'un serveur d'application SIG au Conseil général de Seine-et-Marne

Description de Produit Logiciel. AMI News Monitor v2.0. SPD-AMINM-10 v1.0

Bases de données documentaires et distribuées Cours NFE04

Catalogue des formations Edition 2015

Examen de la saisine Définition de l'architecture du SINP. Contributeurs : Frédéric Gosselin, Pascal Dupont

Hébergement de site web Damien Nouvel

arcopole Studio Version 3.3

Groupe de travail Gestion des identités Les usages et les services ATELIER 2

AMUE : PRISME - Référentiel des données partagées. 3 décembre 2009

Formation SSO / Fédération

DESCRIPTION DU PLUGIN D AUTHENTIFICATION AVEC CAS POUR SPIP

Mercredi 05/10/2011. Forges logicielles. Olivier Berger, Telecom SudParis. Introduction Avant-propos À propos de COCLICO. Panorama des forges

21 mars Simulations et Méthodes de Monte Carlo. DADI Charles-Abner. Objectifs et intérêt de ce T.E.R. Générer l'aléatoire.

Rédaction Anne- Sophie Archambeau (GBIF France) Participants. Thomas Changeux. Michel Guiraud

L impact du programme de relance sur le projet régional 19/05/2009 COPIL AMOA 1

E-TRANSACTIONS. Guide du programmeur API Plug-in. Version 1.1

HEXAPOSTE NV 2011 SERVICE NATIONAL DE L ADRESSE : 15 RUE DE LHOUSTEAUNEUF - BP LIBOURNE CEDEX 1

Technologies du Web. Créer et héberger un site Web. Pierre Senellart. Page 1 / 26 Licence de droits d usage

Formation Webase 5. Formation Webase 5. Ses secrets, de l architecture MVC à l application Web. Adrien Grand <jpountz@via.ecp.fr> Centrale Réseaux

Authentification et contrôle d'accès dans les applications web

contact@nqicorp.com - Web :

Le modèle de données

Recommandations pour la protection des données et le chiffrement

4. Personnalisation du site web de la conférence

CRÉER SON SITE INTERNET. Créer son site Internet. Méd de Roanne. FG 16/09/08

PROJET DE PORTAIL INTRANET YNNA

XML, PMML, SOAP. Rapport. EPITA SCIA Promo janvier Julien Lemoine Alexandre Thibault Nicolas Wiest-Million

contact@nqicorp.com - Web :

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts

COMPRENDRE L ARCHITECTURE DES WEB SERVICES REST. Amosse EDOUARD, Doctorant

Installer un espace de travail collaboratif et d e learning.

LES TOUT PREMIERS PAS

SIP A. Aoun - La Visioconférence SIP - 1

Groupe de travail Low Cost. Frédéric DIDIER Jacques WITKOWSKI

Programmation Web Avancée Introduction aux services Web

Guide d implémentation. Réussir l intégration de Systempay

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Configuration du FTP Isolé Active Directory

Déploiement des manuels numériques sur tablette. Mode d emploi intégrateur / administrateur

MINISTÈRE DES SOLIDARITÉ ET DE LA COHÉSION SOCIALE

.NET remoting. Plan. Principes de.net Remoting

Authentifications à W4 Engine en.net (SSO)

Manuel d Utilisation Nouvelle Plateforme CYBERLIBRIS : ScholarVox Management

Catalogue des Formations Techniques

Patrons de Conception (Design Patterns)

Datalift. + + Architecture Modularité Déploiements. d j = 09/04/2015 Laurent BIHANIC

Introduction. aux architectures web. de Single Sign-On

Transcription:

Identifiant permanent de la DEE Définition opérationnelle dans le cadre du SINP pour la thématique occurrence de taxon Julie Chataigner (MNHN/SPN), Laurent Poncet (MNHN/SPN), Marie Elise Lecoq (GBIF France), Simon Chagnoux (MNHN/DSI), Frédéric Vest(MNHN/SPN) Relecture du GT Standard de données Avril 2014 1 Introduction... 1 2 Choix de l identifiant permanent... 2 3 Outils et «briques» nécessaires... 4 4 Processus... 5 1 Introduction L objectif de ce document est de présenter l identifiant permanent de la donnée élémentaire d échange (DEE) du SINP. Ce travail a fait l objet d un sous groupe de travail rassemblant des structures ayant expérimentées la mise en place d identifiants permanents : le SPN du Mnhn, le service des collections du Mnhn et le GBIF France. Le protocole du SINP indique que l identifiant permanent du SINP porte sur la Donnée Elémentaire d Echange (DEE). En effet une observation peut être représentée par plusieurs «objets» cf Figure 1. Chacun de ces objets est donc susceptible d être identifié, mais seule la DEE doit l être au niveau national. Pour rappel, les DEE sont des données standardisées interopérables. Elles sont élaborées à partir des données source (DS) selon un format standard national propre à chaque thématique du SINP (observations de biodiversité, paysages, espaces protégés, etc) La photo de l observation Le specimen La donnée source (DS) La donnée élémentaire d échange (DEE) Figure 1. Exemples de différents objets pouvant être identifiés à partir d une seule observation 1

2 Choix de l identifiant permanent 2.1 Proposition du GBIF Cette partie du document reprend la conclusion de la solution technique proposée par le GBIF et décrite dans le document analyse_identifiant_gbif_20131025.pdf 1 L analyse du GBIF France conclue sur l utilisation d une solution d identifiant permanent clé en main pour les utilisateurs non avertis sans empêcher des plateformes ayant des ressources nécessaires de développer leurs propres algorithmes. L analyse propose de se baser sur : une architecture permettant potentiellement d accéder à la donnée en URL. Le type d URL (PURL, ) relève de l architecture et n est pas développé dans ce document. un UUID : Suite alphanumérique pseudo aléatoire générée par des algorithmes assurant à très forte probabilité le caractère unique de l identifiant dans le monde. L'UUID est normalisé par l'iso/iec 9834 8:2008. Son format est le suivant : XXXXXXXX YYYY ZZZZ AAAA BBBBBBBBBBBB. Exemple : a0eebc99 9c0b 4ef8 bb6d 6bb9bd380a11. Ainsi la structure de l identifiant proposée est la suivante : http://www.autorité/contexte/resourcepath/objet Avec Autorité : nom de la plateforme nécessitant un nom de domaine pérenne. Si la plateforme est capable de gérer son infrastructure, la création, la gestion et la maintenance des noms de domaine peuvent se faire par la plateforme, sinon elle peut être faite au niveau national. Au niveau national, seul l annuaire des noms de domaine des plateformes régionales et thématiques devra être impérativement mis à jour et disponible. Contexte : le contexte représente les jeux de données ou les fournisseurs. Ils sont identifiés via un code. Deux solutions sont proposées : les Digital Object Identifier 2 (DOI) ou un code. S il est souhaité de garder une homogénéité au niveau du territoire, le code devra être défini au niveau national sinon le choix de la codification peut être laissé libre aux plateformes tout en préconisant une organisation. Resource Path : (facultatif) définition du périmètre de l URL : spécification d une unique localisation pour les informations d une même ressource. Même logique que de créer un répertoire pour y localiser les informations d un même sujet. Ici, pour les données de jeux de données cela serait «data». Objet : L objet représente l occurrence. C est à ce niveau qu est mis en place l UUID. Aujourd hui, la plupart des SGBD ont pris en compte un champ spécifique UUID. Attention, l UUID ne remplacera pas la clé primaire. L objet ne doit pas être lié au type de technologie utilisé. D où la proposition : http://nom_plateforme.org/data/nom_jeu_donnee/uuid. Précisions sur la proposition : Une URL peut être utilisée comme identifiant, sans UUID pour identifier l objet. Cependant dans ce cas, si l autorité ou le contexte change alors on est susceptible de perdre l unicité et la permanence de l identifiant de la donnée. De plus, cela implique potentiellement de nombreuses variantes dans la création de l identifiant de l objet, rendant leur unicité incertaine au niveau national. 1 Lecoq M E., (2013) Analyse et proposition d identifiant permanent pour le SINP, GBIF France, 23 pp 2 Le système DOI fournit des outils pour gérer et identifier de façon pérenne les objets numériques. Les DOI sont standardisés et payants. 2

L UUID utilisé sans URL est complètement opaque et permet de limiter les essais d interprétation de la donnée à partir de son identifiant. C est un identifiant permanent robuste mais il ne permet pas d accéder directement à la donnée. Ainsi, utiliser un identifiant combinant ces 2 types d identifiant permet de cumuler leurs avantages sans créer de plus grands inconvénients : Accès à la donnée rendu possible par l URL Pérennité accrue de la donnée via la pérennité du nom de domaine Unicité assurée par la combinaison de l URL et l UUID Compromis entre opacité de l identifiant et information sur l objet identifié. En effet, l URL donne un minimum d information sur la donnée échangée (nom de la plateforme, prise de connaissance que la donnée échangée concerne une donnée d une plateforme régionale ou thématique, une URL pouvant identifier divers objets comme un document, un film, une page web ) Pour plus d informations techniques, se référer au document du GBIF. 2.2 Proposition finale au SINP 2.2.1 Cas général Nous proposons de retenir la proposition du GBIF avec les quelques modifications et remarques suivantes : L autorité : nom de domaine de la plateforme. Le contexte : comme l identifiant est rendu unique par l UUID, et que le contexte est seulement un élément du lien pour accéder aux données, il est proposé de ne pas l utiliser. Ainsi, l identifiant permanent gagne en concision et en robustesse. Le Resource Path : Cet élément permet de définir des périmètres suivant les thématiques du SINP. Pour la thématique du standard «occurrence de taxon», il est proposé de nommer le resourcepath : «occtax» L objet correspondant à l identifiant de l occurrence est l UUID. D où la proposition : http://nomdomainedelaplateforme/thematique/uuid Remarque sur la résolution de l identifiant : L identifiant est une URL permettant l accès à la donnée. Ainsi, le résultat qu il donne peut être : une erreur (de type erreur 404) une ressource (page HTML ou RDF) décrivant les données de l observation. un renvoi http vers une autre ressource utile à la personne ou à la machine s intéressant à l occurrence désignée par l URI (approche du linked data) Bien que potentiellement accessible via l identifiant unique, la donnée sera aussi diffusée avec l ensemble des attributs qui la compose par les plateformes du SINP. 2.2.2 Exemples Cas de données transitant par la plateforme thématique «occurrence de taxon» : exemple des données de collection du Mnhn. Les données de collection du Mnhn sont des données d emprise nationale. Les DEEs sont donc créées par la plateforme thématique «occurrence de taxon». Ainsi, dans le SINP, la DEE issue de cette DS de collection aura pour : 3

IdentifiantPermanent : http://nomplateformethematiqueoccurrencetaxon/occtax/a0eebc99 9c0b 4ef8 bb6d 6bb9bd380a11 IdentifiantOrigine : http://coldb.mnhn.fr/catalognumber/mnhn/ec/ec3060 L identifiantorigine étant l identifiant des occurrences de specimen propres aux bases de collection du Mnhn. Comme l'identifiant est celui de l objet physique (le specimen), la résolution de l identifiant est une redirection vers une page web sur le specimen. Cas de données transitant par une plateforme régionale Dans le cas d une DEE créée par une plateforme régionale : identifiantpermanent : http://nomplateformeregionale/occtax/f0eevc75 9c0b 4ef8 bz7z 8zb9bz380g15 IdentifiantOrigine : identifiant du producteur Remarque : le nom des autorités (domaine des plateformes) de ces exemples sont théoriques. Ils sont à définir par qui de droit. 3 Outils et «briques» nécessaires 3.1 Annuaire des autorités : nom de domaine décliné par plateforme L annuaire des autorités doit être partagé et géré au niveau national. Dans le cas du SINP, il liste le nom de chaque plateforme. La définition des règles de nommage et de gestion des domaines sont du périmètre de l architecture du SINP et/ou des responsables des plateformes. L identifiant étant basé sur une URL dont l intérêt est de pouvoir être résolu, il faut que les noms de domaine soient pérennes et que les responsables des URL aient les moyens techniques de rediriger les URLs. Le format et les informations nécessaires dans l annuaire dépendent des composants logiciels des plateformes et l usage qu ils en feront. Une ressource XML ou JSON statique donnant une liste de {nom de domaine, regexp de l'identifiant, email de contact} pourrait suffire. 3.2 Resource Path Il est nécessaire de définir une liste de valeur disponible au niveau national. Cette liste peut être proposée par le GT Standard de données, au fur et à mesure de la définition des thématiques dans le SINP. 3.3 Objet de l identifiant : algorithme L objet peut être directement mis en place et géré par les plateformes régionales ou thématiques. Des algorithmes pour générer les UUIDs sont disponibles dans des bibliothèques java, python, C++ etc, et dans les modules de base de données (PostgreSQL, Oracle etc). 3.4 Ressources humaines et matérielles Les compétences suivantes sont requises pour créer et gérer l identifiant permanent au niveau des plateformes régionales et thématiques et de la plateforme nationale : animateur national administrateur et gestionnaire «données» au niveau plateforme administrateur technique de la plateforme hébergeur de la plateforme 4

4 Processus La mise en place d un identifiant permanent de la DEE homogène et partagé par l ensemble des plateformes du SINP proposé dans ce document n empêche pas l existence d un identifiant régional sur la donnée dans le format régional. La possibilité de véhiculer l identifiant régional au niveau national en plus de l identifiant permanent national et de l identifiant origine de la donnée peut être discutée et pourra amener à l ajout de cet attribut dans le standard DEE «occurrence de taxon». 4.1 Processus d attribution de l identifiant à la DEE Les attributions d identifiant permanent national à une DEE sont faites par les plateformes régionales et thématiques. Cet identifiant est ensuite retourné au producteur et/ou fournisseur de la donnée source. Sa prise en compte dans leurs systèmes n est pas obligatoire mais fortement conseillée. 4.2 Processus d évolution de la DEE Afin de rester robuste et simple dans la mise en œuvre, l identifiant permanent ne gère pas le suivi des modifications ou de suppressions logiques d une occurrence. Il faudra que cela soit porté dans les bases de données du SINP et dans le standard d échange (exemple : date de dernière modification). De plus, l identifiant concerne l ensemble des champs (attributs) de l occurrence sous sa forme DEE. Par exemple, si des attributs facultatifs du standard sont ajoutés à l occurrence, ce n est pas considéré comme une nouvelle occurrence : l identifiant de la DEE reste le même. 5