Dernières mises à jour de Nakala (API, Front et NAKALA_PRESS)¶

05-05-2025 (FRONT 3.17.0 - NAKALA_Press 1.7.0)¶

Nouveautés¶

Référencement de NAKALA par Google¶

Les dépôts et collections publiques sont référencés par le moteur de recherche Google via le protocole sitemap qui liste les URLs, selon les recommandations de Google.

Corrections¶

NAKALA_Press¶

Pour améliorer le résultat final des sites NAKALA_Press, des bugs ont été résolus concernant :

l’affichage des rubriques d’un menu de navigation, et de l’en-tête des pages (bandeau et logo)
sur la consultation de vidéos embarquées dans une balise (affichage plein écran et lecture sans interruption)
l’affichage des titres en différentes langues lors de la navigation entre les interfaces multilingues

18-04-2025 (API 3.22.0 - FRONT 3.16.0)¶

A/ Nouveautés¶

Liste des sites NAKALA_PRESS¶

“Liste des sites web nakalapress” ajouté en bas de page permet d’afficher la liste de tous les sites créés par les utilisateurs de NAKALA avec le module NAKALA_Press.

API : rechercher par mots-clés avec le endpoint /search¶

Une facette et un filtre de recherche sur les mots-clés (dcterms:subject) ont été mis en place dans le endpoint /search pour NAKALA_Press.

B/ Corrections¶

Informations sur les fichiers¶

Le bug d’affichage qui impactait les dépôts avec un nombre important de fichiers a été résolu.

Doublons dans la base Auteurs¶

Des bugs côté API ont été identifiés qui permettaient la création dans la base des auteurs de NAKALA, des doublons d’auteurs (même nom, prénom, ORCID). Ces bugs ont été corrigés.

03-04-2025 (API 3.21.0 - FRONT 3.15.0)¶

A/ Nouveautés¶

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Suppression de 3 encodages qui étaient proposés comme ‘Type’ :

dcterms:IMT (Internet Media Type)
dcterms:LCC (Library of Congress Classification)
dcterms:MESH (Medical Subject Headings)

Dans le cadre de la mise en œuvre technique de cette suppression, cette information d’encodage a disparu des métadonnées qui avaient utilisé ces encodages dans les dépôts. En revanche, les valeurs de ces métadonnées n’ont pas été modifiées.

Suppression de l’encodage dcterms:IMT¶

Cet encodage fait référence aux types de Media (MIME Types) spécifiés par IANA (Internet Assigned Numbers Authority). Aujourd’hui, cette information est calculée automatiquement par Nakala de manière fiable et reportée dans la description technique de chaque fichier d’un dépôt. Permettre au déposant de définir manuellement cette information représentait donc une source de conflit.

Suppression de l’encodage dcterms:LCC¶

L’encodage dcterms:LCC qui renvoie au système de classification de la Library of Congress a été très rarement utilisé. Il semble donc peu pertinent de le conserver dans le contexte de NAKALA.

Suppression de l’encodage dcterms:MESH¶

L’encodage dcterms:MESH renvoie au thésaurus MeSH (Medical Subject Headings) qui structure les mots-clés sujets produits par la National Library of Medicine pour les informations biomédicales et relatives à la santé. Ce thésaurus n’ayant pas été utilisé, il apparaît inadapté dans le contexte de NAKALA.

Limitation de propriétés aux collections¶

Limitation de l’utilisation de 3 propriétés aux collections :

dcterms:accrualMethod
dcterms:accrualPeriodicity
dcterms:accrualPolicy

Ces propriétés étaient mises à disposition pour la description des dépôts et des collections. Or dans le Dublin Core, ces propriétés sont destinées à décrire une collection. Pour être en cohérence, Nakala met à disposition ces propriétés uniquement dans le modèle de description d’une collection.

Endpoint pour lister les sites NAKALA_PRESS¶

Un nouveau endpoint a été créé dans l’API qui permet de lister les sites publics développés avec NAKALA_PRESS à partir d’une collection de dépôts dans NAKALA.

Informations sur les fichiers¶

Les informations concernant chaque fichier d’un dépôt seront visibles dans la page de présentation du dépôt, au niveau de la visionneuse. Les informations dorénavant affichées pour un fichier : nom, extension, taille, description (le cas échéant).

Demande de moissonnage d’une collection par ISIDORE¶

Pour faciliter le signalement d’une collection NAKALA dans le moteur de recherche ISIDORE, un bouton “Signaler cette collection dans ISIDORE” est proposé sur la page d’administration de la collection. Un utilisateur connecté peut ainsi faire une demande de signalement d’une collection dont il est gestionnaire, en cliquant sur le bouton “Signaler cette collection dans ISIDORE”. Un formulaire à remplir s’affiche et la demande est automatiquement notifiée à l’équipe ISIDORE qui prendra contact avec l’utilisateur.

Affichage des états ‘En attente’ et ‘En erreur’ des dépôts¶

De nouvelles informations sur l’état du dépôt sont affichées dans la page d’administration d’un dépôt et d’une collection.

L’objectif est d’informer le gestionnaire d’un dépôt lorsque des mises à jour de Datacite et/ou de l’indexation sont en cours qui impliquent que le dépôt n’est pas disponible immédiatemment dans DataCite ou dans NAKALA. En effet, il peut arriver qu’il y ait un délai entre le moment où le dépôt a été publié dans NAKALA et son référencement auprès de DataCite. De la même façon, un décalage peut avoir lieu entre la publication et l’indexation des métadonnées et des fichiers du dépôt par le moteur de recherche de NAKALA (Elastic Search). Dans ces deux cas, l’état du dépôt affiche ‘en attente’ : le gestionnaire n’a aucune action à faire, ces opérations sont relancées automatiquement.

L’indexation des données par Elastic Search (moteur de recherche NAKALA) porte sur les métadonnées et l’ensemble du contenu des fichiers. Si l’indexation affiche ‘en erreur’, cela signifie qu’un fichier est mal formé pour l’indexation dans ElasticSearch, par exemple, un problème d’encodage. Le dépôt sera bien indexé, seul le fichier mal formé sera ignoré. Le nom du fichier mal formé sera indiqué afin que le gestionnaire puisse - s’il le souhaite - vérifier le fichier et le remplacer.

Demande de modération - formulaire de contact¶

La demande de modération est à l’initiative du déposant ou gestionnaire du dépôt. Pour le choix du modérateur, le critère est de privilégier le modérateur dont le périmètre géographique couvre votre établissement ou site universitaire. Pour les déposants qui ne trouvent pas de modérateur répondant à ce critère, un formulaire de contact est mis en place. Cela permet de contacter l’équipe de Huma-Num qui traitera votre demande et trouvera une solution afin de vous mettre en relation avec un modérateur. Un temps de traitement est à prévoir dans ce cas spécifique.

B/ Corrections¶

Mise à jour de l’OAI-PMH¶

Le bug qui bloquait l’affichage des métadonnées des dépôts modérés dans l’entrepôt OAI-PMH a été corrigé.

22-01-2025 (API 3.19.0 - FRONT 3.14.0)¶

A/ Nouveautés¶

Validateur RFC5646¶

Le standard RFC5646 définit une syntaxe qui permet de construire des identifiants de langue. Dans NAKALA, jusqu’à présent, il était possible d’encoder ces identifiants en dcterms:RFC3066, dcterms:ISO639-2 et dcterms:ISO639-3 qui ont depuis été supprimés (cf. 30-09-2024). Dorénavant, NAKALA se base uniquement sur le standard RFC5646 qui lui-même se base sur le registre des langues maintenu par IANA et consultable ici : https://api.nakala.fr/vocabularies/languages?limit=10000

Pour des précisions sur l’utilisation de la syntaxe RFC5646 : seule la sous-étiquette “language” de langue principale est implémentée pour l’instant et la valeur renseignée doit obligatoirement correspondre à une valeur du référentiel des langues.

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Suite au remplacement par l’encodage dcterms:RFC5646 des encodages xsd:language, dcterms:RFC3066, dcterms:ISO639-2 et dcterms:ISO639-3, (cf. 30-09-2024), nous opérons un nettoyage des dépôts qui les avaient utilisés :

si la valeur ne respectait pas l’encodage, elle a été conservée mais la mention de l’encodage RFC5646 a été supprimée
si la valeur était conforme, l’indication d’encodage a été conservée mais l’indication de langue de la métadonnée a été supprimée, le cas échéant
si la valeur respectait l’encodage au détail près de la casse, alors la casse a été corrigée (par ex. : FR est devenu fr)
si la valeur respectait un des anciens encodages, elle a été corrigée pour correspondre à la syntaxe RFC5646 (par ex. : ISO639-3 ‘eng’ est devenue en RFC5646 ‘en’).

B/ Corrections¶

Sur la page de présentation (landing page) d’une collection, l’étiquette qui préfixait l’identifiant était “DOI” or aucun identifiant pérenne n’est attribué à une collection dans NAKALA. Il s’agit en fait d’un identifiant interne à NAKALA qui est attribué lors de l’enregistrement d’une collection. Pour rappel : seuls les données bénéficient d’un identifiant pérenne de type DOI. Ainsi, pour éviter toute confusion, l’étiquette ‘ID’ vient remplacer l’étiquette ‘DOI’ sur la page de présentation d’une collection.

29-11-2024 (API 3.17.2)¶

Corrections¶

Mise à jour de l’OAI-PMH¶

Pour répondre aux besoins de moissonnage de partenaires de recherche, le paramétrage du resumptionToken (‘expirationDate’ et pagination) de l’OAI-PMH a été amélioré afin de permettre le moissonnage complet des métadonnées dans NAKALA.

27-11-2024 (API 3.17.1)¶

Corrections¶

Perte de droits temporaires¶

Suite à un bug dans NAKALA, certains utilisateurs n’avaient plus temporairement accès à leurs dépôts. Ce bug a été corrigé et chaque utilisateur a retrouvé rapidement l’accès aux dépôts concernés.

19 novembre 2024 (API 3.17.0 - FRONT 3.13.0 - NAKALA_Press 1.6.0)¶

A/ Nouveautés¶

Tri par date de modification¶

Un nouveau filtre a été mis en place : la date de modification. Lorsque l’on est connecté, il est devenu possible de trier les résultats par date de modification dans une liste de données et de collections.

Modération : un champ ‘affiliation’ pour identifier le modérateur de son établissement¶

Pour faciliter le choix du modérateur, un champ affichera une affiliation simplifiée afin de permettre au gestionnaire qui fait la demande de modération d’identifier le modérateur local de son établissement.

