Différences

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

--- osug-dc:2-suivi_projets:doi:osug-doi [2019/01/22 14:30] – bourgesl
+++ osug-dc:2-suivi_projets:doi:osug-doi [2019/01/22 14:54] (Version actuelle) – bourgesl
@@ Ligne 27: / Ligne 27: @@
         - recréer vm doi.osug.fr (ansible) et déploiement application automatisé
-Architecture:
+Architecture générale:
 {{osug-dc:2-suivi_projets:doi:osug-doi.png}}
@@ Ligne 38: / Ligne 38: @@
 ==== Outil de génération des métadonnées DOI (datacite XML) ====
-Cas d'utilisation = AMMA-CATCH (voir http://bd.amma-catch.org/) ou OHMCV (fiches Sedoo)
+Cas d'utilisation = AMMA-CATCH (voir http://bd.amma-catch.org/) ou OHMCV (fiches Sedoo):
-=== Principe ===
 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):
@@ Ligne 57: / Ligne 54: @@
 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
-Gestion multi projets sur le serveur:
-        * conf (origine: git)
-            * AMMA-CATCH
-            * OHMCV
-            * projet ...
-        * staging
-            * AMMA-CATCH
-            * OHMCV
-            * projetX
-        * public
-            * AMMA-CATCH
-            * OHMCV
 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:
@@ Ligne 83: / Ligne 67: @@
 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
 {{osug-dc:doi:schema_fs.png}}
 === Chaine de fusion des informations (CSW + templates + URLs) ===
+Préparation CSW (AMMA-CATCH / OHMCV) (bash)
-{{osug-dc:doi:schema_process.png}}
+   - GetRecords -> renvoie autant d'élements <gmd:MD_Metadata/> qu'il y a de jeux de données
+   - Conversion au format CSV
 Séquence de traitement:
-   - GetRecords -> renvoie autant d'élements <gmd:MD_Metadata></gmd:MD_Metadata> qu'il y a de jeux de données
+   - Pour chaque jeu de données partiel (/inputs), fusionner avec les templates (ajout, pas de suppression):
-   - Conversion au format CSV
-   - Pour chaque jeu de données, 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)
-       - sauvegarder et convertir au format XML datacite
+   - Pour chaque jeu de données:
-   - validation des fichiers XML avec le schéma datacite
+       - vérifier les related identifiers (présent dans la BDD OSUG-DOI ?) pour tester les références invalides
-   - vérifier les related identifiers (existe en BDD ?) pour tester des références invalides ?
+       - convertir au format XML datacite
-   - vérifier les URLS (landing page externe et l'URL associée au DOI)
+       - validation du fichier XML avec le schéma datacite
-   - générer les landing pages associées (html) avec l'accès aux données (fragment html + URL)
+       - vérifier les URLs (landing page externe et l'URL associée au DOI)
-   - tester publication du DOI (metadata + URL OSUG-DOI) avec le préfixe de test: STAGING
+       - générer la landing page associée (html) avec l'accès aux données (fragment html + URL)
-   - sauvegarder les informations du DOI en BDD (statut, validation, 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 (publication ultérieure)
+   - 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) !
@@ Ligne 118: / Ligne 101: @@
-=== Chaine de fusion des informations (CSW + templates) ===
+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
 === Publication DOI (datacite) ===
-objectif: automatiser la publication des DOIs et alimenter la BDD (statut)
+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.
-TODO:
-   - 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
+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 ----