Thoughts about DCC and USQ

Having moved computers one of the things that got lost was a list of feeds so I am catching up with some of the ones I used to read. I came across Chris Rusbridge’s Digital Curation Blog which is essential reading for anyone interested in the subject. Chris is a clear and thoughtful writer and often uses the blog to explore new ideas. Here is his comment on something I said at #LOTF09:

Libraries of the Future: SourceForge as Repository?

In his talk (which he pre-announced on his resumed blog), Peter Murray-Rust (PMR) suggested (as he has done previously) that we might like to think of SourceForge as an alternative model for a scholarly repository (“Sourceforge. A true repository where I store all my code, versioned, preserved, sharable”). I’ve previously put forward a related suggestion, stimulated by PMR’s earlier remarks, on the JISC-Repositories email list, where it got a bit of consideration. But this time the reaction, especially via the Twitter #lotf09 feed, was quite a bit stronger. Reactions really fell into two groups: firstly something like: SourceForge was setting our sights way too low; it’s ugly, cluttered by adverts, and SLOOOOOWWW (I can’t find the actual quote in my Twitter search; maybe it was on Second Life). Secondly, the use cases are different, eg @lescarr: “Repositories will look like sourceforge when researchers look like developers” (it might be worth noting that PMR is a developer as well as a researcher).

PMR: My demo of Sourceforge was primarily simply to show features of an Open, versioned system – I wanted to show that writers needed versions, needed to share, needed a submit-and-forget system. What I was implying (and it had to be implicit because of the short time) was that we needed similar systems for compound documents. Chris continues:

Journal articles, by contrast, are mostly written using proprietary (sometimes open source) office systems which create and edit highly complex files whose formats are closely linked to the application. Apart from some graphic and tabular elements, an article will usually be one file, and if not, there is no convention on how it might be composed. Workflow for multi-author articles is entirely dependent on the lead author, who will usually work with colleagues to assign sections for authoring, gather these contributions, assemble and edit them into a coherent story, circulating this repeatedly for comments and suggested improvements (sometimes using tracked change features).

PMR: completely so, and I am happy that Chris and others have picked up the baton. We need something of the power of Word or OpenOffice and in an ideal world the repository would allow either tool to access documents in the system. Indeed we should be careful about the word “repository” which implies “repose” and therefore peaceful but dead documents.

Next week I am off to USQ to work with Peter Sefton, guru of the ICE: The Integrated Content Environment. I need to know more detail before I claim it is the answer to Chris’ requirements. A system which manages collaboration, multiple authors, different content types, links, behaviour, styles, versions, platform independence, etc. is not trivial to create and I’ve probably made some facile assumptions about operations.

But if you are a “repository manager” responsible for curating an institution’s published output, you should be actively looking at communal authoring systems. That’s what the researchers really want, and getting the results into a repository should be a manageable task.