Rappel de l’instance de test NAKALA sur le formulaire de dépôt¶

Pour éviter qu’un utilisateur teste le dépôt dans l’entrepôt NAKALA, un message s’affiche désormais sur la zone de téléchargement des fichiers dans le formulaire de dépôt pour rappeler qu’il existe un bac à sable de NAKALA pour faire des tests, avant tout dépôt dans NAKALA. En effet, un DOI est automatiquement attribué à un dépôt public dans NAKALA, ce qui n’est pas le cas dans le bac à sable : https://test.nakala.fr/

B/ Corrections¶

Bug sur les droits associés à certains dépôts¶

Suite au travail d’identification automatisée des formats de fichiers (cf. la mise à jour du 30-09-2024), la mise à jour des fichiers déjà déposés a pu bloquer le traitement de certains fichiers en cours de dépôt, ce qui explique qu’ils n’étaient pas affichés dans la visionneuse. Ce bug a été corrigé.

Affichage des citations avec un encodage incorrect¶

Le modèle de réponse récupéré par NAKALA suite à l’envoi des métadonnées à DataCite pour afficher les citations a été corrigé. Une incompatibilité avec l’API NAKALA renvoyait des citations contenant des encodages incorrects, par exemple : Jaffrennou, Fran\u00e7ois.

Mise à jour du contenu des info-bulles pour faciliter la description¶

Pour faciliter l’utilisation du schéma de description proposé sur les formulaires (donnée et collection), le contenu des info-bulles a été modifié (cf. les ? associés à chaque champ). Cette mise à jour des informations a pour but d’aider les déposants à mieux décrire leurs données et leurs collections, en les guidant sur l’utilisation de chaque champ.

Un bug de la visionneuse bloquait le chargement des fichiers pdf dans un dépôt multifichiers : le même pdf s’affichait systématiquement. Ce problème a été résolu et la navigation entre les différents fichiers pdf est revenue à la normale.

NAKALA_Press¶

Moissonnage et référencement des sites NAKALA_Press par ISIDORE¶

Les sites créés avec NAKALA_Press sont dorénavant moissonnables par ISIDORE via la mise en place d’un sitemap sur l’ensemble des pages ajoutées dans le NAKALA_Press. Cela permet à chaque site créé sous NAKALA_Press d’être référencé sur demande par le moteur et assistant de recherche ISIDORE. Auparavant, seules les collections NAKALA étaient moissonnées par ISIDORE. Ainsi, un système pour faciliter le signalement de l’ensemble des pages d’un site NAKALA_Press dans Isidore a été mis en place avec des métadonnées fournies via un flux XML de type sitemap et l’ajout de métadonnées au format Dublin Core Element Set en RDFa dans le HTML (encodage RDFa, ie au travers de balises dans l’en-tête de chaque page HTML).

14 octobre 2024 (API V3.16.0 - FRONT 3.12.1)¶

Corrections¶

Mise à jour des métadonnées envoyées à DataCite¶

Lorsqu’une donnée est publiée dans NAKALA, un DOI est créé via l’API de Datacite. Les métadonnées envoyées à DataCite pour la création de ce DOI sont générées à partir des métadonnées renseignées dans NAKALA. Les correspondances entre le modèle de métadonnées source (NAKALA) et le modèle de métadonnées cible (DataCite) ont été revues entièrement. La mise à jour des métadonnées envoyées à DataCite sur les dépôts est en cours : un décalage existe donc actuellement et va se poursuivre sur les prochaines 3 semaines environ, le temps de la mise à jour complète des 758 0827 dépôts à traiter. Pour rappel, la forme de citation présentée sur la page de présentation d’un dépôt dans NAKALA est basée sur les métadonnées déclarées au niveau du DOI à Datacite et pas directement sur les métadonnées renseignées dans NAKALA.

Problème d’authentification https¶

L’URL de redirection traitée par l’annuaire HumanID après l’authentification était en http au lieu d’être en https, ce qui bloquait l’authentification. Ce bug a été résolu.

30 septembre 2024 (API V3.15.0 - FRONT V3.12.0)¶

A/ Nouveautés¶

Identification automatisée des formats de fichiers¶

DROID (Digital Record Object Identification) - un logiciel d’identification de formats de fichiers - a été implémenté dans NAKALA. DROID est lié aux registres de formats PRONOM et types MIME. Cet outil permet d’automatiser l’identification des formats de chaque fichier déposé et de détecter l’identifiant PRONOM (PUID) associé à ce format spécifique. Ce nouveau service offre une information précise, fiable et normalisée de chaque fichier qui est ensuite exploitable entre autres, pour améliorer leur consultation.

Conversion de formats lourds pour leur consultation en ligne¶

A partir de l’identification précise des formats vidéo, audio et d’archives (.tar, .zip, etc.) par DROID, un outil de conversion calcule à la volée un format plus léger mieux adapté à la consultation en ligne sur la visionneuse NAKALA. Le format source du fichier est conservé lors du téléchargement.

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Des encodages ont été remplacés dans les dépôts, supprimés puis retirés de la liste des encodages disponibles dans le champ “Type” sur le FRONT. Ils restent disponibles dans l’API mais sont ignorés le temps de signaler qu’ils vont être définitivement supprimés auprès des utilisateurs de l’API :

les encodages dcterms:RFC3066, dcterms:ISO639-2 et dcterms:ISO639-3 ont été remplacés par dcterms:RFC5646 qui couvre l’ensemble des normes dcterms:ISO639-2 et dcterms:ISO639-3 et a rendu obsolète dcterms:RFC3066
xsd:language a également été remplacé par dcterms:RFC5646 pour être en cohérence avec le schéma Dublin Core
l’encodage xsd:anyURI a été remplacé par dcterms:URI
l’encodage xsd:string a été remplacé par ‘null’

Demander la modération d’un dépôt¶

Dans le cadre du projet de modération des dépôts NAKALA, une nouvelle fonctionnalité permet à un gestionnaire de donnée de demander la modération du dépôt afin d’en évaluer la qualité documentaire. La demande de modération passe par le choix du modérateur, choix effectué par le gestionnaire du dépôt. La liste des modérateurs est gérée par Huma-Num. Ainsi, seul un modérateur de cette liste peut être sélectionné par un gestionnaire de donnée lors de la demande de modération. Une fois le modérateur sélectionné, un mail lui est envoyé automatiquement pour lui signaler qu’une demande de modération est à traiter.

Pour des informations sur le projet de modération dans NAKALA, consulter l’article dans le carnet de recherche de Huma-Num : https://doi.org/10.58079/11v7o.

Création du rôle de modérateur¶

Un rôle de modérateur a été créé. Le modérateur (équivalent dans l’API à ROLE_MODERATOR) a des droits de consultation et de modération sur un dépôt, mais n’a aucun droit de modification. Après l’évaluation documentaire du dépôt et s’il est conforme aux critères qualité, le modérateur modifie le statut de la donnée pour lui attribuer le statut “Modéré”, qui signale la modération et la qualité du dépôt. Le nom du modérateur ainsi que la date d’attribution du statut “Modéré” s’affichent alors automatiquement sur la page de présentation de la donnée. Si des modifications sont faites après l’attribution du statut “Modéré”, la donnée perdra automatiquement ce statut. Un modérateur n’a aucun droit de modération sur les données qu’il a lui-même déposées.

Valoriser un dépôt de qualité (statut modéré)¶

Le statut “Modéré” est affiché sur la page de présentation d’une donnée, en haut de notice. Il a été ajouté comme filtre à la liste de résultats des dépôts NAKALA et peut être utilisé comme facette de recherche. Cela permet de mettre en avant les données qui ont suivi le circuit de modération et ont été évaluées de qualité, en facilitant leur remontée dans la page des résultats.

Nouveaux formats de citation¶

La citation affichée dans la page d’une présentation d”une donnée publique utilise dorénavant le service DataCite Citation Formatter. Ce service récupère les métadonnées descriptives et utilise les informations renseignées pour générer une citation à partir de différents styles de références bibiliographiques. NAKALA met à disposition 6 styles normalisés de référence :

APA
Harvard
MLA
Vancouver
Chicago
BibTeX

Retrait de la citation d’une donnée privée¶

Les données privées n’afficheront plus de citation. En effet, une donnée qui a un statut privé ne peut pas être citée, puisqu’elle n’est pas visible, ni exposée publiquement dans NAKALA. Ainsi, afficher une citation était inapproprié. Un message justifiant l’absence de citation sera dorénavant affiché dans le bloc de citation d’une donnée privée.

Retrait de la citation d’une donnée de test¶

Les données de test n’afficheront plus de citation, l’identifiant n’étant pas déclaré auprès de DataCite. Par ailleurs, les données de test ne sont pas conservées. Permettre de citer une donnée de test n’était donc pas pertinent. Un message justifiant l’absence de citation sera dorénavant affiché dans le bloc de citation d’une donnée de test.

B/ Corrections¶

Suite du chargement de tous les fichiers d’une donnée en une fois (API et FRONT)¶

La fonctionnalité de chargement (download) de tous les fichiers d’une donnée en une fois a été étendue aux visiteurs non authentifiés qui consultent un dépôt public dans NAKALA.

Cette fonctionnalité est disponible :

sur l’interface web (FRONT) : via l’icone de téléchargement (au survol apparaît : ‘Télécharger tous les fichiers’) affiché au niveau de la visionneuse, à droite de “Fichiers”
sur l’API : GET/download/datas/{identifier}/files

Amélioration de l’affichage de la galerie (liste de résultats)¶

Lorsque l’on consultait une liste de résultats sous forme de galerie d’images, la sélection d’une ressource fonctionnait mal et était peu ergonomique :

il est devenu possible d’afficher une ressource en cliquant directement sur le titre
les fonctionnalités d’administration sont plus visibles depuis l’ajout d’une pastille blanche qui améliore le contraste

Métadonnées dcterms:creator de citation envoyées à DataCite¶

Les dcterms:creator de type URI ne sont plus envoyés à DataCite pour éviter une citation affichant un auteur sous forme de lien URI. Seuls les auteurs renseignés sous forme de label (chaîne de caractère) sont envoyés à DataCite.

Visionneuses : bug d’affichage lors de retours aux pages précédentes¶

Lors de retours arrière après la consultation d’un dépôt multifichiers, un bug de la visionneuse se produisait. Ce problème a été résolu.

25 juin 2024 - NAKALA_PRESS V1.3.0¶

Corrections¶

Erreur 500 lors de l’affichage du site¶

