1. Documenting the Resource Malcolm Polfreman Malcolm.polfreman@ahds.ac.uk

2. Types of documentation Contextual documentation within or accompanying the resource e.g. User guides, codebooks, data dictionaries Preservation metadata e.g. Technical metadata, administrative metadata Resource discovery metadata e.g. Dublin Core

3. Resources are not self-explanatory Users will ask legitimate questions: How are the fields in your database defined?  Who took the photographic images that you’ve digitised and are they in copyright? Did you digitise the first private draft of the memorandum or the final published version?

4. Memory is not enough The resource MUST be documented. Memory is fallible: you’ve digitised 10, 100, 10,000, 100,000 other confusingly similar items you come back to the resource after a gap you and/or your colleagues leave the project your organization merges, resources are shared, redistributed, recycled The project ends – perhaps at short notice.

5. When documentation is lacking The data itself is meaningless to users. The creator cannot identify it reliably Data-creation may become inconsistent through the lifetime of the project Correct preservation action is difficult to decide - endangering long-term usability.

6. Things to document … Aims/objectives/purpose Methodology of parent project Subject matter/scope Extent of resource Likely future work

7. Also … Creator/contributors Funding arrangements Methodology Of parent project Of digitisation Rights associated with the resource. Technical details such as file formats and size

8. File structure Provide an overview of the file structure Provide a list of all files Create a logical file strategy from the outset  Choose consistent filenames  Avoid using re-using same filename even in separate folders.  Store files in a logical order with systems and contents files kept apart.  Summary of contents may be included with each file. Keep a record of encryption keys – important for preservation.

9. Identifiers Choose unique identifier for the digital objects. E.g. ISBN, URN Human-readable or random identifiers? Both have advantages and disadvantages

10. Provenance and sources Document the provenance & sources used: Provide scanned images of sources used, such as interview scripts, performance notes, tax returns, specimen forms, questionnaires. Provide references to other relevant resources. Record changes in ownership of the resource. There should be no links in the document chain back to sources. Include key correspondence and formal agreements relating to the creation and use of the resource's content.

11. Document your encoding strategy For a database to make sense, the documentation should include such things as: Codebooks, look-up tables keys to encoded values (e.g. what do 0,1, 2, … mean in this context?) Glossary of abbreviations Names and textual descriptions (definitions) of all fields

12. When should documentation occur? Not additional chore done at end of a project but an on-going process that is integral to the creation of the data. Tasks should be documented as they occur when the activity is fresh in the mind This prevents information being misplaced, forgotten, or taken away from the project if key staff depart, and ensures consistency over time

13. Resource discovery metadata Your resource should also have structured, resource discovery metadata Information that helps potential users find your resource (like in a library catalogue). Create resource discovery metadata for each item (text, image, video …). Create your own structure or use one of the many standards that exist for different subject areas and levels of detail Make sure your resource discovery metadata maps to the Dublin Core standard.

14. Dublin Core 1. Title 2. Creator 3. Subject 4. Description 5. Publisher 6. Contributor 7. Date 8. Type 9. Format 10. Identifier 11. Source 12. Language 13. Relation 14. Coverage 15. Rights

15. Preservation metadata Digital resources are dynamic. Any changes made to the resource over the course of time should be documented: Nature of change made Who made the change? Date Outcome

16. Preservation links Several initiatives have been developing frameworks for Preservation Metadata – OCLC/RLG http://www.oclc.org/research/pmwg/pm_ framework.pdfhttp://www.oclc.org/research/pmwg/pm_ framework.pdf –CEDARS (Leeds University) http://www.leeds.ac.uk/cedars/ –PADI (National Library of Australia) http://www.nla.gov.au/padi/ –NEDLIB http://www.kb.nl/coop/nedlib/results/D4. 2/D4.2.htm

17. Who should document the resource? An archive, such as the AHDS cannot provide supporting documentation. Only the original creator can do that. Retrieving lost information is VERY costly, VERY time-consuming, and often NOT POSSIBLE.