Science in the Open

In a break from your regularly scheduled programme on Open Science we bring you news from deepest darkest Oxfordshire. I am based at ISIS, the UK’s neutron source, where my job is to bring in and support more biological science that uses neutrons. Neutron scattering, while it has made a number of crucial contributions to the biological sciences, has always been a bit player in comparison to x-ray crystallography and NMR. My job, is to try and build and strengthen this activity and to see the potential of neutron scattering in structural biology realised.

The Second Target Station project at ISIS is a huge part of this, and the reason I have a job here. TS-2 is designed specifically to provide a high flux of low energy neutrons, which are ideally suited to looking at large scale structures and biological molecules. The energy characteristics of the neutrons mean they have wavelengths ranging from angstroms up to around 2 nm, meaning they will be well suited to looking the overall shape and size of biomolecules and their complexes. The increase in flux, probably about 10-20 fold over the existing target station, means that experiments can be faster, or smaller, or more dilute. All things that make the bioscientists job easier. Over £140M has been spent on building the target and the instruments that will make use of these neutrons.

At 1308 yesterday the first neutrons were detected on the Inter beamline with a spectrum and flux pretty much dead on what was expected. In fact the first shot flipped out the detector it was so strong. This has been a massive project that despite news coverage to the contrary has been delivered essentially on time and on budget. Congratulations are due to all those involved in pulling this off. As the instruments themselves start to come fully online now we are going to get the chance to do many things that were either difficult or impossible before. In particular I am excited about what we will be able to do with the new small angle instrument SANS2d and INTER, the reflectometer, particularly in the area of membrane biology.

I’ve spent a long time talking about two things that our LaBLog enables, or rather that it should enable. One is that by changing the way we view the record we can look at our results and materials in a new way. The second is that we want to enable a machine to read the lab book. Andrew Milsted, the main developer of the LaBLog and a PhD student in Jeremy Frey’s group, has just enabled a significant step in that direction. He’s managed to dump my lab book as rdf which enables us to look at it in an rdf viewer such as Welkin, developed by the Simile group at MIT.

At the moment this just shows each post as a node and the links between posts as edges. But there a number of things that are immediately obvious. The first is that I start a lot of things and don’t necessarily manage to get very far with them and that I do a number of (currently) unrelated things (isolated subgraphs aren’t connected). Also that there are some materials that get widely re-used and some that don’t. There are also clearly things that I haven’t finished entering properly (isolated nodes). Finally, that we need a more sophisticated tool for playing with the view because building a human readable version of the graph will require some manipulation, grabbing subgraphs and moving them around. Welkin is great but after 30 minutes playing I have a bunch of feature requests. But this is what I’ve done so far. I am sure there are many things that can be done with this kind of view – but for the moment what is important is that it is an entirely new kind of way of looking at the record.

For those interested in following progress on another story, the data and analysis built on the model that Pawel Szczesny built for us is in the bottom right hand corner of the graph. You can see thatat the moment it is isolated from the rest of the graph because we haven’t yet compared these models with our experimental results (actually the relevant experiments aren’t on this graph because it was dumped before we did them). That’s something we should be doing in the next few days. If the data matches the model (current indications are that it does, but data quality is an issue) then we will have something very interesting to say about the structural changes on ligand binding in ligand gated ion channels.

Rule number one: Never give your students your mobile number. They have a habit of ringing it.

Our laboratory is about a ten minute walk from my office. Some of the other staff have offices five minutes away in the other direction and soon we will have another lab which is another ten minute walk away in a third direction. I am also offsite a lot of the time. Somehow we need to keep in contact between the labs and between the people. This is a question of passing queries around but also of managing the way these queries interrupt what I and others are doing.

Having broken rule #1 I am now trying to manage my attention when my phone keeps going off with updates, questions, and details. Much of it at inconvenient times and much of it things that other people could answer. So what is the best way to spread the load and manage the inbox?

