The first session of the unconference turned out to be a kind of brainstorm to extract pertinent issues from the mindmaps generated through the preparatory chats.

The next step is a round of ‘dotmocracy’, which is a way of getting a bit of consensus on which of these issues people are interested in.

The last chat I was part of brought up the question of why we should bother with digital preservation. The argument against it usually goes that if people find resources useful they will preserve them anyway. I personally think that a kind of public interest theory is applicable due to the fact that current value of a resource is often lower than the future value of a resource – intervention is needed to protect the future value of the resource.

On reflection, though, it’s not the issue we should be discussing at an interoperability meeting. What we should be thinking about is “If someone wanted to preserve the resources in a repository, what interfaces / services would they need to be provided with?”

(I’m blogging this now because I don’t expect preservation to make the cut after dotmocracy).


Just picked this up on the digital preservation list – the national library and national archives in the Netherlands have announced Dioscuri, a digital preservation emulator. Dioscuri “is capable of emulating an Intel 8086-based computer platform with support for VGA-graphics, screen, keyboard, and storage devices like a virtual floppy drive and hard drive.”. As such it can emulate 16-bit operating systems.

This is interesting in itself – there are some great arguments for emulation as an approach to preservation and it’s good to see more progress in the area. But what’s really exciting about Dioscuri is that it has taken only 2 man-years to develop. The expense and difficulty in writing emulators has often been used as an argument against emulation, as has the perceived need for the efforts to be centralized. It seems Dioscuri changes the game!

The DSpace@Cambridge project is looking for a DSpace developer.

I’ve been moving more of SPECTRa over to Sourceforge and finding things out about the service. Something that made me sit back and have a think was the sourceforge backup policy. In a nutshell this states that they take at least weekly backups, but won’t restore them unless there’s a catastrophe at their end. I’d say the #1 risk, with high hazard and probability, is me making a mistake. Sourceforge don’t protect you against yourself.

That’s fair enough, it’s just a bit more work to arrange backups. But I’m glad I noticed the policy (I got there from a reference in the login shell), other colleagues I spoke to have used Sourceforge for years, were unaware of it, and don’t backup, expecting sourceforge to do it. The only problem here was my own expectation. Sourceforge provide a generally great service, and I’ve never heard a tale of woe about data loss on Sourceforge, so I built an expectation that they take care of backup and restore.

Perhaps this effect works in favour of IRs? One of the values of an IR is in acting as a deposition, access and dissemination service (as especially espoused by OA evangelists). Another value is in the provision of good curation. The expectation is matched by the service. I think, though, that the expectation has been built in a large part by the increasingly recognized brands of repo software projects such as DSpace, ePrints, Fedora et al.

I think this lies at the heart of why I felt initially uncomfortable about the idea of repositories sitting wholly within the web architecture (Andy Powell on the subject): If the IR is presented as ‘just a website’ then there’s no expectation, and you have to work to convince the user that they’re getting value. If you buy in to the web architecture vision Andy and others have been describing for IRs (as I have!), and if you agree that IRs are going to need a whole range of softwares to satisfy their users’ needs, then the importance of the software brand is going to be less and less important to users’ perception of the value of the IR, which might diminish as a result.

I don’t usually geek out over hardware, and I try to resist becoming a sysadmin myself, but I found this interesting: Everything you know about disks is wrong. It has some some implications for how preservation systems are run, and is in part a fillip for the LOCKSS approach.