Dernière mise à jour de Nakala (API et Front)

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

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

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.

Historique des mises à jour

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

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é.”

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