Le bug technique qui bloquait l’affichage de la page d’accueil d’un site NAKALA_Press et affichait une erreur 500 (erreur d’accès au serveur) a été résolu. Les sites NAKALA_Press s’ouvrent à nouveau correctement.

30 mai 2024 - API V3.14.0 - FRONT V3.11.0 - NAKALA_PRESS V1.2.7¶

A/ Nouveautés¶

Bouton de demande de contact du gestionnaire de la donnée¶

Pour répondre à différents besoins des utilisateurs, une nouvelle fonctionnalité a été mise en place afin de permettre à tout visiteur de NAKALA de prendre contact avec le ou les gestionnaire.s d’une donnée depuis la page de présentation via un bouton affiché en tête de notice pour les personnes non connectées “Contacter le gestionnaire”. Lorsque ce bouton est activé, un formulaire de demande de contact s’ouvre afin de préciser l’objet et décrire la demande. Cette demande est modérée par l’équipe NAKALA qui prend en charge la mise en relation. La demande est ensuite traitée directement par le.s gestionnaire.s de la donnée.

Liste des métadonnées renseignées affichée sur la page de présentation (FRONT)¶

Dorénavant, les métadonnées qui ont été renseignées pour décrire une donnée sont toutes affichées sur la page de présentation afin de rendre plus facilement lisible l’ensemble des informations sur la donnée. Le bouton “Afficher la liste des métadonnées” a été supprimé. Pour rappel, auparavant, seules les métadonnées : type de dépôt (sous forme d’icone) ; titre ; Auteurs ; description ; licence ; mots-clés étaient directement visibles sur la page de présentation ; et pour afficher toutes les autres métadonnées renseignées, il fallait cliquer sur “Afficher la liste des métadonnées” pour ouvrir une pop-up supplémentaire.

Chargement de tous les fichiers d’une donnée en une fois (API et FRONT)¶

Une nouvelle fonctionnalité a été développée pour les utilisateurs authentifiés qui leur permet de downloader tous les fichiers d’une donnée en une fois :

sur l’interface web (FRONT) via l’icone de téléchargement (au survol apparaît : ‘Télécharger tous les fichiers’) affiché au niveau de la visionneuse, à droite de “Fichiers”
sur l’API : GET/download/datas/{identifier}/files

Jusqu’à présent, il fallait downloader les fichiers un par un, ce qui pouvait s’avérer fastidieux lorsqu’un dépôt contenait de nombreux fichiers.

Endpoint API : indexation ‘en attente’ des fichiers mal formés¶

L’indexation des données par Elastic Search (moteur de recherche NAKALA) porte sur les métadonnées et l’ensemble du contenu des fichiers. Or une donnée pouvait être bloquée lors de son indexation lorsqu’un fichier était considéré par Elastic Search comme ‘mal formé’ (par exemple, un problème d’encodage). Dorénavant, les fichiers ‘mal formés’ seront ignorés afin de ne pas bloquer l’indexation de la donnée. Par ailleurs, pour plus de transparence et un meilleur suivi, si un fichier est interprété comme mal formé lors de cette indexation, le message ‘en attente’ sera affiché sur la page d’administration de la donnée. De la même manière un message ‘en attente’ sera affichée sur cette page si le référencement auprès de Datacite n’est pas encore effectif.

B/ Corrections¶

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

L’encodage xsd:duration a été remplacé dans les données, puis retiré de la liste des encodages disponibles dans NAKALA (champ “Type”) afin de poursuivre l’harmonisation des encodages mis à disposition dans l’objectif de proposer uniquement les encodages du Dublin Core qualifié, en cohérence avec le schéma de métadonnées.

Bug avec JSON (API)¶

Le bug qui survenait lorsque le JSON était vide lors de la requête POST data/identifier/metadatas a été résolu.

Facette “Created” (API)¶

La facette “Created” qui ne répondait plus a été rétablie et fonctionne à nouveau.

Dépréciation du format dc dans l’API¶

Le format DC devient ‘déprécié’ et sera prochainement supprimé dans l’API afin d’être en cohérence avec les métadonnées envoyées via le protocole OAI-PMH : GET /datas/{identifier}/metadatas (metadata-format)

Protocole OAI-PMH¶

NAKALA fournit une exposition OAI des données publiques sous 3 formats : Dublin Core (dc) ; Dublin Core qualifié (dcterms) ; DataCite.

La correspondance des métadonnées de NAKALA vers ces 3 formats a été améliorée.

La gestion des dates de création, modification et suppression (datestamp) a été mise en conformité avec les recommandations du protocole OAI-PMH.

NAKALA_Press : ordre des pages¶

La fonctionnalité de changement d’ordre des pages a été améliorée afin de faciliter les modifications.

NAKALA_Press : traduction des pages¶

L’ensemble des traductions manquantes en anglais et espagnol sur les interfaces multilingues a été effectué.

30 avril 2024 - NAKALA_PRESS V1.2.6¶

A/ Nouveautés¶

NAKALA_Press : Confirmation d’une suppression¶

Pour éviter la suppression intempestive d’une page en cours d’administration, un message s’affiche dorénavant pour demander la confirmation de la suppression d’une page.

B/ Corrections¶

NAKALA_Press : Pas de sauvegarde avec le bouton ‘Entrée’¶

Auparavant, lorsqu’on cliquait sur “Entrée”, cela enregistrait automatiquement la page en cours d’administration. Ce comportement a été corrigé et dorénavant, cliquer sur Entrée ne permet plus d’enregistrer automatiquement la page.

NAKALA_Press : Ordre d’affichage des pages¶

Lorsqu’un site contenait plus de 10 pages, un bug rendait aléatoire l’ordre des pages. Ce problème a été résolu et dorénavant, l’ordre d’affichage paramétré est respecté.

15 avril 2024 - NAKALA_PRESS V1.2.5¶

Corrections¶

NAKALA_Press : Nombre de collections affichées (page metadata_collection)¶

Dorénavant, le nombre de collections affichées dans une page metadata_collection (liste de données) est limité à 500 afin de permettre de consulter la liste complète des collections associées à un NAKALA_Press. En effet, avant ce développement, l’affichage était limité à 24 collections, or plusieurs NAKALA_Press faisaient des liens vers un plus grand nombre de collections.

NAKALA_Press : résultats de requêtes (page metadata_collection)¶

Certains résultats de requêtes remontaient des données qui appartenaient à d’autres collections que la collection principale qui était utilisée pour administrer le site NAKALA_Press. Ce comportement a été corrigé. Dorénavant, seules les données concernées par le site NAKALA_Press remontent lors des requêtes.

NAKALA_Press : amélioration de l’administration d’un site NAKALA_Press¶

Lorsqu’un utilisateur enregistrait une nouvelle page, il revenait automatiquement à la page d’accueil. Pour améliorer l’expérience d’administration de NAKALA_Press, lorsqu’une nouvelle page est enregistrée et après toutes modifications, l’utilisateur revient au dashboard qui affiche l’arborescence des pages pour poursuivre l’administration du site NAKALA_Press.

NAKALA_Press : interfaces multilingues¶

Pour les sites multilingues (création des différentes pages en français, anglais et/ou espagnol) : le bug qui empêchait la cohérence de l’affichage des pages selon la langue choisie a été résolu. Dorénavant, chaque interface affiche les pages dans la langue sélectionnée par le visiteur.

NAKALA_Press : identifiant Matomo (statistiques de consultation)¶

Si l’identifiant matomo renseigné ne respecte pas la syntaxe de cet identifiant, l’enregistrement est bloqué afin de signaler que l’identifiant est erroné.

1 mars 2024 - NAKALA_PRESS V1.2.4¶

Corrections¶

NAKALA_Press : traduction des facettes¶

L’ensemble des facettes disponibles sur un site NAKALA_PRESS a été traduit en anglais et espagnol sur les interfaces multilingues.

La sélection des pages dans le menu d’administration fonctionnait de manière aléatoire, sans que l’on ne maîtrise l’endroit précis où cliquer pour les sélectionner correctement. Ce comportement a été corrigé : la zone pour la sélection a été élargie afin de faciliter la sélection des pages dans le menu d’administration.

15 février 2024 (API V3.13.0 - FRONT V3.10.0)¶

A/ Nouveautés¶

Saisie de l’ORCID : contrôle supplémentaire (API et FRONT)¶

Pour enregistrer un nouvel auteur et son ORCID, l’ORCID doit obligatoirement être de la forme https://orcid.org/0000-0002-1825-0097 ou 0000-0002-1825-0097. Autrement, un contrôle automatique bloque l’ajout de l’auteur. Néanmoins ce contrôle ne portait pas jusqu’à présent sur l’identification de l’ORCID dans la base Auteurs afin de vérifier que l’ORCID n’avait pas déjà été renseigné pour un autre auteur. Ce contrôle a été mis en place et il ne sera donc plus possible de générer des doublons, ie d’enregistrer pour des auteurs différents un même ORCID.

API - Filtre sur les dates de modification dans la recherche sur les données et les collections¶

Pour faciliter la recherche, un nouveau filtre a été mis en place qui permet de filtrer les données selon leur date de modification, en plus de leur date de création sur l’ensemble des ressources (données et collections).

API - Amélioration de la recherche¶

La recherche via l’API a été améliorée depuis le endpoint GET /search.

Il est possible d’ajouter plusieurs valeurs pour un même filtre. Par exemple :

scope=collection;status=public;year=2009,1889

Par ailleurs, des opérateurs booléens ont été ajoutés pour affiner la requête et les résultats de recherche. Les caractères de séparation ajoutés sont :

la virgule ‘,’
le ‘&’

La recherche se fera par un OU entre les valeurs dans le cas de la virgule et par un ET dans le cas du &. Il n’est pas possible de mélanger ces deux opérateurs pour un même filtre.

Dorénavant, on peut utiliser la requête suivante :

collection=10.34847/nkl.65196f20,10.34847/nkl.0bf43ce3

Dans cet exemple, les résultats obtenus remonteront uniquement les données en commun aux deux collections.

Pour plus de détails, voir la documentation de l’API, GET /search : https://api.nakala.fr/doc.

API - Requête : Filtrer à partir des identifiants des collections¶

Dans une requête, il est maintenant possible de filtrer les données à partir des identifiants des collections.

Ajout de facettes pour filtrer les résultats de recherche (page de recherche publique - sans authentification)¶

Une facette “Ressource” a été ajoutée aux facettes existantes (“Type” ; “Licence” ; “Année de création”) pour filtrer les résultats de recherche. Cette facette contient les valeurs “Données” et “Collections” qui jusque-là étaient intégrées à la facette “Type”.

