 Hi, my name is Jacob Jett and I'll be giving you a brief overview of the work technical workflows that underlie the MLS DCC aggregation. More information about these workflows can be found in the appendix to this presentation. Our aggregation can be thought of having two major parts, a registry and a repository. Every collection we add gets a collection record and registry. For those collections that also provide harvestable item metadata, item records are added to an integrated item metadata repository. Thumbnail images of items are separately harvested for use in our interfaces. The aggregation is used to feed content to a few different thematically focused portals. The DPLA prototype is one such portal to aggregation's content. Adding a collection to the collection registry involves several steps which are mostly manual and are detailed in the appendix. We start with an assessment of a collection and its items. It doesn't meet our collection development policy. Will the collection fill thematic gaps, build on existing strengths, or otherwise complement and enrich the existing aggregate? If so, we start with a sub-record in our staging database. We assist collection administrators in fleshing each stub out to accurately and adequately describe the collection. Once the administrators are satisfied with the quality of the collection record, we make the collection record public. If a collection's items are harvestable via the Open Archives Initiative Protocol for Metadata Harvesting, OAIPMH. We add them to our automated harvesting workflow. Once harvested into our file system, we then take the records and filter and augment them. We filter out those records with on-cut metadata that would impede search or display in the aggregation, or those records with out-of-date information like broken links. We use automated processes to normalize certain values where possible and suppress empty or misused elements. Once augmented, we then rely on another automated process to index the records into our item repository and link them to collection records in the registry. Meanwhile, an automated script parses OIA identifiers from the harvested records and uses those identifiers to gather thumbnail images for each item, which will in turn be used by the portal's displays. While these processes work fairly well for our aggregation, they're not perfect. The creation of collection-level records is time-consuming, requiring a review process with a host institution that can take weeks of back-and-forth communications. Data normalization is also labor-intensive because raw metadata is heterogeneous and often not truly interoperable, partially due to the lack of any usage of standard vocabularies. Metadata with missing or misused elements needs to be manually assessed for filtering. Further, OIA data providers cease to exist or change their repository's URLs, preventing fresh data sets from being harvested. Some OIA data providers also fail to make use of the optional sets parameter of OIA, which can complicate things by making it hard to associate items with distinct collections. It also takes a great deal of time to rebuild our repository database collections table, each time we would synchronize our item in repository with the collection registry. This is done as infrequently as possible to avoid service disruptions. Finally, harvesting thumbnail images take significantly longer than harvesting metadata records. While it might only take several hours to harvest 100,000 metadata records from OIA data provider, depending on the type of images to be captured in web services to target site, it can often take days or weeks to harvest thumbnail images for those item records.