NAKALA documentation¶

Introduction and presentation¶

What is NAKALA used for?¶

NAKALA is a Huma-Num service allowing researchers, teacher-researchers or research teams to share, publish and enhance all types of documented digital data (text files, sounds, images, videos 3D objects, etc.) in a secure warehouse in order to publish them in accordance with the principles of FAIR data (Easy to Find, Accessible, and Publish). (Easy to find, Accessible, Interoperable and Reusable).

NAKALA ensures both the accessibility of data and metadata as well as their “citability” over time with using stable identifiers provided by Huma-Num and based on Handle and/or DOI.

NAKALA is part of the Web of Data, which makes it possible to make metadata interoperable, i.e. the possibility of connecting them to other data. to be able to connect them to other existing warehouses, thus following the logic of open and linked data (Linked Open Data). data (Linked Open Data).

In addition, NAKALA also offers a metadata exposure system that allows them to be referenced by specialized specialized search engines such as ISIDORE.

NAKALA is part of a coherent set of services set up by Huma-Num to facilitate access, reporting, preservation and reporting, conservation and long-term archiving of research data in SHS.

The rich, precise and harmonized description of your data with NAKALA allows them to be understood in the long term, to guarantee their traceability and to be used as a basis for research. traceability over time and to control their reuse.

When should NAKALA be used?¶

It is interesting to use NAKALA in cases where you wish to publish online a set of data and descriptive metadata with a scientific consistency (corpus, collections, reports, etc.).

For example, a video file deposited in NAKALA can be inserted into web pages, as in the case of a Hypotheses research notebook or in a web-documentary.

There are several ways to use the data in NAKALA:

• You use the NAKALA_Press publishing module offered by Huma-Num;
• You use existing tools such as a blog engine, a CMS, etc. ;
• You have the technical skills and you develop your site on top of NAKALA’s APIs.

Huma-Num supports:¶

• A secure copy of your data and metadata on its infrastructure ;
• Assigning a stable identifier to allow citation (Handle before 2020 and DOI);
• Interoperable provision of your metadata based on Web of Data technologies;
• Exposure of data metadata through the OAI-PMH document protocol;
• The durability of the public web interface generated by the NAKALA_Press publishing module.

In short, what does NAKALA do?¶

• It relieves you of the management of your data;
• It allows you to visualize them;
• It allows you to group and present them in homogeneous collections;
• It supports the interoperable sharing of data and metadata and their citability;
• It separates data storage from data presentation;
• It prepares the referencing of data in ISIDORE and facilitates the long-term archiving process;
• It allows the editorialization of your data in a personalized web site of type https://monprojet.nakala.fr thanks to NAKALA_Press publishing module.

What does NAKALA not do?¶

• It does not enrich the data;
• It does not allow the storage of sensitive or sub-rights data.

Using NAKALA¶

Requesting an account¶

To access NAKALA, you must go to HumanID and request to open this service for your account. You can also browse, search and use published NAKALA data without published NAKALA data without logging in.

Using NAKALA¶

Requesting an account¶

To access NAKALA, you must go to HumanID and request to open this service for your account. You can also browse, search and use published NAKALA data without published NAKALA data without logging in.

Home and Dashboard¶

Once your account has been created and your access to the service has been validated, you will be able to access the various features of NAKALA:

• A Dashboard tab allows you to follow the metrics of your data in a quantified way: number of data A dashboard tab allows you to follow the metrics of your data in a quantified way: number of data deposited/published, consultations of these data, downloads, private storage, frequency of deposits. This page is personal to you;
• A Data tab allows you to list your data or data that other users have shared with you;
• A Collections tab allows you to manage your different collections as well as those shared with you by other users;
• A Lists tab allows you to manage your user groups in order to more easily manage access and contribution rights to your repositories and contribution rights to your repositories;
• A Websites tab allows you to manage your different NAKALA_Press websites.

The distinction between collection and data¶

