C-1.5 Mixed Model


Cite Permalink:
1
This model is a mixture of the multiple schemas aggregation model and the linked data model. There is a central aggregator, with a common metadata schema guideline defined. Each of the content owners provides their metadata in their existing format together with their schema. The aggregator creates links between the schemas and metadata using linked data. An example of this is an aggregation project of the Communauté française de Belgique called PEPS, currently in pilot stage.
Cite Permalink:
2
Figure C5: Mixed Model
Figure C5: Mixed Model
Cite Permalink:
3
Many other variations on the mixed model exist, with more or less focus on harmonisation of the central schema.
Cite Permalink:
4
The main advantages and disadvantages of this approach are summarised in the following table.
Cite Permalink:
5
Advantages Disadvantages
  • Extended schema based on collections own schema means fields are more likely to be complete.
  • Little information is lost as the collection shares all metadata that it wants to.
  • Fast retrieval of metadata from common schema metadata store.
  • Comparison of items and connection between items is straightforward.
  • 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.
  • Not all collections are technically capable of providing metadata in the OAI-PMH format.
  • Harvesting protocols are not always implemented consistently across collections.
  • Collections must provide metadata to satisfy other aggregators, e.g. Europeana, MICHAEL and Athena.
  • Significant manual effort to harmonise terms.
  • Example is in pilot; not yet a well-proven approach.
Cite Permalink:
6

C-1.1.1 Note on the PEPS pilot project of the Communauté française de Belgique

Cite Permalink:
7
The pilot PEPS project is based on the premise that they don’t ask the institutions to change their way of managing and documenting their collections and they assume that the institutions have their own web site presenting them, their collections and each asset in their collection. The harvesting is through standard OAI-PMH but is defined explicitly in a document called the Harvesting Agreement (one per collection) split into two blocks:
Cite Permalink:
8
  1. The metadata applicable to each of the assets of the collection (cataloguing the Cultural or Scientific asset) according to:
    • A selection of the metadata terms as defined and used within the institution.
    • The metadata terms as required for Europeana.
    • The metadata terms as required for Athena.
Cite Permalink:
9
All these metadata terms are linked by typed alias statements whenever applicable.
Cite Permalink:
10
  1. The CONTEXTS values applicable to the domain covered by the collection (each name instance is described by a small IT record card). List of names of instances of:
    • Physical persons.
    • Moral persons / Institutions / Organisations / Enterprises.
    • Periods.
    • Places.
    • Events.
Cite Permalink:
11
The Aggregation project team is undertaking the harmonisation task, which produces one Aggregation Agreement which contains harmonisation of:
Cite Permalink:
12
  1. The description of the institutions and of the collections.
  2. The names of some of the terms covering identical/similar things between the collections (expressed as typed alias).
  3. The instances of metadata (e.g. W.A. Mozart; Mozart; Wolfgang Amadeus Mozart) (expressed as typed alias).
  4. The names of the instances of each class of context (expressed as typed alias).
Cite Permalink:
13
The intention is to use a Semantic definition tool in such a way that the Harvesting Agreements and the Aggregation Agreement will be expressed in OWL, implemented on a simple RDF triples database and will include the alias. The aggregator will then exploit the harvested metadata and the Aggregation Agreement to make vertical (within a collection) and horizontal (context dependent between the collections) queries and other applications. At any moment, the users of the aggregator could click to be re-linked to the applicable item, within the Web services dedicated to the collection in the owner or deputy of the assets of the collection. The semantic database in this case is a fundamental element of the aggregation, used for the aggregation services to understand and make the link between the way of describing the item in a specific collection and the way of describing it in the view of aggregated services.
Cite Permalink:
14
The migration to a full semantic network of the aggregator will be the subject of the project that would follow PEPs but the approach above ensures a progressive evolution (not revolution). The trick is the mapping onto the classes and instances of authority lists allowed by the aggregation and the harmonisation process.
Cite Permalink:
15
Furthermore, there is also a pilot with three organisations that is aggregating at the resource level, and also controlling security to individual resources at an aggregated level. That is, a user would be authenticated and given links to those resources that they have authority to access.

Total comments on this page:

Comments are closed.