iFLAME?

ICPSR's project to stand up a repository system continues to move along, but slowly. 

Some of this is due to changes in staffing; for example, our colleague Nancy McGovern has joined the team at MIT, and is now Head, Curation and Preservation Services at MIT Libraries.

Some of this is due to people getting busy with their day jobs at ICPSR and finding less opportunity to discuss requirements for the project, or to work through existing lists to ensure that they make sense.

And a big part is due to changes on my team.  We lost four people to a retirement incentive opportunity, and a pair of new Gates Foundations project created a demand for the equivalent of over three full-time positions, and so this is a net swing of seven people.  It's hard to sustain effort on projects with that level of change.

One of my colleagues dropped by earlier this week to relate a metaphor for FLAME (the File Level Archival Management Engine).  She likened the current ICPSR content environment to be like the world of LPs.  The unit of content is the "album" and that is where most of the metadata lives.  At ICPSR our "album" is the "study."

FLAME, however, aims to take the unit of content to the file level, and to collect and store more data at that level.  This is particularly essential in a world where less and less content is a "study" and where good preservation practices call for collecting and retaining information at the file level.

To continue Laurie's metaphor, she described the move to FLAME as similar to the move Apple made in music with iTunes.  That is, the unit of content is now the song rather than the album.  I really like this metaphor, and I think it captures the issues well.

For example, if one is capturing metadata at the song level, one will still want to group songs into different lists: albums, playlists, etc.  And one may want to edit group-level metadata for a list of songs that is arbitrarily large, and to do so without editing lots and lots of songs individually.  And so on.