All the data deposited in NAKALA can be grouped into collections. A collection groups together a set of coherent data. You can thus have several collections, corresponding to different research projects and including different contributors with specific rights within these collections. Any public collection constitutes a set in the NAKALA OAI-PMH exhibition. This OAI set can, by request to isidore-sources@huma-num.fr, be indexed by the ISIDORE engine and presented as a collection in this platform.

Creating a collection, managing rights and groups¶

When creating your collection, you can choose :

• Whether it is private or public (mandatory metadata);
• Its title(s), specifying or not their language (mandatory metadata);
• Additional and optional information on the description of this collection, its keywords, etc. ;
• The rights related to this collection and the role of the contributors associated with it. Following the addition of a user or a list of users, a small eye allows you to give the user of the collection the administrator, editor or reader**.

To facilitate the addition of members, it is possible to create lists of users (belonging to the same project, for example) in the lists and then add this list directly to the collection. Similarly, in the tabs Collections and Data, the Shared with me** feature allows you to identify which data or collections the collections the user has in common.

A piece of data can belong to several collections. There is no hierarchy between collections. A collection can only contain published** data. You don’t have to have administration or read rights on a published data to rights on a published data to be able to add it in your collection.

The management rights of a collection are independent of the management rights of the data it contains. This means that if you give read rights to a user on a collection that contains unpublished data, you will also have to give that user read rights on a collection that contains unpublished data. published data, you will also have to give that same user read rights to the data if you want him to be able to access it. to have access to it.

Each public collection is a set for the NAKALA OAI-PMH server.

Depositing data in NAKALA¶

NAKALA data consists of one or more files and descriptive metadata. There are two ways to upload data to NAKALA:

• Either through the web interface using the drag / drop / navigate functions where the user selects the file(s) he wants to deposit for the data in NAKALA.

• Or via the NAKALA API: in this case, each data file associated with the metadata is to be uploaded first via POST /uploads and then the related metadata is uploaded via the POST /datas tab. The use of the API is to be preferred for the implementation of a deposit by batch while waiting for the availability of this functionality directly from the of this functionality directly from the web interface (under development at Huma-Num).

File visibility and embargo¶

When depositing a data, it is possible to manage the visibility date of the files of this data. By default, the files are visible as soon as they are submitted. You can decide to make them public from a certain date, or never. When a file is embargoed, only users with at least the reader rights on the data can consult the embargoed files of this data. The metadata remains public.

Distinction between deposited and published data¶

After having duly filled in the metadata corresponding to the data, the user has the possibility of depositing his data or data or to publish them.

• The deposit makes the data and its files visible only to users with access rights. It It is a transitory state before final publication (e.g.: proofreading stage). Each user has a limited storage space for this unpublished data (1000 data or 2 GB). Unpublished data cannot belong to a public collection and cannot be public collection and cannot be edited in a NAKALA_Press site. A deposited data can be deleted.
• Publication makes the data accessible and reusable by all. The DOI is published at Datacite. There is no specific storage limit for published data. Data can be published with embargoed files if only the metadata must be freely accessible. The publication of a data is final. It is not possible to delete or It is not possible to delete or unpublish data that has been published unless a specific request is made to the Huma-Num team.

NAKALA data model and metadata format¶

Users can describe their data according to several vocabularies (NAKALA, DublinCore and FOAF for now). You can propose to Huma-Num team new vocabularies to complete this list.

Five metadata are mandatory to describe a data:

• Title** (nakala:title, multivalued)
• Type** (nakala:type, unique)
• Author** (nakala:creator, multiple values)
• Date** (nakala:created, unique)
• License** (nakala:license, unique)

This metadata must be expressed at repository time in the NAKALA vocabulary, but can be converted to DublinCore at the time of data query via the API or via the OAI-PMH protocol.

It is possible to add multiple nakala:title titles with or without specifying the language of each. NAKALA offers a list of over 7000 living or extinct languages according to ISO-639-2 and ISO-639-3 standards.