Une facette “Statut” a été également ajoutée pour filtrer les résultats de recherche selon le statut de la ressource. Cette nouvelle facette contient les valeurs :

“Données publiques”
“Données privées”
“Collections publiques”
“Collections privées”

Champ Auteurs : recherche par autocomplétion sur le nom de famille¶

Lorsque l’on saisit les premiers caractères d’un nom dans le champ ‘Auteurs’, l’autocomplétion remonte par défaut les noms de famille des auteurs qui commencent par les caractères saisis afin de mieux répondre aux pratiques de recherche et de saisie qui portent avant tout sur le nom de famille d’un auteur. Auparavant, l’autocomplétion portait par défaut sur le prénom de l’auteur.

B/ Corrections¶

API - Suite du Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Via l’API, lorsque les métadonnées nkl:created, nkl:license et nkl:type sont renseignées, il n’est plus possible de renseigner une langue. En effet, renseigner une langue est incohérent avec les informations saisies dans ces propriétés.

API - Affichage de fichiers texte lourds¶

Le traitement de l’affichage de fichiers texte dépassant un certain poids mettait trop de temps. Des corrections et des nouvelles règles ont été établies afin de faciliter l’affichage des fichiers texte de 1 à 5 Mo. Un fichier de plus de 5Mo ne peut pas être affiché car il atteint les capacités maximales de traitement de la visionneuse mais dorénavant, un message d’erreur et explicatif s’affiche dans la visionneuse et recommande le téléchargement du fichier texte de plus de 5Mo pour le consulter.

Facette de recherche “Année de création” : affichage des résultats¶

Dans une recherche contenant de nombreux résultats, la facette “Année de création” affichait uniquement 25 valeurs, ce qui ne permettait pas de filtrer les résultats à partir de la liste complète des dates de création renseignées puisqu’elles n’étaient pas disponibles dans la facette. Dorénavant la facette “Année de création” affiche 100 valeurs par défaut, ce qui permet de filtrer plus finement les résultats de recherche en donnant la possibilité de sélectionner une année à partir de la liste complète des années de création existantes.

Sélection des valeurs dans les facettes¶

La sélection des valeurs dans une facette fonctionnait de manière aléatoire, sans que l’on ne maîtrise l’endroit précis où cliquer pour sélectionner correctement les valeurs (case à cocher, label et/ou nombre de résultats). Ce comportement a été corrigé : la zone pour la sélection a été élargie afin de faciliter la sélection des valeurs dans les facettes.

Erreur lors de la sélection d’un auteur sans ORCID renseigné¶

Le champ ‘Auteur’ permet de renseigner 3 champs lors de la création d’un nouvel auteur : Nom, Prénom, ORCID. L’ORCID est la seule métadonnée à être optionnelle. Ainsi, l’ORCID n’est pas nécessairement saisi lors de la création d’un auteur. Or un bug empêchait de sélectionner un auteur enregistré sans ORCID. Ce bug a été corrigé.

22 novembre 2023 - API V3.12.0 - FRONT V3.9.0 - NAKALA_PRESS V1.2.3¶

A/ Nouveautés¶

Champ Auteurs : affichage des informations concernant un auteur qui remonte en autocomplétion lors de la saisie¶

Dans le champ Auteurs, la liste des auteurs enregistrés précédemment remonte par autocomplétion lorsque le déposant saisit les premiers caractères du nom ou du prénom d’un auteur. L’affichage des informations a été amélioré afin de permettre de rechercher dans un champ précis les 3 informations qui sont renseignées à la création d’un auteur : prénom, nom et ORCID. Cela permet d’identifier clairement les informations enregistrées, de désambiguiser les informations sur un auteur et d’éviter toute confusion lorsque l’on sélectionne un auteur enregistré.

Suite du Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Liste des encodages remplacés dans les données, puis retirés de la liste des encodages disponibles dans NAKALA (champ “Type”) :

rdf:HTML
rdf:PlainLiteral
rdf:langString
le vocabulaire rdf qui contenait ces types

Affichage des encodages dans la page de présentation¶

Lorsqu’un encodage est sélectionné et renseigné dans un champ “Type” (associé à une propriété du Dublin Core), celui-ci est dorénavant visible et affiché dans la page de présentation de la donnée (landing page).

B/ Corrections¶

Multiplication de versions des fichiers liée aux sha1 (API)¶

Dans le PUT data, deux erreurs provoquaient une montée de version non souhaitée :

un sha1 en doublon
un sha1 vide

Ce problème a été résolu et dorénavant, lors d’un PUT data, si le sha1 des fichiers est en doublon ou vide, cela n’implique plus une montée de version.

Harmonisation des champs de métadonnées dans la page de présentation¶

Auparavant, sur la page de présentation (landing page), les noms des champs de description étaient affichés dans des syntaxes diverses et hétérogènes. Pour améliorer et harmoniser l’affichage de ces informations, la page de présentation affiche une URI simplifiée et courte pour chaque propriété basée sur un modèle commun à tous les champs de description. Par exemple : http://purl.org/dc/terms/tableOfContents devient dcterms:tableOfContents.

Résultats de recherche liés à un mot-clé¶

Lorsqu’on clique sur un mot-clé dans une page de présentation, une page affichait tous les résultats (données et collections) qui avaient ce mot-clé mais également les données et collections qui contenaient ce terme dans leur contenu. Dorénavant, lorsque l’on clique sur un mot-clé, seules les données (ou les collections) qui ont ce mot-clé remonteront dans les résultats de recherche.

Clé metas avec PUT :datas/{id} sans modification sur les métadonnées¶

Lors qu’on fait un PUT /datas/{id} avec la clef metas, la donnée éditée était considérée comme modifiée, même si aucune nouvelle information n’avait été envoyée, ni d’informations existantes modifiées. Dorénavant, un contrôle supplémentaire sera fait sur chaque donnée éditée pour vérifier s’il y a eu un changement dans les métadonnées, avant l’envoi de la donnée. Ainsi, lorsqu’aucune nouvelle information n’est ajoutée, ni aucune information modifiée, la donnée ne sera plus considérée comme ayant été modifiée.

27 septembre 2023 - FRONT 3.8.1¶

Retrait de “Champ Auteurs : affichage des informations concernant un auteur qui remonte en auto-complétion lors de la saisie (FRONT 3.8.0)”¶

Cette fonctionnalité a été mise en attente et retirée en attente de développements complémentaires pour assurer son fonctionnement optimal.

22 septembre 2023 - API V3.11.0 - FRONT V3.8.0 - NAKALA_PRESS V1.2.2¶

A/ Nouveautés¶

Contrôle des informations renseignées dans le type dcterms:ISO3166¶

Le type dcterms:ISO3166 est lié à un vocabulaire contrôlé de l’ISO qui définit les codes pays “countryCode” consultable à l’URL https://www.iso.org/obp. La liste des codes pays est également consultable sur l’API NAKALA : GET /vocabularies/countryCodes. Jusqu’à présent, il était possible de renseigner des valeurs incompatibles avec dcterms:ISO3166. Dorénavant, seuls les codes pays issus de ce vocabulaire contrôlé peuvent être renseignés. Le choix a été fait de retenir uniquement les codes officiels de l’ISO3166 alpha-2 (sur 2 caractères). Si une autre information est saisie, le déposant recevra un message d’erreur lors de l’enregistrement et devra saisir un code pays issu de ce vocabulaire.

B/ Corrections¶

Supprimer une relation entre données publiques¶

Il n’était pas possible de supprimer les relations d’une donnée depuis le formulaire web lorsqu’un partage des droits sur cette donnée avait été paramétré (utilisateur individuel ou liste d’utilisateurs). Ce comportement a été corrigé et il est possible de supprimer une relation sur une donnée sur laquelle plusieurs contributeurs ont un rôle.

Erreur 500 lors de la modification du statut d’une collection¶

Lorsque le statut d’une collection était modifié via l’API (PUT /collections/{identifier}/status/{status}), cela renvoyait à une erreur 500. Ce comportement a été stabilisé.

Nombre de résultats dans la facette type¶

Dans la page des résultats d’une recherche à vide, le type “datapaper” ne remontait pas dans la facette “Type”, ce qui ne permettait de filtrer les résultats avec ce type. Dorénavant la facette “Type” des résultats de recherche contient tous les types listés dans le champ “Type de dépôt”.

Affichage des données d’une collection¶

Un utilisateur qui a créé une collection publique contenant des données sur lesquelles il n’a aucun droit ne pouvait pas visualiser la page de présentation (landing page) des données, suite à un bug qui a été résolu.

Champ Auteurs : affichage des informations concernant un auteur qui remonte en auto-complétion lors de la saisie¶

Dans le champ Auteurs, la liste des auteurs créés précédemment remonte par autocomplétion lorsque le déposant saisit les premiers caractères du nom ou du prénom d’un auteur. L’affichage des informations a été amélioré afin de permettre de rechercher dans un champ précis les 3 informations qui sont renseignées à la création d’un auteur : prénom, nom et ORCID. Cela permet d’identifier clairement les informations enregistrées et d’éviter une confusion lorsque l’on sélectionne un auteur enregistré.

Affichage de la métadonnée dcterms:abstract¶

Quand la métadonnée dcterms:abstract était renseignée, celle-ci était affichée à la place du champ Description sur la page de présentation d’une donnée. Ce problème d’affichage a été résolu.

NAKALA_Press : enregistrement du préfixe du site¶

Dans la boîte de dialogue qui s’ouvre pour enregistrer le préfixe du site, l’exemple ‘donnees-pour-capturer-ecran’ est renseigné pour préciser la forme du préfixe attendu. Si cette forme n’est pas respectée, l’utilisateur reçoit un message d’erreur qui masquait l’exemple. Le message d’erreur détaille dorénavant la forme du préfixe à saisir et guide explicitement l’administrateur du site.

26 juin 2023 - NAKALA_PRESS V1.2.1¶

A/ Nouveautés¶

NAKALA_Press : Prévisualisation du site non publié par l’administrateur¶

Avant toute publication, l’administrateur du site a maintenant la possibilité de prévisualiser le site NAKALA_PRESS sous sa forme publique. Auparavant, il était nécessaire de rendre public le site NAKALA_PRESS pour pouvoir voir le résultat.

B/ Corrections¶

NAKALA_Press : affichage des collections publiques uniquement dans une page Metadata_Collections¶

Suite à un bug, les collections privées étaient affichées dans une page Metadata_Collections. Ce bug a été corrigé et dorénavant, seules les collections publiques apparaissent dans la page Metadata_Collections.

7 juin 2023 - API V3.10.0¶

Nouveautés¶

