% !TeX document-id = {58c4fd33-701c-43bf-94c8-d7ee5265b1ea}
% !TEX program = lualatex
% !BIB program = biber
%                                                __
%  __                                     __    /\ \
% /\_\    ___      __          __   _ __ /\_\   \_\ \
% \/\ \ /' _ `\  /'_ `\      /'_ `\/\`'__\/\ \  /'_` \
%  \ \ \/\ \/\ \/\ \L\ \  __/\ \L\ \ \ \/ \ \ \/\ \L\ \
%   \ \_\ \_\ \_\ \____ \/\_\ \____ \ \_\  \ \_\ \___,_\
%    \/_/\/_/\/_/\/___L\ \/_/\/___L\ \/_/   \/_/\/__,_ /
%                  /\____/     /\____/
%                  \_/__/      \_/__/
%
%                        journal ing.grid
%
%
% Template for authors
%
% Structure of this template:
% .
% ├── acknowledgements.tex <-- acknowledgements, funding information
% ├── authors.tex         <-- authors and affiliations
% ├── figures             <-- images and pictures
% │   └── image-a.pdf         example image
% ├── fonts               <-- needed fonts
% ├── inggrid.cls         <-- the documentclass
% ├── main.tex            <-- this file, content
% └── references.bib      <-- the bibliography
%
%
\documentclass{inggrid}

\input{metadata/acronyms.tex}
%
%
% The documentclass already loads a number of packages, amongst others:
% - amsmath,amssym
% - xcolor, graphicx
% - babel, csquotes
% - biblatex
% - fontspec, microtype
% - booktabs, longtable
% - listings
%
% -----------------------------------------------




\title{RDM Platform Coscine -- FAIR play integrated right from the start}
\subtitle{} % FIXME needs to be emtpy for now otherwise there is a compiling error (LCB)
\shorttitle{Coscine -- FAIR play}
%
%
% \title and \shorttitle are mandatory, \subtitle can be omitted
%
%

%
%
% In order to anonymise your submission, the information on authors and
% affiliations have to be provided in the file: authors.tex
%
% Thanks and acknowledgements  and funding
% information have to be saved in: acknowledgements.tex
%
%

\keywords{Coscine, Research Data Management Platform, FAIR Guiding Principles, FAIR Digital Object Framework, metadata}
%
%
% 4-6 meaningful keywords that describe the paper



\dataavailability{Data can be found here: \url{git.rwth-aachen.de/coscine}}
\softwareavailability{Software can be found here: \url{coscine.de/}}
%
%
% Please anonymise your repositories with https://anonymous.4open.science/ or similar services
%
%


\addbibresource{references.bib}
\addbibresource{rpdm.bib}
%
%
% Save all your references in this Bib(La)TeX file
\usepackage{xspace}
\newcommand{\FAIR}{\enquote*{FAIR Guiding Principles}\xspace}
\begin{document}
\begin{abstract}
Nowadays, researchers often need to distribute their research data among a multitude of service providers with varying (if any) levels of maturity in terms of FAIR \ac{RDM}. To provide researchers with a single point of access to their project data and to add a \enquote*{FAIR} layer to already established services, the \ac{RDM} platform Coscine was developed. Within Coscine different services (so-called resources) can be added to a project, allowing access to the associated data for all project participants. A \ac{PID} is assigned for each resource and metadata management is integrated with flexibly definable schemas based on \ac{RDF}, \ac{OWL} and \ac{SHACL}. Thereby, Coscine bundles for each project the research data, metadata, interfaces and \acp{PID} into a linked record according to the \ac{FDO} model.
\end{abstract}

\linenumbers
\section{Introduction}
For many researchers, whether from engineering sciences or other fields, an
involvement with the \FAIR \cite{Wilkinson.2016} does not
begin until the publication of an article and the sometimes-obligatory transfer
of the research data to a repository. At this point, a significant amount of
valuable information about the research project is often already lost.
Therefore, only a fraction of the data (and metadata) collected during a
research project is ever published.

