HowTo OAI-PMH: Unterschied zwischen den Versionen

Aktuelle Version vom 12. November 2009, 11:05 Uhr

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

Einführung

Der 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.

• Einführung (aus GIS-Blickwinkel): http://gis.hsr.ch/wiki/OAI-PMH
• Homepage mit Community: http://www.openarchives.org/

Konzept

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 Limitationen

OAI-PMH ist einfach, offen für neue Metadatenmodelle, und lose gekoppelt, da es auf dem Harvesting-Prinzip basiert. Als Nachteil kann genannt werden, dass das Harvesting-Prinzip Daten dupliziert und daher Redundanzprobleme erzeugt, die mit Identifiern gelöst werden müssn. OAI-PMH ist zudem in OGC/ISO-Kreisen noch wenig bekannt, bzw. hat dort keine Lobby.

Verbreitung

OAI-PMH ist verbreiteter als 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.

Aufwand

Der Realisierungsaufwand kann aus einschlägiger Erfahrung 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.

Weiterentwicklung

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 .

Hinweise zur Implementierung

• Spezifikation: http://www.openarchives.org/OAI/openarchivesprotocol.html
• Weitere Infos: OAI-PMH#Specifications_and_links_for_implementers
• Tools, insbes. der Explorer/Validator: http://www.openarchives.org/pmh/tools/
• Die wichtigsten zu implementierenden Requests sind Identify, ListMetadataFormats und ListRecords.

GIS-spezifische Tipps und Regelung zum Datenmodell (Schema, basierend auf Dublin Core):

• Es wird nur das (obligatorische) XML-Schema ('oai_dc') implementiert. Siehe Geometa-Editor#Dublin_Core_.C3.A0_la_OAI-PMH.
• metadaten-id: direkter Link zum entspr. Metadaten-Katalog-Eintrag (AGIS) (URL-Typ Computer-Readable-Ressource)
• dc:publisher: kann eine (AGIS) URL (Typ Human Readable Ressource) sein
• dc:type: hat Wert 'dataset'
• dc:relation: direkter Link zu Daten (falls frei/offen), sonst wie metadaten-id (URL-Typ Computer-Readable-Ressource)
• dc:coverage: enthält BBox (WGS84) z.B. 8.34928 47.067242 8.380961 47.084862 gemäss Spezifikation von box auf GeoRSS Simple > Box.
  • Alternative dazu ist dcmi-box.
• dc:date means in fact dct:modified

Zum URL-Typ: Wir unterscheiden zwei Arten von URLs: Computer-Readable- und Human-Readable-Ressources (solche, die vom Browser direkt dargestellt werden können). Wenn nichts anderes angegeben, sind die allfälligen URLs vom URL-Typ Human-Readable-Ressource.

Gallerie

• geometa.info Directory mit 'metadata+webservice' (periodisch aktualisiert)
• "(Meta) Data Provider": http://www.geometa.info/gmdb/oai_pmh_data_provider/
• Bibliotheks-Kataloge:
  • Bekannter Pionier: http://oaister.umdl.umich.edu/o/oaister/
  • Aus der Schweiz: http://www.scientificcommons.org/

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 contents and encoding 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) in WGS-84. 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.

See DClite4G#Guidelines_for_a_minimal_OAI-PMH_implementation for a concrete implementation of this format with examples.

OAI implementations

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