HowTo OAI-PMH

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche

Einstieg in OAI-PMH für Geometadaten (deutsch)

Zweck des "Open Archives Initiative - Protocol for Metadata Harvesting" (OAI-PMH): Zugang zu digitalen Ressourcen, inbesondere um wissenschaftliche Publikationen zu erleichtern. Dort etabliert seit 2001.

Die OAI-PMH-Architektur ist offen, dezentral, stabil. Sie arbeitet asynchron, d.h. Suchdienste (u.a. 'Metadaten-Kataloge') sammeln Metadaten von anderen sog. "(Meta) Data-Providern". Offen, weil zwar Dublin Core vorgeschrieben, darüber hinaus aber beliebige erweiterte Strukturen ausgetauscht werden können. Dieses 'Ernten' (engl. harvesting) ist robuster im Betrieb und einfacher zu realisieren als z.B. die bisher von ISO 19000 und OGC verfolgte Technik der direkten Online-Aufrufe. So gibt es z.B. kein Warten auf den Letzten und es ist keine einheitliche Query-Sprache nötig. Die wichtigsten OAI-PMH-Requests (Identify/ListMetadataFormats und ListRecords/GetRecord) sind vergleichbar mit den bekannten zwei WMS-Aufrufen GetCapabilities und GetMap.

Vorteile und Nachteile dieses Protokoll

  • Technische Vorteile: Es ist einfach, offen für neue Metadatenmodelle, und lose gekoppelt, da es auf dem Harvesting-Prinzip basiert.
  • Verbreitung und nicht-technische Vorteile: Es ist verbreiteter alls alle Geo-Metadaten-Standards (da älter), bewährt (Version 2.0) und wird von Google gelesen (vgl. Google Webmaster Tools und sitemals.xml). OAI-PMH ist in der Version 2.2 des Open Source 'GeoNetwork' geplant. Das Protokoll ist für alle GeoShop-Kunden verfügbar und wird z.B. von den Metadaten-Stellen der Kantone Aargau und St.Gallen/Appenzell sowie vom OSGeo Geodata Team geprüft bzw. realisiert.
  • Nachteile: Das Harvesting-Prinzip dupliziert Daten und erzeugt daher Redundanzprobleme, die mit Identifiern gelöst werden können. OAI-PMH ist in OGC/ISO-Kreisen noch wenig bekannt, bzw. hat dort keine Lobby.

Der Realisierungsaufwand kann unserer Erfahrung nach nicht grösser als zwei Tage sein(!), gegeben, dass eine Metadatenbank und ein Webserver bereits existieren. Zur zusätzlichen Sicherheit kann vereinbart werden, dass der Aufruf eines OAI-PMH-Harvesters/Webcrawlers (wie z.B. geometa.info) über eine fixe IP-Adresse erfolgt.

Nachdem erste Metadaten ausgetauscht worden sind, realisieren viele, dass deren Inhalt noch etwas detaillierter zu klären ist. So gilt es z.B. auf Seiten eines Suchdienstes, Doubletten zu erkennen, was die Forderung eines geregelten dc:identifier's nach sich zieht. Optimalerweise sollte dieser zudem ein mind. für die Fachgemeinschaft eindeutige und stabile URL sein, wie hier: http://urlx.org/geometa.info/0363d .

Demos und Einführung:

Über OAI-PMH:

Hinweise zur Implementierung:

GIS-spezifische Tipps und Regelungen:

  • Es wird nur das (obligatorische) XML-Schema ('oai_dc') implementiert.
  • metadaten-id: direkter Link zum entspr. Metadaten-Katalog-Eintrag (AGIS)
  • dc:publisher: kann eine (AGIS) URL sein
  • dc:type: hat Wert 'data'
  • dc:relation: direkter Link zu Daten (falls frei/offen), sonst wie metadaten-id
  • dc:coverage: enthält BBox (WGS84) z.B. 8.34928 47.067242 8.380961 47.084862

HowTo implement OAI-PMH

  • 1. Join the community: Register to the 'OAI Implementers list' at the official OAI Homepage
  • 2. Read the spec.: The Harvesting Protocol (version 2.0) specification together with Implementation Guidelines
  • 3. Look at existing tools, rated above.
  • 4. Implement functions: Most important operations (called 'verbs') are Identify, ListMetadataFormats, ListRecords and GetRecord, perhaps initially without incremental harvesting (resumption process).
  • 5. Implement mapping: of your internal data model to DC model elements. See also the special meaning of certain elements like dc:coverage, as explained below.
  • 6. Test it: with the The official OAI Repository Explorer.
  • 7. Extend it: eventually with specific metadata models and respective XML formats.

Minimal OAI-PMH data provider implementation

Following are more specific guidelines for a minimal OAI-PMH implementation of a so called 'data provider' using only the mandatory 'unqualified' Dublin Core (DC):

  • Only three operations (verbs) are needed: Identify, ListMetadataFormats and ListRecords.
  • Following operations are not required (initially): ListIdentifiers, ListSets, GetRecord.
  • No incremental harvesting (resumption process for ListXxx operations with more than 1000 records)
  • No compression as defined in the OAI-PMH spec. (compression at lower http level still possible)
  • Date granularity may be 'day' not seconds (YYYY-MM-DD)
  • Keeping track of deleted records may not be supported (deletedRecord=no)
  • The default data model supported is Dublin Core but this still needs some decisions and explanations (as shown below)

Dublin Core with considerations for GIS

Mandatory Dublin Core (DC) supported as data model is sufficient for a start but with specific semantics (e.g. coverage, relation) (see also example below):

  • dc:identifier is to be specified to reduce redundancy problems (doublettes)
  • dc:description contains dct:abstract
  • dc:coverage
    • contains a lat/lon bounding box encoding as defined in http://georss.org/simple.html#Box (minx, miny, maxx, maxy: dc:coverage example for a Swiss Canton: 7.30676 47.0585 8.10371 47.5371).
    • Alternatives are either "<dc:coverage>(BBox: 702.751,236.711,708.663,232.784)</dc:coverage>" or as defined in dcmi-box.
  • dc:date means in fact dct:modified
  • dc:relation (if available) is filled in with dclite4g:onLineSrc. If dc:type='service' dct:hasPart can be derived from GetCapabilities.

OAI implementations

  • Geometa-Editor
  • GeoShop, Fa. infoGrips GmbH, Zurich, Switzerland (C, Java)
  • GeoNetwork, open source, rel. 2.2 (GPL, Java)