The University of Virginia Library has been building digital collections since 1992. We have amassed a large collection that includes a variety of SGML encoded etexts, digital still images, video and audio files, and social science and geographic data sets that are being served to the public from a collection of independent web sites that have very little cross-integration. We began searching in 1998 for a digital library management system that could effectively meet both our current and future digital content needs. Like many other libraries, we initially sought a vertical vendor solution that provided a complete, self-contained package for delivering and managing all digital content needs. Finding nothing available that would meet our needs, we decided to embark on an in-house development effort. Modularity and use of open-system standards is fundamental to our design strategy. Such modularity is essential for future evolution through component replacement. We are convinced that an object-oriented design is most appropriate, allowing us maximum flexibility, scalability and, eventually, interoperability with other repositories. We are also convinced that the Library should be providing tools to our users to give them sophisticated access to our collections and to help them manage their own collections. In the summer of 1999, early in our design process, we discovered a paper about the Flexible Extensible Digital Object Repository Architecture (FEDORA) written by Carl Lagoze and Sandra Payette at Cornell's Digital Library Research Group, describing the architecture that they had designed. FEDORA is a modular architecture built on the principle that interoperability and extensibility is best achieved by the clean separation of data, interfaces, and mechanisms (i.e., executable programs). A FEDORA Repository provides a general-purpose management layer for digital objects. In their simplest form, digital objects are containers that aggregate mime-typed streams of data (e.g., digital images, XML files, metadata), known as datastreams. It should be noted that datastreams can be references to external data - either disseminations of other FEDORA digital objects, or service requests to remote data sources. This capability allows FEDORA digital objects to serve as aggregators and value-added surrogates for existing on-line digital content. In addition to behaving in a generic manner, digital objects must be able to mirror real-world entities by providing access methods that make an object behave in a content-specific manner. For example, a natural behavior for a book would be "Get Table of Contents." FEDORA allows the association of rich and extensible behaviors with digital objects by "plugging in" generic components known as disseminators. Each disseminator aggregates references to: (1) a formally defined behavior interface that defines a set of methods for a particular kind of digital library resource (e.g. a Book interface), (2) an executable mechanism that runs these methods, and (3) the datastreams that the execution mechanism should use to fulfill specific method requests. These interfaces and mechanisms can, themselves, be stored as digital objects, laying the foundation for unlimited extensibility of the architecture. The Digital Library Research and Development group implemented the FEDORA architecture, using an SQL database and a single Java servlet. We implemented a variety of different testbeds, ultimately scale-testing a repository with 10,000,000 objects in it, simulating a very heavy user load, with excellent results. In September of 2001 we received a grant from the Andrew W. Mellon Foundation that will enable the University of Virginia Library, in collaboration with Cornell University, to build a sophisticated digital object repository system based on FEDORA that can be the basis for a variety of information management schemes. We will form two teams to carry out this project. First, a development team composed of people from Virginia and Cornell that will pursue a three-phase project with the goal of producing an open-source reference implementation, which will be available to other libraries and practitioners as they construct digital library systems. The first phase involves taking a strong proof of concept (already done) and producing a package that can be distributed and used in a variety of settings. The later phases will extend system by adding important functions that a sophisticated digital library system needs. The second team will deploy the software package at each of their own sites, using it to deliver testbeds of their own digital resources. That group includes: the Digital Library group at Indiana University; the Humanities Computing group at New York University; the Digital Collections and Archives Department at Tufts University; the Humanities Computing group at Kings College, London; the Refugee Studies Center at Oxford University; and the Motion Picture Broadcasting and Recorded Sound Division at the Library of Congress; and a library/academic computing team from Northwestern University. As the development team started to review the Virginia implementation, we discussed the possibility of building the objects as XML files, then using these files to build the necessary indexes in SQL databases. By doing this we are able to build the management interface against the XML, simplifying that effort, while separating the backend of the repository to make it easy to experiment with other indexing schemes. Ultimately, that should make it easy for us to experiment with a full-XML based repository, which we suspect will allow us to scale up to required levels. As we started to redesign the implementation, we looked at the Metadata Encoding and Transmission Standard (METS) schema to see if it would work for describing the objects. It turned out that most of what we needed to describe a FEDORA object was readily available in METS. The only thing really missing was a way to handle the disseminators that FEDORA uses to give the object behaviors. We made a proposal to the METS working group that resulted in a new top-level section being added for behavioral metadata that will be optional. That section can be used to associate an object with a behavior definition object and a corresponding behavior mechanism object. This presentation will discuss the use of METS to build a variety of different types of FEDORA objects, including the two types of behavior objects.