Cameron Neylon

Something that [has been bothering
m](http://blog.openwetware.org/scienceintheopen/2007/08/23/blogs-vs-wikis-and-third-party-timestamps/)e
for quite some time fell into place for me in the last few weeks. I had
always been slightly confused by my reaction to the fact that on
[UsefulChem](http://usefulchem.wikispaces.com) Jean-Claude actively
works to improve and polish the description of the experiments on the
wiki. Indeed this is one of the reasons he uses a wiki as the process of
making modifications to posts on blogs is generally less convenient and
in most cases there isn't a robust record of the different versions. I
have always felt uncomfortable about this because to me a lab book is
about the record of what happened -- including any mistakes in recording
you make along the way. There is some more nebulous object (probably
called a report) which aggregates and polishes the description of the
experiments together.

Now this is fine, but point is that the full history of a UsefulChem
page is immediately available from the history. So the full record is
very clearly there -- it is just not what is displayed. In our system we
tend to capture a warts and all view of what was recorded at the time
and only correct typos or append comments or observations to a post.
This tends not be very human readable in most cases -- to understand the
*point* of what is going on you have to step above this to a higher
level -- one which we are arguably not very good at describing at the
moment.

I had thought for a long time that this was a difference between our
respective fields. The synthetic chemistry of UsefulChem lends itself to
a slightly higher level description where the process of a chemical
reaction is described in a fairly well defined, community accepted,
style. Our biochemistry is more a set of multistep processes where each
of those steps is quite stereotyped. In fact for us it is difficult to
define where the 'experiment' begins and end. This is at least partly
true, but actually if you delve a little deeper and also have a look at
Jean-Claude's recent efforts to [use a controlled
vocabulary](http://usefulchem.blogspot.com/2008/01/modularizing-results-and-analysis-in.html)
to describe the synthetic procedures a different view arises. Each line
of one these 'machine readable' descriptions actually maps very well
onto each of our posts in the LaBLog. Something that maps on even better
is the log that appears near the bottom of each UsefulChem page. What we
are actually recording is rather similar. It is simply that Jean-Claude
is presenting it at a different level of abstraction.

And that I think is the key. It is true that synthetic chemistry lends
itself to a slightly different level of abstraction than biochemistry
and molecular biology, but the key difference actually comes in
motivation. Jean-Claude's motivation from the beginning has been to make
the research record fully available to other scientists; to *present*
that information to potential users. My focus has always been on
*recording* the process that occurs in the lab and particular to capture
the connections between objects and data files. Hence we have adopted a
fine grained approach that provides a good record, but does not
necessarily make it easy for someone to follow the process through. On
UsefulChem the ideal final product contains a clear description of how
to repeat the experiment. On the LaBLog this will require tracking
through several posts to pick up the thread.

This also plays into the [discussion I had some months
ago](http://blog.openwetware.org/scienceintheopen/2008/04/20/more-on-fuge-and-data-models-for-lab-notebooks/)
with [Frank Gibson](http://peanutbutter.wordpress.com) about the use of
data models. There is a lot to be said for using a data model to
*present* the description of an experiment. It provides all sorts of
added value to have an agreed model of what these descriptions look
like. However it is less clear to me that it provides a useful way of
*recording* or *capturing* the research process as it happen, at least
in a general case. Stream of consciousness recording of what has
happened, rather than stopping halfway through to figure out how what
you are doing fits into the data model, is what is required at the
recording stage. One of the reasons people feel uncomfortable with
electronic lab notebooks is that they feel they will lose the ability to
scribble such 'free form' notes -- the lack of any presuppositions about
what the page should loook like is one of the strengths of pen and
paper.

However, once the record, or records, have been made then it is
appropriate to pull these together and make sense of them -- to
*present* the description of an experiment in a structured and sensible
fashion. This can of course be linked back to the primary records and
specific data files but it provides a comprehensible and fine grained
descriptionof the rationale for and conduct of the experiment as well as
placing the results in context. This 'presentation layer' is something
that is missing from our LaBLog but could relatively easily be pulled
together by writing up the methodology section for a report. This would
be good for us and good for people coming into the system looking for
specific information.

Person Frank Gibson

Right click for SmartMenu shortcuts


Something that has been bothering me for quite some time fell into place for me in the last few weeks. I had always been slightly confused by my reaction to the fact that on UsefulChem Jean-Claude actively works to improve and polish the description of the experiments on the wiki.

The distinction between recording and presenting &#8211; and what it means for an online lab notebook

â€¦is knowing what you meanâ€¦

I posted last week about the spontaneous [CMLReact
hackfest](http://blog.openwetware.org/scienceintheopen/2008/08/31/linking-up-open-science-online/)
held around Peter Murray-Rustâ€™s dining room table the day after
[Science Blogging](http://network.nature.com/forum/sciblog2008) in
London. There were a number of interesting things that came out of the
exercise for me. The first was that it would be relatively easy to
design a moderately strict, but pretty standard, description format for
a synthetic chemistry lab notebook that could be automatically scraped
into CMLReact.

Automatic conversions from lab book to machine readable XML

[CMLReact](http://cml.sourceforge.net/schema/cmlreact.xsd) files have
(roughly) three sections. In the first, all the molecules that are
relevant to the description are described, or in the ideal semantic web
world pointed to at an external authority such as
[Chemspider](http://www.chemspider.com),
[PubChem](http://pubchem.ncbi.nlm.nih.gov/), or other source. In the
second section the relationships between input materials, solvents,
products, and samples are described. In general all of these will be
molecules which are referred to in the first session but this is not
absolutely required (and this will be important later). The final
section describes observables, procedures, yields, and other
descriptions of what happened or what was measured.

If we take a look at the [UsefulChem
experiment](http://usefulchem.wikispaces.com/Paper03) that we [converted
to
CMLReact](http://docs.google.com/View?docID=dq5m5bs_12hb8d2wcw&revision=_latest)
you can see that most of this information is available in one form or
another. The molecules are described via InChi/InChiKey at the bottom of
the page. This could be used as they are to populate the molecules
section. A little additional markup to distinguish between reactants,
solvents, reagents, and products would make it possible to start
populating the second section describing the relationships between these
molecules.

The third section is the most tricky, and this will always be an 80:20
game. The object is to abstract as much information as can be reasonably
garnered without putting in the vast amount of work required to get
close to 100% retrieval. At the end of the day, if someone wants the
real detail they can go back to the lab book. Peter has demonstrated
text scraping tools that do a pretty good job of extracting a lot of
this information. In combination with a bit of markup it is reasonable
to expect that some basic information (amounts of reagents, yield,
temperature of reaction, some descriptive terms) could reasonably be
extracted. Again, getting 80-90% of a subset of regularly used termsÂ 
would be very powerful.

But what are we describing?

There is a problem with grabbing this descriptive information from the
lab notebook however, and it is a problem that is very general and
something I believe we need to grapple with urgently. There is a
fundamental question as to what it is that this file is describing. Does
it describe the plan of the experiment? The record of carrying out a
specific example of this experiment? An â€˜averagedâ€™ description of a
set of equivalent experiments? A general description of the reaction? Or
a description of a model of what we expect or think is happening?

If you look closely at the [current version of the CMLReact
file](http://docs.google.com/View?docID=dq5m5bs_12hb8d2wcw&revision=_latest)
you will see that the yield is expressed as a percentage with a standard
deviation. This is actually describing the average of three independent
reactions but that is not actually made explicit anywhere in this file.
Is this important? Well I think it is because it has an effect on what
any outward links back to the lab book mean. There is a significant
difference between â€" â€˜this link points to an example of this kind of
reactionâ€™ (which might in fact be significantly different in the
details) and â€˜this link points to this exact experimentâ€™ or indeed
â€˜this link points to an index of relevant experimental resultsâ€™.
Those distinctions need to be encoded in the links, or perhaps more
likely made explicit in the abstracted file.

The CMLReact file is an abstraction of the experimental record. It is
therefore important to make it clear what the level of abtraction is and
what has been abstracted out of that description. This relates to the
distinction I have made before between the flexibility required to
*record* an experiment versus the ability to use a more structured
vocabulary to *describe* the experiment after it has happened. My
impression is that people who work in developing these controlled
vocabularies are focussed on description rather than recording and
donâ€™t often make the distinction between the two. There is also often
a lack of distinction between describing an experiment and describing a
*model* *of what happened* in that experiment.Â  This is important
because the model may need to be modified in the future whereas the
description of the experiment should be accurate.

Summary

My view remains that when *recording* an experiment the system used
should be as flexible as possible. Structure can be added to this
primary record *when convenient* to make the process of abstracting from
this primary record to a controlled vocabulary easier. The primary goal
for me, for the moment, remains making a human readable record
available. The process of converting the primary record into a
controlled vocabulary, such as CMLReact,
[FuGE](http://fuge.sourceforge.net/), or workflow system such as
[Taverna](http://taverna.sourceforge.net/), should be enabled via
*domain specific* automated or semi-automated tools that help the user
to structure their description *of the experiment* in a way that makes
it more directly useful to them but maintains the links with the primary
record. Where the same controlled vocabulary is used for more abstracted
descriptions of studies, experiments, or the models that purport to
describe them, this distinction must be made clear.

Semantics depends absolutely on being clear about what you are
describing. There is absolutely no point in having absolute clarity
about the description of an object if the nature of that object is
fuzzy. Get it right and we could have a very sophisticated description
of the scientific record. Get it wrong and that description could be at
best unclear and at worst downright misleading.


â€¦is knowing what you meanâ€¦  I posted last week about the spontaneous CMLReact hackfest held around Peter Murray-Rustâ€™s dining room table the day after Science Blogging in London.

The trouble with semantics&#8230;

[Frank Gibson](http://peanutbutter.wordpress.com) has [posted
again](http://peanutbutter.wordpress.com/2008/04/14/modeling-experiments-and-presenting-the-information/)
in our ongoing conversation about using FUGE as a data model for
laboratory notebooks. We have also been discussing things by email and I
think we are both agreed that we need to see what actually doing this
would look like. Frank is looking at putting some of my experiments into
a FUGE framework and we will see how that looks. I think that will be
the point where we can really make some progress. However here I wanted
to pick up on a couple of points he has made in his last post.

> From Frank: However, this is no denying that FuGE is a datamodel and
> does not come with a high degree of tool support or nice user
> interfaces, which Cameron is crying out for, as are most lab
> scientists from a usability point of view.

Certainly to implement FUGE we will need to provide a set of tools that
provide interfaces that work. To a certain extent it is certainly true
that Frank is talking about data models while I am talking about
interfaces. Nonetheless any data model will influence and indeed limit
the possibilities of user interfaces. My concern with any data model is
that it will limit user interface design in a way that makes it
inappropriate for use in a research laboratory.

> > Me: I got off to a very bad start here. I should have used the word
> > â€˜captureâ€™ here. This to me is about capturing the data streams
> > that come out of lab work.

> Frank: This seems to be a change of tact :) The original post was
> about a data model for lab notebooks .

This is part of the semantic problem (pardon the pun). To me, the
primary use of a lab book is to capture the processes that occur in the
lab, as far as is practicable. Data stream here should be understood to
mean streams from instruments, monitors, and the stream of descriptive
information that comes from the scientist.

My central problem with implementing a data model for an experiment is
that we do not necessarily know in advance what the boundaries of the
experiment are. But the key question will be how can FuGE work as a data
model in practice. This is why we need to actually try it out and see
how it fits. In a sense the question of â€˜what is the experimentâ€™ is
similar to the one we have developed at a practical level in deciding
what element of our record justifies its own post.

Frank divides the issues into four different stages or issues and is
correct in saying that we have to a large extent conflated these issues
together.

> Frank again: Summary
>
> So I will start with re-pointing what I believe to be the areas of
> conflation within these discussions
>
> 1\. the representation of experiments -- the data model
>
> 2\. the presentation or level of abstraction to the user (probably
> some what dependent on 3.)
>
> 3\. the implementation of the data model
>
> 4\. the publication of the data (Notification, RSS etc.)

I donâ€™t disagree with this, but I think there is another phase or
stage. A Stage 0 where the stuff that happens in the real world is
mapped onto the data model. This is the part that worries me the most.
It is also an important question to deal with in a general sense. Where
do we impose our data model? Before the experiment, when we are planning
it, or after it has been done and we have an understanding of what we
have one and what it mean. So this is where we need to see how it works
in practice and go from there.

Posting this from BioSysBio 2008 at Imperial College London.


Frank Gibson has posted again in our ongoing conversation about using FUGE as a data model for laboratory notebooks. We have also been discussing things by email and I think we are both agreed that we need to see what actually doing this would look like. Frank is looking at putting some of my experiments into a FUGE framework and we will see how that looks. I think that will be the point where we can really make some progress.

More on FuGE and data models for lab notebooks

[![Rendering of human
brain.](http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Brain.png/202px-Brain.png){decoding="async"}](http://commons.wikipedia.org/wiki/Image:Brain.png)And
other big words I learnt from mathematicians...

The observant amongst you will have realised that the title of [my
previous
post](http://blog.openwetware.org/scienceintheopen/2008/03/25/semantics-in-the-real-world-part-i-why-the-triple-needs-to-be-a-quint-or-a-sext-or/)
pushing a boat out into the area of semantics and
[RDF](http://en.wikipedia.org/wiki/Resource_Description_Framework "Resource Description Framework"){rel="wikipedia"}
implied there was more to come. Those of you who followed the reaction
\[[comments in original
post](http://blog.openwetware.org/scienceintheopen/2008/03/25/semantics-in-the-real-world-part-i-why-the-triple-needs-to-be-a-quint-or-a-sext-or/),
[1](http://blog.openwetware.org/scienceintheopen/2008/03/25/the-heavyweights-roll-indistinguishing-recording-the-experiment-from-reporting-it/),
[2](http://feeds.feedburner.com/~r/PetermrsBlog/~3/258183119/),
[3](http://peanutbutter.wordpress.com/2008/03/27/a-data-model-for-life-science-experiments-fuge/)\]
will also be aware that there are much smarter and more knowledgeable
people out there thinking about these problems. Nonetheless, in the
spirit of thinking aloud I want to explore these ideas a little further
because they underpin the way I think about the LaBLog and its
organization. As with the last post this comes with the health warning
that I don't really know what I'm talking about.

If the problem with RDF is that it requires a [controlled
vocabulary](http://en.wikipedia.org/wiki/Controlled_vocabulary "Controlled vocabulary"){rel="wikipedia"}
then this is also going to be the case with
[ontologies](http://en.wikipedia.org/wiki/Ontology_%28information_science%29 "Ontology (information science)"){rel="wikipedia"}.
These take years of very careful work to put together, requiring a lot
of effort and a lot of people's time to generate something which is
still likely to be very domain specific. Very often what you have to
hand is a lot of semi-structured data, or multiple sets of differently
structured data that you want to use together.

If I look at one of our LaBLogs we have quite a lot of fairly structured
[metadata](http://en.wikipedia.org/wiki/Metadata "Metadata"){rel="wikipedia"}.
But if we want to use all the tools out there that people have developed
we need to convert it to something useful like
[XML](http://en.wikipedia.org/wiki/XML "XML"){rel="wikipedia"} or RDF.
But to do this we need a vocabulary. Now we could attempt to adopt
[something that
exists](http://peanutbutter.wordpress.com/2008/03/27/a-data-model-for-life-science-experiments-fuge/)
but as I have posted I have concerns about this. My background is (at
least partially) in evolution and our experience of the development of
our data organisation system has certainly gone through periods of
[punctuated
equilibrium](http://en.wikipedia.org/wiki/Punctuated_equilibrium "Punctuated equilibrium"){rel="wikipedia"}
so I would like to see a more organic approach where we adapt our
controlled vocabulary over time to suit what we need to do with it (as
we figure out what that is).

A good vocabulary, used by lots of people will be useful. Tags,
hashtags, and all their variants work when people agree on them. But
they carry very little information with them. I am still using
[Zemanta](http://www.zemanta.com "Zemanta ltd."){rel="homepage"} to
write these posts, and it does seem to be getting better, as I guess
more people use it and the backend starts to build up a better
understanding of relationships between names and items. Controlled
vocabularies are great, but they require way too much effort in my view
to deploy effectively (maybe this will change as instrument
manufacturers in particular come on board).

So what if there were a half way house. The structure of a properly
defined ontology/controlled vocabulary is (I am assuming) well known and
machine checkable. Is it possible to mine all of our highly structured,
partially structured, and unstructured data and information to put
together best guess ontologies for particular uses? Can those then be
deployed in systems, like Zemanta, which offer you a guess as to what
you mean. Below my editing screen Zemanta has come up with a range of
possible links for this post. I've picked six of the seven it offered
me. The first time I used it (last week) I picked none.

I'm not suggesting text mining or natural language processing here per
se but making an attempt to pull out from structured and partially
structured information and more specifically links between documents on
the web. This could include grabbing identifies, microformats, RDF, XML,
and 'real' ontologies where they exist and attempting to build a best
guess model of how they all relate together.

This could be built as an ecosystem with competing, contingent,
ontologies all trying their best to represent specific domains. By using
these offerings and confirming or denying the relevance of specific
links or descriptions branches would be chopped or would sprout. By
checking what a user chose to do when they rejected the offered
description the service could find new options to refine itself. In a
sense this would look like the bastard offspring of a spell checker and
a greasemonkey script. Offering you possible descriptions of existing
pages, and checking to see whether you found it useful; offering you
links and ways of categorising your own offerings when you are editing
documents and checking to see whether you used them, or chose something
else.

The underlying system to run this would involve hideous storage and
processing issues. I am essentially proposing to remap the whole web as
RDF but with the predicates associated with every link, whether authored
or inferred, being held in its own database (something for the new
Google offering to chew on perhaps).

Another problem is that such ontologies would be necessarily
probablistic rather than absolute and would require that machine
reasoning approaches over them took account of this. Again, though this
more closely mirrors our own view of the world. Might it be a more
natural way of interacting with these systems.

We keep talking about data models as though they are models of our data.
But they're not, they're models of the way we *think* about our data.
That's a very different thing.

Image is from Wikipedia via Zemanta

[![](http://img.zemanta.com/pixie.png?x-id=c88c55c3-729e-4969-9b49-12babc0d866d){decoding="async"}](http://www.zemanta.com/ "Zemified by Zemanta")


And other big words I learnt from mathematicians…  The observant amongst you will have realised that the title of my previous post pushing a boat out into the area of semantics and RDF implied there was more to come. Those of you who followed the reaction [comments in original post, 1, 2, 3] will also be aware that there are much smarter and more knowledgeable people out there thinking about these problems.

Semantics in the real world? Part II &#8211; Probabilistic reasoning on contingent and dynamic vocabularies

[Frank Gibson](http://peanutbutter.wordpress.com/) has [continued the
discussion](http://peanutbutter.wordpress.com/2008/03/27/a-data-model-for-life-science-experiments-fuge/)
that [kicked off
here](http://blog.openwetware.org/scienceintheopen/2008/03/23/proposing-a-data-model-for-open-notebooks/)
and has continued here
\[[1](http://blog.openwetware.org/scienceintheopen/2008/03/25/semantics-in-the-real-world-part-i-why-the-triple-needs-to-be-a-quint-or-a-sext-or/),
[2](http://blog.openwetware.org/scienceintheopen/2008/03/25/the-heavyweights-roll-indistinguishing-recording-the-experiment-from-reporting-it/),
[3](http://blog.openwetware.org/scienceintheopen/2008/03/26/the-structured-experiment/),
[4](http://blog.openwetware.org/scienceintheopen/2008/03/26/responding-to-pm-r-on-the-structured-experiment/)\]
and in other places
\[[1](http://nsaunders.wordpress.com/2008/03/26/experiments-and-structured-data/),
[2](http://wwmm.ch.cam.ac.uk/blogs/murrayrust/?p=1017)\] along the way.
Frank's exposition on using FuGE as a data model is very clear in what
it says and does not say and some of his questions have revealed
sloppiness in the way I originally described what I was trying to do.
Here I will respond to his responses and try to clarify what it is that
I want, and what I want it to achieve. I still feel that we are trying
to describe and achieve different things, but that this discussion is a
great way of getting to the bottom of this and achieving some clarity in
our description and language.

> *CN: What Iâ€™m suggesting is a standard format to describe
> experiments;â€¦*
>
> A â€œstandardâ€? in the true sense of the word ([established by
> consensus and approved by a recognized
> body](http://www.bsi-global.com/en/Standards-and-Publications/About-standards/Glossary/))
> already exists to describe life-science experiments. It is a data
> model represented in UML called [FuGE](http://fuge.sourceforge.net/).

I got off to a very bad start here. I should have used the word
'capture' here. This to me is about capturing the data streams that come
out of lab work. FuGE is indeed a model to describe life science
experiments. I have concerns about whether it is extendable in a useful
way to other disciplines but it is well structured for what it was
designed to do; which is to describe life science experiments,
particularly those involving high throughput analysis. What I am less
sure about is it's practical application to capturing whatis going on in
the researcher's head in the laboratory during an experiment.

> \[CN\] â€¦..a default format for online notebooks. The object is to do
> a number of things. Firstly identify the page(s) as being an online
> laboratory notebook so that they can be aggregated or auto-processed
> as appropriate.
>
> \[FG\] I see this as two different and separate things, the data model
> which represents experiments, and the presentation of the model to the
> user, in this case described as an online notebook. Page numbers are
> an arbitrary visual aid, they are not integral to modelling
> experiments

Here we start to see how the different motivations are driving our
views. What I want here is a marker on a web document that says 'I am a
scientific experiment' (page was a more term to use -- I simply mean any
web document, generally accessed through discrete web pages). This will
allow aggregation and distribution of the notebook a la
[PostGenomic](http://postgenomic.com/) or [Chemical
Blogspace](http://cb.openmolecules.net/). To me this is *more* important
than the format of the underlying data. If I can find interesting data I
will probably put the work into extracting it in a form useful to me To
Frank I suspect the aggregation and indexing is a peripheral issue. If
the data isn't in a agreed format it isn't useful for him.

> \[CN\] Another issue is the tables. My original thinking was that if
> we had a data model for tables then most of our problems would go
> away.
>
> \[FG\] I am not sure I agree here. What is a table? I see it as a
> particular visual display mechanism that you have chosen to represent
> you results. The results can be modelled more accurately within the
> data model such as chemical-has_measurement, measurement has_numerical
> value and has_unit. I believe this statement is confusing the visual
> presentation of data with structuring the data.

Again this is a central user interface issue for us. *Capturing* an
experiment in the wet lab, whether noting it as it happens or planning
what you are going to in advance, is often most easily done with a
table. Tables are not well implemented in the wiki and blog frameworks
we are using for these systems. Therefore providing a table to *capture*
the experiment is critical if you actually want anyone to use your
system. Our users consistently identify this as the single biggest
barrier to them using our system.

Now the heavyweight approach to this is to say; 'That's why you need a
data model. Once you have that you can generate a nice web form to
capture the necessary data'. The problem with this comes when you do
something slightly different. As an example I had a template set up in
our system for capturing the setup of SDS-PAGE gels. This would go and
look for anything that tagged as 'protein' as potential samples and
present these in a drop down menu. This was fine until the day I wanted
to run a DNA-protein conjugate on the gel. Essentially I had broken my
own data model. This could be fixed, and I did fix it, by changing the
way my template looked for potential samples. But in the cut and thrust
of real lab work (as opposed to an academic pottering under sufferance
of his students) this isn't feasible. We can't extend the data model
every time we do something new -- we are always doing something new.

Bottom line is that tables are a familiar and easy way for users to
structure information visually. If you can't provide them people will
walk away. Now how we implement those in a general way I think is an
open question. I would argue against anything more complex than; 'This
is an input. This is an output.' But then again this is because we are
at the sample production end rather than the sample analysis end.

> \[FG\]....FuGE is designed so that it provides a generic structure
> which can then be described or further specialised by the
> user/application by extending the model itself or by using
> cvâ€™s/ontologies or free text. This provides the flexibility and in
> theory future proof.

But does this require that the user does the extension every time they
move on to something new. As a matter of interest, how much time and
effort went into agreeing the GelML? Is it practical to do this
extension over and over again? And who will fund it? My concern is that
achieving added value requires the controlled vocabulary. If we are
going to just end up using free text because a cv doesn't exist for the
experiment we are doing then why use a complex data structure?

> \[CN\] Overall an experiment has inputs and outputs. These may be data
> or material objects. Procedures take inputs and generate
> outputs.\[..\] Broadly speaking there seem to be three types of item;
> material objects , data, and procedures (possibly also comments). For
> each of these we require a provenance (author), and a date
>
> \[FG\] I would agree with you assessment of what classes are needed.
> This corresponds to what FuGE contains as illustrated in the digram
> below ([click \[to see\]
> image](http://fuge.sourceforge.net/dev/Images/FuGEOverview.png)
> \[...\])

Yep, we can agree on something! FuGE certainly has the categories of
items and a bunch more. I don't think this is terribly controversial
except that we will start having arguements over what is 'data' and what
is a 'material property' as we move into the more chemical sciences.

> \[FG\] In summary, the position I want to present is that FuGE is a
> data model to represent scientific experiments. Several domains are
> using it to represent their experiments from traditional
> biology/molecular biology to neurophysiology. I believe FuGE could
> form the underlying model for a â€œnotebookâ€? via an
> abstraction/presentation layer to the user. **In how should it be
> implemented, blog, wiki, database, latex, XML, RDF, OWL, I am not
> going to hypothesis** \[CN -- my emphasis\]. However, a database
> implementation of the FuGE schema is already in development called
> [SyMBA](http://symba.sourceforge.net/) which abstracts away from the
> user presenting simple web forms to fill out the XML which is then
> stored as a relation database.

I think this defines our different perspectives quite well. I am all
about hypothesising how this should be implemented and how this will
effect the user interface. Simple web based forms will not work for the
experimental work that is done in my lab, and I think Jean-Claude, and
possibly Peter Murray-Rust will agree with me. Unless you are doing very
structured experiments (of the type that FuGE was designed to describe)
then my experience is that a form based approach is inadequate to
capture what is actually happening and the decision making process that
is driving that. You *can* however apply form based approaches to
specific well defined protocols but *only* if such well defined
protocols exist for what you are doing.

Finally I want to return to the begining of Frank's post where he notes:

> I think a large part of this discussion confuses and conflates 3
> issues which I believe to be separate;
>
> 1.  the representation of experiments -- the data model
> 2.  the presentation or level of abstraction to the user (probably
>     some what dependent on 3.)
> 3.  the implementation of the data model

Yep. Couldn't agree more. And I don't think my use of language has been
helpful here. I am still groping for the right terminology to use. But
there is one thing that is missing here which is the mapping of the
*scientist's* data model onto all of these. If we don't consider the way
the user thinks about their experiments then we will run into trouble
very rapidly.

If I can crystallise my concerns about FuGE (which are not based, as yet
on a real attempt to implement it, hopefully we can work together to put
together a few examples of how it could be used to represent our
experiments and nail some of these concerns down properly) I think they
do fundamentally revolve around the user experience in the lab recording
the experiment as it happens.

1.  Are the data models there for what I am doing? If not who is going
    to develop them and then develop the UI implmentations?
2.  If we simply use a framework and the rest is free text is FuGE going
    to add more than a simpler model?
3.  Does the model extend effectively into other domains, particularly
    on the hinterlands between chemistry and biology?
4.  Does the data model effectively capture the process of an experiment
    as it happens? Particularly, how does it deal with capturing the
    basis of decisions to change (or abandon) a protocol midstream, to
    entirely re-purpose an experiment, or to reassess the identity of a
    specific sample or material? How is an exciting new observation
    incorporated?

None of which should be taken as a rejection. I am strongly in favour of
incorporating structured descriptions of experiments where they exist
and can be implemented in a way that is good for the user. I am also
definitely against re-inventing the wheel. Structured descriptions of
processes can be used effectively to make it easier for the researcher
to capture what is happening during an experiment as long as they are
accessible and implemented well. UML/XML/RDF/OWL systems have great
appeal because our 'lab book system' can decide to look these up and say
'Ah hah! Running a gel are you? Well we'll grab GelML and set up some
forms for you to fill in then.'

Perhaps the right question to be asking is, what is the minimal
implementation of FuGE, and is it actually very different to what I in
fact proposed to start with? Perhaps we should look for the similarities
first?


Frank Gibson has continued the discussion that kicked off here and has continued here [1, 2, 3, 4] and in other places [1, 2] along the way.

Rogue Scholar Beiträge

The distinction between recording and presenting – and what it means for an online lab notebook

The trouble with semantics…

More on FuGE and data models for lab notebooks

Semantics in the real world? Part II – Probabilistic reasoning on contingent and dynamic vocabularies

Data models for capturing and describing experiments – the discussion continues