Difference between revisions of "Persistent identifiers(pid)"
Jump to navigation
Jump to search
m (Terminology section added) |
|||
| Line 4: | Line 4: | ||
=== Status === | === Status === | ||
Draft (2022-01-09) | Draft (2022-01-09) | ||
| − | === What are PID === | + | === What are PID and why do they matter to OSGeo === |
* [https://en.wikipedia.org/wiki/Persistent_identifier Definition of PID according to Wikipedia] | * [https://en.wikipedia.org/wiki/Persistent_identifier Definition of PID according to Wikipedia] | ||
| + | |||
| + | === Terminology and Abbreviations === | ||
| + | * PID: | ||
| + | * DOI: | ||
| + | * ISSN: | ||
| + | * ISBN: | ||
| + | * Open Access: | ||
| + | * FAIR: | ||
| + | * Zenodo: | ||
| + | * Landing page: | ||
| + | * CFF: | ||
| + | * GitHub: | ||
| + | * Software Versioning: | ||
| + | * Roles: | ||
| + | * Video quotes: | ||
=== PID for software === | === PID for software === | ||
Revision as of 07:33, 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)
What are PID and why do they matter to OSGeo
Terminology and Abbreviations
- PID:
- DOI:
- ISSN:
- ISBN:
- Open Access:
- FAIR:
- Zenodo:
- Landing page:
- CFF:
- GitHub:
- Software Versioning:
- Roles:
- Video quotes:
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.
Quick Approach: Upload a repository-snapshot to Zenodo
- 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
Coming real soon
Examples
Sustainable Approach: 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 ?)
- Beware: If no CFF or .zenodo.json file is included, the author section of the DOI landing page will be reset to the username of the owner of the GitHub repo. This can be manually edited afterwards, but is awkward.
Howto
- How to make your code citable (Berkeley Library)
- Tutorial video (YouTube)
- Not covered in the video and the Berkeley guido: A file (hard-)named ".zenodo.json" may be added to the top-level of the GitHub repo for advanced author info handling (Example from MOSS project).