You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FAIR principles are all very well, but without the TOOLS for FAIR then its not possible to adopt. To make a "app eco system" of FAIR tools we need very small number of lightweight protocols and conventions, with real and adoptable, sustainable tooling.
This is not the time for monolithic systems.
Scruffy, lightweight, easy and ubiquitous ALWAYS beats out fancy, heavyweight, tricky and limited in my experience.
The text was updated successfully, but these errors were encountered:
We need FAIR on-Ramps to lift the burden on all data providers, including long tail
– Tools, governance, methods of working, costs
– Leveraging reality of practice (spreadsheets are ubiquitous and a great ramp)
– Leverage commercial and commodity Off the Shelf infrastructures (Bioschemas, Docker...)
– FAIR as a side-effect, removing friction
We should NOT build specialist bespoke infrastructures that are impossible to sustain. And we should not waste public money on such where few researchers or data providers really use it.
People are RAMPS too – FAIR curators. We had to do a great deal of curating to make data FAIR for the FAIRDOMHub.org.
How do you define now the difference between a tool and the (e-)infrastructure? I would have defined it rather from the (e-)infrastructure that includes a set of tools. However, there are still open questions as do we talk about a subset of an infrastructure or are we talking about (future) potential aggregations of infrastructures we currently are not even aware of?
FAIR principles are all very well, but without the TOOLS for FAIR then its not possible to adopt. To make a "app eco system" of FAIR tools we need very small number of lightweight protocols and conventions, with real and adoptable, sustainable tooling.
This is not the time for monolithic systems.
Scruffy, lightweight, easy and ubiquitous ALWAYS beats out fancy, heavyweight, tricky and limited in my experience.
The text was updated successfully, but these errors were encountered: