So I have given three talks in ten days or so, one at the CanSAS meeting at NIST, one at Drexel University and one at MIT last night. Jean-Claude Bradley was kind enough to help me record the talk at Drexel as a screencast and you can see this in various formats here. He has also made some comments on the talk on the UsefulChem Blog and Scientific Blogging site.
The talks at Drexel and MIT were interesting. I was expecting the focus of questions to be more on the issues of being open, the risks and benefits, and problems. Actually the focus of questions was on the technicalities and in particular people wanting to get under the hood and play with the underlying data. Several of the questions I was asked could be translated as ‘do you have an API?’. The answer to this is at the moment no, but we know it is a direction we need to go in.
We have two crucial things we need to address at the moment: the first is the issue of automating some of the posting. We believe this needs to be achieved through an application or script that sits outside the blog itself and that it can be linked to the process of actually labelling the stuff we make. The second issue is that of an API or web service that allows people to get at the underlying data in an automated fashion. This will be useful for us as we move towards doing analysis of our data as well. Jean-Claude said he was also looking at how to automate processes so clearly this is the next big step forward.
Another question raised at MIT was how you could retro-fit our approach into an existing blog or wiki engine. The key issues here are templates (which is next on my list to describe here in detail) which would probably require some sort of plugin. The other issue is the metadata. Our blog engine goes one step beyond tagging by providing keys with values. Presumably this could be coded into a conventional engine using RDF or microformats – perhaps we should be doing this our Blog in any case?
Incidentally a point I made in both talks, partly in response to the question ‘does anyone really look at it’, is that in many cases it is your own access you are enabling. Making it open means you can always get at your own data, which is a surprisingly helpful thing.
The CanSAS meeting was also interesting. This is traditionally a meeting where Small Angle Scattering instrument scientists, the people who maintain and support these instruments at large scale neutron and X-ray facilities, fail to agree on a standard data format. I wanted to make two points, one was the general point that making data available was a good thing, and secondly that making the instrument data available without a detailed description of the sample was pretty useless. However against all precedent they not only agreed a data format but it is also a flexible XML format allowing different tags for different ‘dialects’. So I can insert a tag into the data file that will point to our lab book, which is what I wanted.
Today I head off to talk to the OpenWetWare developers and the Simile group so that will be very interesting. More details as I have time to post.
It was really enjoyable to finally meet you in Philly!
Yes, we’ll continue the conversation about automation in the blogosphere in the coming months…
It was really enjoyable to finally meet you in Philly!
Yes, we’ll continue the conversation about automation in the blogosphere in the coming months…
This is great stuff, Cameron. Something that keeps occurring to me whenever I read your discussions is the issue of physical footprint: one doesn’t want to enter notes into a paper notebook and then RE-enter them into the Open notebook, which is necessarily online. I don’t know how chemists work, but biologists mostly carry their notebooks around — I use a pad of paper with holes punched down one side, so that as a sheet is filled I can tear it off and store it in a binder. So for me to do ONS would mean sitting down at the end of the day and transcribing notes from paper to pixels. Not only does that take away some of the immediacy that is so important in ONS, but it represents a barrier to adoption that I think will keep ONS out of the mainstream until it is lowered — even more of a barrier, in the end, than fear of scooping etc.
What I think I want is something like a Palm Pilot or Blackberry with an interface that allows me to take notes as quickly and easily as scribbling on paper. The actual instrument could be larger — more like a Vaio or small laptop in size — but I think it would still need the tablet function, and handwriting recognition, and a way to interface with a variety of software so that I could load raw data directly into my notes, and probably a million things I won’t think of until I have a prototype to play with.
Is your group thinking of testing hardware as well as software? For instance, you mention the need to automate some posting — this could be at least partly solved if the scientist could upload to the web from a hand-held device that he or she carries around and takes notes with all day.
This is great stuff, Cameron. Something that keeps occurring to me whenever I read your discussions is the issue of physical footprint: one doesn’t want to enter notes into a paper notebook and then RE-enter them into the Open notebook, which is necessarily online. I don’t know how chemists work, but biologists mostly carry their notebooks around — I use a pad of paper with holes punched down one side, so that as a sheet is filled I can tear it off and store it in a binder. So for me to do ONS would mean sitting down at the end of the day and transcribing notes from paper to pixels. Not only does that take away some of the immediacy that is so important in ONS, but it represents a barrier to adoption that I think will keep ONS out of the mainstream until it is lowered — even more of a barrier, in the end, than fear of scooping etc.
What I think I want is something like a Palm Pilot or Blackberry with an interface that allows me to take notes as quickly and easily as scribbling on paper. The actual instrument could be larger — more like a Vaio or small laptop in size — but I think it would still need the tablet function, and handwriting recognition, and a way to interface with a variety of software so that I could load raw data directly into my notes, and probably a million things I won’t think of until I have a prototype to play with.
Is your group thinking of testing hardware as well as software? For instance, you mention the need to automate some posting — this could be at least partly solved if the scientist could upload to the web from a hand-held device that he or she carries around and takes notes with all day.
Hi Bill
I need to write something on this as well at some point. The short answer here is that my perspective is that we try to do two things. First is to provide user friendly web interfaces that are easily accessible via computers that are in the lab. The second is that, as you suggest, a lot of this can be done with mobile phones. Mine will read bar codes, has a web browser, and can get on the web via wireless so a lot of the functionality is potentially there.
I personally find less need to scribble but I know that a lot of people want this. I’ve seen a cool uploadable pen and some pad systems that look quite good. Simplest approach? A one button scanner that automatically posts a scan of the page. Perhaps though the other approach is to ask why it is that you are scribbling? Is there another way to achieve the same end (audio/video/other random data?)
Hi Bill
I need to write something on this as well at some point. The short answer here is that my perspective is that we try to do two things. First is to provide user friendly web interfaces that are easily accessible via computers that are in the lab. The second is that, as you suggest, a lot of this can be done with mobile phones. Mine will read bar codes, has a web browser, and can get on the web via wireless so a lot of the functionality is potentially there.
I personally find less need to scribble but I know that a lot of people want this. I’ve seen a cool uploadable pen and some pad systems that look quite good. Simplest approach? A one button scanner that automatically posts a scan of the page. Perhaps though the other approach is to ask why it is that you are scribbling? Is there another way to achieve the same end (audio/video/other random data?)
Bill,
We have computers near the fume hoods so updating directly into the wiki is definitely a good option. I think that updating through a regualar keyboard is more convenient than handheld devices. Maybe for biologists in the field that would not be the case but for organic chemistry this works.
The policy in my lab is that all log updates need to be done on the wiki by the end of the day. So for students who prefer to record on paper first they have to take a few minutes to type before leaving. But there is generally very little writing in the log – things like “turned on heat to 3/10”, “temp = 30C”, etc. They can upload data files like NMR or images the next day.
Bill,
We have computers near the fume hoods so updating directly into the wiki is definitely a good option. I think that updating through a regualar keyboard is more convenient than handheld devices. Maybe for biologists in the field that would not be the case but for organic chemistry this works.
The policy in my lab is that all log updates need to be done on the wiki by the end of the day. So for students who prefer to record on paper first they have to take a few minutes to type before leaving. But there is generally very little writing in the log – things like “turned on heat to 3/10”, “temp = 30C”, etc. They can upload data files like NMR or images the next day.
I’ll follow up on this independently but talking with Jeremiah Faith this morning the concept of just having a bunch of cheap computers with relatively small screens mounted around the lab with cheap keyboards and mice that can be thrown away and replaced as necessary is becoming the most appealling approach.
There are different usage patterns; plan in lab book and then execute; execute directly in lab and note as you go; execute in lab and record later. I think we need to be able to cater for all of these.
I’ll follow up on this independently but talking with Jeremiah Faith this morning the concept of just having a bunch of cheap computers with relatively small screens mounted around the lab with cheap keyboards and mice that can be thrown away and replaced as necessary is becoming the most appealling approach.
There are different usage patterns; plan in lab book and then execute; execute directly in lab and note as you go; execute in lab and record later. I think we need to be able to cater for all of these.
Regarding the canSAS and its agreement to proceed on a common data format for reduced 1-D small-angle scattering data, the documentation for that standard can be found at:
http://www.smallangles.net/wgwiki/index.php/cansas1d_documentation
Also, other materials can be found at:
http://www.smallangles.net/wgwiki/index.php/1D_Data_Formats_Working_Group
Regarding the canSAS and its agreement to proceed on a common data format for reduced 1-D small-angle scattering data, the documentation for that standard can be found at:
http://www.smallangles.net/wgwiki/index.php/cansas1d_documentation
Also, other materials can be found at:
http://www.smallangles.net/wgwiki/index.php/1D_Data_Formats_Working_Group