Différences

Ci-dessous, les différences entre deux révisions de la page.

--- osug-dc:2-suivi_projets:doi:osug-doi [2018/07/16 14:40] – [OSUG-DOI (public)] bourgesl
+++ osug-dc:2-suivi_projets:doi:osug-doi [2019/01/22 14:54] (Version actuelle) – bourgesl
@@ Ligne 1: / Ligne 1: @@
 ====== OSUG-DOI (public) ======
-Source code:
+http://doi.osug.fr/
-https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi
-Roadmap:
-    * tests: metadata + soumission DOI de test: OK
-    * génération landing pages simples: OK
-    * génération metadata et landing pages pour amma-catch (pipeline iso 19-115 + templates csv): OK
-    * TODO List:
-        * TEST:
-        - publication DOI avec relatedIdentifier en test (lien invalide): fait = datacite ne vérifie pas la validité des relations
-        * DOC:
-        - faire un template CSV (with all possible key/values + comments)
-        - procédure à écrire pour un projet (templates, config...)
-        * DEV:
-        - création dépot DOI sur forge (sourcesup ?): OK
-        - packaging scripts, pipeline + configuration (templates), landing pages: OK
-        - améliorer landing page (html header / footer, about page): OK
-        - générer index.html pour lister les DOIs (staging / public): en cours
-        - gestion BDD:
-              - design des tables: projet et DOI: dates (génération, publication), état(staging/public), URL data access, URL landing page externe, URL landing page active: en cours
-        - améliorer scripts de publication pour gérer des dossiers staging et production (par projet) et modifier l'etat en BDD: en cours
-        - accès landing pages: gestion des redirections si landing page personnalisée (générer .htaccess)
-        - supervision pour detecter / signaler les URLs invalides (URL 404)
-        * PROD:
-        - création vm doi.osug.fr pour héberger toute la gestion (backoffice simple) et les landing pages
-            - demande: faite
-            - installation paquets (httpd + conf)
-            - installation pipeline + scripts
-            - installation BDD
-    * backoffice web de gestion/soumission DOI (futur)
 ===== Principe =====
@@ Ligne 41: / Ligne 11: @@
     * OSUG-DC: le serveur doi.osug.fr héberge les landing pages (en local) ou réalise une redirection vers un autre serveur (spip...) dans le périmètre de l'OSUG
     * les landing pages doivent être pérennes et contenir les instructions pour accéder aux données / services
 ===== Développement =====
-OSUG DOI: http://doi.osug.fr/
+Source code:
+https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi
+TODO:
+    * DOC:
+        - écrire la Procédure pour demander des DOIs (intro, approche, méta-données), initier un projet (templates, config...)
+        - créer template CSV (with all possible key/values + comments)
+    * DEV:
+        - supervision pour detecter les URLs invalides (URL 404) et basculer sur les landing page locales
+    * PROD:
+        - recréer vm doi.osug.fr (ansible) et déploiement application automatisé
+Architecture générale:
+{{osug-dc:2-suivi_projets:doi:osug-doi.png}}
 ==== Génération Landing Pages (datacite XML to HTML) ====
