D: What are the problems/barriers?

[ml-evs]

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

Link to current description

What is the actual problem?

• Is the problem the lack of standards, lack of tools, or lack of motivation/incentives?
• Precious time is spent in groups discussing how we can query all this Big Data that is sure to be published via RDF instead of figuring out a way of making it easy to publish that data on the Web by leveraging common practices in use today.
  • There are already a lot of standards for experimental data. However, they are not really used.
  • For metal-organics, for instance, there is no structure editor that even allows to draw and serialize multi-center compounds, and most struggle with valenceny rules

[kjappelbaum]

Perhaps unpopular opinion: The problem is not the lack of formats or standards but the lack of tooling. If the tooling (e.g., ELN) would take care of converting/annotating data "under the hood" then we would have no problem.

This requires:

1. ELN developers do not only store data as provided, but annotate data/convert it into some reusable/"machine actionable" form
2. Chemists use ELNs -> we need to provide added value
3. The interface must make it easy to enter data correctly (e.g., currently not possible with metalorganics)

[kjappelbaum]

Also, i like to think about point 2. as Collective action problem.

An interesting question in this context is then to ask what external forces can be useful:

• Something like the Bermuda principles?
• Do we need the editors to request something as condition for publication?

[sphuber]

I agree that the problem is twofold: if data entered by humans is valuable, we need a tool that encourages them to enter the data. But at the same time the date also needs to be addressable and actionable by machines. I don't think there is necessarily a conflict of interest here, just that tool developers sometimes lose sight of both important requirement and focus on one or the other. It should be possible to do both, at cost of more effort of course. I have seen a couple of ELNs already that focus on usability, but forget that to make it possible to have the data they contain extracted programmatically: there is nothing that stops this from being implemented however. We just need to create more awareness here I believe.

[kjappelbaum]

Here a potentially interesting thread about the lack of good (web-native) tooling for chemistry https://twitter.com/michael_nielsen/status/1481784677803257858

[sphuber]

For metal-organics, for instance, there is no structure editor that even allows to draw and serialize multi-center compounds, and most struggle with valenceny rules

On the one hand, yes, there are plenty of standards that could be useful but that simply don't find adoption. On the other hand, I also see clear shortcomings. A single format or serialization that allows communicating the structure of molecules with complex coordination and stereochemistry seems a problem that hasn't yet been solved. Yet this seems such a fundamental problem for chemistry.

[kjappelbaum]

I think that the metal-organics might also be a case study that highlights that I can be difficult to specify all eventualities a-priori. If some chemists just try to break the rules, we will always have a hard time representing what they do.

Regarding the bonds I had a couple of discussions that always boiled down to that chemists somehow always draw structures the same way, but it is still hard to encode this in some algorithm-this then led to the intuition that one might "simply" learn a program. However, this approach is I'll clearly not work in the out-of-training-domain cases.

Others suggested that chemists just draw a line between all atoms that are in strong interaction. Then you could in principle use any of the many graph libraries to model this.

[cpignedoli]

From the experience I have from my Lab the main problems/barriers are:
-we have some collection of tools/practices to comply (somehow) with ORD requirements, if we invest resources to switch to a different solution what do we gain?
-no solution is presently available to easily replace our tools/practices, a lot of thinking (design) and coding will be needed, where do we get the resources? how long will it take?
-what if after our investment something better (maybe a commercial solution) comes out or teh platform we selected "dies"?

[kjappelbaum]

For the point 1. you refer to you having already an ELN/LIMS and switching to a new one?

I think one common theme that emerges in our discussion is that any new solution should make switching easy via 1. interoperability functionality (at least some basic API) and 2. exporting functionality

For the point 2. I think this is really a common pattern with some softwares that all use in a given field and that is really hard to redevelop. @ml-evs had some ideas on how to incorporate such tools in the big picture.

[cpignedoli]

Correct Kevin, for point one in the specific case of our experimentalists we use an old ELN developed at PSI plus some rudimental databases plus some policy of organizing manually data to be ready to be released open. It is obvious teh advantage of a well designed solution (we are currently evaluating how to migrate to openBIS) but the comment I always receive is "it's a lot of effort and our strategy still works, do we really want to go in this new direction?"

[kjappelbaum]

What I also hear as a problem with ELNs compared to paper based lab notebooks (but it generalizes to many of the other techniques we're discussing) is immediacy.
It is much easier to simply jot something down on paper than it is to enter it in most ELNs (need to open the page, wait till it loads, then find the right field(s) ...)

[kjappelbaum]

Ulrich in chat

Please keep in mind that there are many end users who can just open their Word, PowerPoint, and a few special software pieces to process spectroscopic data from routine Instruments (NMR, MS, IR) and have never ever interacted with a command line interface or "typed" commands

[kjappelbaum]

But this is the wrong attitude of the programmer - these people have other focus and simply not the time to dig into programming and often zero Knowledge, they are like a baby saying a first word in terms of programming

[kjappelbaum]

Alex

The amount of data that is already or going to be produced is way beyond what people had handle even as a hoppy data scientist

[kjappelbaum]

It's not an issue of data improperly handled, these people have very good Knowledge and are continously trained to spot issues with data quality - but simply programming (languages, data structures) is not part of their training - they already have a 5-year Bachelor/Master that is full with other topics

[merkys]

My experience why the data producers prefer non-machine-readable formats is that machine-readable ones are just too strict. These need adapting/converting the data (possibly causing data loss or introduction of human errors) and they impose certain data model (which sometimes is just not flexible enough). Maybe semantic markup in ELNs could be a solution, but I am not sure many tools could support that. And, of course, it requires standardization and appropriate training.