Cache Warming
Title (Goal) | Reduce system load on harvest runs by pre-generating OAI records |
---|---|
Primary Actor | Repository, Harvester |
Scope | Data access |
Level | High |
Story | OAI harvesting runs usually fetch hundreds of records. Generating the OAI output for each record on access time can be costly operation, especially if the process of generating involves multiple queries or generates huge XML documents. This specifically applies to records that are new in the system. It is very likely that these records get harvested soon. The repository should pre-generate OAI output for certain records selected by a cache warm-up strategy, separating record generation from record delivery, so that extensive OAI requests can be served quickly and at low cost. Related to: Multiple Metadata Formats |
HTTP Authentication
Title (Goal) | Support for HTTP authentication and access policies |
---|---|
Primary Actor | Administrator, Harvester |
Scope | Data access |
Level | High |
Story | Repository object information should be made available for harvesting and integration as soon as possible. However, some harvesting clients may have different permissions for downloading records or accessing particular sets. HTTP authentication should provide a OAI-PMH compatible mechanism to restrict access if necessary. |
Dynamic Sets
Title (Goal) | Support for dynamic OAI sets |
---|---|
Primary Actor | Repository Manager, Harvester |
Scope | Data access |
Level | High |
Story | It should be possible to define an OAI set by using Fedora object properties and predicates. Objects that fit to the defined pattern should be disseminated as members of the so defined sets. |
Deleted Record Policy
Title (Goal) | Support for configurable OAI deletion policies |
---|---|
Primary Actor | Repository Manager, Harvester |
Scope | Data access |
Level | High |
Story | OAI specification describes three tracking levels for record deletion: no, persistent and transient. While NO and TRANSIENT do not provide any useful information about deleted records, PERSISTENT explicitly states the deletion of a previously existing record and thus helps to keep a harvesters database update to date. The repository should allow to configure the deletion behavior according to OAI specification. |
Multiple Metadata Formats
Title (Goal) | Support for multiple metadata formats beyond oai_dc |
---|---|
Primary Actor | Repository Manager, Harvester |
Scope | Data access |
Level | High |
Story | The repository is able to store and disseminate multiple XML based metadata formats. This formats should also be accessible in OAI harvesting. Access to some metadata formats may be restricted via HTTP Authentication. |