What I am going to propose is to setup a lab account on Twitter. If I we get everyone to follow this account and set updates to be sent via SMS to everyone’s phones we have a nice simple notification system. We just set up a Twitter client on each computer in the lab, logged into that account, agree a partly standardised format for Tweets (primarily including person’s name) and go from there. This will enable people to ask questions (and anyone to answer them), provide important updates or notices (equipment broken, or working again), and to keep people updated with what is happening. It also means that we will have a log of everyone’s queries, answers, and notices that we can go back to and archive.

So a fair question at this point would be why don’t we do this through the LaBLog? Surely it would be better to keep all these queries in one place? Well one answer is that we are still struggling to deploy the LaBLog at RAL, but that’s a story for a separate post. But there is a fundamental difference in the way we interact with Twitter/SMS and notifications through the LaBLog via RSS. Notification of new material on the LaBLog via RSS is slow, but more importantly it is fundamentally a ‘pull’ interaction. I choose when to check it. Twitter and specifically the SMS notification is a ‘push’ interaction which will be better when you need people to notice, such as when you’re asking an urgent question, or need to post an urgent notice (e.g. don’t use the autoclave!). However, both allow me to see the content before deciding whether to answer, a crucial difference with a mobile phone call, and they give me options over what medium to respond with. They return the control over my time back to me rather than my phone.

The point is that these different streams have different information content, different levels of urgency, and different currency (how long they are important for). We need different types of action and different functionality for both. Twitter provides forwarding to our mobile devices, regardless (almost) of where in the world we are currently located, providing a mechanism for direct delivery. One of the fundamental problems with all streaming protocols and applications is that they have no internal notion of priority, urgency, or currency. We are rapidly approaching the point where to simple skim all of our incoming streams (currently often in many different places) is not an option. Aggregating things into one place where we can triage them will help but we need some mechanism for encoding urgency, importance, and currency. The easiest way for us to achieve this at the moment is to use multiple services.

One approach to this problem would be a single portal/application that handled all these streams and understood how to deal with them. My guess is that Workstreamr is aiming to fit into this niche as an enterprise solution to handling all workstreams from the level of corporate governance and strategic project management through to the office watercooler conversation. There is a challenging problem in implementing this. If all content is coming into one portal, and can be sent (from any appropriate device) through the same portal, how can the system know what to do with it? Does it pop up as an urgent message demanding the bosses attention or does it just go into a file that can be searched at a later date? This requires that the system either infer or have users provide an understanding of what should be done with a specific message. Each message therefore requires a rich semantic content indicating its importance, possibly its delivery mechanism, and whether this differs for different recipients. The alternative approach is to do exactly what I plan to do – use multiple services so that the semantic information about what should be done with each post is encoded from its context. It’s a bit crude but the level of urgency or importance is encoded in the choice of messenging service.

This may seem like rather a lot of weight to give to the choice between tweeting and putting up a blog post but this is part of a much larger emerging theme. When I wrote about data repositories I mentioned the implicit semantics that comes from using repositories such as slideshare and Flickr (or the PDB) that specialise in a specific kind of content. We talk a lot about semantic publishing and complain that people ‘don’t want to put into the metadata’ but if we recorded data at source, when it is produced, then a lot of the metadata would be built in. This is fundamentally the publish@source concept that I was introduced to by the group of Jeremy Frey at Southampton University. If someone logs into an instrument, we know who generated the data file and when, and we know what that datafile is about and looks like. The datafile itself will contain date and instrument settings. If the sample list refers back to URIs in a notebook then we have all the information on the samples and their preparation. If we know when and where the datafile was recorded and we are monitoring room conditions then we have all of that metadata built in as well.

The missing piece is the tools that bring all this together and a more sophisticated understanding of how we can bring all these streams together and process them. But at the core, if we capture context, capture user focus, and capture the connections to previous work then most of the hard work will be done. This will only become more true as we start to persuade instrument manufacturers to output data in standard formats. If we try and put the semantics back in after the fact, after we’ve lost those connections, then we are just creating more work for ourselves. If the suite of tools can be put together to capture and collate it at source then we can make our lives easier – and that in turn might actually persuade people to adopt these tools.

The key question of course…which Twitter client should I use? :)