Cameron Neylon

AtÂ [Science Online 09](http://scienceonline09.com/index.php/wiki/)Â and
at the Smi Electronic Laboratory Notebook meeting in London later in
January I talked about how laboratory notebooks might evolve. At Science
Online 09Â [the
session](http://www.scienceonline09.com/index.php/wiki/Open_Notebook_Science/)Â was
aboutÂ [Open Notebook
Science](http://en.wikipedia.org/wiki/Open_notebook_science)Â and here I
wanted to take the idea of what a â€œweb nativeâ€? lab record could look
like and show that if you go down this road you will get the most out if
you are open. At the ELN meeting which was aimed mainly at traditional
database backed ELN systems for industry I wanted to show the potential
of a web native way of looking at the laboratory record, and in passing
to show that these approaches work best when they are open, before
beating a retreat back to the position of â€œbut if you're really
paranoid you can implement all of this behind your firewallâ€? so as not
to scare them off too much.Â The talks are quite similar in outline and
content and I wanted to work through some of the ideas here.The central
premise is one that is similar to that of many web-service start ups:
â€œThe traditional paper notebook is to the fully integrated web based
lab record as a card index is to Googleâ€?. Or to put it another way, if
you think in a â€œweb-nativeâ€? way then you can look to leverage the
power of interlinked networks, tagging, social network effects, and
other things that don't exist on a piece of paper, or indeed in most
databases. This means stripping back the lab record to basics and
re-imagining it as thought it were built around web based functionality.

So what is a lab notebook? At core it is a journal of events, a record
of what has happened. Very similar to
aÂ [Blog](http://en.wikipedia.org/wiki/Blog)Â in many ways. An episodic
record containing dates, times, bits and pieces of often disparate
material, cut and pasted into a paper notebook. It is interesting that
in fact most people who use online notebooks based on existing services
useÂ [Wikis](http://en.wikipedia.org/wiki/Wiki)Â rather than blogs. This
is for a number of reasons; better user interfaces, sometimes better
services and functionality, proper versioning, or just personal
preference. But there is one thing
thatÂ [Wikis](http://en.wikipedia.org/wiki/Wiki)Â tend to do very badly
that I feel is crucial to thinking about the lab record in a web native
way; they generate at best very ropeyÂ [RSS
feeds](http://en.wikipedia.org/wiki/RSS). Wikis are well suited to
report writing and formalising and sharing procedures but they don't
make very good diaries. At the end of the day it ought to possible to do
clever things with a single back end database being presented as both
blog and wiki but I've yet to see anything really impressive in this
space so for the moment I am going to stick with the idea of blog as lab
notebook because I want to focus on feeds.

So we have the idea of a blog as the record â€" a minute to minute and
day to day record. We will assume we have a wonderful backend and API
and a wide range of clients that suit different approaches to writing
things down and different situations where this is being done. Witness
the plethora of clie[nts for
Twittering](http://www.readwriteweb.com/archives/top_twitter_clients_definitive_list.php)Â in
every circumstance and mode of interaction for instance. We'll assume
tagging functionality as well as key value pairs that are exposed as
microformats
andÂ [RDF](http://en.wikipedia.org/wiki/Resource_Description_Framework)Â as
appropriate. Widgets for ontology look up and autocompleton if it is
desired and the ability to automatically generate input forms from any
formal description of what an experiment should look like. But above
all, this will be exposed in a rich machine readable format in an
RSS/Atom feed.What we don't need is the ability to upload data. Why not?
Because we're thinking web native. On a blog you don't generally upload
images and video directly, you host them on an appropriate service and
embed them on the blog page. All of the issues are handled for you and a
nice viewer is put in place. The hosting service is optimised for
handling the kind of content you need;Â [Flickr](http://flickr.com)Â for
photos,Â [YouTube](http://youtube.com)Â ([Viddler](http://viddler.com),Â [Bioscreencast](http://bioscreencast.com))
for video,Â [Slideshare](http://slideshare.net)Â for presentations etc.
In a properly built ecosystem there would be a data hosting service,
ideally one optimised for your type of data, that would provide cut and
paste embed codes providing the appropiate visualisations. The lab
notebook only needs to point at the data; doesn't need to know anything
much about that data beyond the fact that it is related to the stuff
going on around it and that it comes with some html code to embed a
visualisation of some sort.

That pointing is the next thing we need to think about. In the way I use
the Chemtools LaBLog I use aÂ [one post, one item
system](http://blog.openwetware.org/scienceintheopen/2007/08/17/the-southampton-e-lab-blog-notebook-part-2-eln-strategy/).
This means that every object gets its own post. Each sample, each bottle
of material, should have its own post and its own identity. This creates
a network of posts thatÂ [I have written about
before](http://blog.openwetware.org/scienceintheopen/2008/07/31/a-new-way-of-looking-at-science/).
What it also means is that it is possible to apply page rank style
algorithms and link analysis more generally in looking at large
quantities of posts. Most importantly it encodes the relationship
between objects, samples, procedures, data, and analysis in the way the
web is tooled up to understand: the relationships are encoded in links.
This is a lightweight way of starting to build up a web of data â€" it
doesn't matter so much to start with whether this is in hardcore RDF as
long as there is enough contextual data to make it useful. Some tagging
or key-value pairs would be a good start. Most importantly it means that
it doesn't matter at all where our data files are as long as we can
point at them with sufficient precision.

But if we're moving the datafiles off the main record then what about
the information about samples? Wouldn't it be better to use the existing
Laboratory Information Management System, or sample management system or
database? Well again, as long as you can point at each sample
independently with the precision you need then it doesn't matter. You
can use aÂ [GoogleSpreadsheet](http://docs.google.com)Â if you want to
â€" you can give URL for each cell, there is a powerful API that would
let you build services to make putting the links in easy. We use the
LaBLog to keep information on our samples because we have such a wide
variety of different materials put to different uses, that the
flexibility of using that system rather than a database with a defined
schema is important for our way of working. But for other people this
may not be the case. It might even be better to use multiple different
systems, a database for oligonucleotides, a spreadsheet for
environmental samples, and a full blown LIMS for barcoding and following
the samples through preparation for sequencing. As long; as it can be
pointed at, it can be used. Similar to the data case, it is best to use
the system that is best suited to the specific samples. These systems
are better developed than they are for data â€" but many of the existing
systems don't allow a good way of pointing at specific samples from an
external document â€" and very few make it possible to do this via a
simple http compliant URL.

So we've passed off the data, we've passed off the sample management.
What we're left with is the procedures which after all is the core of
the record, right? Well no. Procedures are also just documents. Maybe
they are text documents, but perhaps they are better expressed as
spreadsheets or workflows (or rather the record of running a workflow).
Again these may well be better handled by external services, be they
word processors, spreadsheets, or specialist services. They just need to
be somewhere where we can point at them.

What we are left with is the links themselves, arranged along a
timeline. The laboratory record is reduced to a feed which describes the
relationships between samples, procedures, and data. This could be a
simple feed containing links or a sophisticated and rich XML feed which
points out in turn to one or more formal vocabularies to describe the
semantic relationship between items. It can all be wired together, some
parts less tightly coupled than others, but in principle it can at least
be connected. And that takes us one significant step towards wiring up
the data web that many of us dream of

The beauty of this approach is that it doesn't require users to shift
from the applications and services that they are already using, like,
and understand. What it does require is intelligent and *specific*
repositories for the objects they generate that know enough about the
object type to provide useful information and context. What it also
requires is good plugins, applications, and services to help people
generate the lab record feed. It also requires a minimal and arbitrarily
extensible way of describing the relationships. This could be as simple
html links with tagging of the objects (once you know an object is a
sample and it is linked to a procedure you know a lot about what is
going on) but there is a logic in having a minimal vocabulary that
describes relationships (what you don't know explicitly in the tagging
version is whether the sample is an input or an output). But it can also
be fully semantic if that is what people want. And while the loosely
tagged material won't be easily and tightly coupled to the fully
semantic material the connections will at least be there. A combination
of both is not perfect, but it's a step on the way towards the global
data graph.


AtÂ Science Online 09Â and at the Smi Electronic Laboratory Notebook meeting in London later in January I talked about how laboratory notebooks might evolve. At Science Online 09Â the sessionÂ was aboutÂ Open Notebook ScienceÂ and here I wanted to take the idea of what a â€œweb nativeâ€ lab record could look like and show that if you go down this road you will get the most out if you are open.

Rogue Scholar Beiträge

The integrated lab record – or the web native lab notebook