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

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é)

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:W3CDT, 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 ont été conservées mais l’encodage a été remplacé par xsd:string

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. Un deuxième lot d’encodages non pertinents sera prochainement retiré. 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 pour les fichiers .csv permet d’afficher des fichiers, même s’ils comportent des anomalies. Cependant, leur affichage pourra possiblement être perturbé. Dans ces 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 autres URIs 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}

Ajout d’un menu pour naviguer dans les versions d’une donnée

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/.