Develop and publish `hermes` and related vocabularies

[sdruskat]

• Related: Consolidate bundled vocabularies and loading #379

TODOs

• Decide if and how to separate vocabularies with different concerns ("content", "prov", etc., see current implementation details in Ha Ha Hack-A-Thon! 🐱‍💻 #288).
• Decide how to develop, version and publish vocabularies
  • E.g., if we extract all plugins, should they all define own vocabularies (see, e.g., Extend hermes context to depict all metadata of a pyproject.toml #405 for pyproject.toml-specific metadata)? Or, under which circumstances can they contribute to hermes' vocabs? (Example: terms defined by the git plugin: gitAuthor, etc.; PyPI classifiers may be mapped to different terms (see, Extend hermes context to depict all metadata of a pyproject.toml #405, e.g., Development Status can be mapped to developmentStatus, etc.)
  • Decide on IRI scheme that is ideally backed by a long-living URL (e.g., do we agree on https://schema.software-metadata.pub/<schema-name>/<schema-version>/<term>?) See also Unify terms to use in model-related code #392 for, e.g., use of "schema".

For publicizing the schema(s) and making it persistently accessible, I'm preparing a W3ID here: perma-id/w3id.org#5152.

[sdruskat]

Thinking about this again, unless we want to fix fundamental things in CodeMeta, there may not have to be a hermes schema at all. Rather, plugins should define their own schemas where necessary (e.g., the git plugin, the pyproject plugin, etc.).

As for the question where these should be published, I'm proposing to use https://w3id.org/hermes as mentioned above, e.g., https://w3id.org/hermes/pyproject/1.0/ which can resolve to, e.g., a website for HTML requests, and the .jsonld for application/json+ld requests. Additionally, we could offer plugin developers the use of the w3id namespace if they so wish.