Contrôle des informations renseignées dans le type dcterms:Point¶

Le type dcterms:Point (coordonnées géographiques) est lié à une syntaxe formalisée du standard DCMI Point : https://www.dublincore.org/specifications/dublin-core/dcmi-point/.

Jusqu’à présent, il était possible de renseigner des valeurs incompatibles avec dcterms:Point. Dorénavant, ne sont acceptées que les valeurs qui respectent la forme et syntaxe de l’information de type coordonnées géographiques du DCMI Point.

Pour des précisions sur les composants à utiliser :

east : obligatoire
north : obligatoire
elevation : facultatif
name : facultatif
units : facultatif
zunits : à utiliser uniquement si “elevation” est renseigné : est donc facultatif sinon interdit.
projection : facultatif

Quant aux valeurs à renseigner, quelques indications :

east doit être compris entre -180 à 180 et contenir des valeurs numériques en degrés décimaux
north doit être compris entre -90 à +90 et contenir des valeurs numériques en degrés décimaux
elevation doit être compris entre -6 371 000 et 8 849
units : la seule valeur acceptée par défaut est “signed decimal degrees”
zunits : la seule valeur acceptée est “metres”
projection : la seule valeur acceptée est “WGS84”

Quelques exemples :

east=43.244591; north=-11.699912; name=Moroni
east=27; north=46.5;name=Moldova
east=-2.83333; north=48.16667;name=Bretagne

Contrôle des informations renseignées dans le type dcterms:Box¶

Le type dcterms:Box est utile pour identifier un espace physique en renseignant ses limites géographiques. Cette information est liée à une syntaxe formalisée du standard DCMI Box Encoding Scheme : https://www.dublincore.org/specifications/dublin-core/dcmi-box/.

Jusqu’à présent, il était possible de renseigner des valeurs incompatibles avec dcterms:Box. Dorénavant, ne sont acceptées que les valeurs qui respectent la forme et syntaxe de l’information de type espace géographique délimité du DCMI Box.

Pour des précisions sur les composants à utiliser :

northlimit : obligatoire
southlimit : obligatoire
eastlimit : obligatoire
westlimit : obligatoire
uplimit : facultatif
downlimit : facultatif
name : facultatif
units : facultatif
zunits : facultatif
projection : facultatif

Quant aux valeurs à renseigner, quelques indications :

northlimit et southlimit : obligatoire et compris entre [-90 à +90]
eastlimit et westlimit : obligatoire et compris [-180 à 180]
uplimit doit être compris entre -6 371 000 et 8 849
downlimit doit être compris entre -6 371 000 et 8 849 et inférieur à uplimit, si uplimit est renseigné
units : la seule valeur acceptée est “signed decimal degrees”
zunits : la seule valeur acceptée est “metres”. Ne peut être ajouté que si uplimit ou downlimit est renseigné
projection : la seule valeur acceptée est “WGS84”

Quelques exemples :

northlimit=-7.73; southlimit=-12; westlimit=42; eastlimit=48.29
westlimit=-7.22; southlimit=34.67; eastlimit=45.99; northlimit=58.54
northlimit=48.9354; southlimit=47.2479; westlimit=-4.8504; eastlimit=-0.9722

15 mai 2023 - API V3.9.1 - FRONT V3.7.0¶

Corrections¶

Chargement (upload) d’un fichier volumineux¶

Lors du dépôt de fichiers lourds, certains déposants rencontraient des difficultés techniques qui faisaient échouer le chargement (upload) des fichiers à cause de déconnexions intempestives. Le temps de chargement pouvait être impacté de différentes manières : débit de la connexion Internet, temps de calcul sur les serveurs, etc. - des problèmes directement liés au poids du fichier. Ce problème technique a été résolu. Pour suivre l’état du chargement des fichiers, NAKALA affiche dorénavant une fenêtre qui permet de visualiser le chargement en cours.

18 avril 2023 - API V3.9.0 - FRONT V3.6.0¶

A/ Nouveautés¶

Attribution d’un identifiant de type DOI aux collections avec un identifiant Handle¶

Pour des raisons historiques, les collections créées avant janvier 2020 avait un identifiant handle alors que les collections créées après cette date ont un identifiant de type DOI. Dorénavant, toutes les collections ont pour identifiant principal un identifiant de type DOI. Contrairement aux données, les collections ne sont pas publiées sur Datacite. Ces identifiants ne sont donc pas résolvables contrairement aux identifiants handle.

Affichage des identifiants DOI et handle aux collections publiques¶

Les deux identifiants sont affichés sur la page de présentation (landing page) et sur la page de gestion de la collection.

Contrôle des informations renseignées dans le type dcterms:DCMIType¶

Le type dcterms:DCMIType est lié à un vocabulaire contrôlé du DCMI qui contient une liste de 12 entrées. Jusqu’à présent, il était possible de renseigner des valeurs incompatibles avec dcterms:DCMIType. Dorénavant, seules les 12 valeurs de ce vocabulaire contrôlé peuvent être renseignées. Si une autre information est saisie, lors de l’enregistrement, le déposant recevra un message d’erreur et devra saisir uniquement une des 12 entrées de ce vocabulaire : “Collection”, “Dataset”, “Event”, “Image”, “InteractiveResource”, “MovingImage”, “PhysicalObject”, “Service”, “Software”, “Sound”, “StillImage”, “Text”.

Rechercher des fichiers d’une donnée avec le moteur de recherche¶

Il est devenu possible de faire des requêtes à partir des informations renseignées au niveau de chaque fichier d’une donnée. L’indexation et la recherche sur un fichier portent sur les informations suivantes : nom, identifiant (sha1), description.

B/ Corrections¶

Identifiants DOI dans la facette collections¶

La facette collections pouvait contenir des identifiants handle ou des identifiants de type DOI selon la date de création des collections. Puisque toutes les collections ont maintenant un identifiant de type DOI, c’est toujours cet identifiant qui est utilisé dans la facette collections.

Filtre de tri sur les identifiants DOI et handle des collections¶

Le filtre permettant de trier les résultats d’une recherche sur une collection en particulier peut se baser aussi bien sur l’identifiant DOI ou l’identifiant handle de cette collection.

Indexation des métadonnées des fichiers sous embargo¶

Toutes les métadonnées d’un fichier sont indexées par le moteur de recherche de NAKALA, même lorsque ce fichier est sous embargo. Le contenu du fichier sous embargo n’est quant à lui jamais indexé comme c’était le cas auparavant.

Liste de résultats d’une recherche : filtre “Année de création” retourne plus de résultats¶

Le filtre “Année de création” limitait le nombre de résultats d’une recherche. En effet, ce filtre était trop restrictif et recherchait uniquement des données qui contenaient exactement la date requêtée, ce qui ne remontait pas certains résultats pertinents. Dorénavant le filtre “Année de création” transforme automatiquement la valeur de la date requêtée afin de remonter tous les résultats pertinents. Pour plus de détails, consulter dans la documentation de l’API, le verbe GET /search “Recherche des données NAKALA”.

Affichage des titres longs dans le bloc de citation¶

Les titres de données contenant de nombreux caractères sans espace ne s’affichaient pas correctement dans le bloc de citation. Ce problème d’affichage a été résolu.

Protocole OAI - Flux XML¶

Le flux XML proposé par NAKALA via le protocole OAI contenait des erreurs qui ont été corrigées.

Protocole OAI - Identifiant DOI pour les sets et records¶

L’identifiant OAI pour les sets et les records repose dorénavant uniquement et strictement sur les identifiants de type DOI, et non plus sur les handle. Ainsi, les sets ou records moissonnés jusque-là en se basant sur les identifiants de type handle n’existent plus. Ce changement impacte le moissonnage et les mises à jour envoyées dans le cadre du protocole OAI. Depuis cette cette mise à jour, le moissonnage via OAI-PMH ne peut se faire que sur la base de l’identifiant de type DOI pour les sets et les records.

15 mars 2023 - NAKALA_PRESS V1.2.0¶

A/ Nouveautés¶

NAKALA_Press : Affichage des identifiants DOI et Handle sur la page de présentation d’une donnée¶

Avant décembre 2020 (date d’une mise à jour majeure de NAKALA), NAKALA attribuait des identifiants pérennes de type Handle aux données publiques. Ces Handles n’apparaissaient pas dans les métadonnées des données affichées sur les pages d’un site NAKALA_PRESS. Une page de NAKALA_PRESS qui présente une donnée affiche maintenant l’identifiant Handle, en plus du DOI.

3 mars 2023 - API V3.8.0¶

Suite du Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Liste des encodages remplacés dans les données, puis retirés de la liste des encodages disponibles dans NAKALA :

xsd:date
xsd:dateTime
xsd:time
xsd:gYear
xsi:hexBinary
xsi:base64Binary

2 mars 2023 - NAKALA_PRESS V1.0.1¶

A/ Nouveautés¶

NAKALA_Press : ouverture d’une page externe dans un nouvel onglet du navigateur¶

Lorsque vous ajoutez un lien web externe dans le contenu d’une page, ce lien externe va s’ouvrir dans un nouvel onglet du navigateur.

B/ Corrections¶

NAKALA_Press : enregistrement de la page d’accueil¶

Un bug sur le bouton “Envoyer” empêchait l’enregistrement de la page d’accueil lors de l’ajout ou de la modification de son contenu. Ce bug a été corrigé.

NAKALA_Press : affichage des titres de la collection sur une page de type “Metadata”¶

L’affichage des collections se faisait de manière aléatoire sur une page de type “Metadata” en affichant parfois le titre, parfois l’identifiant des collections. Ce comportement a été corrigé : une page de type “Metadata” affiche désormais les titres des collections.

NAKALA_Press : affichage des données NAKALA mises à jour¶

Sur une page de résultats de recherche (qui fait appel à l’API /search), les titres des données n’étaient pas mis à jour en synchrone lorsque ces titres étaient modifiés dans NAKALA, alors que les titres étaient pourtant bien retournés par l’API. Ce problème d’affichage a été corrigé et les informations mises à jour dans NAKALA sont visibles dans NAKALA_PRESS.

NAKALA_Press : iframe et affichage en plein écran¶

Sur les pages de contenu, lorsqu’on ajoutait un lien embed vers une image NAKALA, il n’était pas possible de passer la visionneuse en mode plein écran car il manquait le paramètre “allowfullscreen” sur l’iframe généré par l’éditeur WYSIWYG. Ce problème a été résolu.

16 février 2023 - API V3.7.0 - FRONT V3.5.0¶

A/ Nouveautés¶

Tri par ordre alphabétique des collections d’une donnée¶

