Do Less More Often Trevor Owens, Digital Archivist, The Library of Congress [email protected] @tjowens an approach to digital strategy for cultural heritage organizations
Jan 15, 2015
Do Less More Often
Trevor Owens, Digital Archivist,
The Library of Congress
@tjowens
an approach to
digital strategy for
cultural heritage
organizations
just one digital archivist’s
perspective… not The
Library’s
A cultural heritage digital strategy needs to
be about exhibition, discovery, access,
description, processing & preservation
4
For example
Software should do less: Serve particular purposes
Metadata formats and schemas should do less, and serve
local needs
We should be doing as little as possible before making
digital archival collections available to users
We should start implementing and improving on practices to
mitigate risk of data loss (digital preservation)
We should think about how we can serialize as much of our
work as possible to get it out there quicker
5
Why?• This makes our work more sustainable: We can swap
out the parts when they are smaller and discrete
• It makes our work more responsive to our users or
our patron’s needs
• Our work becomes more transparent; people can see
what is happening more frequently
• The modularity enables the flexibility to shift work
back and forth between experts, computational
processes, and volunteers and patrons.
1. WiscoHisto: Exhibition/Storytelling
2. NDSA Levels of Digital Preservation
3. MPLP and Born digital Processing
Three stops
[WiscoHisto img]
This is syndicated exhibition
What about preservation?
Sustainability?
Will tumblr be here in 100
years?!
No…
and that’s the wrong
question.
Tumblr is great for
presentation
RSS makes it trivial to keep a
copy
Don’t confuse tools with the
content. It’s the content we
steward.
2. Digital Preservation
So digital preservation…
is there an app for that?
In short, no, nor should there
be.
A piece of software can’t be an
institution.
But that’s not how we think
about software… It’s more like.
I just want to say
one word to you.
Dspace…
ContentDM…
Omeka…
Archivematica…
No! Our plan’s can’t be about
pieces of software
Say no to the idea of software
as swiss army knife
“The Swiss knife (don’t tell the Swiss army) is a bad
can-opener, you can’t even kill a rabbit with the knife,
and worst of all the corkscrew will ruin your fine bottle
of French wine. So always keep it simple, solve
problems step by step and stay focused on one
problem at a time. Single purpose tools are good in
what they are designed for, so if there is no direct need
for multiple solutions, stick to single solutions.”
- Bram van der Werf, the Open Planets Foundation
So what should we be doing?
TRAC/TDR has a laundry list
for us.
Overwhelmed? Where to start?
National Digital Stewardship
Alliance is trying to help clarify
where to start.
Prioritizing actions for different
levels of preservation
Level One(Protect your data)
Level Two(Know your data)
Level Three(Monitor your data)
Level Four(Fix your data)
Storage and geographic location
Two complete copies that are not collocated
Three complete copies
At least one copy in a different geographic location
At least one copy in a geographic location with a different disaster threat
All copies in geographic locations with different disaster threats
File Fixity and Data Integrity
Check fixity on ingest if it has been provided with the content
Create fixity info if it wasn’t provided with the content
Check fixity on all ingests
Virus-check high risk content
Check fixity on all transactions
Check fixity of sample files/media at fixed intervals
Maintain logs of fixity info
Ability to detect corrupt data
Virus-check all content
Check fixity of all content at fixed intervals
Ability to replace corrupted data
Information Security
Know who has write, move, and delete authorization to individual files
Restrict who has write, move, and delete authorization to individual files
Maintain logs of who has accessed individual files
Maintain logs of who performed what actions on files, including deletions and preservation actions
Metadata Inventory of content and its storage locationEnsure backup and non-collocation of inventory
Store administrative metadata
Store standard technical and descriptive metadata
Store standard preservation metadata
File Formats
Encourage use of limited set of known and open file formats and codecs
Inventory of file formats in use
Validate files against their file formatsMonitor file format obsolescence threats
Perform format migrations, emulation and similar activities
Technology obsolescence
For data coming in on heterogeneous media (optical disks, hard drives, floppies) get the digital content off the medium and into your storage system.
Document your storage system(s) and storage media what you need to use them
Start an obsolescence monitoring process for your storage system(s) and media
Have a comprehensive plan in place that will keep files and metadata on currently accessible media or systems.
Still overwhelmed, then let’s
just look at level one.
Getting our digital boxes off the
digital floor.
Storage and geographic location
Two complete copies that are not collocated
File Fixity and Data Integrity
Check fixity on ingest if it has been provided with the contentCreate fixity info if it wasn’t provided with the content
Information Security
Know who has write, move, and delete authorization to individual files
Metadata Inventory of content and its storage locationEnsure backup and non-collocation of inventory
File Formats Encourage use of limited set of known and open file formats and codecs
Technology obsolescence
For data coming in on heterogeneous media (optical disks, hard drives, floppies) get the digital content off the medium and into your storage system.
Everybody needs somewhere
to start. Somewhere to work
from.
3. Processing and MPLP
Curatecamp:
Processing
Familiarity with MPLP
“More Product Less
Process”?
More Product, Less Process: Revamping Traditional
Archival Processing, Mark A. Greene and Dennis
Meissner The American Archivist, Vol. 68, No. 2 (Fall -
Winter, 2005), pp. 208-263
I’ll bring in some quotes
from them…
“We need to articulate a new set of arrangement,
preservation, and description guidelines that 1)
expedites getting collection materials into the
hands of users; 2) assures arrangement of
materials adequate to user needs; 3) takes the
minimal steps necessary to physically preserve
collection materials; and 4) describes materials
sufficient to promote use.”
“In other words, it is time to focus on
what we absolutely need to do,
instead of on all the things that we
might do in a world of unbounded
resources.”
Why is this the case?
“we tolerate this situation in part
because our profession awards a
higher priority to serving the
perceived needs of our
collections than to serving the
demonstrated needs of our
constituents.”
The Ideas of MPLP fit quite well with a
maxim of Open Source Software;
Release early and release often
“Release early, release often is a
software development philosophy that emphasizes the
importance of early and frequent releases in creating a tight
feedback loop between developers and testers or users,
contrary to a feature-based release strategy. Advocates argue
that this allows the software development to progress faster,
enables the user to help define what the software will become,
better conforms to the users' requirements for the
software, and ultimately results in higher quality software.
Wikipedia.
So, where does this leave us?
It leaves us, as we were before, in
perpetual beta
Perpetual Beta from Tim O'Reilly
"Users must be treated as co-developers…
The open source dictum, '
release early and release often', in fact has
morphed into an even more radical position,
'the perpetual beta', in which the product is
developed in the open, with new features
slipstreamed in on a monthly, weekly, or even
daily basis.." O'Reilly, Tim (2005-09-30).
"What Is Web 2.0".
Making Museums
into a Perpetual Beta
“the museum is always in flux, incrementally
releasing new versions, refining procedures,
and responding to audience desires.” Nina
Simon, Museum 2.0
http://museumtwo.blogspot.com/2012/10/dreaming-of-perpetual-beta
-making.html
Oct, 17, 2012
History is itself a Perpetual Beta:
“history, like many Web 2.0 applications, is in
a perpetual "beta," or in a constant state of
testing, revision, and improvement.”--Jeremy
Boggs
http://clioweb.org/2006/09/29/history-is/
So, lets do less and free ourselves up to
accomplish more often.
Do Less More Often
Trevor Owens, Digital Archivist,
The Library of Congress
@tjowens
an approach to
digital strategy for
cultural heritage
organizations