G: Reusability and discoverability

[ml-evs]

This thread is for discussing, finalizing and organizing a breakout with the theme in the title above.

Original text:

Making tools reusable and discoverable

• How can one make spectroscopy-related applets interoperable? Re-implementing from scratch can be cheaper than just patching together (commercially) available solutions.
• Wouldn’t it be amazing if we could build our custom ELN by just installing relevant apps/modules from an app store?
  • What do we need for this model, where experts from every domain contribute an app, to work
  • How can we create a rich ecosystem in this space? Is there a clear and simple path from, say, a Python library to a serverless linked data API? How much will “modern” DevOps practices accelerate this? (e.g., “free” hosting with continuous deployment, automated and verifiable release processes)
  • How can we make it work between ELN implementations/backends? Via web-services? Are there existing technical solutions (e.g., mitosis), and if not, could we collectively design one?
  • How do we split the analysis code from the visualization code and make both interoperable?
• Refresh/review the current data management landscape with interop. in mind, building on e.g., The Labiii comparison grid of ELNs

[kjappelbaum]

I think a good activity for the breakout / potential paper would be the last point you mentioned. For this it might be really interesting to have the ELN developers in this breakout room:

• what are criteria to measure interoperability? (has API (/w docs), uses some kind of documented schema, uses semantic techniques)
• what fraction of ELN is actually interoperable according to these criteria
• what would be a minimal viable implementation?
• would some developers be willing to collaborate on doing this? (cheminfo via me would be interested)

(btw, i think the grids from Harvard Med School and Cambridge Library are even better)

[kjappelbaum]

as preparation, we can already create a list of ELN, potentially already pre-fill and put it into this repo

[kjappelbaum]

For the "modular ELN" idea: Are there any conventions/best practice guides how to set up such a plugin system?
What happens to legacy code people are attached to?

[ml-evs]

Some possible breakout room starter questions: How do you currently index/publish/make available data from your initiatives? Is programmatic access possible? If you are not using linked data, how do you report your schemas?

[stefhk3]

Wouldn't metadata be an issue here? I know there are attempts for standardization, but I am not an expert. For NMR, this plays a role in NFDI4Chem, but it should in other areas as well. OAI-PMH and Bioschemas have been mentioned, but I don't know too much about it.

[ml-evs]

Do we think this room also aligns with the "potential solutions" room that we nixed? I just think this would lead most neatly into hacking on some software ideas

[kjappelbaum]

what do you envision? i think the start could really be just reviewing what is out there and we could prepare this by going through some of the ELN/LIMS and the developers that are around can mention what they do.

another aspect would be to come up with "dimensions" of interoperability (#12 (comment))

i think this could then align with the BYOC/BYOD section where one could try to use the techniques of others/showecase one's technique/implementation

i think to do some productive development, we'd need to have a clearer design/problem in mind

[kjappelbaum]

One thing for the reusability we might want to keep in mind is that we won't be able to convince all people to use JS/Ruby/Python/... - as there are good reasons to use one language over the others - this, of course, makes interoperability harder (cannot simply import a package, if one ignores things like WebAssembly).

The only language agonistic way we can then achieve the interoperability are APIs. They might even be simply exposed by webservices maintained by different domain experts.

However, it is not clear to me what to best do with frontend components. I feel that JS is the most interesting language here and it maybe makes most sense to develop a JS ecosystem (given that you can reuse them also in Plotly/Dash and you can always have a python backend and a JS frontend)