-A partir d'un document XML correspondant aux métadonnées du DOI (datamodel datacite), une transformation XSLT génère une page HTML statique (bootstrap + CSS) qui affiche simplement les méta données.
+A partir d'un document XML correspondant aux métadonnées du DOI (datamodel datacite), une transformation XSLT génère une page HTML statique (bootstrap + CSS) qui présente simplement les méta données et les instructions d'accès aux données / service.
-Cependant, il manque les informations pour l'accès aux service / données dans le document XML (datacite).
-TODO:
+==== Outil de génération des métadonnées DOI (datacite XML) ====
-    * trier les meta données selon le document AMMA-CATCH: OK
-    * ajouter un page footer (date + lien vers OSUG-DOI): OK
-    * rajouter les instructions d'accès aux données via un fragment HTML (fichier dans config); si manquant, prévoir une phrase par défaut
-    * rajouter l'URL de destination pour accéder aux données
-    * revoir le page header (optionnel)
-    * générer l'index pour staging / public
-Proposition: fournir ces paramètres à la transformation XSLT récupérés depuis la configuration (projet ou du jeu de données pour URL) depuis les templates CSV (data_access:URL et data_access:information) ou la BDD ?
+Cas d'utilisation = AMMA-CATCH (voir http://bd.amma-catch.org/) ou OHMCV (fiches Sedoo):
-==== Outil de génération des métadonnées DOI (datacite XML) à partir des méta données ISO-19139 (CSW) ====
-Cas d'utilisation = AMMA-CATCH (voir http://bd.amma-catch.org/amma-catch2)
+Certaines meta-données sont déjà renseignées pour chaque jeu sur le portail Web d'accès aux données AMMA-CATCH et sont récupérables en utilisant le webservice CSW méthode getRecords (format XML ISO 19139):
+http://bd.amma-catch.org/amma-catchWS2/WS/csw/default?service=CSW&request=GetRecords&version=2.0.2&typenames=csw:Record&resulttype=results&maxrecords=100&elementsetname=summary&outputschema=http://www.isotc211.org/2005/gmd
-=== Principe ===
+Il faut ensuite les compléter pour produire un fichier XML complet (dataCite) pour chaque jeu de données.
-Certaines infos nécessaires au schéma datacite sont déjà renseignées pour chaque jeu sur le portail Web d'accès aux données AMMA-CATCH et sont récupérables par http en utilisant le webservice CSW méthode getRecords (format XML ISO 19139): http://bd.amma-catch.org/amma-catchWS2/WS/csw/default?service=CSW&request=GetRecords&version=2.0.2&typenames=csw:Record&resulttype=results&maxrecords=100&elementsetname=summary&outputschema=http://www.isotc211.org/2005/gmd
+Solution: pour rester indépendant du format datacite (XML), des fichiers CSV (clé / valeur) sont utilisés pour définir tout ou partie des méta-données.
-Il faut ensuite les compléter pour produire un fichier XML DataCite pour chaque jeu de données.
+=== Configuration d'un projet ===
-=== Chaine de fusion des informations (CSW + templates) ===
+Un projet dans l'outil OSUG-DOI correspond à un ensemble de DOIs au préfixe commun, comme un service d'observation, un data paper.
-Pour compléter les metadonnées, des templates (global, pays et jeu) au format CSV sont utilisés.
+Toute la configuration du service OSUG-DOI avec tous les projets est archivée dans git (forge gricad):
+https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi/tree/master/conf
-{{osug-dc:doi:schema_process.png}}
+Pour compléter les metadonnées obtenues du webservice CSW, des templates (global, par pays, par jeu de données) au format CSV sont utilisés:
+https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi/tree/master/conf/AMMA-CATCH/templates
-Séquence de traitement:
+Pour indiquer l'URL d'une landing page externe (spip...), le fichier doi_url_landing_page.csv ( table [DOI suffix :: URL (absolue) ] ) est utilisé:
-   - GetRecords -> renvoie autant d'élements <gmd:MD_Metadata></gmd:MD_Metadata> qu'il y a de jeux de données à condition d'indiquer le paramètre maxrecords dans l'URL
+https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi/blob/master/conf/AMMA-CATCH/doi_url_landing_page.csv
-   - Conversion au format CSV
-   - Pour chaque jeu de données, fusionner avec les templates:
-       - template global: template_all.csv
-       - template pays: correspondant au pays indiqué par geoLocationPlace (geoLocationPlace;Benin)
-       - template spécifique au jeu de données: correspondant à l'identifiant indiqué par identifier (identifier:DOI;10.5072/AMMA-CATCH.CL.Run_O)
-       - sauvegarder et convertir au format XML datacite
-   - validation des fichiers XML avec le schéma
-   - vérifier les related identifiers (existe en BDD ?) pour tester des références invalides ?
-   - générer les landing pages associées
-   - tester publication du DOI (metadata + URL) avec le préfixe de test: STAGING
-   - sauvegarder les informations du DOI en BDD (statut des étapes de traitement, URL ...)
+Pour donner l'URL associée réellement au DOI (accès aux donnés), le fichier doi_url_data_access.csv ( table [DOI suffix :: URL (absolue) ] ) est utilisé:
+https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi/blob/master/conf/OHMCV/doi_url_data_access.csv
+Si le DOI ou ce fichier est absent, la valeur par défaut définie dans le fichier project.properties (dataAccessUrl=...) est utilisée.
-Note: les identifiants DOI doivent contenir que le préfixe de test (publication ultérieure) et les méta-données en doublons sont ignorées (même clé / valeur) mais attention si les informations ne sont pas disjointes (clés présentes dans plusieurs templates)
+Pour définir les instructions d'accès aux données, il faut fournir le fragment HTML:
+https://gricad-gitlab.univ-grenoble-alpes.fr/OSUG/DC/osug-doi/blob/master/conf/AMMA-CATCH/access_instruction.html
-Attention à l'encodage des fichiers CSV (utf-8 sous linux et iso-8859-1 sous windows) !
+{{osug-dc:doi:schema_fs.png}}
-TODO:
-    * généraliser à d'autres services CSW en externalisant toute la configuration du pipeline dans un fichier (clé=valeur) par projet: en cours
-    * validation: vérifier la présence de méta-données (en plus, de la validation xml assez laxiste) comme dataAccess:URL ...
-    * comment gérer la mise à jour des templates CSV ? manuel dans un premier temps; plus tard: via owncloud.osug.fr ou via interface d'administation
-Gestion multi-projet dans le file system:
+=== Chaine de fusion des informations (CSW + templates + URLs) ===
-        * config
-            * AMMA-CATCH
-            * projetX
-        * staging
-            * AMMA-CATCH
-            * projetX
-        * public
-            * AMMA-CATCH
+Préparation CSW (AMMA-CATCH / OHMCV) (bash)
+   - GetRecords -> renvoie autant d'élements <gmd:MD_Metadata/> qu'il y a de jeux de données
+   - Conversion au format CSV
-{{osug-dc:doi:schema_fs.png}}
+Séquence de traitement:
+   - Pour chaque jeu de données partiel (/inputs), fusionner avec les templates (ajout, pas de suppression):
+       - template global: template_all.csv
+       - template du pays: correspondant au pays indiqué par geoLocationPlace (geoLocationPlace;Benin)
+       - template spécifique au jeu de données: correspondant au suffixe du DOI (identifier:DOI;10.5072/AMMA-CATCH.CL.Run_O)
+   - Pour chaque jeu de données:
+       - vérifier les related identifiers (présent dans la BDD OSUG-DOI ?) pour tester les références invalides
+       - convertir au format XML datacite
+       - validation du fichier XML avec le schéma datacite
+       - vérifier les URLs (landing page externe et l'URL associée au DOI)
+       - générer la landing page associée (html) avec l'accès aux données (fragment html + URL)
+       - tester la publication du DOI (metadata + URL OSUG-DOI) avec le préfixe de test: STAGING
+       - sauvegarder l'état du DOI en BDD (statut, validation, URL ...)
+   - ré-générer les pages d'index, de rapport d'erreur (STAGING) et les redirections(/r) (internes + landing pages externes)
+{{osug-dc:doi:schema_process.png}}
+Notes:
+   - les identifiants DOI présents dans la configuration (CSV) ne doivent contenir que le préfixe de test 10.5072 (publication ultérieure)
+   - les méta-données en doublons sont ignorées (même clé / valeur) mais attention si les informations ne sont pas disjointes (clés présentes dans plusieurs templates)
+   - attention à l'encodage des fichiers CSV (UTF-8 sous linux et iso-8859-1 sous windows) !
+   - il est possible d'utiliser des fichiers Excel pour saisir les templates (qui seront convertis correctement en CSV)
-=== Publication DOI (datacite) ===
+Pendant la phase de préparation ou de mise à jour des DOIs, il faut éditer les fichiers CSV, relancer la chaine de traitement et vérifier les résultats en STAGING:
+http://doi.osug.fr/staging/index.html
-objectif: automatiser la publication des DOIs et alimenter la BDD (statut)
-TODO:
+=== Publication DOI (datacite) ===
-   - copier la landing page (URL publiée chez datacite): PUBLIC
-   - reécrire les identifiants DOI (identifier et relatedIdentifier) pour remplacer le préfixe de test en préfixe OSUG à l'aide de la base de données
-   - publier ce DOI avec le préfixe OSUG et mettre à jour la BDD
-   - gérer les redirections ie une URL alternative pour la landing page
-note: garder les documents XML + URL dans le file system et BDD
+Lorsqu'un ou plusieurs DOIs sont valides et vérifiés, il est possible de publier le DOI sur datacite (attribution) ce qui le rend pérenne.
+Séquence de publication d'un DOI:
+   - vérifications
+   - copier les méta-données XML (datacite)
+   - ré-écrire les identifiants DOI (identifier et relatedIdentifier) pour remplacer le préfixe de test 10.5072 en préfixe OSUG
+   - générer la landing page en PUBLIC (URL publiée chez datacite)
+   - publier le DOI (metadata + URL OSUG-DOI) avec le préfixe OSUG
+   - mettre à jour l'état du DOI en BDD
+   - ré-générer les pages d'index et les redirections(/r) (internes + landing pages externes)
 ---- struct data ----