Cameron Neylon

[Google Wave](http://wave.google.com) has got an awful lot of people
quite excited. And others are more sceptical. A lot of SciFoo attendees
were therefore very excited to be able to get an account on the
developer sandbox as part of the weekend. At the opening plenary
[Stephanie Hannon](http://www.crunchbase.com/person/stephanie-hannon)
gave a demo of Wave and, although there were numerous things that didn't
work live, that was enough to get more people interested. On the
Saturday morning I organized a session to discuss what we might do and
also to provide an opportunity for people to talk about technical
issues. Two members of the wave team came along and kindly offered their
expertise, receiving a somewhat intense grilling as thanks for their
efforts.

I think it is now reasonably clear that there are two short to medium
term applications for Wave in the research process. The first is the
collaborative authoring of documents and the conversations around those.
The second is the use of wave as a recording and analysis platform. Both
types of functionality were discussed with many ideas for both. [Martin
Fenner](http://network.nature.com/people/mfenner/blog) has also [written
up some initial
impressions](http://network.nature.com/people/mfenner/blog/2009/07/18/using-google-wave-for-a-week-its-still-great).

Naturally we recorded the session in Wave and even as I type, over a
week later, there is a conversation going in real time about the details
of taking things forward. There are many things to get used to, not
leastwhen it is polite to delete other people's comments and clean them
up, but the potential (and the weaknesses and areas for development) are
becoming clear.

I've pasted our functionality brainstorm at the bottom to give people an
idea of what we talked about but the discussion was very wide ranging.
Functionality divided into a few categories. Firstly Robots for bringing
scientific objects, chemical structures, DNA sequences, biomolecular
structures, videos, and images into the wave in a functional form with
links back to a canonical URI for the object. In its simplest form this
might just provide a link back to a database. So typing "chem:benzene"
or "pdb:1ecr" would trigger a robot to insert a link back to the
database entry. More complex robots could insert an image of the
chemical (or protein structure) or perhaps rdf or microformats that
provide a more detailed description of the molecule.

Taking this one step further we also explored the idea of pulling data
or status information from larboratory instruments to create a
"laboratory dashboard" and perhaps controlling them. This discussion was
helpful in getting a feel for what Wave can and can't do as well as how
different functionalities are best implemented. A robot can be built to
populate a wave with information or data from laboratory instruments and
such a robot could also pass information from the wave back to the
instrument in principle. However both of these will still require some
form of client running on the instrument side that is capable of talking
to the robot web service. So the actual problem of interfacing with the
instrument will remain. We can hope that instrument manufacturers might
think of writing out nice simple XML log files at some point but in the
meantime this is likely to involve hacking things together. If you can
manage this then a Gadget will provide a nice way of providing a visual
dashboard type interface to keep you updated as to what is happening.

Sharing data analysis is something of significant interest to me and the
fact that there is already a robot (called
[Monty](http://wave-samples-gallery.appspot.com/about_app?app_id=9003))
that will intepret [Python](http://python.org) is a very interesting
starting point for exploring this. There is some basic graphing
functionality
([Graphy](http://code.google.com/p/google-wave-resources/source/browse/trunk/samples/extensions/robots/python/graphy/)
naturally). For me this is where some of the most exciting potential
lies; not just sharing printouts or the results of data analysis
procedures but the details of the data and a live representation of the
*process* that lead to the results. Expect much more from me on this in
the future as we start to take it forward.

The final area of discussion, and the one we probably spent the most
time on, was looking at Wave in the authoring and publishing process.
Formatting of papers, sharing of live diagrams and charts, automated
reference searching and formatting, as well as submission processes,
both to journals and to other repositories, and even the running of peer
review process were all discussed. This is the area where the most
obvious and rapid gains can be made. In a very real sense Wave was
designed to remove the classic problem of sending around manuscript
versions with multiple figure and data files by email so you would
expect it to solve a number of the obvious problems. The interesting
thing in my view will be to try it out in anger.

Which was where we finished the session. I proposed the idea of writing
a paper, in Wave, about the development and application of tools needed
to author papers in Wave. As well as the technical side, such a paper
would discuss the user experience, and any of the social issues that
arise out of such a live collaborative authoring experience. If it were
possible to run an actual peer review process in Wave that would also be
very cool however this might not be feasible given existing journal
systems. If not we will run a "mock" peer review process and look at how
that works. If you are interested in being involved, drop a note in the
comments, or join the [Google
Group](http://groups.google.com/group/knowledge-waves) that has been set
up for discussions (or if you have a developer sandbox account and want
access to the Wave drop me a line).

There will be lots of details to work through but the overall feel of
the session for me was very exciting and very positive. There will
clearly be technical and logistical barriers to be overcome. Not least
that a a significant quantity of legacy toolingmay not be a good fit for
Wave. Some architectural thinking on how to most effectively re-use
existing code may be required. But overall the problem seems to be where
to start on the large set of interesting possibilities. And that seems a
good place to be with any new technology.

> Brainstorming functionality:
>
> - biological structures
> - gene and protein information
> - integration of graphs and text, charts
> - chemical structure and information
> - laboratory dashboard
> - slide presentations to share and do remotely
> - 3d objects rotated and maniplauted
> - embedding videos (already done for You Tube)
> - sharing data analysis procedures (via python code execution?)
> - embed pdfs and full text reference
> - graphical annotation over other objects
> - Latex and mathematics
> - human to science translation
> - integration with email for the people who get left behind :-)
> - specific publisher formats? How does the underlying formatting work
>   -- convert to NLM DTD? This should also include checking that all
>   required elements (e.g. title, authors, keywords, abstract,
>   introduction, etc.) are present
> - pushing papers into peer review system (use in peer review as well?)
> - institutional repositories and automatic deposition (capture dublin
>   core?)
> - offline use will be important for researchers


Google Wave has got an awful lot of people quite excited. And others are more sceptical. A lot of SciFoo attendees were therefore very excited to be able to get an account on the developer sandbox as part of the weekend. At the opening plenary Stephanie Hannon gave a demo of Wave and, although there were numerous things that didn’t work live, that was enough to get more people interested.

Publicaciones de Rogue Scholar

Sci – Bar – Foo etc. Part III – Google Wave Session at SciFoo