

Show HN: The Autoprotocol Language Standard for Biology - frisco
http://www.autoprotocol.org

======
jnj16180340
So, 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.

~~~
frisco
> 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.

------
therzka
Hey all, I've been working on Autoprotocol for the last couple of months and
can answer any questions!

------
fsloth
What is the overall process when using autoprotocol? I presume there are
standardized robotic workstations with the capability to - 'do biology'. My
experience of microbiology is limited to high school biology experiments 20
years ago -sequencing DNA and culturing bacteria on a petri dish. What is it
exactly like to do biology in a modern research setting? (rough high-level
description/example appreciated :) )

~~~
therzka
At Transcriptic we perform experiments using what we call a workcell - a set
of devices like liquid handlers (automated pipettors), PCR machines, and plate
readers all linked together via a common interface and a robotic arm that
moves containers between devices. That interface understands Autoprotocol and
executes the instructions accordingly. Autoprotocol itself was designed to be
an agreed upon standard for different types of laboratory automation (not just
ours) to execute protocols.

An example of an experiment someone could run through our cloud laboratory
interface would be to monitor the growth rate of bacteria expressing different
genes. This would be done using a protocol that contains some pipetting steps
to dilute the bacteria and then alternates between incubating the plate at 37
degrees and reading OD600 of its wells using a plate reader at a specified
interval for a certain number of repetitions.

------
endeavour
This is a really neat idea. I wrote test-scripts for cell culture machines a
few years back. Great fun moving giant robotic arms around!

If you can indeed encode all the primitives needed to more formally describe
an experiment this would be great.

Are you worried the language will endlessly grow in complexity as you find
edge cases it doesn't support?

------
oodles-n-moles
I'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.

~~~
Terr_
> on-site

In the general area of...?

~~~
oodles-n-moles
The general area of San Francisco Bay.

------
desdiv
_Both 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.

[0]
[http://en.wikipedia.org/wiki/ISO_31-0#Expressions](http://en.wikipedia.org/wiki/ISO_31-0#Expressions)

------
nornagon
Another of the devs here along with @therzka, happy to answer questions :)

~~~
zevets
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.

~~~
therzka
_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 all three) and it can
be consumed by lots of different things. If you have a lab of your own, we'll
release our to-english converter soon! You can also post the protocol JSON to
Transcriptic to run it in our cloud lab environment, which produces a preview
of the instructions that looks like this:
[http://imgur.com/EOBfZfW](http://imgur.com/EOBfZfW)

~~~
Terr_
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.

------
kanzure
Hmm I have a microfluidics SVG library that I have been cooking, I think I
will write a converter.

------
dflock
What's the 3rd party hardware/software support for this like?

~~~
nornagon
Software-wise, there are a couple of unannounced things from our partners
coming down the line that work with Autoprotocol, and several of our customers
have been building on top of the autoprotocol-python[1] and autoprotocol-
core[2] libraries. Hardware-wise, Autoprotocol is a description language, it
could even be executed on a sufficiently meticulous "human" device. (We have a
project in the works that transforms Autoprotocol into human-readable
instructions suitable for inclusion in a publication.) Transcriptic is the
only fully automated system today that accepts Autoprotocol, but we're working
with other groups building low-cost hardware systems (in particular,
OpenTrons) who want to build on top of the Autoprotocol standard.

[1]: [https://github.com/autoprotocol/autoprotocol-
python](https://github.com/autoprotocol/autoprotocol-python) [2]:
[https://github.com/autoprotocol/autoprotocol-
core](https://github.com/autoprotocol/autoprotocol-core)