NAKALA offers autocompletion of the authors’ database according to the deposits made by the users. If an author is not available in the autocompletion proposed from the web interface, it is possible to add a new one by clicking on “Add other authors” at the bottom of the autocompletion result. Each author can be described by his name, first name and possibly an identifier [ORCID] (https://orcid.org/). When the author cannot be filled in, it is possible to check the “Anonymous” box via the web interface or to fill in a value of null via the API. It is possible to fill in other author forms by adding metadata from the DublinCore vocabulary.

The expected date format for nakala:created is YYYY, YYYY-MM or YYYY-MM-DD. When the date is unknown or cannot be filled in, it is possible to check the “Unknown” box via the web interface or set the value to null via the API. the API. It is possible to indicate other date formats by adding for example a metadata in the DublinCore vocabulary.

The expected date format for nakala:created is YYYY, YYYY-MM or YYYY-MM-DD. When the date is unknown or cannot be filled in, it is possible to check the “Unknown” box via the web interface or set the value to null via the API. the API. It is possible to indicate other date formats by adding for example a metadata in the DublinCore vocabulary.

The nakala:type and nakala:license metadata must contain values from the repositories used in NAKALA. The license repository currently contains over 400 values. You can propose to the Huma-Num team new values to complete this list if needed. to complete this list if needed.

NAKALA data types are identical to those used in the ISIDORE engine. The list is available in the table below or via the API at URL https://api.nakala.fr/vocabularies/datatypes.

Type	URI
image	http://purl.org/coar/resource_type/c_c513
video	http://purl.org/coar/resource_type/c_12ce
audio	http://purl.org/coar/resource_type/c_18cc
publication	http://purl.org/coar/resource_type/c_6501
poster	http://purl.org/coar/resource_type/c_6670
presentation	http://purl.org/coar/resource_type/c_c94f
course	http://purl.org/coar/resource_type/c_e059
book	http://purl.org/coar/resource_type/c_2f33
map	http://purl.org/coar/resource_type/c_12cd
dataset	http://purl.org/coar/resource_type/c_ddb1
software	http://purl.org/coar/resource_type/c_5ce6
other	http://purl.org/coar/resource_type/c_1843
archive	http://purl.org/library/ArchiveMaterial
art exhibition	http://purl.org/ontology/bibo/Collection
bibliography	http://purl.org/coar/resource_type/c_86bc
bulletin	http://purl.org/ontology/bibo/Series
edition of sources	http://purl.org/coar/resource_type/c_ba08
manuscript	http://purl.org/coar/resource_type/c_0040
correspondence	http://purl.org/coar/resource_type/c_0857
report	http://purl.org/coar/resource_type/c_93fc
periodical	http://purl.org/coar/resource_type/c_2659
pre-publication	http://purl.org/coar/resource_type/c_816b
review	http://purl.org/coar/resource_type/c_efa0
score	http://purl.org/coar/resource_type/c_18cw
survey data	https://w3id.org/survey-ontology#SurveyDataSet
text	http://purl.org/coar/resource_type/c_18cf
thesis	http://purl.org/coar/resource_type/c_46ec
web page	http://purl.org/coar/resource_type/c_7ad9
data paper	http://purl.org/coar/resource_type/c_beb9
programmable article	http://purl.org/coar/resource_type/c_e9a0

The metadata “Keywords”, associated to the vocabulary dcterms:subject, is linked to the different thesaurii used in ISIDORE. Indeed, NAKALA proposes here in autocompletion all the labels (prefLabel and altLabel) of the concepts of the repositories used by ISIDORE to enrich its data: the Rameau vocabulary, the Pactols, GEMET, LCSH, BNE, GéoEthno, Archires thesauri and finally the Geonames geographic reference frame.

meta_subject](../media/nakala/meta_subject.png){: style=”width:600px; border: 1px solid grey;”}