\subsection{A Brief Overview on \ac{RDM} Platforms}
\label{sec:platforms}

But even if researchers try to follow the \FAIR  during their whole
data life cycle, it is a big challenge to find a service that offers solutions
for all project-related data types (e.g., managing code, collaborative work,
multiple large files). Therefore, researchers typically employ a broad spectrum
of IT service infrastructures for their projects that range from local to
centralized, federated and external IT service providers. Central applications
like Radar \cite{Kraft.2016} or MASi \cite{Grunzke.2019} are less specific and
address a wider community with more generic \ac{RDM} workflows. External
\enquote*{clouds} like Zenodo, Figshare or \ac{OSF} support basic \ac{RDM} workflows like
citation or persistent identification. By far most prominent are generic
\enquote*{clouds}, like the Owncloud-based tool Sciebo \cite{Vogl.2015}, Dropbox, Google Drive
or GitLab. They are used to store and manage data, however, these options usually lack in
support of \ac{RDM} workflows or policies.

Taken together, the situation nowadays often leads to a fragmentation of
research data among a multitude of service providers with varying (if any)
levels of maturity with respect to FAIR \ac{RDM}. Moreover, the amount of
service providers makes it hard for researchers to keep an overview over the
entirety of data related to a research project.

\subsection{Goals \& Requirements}

Thus, a software solution is needed to get all research data under one roof
while supporting the \FAIR. Based on the focus on engineering at 
RWTH Aachen University and the associated high volume of research data, initial
analyses and developments towards such a software solution were started at the
\ac{RDM} team of the IT Center in 2018. Two options were analyzed: 
\begin{enumerate}
    \item develop a data management system that replaces all existing services or 
    \item develop a data management system that adds a \enquote*{FAIR} layer to already established services. 
\end{enumerate}
The first option would require an enormous amount of human resources to cover all
functions already developed by other services. A recent study shows, however,
that the software development in the public sector is and will be confronted
with low human resources \cite{SchulzeSpüntrup.2023}. This makes the development
of a data management system that replaces all existing services an unattainable
goal in the near future. The second option thus has two direct advantages: 
\begin{enumerate}
\item  the data management system does not have to cover all the functions of already
   established services, but can focus entirely on adding features for compliance with the \FAIR and 
\item researchers can use all their established services and still get access from one platform.
\end{enumerate}


