proycon / codemetapy

A Python package for generating and working with codemeta
https://codemeta.github.io/
GNU General Public License v3.0
24 stars 5 forks source link

Add support for .zenodo.jsons #29

Open broeder-j opened 1 year ago

broeder-j commented 1 year ago

Many projects publish their code to zenodo and putting manual rich metadata into one .zenodo.json file in the repository. One could also harvest this one.

proycon commented 1 year ago

I like this idea, is there a specification for this .zenodo.json?

broeder-j commented 1 year ago

information: https://developers.zenodo.org/#add-metadata-to-your-github-repository-release

links to docs and schema https://developers.zenodo.org/#representation https://zenodo.org/schemas/deposits/records/legacyrecord.json

Since the schema link points to some legacy stuff, one should check what they are doing now and what the current one is. I did not find it for now.

As an idea, one could also if one finds a 'zenodo' DOI through a badge or within a README.md request the zenodo.json for the record from the zenodo.org API.

In the repository users define only keys they want to be overwritten, or added, which are not automatically extracted, but on the other hand all the other data utlized by zenodo comes from the github API. Therefore, it is available without doing a request to zenodo. Maybe the zenodo code to extract this metadata from a github repo is also available (probably in python) and could save some work in extracting metadata from the github API.

proycon commented 1 year ago

Thanks for the info, that looks like valuable information we should use.

As an idea, one could also if one finds a 'zenodo' DOI through a badge or within a README.md request the zenodo.json for the record from the zenodo.org API.

Yeah, querying the Zenodo API sounds like the best strategy here if the .zenodo.json only specifies overriding values (similar to how I use codemeta-harvest.json vs codemeta.json). But I do see a bit of a chicken-egg problem for people that want to include a codemeta.json in their repository; for the codemeta.json to be generated using zenodo's info, the package must have already been published to zenodo (but then it would be published without the up-to-date codemeta.json). The other-way-round also introduces problems, because if you want to include the Zenodo DOI in the codemeta, it must have been generated before the codemeta.