I just spotted a posting from a fellow Antipodean, made to the Australian Archivists (aus-archivists) listserv, which has certainly raised some interesting questions surrounding web 2.0 technologies and their impact on the Archive sector…. Perhaps a debate well worth monitoring, and further exploring here, within the realm of web 2.0 itself?

See Australian Archivists listserv posting below:

Archival institutions are increasingly using social networking sites, tagging (folksonomies), blogs, wikis, and Flickr to promote their collections. Does anyone know any studies evaluating this phenomenon in the archival setting? I don’t mean the this-is-how-we-did-it, isn’t-it-exciting or look-how-many-hits-we’re-getting articles. I mean thoughtful consideration of the value of these tools and the effects they are having on our work. I’d also love some discussion on the list.

Why we have decided to use these tools? What benefits have they brought? What kind of new audiences are they attracting? How long do these audiences stick around? Is the resource taken to sustain these ‘relationships’ worth it? Do these audiences engage with us beyond the social network stuff? Do they use our databases? come in and use our collections? order quality copies? Does it matter if they don’t? How is our adoption of these tools affecting what material we choose to process and promote? With user-generated content and tagging are our formal documentation skills, cataloguing standards, thesauri, etc passé? Does mashing trivialise our research collections? Any observations or leads to articles welcome. [ Helen Yoxall, Archives Manager, Registration and Collection Management, Powerhouse Museum, PO Box K346, Haymarket NSW 1238, Australia, URL: www.powerhousemuseum.com/archives/index.asp]“

After a quick (and rudimentary) search, I stumbled across a few sources that may be of interest:

• UKOLN have a presentation “Web 2.0: Implications For The Cultural Heritage Sector”
• The Archives & Museum Informatics Museums and the Web website, includes a paper “Towards Community Contribution: Empowering Community Voices On-Line” (Angèle Alain, Library and Archives Canada, Canada; Michelle Foggett, The National Archives of England and Wales, UK). It refers to Web 2.0 and community involvement in museums, libraries and archives e.g. the Moving Here project which has sought to “break down barriers to the direct involvement of minority ethnic groups in sharing their history on-line” and is among other projects keen to “embrace social networking in future to give users a higher profile voice to enable their knowledge to be passed down to the next generation”. (However, “specialised and appropriate training” was identified as crucial to tackling the barriers,[such as the 'digital divide' itself]). On the related MuseumsComputerGroup website is the article abstract “Museums and Web 2.0: Connections + Community” (by Jennifer Trant, Archives and Museum Informatics), noting both the possibilities, and challenges, surrounding the adoption of web 2.0.
• Also of interest are the web 2.0 blogs: Library 2.0 network, Library 2.0 gang, Museum 2.0; and while I couldn’t spot an Archives 2.0-specific blog anywhere, there was an interesting posting on the Archives Hub blog and on ArchivesNext (which, as one of its aims, invites bloggers to explore “Web 2.0 applications and discussing their applicability to archival institutions”).
• Our own dablog has highlighted one dimension of the web 2.0 impact (inspired by UCL’s Dr Andrew Flinn) i.e. in relation to urgent calls to preserve the heritage outputs of web 2.0, due to “the transient history of the increasing number of minority/dissenting voices, whose heritage is only documented via websites, blogs, wikis and social software”.
• In true folksonomic Web 2.0 style, we can also see what’s been tagged as Archives2.0 in del.icio.us.

Know of any other sources that discuss the impact of Web 2.0 on the Archives Sector? Or would you like to share your opinions in response to the questions posed by Helen Yoxall (above)?

But what’s often given less serious consideration, in the excitement of using a third-party provider of wikis, blogs, Ning, etc., to get your collaborative hypertext project off the ground so quickly and easily – and without having to go cap or cheque in-hand to whoever guards your web space – is this key preservation issue: what happens when you want to get your painstakingly intricate web of hyperlinked pages out?

There are many good reasons why you might want to do this: you might want to migrate to another wiki system or CMS, as the shape and nature of your content evolves; or put it on a permanent, persistent footing by moving it into your own domain; you might simply want to back it up or take a snapshot; or you might want to pull out information for publication in a different form. When you had one or two pages, it might have seemed trivial; but what if you now have hundreds?

Unfortunately, just as exporting the information is often a secondary consideration for wiki content creators, so it also is for the wiki farm systems. The Wetpaint Wiki discussion boards indicate that an export feature was a long time in coming (and its absence quite a blocker to adoption by a number of serious would-be users). And what was eventually provided leaves a lot to be desired.

Wetpaint’s backup option “lets” you download your wiki content as a set of HTML files. Well, not really HTML files: text files with some embedded HTML-like markup. (Which version? Not declared.) Don’t expect to open these files locally in your browser and carry on surfing your wiki hypertext (even links between wiki pages need fixing). The export doesn’t include comment threads or old versions. Restoring it to your online wiki is not possible. But, for what it’s worth, you have at least salvaged some sort of raw content, that might be transformed into something like the wiki it came from, if hit with a bit of Perl script or similar.

I checked out Wikidot – another impressively-specced, free “wiki farm”. Wikidot’s backup option will deliver you a zip file containing each wiki page as a separate text file, containing your wiki markup as entered, as well as all uploaded file attachments. However, according to Wikidot support:

you can not restore from it automatically, it does not include all page revisions, only current (latest), it does not include forum discussion or page comments.

To reconstruct your wiki locally, you’ll, again, need some scripting, including using the Wikidot code libraries to reconvert its non-standard wiki-markup into standard HTML.

A third approach can be seen with a self-hosted copy of Mediawiki. Here you can select one or more pages by name, and have them exported as an XML file, which also contains revisions and assorted other metadata. Within the XML framework, the page text is stored as original wiki markup, raising the same conversion issues as with Wikidot. However, the XML file can be imported fairly easily into a different or blank instance of Mediawiki, recreating both hypertext and functionality more or less instantly.

In contrast to all these approaches, if you set a spidering engine like HTTrack or Wget to work “remotely harvesting” the site, you would get a working local copy of your wiki looking pretty much as it does on the web. This might be an attractive option if you simply want to preserve a record of what you created, a snapshot of how it looked on a certain date; or just in case a day should come when Wetpaint.com Inc., and the rest, no longer exist.

However, this will only result in something like a preservation copy – not a backup that can be easily restored to the wiki, and further edited – in the event, say, the wiki is hacked/cracked, or otherwise disfigured. For security alone, it may be sufficient to depend on regular backups of the underlying database, files and scripts: but you still ought to reassure yourself exactly what backup regime your host is operating, and whether they can restore them in a timely fashion. (Notwithstanding the versioning features of most wikis, rolling back a raft of abusive changes across a whole site is not usually a quick, easy or particularly enjoyable task.)

All this suggests some basic questions that one needs to ask when setting up a wiki for a project:

• How long do we need it for?
• Will it need preserving at intervals, or at a completion date?
• Is it more important to preserve its text content, or its complete look?
• Should we back it up? If so, what should we back up?
• Does the wiki provide backup features? If so, what does it back up (e.g. attachments, discussions, revisions)?
• Once “backed up”, how easily can it be restored?
• Will the links still work in our preservation or backup copy?
• If the backup includes raw wiki markup, do you have the capabilities to re-render this as HTML?

And questions like these are no less relevant when considering your uses of blogs and other social software: I hope we’ll be able to look at them more closely in another post.