Late last night, local time, the Access2Research petition at whitehouse.gov got 25,000 signatures, which means that the White House is committed to responding. As someone who no longer reviews for journals that aren't OA, I obviously think that's great news, but it once again raises the question: what concepts and skills do researchers need in order to implement open access? Jon Udell has written at length about some things (most recently here), but to sharpen up the discussion:
If we added a third day to our standard two-day workshop, what could we put in it to help scientists use the web in their work?
I've asked this question before, and even answered it, but now that I'm part-way through writing up curriculum for that answer, I'm no longer satisfied with it. Yes, I can explain the HTTP request/response cycle, the structure of HTML, and how to use a web service, but that's like explaining the syntax of Python rather than how to structure a program, and over the past few years, we've moved from the former to the latter because the latter is what really matters.
So let me reframe the question. I think that half a day (i.e., the morning of day 3) is enough to teach:
- the structure of HTML/XML,
- how to create/parse documents programmatically, and
- the HTTP request/response cycle, the structure of URLs, etc.
There is absolutely, positively not time to teach them enough about security for them to start writing their own server-side applications: frameworks like Django do make some things simpler, but even experts can still create vulnerabilities for villains to exploit.
If we add a third day to our standard two-day workshop, can we teach people enough about the web for them to use and hack the IPython Notebook?
"And hack" is the important part: tools like these are still in their infancy, and every researcher's needs are slightly different, so I think our goal should be to accelerate evolution in this arena by teaching people how to extend the Notebook, connect it to other systems, etc. As always, the acid test must be whether they can debug the things they build using the skills they have—we know from both our own experience and the work of others that cookbook/template approaches fail in this regard.
Is the intersection of these constraints non-empty? Is there something we actually can teach in the time we have, to the audience we have, that's useful and debuggable? And if so, would you like to help us build it?
Originally posted at Software Carpentry.