Today, only the label of the concept is recorded in the metadata of the data. It is therefore up to the depositor to add labels in several languages if necessary. A planned evolution of NAKALA is to record the concept object itself instead of the label and then display or export all the information of the concept (labels, links, …).

When deposited, the data can be integrated into one or more collections, while respecting the constraint that a public collection can only contain published data.

Assigning a permanent identifier: DOI.¶

NAKALA automatically provides a unique and stable identifier for each piece of data deposited, a DOI. There is therefore nothing to to obtain a DOI with NAKALA. As soon as a piece of data is published, the are sent to the search engine, the OAI-PMH server and published in Datacite.

You will be able to access your data through a link constituted in the following way following: https://nakala.fr/*identifier*

For example, if the data has the identifier 11280/000028fb, the link to access or cite the data is: https://nakala.fr/11280/000028fb.

Using and accessing data¶

NAKALA is accessed via the address https://nakala.fr.

When the user is not logged in, NAKALA offers a page for exploring and searching of the data allowing them to be viewed and reused. For example: https://nakala.fr/11280/d6dfc55a

The presentation page for an object is https://nakala.fr/{identifier}, where {identifier} corresponding to a Handle or DOI.

NAKALA has its own OAI-PMH warehouse whose web address is: https://api.nakala.fr/oai2. Each NAKALA collection NAKALA collection corresponds to an OAI set. Thus, all users in the NAKALA space can use the web address of the the OAI-PMH repository to harvest the metadata through document portals ([ISIDORE]). portals (ISIDORE, Gallica, etc.).

Roles in NAKALA¶

The roles of a user on a data are :

• Depositor (ROLE_OWNER) ;
• Administrator (ROLE_ADMIN) ;
• Editor (ROLE_EDITOR) ;
• Reader (ROLE_READER);
• Anonymous (GUEST).

These roles allow to perform the following actions on a data:

Actions	ROLE_OWNER	ROLE_ADMIN	ROLE_EDITOR	ROLE_READER	GUEST
Consultation of a published data	+	+	+	+	+
Consultation of a deposited data	+	+	+	+	-
Consultation of an old version (1)	+	+	+	+	+
Consultation of deleted data (2)	+	+	+	+	+
Modification of data metadata -	-	-
Modification of the metadata of a deleted data or old version	-	-	-	-	-
Publication of deposited data (3)	+	+	-	-	-
Modification of access rights to data (4)	+	+	-	-	-
Deleting deposited data	+	+	-	-	-
Delete published data (5)	-	-	-	-	-

1. This is the consultation of an old version of a published data
2. Only certain information can be consulted (e.g.: title, date of deletion, depositor)
3. To be published, a data must have a certain number of mandatory metadata (nakala:title, nakala:creator, nakala:created, nakala:type, nakala:license)
4. Unlike the ROLE_ADMIN, the ROLE_OWNER cannot be deleted.
5. The deletion of published data can only be done by request to the NAKALA administrator.

Connection with Zotero¶

A connection between NAKALA and Zotero is offered and allows you, through the Zotero web module to reference data from NAKALA in your bibliographic manager with all the corresponding metadata.

Deleting data and archiving¶

NAKALA does not offer the possibility to directly delete published data. When the files of a published data item are modified, a new version of the are modified, a new version of the data is generated and all old versions remain accessible. The modification of the metadata only does not lead to the creation of a new version. If the user wishes to see a published piece of data deleted, they must make a request to nakala@huma-num.fr. However, the DOI of the data will still be however, always retained, even if it is noted as deleted.

Data deposited in NAKALA does not automatically enter a long-term archiving process. To set up this process, you must set up this process, you must contact Huma-Num members via cogrid@huma-num.fr.

If Huma-Num disappears, how will the citability of data deposited in NAKALA be ensured?¶

Since NAKALA uses the DOI naming system to assign a unique identifier to each piece of data, it will still be possible to transfer the database of identifiers to any other structure that will be in charge of the rest of the system ( for example the BnF, CINES, National Archives, etc.).