Hmm I have a microfluidics SVG library that I have been cooking, I think I will write a converter.
Show HN: The Autoprotocol Language Standard for Biology
11–18 of 18 posts
Re: Show HN: The Autoprotocol Language Standard for Biology
#12Both the volume and duration are measures, which are strings of the format "value:unit".
FYI, ISO 31-0 [0] already defines a single space as the separator between the value and the unit. Granted, most people (and even some scientists) don't know about this rule.
Re: Show HN: The Autoprotocol Language Standard for Biology
#13So, this is cool and it's nice to have an open standard with got traction from an active company.
When setting up lab automation, instrument communication is the biggest headache. There's lots of variability in how instruments communicate (serial, gpib, analog voltage, ftp/email from a contractor,...) and in how easily accessible their protocols are (published by manufacturer, closed, too old to know). Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?
What are previous similar works like? I imagine stuff like this was made, way long ago, for doing combichem and hts... did it all remain in-house?
Support for extra parameters, like constant current vs constant voltage for gels, or that kind of thing? Or will this be in the name, like "op": "gel_separate_constant_I"
Support for timing, e.g. thaw out reagentB in time to mix it with reagentA which is being centrifuged, etc?
Reagents-- Any standardization for names/concentrations, or integration with inventory management?
Any planned integration with lab notebook/management software?
Any plans for 'preventing catastrophe' or 'forbidden operations' like centrifuging asymmetrically, or mixing stuff that precipitates+clogs (vs. intentional precipitation of, e.g., dna)? Not that we should need this, but increasing abstraction makes it easier to break stuff.
Looking forward to using this and contributing, etc.
Re: Show HN: The Autoprotocol Language Standard for Biology
#14I'm a molecular engineer working on a well-funded, stealth biotech project. We're building the world's first biological server farm. It's going to be a massive, fully automated research facility that manipulates, moves, mixes, and analyzes millions of batches of cells and molecules everyday.
It'll have the effective throughput capacity of taking everyone on earth, giving them a pipette, and having them do molecular biology by hand. But it'll be accessible from the comfort of a laptop. Biology will become a programming discipline.
We have an IMMEDIATE need for talented Python coders for short-term, on-site contract work. If the mission inspires you and you'd like to hear more, please email Kent Kemmish biokemmishtree at gmail.
Re: Show HN: The Autoprotocol Language Standard for Biology
#15Earlier quoted context omitted.
This is neat, but you guys have failed on the basic human motivation. A python file isn't something I can take into the lab with me to reproduce an experiment. Does this spit out a useful human readable set of instruction? Is there a sample output spec, compared with the norm of human readable input? As is, this seems like a solution for computers, not folks in the lab.
Does this spit out a useful human readable set of instruction? At its core, Autoprotocol is just a way to agree on how to capture all of the information about an experimental method, which in itself turns out to be deceptively complex (though looks a little obvious afterwards when you see it). That description is just JSON: it can be generated by scripts, UIs, or written by hand (and we at Transcriptic + customers do…
If it's a subset of JSON... Is there a mechanism to add in comments for humans to read?
I know the main use-case may be inter-device, but someday you might want to embed a short hint or explanation along with a particularly arcane set of instructions or parameters.
Re: Show HN: The Autoprotocol Language Standard for Biology
#16I'm a molecular engineer working on a well-funded, stealth biotech project. We're building the world's first biological server farm. It's going to be a massive, fully automated research facility that manipulates, moves, mixes, and analyzes millions of batches of cells and molecules everyday. It'll have the effective throughput capacity of taking everyone on earth, giving them a pipette, and having them do molecular b…
> on-site
In the general area of...?
Re: Show HN: The Autoprotocol Language Standard for Biology
#17I'm a molecular engineer working on a well-funded, stealth biotech project. We're building the world's first biological server farm. It's going to be a massive, fully automated research facility that manipulates, moves, mixes, and analyzes millions of batches of cells and molecules everyday. It'll have the effective throughput capacity of taking everyone on earth, giving them a pipette, and having them do molecular b…
> on-site In the general area of...?
The general area of San Francisco Bay.
Re: Show HN: The Autoprotocol Language Standard for Biology
#18So, this is cool and it's nice to have an open standard with got traction from an active company. When setting up lab automation, instrument communication is the biggest headache. There's lots of variability in how instruments communicate (serial, gpib, analog voltage, ftp/email from a contractor,...) and in how easily accessible their protocols are (published by manufacturer, closed, too old to know). Moreover, real…
> Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?
This is obviously a big issue; it's what we spend most of our time on at Transcriptic. (That, and building new hardware when it makes sense.) Only a few devices are designed for being controlled by 3rd party software and even fewer are designed for real automation like motorized lids for sample loading. Internally we have a layer that handles all of the device communication, but we haven't open sourced that and it wouldn't make sense without the rest of our infrastructure anyway: not something easy to just pick up on part of.
This is kind of outside the scope of Autoprotocol. I think that in reality there will be three big uses of it right now:
- generating eg a PDF to take into the lab - using it for more semantic information about the methods being used in conjunction with analysis of data you get from running stuff in lab - running experiments on Transcriptic
In terms of automating communication and data capture in your own lab, I think Riffyn's doing the most interesting work here and it will be interesting to see what they come out with.