Difference between revisions of "Persistent identifiers(pid)"
Jump to navigation
Jump to search
(→Howto) |
m (→Examples) |
||
Line 79: | Line 79: | ||
* [https://doi.org/10.5281/zenodo.5825144 MOSS (simple example from a static heritage project)] | * [https://doi.org/10.5281/zenodo.5825144 MOSS (simple example from a static heritage project)] | ||
* [https://doi.org/10.5281/zenodo.5810537 GRASS GIS (complex example from a highly dynamic project)] | * [https://doi.org/10.5281/zenodo.5810537 GRASS GIS (complex example from a highly dynamic project)] | ||
− |
Revision as of 06:16, 9 January 2022
Persistent Identifiers (PID): Introduction and HowTo
Scope
This wiki page summarizes relevant facts and procedures regarding persistent identifers (PID) for the OSGeo communities.
Status
Draft (2022-01-09)
Overview
- What are persistent identifiers and why are they relevant
- PID for software
- PID for people
- PID for data
- PID for documentation
- PID for video
- PID for physical objects
- Infrastructure
- Howto: Registering a DOI for a OSGeo software Project
What are PID
PID for software
Digital Object Identifier (DOI)
Dealing with different roles within projects
PID for people
Open Researcher and Contributor ID (ORCID)
PID for documentation
tbd
PID for data
PID for video
PID for physical objects
tbd
Infrastructure
* Software Repositories (GitHub) * Zenodo
Howto: Registering a DOI for a OSGeo software Project
Requirements
This should be done by a person who represents the software project (member of PSC or similar).
Options
ORCIDs for authors, developers and other project staff can be embedded in the DOI metadata, allowing for proper citation.
Option 1: Upload a snapshot
- Pro: Takes less than 10 minutes to achieve
- Pro: Can be extended and superseeded with better integration options. the DOI will stay always valid regardless and will point to the most up to date software version (and author credits)
- Pro: No need to set webhooks in Zenodo or store description files in GitHub
- Con: Metadata (author list) must be edited manually. (ORCID option ?)
- Con: Every software release requires maintenance work by project staff, as an additional tarball must be uploaded and metadata must be updated.
Howto
Examples
Option 2: Create a live link between the GitHub Repo and Zenodo
- Pro: Immediate automated updates of DOI payload and metadata for each software release on GitHub
- Con: Takes a bit longer than option 1 (20 minutes ?)
Howto
- Tutrial video (Youtube)
- Not covered in the video: A file (hard-)named ".zenodo.json" can be added to the top-level of the GitHub repo for advanced author info handling (Example from MOSS project).