search

research-software-ecosystem / content

A metadata commons to store research software metadata
Creative Commons Attribution 4.0 International
40 stars 29 forks source link

Information mapping, gap analysis & schema revision #9

Open joncison opened 5 years ago

joncison commented 5 years ago

Mapping of tool information from different projects (to be integrated) with gap analysis for anticipated information requirements, followed by revision of biotoolsSchema to support integration of new data where possible and desirable.

joncison commented 5 years ago

Hi @ypriverol, can we use this thread to start the conversation you mooted at the recent ETP meeting, re use-cases of the data? My interest is in the modelling of biotoolsSchema to ensure that can in future support whatever integrations / applications we want.

hansioan commented 4 years ago

Redirecting post of issue: https://github.com/bio-tools/biotoolsRegistry/issues/493 here

@piotrgithub1 @joncison @hmenager @matuskalas @bgruening

Hey all,

I am thinking about bio.tools data (model / schema) better supporting external projects and collaborators like Bioconda, Debian, Bioconductor and ELIXIR partner projects like OpenEBench, TeSS etc.

Technically we already have some support for this in our model by having Links of different types or Downloads with different types. While this is kinda ok, we could probably have more, in terms of annotations that are available. Currently a Link supports URL - Type - Note and Download supports URL-Type-Version-Note, but aside from Downloads of type CWL, Galaxy and Taverna workflows we don't have something custom. If a bio.tools entry has a link to a Biocontainers.pro in the bio.tools interface we just see a link which says "Container file", no name of the website/project, no logo, not a lot really.

It could be nice to have something a bit more custom with some additional properties coming from the other projects and all of this can be displayed nicely on the bio.tools tool cards, perhaps with logos to the other projects. This would also work well with the new ecosystem in which these projects can keep their annotations and from which we can take the properties we find relevant.

What do you think? Please tag other people who would want to participate in the discussion.

osallou commented 4 years ago

Adding myself to discussion @osallou

joncison commented 4 years ago

sorry for taking an age to get back to this @hansioan. In broad terms, I think we should aim to extend the model where sensible, but not aim for one unifying schema for everything necessarily (which would likely be clunky and monolithic). We can always have a modular schema architecture (extensions around a core).

So ... simple changes could be to pull out Software package and Container file from Download and covert to elements (same as for Links, Download and Documentation):

Better to do this systematically rather than piecemeal though, which means the mapping / gap analysis mention in the thread title.

cc @osallou