To create such a data management system that supports researchers during their
whole data life cycle, the \ac{RDM} platform Coscine was developed at the IT
Center of the RWTH Aachen University
(\autoref{fig:ResearchDataLifeCycle_Coscine}). Since 2020, the development is
further supported by two consortia of the \ac{NFDI}: NFDI4Ing
\cite{Schmitt.2020} and NFDI-MatWerk \cite{Eberl.2021}. These consortia aim to
develop \ac{RDM} solutions that, at best, can be applied to other disciplines as
well. For the engineering sciences, NFDI4Ing was founded to develop,
disseminate, standardize and provide methods and services to make engineering
research data FAIR\footnote{see \url{https://nfdi4ing.de/about-us/}}.

In this paper, we show which features Coscine provides for researchers and how
they support the \FAIR -- from the initial collection of data to its
subsequent reuse.

\begin{figure}
	\includegraphics[width=\textwidth]{ResearchDataLifeCycle_Coscine.png}
	\caption{Using Coscine along the research data life cycle. The usage of Coscine starts at the beginning of a project, when the project-related metadata is defined and project participants are invited. During the production and analysis phase, Coscine provides access to project-related (meta)data for all project participants. Depending on the used resource type, (meta)data can be archived inside the respective resource. To access the (meta)data, Coscine assigns for each resource a \acs{PID} and offers the possibility to add externals to a project. The reuse of (meta)data is supported by an internal search function.}
	\label{fig:ResearchDataLifeCycle_Coscine}
  \end{figure}

\section{Core Features of Coscine}

Coscine is a platform for the management, storage and archiving of research
(meta)data generated in the context of research projects. For each project,
Coscine allows inviting all project participants, integrating the project-related
data from different resources and adding the related metadata
(\autoref{fig:ResourcesMetadata}).  Specifically, Coscine offers researchers the
following core features:


\subsection{Integration}
By integrating various already established services, so-called resources
(\autoref{fig:ResourceTypes}), researchers can see and manage all project data
in one place via the Coscine web interface or the Coscine API. Currently,
resource types of the \ac{RDS} (see below), Linked Data and GitLab are
integrated. For the end of 2023 also cloud applications such as Sciebo and
Nextcloud shall be added as resource type. Based on customer requests or market
changes, additional resources can be continuously added or others replaced.

\begin{figure}
	\includegraphics[width=\textwidth]{flowchart_resources_in_coscine.drawio.png}
	\caption{Resource Types in Coscine.To date, there are three different resource types in Coscine: RDS (subtypes: Web, \ac{S3}, \ac{WORM}), GitLab, and Linked Data. The decision diagram helps to select the right resource type based on different project needs.}
	\label{fig:ResourceTypes}
\end{figure}

\subsection{Storage Space}
Coscine provides researchers of participating universities access to storage
space on the \ac{RDS}. The \ac{RDS} is a consortial object storage system funded
by the \ac{MKW} and the \ac{DFG}. When using \ac{RDS} resources, a retention and
archiving period of research data of ten years after the end of a research
project is ensured in terms of \ac{GSP}. By default, employees of participating
universities receive 100\,GB of storage space per project for their research
data, which they can distribute among several so called \ac{RDS}-Web resources.
For large amounts of data, more storage space can be requested. It is also
possible to request \ac{RDS-S3} resources to interact directly with the \ac{S3}
buckets or \ac{RDS-WORM} resources to store research data with high protection
requirements and prevent subsequent manipulation of the data
(\autoref{fig:ResourceTypes}).

Researchers can apply for \ac{RDS} storage space using the \ac{JARDS}
\cite{Janetzko.2019} (\autoref{fig:JardsApplication}). The \ac{JARDS} platform
allows researchers to create and manage their applications as well as \ac{RDM}
experts to review these applications regarding formal, technical and \ac{RDM}
specific feasibility. If large amounts of storage (>125\,TB) are requested, a
scientific review is performed to ensure the scientific value of the project.
\ac{JARDS} is already widely used within the high-performance computing
community in Germany, so many researchers are already familiar with the
platform and the procedure. Researchers thus may request storage space independently of their affiliation, however whether access is granted remains a policy of the storage provider. Especially for \ac{RDS} storage, space may be provided for use cases endorsed by any \ac{NFDI} consortium if they meet the formal, technical and scientific criteria mentioned above.

\begin{figure}
	\includegraphics[width=\textwidth]{JARDS_Application_Overview.png}
	\caption{\ac{JARDS}: Overview of ongoing and approved applications}
	 \label{fig:JardsApplication}
\end{figure}

\subsection{Collaboration}
Coscine allows access for all internal and external members of a research
project. Users can log in as a member of a participating organization via
Shibboleth or as an external person via their \ac{ORCID}. While the ability to request certain storage services may be restricted, once added to a project the resource is available for all member. Basic functionalities like project and metadata management are available to all users.  
Project members can be invited to projects in a low-threshold way via their email,
enabling easy collaborations.

\subsection{Metadata}
The use of Coscine involves three levels of metadata: at the project, resource,
and data level. Adding metadata at the project and resource level is mandatory,
and the necessary fields are standardized for all users and disciplines. At the
data level, users can choose between different application profiles to optimally describe their research data inside a resource. All metadata are captured according to flexibly definable schemas that follow
\ac{RDF}, \ac{OWL}, and \ac{SHACL} standards. This allows a Coscine-wide search for all available metadata. 

Individual application profiles
can be created using the integrated application profile generator, 
developed within the \ac{DFG}-funded project \ac{AIMS} \cite{Gronewald.2022}.
% Project-ID 432233186
This application profile generator allows researchers to create new application profiles
from scratch or explore and extend already existing ones (\autoref{fig:AIMSFrontend}). 
New profiles can be sent as a merge request to the GitLab repository of Coscine, where they are
reviewed by \ac{RDM} experts to ensure a required level of technical quality
and interoperability for Coscine.


% AIMS - Vertiefender Satz zu AIMS Projekt plus Webseite

\begin{figure}
	\includegraphics[width=\textwidth]{AIMS_Coscine_Frontend.png}
	\caption{Screenshot of the application profile generator developed within \ac{AIMS} \cite{Gronewald.2022}.}
	 \label{fig:AIMSFrontend}
\end{figure}

\subsection{Archiving}
After completion of a research project, research data and metadata stored in resource types of \ac{RDS} or Linked Data can be archived for ten years according to \ac{GSP}. Thanks to the link to metadata, the assignment of a \ac{PID} and the existing access for project members, Coscine facilitates the low-threshold subsequent use of the research data even during archiving. 

\begin{figure}
	\includegraphics[width=\textwidth]{ResourcesMetadata.png}
	\caption{The project structure of Coscine. For each research project, researchers can invite all project participants (above -- light blue circles), integrate the project-related data from different resources (left side -- gray circles) and add the related metadata (right side -- blue circles).}
	\label{fig:ResourcesMetadata}
\end{figure}

\section{Coscine \& \FAIR}
To enable the accessibility of research data in line with the \FAIR  across
institutional borders, Coscine can be accessed either through participating
universities or at a low-threshold level via \ac{ORCID}. After
registration, researchers can create a research project and invite all
project-related participants. The project creator is automatically the project
owner and can choose between three different roles for the other participants
(owner, member, or guest). In line with  A1.2 of the \FAIR
\cite{GOFAIR.2023} the mandatory registration of project participants ensures
the authentication of all data owners and contributors for each dataset, while
the role management enables the definition of user-specific rights.

\subsection{Metadata Representation}

For research projects, metadata is collected at three levels and automatically
linked to the research data. The first level of metadata relates to the research
project (including name, description, \acp{PI}, discipline). The second level of
metadata describes the resources, which are assigned to the research project
(including resource name, discipline, keywords, metadata visibility, license).
The third level of metadata is realized via application profiles that describe
the uploaded or linked research data. For this step the researchers must select
for each resource an application profile from various predefined profiles, e.g.,
for engineering research data the established EngMeta profile can be used. If a
suitable application profile has not yet been added to Coscine, the \ac{AIMS}
Application Profile Generator \cite{Gronewald.2022} can be used to create a
profile with individual and discipline-specific metadata. When using the storage
resource type RDS-Web, file upload is only possible after entering the
associated metadata in the application profile. In this way, Coscine makes
metadata entry a direct part of the researcher's workflow, supporting the FAIR
principles.

The \ac{W3C} standards \ac{RDF} \cite{Cyganiak.2014} and \ac{SHACL}
\cite{Knublauch.2017} are used for the technical representation and validation
of all metadata stored in Coscine. This largely complies with the FAIR
principles regarding findability, interoperability, and reusability of metadata
\cite{GOFAIR.2023}. By using the \ac{AIMS} Application Profile Generator
\cite{Gronewald.2022} researchers without knowledge regarding \ac{RDF} and
\ac{SHACL} can still create an application profile that suits their needs while
being FAIR regarding the technical representation and validation.

Following the recommendations of the FAIR principle F4, the (meta)data are
indexed in Coscine in a searchable resource via ElasticSearch. To also publish
the semantically-rich and machine-actionable metadata, we work on implementing
\ac{FDP} as a standardized interface \cite{daSilvaSantos.2023}. Moreover, a
connection to the NFDI4Ing metadata hub is currently realized via "FAIR Digital
Object" interfaces.

To support researchers' processes as much as possible and to align with A1
\cite{GOFAIR.2023}, Coscine provides open, free and universally implementable
protocols to access data based on the resource type, either via a browser, using
a REST API or directly via an \ac{S3} interface. This allows for high
performance transfer of even large amounts of research data.

Regarding the FAIR principles F1 and A1 \cite{GOFAIR.2023}, Coscine assigns for
each resource (including data and metadata) a handle-based ePIC-\ac{PID}
\cite{Kalman.2012,Kramer.2016}. This is used to uniquely and permanently
identify the location of the resource and all contained files on a global level.
As a result, each RDF-triple includes a \ac{PID} leading to the data it
describes. Within resources, fragment identifiers are used to address individual
files by extending the handle URL.

Even though the technical standards used by Coscine to represent metadata are featuring a set of complex technologies, they are mostly hidden for the average user of the web user interface or the REST API respectively. Hence, a researcher in a lab or even a data scientist storing, annotating and accessing data can make use of the underlying standards without going into technical details. This is slightly different for data stewards, who are often required to configure projects or create application profiles. The creation process is partly supported by the \ac{AIMS} Application Profile generator, however advanced use cases will likely require some knowledge of \ac{RDF} to (re-)use or define vocabulary terms or thesauri. Most advanced users could create complex queries using \ac{SPARQL} for the metadata stored in \ac{SHACL} validated graphs \cite{Politze.2019}. In turn, this requires in depth knowledge of the used technologies and terminologies.

The layers in Coscine (metadata, interfaces \& operations and persistent
identifiers) that increase the FAIRness of the research data can be best
described with the framework of \acp{FDO}. 


\subsection{Coscine \& FAIR Digital Objects}

The FAIR principles are about making data findable, accessible, interoperable
and reusable both for humans and machines. To reach these aims, \ac{RDM}
software requires a framework to store and disseminate digital objects in a
robust and informative way.


Although the concept of \ac{DO} was introduced by Robert Kahn in the early
1990s, an ecosystem of easy tools that add the \ac{FDO} layers to raw data
including unique identifiers and metadata is still needed
\cite{Kirkpatrick.2022}. This issue is most prominent in current industry grade
IT solutions on the market, as used for the \ac{RDS}. While these usually
provide high scalability at reasonable costs, their focus is clearly on (mostly)
standardized storage of and access to binary information rather than (global)
identification or (fine granular) description of the data itself.


Using the notion of the \ac{FDO} as shown \autoref{fig:coscine-fairdo}, Coscine
adds on to the bit sequences in a storage system with required elements as
successive layers: metadata, interfaces \& operations and finally a persistent
identifier. All the elements of the \ac{FDO} form a logical unit that can be
distributed and fully interpreted in solitude. While \ac{FDO} supplies a generic
architecture, different frameworks exist for their representations
\cite{Heinrichs.2022}.

\begin{figure}
    \centering
    \includegraphics[width=0.5\textwidth]{coscine-fairdo.drawio.png}
    \caption{A layered model of an \ac{FDO} with the elements needed to make the data FAIR: bit sequence, metadata, interfaces \& operations and the persistent identifier \cite{DeSmedt.2020}.}
    \label{fig:coscine-fairdo}
\end{figure}

For retaining the bit sequence of the \ac{FDO} Coscine relies mostly on a
background storage system. In the case of the \ac{RDS} the provided HTTP based
\ac{S3} interface can be directly handed through to the client. For storage
service that do not provide an HTTP accessible interface or in cases where
access management is required, Coscine provides means for protocol translation.
Coscine aims to combine approaches from two frameworks: \acp{PID} based on
\acp{KIR} \cite{RDA.2018} and the semantic approach of the \ac{FDOF}.

On the one hand, the \ac{KIR} work \blockcquote{RDA.2018}{by injecting a tiny amount of carefully
selected metadata into a [PID] record}. While the metadata set
is typically small and rather technical key-value-pairs, directly adding it into
the \ac{PID} provides basic information about the described \ac{FDO} without the
need of querying additional metadata indexes. The \ac{FDOF}, on the other hand,
provides a set of conventions that suggest \blockcquote{Bonino.2022a}{predictable resolution behaviour} for accessing bit sequences and binding rich and discipline
specific semantic metadata in the form of linked documents. An \acp{FDO}
implemented with the combination of both frameworks thus is machine and human
actionable, technically and semantically meaningful, and widely technologically
independent.

The \ac{KIR} is used by Coscine to store information about the (file) type of
the \ac{DO} and how it can be accessed. Additionally, Coscine provides links
that can be followed to access the bit stream and the semantic metadata
documents. The semantic representations can be retrieved from using interfaces
compliant to the \ac{FDP} specification that builds upon \ac{LDP} and extends
\ac{DCAT} with a metadata service. While \ac{LDP} and \ac{DCAT} allow discovery
of data along the hierarchies defined by projects, resources and files, \ac{FDP}
defines the access to the rich semantic metadata and the respective application
profiles for the different levels of the aforementioned hierarchy.

\section{Coscine -- Options for Process Automation}
Many approaches to \ac{RDM} consider an ideal scenario where researchers start
from scratch with a new project. However, this is often not the case, since
research projects have a very long lifetime and sometimes a correct management
of the data and the corresponding metadata was not originally considered. In
addition, research projects are generating increasing amounts of data, which requires flexible automation of data handling processes. Thus, supporting this type of
projects in Coscine is important as it allows easier adaption of the platform on
a larger scale.

\subsection{Data Upload}
Depending on the requirements of the researchers, different resource types and
ways for interactions (e.g., web UI, REST API, S3 protocol) are available in
Coscine, of which \ac{RDS-S3} in particular is suitable for handling large
amounts of (already existing) research data (\autoref{fig:ResourceTypes}). The
\ac{RDS-S3} resource type allows an easy interaction with the underlying storage
system. Research data can be directly uploaded to the \ac{S3} bucket through a
variety of programs, e.g., rclone or minio. Moreover, for each \ac{RDS-S3}
resource there are two access keys available with different permissions (writing
and reading), thereby also allowing easy reuse of the data.

\subsection{Coscine API}
After resource creation and before uploading the research data, the associated
metadata must be entered into the application profile through a form on the website, which supports the use
of suitable metadata default values and editing a batch of files at once. This
approach of metadata management is especially feasible for smaller data sets,
but for working with large amounts of research data, we recommend using the
Coscine API\footnote{see \url{https://docs.coscine.de/de/advanced/api/}}.

The API allows the use of all functions that are available on the website
through scripts. To secure the access, a token is required, which can be created
on the website. A token belongs personally to a unique user and allows the use of all
functions that the user could access through the website. During creation, each
token is assigned a time frame, in which it is valid. The maximum time frame is
one year, thereby a regular revision of the access rights is ensured. Every token
can be revoked at anytime, in case a token is no longer required or if it has been
compromised.

The token can be used to interact with the API, which comes with an extensive
documentation of all endpoints, parameters, and return values
\cite{CoscineAPIDoc.2023}. Swagger, an open-source tool set for API development, interaction and documentation \cite{Swagger.2023}, is used to allow the exploration and
execution of example queries through a website. An option exists to create
commands for every query that can be used to a create a custom script to upload
the metadata. Through the detailed documentation and the possibility to copy
snippets with working queries it is possible for users without a background in computer
science using the API and automate parts of their workflow.

Existing research project have often already research data available that can
be extracted from the environment or from some files that are stored along with the
research data. With the tools described above, it is also possible to write a
script that allows adding the locally available metadata to the files that are
uploaded to Coscine.

\subsection{Taskforce \enquote*{Coscine Technical Adaptation}}
To support researchers with the technical adaptation of the \ac{RDM} platform
Coscine, a group of developers and data stewards has been established -- the
\ac{CTA}. The \ac{CTA} is in direct contact with research groups from different
disciplines. Its aim is at firstly understanding the researchers’ workflows 
in order to provide scripts, programs, tools, and best practices for the interaction with
the platform \cite{CTADoc.2023}. The provided material is publicly available
under an open-source-license and researchers are encouraged to get involved with
the development. Of course not every workflow can be generalized, however
frequent exchange with the researchers allows a better understanding of the
requirements and challenges for the adaptation of Coscine and improves the
quality of \ac{RDM} in the different research groups (e.g. automation of
metadata collection).

\section{Discussion}

Coscine offers a technical environment to follow the \FAIR, however,
the platform does not replace the need for subject-specific \ac{RDM} knowledge --
e.g., provided by data stewards employed in research projects. For example, the
level of richness in metadata (reusability) is determined by the selection and
completion of the application profile by the researchers. Furthermore, the
link to domain-specific vocabularies and ontologies during the creation of
application profiles depends on the expertise of the creating researchers.

\subsection{Use Cases}

As Coscine is a general service offering, most researchers are able to integrate Coscine into their day-to-day work without further assistance of the core team. Nevertheless, we can present some illustrative projects using the platform that happened to come to our knowledge due to the feedback of the respective data stewards.

Jan Rüth et.\,al. presented their formerly evolving dataset of incoming ICMP internet traffic \cite{hiddentreasuresPAM2019}. Over a timespan of about a year, several gigabytes of daily log files were collected and made accessible to the public. Daily metadata to the files could include the current version of the application used. The daily datasets are stored in an \ac{S3} resource and are linked from the projects' website.

Thomas Hitch et.\,al. create a continuously growing collection of bacterial strains, isolated from the human gut \cite{Hitch.2023}. Again data is stored in an \ac{S3} resource and annotated with various metadata fields describing the cultivation, isolation, and genome assembly which were previously stored in an SQLite database. Data can be accessed by a specially created web application that allows filtering for different aspects of metadata using the REST APIs of Coscine.

\subsection{Comparison of Features}

Looking back at the previously mentioned \ac{RDM} platforms in \autoref{sec:platforms} there are some key differences that led to the realization of Coscine. However, it is to be noted that this aims to give a broad overview and not a rigorous review nor an exhaustive comparison. Alternative producs are compared in three rough categories: Research Oriented Databases, \acp{ELN}, Knowledge Graphs, and Repositories.

\subsubsection{Research Oriented Databases}

This category includes discipline oriented databases and workflow management systems. Examples for these are FurthrMind\footnote{see \url{https://www.furthrmind.com/}}, or idCarl\cite{Babaei.2024} explicitly target specific disciplines. These systems usually support the direct recording of data and metadata within the database. As the contents are based on the often discipline specific schemas or formats, they usually do not provide means to support usage by multiple disciplines at the same time or require heavy customizations to do so. If at all, these applications only consider discipline specific standards rather than overarching standards e.g. those provided by the W3C.

\subsubsection{Electronic Laboratory Notebooks}

Almost like the Databases presented in the previous section \acp{ELN} are typically motivated by individual scientific disciplines e.g. eLabFTW \footnote{see \url{https://www.elabftw.net/}} (chemistry), chemmotion \footnote{see \url{https://chemotion.net/}} (chemistry), or labfolder\footnote{see \url{https://labfolder.com/}} (life sciences). Nevertheless, they can often be applied across disciplines. They typically focus on recording individual steps along laboratory experiments. Tabular data can often be embedded or attached with other binaries. Most \acp{ELN} feature group and project structures and some have agreed on a common standard to exchange information\footnote{\url{https://github.com/TheELNConsortium}}. \acp{ELN}, however, often lack ability to validate metadata according to semantic profiles and do not support storage of very large files.

\subsubsection{Knowledge Graphs}

Knowlegde Graphs offer a form of databases that allow interlinking of datasets within a database. Some like CaosDB\footnote{see \url{https://caosdb.org/}} use proprietary formats, others like Semantic Media Wiki \footnote{see \url{https://www.semantic-mediawiki.org}} are based on standard technologies like \ac{RDF}. While the data model is also used for metadata stored in Coscine, Knowledge Graphs usually do not validate their contents based on application profiles and only link binaries from external sources. Furthermore, knowledge graphs typically only offer instance level access permissions and do not have a more fine-grained access management.

\subsubsection{Repositories}

The last regarded category are traditional data repositories like Radar\footnote{see \url{https://www.radar-service.eu/radar/de/home}}, or Dataverse\footnote{see \url{https://dataverse.org/}}. These applications usually offer instance wide metadata schemas or are even limited to bibliographic metadata. Further more repositories likely focus on finalized data sets and do not consider changing data after it was uploaded. This is surely required for publication but is a use case explicitly covered by Coscine allowing collaboration in early stages of research before data is ready for publishing.

\subsection{Limitations}

Coscine does not cover all steps of the data life cycle
(\autoref{fig:ResearchDataLifeCycle_Coscine}) completely -- especially regarding
the publication of research data. This is mainly due to the generic approach of
Coscine, which contrasts with the recommended subject-specific publishing of
data in established repositories. In addition, Coscine has been explicitly
developed as an access point for so-called \enquote*{warm} research data, thereby
deliberately allowing files behind a \ac{PID} to be modified during the course
of the project. 
Coscine is continuously improved in order to promote the publication of data: 
Currently a contact form is established to contact advisory services (e.g. libraries).
This will enable researchers to share project metadata relevant for publication
with the respective advisory centers.

Moreover, the core development team of Coscine can not provide access to very
specific service providers for single communities due to limited resources.
However, since Coscine is being developed as an open-source platform, the
addition of other community-specific resource types could also be realized by
external development teams \footnote{see \url{https://git.rwth-aachen.de/coscine}}. For contributions from external developers, the core development team monitors pull requests, has set up a publicly available issue tracker for discussions\footnote{see \url{https://git.rwth-aachen.de/coscine/collaboration/issues/-/issues}} and makes the strategic decision processes publicly available for discussion \footnote{see \url{https://git.rwth-aachen.de/groups/coscine/-/epic_boards/539}}.  

While the source code of Coscine is available to everyone under an open-source license, the application is built as a service offering. Much like \ac{OSF}, there is currently little to no support by the maintainers for local installations. This is mostly due to dependencies and access requirements to administrative interfaces of PID services and storage providers that could require significant adaptations when transferring to a local installation. However, further development will likely go into the direction of a more federated service based on the \ac{FDO} concept.

\section{Conclusion}

Coscine is a strong partner for researchers in their daily \ac{RDM}: 
Thanks to the access to storage space, interfaces for automation as well as
extensive collaboration possibilities, Coscine enables compliance with the \FAIR.
This spans from the very first storage of data by bundling raw data, metadata,
interfaces and \acp{PID} to a linked record according to the \ac{FDO} concept.
Coscine ensures that these data objects are also independently findable and
accessible via the API. The API allows researchers to easily enter their data and
metadata into the system and facilitates subsequent use of the same.

While the creation or adaptation of some kind \ac{RDM} platform was inevitable, choosing to implement a new open-source service offering based on existing \ac{W3C} standards was a bold step. It would likely not have been successful if the accompanying projects had not started at the same time. On the other hand, was the clear need for an implementation that picks up the semantic web technologies and makes them available to a broad user community. Apart from the implementation and operation work for the platform, sufficient work power needs to be available for data stewards, community management, and engagement in the further development of the standards taking place in various working groups in the \ac{NFDI}, \ac{RDA}, \ac{W3C} and several small independent working groups.

In addition, the API enables token-based authentication to automate workflows. Even
for externally stored research data, Coscine allows increasing FAIRness by
linking data with metadata and assigning \acp{PID}. In this way, Coscine is
a valuable contribution to the goal of NFDI4Ing: foster proper \ac{RDM} in
engineering sciences that implements the \FAIR.

\end{document}
