1
2	"Manager" Manager: Brad Westbrook: UCSD Kelcy Shepherd: Five Colleges The narrator: NYU
3	"http://www.diglib.org/collections/eadmtg1rep.htm" http://www.diglib.org/collections/eadmtg1rep.htm
4	"Partner Repositories" Partner Repositories Refine the inputs and outputs of the software Refine system responses Guide a design structure
5
6
7
8	Full-time staffing range for participating repositories
9	Size range of PRs
10	Types of archives participating
11	EAD Status
12	MARC Status
13	"Development Team" Development Team: Lee Mandell [Programmer/Analyst at Harvard University Library's Office for Information Systems (OIS) for 17 years - helped develop the system known as OLIVIA, a visual materials cataloging system.]
14
15
16	Design Schedule June 2004-August 2005 - Development of design specification. July 2005-Early 2006 - Design of the prototype Early 2006-June 2006 - Testing and refining prototype
17	Use Case Methodology: The "Use Case" methodology is a means of defining the requirements of a system based on the goals of the users of that system. This ensures that the study is focused on the requirements of the users. . . The point of the "use case" approach is that it doesn’t matter what the architecture is because that comes later. The use case are simply a way of defining what people want to achieve. (Digital Rights Management Study Interim Report, 10 June 2004)
18	"Standards" Standards Standards will be imposed on: the structure of the toolkit the various metadata elements of a record.
19	"Input standards" Input standards: International Council On Archives’ ISAD(G): International Standard Archival Description DA:CS (creator, scope notes, biog hist, etc.) MODS, EAD, AMIA, MARC, VRA Core, etc. as a point of reference to guide the content and the extent of the descriptive metadata proposed for descriptive elements.
20	Design Overview
21	Data management not in scope for this design phase: Comprehensive preservation functionality Collection usage data Ingest of most legacy data Technical Metadata for digital objects beyond text and image Robust donor management data
22
23
24	Resource ID The resource ID: a key element
25	Administration/Project Management Levels of access to database Setting repository defaults Setting project parameters Reviewing audit information
26	Accessions No accession records will exist without a resource ID being assigned to it. Many accessions can have the same resource ID. Only one resource ID may be linked to an accession.
27
28	Locations Applied to resource ID Any container can be given a location
29	Subjects and Names Authority tables will exist for a repository’s names and subjects Applicable to accessions and resource descriptions
30
31	Audit Track which user made changes to the database and when. Monitor productivity of users.
32	Resource Description Describe collections down to 12 levels of hierarchy (same as EAD) Link to digital objects or analog derivatives from any resource or resource component in the resource hierarchy Ability to store wide array of data on objects in a collection
33
34	Hierarchical display Resource navigation Entry access Overview of hierarchy
35