Distribution Infrastructure for DIY Bio
10 views
Skip to first unread message
Rick Smith
Nov 6, 2009, 9:31:50 AM11/6/09
to DIYbio
I have been trying to hash out the raw details of a distributed
approach within my own academic department. As could be easily
guessed, there is lots of interest in the *idea* of open/distributed
access and production of research, but also lots of interest to
actually *doing something about it*.
One of the biggest obstacles is human nature - even with a creative
commons/science commons attribution system, people are really afraid
of getting scooped. Additionally, scientists doubt that human nature
is so anxious for participation as to mitigate the effects of rapidly
providing access to scientific work. I blogged on this today -
http://bit.ly/11ibkz - and just want to see what kinds of ideas are
out there.
Rick Smith
Twitter: @h2oindio
approach within my own academic department. As could be easily
guessed, there is lots of interest in the *idea* of open/distributed
access and production of research, but also lots of interest to
actually *doing something about it*.
One of the biggest obstacles is human nature - even with a creative
commons/science commons attribution system, people are really afraid
of getting scooped. Additionally, scientists doubt that human nature
is so anxious for participation as to mitigate the effects of rapidly
providing access to scientific work. I blogged on this today -
http://bit.ly/11ibkz - and just want to see what kinds of ideas are
out there.
Rick Smith
Twitter: @h2oindio
JonathanCline
Nov 6, 2009, 2:37:46 PM11/6/09
to DIYbio
On Nov 6, 8:31 am, Rick Smith <h2oneu...@gmail.com> wrote:
> I have been trying to hash out the raw details of a distributed
> approach within my own academic department. As could be easily
> guessed, there is lots of interest in the *idea* of open/distributed
> access and production of research
What kind of stuff is being discussed for open access? Which one of
> I have been trying to hash out the raw details of a distributed
> approach within my own academic department. As could be easily
> guessed, there is lots of interest in the *idea* of open/distributed
> access and production of research
the below, or others:
source code for apps (c, perl, java, etc)
source code for 1-off data-processing scripts (matlab, r, etc)
bio protocols / methods documentation
mathematical algorithms
hardware cad drawings
graphic image data (i.e. gel scans, plate scans)
vector image data (i.e. nework diagrams, svg)
documentation
online discussion/ conversation
in-process docs / pre- publications
presentations / slides documents
raw data from instrumentation
educational/howto audio/video
digital lab notebooks / scans of paper lab notebooks
remote access (i.e. over internet) to local equipment
(instrumentation) hosted in lab
lab inventory data / LIMS database
custom bio databases
custom lab wiki's / intranets
physical equipment sharing (lending to remote users & shipping it
there)
chemical or biologicals supply (i.e. "send me your homegrown taq")
remote access to lab machines using network client (SSH, VNC)
other?
## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################
Rick Smith
Nov 7, 2009, 1:07:22 PM11/7/09
to DIYbio
> What kind of stuff is being discussed for open access?
That's quite the laundry list, but the basic idea involves getting
students to:
1. Organize into groups to tackle known issues in molecular biology
2. Allowing the the resources they need to collaboratively attack
multiple aspects of the problem.
3. Distributing the data in a rapid, open fashion and publishing the
results via the web on a blog, etc.
The resistance comes mostly from:
1. Grads not focusing on their thesis/dissertation work
2. Resources being spent on a project not related to the lab's focus
3. Revealing data to the public (and other scientists) that might
lead to that work getting "scooped" by another lab
I think that the majority of these concerns could be handled by using
a universal attribution system (complete with timestamps, etc) which
would allow the public to see who produced what data and who did it
first.
Additionally, there's the issue of data production vs. knowledge
production. It's one thing to produce data, and another altogether to
produce knowledge.
If I can figure out a meaningful way of organizing people such that it
doesn't disrupt normal, day-to-day activity, I think researchers would
be willing to diversify a bit and try something new.
Ideas, suggestions, and comments all welcome!
Twitter: @h2oindion
Site: http://opsd.wordpress.com/
JonathanCline
Nov 9, 2009, 7:59:47 PM11/9/09
to DIYbio, jcl...@ieee.org
On Nov 7, 12:07 pm, Rick Smith <h2oneu...@gmail.com> wrote:
If you say "Open access", then in this context, it might be
misleading. Your list boils down to:
> 1. Organize into project groups
> 2. collaborate, share
> 3. Distribute / rapid-publish data
These are independent of open access. In fact corporate environments
deal with the same issues on intranets regularly: how to boost
productivity (collaboration) in distributed environments. For any
group (corporate or academic or open source) it boils down to this:
less than 10% of the participants will contribute over 90% of the
collaboration effort / data -- the others don't publish directly.
Even if there are incentives involved (or job mandates), there is a
lot of inertia. A minor part of this inertia is due to the tools
being hard to use. Better tools can create more productivity for
those 10%, however motivating the non-10% to collaborate / contribute
takes a lot of thought. Automatic publishing is the easiest: i.e. in
the normal course of working, the data gets pushed into the
collaboration software (same as source code control). Using Web 2.0
can actually reduce productivity for the most efficient workers.
Internet apps (like editing on wikipedia, or blog editors) have much
slower response than running a local word processor, for example --
the benefit is that the regular procedure (i.e., clicking "Save") will
automatically push the docs around to the collaborators. If you want
to go full Web 2.0, look at online collaboration software (a popular
one today is Joomla, or go with a wiki). Otherwise, you might get
away with a simpler working procedure method, like uploading shared
files to google docs. I would think that patent issues would create
more of a lockdown than getting scooped, even in university
environments, so I'm surprised you didn't mention it in the list. For
scientific use, I would go with TWiki, because it is written
completely in perl with capabilities for plugins. That means the
content can feed into custom perl plugins, process the data, and feed
it back to users (for example: taking data and displaying custom bar
graphs). Be aware that you'll need an admin if you choose any Web 2.0
system.
The human work procedure which is the most important element of
collaboration, and not really the tools. The internet itself was
built using simple technical memos, emailed around as plain text
documents with ASCII drawings (lowest common denominator data sharing
format, so that anyone could view it, even on a teletype machine).
Nowadays the lowest common denominator isn't quite so primitive as
that.. those tools are still getting the job done today. If the
processes / procedures are well written and training is done properly,
the tools will be 100x more productive.
The benefits of making the above collaboration internet accessible
(open access) is that you open up to Long Tail productivity. Which
means that when the most active 10% of the participants move on to a
different project, the project still exists for others to make small
improvements to, or branches off of it, over the very long term.
(Contrast to locked down projects, which usually die when the original
participants move on.) *BUT* if you choose great Web 2.0
collaboration software today, and the admin moves on or the budget
expires or the server goes through an upgrade which creates some silly
SQL/PHP problem -- the entire set of work might die from
inaccessibility. The long tail consideration includes providing for
the collaboration mechanism to live on without much maintenance.
Simpler tools are often better.
If you say "Open access", then in this context, it might be
misleading. Your list boils down to:
> 1. Organize into project groups
> 2. collaborate, share
> 3. Distribute / rapid-publish data
These are independent of open access. In fact corporate environments
deal with the same issues on intranets regularly: how to boost
productivity (collaboration) in distributed environments. For any
group (corporate or academic or open source) it boils down to this:
less than 10% of the participants will contribute over 90% of the
collaboration effort / data -- the others don't publish directly.
Even if there are incentives involved (or job mandates), there is a
lot of inertia. A minor part of this inertia is due to the tools
being hard to use. Better tools can create more productivity for
those 10%, however motivating the non-10% to collaborate / contribute
takes a lot of thought. Automatic publishing is the easiest: i.e. in
the normal course of working, the data gets pushed into the
collaboration software (same as source code control). Using Web 2.0
can actually reduce productivity for the most efficient workers.
Internet apps (like editing on wikipedia, or blog editors) have much
slower response than running a local word processor, for example --
the benefit is that the regular procedure (i.e., clicking "Save") will
automatically push the docs around to the collaborators. If you want
to go full Web 2.0, look at online collaboration software (a popular
one today is Joomla, or go with a wiki). Otherwise, you might get
away with a simpler working procedure method, like uploading shared
files to google docs. I would think that patent issues would create
more of a lockdown than getting scooped, even in university
environments, so I'm surprised you didn't mention it in the list. For
scientific use, I would go with TWiki, because it is written
completely in perl with capabilities for plugins. That means the
content can feed into custom perl plugins, process the data, and feed
it back to users (for example: taking data and displaying custom bar
graphs). Be aware that you'll need an admin if you choose any Web 2.0
system.
The human work procedure which is the most important element of
collaboration, and not really the tools. The internet itself was
built using simple technical memos, emailed around as plain text
documents with ASCII drawings (lowest common denominator data sharing
format, so that anyone could view it, even on a teletype machine).
Nowadays the lowest common denominator isn't quite so primitive as
that.. those tools are still getting the job done today. If the
processes / procedures are well written and training is done properly,
the tools will be 100x more productive.
The benefits of making the above collaboration internet accessible
(open access) is that you open up to Long Tail productivity. Which
means that when the most active 10% of the participants move on to a
different project, the project still exists for others to make small
improvements to, or branches off of it, over the very long term.
(Contrast to locked down projects, which usually die when the original
participants move on.) *BUT* if you choose great Web 2.0
collaboration software today, and the admin moves on or the budget
expires or the server goes through an upgrade which creates some silly
SQL/PHP problem -- the entire set of work might die from
inaccessibility. The long tail consideration includes providing for
the collaboration mechanism to live on without much maintenance.
Simpler tools are often better.
Rick Smith
Nov 10, 2009, 10:51:52 PM11/10/09
to DIYbio
Thanks for the ideas - it is great to get some feedback.
As far as the using open access to describe what I'm attempting to do
in the lab, I think I'm more or less right on, though I may be
misunderstanding the concept of open source/open access. It seems like
producing data and getting to the public in a standardized format so
that more can be added to it is the whole crux of the "open" movement
- transparency, etc. My object is definitely to use distribution of
data (experimenting with an open system using experts first) but
eventually to move that into a completely public forum where data set
attribution is protected, but data set use is ubiquitous. Creative
Commons and Science Commons are the first steps in this direction
because they free up the administrators and PIs who are worried about
having their discoveries/patents stolen from them by establishing a
clear-cut method of data set attribution and allow public users full
access to add to the data as they wish.
In reality, though open access to that data and the open production of
that data are essentially two distinct fields, they are nevertheless
tightly coupled - coupled to the point that working on one without the
other is senseless. That's where I'm coming from when I call either
aspect of this kind of an endeavor "open".
I definitely agree that the way to get that 90% involved is going to
require a lot of effort. Where are the difficulties? Is it a matter of
user interface on the scientific data side? I think that regardless of
the hardware/software used, the platform for automatic publication of
data is going to be essential, and there will also need to be tools to
effectively inform the user on what the data are/how they are
interpreted.
In the open source programming world, programmers/engineers are able
to learn a language in a month or two (or less, with effort), but it
seems like there's a lot more training necessary for open sourcing
biology. Any ideas on how to streamline that process? That would
really speed things up. Additionally, projects that people were really
concerned about would be the ones that get accomplished faster.
Again, thanks for the reply.
Cheers,
Rick Smith
As far as the using open access to describe what I'm attempting to do
in the lab, I think I'm more or less right on, though I may be
misunderstanding the concept of open source/open access. It seems like
producing data and getting to the public in a standardized format so
that more can be added to it is the whole crux of the "open" movement
- transparency, etc. My object is definitely to use distribution of
data (experimenting with an open system using experts first) but
eventually to move that into a completely public forum where data set
attribution is protected, but data set use is ubiquitous. Creative
Commons and Science Commons are the first steps in this direction
because they free up the administrators and PIs who are worried about
having their discoveries/patents stolen from them by establishing a
clear-cut method of data set attribution and allow public users full
access to add to the data as they wish.
In reality, though open access to that data and the open production of
that data are essentially two distinct fields, they are nevertheless
tightly coupled - coupled to the point that working on one without the
other is senseless. That's where I'm coming from when I call either
aspect of this kind of an endeavor "open".
I definitely agree that the way to get that 90% involved is going to
require a lot of effort. Where are the difficulties? Is it a matter of
user interface on the scientific data side? I think that regardless of
the hardware/software used, the platform for automatic publication of
data is going to be essential, and there will also need to be tools to
effectively inform the user on what the data are/how they are
interpreted.
In the open source programming world, programmers/engineers are able
to learn a language in a month or two (or less, with effort), but it
seems like there's a lot more training necessary for open sourcing
biology. Any ideas on how to streamline that process? That would
really speed things up. Additionally, projects that people were really
concerned about would be the ones that get accomplished faster.
Again, thanks for the reply.
Cheers,
Rick Smith
Cathal Garvey
Nov 11, 2009, 2:59:32 PM11/11/09
to diy...@googlegroups.com
Google Wave as a Web2 collaborative tool seems to be a ripe solution to many of these concerns. As simple as a document editor, trivially easy to share, persistent and secure, and publishable.
## Mobile: +1-805-617-0223 ######################## --~--~---------~--~----~------------~-------~--...
Mackenzie Cowell
Nov 11, 2009, 3:23:48 PM11/11/09
to diy...@googlegroups.com
Broader, deeper, more instantaneous data logging with attribution will be one aspect of future distributed science.
Jason Morrison and I are organizing a one- to two- day camp in early 2010 to bring together the leaders in this area: the augmented scientists, hardware hackers, and standards-builders, and this is exactly what we hope the group will be able to work on. http://futurelabcamp.org
Have you read the OneBigLab blog?:
Envisioning the scientific community as One Big Lab (Monday, April 14, 2008)
The blogosphere has been abuzz recently, or, at least, it seems that way if you've only been checking up on it sporadically the last few weeks. Jennifer Rohn's post about lab notebooks has spurred over 100 lively comments spanning electronic lab notebooks, peer-review, openness in science, and the reward system in science, making for an engrossing peek at the social science of science. Cameron's own musings on that discussion. Pawel Szczesny writes about what it means to be a freelancing scientist. All of this is fascinating and it is exciting to contemplate both what the future of science holds and the obstacles we will need to overcome; the fact that there are indeed stubborn obstacles (technological as well as cultural) and potentially tremendous rewards makes the anticipation of that future all the more heightened.
There seems to be growing institutional agreement that microattribution is a Good Thing: http://blogs.nature.com/nautilus/2009/11/nature_cell_biology_joins_call_1.html.
Hope to see you at Future Lab Camp! (Jason and I are sending out formal announcements this weekend).
Mac
+1.231.313.9062 / m...@diybio.org / @100ideas
Eugen Leitl
Nov 11, 2009, 4:49:16 PM11/11/09
to diy...@googlegroups.com
osla
On Wed, Nov 11, 2009 at 07:59:32PM +0000, Cathal Garvey wrote:
> Google Wave as a Web2 collaborative tool seems to be a ripe solution to many
> of these concerns. As simple as a document editor, trivially easy to share,
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
JonathanCline
Nov 11, 2009, 11:00:05 PM11/11/09
to DIYbio, jcl...@ieee.org
On Nov 10, 9:51 pm, Rick Smith <h2oneu...@gmail.com> wrote:
> - transparency, etc. My object is definitely to use distribution of
> data (experimenting with an open system using experts first) but
> eventually to move that into a completely public forum where data set
> attribution is protected, but data set use is ubiquitous. Creative
> Commons and Science Commons are the first steps in this direction
It is probably better to discuss a specific example. Do you have
> - transparency, etc. My object is definitely to use distribution of
> data (experimenting with an open system using experts first) but
> eventually to move that into a completely public forum where data set
> attribution is protected, but data set use is ubiquitous. Creative
> Commons and Science Commons are the first steps in this direction
one? The bio data I see most often is genomic and is too big to
really share without custom database infrastructure to retrieve only
subsets of the data from queries. This seems to create the many-non-
integrated-database problem too.
To protect attribution, the original open source licenses had in the
license the required attribution (old BSD), i.e. "All uses of this
software must state it contains portions of software copyright Author
Name". This caused so much of a problem (so many people to attribute
that a software release had pages of attributed authors) that the
practice was dropped from majority use, as being impractical.
> I definitely agree that the way to get that 90% involved is going to
> require a lot of effort. Where are the difficulties? Is it a matter of
> user interface on the scientific data side?
of it is documenting procedure, some of it is training. Best to
discuss by specific example.
Example - graphic artists who need to share and rapidly publish data
for a large web site; the data is the graphics files in different
sizes, formats, and such. The graphics fit within the html and css,
which is written by others (web designers). Both of these are used by
the web programmers for integrating with back end code (php, sql,
etc). Of these, the graphic artists are the non-technical "creative"
types and are typically tough to get on a program of revision control,
etc. Some groups have successfully used TortoiseSVN (assumes the
workers are using Microsoft operating systems) with a very-well-
documented data publishing how-to-procedural manual. The end result
is the graphic artists focus on the graphics, do some right clicking
and left clicking, and the data is published for others.
Getting workers to write wiki (or other pre-publication) docs is more
challenging. Some people do not write. Although I have seen more get
into publishing to wiki's after hours of training followed by mandates
of it's use. Sometimes getting techies to update their changes into
source control is tough too -- not what is normally expected --
because the techies want to "finish one last thing" before committing
the code, and there's always "one last thing" so the sharing is
delayed. Regular reminders/hassling by project managers ensures the
data is forced into the cloud, sometimes with loud protests. Also
one very important point, is that the mandates must come from the very
top -- any disagreement between managers regarding the importance of
following the process gives workers excuses not to spend the
"extra"/"wasted" effort (I've seen this a lot).
> In the open source programming world, programmers/engineers are able
> to learn a language in a month or two (or less, with effort), but it
> seems like there's a lot more training necessary for open sourcing
> biology.
me a weekend to get running with a cyanobacteria bioreactor (still on
my todo list), and that's a lot faster than learning a computer
language which might take a month. Sure, the latest in bio (syn bio)
takes a lot of learning, though so does the latest in computer
software development (android apps, anyone? .. and that's using
existing languages).
Probably the point here is that programming/engineering is mostly
repeatable and repeating an experiment costs virtually nothing
(recompile -> run -> debug -> recompile..), whereas bio is not so much
repeatable and an experiment might have much higher cost (experimental
time, consumables, environmental conditions, ...).
Also it's fair to say that bio people go into bio, in some part, to
get away from technology. Sure, there will be more of a learning
curve for technology in bio circles. (I would say, keep as much of
the technology abstracted & easy to use as possible, and let the bio
people focus on the bio.)
> Any ideas on how to streamline that process? That would
> really speed things up.
for automatic documentation. For example in a text database, define
fields in advance that are descriptive fields, and have the
publication process pull out these descriptions for users to view as a
cross-reference "manual", immediately upon publication. In computer
science, this is akin to Javadoc or Perl POD -- writing the manual
alongside the code, both in parallel. It's tougher to go back to
document later, the documentation always get cut from the schedule.
Documentation nowadays includes audio and video. (Everyone see
http://labtube.tv ? )
Include third-party testing in the process. In the publishing
process, include mechanisms for marking verification by others (or by
machine). This ensures the data is correct (from both typos and bad
work). In computer science, this is akin to an autobuild process,
which compiles the software every night and emails publishers if there
are bugs; if the failures continue for several weeks without fixing,
then the CTO of the organization gets cc:'ed on that email so he can
send a nasty-gram to the project managers for not keeping things tight
(sounds extreme, though it's true). The faster the feedback loop
becomes (ex. noticing an error, reporting it to the author, getting it
corrected) the more productive the system becomes.
Easy methods of submitting error reports and a solid tracking system.
In the publishing process, include work tags (i.e. bug numbers /
project tracking identifiers) in the commit messages. This cross-
references into the documentation and the task tracking database, with
back linking. This streamlines the process of: creating work todo's,
filling the todo's with finished work, documenting the work has been
done on a specific publishing step, and cross-referencing the tracking
database as "work completed".
The process is adopted from a couple angles; hopefully, people see
that it saves time, so they use the system (not so common). More
likely, the managers apply pressure periodically to continually follow
the process (all kinds of motivators are used). The above are all
standard work processes in software teams. Some teams do it better
than others. I could imagine that much of this could be integrated
into openwetware.org with sufficient motivation. Different types of
projects need different perspectives though, i.e. not every project
tracker can be the same, so I wouldn't expect a system for open bio to
be a universal solution either. It would depend on the type of
project and often on the work style (style being analogous to "Agile"
or "XP" or "Task based" or ... in the software world -- not everyone
works the same, not every project can be "Agile", etc).
Reply all
Reply to author
Forward
0 new messages