Conceptual Framework

From Metadata-Registry
Revision as of 06:57, 25 October 2005 by Diane (Talk | contribs)

Jump to: navigation, search

Metadata Repository Conceptual Framework

[Note: This section will be fixed to include: overall picture of an MMS, OAI-glue, underlying repository interacting with other data stores, harvest-shred-recompilation of metadata taking advantage of other services, etc. Individual components will be moved to compontents and functionality section]

There is an Architecture/Philosophy at work that forms the basis of the following framework:

  1. A Provider/Management service provides a user interface and a data storage space for providers to register their OAI servers with the aggregator, supply and maintain data necessary to the HarvestService, and provide metadata describing their service. This service creates two XML document types for further processing:
    • HarvestTrigger documents that contain all information necessary to initiate an OAI harvest from a metadata provider.
    • CollectionRecord documents that contain descriptive metadata about a collection of metadata being provided by a metadata provider.
  2. A HarvestService that processes incoming HarvestTrigger documents in order to initiate an OAI harvest and then optionally further processes the resulting harvested documents. The HarvestService utilizes the concept of WatchedFolders and an extensible ProcessingHarness. HarvestTrigger documents may arrive in the WatchedFolders from many sources via many methods and will be processed as long as they contain a valid set of instructions. This service produces the following documents for further processing:
    • HarvestMerge documents that contain information from the HarvestTrigger document that initiated the harvest and may also contain the results of combining all metadata documents created by the OAI harvest process.
    • Emailed server and metadata validation responses may also be optionally produced
  3. A MetadataCrosswalk service processes incoming HarvestMerge documents to create the desired metadata format. This is most likely a qualified Dublin Core metadata format created and maintained for use by an assortment of services. By default, the desired QDC is created from the required oai_dc metadata format that must be provided by every OAI-PMH server, but it may also be crosswalked from any other "native" metadata format. The MetadataCrosswalk service:
    • validates the base utility of incoming metadata and either accepts or rejects it
    • utilizes "safe" XSLT transforms to correct minor imperfections where possible
    • utilizes either custom or default XSLT transforms provided by a MetadataQA service to create the desired QDC
    • produces as output a DbInsert document that is used by the MetadataIngest service of the Metadata Repository
  4. A MetadataQA service that produces provider-specific crosswalks in the form of XSLT scripts to create high quality QDC metadata from selected native metadata.
  5. MetadataIngest service that further validates and parses DbInsert documents and inserts the processed metadata into the Metadata Repository

The Metadata Repository stores all provided native metadata formats and QDC in an object/relational layer. From this layer, internal processes create static XML documents for use in efficiently serving metadata in multiple formats via OAI.