Lorsqu’on affiche une donnée, la liste des collections est organisée par ordre alphabétique.

Pour l’API : Depuis une requête à GET /datas/{identifier}/collections, il est possible au moyen du paramètre “order” de trier les collections en fonction de leur :

date de création : creaDate,asc (croissant) ou creaDate,desc (décroissant)
titre : title,asc (croissant) ou title,desc (décroissant)

Une même collection pouvant avoir plusieurs titres dans la même langue ou des langues différentes, le tri des collections en fonction de leur(s) titre(s) se fait selon les critères suivants :

la langue de la requête est déterminée à partir de l’entête Accept-Language
si aucun entête de ce type n’est envoyé, c’est l’anglais qui sera la langue par défaut
le titre sur lequel s’effectue le tri est le premier titre disponible dans la langue de la requête
si aucun titre n’est disponible dans la langue de la requête, c’est le premier titre disponible qui est pris en compte
l’ordre des titres d’une collection correspond à celui renseigné au moment de la création ou de l’édition de cette collection-

Affichage de la liste complète des auteurs dans la citation¶

Jusqu’à présent, un seul nom d’auteur était affiché dans la citation de la donnée. Dorénavant tous les auteurs enregistrés dans le champ “Auteurs” apparaissent dans la citation.

Affichage par ordre alphabétique des auteurs¶

Dans la citation et dans la notice de description de chaque donnée, les auteurs renseignés dans le champ “Auteurs” sont affichés par ordre alphabétique.

Recherche dans la liste des licences et des langues¶

Pour améliorer la recherche dans les champs liés à un référentiel :

le champ “Langues” et les champs “Pas d’information de langue” proposés pour tous les autres champs affichent par défaut 5 langues. Un champ vide complémentaire permettait de saisir les premiers caractères d’un terme afin de rechercher d’autres langues non présentes dans la liste par défaut. Ce champ vide manquait de visibilité : la mention “Tapez ici pour trouver d’autres langues” a été ajoutée.
le champ “Licence” affiche par défaut 6 licences et proposait un champ vide complémentaire pour rechercher d’autres licences non présentes dans la liste. La mention “Tapez ici pour trouver d’autres licences” a été ajoutée pour plus de visibilité.

B/ Corrections¶

Création d’un nouvel auteur par l’API¶

Depuis l’interface web, il est obligatoire de renseigner un prénom et un nom de famille pour enregistrer un nouvel auteur dans le champ Auteurs sur le formulaire de dépôt d’une donnée. L’API permettait de ne pas respecter cette forme à la création d’un nouvel auteur. Cette différence de comportement a été corrigée : la règle est dorénavant la même pour les utilisateurs qui utilisent l’interface web ou l’API. Il est donc obligatoire de renseigner un prénom et un nom de famille pour ajouter un nouvel auteur dans NAKALA.

C/ Suite du Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Suppression d’encodages non adaptés¶

Liste des encodages remplacés dans les données, puis retirés de la liste des encodages disponibles dans NAKALA :

xsd:date
xsd:dateTime
xsd:time
xsd:gYear

Si les déposants ont renseigné des valeurs avec ces encodages en respectant les recommandations définies par le Dublin-Core, les encodages listés ci-dessus ont été remplacés par dcterms:W3CDT.

Si la valeur est de la forme “début/fin” et que les valeurs début et fin sont compatibles avec dcterms:W3CDTF, alors la valeur a été transformée en “start=début; end=fin; scheme=w3c-dtf” et son encodage remplacé par dcterms:Period.

Si les déposants ont renseigné avec ces encodages des valeurs non compatibles avec dcterms:W3CDTF, alors ces encodages ont été remplacés par xsd:string.

Des contrôles vont être effectués sur les valeurs encodées en dcterms:W3CDTF et dcterms:Period. Ces contrôles impliquent de modifier les encodages en cas d’anomalies. Ainsi, si la valeur d’un champ encodée en dcterms:W3CDTF ou en dcterms:Period ne respecte pas son encodage, les valeurs sont conservées mais l’encodage remplacé par xsd:string.

Contrôle des informations renseignées dans le type dcterms:Period¶

