self-explanatory title. Most used labware is standardized according to SLAS guidelines and quite universal. Still, I haven’t found any database where this information is provided for most common labware to look up when generating liquid handler protocols/methods.
Do you find this as useful as I do? Am I overthinking this?
Does a such database exist?
Is a such database providing all dimensions legal to distribute?
What kind of database should be used? Is Excel enough? Relational DB?
What should this database look like? E.g. “type”, “company”, “product number”, “container type”, “container diameter” (including +/- batch-to-batch variations), “material”, “autoclavable”, “vendors”, etc.
Where do we store a such database?
Thanks.
PS: Not to mention open-source labware for 3d-printing. This seems to be a new concept.
Edit 06.09.22: So thanks to @jakebeal we had our first meeting to discuss the direction of this open-source project. We collectively (up to 14 people) decided to primarily discuss everything on the Bits in Bio Slack in the “collab-labware-database” channel. Feel free to join:
Incredibly useful. Also serves a potential avenue for alternatives AND may have the unintended consequence of forcing consumable vendors to further conform.
Not to my knowledge, finding labware is a mess.
If we manually harvest that information, I don’t see the issue.
The real cool part would be to share tested and proven labware files for liquid handlers aka labware files that have been optimized (for example) with specifications/dimensions that are smart enough to pretty accurately detect liquid volumes.
Definitely. But I think before doing that we would have to brainstorm either here or on Slack/Discord about what it should look like. The complexity of the database depends on how variable your labware (specifications) will be. The more variable, the better, and so I think it will need quite some planning beforehand. I will have to work on this in my free time.
If we accurately model the internal volume of a well for a particular labware, that’s already a big benefit for the OT-2! We estimate within-well liquid height with surprising precision using just a bit of math.
I was also thinking about this. But then I ask myself: because to my knowledge not provided by the manufacturer, how do we characterize a well’s geometry? They are often not perfect spheres but rather a skewed variant of it. Or you have a sphere-like bottom part, some truncated cone with increasing diameter and a cylinder such as in PCR-plates.
Next to that we could just experimentally correlate liquid height (measured either using a ruler or using liquid level sensing) with volume added given a defined liquid type/concentration and standardize it this way. E.g. a liquid that has near to no meniscus.
there is no liquid detection. We can tell when the pipette tip interfaces with a liquid surface using the pipette cam, so there a chance we build a computer vision script to do this for us when/if it is necessary
SilA had a labware database that was publicly accessible for a while on their older website. I am unsure if it still exists or if you need to be a paying member to access it.
In the Bioprotocols / PAML effort, we realized this was a problem about a year ago and built a container ontology to capture such information. It’s not in a very polished state, but community members have been using it successfully for protocol automation projects. It also has an associated webserver app to support queries.
It’s on GitHub under the Apache license and welcomes addition community contributions.
Well this is timely. I was having discussions with some coworkers recently about the need to standardize and share labware definitions across our organization. I was thinking a single flat file could do what we needed for now.
In the short-term, I was planning to set up something to store our labware dimensions that could translate from a standardized dimension to the language used on the liquid handler. We have labware defined for many liquid handlers: VWorks (Agilent Bravo), Solution (HRB Prime), Venus (Hamilton Star), Echo (Beckman), Tempest (Formulatrix). We also need labware definitions for our high content imagers and sometimes our plate readers. Having a translator that lists the dimensions that each instrument will ask for in the same language would make defining labware on those instruments so much faster.
I think in the long-term it would be awesome if we could convince liquid handler and other device vendors to implement an import utility to query this DB and import labware definitions. I have wondered if this kind of integration would incentivize the labware vendors to load their labware dimensions so we would not need to source it from the community.
If it becomes an open-source project, I bet this community could figure out how to do the translation without the vendors for a lot of the instruments.
What you’re hinting at here is already doable on Tecan’s. I’ve written and tested scripts that will parse, modify or compare XML files. You then just need to validate the checksum and you’re ready to go.
