metadatamanagement
metadatamanagement copied to clipboard
dzhw
doi registration of attachments via cockpit
We should evaluate whether there is a viable way to register a doi for attachments via the cockpit using the da|ra API.
The documentation for the da|ra registration can be found here: https://github.com/dzhw/metadatamanagement/wiki/Metadata-and-DOI-registration-at-dara
There should be a way to register doi in the cockpit interface for the attachments. This interface should contain (at least) all mandatory attributes of the da|ra metadata scheme. The mentioned restrictions introduced by the VerbundFDB can be ignored for registering attachments.
We should start with the data and method report, which is a predefined attachement type.
The ressource type should be text.
The ressource id should be defined as follows:
DZHW:[stuid]-dmr
The doi should be defined as follows (note: this is the version of the attachment not of the datapackage):
https://doi.org/10.21249/DZHW:[stuid]-dmr:[version]
Example for sid2021: https://doi.org/10.21249/DZHW:sid2021-dmr:1.0.0
Defining the landing page is the trickiest part of the whole story, because attachments are not objects in their own right, but files in a file system. The paths in the file system are defined by the data package ID (stuid) and the version of the data package the files are attached to (e.g. https://metadata.fdz.dzhw.eu/public/files/data-packages/stu-gra2005$-2.0.0/attachments/gra2005_MethodReport_de.pdf). When a new version of a data package is released, the files are copied even if no changes have been made to them (e.g. https://metadata.fdz.dzhw.eu/public/files/data-packages/stu-gra2005$-2.0.1/attachments/gra2005_MethodReport_de.pdf). In this case the landing page of the doi should remain the one that is (now) stored in the shadow copy and the file in the new version should get the existing doi not a new one. The new URL could be mentioned in the da|ra attributes as a second but not the main landing page. In this case we have to implement a way to easily transfer the unchanged attachments to the new version of the datapackage.
#3285 An optimal solution for this problem would be to implement attachments as objects with their own detail pages (conceptually, attachments would become overarching objects, as publications and concepts already are). These objects would have a 1:n relationship to data packages, since a single attachment/document could be assigned to many data packages. From my perspective this is a tidy but not a simple solution as we have to deal with legacy problems.