University of Rochester eXtensible Catalog Project

Must provide a single simple data API designed to support drop-in, plug-in data connectors.
Must support any number of data connectors and can use them to aggregate data from multiple sources into a single feed
Can provide data from specific data sources in response to request for specific collections or metadata formats.

Must be flexible and forgiving in its handling of common metadata validation errors, allowing otherwise invalid multi-record metadata harvests to be processed on an individual record basis, rejecting only records that can't be processed, and logging the results.

Provide a comprehensive remote acceptance test suite that fully tests the functionality of a compatible OAI server.
Provide a set of test data that can be accessed from the remote test suite to ensure that the server is correctly serving a known and correct set of data to compare and isolate data source problems form the server itself.

Service Providers are the organizations and individuals that provide and manage the Services. In view of general preferences to harvest data where it occurs and use human resources only when necessary, we intend to make a first pass at service registration where an OAI server is specified by simply harvesting the data that the server provides in compliance with the OAI-PMH specification. This is the approach used to populate the [http://gita.grainger.uiuc.edu/registry/searchform.asp University of Illinois/Urbana-Champaign OAI Registry.

A single Service Provider may be responsible for one or more Services and the HUB provides the ability for Service Providers to:

identify themselves and their organization
- This includes the OAI server address and sufficient information to allow the OAI Harvester to validate compliance with OAI-PMH and to initiate a harvest.
register organizational, administrative and technical contacts
- Name, role and email address are required. Other kinds of addresses and alternative contact information can be filled in, but are not required. The email address of the primary contact (the person providing the registration) will require validation prior to the registration of additional contacts. A role vocabulary will be provided as a pull down list, but text entry will be allowed as well.
manage the authentication and level of authorization for these individuals within the system
- Default notifications and authorizations based on role will be enabled, but can be overriden by the server admin at the time of registration or during a later login.
register the individual services they're providing
- A service vocabulary and definitions will enable characterization of services at the time of registration. Use of these vocabularies will be required, although additional tagging will be allowed to further develop the vocabularies. Description of the services or links to service descriptions will be required.

Other Notifications:

The HUB Administrator should be notified of new Service Registrations, including when email notifications to registered contacts bounce.
The Service contacts should be notified of the Service Registration, including how to change their settings if they are incorrect.

====

Upon completion of a harvest, error logs are passed to the notification service, and registered Service administrators or technical contacts that have signed up for event notification will receive an email or a notice in their RSS feed.
Technical contacts will have the opportunity to correct or delete the invalid records and schedule an immediate one-time incremental harvest to retrieve them for addition to the MR data store.

Contents