A Portal to Support Claddier

Requirements for a Claddier Portal

To demonstrate the functionality of Claddier, it is useful to be able to put a portal across different archives. The main purpose of this portal is not to be a "front-end" or a primary way of presenting or replacing an archive or a set of archives, but rather to present a common point of search across a set of registered archives.

This portal should:

• be lightweight - a relatively simple component, easy to install and populate. Perhaps as a local server for a research team.
• provide a relatively simple common search across the catalogue records of the registered archives.
• searches should be:
  • based on a small set of common metadata fields (Dublin Core).
  • allow domain classification search using controlled vocabulary (adaptable to the system used).
  • allow simple text searching across catalogue fields.

The portal should redirect visitors quickly to the archive for more detailed metadata investigation and access to the resource itself.

The portal could:

• Harvest records in advance and search across a local cache.
  • Advantages: quick local search on known availability; can harvest records in own time.
  • Disadvantages: information may not be current; large ammount of local storage required.

or:

• Distribute query for real time search.
  • Advantages: current information; local memory usage relatively low;
  • Disadvantages: network latency and archive availability affects search performance; complex joins can be difficult to distribute and manage.

For practical reasons, the harvesting approach is the one proposed in Claddier. OAI-PMH forms an existing standard protocol for metadata harvesting, with Dublin Core as a common metadata set. The participating repositories in Claddier have OAI-PMH interfaces already.

[WE NEED TO DETAIL THE OAI-PMH INTERFACES OF THE REPOSITORIES IN CLADDIER]

Overall Architecture

The overall architecture of the Portal is given in Figure 1, where a set of three data archives and two publication archives are linked via one portal.

Figure 1: Overall Portal Architecture

This architecture diagram proposes web services as the mechanism to link the components together; with OAI-PMH being the primary mechanism, it is not certain that that would be the best approach. This may add an unnecessary level of complexity and for the first prototype, we will use a REST approach.