Implement tool store component for tool discovery

[proycon]

The component is defined in https://github.com/CLARIAH/clariah-plus/blob/main/shared-development-roadmap/epics/fair-tool-discovery.md as follows:

• Function: Stores all harvested/aggregated tool metadata
• Function: API for updating (invoked by harvester)
• Function: API for querying (invoked by end-user, portals)

Further details all remain to be worked out still, reuse of existing solutions and coordination with the FAIR Datasets epic is recommended. I'd advocate for something fairly minimal and simple.

[proycon]

@CLARIAH/fair-tool-discovery is there anybody in our team who is eager to pick up this implementation as a developer? @jblom perhaps, I remember you doing a good suggestion for the implementation during the tech day (stick out a finger, I grab the whole hand 😉 ) ? Most of the implementation details are still undecided so there's plenty of freedom here still. The main thing I'd like to guard against is unnecessary complexity, a fairly minimal and simple implementation should suffice for this.

[jblom]

@proycon it sounds like fun to cooperate on this. Also planning to open up all B&G DANE repositories (private->public), so they can be code meta'd, while I am doing that I should be in the right space to work on this as well. Will check our planning here, but let's say this is a yes for now :-)

[proycon]

Great! Very good!

[proycon]

As I'm making progress on the harvester, ideas about the next step, the tool store implementation, are forming in my head as well:

• A core component of the harvester is my codemetapy which deals with converting other metadata to codemeta and merging multiple codemeta representations into one. I'm rewriting that to use rdflib (https://github.com/proycon/codemetapy/issues/12)
• The harvester will output a single codemeta.json file (JSON-LD) per tool.
• For the tool store, I imagine a two-fold solution:
  1. all these JSON-LD output files can simply be statically served as-is from some webserver.
  2. a small service can be built around codemetapy, which simply loads all the codemeta descriptions in memory (should be feasible considering we're not scaling up to huge amounts of tools), and offers a SPARQL endpoint for querying. Codemetapy itself will act as the triple store (in memory, using rdflib) and provide the necessary query functionality so all that needs to be written here is a tiny wrapper to make a webservice out of it.

[proycon]

I had a first implementation of the tool store using simple static files generated by the harvester pipeline, but now I'm progressing towards a tool store that is a bit more dynamic and which provides either JSON-LD, Turtle or actual HTML visualization (CLARIAH/clariah-plus#99) on-demand. The new codemeta-server provides the server with API (including SPARQL endpoint) and builds (like the harvester) upon codemetapy which does most of the actual work.

[proycon]

Closing this issue has it can be considered done now (even though further tweaks to the tool store may occur)