Closed proycon closed 1 year ago
I’ve added codemeta.json files to the wgd, wld, wbd and wald sections of RU-wnd, since those are the actual django project repositories.
I hope the harvester will be able to find them and make use of them.
What about Cesar? URL: https://github.com/ErwinKomen/RU-cesar That is ClariaH too.
I’ve added codemeta.json files to the wgd, wld, wbd and wald sections of RU-wnd, since those are the actual django project repositories.
I hope the harvester will be able to find them and make use of them
Thanks! (sorry for the delay, was out of action last week). That should work fine yes, I will split the RU-wnd entries in the tool source registry into four.
What about Cesar? URL: https://github.com/ErwinKomen/RU-cesar That is ClariaH too.
Right, that should definitely be in there as well then. I'll add an entry to the tool source registry for it, but there I don't think much can be extracted automatically so we'll also need a codemeta.json
or codemeta-harvest.json
.
If you have any other things which you feel should be in the CLARIAH tool registry, just feel free to do pull requests on the source registry as explained in the contributor guidelines. We're trying to be as complete as possible.
Hi Erwin!
As you might have heard, for CLARIAH we are automatically collecting software metadata for all tools in CLARIAH-PLUS, which includes the dialect dictionaries. This metadata is automatically and periodically harvested from the source code repositories (of which this repository is one), and services (the various deployments of the dialect dictionaries).
The results are published daily on https://tools.clariah.nl and this will in turn be queried by other platforms (Ineo, CLARIN VLO) to disseminate the tools in portals for end-users.
The harvesting is set-up in such a way that various existing metadata formats are supported, such as
pyproject.toml
orsetup.py
. For deployed webservices/webapps, standard metadata headers (<meta>
,<title>
, etc) are interpreted. The whole idea is to burden developers as little as possible, use standards they already use, and prevent any unnecessary duplication of metadata fields.In january a call went out to request all CLARIAH developers to take a look at this metadata and to improve upon it where needed (see https://github.com/CLARIAH/clariah-plus/issues/143). The dialect dictionaries are currently lacking various metadata (both this source repo as well as the deployed sites don't specify much metadata). Could you take a look at improving the metadata? Your project currently comes out like this
Please see the contributing guidelines and the CLARIAH Software Metadata Requirements for in-depth instructions on what metadata to provide and how this can be accomplished.
By the way, the webservices portal in Nijmegen will soon be replaced by the exact same system
(sneak preview: https://dev.webservices.cls.ru.nl/portal/services/) so any efforts in improving metadata will be beneficial on multiple fronts.