Case study – Capturing wiki contents « Guide to Preservation of Web Resources

1 “ x Cite
Embed

<blockquote cite='http://jiscpowrguide.jiscpress.org/case-study-%e2%80%93-capturing-wiki-contents/#1'><table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="616" valign="top">Scenario: Wikis are now are at the   online heart of innumerable projects  for teaching, research, publishing and   business. When the project is complete what should be done with the content   to ensure it is retained? Does wiki software allow for this?</td>
</tr>
<tr>
<td width="616" valign="top">
<h3>Issues</h3>
<p>Many wikis have a backup option which will enable the   capture of wiki content, such as Wetpaint, Wikidot, Mediawiki, and   Confluence. However all these options produce imperfect results. In contrast   to this, if a spidering engine like HTTrack or Wget (see Appendix C) is used   to harvest the site remotely, a working local copy of the wiki, looking much   as it does on the web, will be the result. This might be an attractive option   if a record of what it looked like on a certain date is required.</p>
<p>However, it may not be necessary to gather every web   page since the wiki contains many automatically generated pages: versioning,   indexing, admin etc. So a <strong>selection decision</strong> is needed. For example, the edit   history and discussion pages may be excluded as the user community only wants   to look at the finished content.</p>
<p>The change history is important to the current   owner-operators of the wiki, however is this really needed for long term (or   even permanent) preservation. Indeed, could their access requirement be   satisfied merely by allowing the wiki (presuming it is reasonably secure,   backed-up etc.) to go on operating the way it is, as a self-documenting   collaborative editing tool?</p>
<h3>Approaches</h3>
<p>All this suggests some basic questions to ask when   setting up a wiki for a project:</p>
<ul>
<li>What aspects of the wiki do   we want to preserve and for how long?</li>
<li>Is there a business need to   capture the wiki change history, and for how long?</li>
<li>Will it need preserving at   intervals, or at a completion date?</li>
<li>Is it more important to   preserve text content, complete functionality, or its look?</li>
<li>Should we back it up? If so,   what should we back up?</li>
<li>Does the wiki provide backup   features? If so, what does it back up (e.g. attachments, discussions,   revisions)?</li>
<li>Once backed up, how easily   can it be restored?</li>
<li>Will the links still work in   our preservation or backup copy?</li>
<li>If the backup includes raw   wiki markup, do you have the capabilities to re-render this as HTML?</li>
</ul>
</td>
</tr>
</tbody>
</table></blockquote>

Scenario: Wikis are now are at the online heart of innumerable projects for teaching, research, publishing and business. When the project is complete what should be done with the content to ensure it is retained? Does wiki software allow for this?

Issues

Many wikis have a backup option which will enable the capture of wiki content, such as Wetpaint, Wikidot, Mediawiki, and Confluence. However all these options produce imperfect results. In contrast to this, if a spidering engine like HTTrack or Wget (see Appendix C) is used to harvest the site remotely, a working local copy of the wiki, looking much as it does on the web, will be the result. This might be an attractive option if a record of what it looked like on a certain date is required.

However, it may not be necessary to gather every web page since the wiki contains many automatically generated pages: versioning, indexing, admin etc. So a selection decision is needed. For example, the edit history and discussion pages may be excluded as the user community only wants to look at the finished content.

The change history is important to the current owner-operators of the wiki, however is this really needed for long term (or even permanent) preservation. Indeed, could their access requirement be satisfied merely by allowing the wiki (presuming it is reasonably secure, backed-up etc.) to go on operating the way it is, as a self-documenting collaborative editing tool?

Approaches

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

What aspects of the wiki do we want to preserve and for how long?
Is there a business need to capture the wiki change history, and for how long?
Will it need preserving at intervals, or at a completion date?
Is it more important to preserve text content, complete functionality, or its 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?