Consider the CodeMeta project standard

[wd15]

Maybe update the existing CODEMETA.yaml to have more elements of the CodeMeta project. I realize that this might be extremely onerous. codemeta.json seems like something that should be auto-generated to some degree, but possibly having a think if the current schema can more closely align. Maybe we could auto-generate the codemeta.json from the existing schema and github meta-data.

Example: https://github.com/datacite/maremma/blob/master/codemeta.json

[tkphd]

Agreed. It looks like CODEMETA.md is maybe an accidental collision with the CodeMeta project, as an obvious portmonteau. Still.

Generating codemeta.json is not too onerous, using this handy tool then perhaps fine-tuning. Perhaps a clever person could pre-fill the HTML form based on existing metadata? or hack the source?

[wd15]

Generating codemeta.json is not too onerous, using this handy tool then perhaps fine-tuning. Perhaps a clever person could pre-fill the HTML form based on existing metadata? or hack the source?

I hadn't noticed that. That does make it easier.

[GRG2]

There is more related information to this base repo
See https://code.nist.gov/about/, also documentation generated on ODI Confluence site here: http://mml.nist.gov:8090/display/OCP/OAR+Code+Portal

We export the standard datacite JSON file from this portal, as part of a coordination GSA effort with code.gov. That project is currently on hold. https://code.nist.gov/explore/code.json is compliant with standard schema

Contributions are welcome, this effort is ongoing work as part of the OAR project, led by ODI, and developed as open source.

[wd15]

So, the CODEMETA.yaml file is compatible with another schema standard that's related to NIST / code.gov / GSA etc. Maybe that should be renamed CODENIST.yaml or CODEGOV.yaml to not clash with codemeta.json if they need to be independent. That's assuming codemeta.json is a widely agreed on standard, which I'm not even sure about.

[GRG2]

My bad on the naming it was unintended conflict, the purpose is for meta tagging, hence the "META" in the name. I'm not sure how widely adopted codemeta.json is used. Can float these rename ideas, @faical-yannick-congo , also possibly REPOMETA.yaml?

[tkphd]

Perhaps just "METADATA.yaml", along the same lines as README and LICENSE?

[tkphd]

@wd15 there's some documentation of the Code Inventory metadata schemas and scraper on the GSA/code-gov repo I believe the code.json @GRG2 mentioned is compliant with the code.gov Metadata Schema 2.0. The individual repositories' CODEMETA.yaml files are read by a NIST-internal scraper, which may or may not be related to the scrapers mentioned in code_json_generators.md.

As a metadata file for a specific, internal purpose, the fact that CODEMETA.yaml is an ad hoc key-values container is fine, though not ideal. The fact that its name conflicts with a broader, FAIR-related effort to properly document and store metadata is more of a problem. If we have input on the NIST scraper source code (is it on GitLab or GitHub?), I believe there is value in clarifying the difference by deprecating "CODEMETA.yaml" in favor of something more specific and descriptive, like "NISTCODE.yaml" or, since it's GitHub-specific, .github/NISTCODE.yaml.

[wd15]

@tkphd: switching to NISTCODE.yaml makes sense. Is this useful for PFHub do you think?