Databases and Systems

290
LabFlow Summary
LabFlow makes it easier to create a LIMS by providing facilities for orchestrating the
execution of components. Workers encapsulate the vagaries of invoking
components, capturing their outputs, and coping with failures. Steps handle database
access. Routers control the order in which components execute. States keep track of
the progress of Materials as they advance through the workflow. The LabFlow
engine acts as a scheduler to carry out the work specified by the above elements.
It would be useful to extend the system to handle workflows involving multiple
Materials. Suppose we expand our example to include expression monitoring, in
which cDNAs are arrayed on a chip and probed with different libraries. It is natural
to think of this as a two dimensional process whose materials are chips (which we
would like to think of as groups of cDNAs) and libraries, and whose result is a twodimensional
matrix indicating expression level as a function of cDNA and library. In
broad terms, the workflow for this process would include the following Steps: (1)
prepare chip for probing; (2) prepare library for probing; (3) probe; (4) analyze the
results. It seems intuitive to regard the chip as the Material for step (1), the library as
the Material for step (2), and the pair as the Materials for steps (3) and (4). This
complicates our previously simple view of Materials “flowing through” a workflow.
We may need to adopt two perspectives: a sample-tracking view, in which we regard
a workflow as describing how a Material travels from Step-to-Step through a process,
and a task-completion view, in which we regard a workflow as describing the process
needed to accomplish an arbitrary task. While more general, the latter is also more
complex, and we have yet to work out all its implications.
Another useful extension would be to handle workflows involving related
Materials. We earlier mentioned three important kinds of inter-Material relationships,
namely, derived-from, grouping, and part/whole. If LabBase and LabFlow were
extended to represent these relationships in a direct manner, it would allow us to
represent the example database and workflow more naturally. Instead of combining
clones and sequence-reads into a single kind of Material, each could exist
independently. And instead of coordinating multiple reads per clone in the sequenceassembly
workflow, we could handle this through an explicit clone-analysis
workflow. We see this as an important benefit, since the central theme of our work is
to simplify LIMS construction by eliminating arcane design tasks and reducing what
remains to its most natural form.
Conclusion
The LabBase and LabFlow systems described in this chapter are the latest in a series
of systems we have built to tackle the problems of data management and workflow
management for large scale biological research projects. We and our colleagues have
used the predecessor systems for several projects at the Whitehead/MIT Center for