Do Less More Often

Trevor Owens, Digital Archivist,

The Library of Congress

trow@loc.gov

@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

trow@loc.gov

@tjowens

an approach to

digital strategy for

cultural heritage

organizations