1. Case History: Library of Congress Audio-Visual Prototyping Project METS Opening Day (2003), Revised For the CUL Metadata Working Group July 22, 2004 Carl Fleischhauer Office of Strategic Initiatives, Library of Congress cfle@loc.gov

2. The AV Project Preservation, sense one: reformatting into digital-file form Preservation, sense two: sustaining digital objects Participation by Motion Picture, Broadcasting, and Recorded Sound Division (M/B/RS) and the American Folklife Center

3. Reformatting Documentation About the source –original disc or tape being reformatted – About the process –how the copy file was made, what devices/tools – About the outcome –characteristics and features of the copy file –

4. Diagram of Extension Schemas See also: http://lcweb.loc.gov/rr/mopic/avprot/metsmenu2.html descriptive metadata MODSstandard as maintained by LC technical metadata audio (file) metadatarolled our own, using data dictionary from AES image (file) metadatastandard as maintained by LC, data dictionary from NISO rights and access mgt metadata access “category” metadatarolled our own, just tracking categories source metadata audio (source) metadatasame schema as AMD above image (source) metadatasame schema as MIX above digital provenance metadata digital provenance metadatarolled our own, data dictionary from AES, with some simplifications behavior section did not usewill METS profiles play this role? file group (inventory) from METS proper structural map from METS proper

5. PRODUCERSPRODUCERS ADMINISTRATION DATA MANAGEMENT ARCHIVAL STORAGE INGEST ACCESS CONSUMERSCONSUMERS PRESERVATION PLANNING Reference Model for an Open Archival Information System (OAIS) SIPs (Submission Information Packages) will be produced by the AV preservation activity, ready to submit to LC’s future digital repository.

7. AV Project Web Site Home Page http://lcweb.loc.gov/rr/mopic/avprot/

8. AV Project Extension Schema Page http://lcweb.loc.gov/rr/mopic/avprot/metsmenu2.html

9. AV Project Initial Data Capture System MS-Access Database - Collation Input Screen

10. Top level: work Second level: sound recordings Third level: disc sides Fourth level: cuts

11. Recorded Sound Processing Section Content selected for reformatting 1. Initial creation or copying-in of metadata Workflow Sidebar

12. Recorded Sound Processing Section Content selected for reformatting 1. Initial creation or copying-in of metadata LC Recording Lab or offsite contractor Scanning activity 2. Creation of second layer of metadata Workflow Sidebar

13. Recorded Sound Processing Section Content selected for reformatting 1. Initial creation or copying-in of metadata LC Recording Lab or offsite contractor Scanning activity 2. Creation of second layer of metadata 3. Return loop to processing, edit and possible addition of third layer of metadata Workflow Sidebar

14. The AV METS System Today

15. OUTCOME ONE: A VIRTUAL DIGITAL OBJECT (SIP) Logical storage structure based in a UNIX filesystem master -- family of logical directories where the master files are stored (there is a parallel set of “service” directories) afc -- “owner” is the American Folklife Center afc1941001 -- group or aggregate of items, often from an actual collection sr05 -- item directory (at the level of the digital object, counterpart to a bib record or “line” in a finding aid) sr05am.wav -- the master file for side A of this disc sr05am.wav -- the master file for side B of this disc Index of master/afc/afc1941001/sr05

16. OUTCOME ONE: VIRTUAL DIGITAL OBJECT The fileGrp segment of a METS instance “binds” the object Includes logical pathnames for files, future switch to persistent names possible.

17. OUTCOME 2: PRESENTATION OF OBJECT Presentation in Browser

18. Zoom on Image in Presentation

19. Interim username/password access management

20. In the Presentation: Metadata Map for the Dedicated

21. sourceMD data from the Metadata Map Extension schema content displayed as name-value pairs

22. Generator takes data from the database and makes METS XML

23. Snapshot of the database back end

24. Selection from the database diagram: tables for METS id, agent information, and structMap data

25. Selection from the database diagram: tables for extension schema data for image source, video source, and audio source

26. Selection from the database diagram: tables for digiProv (“digitization process”) information

27. Builder: the data-entry front end to the database

28. Builder: template making tool

29. Builder: tool to shape a structMap using indent, outdent, up, and down. May be used in both template and individual object modes.

30. “Cut wizard” – a twenty more like this one tool

31. Part of MODS descriptive data for a recorded interview with a former enslaved person.

32. File Association Tool

33. Tool to append a MODS record

34. Two samples from the MODS entry and editing tool. + repeats the section x and – delete sections or subsections

35. Selection from the online data dictionary

36. Some METS objects, by title

37. Administration Tool Menu

38. Example of data entry screen Blue terms are used to select separate data entry screens

39. Some Shortcomings Cumbersome data entry – many screens, many actions Bugs – hard to get them all fixed now that the contractor is gone Best if users understand METS and the structMap – barrier to entry for new team members Does not include tools for bulk compilation from pre-existing data

41. Distributed Data Entry Each team enters its own data in less cumbersome “local” tools Tool for descriptive data, especially copying in and out of the ILS Tool for data about the source item and certain technical aspects, copied in and out of MAVIS Tool for digiProv data, “the engineers’ form” Tool or a MAVIS extension to encode the structMap

42. Supporting Tools Approach being discussed –Dispersed tools produce XML outputs –Centralized tool gathers and compiles the various XML data units into a METS instance –Downstream facility to manage the METS XML documents

43. Supporting Concept METS profiles –LC implementation in early development by Morgan Cundiff Rationale –METS is very flexible, need to narrow use within an organization or community –Profiles establish limits that make for more efficient tool-building and more efficient work –Profile-governed objects will enhance interoperability between repositories

44. METS Profile for “simple phonodisc” Relatively simple object but profile with some detail May evolve into a more general profile for a wider range of phonodiscs For now: agnostic about administrative metadata

45. Show examples

46. METS Profile for “simple phonodisc” Limit to discs partly for management of semantics Apply judgment to find the right point between specific and general –not much experience yet History of reformatting may inhibit our imagination – we still are using terms that fit the source object and not the digital object