«
»

C-1.1 Common (Standardised) Schema Metadata Aggregation Model


Cite Permalink:
1 This is a model where there is a central aggregator, which has a particular metadata schema defined. Each of the content owners provides metadata in the format of the aggregator schema, which standardises the metadata into a common format. Examples are Europeana and SUNCAT. This is described in the following diagram:
Cite Permalink:
2 Figure C1: Common (Standardised) Schema Metadata Aggregation Model
Figure C1: Common (Standardised) Schema Metadata Aggregation Model
Cite Permalink:
3 Since the source schemas are not identical effort has to be expended to select the fields in the source schema and map them to the target schema.
Cite Permalink:
4 The main advantages and disadvantages of this approach are summarised in the following table.
Cite Permalink:
5
Advantages Disadvantages
  • Simple schema means fields are more likely to be complete.
  • Fast retrieval of metadata from common schema metadata store.
  • Comparison of items and connection between items is straightforward (though limited).
  • Aggregation is kept up to date with frequent updates.
  • Updates require little effort and are very effective when a harvesting protocol such as OAI-PMH is used and the source collections comply with it.
  • Many repositories provide support for harvesting protocols out of the box, so little effort is needed to enable harvesting.
  • Collections do not have to contribute individually to other aggregators such as Europeana, MICHAEL and Athena; this is done on an aggregated basis.
  • Large amounts of information and richness is lost as only a subset of metadata is shared in the common schema.
  • Some metadata are forced into fields they are not natural fits for (if using DC).
  • Not all collections are technically capable of providing metadata in the standardised schema format, or via OAI-PMH.
  • Harvesting protocols are not always implemented consistently across collections.
  • Maintenance is harder: any changes to the standardised schema require effort at every collection to provide updated metadata.
Cite Permalink:
6 This model was discussed during the Metadata Forum at the Repository Fringe and a participant commented that this was ‘not a goer’ due to the difficulty of gaining agreement between all parties.

This entry was posted on Friday, November 5th, 2010 at 3:57 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Total comments on this page:

2 Responses to “C-1.1 Common (Standardised) Schema Metadata Aggregation Model”

Fred Guy says:

(I work at EDINA and am Project Manager for SUNCAT)

SUNCAT is mentioned as an example of this model but we would like to take issue with the first two bullet points as far as SUNCAT is concerned. As SUNCAT accepts almost all of the metadata supplied by the Contributing Library no information is lost and the richness is maintained. There is also no attempt to force data into fields which are not natural fits. The MARC 21 format which is used in SUNCAT and by the majority of SUNCAT Contributing Libraries is a very rich format. In those cases where a Contributing Library has supplied data in some other format all the supplied fields have been mapped to appropriate fields in the MARC 21 format because it is so comprehensive. It is therefore incorrect to associate these disadvantages with SUNCAT which is what the reader would do as the section stands at the moment. The options seem to be to either remove mention of SUNCAT as an example of this particular model or to state explicitly that the disadvantages do not apply to SUNCAT.

Sheila says:

Absolutely, there is no link intended to be inferred: it is recognised that these disadvantages due not apply to SUNCAT due to the use of the standardised MARC21 format.

«
»