University of Rochester eXtensible Catalog Project

University of Rochester eXtensible Catalog Project

HUB Deliverables

OAI server

• 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.

OAI harvester

• 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.

OAI testing service

• 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.

Services Registry (includes db and admin interface)

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.

Reassembly (Mudball)

====

Service Orchestration (ping, ordering, notification)

• 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.

---

User Roles

[

Human Actors

• System Administrator
  • Overall system administrator. Responsible for system-level software and hardware maintenance

• HUB Manager
  • One or more persons responsible for the administrative tasks involved in the management of a HUB instance
  • Authorizations: Service Administrator for all registered Services Editor for all Collections and Metadata [not sure about this one]
  • Only role authorized to Delete Services, Users, and Collections

• Service Administrator
  • One or more persons authorized to maintain one or more Service records. The user who registers a Service becomes the Service Administrator for that Service
  • Authorizations:
    • Service Administrator for all Services owned by that Agent
    • Edit/Delete Service Records
    • Designate other Registered Users as Service Contacts
    • Register Contacts and designate them as: Service Administrators for that Agent or Technical Contacts for that Agent

• Service Primary Contact
  • One or more persons acting on behalf of a Service, to whom notifications to the Service may be sent.
  • Domain of email address must match the domain registered to that Service

• Service Technical Contact
  • One or more persons acting on behalf of a service, to whom technical notifications to the Service may be sent.

• Registered User
  • A Visitor who has registered himself/herself for the purpose of registering an organization or vocabulary. A Registered User may assume an additional role while registering an organization or service. **[

HUB Use Cases

---

Archive Page