Difference between revisions of "Persistent identifiers(pid)"
Jump to navigation
Jump to search
m |
m |
||
| Line 2: | Line 2: | ||
=== Scope === | === Scope === | ||
This wiki page summarizes relevant facts and procedures regarding persistent identifers (PID) for the OSGeo communities. | This wiki page summarizes relevant facts and procedures regarding persistent identifers (PID) for the OSGeo communities. | ||
| − | |||
=== Status === | === Status === | ||
Draft (2022-01-09) | Draft (2022-01-09) | ||
| − | |||
=== What are PID === | === What are PID === | ||
* [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] | ||
=== PID for software === | === PID for software === | ||
| − | == Digital Object Identifier (DOI) == | + | ==== Digital Object Identifier (DOI) ==== |
* [https://en.wikipedia.org/wiki/Digital_object_identifier Definition of DOI by Wikipedia] | * [https://en.wikipedia.org/wiki/Digital_object_identifier Definition of DOI by Wikipedia] | ||
| − | == Dealing with different roles within projects == | + | ==== Dealing with different roles within projects ==== |
* [https://github.com/codemeta/codemeta/issues/240 CodeMeta on roles] | * [https://github.com/codemeta/codemeta/issues/240 CodeMeta on roles] | ||
=== PID for people === | === PID for people === | ||
| − | == Open Researcher and Contributor ID (ORCID) == | + | ==== Open Researcher and Contributor ID (ORCID) ==== |
* [https://en.wikipedia.org/wiki/ORCID Definition of ORCID by Wikipedia] | * [https://en.wikipedia.org/wiki/ORCID Definition of ORCID by Wikipedia] | ||
| Line 37: | Line 35: | ||
| − | + | == Howto: Registering a DOI for a OSGeo software Project == | |
| − | == Requirements == | + | === Requirements === |
This should be done by a person who represents the software project (member of PSC or similar). | This should be done by a person who represents the software project (member of PSC or similar). | ||
| − | == Options == | + | === Options === |
ORCIDs for authors, developers and other project staff can be embedded in the DOI metadata, allowing for proper citation. | 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: 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: 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) | ||
| Line 52: | Line 50: | ||
*Con: Every software release requires maintenance work by project staff, as an additional tarball must be uploaded and metadata must be updated. | *Con: Every software release requires maintenance work by project staff, as an additional tarball must be uploaded and metadata must be updated. | ||
| − | =Howto= | + | ==== Howto==== |
Coming real soon | Coming real soon | ||
| − | =Examples= | + | ====Examples==== |
*[https://doi.org/10.5281/zenodo.1163021 rasdaman project] | *[https://doi.org/10.5281/zenodo.1163021 rasdaman project] | ||
| − | == | + | === 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 | *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 ?) | *Con: Takes a bit longer than option 1 (20 minutes ?) | ||
| − | =Howto= | + | ====Howto==== |
* [https://guides.lib.berkeley.edu/citeyourcode How to make your code citable (Berkeley Library)] | * [https://guides.lib.berkeley.edu/citeyourcode How to make your code citable (Berkeley Library)] | ||
| Line 66: | Line 64: | ||
* 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 ([https://github.com/OSGeo/MOSS/blob/main/.zenodo.json Example from MOSS project]). | * 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 ([https://github.com/OSGeo/MOSS/blob/main/.zenodo.json Example from MOSS project]). | ||
| − | =Examples= | + | ====Examples==== |
* [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:24, 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
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 ?)
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).