Le type dcterms:Period est utile pour identifier un intervalle temporel délimité en renseignant des années de début et de fin. Cette information est liée à une syntaxe formalisée du standard DCMI Period Encoding Scheme : (https://www.dublincore.org/specifications/dublin-core/dcmi-period/)[https://www.dublincore.org/specifications/dublin-core/dcmi-period/].

Jusqu’à présent, il était possible de renseigner des valeurs incompatibles avec dcterms:Period. Dorénavant, ne sont acceptées que les valeurs qui respectent la forme et syntaxe de l’information d’un intervalle temporel délimité du DCMI Period.

Pour des précisions sur les composants à utiliser :

name (facultatif)
start (obligatoire)
end (obligatoire)

Quant aux valeurs à renseigner, quelques indications :

les années doivent comporter 4 chiffres. Par exemple : start=0030; end=0330
les années peuvent être négatives : start=-0330; end=-0030
la date saisie dans ‘start’ doit être antérieure à la date saisie dans ‘end’

Des exemples de syntaxes :

name=Hellénistique, Antiquité; start=-0330; end=-0030
name=Haut empire Romain; start=-0030; end=0099
name=The Great Depression; start=1929; end=1939
start=1999-09-25T14:20+10:00; end=1999-09-25T16:40+10:00

25 janvier 2023 - API V3.6.0 - FRONT V3.4.0 - NAKALA_PRESS V1.0.0¶

A/ Corrections¶

Attribution d’un DOI aux données avec un identifiant Handle¶

Toutes les données publiques ayant un handle ont dorénavant également un identifiant de type DOI.

Indexation des collections¶

Un bug bloquait l’indexation des collections. Ce bug a été corrigé et Nakala indexe à nouveau les collections publiques.

Affichage des facettes de filtres et de tri sur les collections¶

Les facettes de filtres et de tri sur la liste des données d’une collection ne s’affichaient plus. Ce bug a été corrigé.

NAKALA_Press : Remplacement de la facette “Année de dépôt” par “Année de création”¶

Sur une page de résultats qui liste les données de la collection éditorialisée avec NAKALA_PRESS, la facette “Année de dépôt” affichait l’année de création de la donnée. Cette incohérence a été corrigée : la facette “Année de création” remplace “Année de dépôt”.

B/ Nouveautés¶

Affichage des identifiants DOI et handle aux données publiques déposées avant décembre 2020¶

Dorénavant les deux identifiants sont affichés sur la page de présentation (landing page) et sur la page de gestion de la donnée.

Boutons pour copier l’identifiant et les URLs des fichiers¶

Des boutons pour copier facilement l’identifiant et les URLs d’intégration et de téléchargement des fichiers remplacent l’identifiant et les URLs affichés sous la visionneuse de chaque fichier.

API : affichage du handle¶

Pour les données ayant un handle, cette information est précisée sur certains verbes de l’API par le préfixe “handleIdentifier”. Pour l’affichage du DOI, la forme du préfixe “identifier” est conservée.

NAKALA_Press : affichage des titres de la collection sur une page de type “Metadata”¶

La liste des différentes collections auxquelles appartiennent une donnée affiche désormais le titre des collections, et non plus l’identifiant.

21 novembre 2022 - API V3.5.0 - FRONT V3.3.0¶

A/ Corrections¶

Modification de certains termes de l’interface web¶

La terminologie de l’interface web a été revue et harmonisée pour faciliter son utilisation. Quelques exemples de modifications :

bouton d’enregistrement “Déposer” remplacé par “Créer” (formulaire de dépôt d’une donnée)
Remplacement de l’appellation du statut de la donnée en plusieurs endroits : la notion de statut “déposé” est remplacé par le statut “privé” ; la notion de statut “publié” est remplacé par statut “public”.
Le nom du rôle “Propriétaire” a été remplacé par le terme “Gestionnaire”.

Corrections d’un bug d’affichage de la page de gestion d’une donnée¶

Un bug ne permettait plus à un utilisateur avec des rôles d’éditeur et de lecteur de consulter la page de gestion d’une donnée privée (anciennement statut déposé) depuis l’interface d’administration. Ce comportement a été corrigé.

Blocage de plusieurs chargements d’un même fichier dans une donnée¶

Il n’est plus possible de charger deux fois le même fichier dans une même donnée.

Le nom des fichiers devient optionnel lors d’un PUT datas (API)¶

Le nom du fichier est devenu optionnel pour PUT datas/{identifier} qui peut être utile pour réordonner l’ordre d’affichage des fichiers d’une donnée, par exemple.

B/ Nouveautés¶

Lecteur adapté aux fichiers audio¶

Un nouveau lecteur adapté aux fichiers audio a été mis à disposition.

Donnée supprimée qui renvoie à une donnée publiée en remplacement¶

La propriété ‘dcterms:ReplacedBy’ a été ajoutée à la description d’une donnée supprimée dans le cas où une nouvelle donnée a été créée pour la remplacer. Cette métadonnée est affichée dans la page de présentation de la donnée supprimée et contient l’URI qui pointe vers la nouvelle donnée publiée.

Ajouter des données aux collections sur une liste de résultats de recherche¶

Tout utilisateur authentifié peut dorénavant ajouter des données dans une collection directement depuis la page de résultats de recherche. Jusqu’à présent, lorsqu’un utilisateur faisait une recherche dans Nakala, celui-ci avait uniquement la possibilité de consulter la vue publique des données listées dans les résultats de la recherche.

Ajout d’un libellé pour distinguer les différentes instances de Nakala¶

En haut de page des instances de test et de formation de Nakala, un libellé a été ajouté sous l’en-tête de chaque page pour permettre à l’utilisateur de repérer facilement l’instance sur laquelle il travaille et de les distinguer plus facilement.

Attribution de DOI aux données déposées avant décembre 2020 qui disposaient d’un handle¶

Les données déposées dans Nakala avant décembre 2020 qui étaient identifiées par un handle ont fait l’objet d’ajout de DOI. Elles sont déclarées sur Datacite.

27 septembre 2022 (API V3.4.0 - FRONT V3.2.0)¶

A/ Corrections¶

Gestion de l’arborescence dans les sites NAKALA Press¶

Une page d’un site NAKALA Press ne peut plus avoir comme parent elle-même. Cette possibilité générait un bug d’affichage des pages.

Les versions de données ne peuvent plus être dupliquées¶

Un bug dans la gestion du versionning générait des doublons avec perte des droits par le propriétaire. L’ajout de critères d’unicités supplémentaires devrait corriger ce comportement.

Suppression des cases à cocher inutiles¶

Sur les pages de gestion des données et collections dans le tableau de bord personnel, les cases à cocher présentes sur les listes de résultats ne permettaient pas pour l’instant de faire des actions groupées sur les données et/ou collections. Les cases à cocher ont donc été supprimées.

Corrections et modifications sur les visionneuses¶

La visionneuse PDF générait une erreur sur les fichiers pdf de gros volume, la méthode de lecture a été modifiée pour corriger cela.
Activation d’options sur la visionneuse Markdown : openLinksInNewWindow (ouvrir les liens HTML dans de nouveaux onglets du navigateur), parseImgDimensions (rendre possible de configurer la taille des images), SimplifiedAutoLink (générer automatiquement les liens HTML présents dans le fichier), tables (supporter la syntaxe pour créer des tableaux)

Vérification de l’intégrité des fichiers uploadés par navigateurs¶

Afin de renforcer la sécurisation des transferts de données, un contrôle d’intégrité des fichiers a été ajouté. Il permet de comparer les empreintes des fichiers faites par le poste du client (si disponible dans le navigateur) à celles calculées à l’arrivée des fichiers sur le serveur.

B/ Suite du Chantier de nettoyage des métadonnées (amélioration de la qualité) :¶

Liste des encodages remplacés dans les données par xsd:string, puis retirés de la liste des encodages disponibles dans Nakala :

xsd:ENTITY
xsd:ID
xsd:IDREF
xsd:gYearMonth
xsd:normalizedString
xsd:name
xsd:byte
xsd:long
xsd:integer

7 juillet 2022 (API V3.3.0 - FRONT V3.1.0)¶

A/ Nouveautés¶

Chantier de nettoyage des métadonnées (amélioration de la qualité) :¶

Dans le cadre d’un chantier d’amélioration de la qualité des descriptions des données dans Nakala, 32 encodages ont été retirés de la liste disponible. Cette décision a été guidée par une analyse de leur pertinence dans le contexte de l’entrepôt NAKALA et du constat d’une absence totale d’utilisation par les déposants. D’autres lots d’encodages non pertinents seront prochainement retirés. Les déposants qui les auraient utilisés seront contactés afin de leur proposer des corrections et des alternatives.

Liste des encodages supprimés de Nakala :

http://purl.org/dc/terms/DDC
http://purl.org/dc/terms/UDC
http://purl.org/dc/terms/NLM
http://purl.org/dc/terms/RFC1766
http://purl.org/dc/terms/RFC4646
http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
http://www.w3.org/2001/XMLSchema#ENTITIES
http://www.w3.org/2001/XMLSchema#IDREFS
http://www.w3.org/2001/XMLSchema#NCName
http://www.w3.org/2001/XMLSchema#NMTOKEN
http://www.w3.org/2001/XMLSchema#NMTOKENS
http://www.w3.org/2001/XMLSchema#NOTATION
http://www.w3.org/2001/XMLSchema#QName
http://www.w3.org/2001/XMLSchema#boolean
http://www.w3.org/2001/XMLSchema#decimal
http://www.w3.org/2001/XMLSchema#double
http://www.w3.org/2001/XMLSchema#float
http://www.w3.org/2001/XMLSchema#gDay
http://www.w3.org/2001/XMLSchema#gMonth
http://www.w3.org/2001/XMLSchema#gMonthDay
http://www.w3.org/2001/XMLSchema#int
http://www.w3.org/2001/XMLSchema#negativeInteger
http://www.w3.org/2001/XMLSchema#nonNegativeInteger
http://www.w3.org/2001/XMLSchema#nonPositiveInteger
http://www.w3.org/2001/XMLSchema#positiveInteger
http://www.w3.org/2001/XMLSchema#short
http://www.w3.org/2001/XMLSchema#token
http://www.w3.org/2001/XMLSchema#unsignedByte
http://www.w3.org/2001/XMLSchema#unsignedInt
http://www.w3.org/2001/XMLSchema#unsignedLong
http://www.w3.org/2001/XMLSchema#unsignedShort

Dans le même objectif d’amélioration de la qualité des descriptions, 4 propriétés ont également été supprimées :

owl:sameAs
foaf:page
foaf:theme
foaf:publications

B/ Corrections¶

API : Ajustement du moteur de recherche pour prendre en compte la notion de langue (recherche sur le champ titre)¶

Ajout de titleSearchLang permettant au moteur de recherche de prendre en compte la langue.

30 mai 2022 (API V3.2.0 - Front V3.0.0)¶

A/ Nouveautés¶

Modification de configuration de la visionneuse de fichiers .csv¶

La visionneuse permet d’afficher des fichiers .csv, même s’ils comportent des anomalies. Cependant, leur affichage pourra possiblement être perturbé. Dans ce cas, la visionneuse signale tout de même l’anomalie : “Le fichier CSV contient des erreurs. Il peut ne pas être bien formé.”

B/ Corrections¶

Sur Nakala_Press : amélioration de la gestion des sessions d’identification pour corriger un bug de perte de session.

14 février 2022 (API V3.1.0)¶

Amélioration du moteur de recherche sur les données publiées¶

Le champ de recherche dans NAKALA permet d’utiliser les opérateurs booléens AND, OR et NOT et les caractères génériques : *, ?, (),”

La recherche sur des propriétés particulières est aussi possible en préfixant un terme de recherche par title, abstract, keyword ou str_dcterms_bibliographicCitation (liste non exhaustive) suivi du caractère “:”.

Modifications dans la gestion des collections sur une donnée¶

Sur l’interface de présentation de la gestion des collections : révision du formulaire pour associer une donnée à une collection afin de le rendre plus ergonomique.
Sur l’API datas (gestion des données), ajout d’une nouvelle requête PUT /datas/{id}/collection permettant le remplacement de l’ensemble des collections d’une donnée.

Ajout de vérifications sur les ORCID¶

Lorsque l’ORCID d’un auteur est renseigné, ajout d’une vérification sur la syntaxe de l’ORCID : https://orcid.org/{4chiffres}-{4chiffres}-{4chiffres}-{3 chiffres et (1 ‘X’ ou un chiffre)}

pattern : "/^\d{4}-\d{4}-\d{4}-\d{3}(\d|X)$/"

Possibilité d’accès direct à un fichier spécifique sur la page de présentation d’une donnée¶

Lorsqu’une donnée est constituée de plusieurs fichiers, vous pouvez ouvrir la page de présentation de cette donnée (landing page) sur un fichier en particulier, en ajoutant l’identifiant du fichier (le sha1) comme ancre, dans l’URL.

L’URL se présente ainsi : https://nakala.fr/{identifiant}#{fileID}

Correction des URI retournées par l’API¶

Seules les données publiées sont déclarées auprès de Datacite et résolues par doi.org.

Les URIs des données privées et des collections sont propres à Nakala.

L’API a été corrigée en conséquence :

collections : https://nakala.fr/collection/{identifiant}
donnée déposée non publiée : https://nakala.fr/{identifiant}

Il est désormais possible de parcourir les différentes versions d’une donnée depuis sa page de présentation (landing page) sur l’interface web.

Sur l’API datas (gestion des données), ajout d’une nouvelle requête GET /datas/{id}/versions permettant la récupération de la liste des versions d’une donnée. L’accès à la version spécifique d’une donnée ne se fait plus via un paramètre de requête (ex: ?version=2), mais en ajoutant à la fin de l’identifiant de la donnée un numéro de version.

Exemple : 10.34847/nkl.eabbbf68.v2 donne accès à la version 2 de la donnée 10.34847/nkl.eabbbf68

Divers¶

Les requêtes “GET /collections/{id}/datas” et “GET /datas/{id}/collections” retournent maintenant les résultats triés par ordre décroissant sur la date de création des données ou des collections.
Lors de la création d’une nouvelle version d’une donnée, cette version a maintenant pour date de création, la date du jour. Elle n’hérite pas de la date de création de la version 1.
Lorsqu’on supprime une donnée ayant des relations avec d’autres données, toutes ses relations ainsi que les relations inverses sont bien supprimées.

12 janvier 2022 (API V3.0.4)¶

Prise en charge de nouveaux formats archives par la visionneuse¶

La visionneuse de NAKALA peut désormais afficher l’arborescence des dossiers et des fichiers contenue dans les archives au format suivant : .zip, .rar, .phar, .tar, .tgz, .gz, .bz2.

15 décembre 2021 (API V3.0.3)¶

Ordre des fichiers d’une donnée¶

Ajout de la possibilité d’ordonner les fichiers d’une donnée suivant son choix. L’ordre modifié est conservé lors de la consultation de la donnée.

Ajout d’un nouveau rôle (administrateur) pour les listes d’utilisateurs¶

Ajout de la possibilité de déléguer l’administration d’une liste d’utilisateurs à d’autres membres de la liste en leur attribuant le rôle “administrateur” de la liste.

Afin prendre en compte cette nouvelle fonctionnalité, les modèles suivants ont changé au niveau de l’API :

POST /groups et PUT /groups/{id}

Au lieu de ce contenu en JSON :

{
    "name": "HUMA-NUM",
    "users": [
        "pdupont",
        "jdubois",
        "lmartin"
    ]
}

Vous devez maintenant renseigner ceci :

{
    "name": "HUMA-NUM",
    "users": [
        {
            "username": "pdupont",
            "role": "ROLE_OWNER"
        },
        {
            "username": "jdubois",
            "role": "ROLE_ADMIN"
        },
        {
            "username": "pmartin",
            "role": "ROLE_USER"
        }
    ]
}

GET /groups/search

Au lieu de ce contenu en JSON :

[
    {
        "id": "b55e770c-849b-11ea-87ea-0242ac1b0003",
        "type": "user",
        "username": "pdupont",
        "name": "Pierre Dupont",
        "photo": null,
        "datemodify": "2020-05-10T10:18:24+00:00"
    },
    {
        "id": "g67e770c-349b-33ea-a2ea-1243ac1b0007",
        "name": "HUMA-NUM",
        "type": "group",
        "users": [
            {
                "username": "jdubois",
                "fullname": "Jacques Dubois",
                "photo": null
            },
            {
                "username": "lmartin",
                "fullname": "Laure Martin",
                "photo": null
            }
        ],
        "datemodify": "2020-04-28T09:39:34+00:00"
    }
]

L’API vous retourne désormais ce contenu :

[
    {
        "id": "b55e770c-849b-11ea-87ea-0242ac1b0003",
        "type": "user",
        "username": "pdupont",
        "name": "Pierre Dupont",
        "photo": null,
        "datemodify": "2020-05-10T10:18:24+00:00"
    },
    {
        "id": "g67e770c-349b-33ea-a2ea-1243ac1b0007",
        "name": "HUMA-NUM",
        "type": "group",
        "users": [
            {
                "username": "jdubois",
                "fullname": "Jacques Dubois",
                "photo": null,
                "role": "ROLE_OWNER"
            },
            {
                "username": "lmartin",
                "fullname": "Laure Martin",
                "photo": null,
                "role": "ROLE_ADMIN"
            }
        ],
        "datemodify": "2020-04-28T09:39:34+00:00",
        "isOwner": false,
        "isAdmin": false,
        "isMember": false
    }
]

GET /groups/{id}

Au lieu de ce contenu en JSON :

{
    "id": "g67e770c-349b-33ea-a2ea-1243ac1b0007",
    "name": "HUMA-NUM",
    "type": "group",
    "owner": {
        "username": "jdubois",
        "photo": null,
        "fullname": "Jacques Dubois"
    },
    "users": [
        {
            "username": "jdubois",
            "fullname": "Jacques Dubois",
            "photo": null
        },
        {
            "username": "lmartin",
            "fullname": "Laure Martin",
            "photo": null
        }
    ],
    "datemodify": "2020-04-28T09:39:34+00:00"
}

L’API vous retourne désormais ce contenu :

{
    "id": "g67e770c-349b-33ea-a2ea-1243ac1b0007",
    "name": "HUMA-NUM",
    "type": "group",
    "users": [
        {
            "username": "jdubois",
            "fullname": "Jacques Dubois",
            "photo": null,
            "role": "ROLE_OWNER"
        },
        {
            "username": "lmartin",
            "fullname": "Laure Martin",
            "photo": null,
            "role": "ROLE_ADMIN"
        }
     ],
    "datemodify": "2020-04-28T09:39:34+00:00",
    "isOwner": false,
    "isAdmin": false,
    "isMember": false
}

4 novembre 2021 (API V3.0.2)¶

Ajout d’un champ de métadonnée permettant de signaler le lien entre deux données publiées dans Nakala¶

Le champ “Relation vers d’autres données publiées dans Nakala” permet de déclarer le lien entre deux données
Les relations disponibles sont celles de Datacite

Les requêtes suivantes ont été ajoutées à l’API de NAKALA :¶

- GET /datas/{identifier}/relations : Récupération de liste des relations d'une donnée
- POST /datas/{identifier}/relations : Ajout de relations sur une donnée
- PATCH /datas/{identifier}/relations : Modification du commentaire d'une relation
- DELETE /datas/{identifier}/relations : Suppression des relations d'une donnée
- Les relations d'une donnée sont également accessibles depuis GET /datas/{identifier} et modifiables depuis PUT /datas/{identifier}.

Les bugs suivants ont été corrigés :¶

- Suppression ou remplacement d'un fichier d'une donnée "déposée" (pending)
- Upload d'un fichier depuis NAKALA_PRESS
- Visionneuse des fichiers .CSV

8 juillet 2021 (API V3.0.1)¶

Ajout d’un rôle déposant¶

Un nouveau ROLE_DEPOSITOR est introduit avec cette version de l’API. Il désigne le déposant d’une donnée ou d’une collection. Ce rôle est attribué automatiquement à l’utilisateur authentifié au moment du dépôt et ne peut pas être modifié. Il n’y a pas de droit spécifique associé au ROLE_DEPOSITOR. Par défaut, le déposant d’une donnée est aussi le propriétaire.

Il est maintenant possible d’associer le ROLE_OWNER à un groupe d’utilisateurs lorsque l’on souhaite déposer une donnée ou une collection pour le compte d’un laboratoire ou d’un projet. Seuls les propriétaires d’une donnée ou d’une collection peuvent éditer le ROLE_OWNER. Il n’est pas possible de transmettre le ROLE_OWNER sans passer par un groupe d’utilisateurs.

Affichage des droits¶

Uniformisation de l’affichage des droits sur une donnée ou une collection dans les réponses à l’API GET /search.

Au lieu de :

"rights": [
    {
        "role": "ROLE_OWNER",
        "group": {
            "users": [
                {
                    "username": "mdupuis",
                    "givenname": "Marie",
                    "surname": "Dupuis"
                }
            ]
        }
    },
    {
        "role": "ROLE_ADMIN",
        "group": {
            "users": [
                {
                    "username": "pdupont",
                    "givenname": "Pierre",
                    "surname": "Dupont"
                }
            ]
        }
    }
]

L’API retourne maintenant les droits selon ce modèle :

"rights": [
    {
        "role": "ROLE_DEPOSITOR",
        "id": "01abcf299-ac17-11eb-ab7d-0242ac120009",
        "name": "Marie Dupuis",
        "type": "user",
        "username": "mdupuis",
        "givenname": "Marie",
        "surname": "Depuis"
    },
    {
        "role": "ROLE_OWNER",
        "id": "01abcf299-ac17-11eb-ab7d-0242ac120009",
        "name": "Marie Dupuis",
        "type": "user",
        "username": "mdupuis",
        "givenname": "Marie",
        "surname": "Depuis"
    },
    {
        "role": "ROLE_ADMIN",
        "id": "1a2gfh299-dc18-a1eg-e37c-1232gcf21004",
        "name": "Pierre Dupont",
        "type": "user",
        "username": "pdupont",
        "givenname": "Pierre",
        "surname": "Dupont"
    }
]

Dans le cas d’un groupe d’utilisateurs, le modèle est le suivant :

"rights": [
    ...,
    {
        "role": "ROLE_ADMIN",
        "id": "1110b97a-ad9c-11eb-94b4-0242ac120003",
        "name": "HUMA-NUM",
        "type": "group",
        "users": [
            {
                "username": "lcapelli",
                "givenname": "Laurent",
                "surname": "Capelli",
                "fullname": "Laurent Capelli"
            },
            {
                "username": "adesseigne",
                "givenname": "Adrien",
                "surname": "Desseigne",
                "fullname": "Adrien Desseigne"
            },
            ...
        ]
    }
]

18 décembre 2020 (API V3.0.0) (FRONT V3.0.0)¶

Mise en production de la nouvelle API et des nouvelles interfaces web de NAKALA¶

La nouvelle version des API comprend :

- créer, gérer et administrer vos dépôts 
- un moteur de recherche 
- un entrepôt OAI-PMH
- un accès à l'API Image de IIIF 
- une visionneuse pour les fichiers deposées

Nouvelle API : https://api.nakala.fr/

La nouvelle interface est refondue pour faciliter le dépôt. Elle a été conçue selon les principes de l’UX design.

Nouvelles interfaces web : https://nakala.fr/.

Dernières mises à jour de Nakala (API, Front et NAKALA_PRESS)¶

05-05-2025 (FRONT 3.17.0 - NAKALA_Press 1.7.0)¶

Nouveautés¶

Référencement de NAKALA par Google¶

Corrections¶

NAKALA_Press¶

18-04-2025 (API 3.22.0 - FRONT 3.16.0)¶

A/ Nouveautés¶

Liste des sites NAKALA_PRESS¶

API : rechercher par mots-clés avec le endpoint /search¶

B/ Corrections¶

Informations sur les fichiers¶

Doublons dans la base Auteurs¶

03-04-2025 (API 3.21.0 - FRONT 3.15.0)¶

A/ Nouveautés¶

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Suppression de l’encodage dcterms:IMT¶

Suppression de l’encodage dcterms:LCC¶

Suppression de l’encodage dcterms:MESH¶

Limitation de propriétés aux collections¶

Endpoint pour lister les sites NAKALA_PRESS¶

Informations sur les fichiers¶

Demande de moissonnage d’une collection par ISIDORE¶

Affichage des états ‘En attente’ et ‘En erreur’ des dépôts¶

Demande de modération - formulaire de contact¶

B/ Corrections¶

Mise à jour de l’OAI-PMH¶

22-01-2025 (API 3.19.0 - FRONT 3.14.0)¶

A/ Nouveautés¶

Validateur RFC5646¶

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

B/ Corrections¶

29-11-2024 (API 3.17.2)¶

Corrections¶

Mise à jour de l’OAI-PMH¶

27-11-2024 (API 3.17.1)¶

Corrections¶

Perte de droits temporaires¶

19 novembre 2024 (API 3.17.0 - FRONT 3.13.0 - NAKALA_Press 1.6.0)¶

A/ Nouveautés¶

Tri par date de modification¶

Modération : un champ ‘affiliation’ pour identifier le modérateur de son établissement¶

Rappel de l’instance de test NAKALA sur le formulaire de dépôt¶

B/ Corrections¶

Bug sur les droits associés à certains dépôts¶

Affichage des citations avec un encodage incorrect¶

Mise à jour du contenu des info-bulles pour faciliter la description¶

Navigation dans les fichiers pdf (dépôt multifichiers)¶

NAKALA_Press¶

Moissonnage et référencement des sites NAKALA_Press par ISIDORE¶

14 octobre 2024 (API V3.16.0 - FRONT 3.12.1)¶

Corrections¶

Mise à jour des métadonnées envoyées à DataCite¶

Problème d’authentification https¶

30 septembre 2024 (API V3.15.0 - FRONT V3.12.0)¶

A/ Nouveautés¶

Identification automatisée des formats de fichiers¶

Conversion de formats lourds pour leur consultation en ligne¶

Chantier de nettoyage des métadonnées (amélioration de la qualité)¶

Demander la modération d’un dépôt¶

Création du rôle de modérateur¶

Valoriser un dépôt de qualité (statut modéré)¶

Nouveaux formats de citation¶

Retrait de la citation d’une donnée privée¶

Retrait de la citation d’une donnée de test¶

B/ Corrections¶

Suite du chargement de tous les fichiers d’une donnée en une fois (API et FRONT)¶

Amélioration de l’affichage de la galerie (liste de résultats)¶

Métadonnées dcterms:creator de citation envoyées à DataCite¶

Visionneuses : bug d’affichage lors de retours aux pages précédentes¶

25 juin 2024 - NAKALA_PRESS V1.3.0¶

Corrections¶

Erreur 500 lors de l’affichage du site¶

30 mai 2024 - API V3.14.0 - FRONT V3.11.0 - NAKALA_PRESS V1.2.7¶

A/ Nouveautés¶

Bouton de demande de contact du gestionnaire de la donnée¶

Liste des métadonnées renseignées affichée sur la page de présentation (FRONT)¶

Chargement de tous les fichiers d’une donnée en une fois (API et FRONT)¶

Endpoint API : indexation ‘en attente’ des fichiers mal formés¶

B/ Corrections¶