Geo-Metadaten und GDI: Unterschied zwischen den Versionen

Aktuelle Version vom 19. Oktober 2008, 12:08 Uhr

Dieser Artikel ist noch 'Work in Progress'...

Überblick

Geo-Metadaten dokumentieren Geodaten und Geo-Webservices. Geo-Metadaten ermöglichen den Zugang zu Geoinformationen und bilden daher eine wichtige Komponente einer (Nationalen) Geodaten-Infrastruktur (GDI).

Es gibt folgende Beteiligte, bzw. 'Rollen':

 1. Benutzer/Anwender
 2. Datenanbieter 
 3. Verarbeitungs-Anbieter
 4. Metadatenanbieter ('Kataloge')
 5. Index(-Dienste), automatisch oder von Hand
 6. Suche(-Dienste), Index-Abfrage 

So kommen Benutzer/Anwender zu ihren Informationen:

1. (End-)Benutzer suchen Informationen über Daten, bzw. Dienste im allgemeinen Sinne, beispielsweise über Google, über spezialisierte Suchmaschinen und Verzeichnisse oder von ihrem GIS aus.
2. Daten- und Verarbeitungs-Anbieter verwalten Informationen über ihre Daten und Dienste.
3. Metadatenanbieter sind typischerweise gleichzeitig Daten- und Verarbeitungsanbieter oder aber organistorisch eng mit ihnen verbunden.
4. Index-Dienste suchen oder sammeln Informationen über Daten und Dienste automatisch oder von Hand.

Zur Kommunikation unter diesen Beteiligten sind folgende Schnittstellen (= Protokolle und Informationsmodelle) und Komponenten nötig:

• Zwischen Benutzer und Daten gibt es http/ftp und Geo-Webdienste (WMS, WFS, WxS). Zur Verteilung grosser Datenmengen sind auch Filesharing-Protokolle wie BitTorrent denkbar.
• Als Schnittstelle zwischen Index-Diensten (=> Suchmaschinen und Kataloge) werden Metadaten ausgetauscht. Dazu genügt ein 'Sammel'-Protokoll (= harvesting). OAI-PMH ist so eines.

Bemerkungen:

• Wie die Metadaten zwischen Daten-/Serviceanbieter und Katalogen 'synchronisiert' werden, ist noch offen. OGC's CSW und SRU (ISOxxx/Z39.50) sind mögliche Lösungen. Sie repräsentieren aber eine aufwändige, verteilte Online-Suche (ausser es werden Profile erstellt), was sie ungeeignet macht für eine Metadaten-Sammel-Schnittstelle.
• Wie die Daten- und Diensteanbieter ihre Daten und Dienste auffindbar machen, ist ebenso unklar. Die Massnahmen reichen von Registrieren bei Metadatenanbietern bis zu verschiedenen Versuchen mit Hyperlinking (vgl. OSGeodata_Discovery#Autodiscovery).

Szenario eines Geo-Metadaten-Netzwerks

Kataloge und Inventare sind Begriffe und Werkzeuge aus Sicht der Datenherren. Für Benutzer stehen vielmehr bequem auffindbare und möglichst unmittelbar sichtbare Geoinformationen im Vordergrund.

Eine Vision zur verbesserten Zugänglichkeit und Auffindbarkeit von Daten soll daher bei den Benutzern und Anwendern beginnen!

• Benutzer suchen über ein Google-artiges Eingabefeld, allenfalls mit Online-Karte zur räumlichen Eingrenzung oder sie blättern in Verzeichnissen (Directories). Beides nennen wir Suchdienste (Hinweis: Benutzer suchen nicht Dienste per se, sondern Geoinformationen).
• Suchdienste ermöglichen das Auffinden und Entdecken von Georessourcen, d.h. von Geodaten und 'Filter Services'. Diese Suchdienste nennen sich auch (Such-)'Service Provider'. Das können Suchmaschinen, Katalog-Verzeichnisse (Directories) oder Kataloge (Inventare, Registries) selber sein.
• Suchdienste holen ihre Informationen bei den Katalog-Verzeichnissen, den Katalogen oder mittels Suchroboter. Dahinter steckt die Architektur eines Netzwerks.
• Kataloge nennen sich Meta-'Data Service Provider'. Sie bieten 'ihre' Metadaten über verschiedene Schnittstellen an, so dass sie von Katalog-Verzeichnissen, Suchmaschinen und GIS selber abgefragt werden können. Mit OGC's CSW können verteilte Kataloge online angefragt werden, was eine Hierarchie von Katalogen bedingt, welche zudem genau dieselbe Anfragesprache implementiert haben müssen. Für den Austausch mit Suchdiensten genügen einfachere Schnittstellen als z.B. CSW.
• Metadaten verweisen auf die die Geodaten selber - falls diese frei zugänglich sind. Auf Geodaten wird entweder direkt (z.B. ftp) oder mit den entsprechenden 'Data Access Services' (z.B. WMS/WFS) zugegriffen. Es gibt (in Zukunft) auch 'Filter Services' (z.B. OWS); das sind spezielle, eigenständige Geo-Webdienste, wie z.B. Koordinatentransformations-Webdienste.

Eine der offenen Fragen ist nun, was für Metadaten-Schnittstellen geeignet sind. Offensichtlich sind mehrere notwendig: 1. Zwischen GIS-Clients und Suchdiensten 2. zwischen Suchdiensten und Daten-Anbietern, inkl. Katalogen und Katalog-Verzeichnissen und allenfalls 3. zum Austausch unter Katalogen selber (hier v.a. CSW).

Lösungsvorschlag

Ein Lösungsvorschlag zur Realisierung dieser Vision wurde hier vorgestellt und mit einer Geo-Metadata Network Suite teilweise realisiert.

Bemerkungen zu Such-Schnittstellen

Such-'Service Provider' wie z.B. Kataloge könnten ihre Anfragen zur Laufzeit stellen; sie könnten ganze Datenbankanfragen an die 'Data/Filter Service Provider' übertragen und bekämen als Antwort eine Liste von Metadaten ('request/response', 'query protocol'). So etwa ist das Prinzip hinter OGC's CSW Katalogdienste.

Viel einfacher in diesem Fall ist es jedoch, wenn die Suchdienste ihre Informationen - die Metadaten - vorher einsammeln. Man nennt dies auch 'Harvesting' (ernten) oder 'Gathering'. Das HTTP-Protokoll über das Webcrawler Metadaten-XML-Dateien sammeln können, genügt zunächst dafür. Das entspricht der OAI-PMH-Schnittstelle.

Werden Georesourcen selbständig von Suchrobotern aufgespürt, so spricht man vom Holprinzip. Das nennt sich 'Autonomous Data Provider', bzw. 'autodiscovery'. Es ist noch in Diskussion, ob man diesem 'Entdecken' (discovery) nicht nachhelfen muss und ein zusätzliches Protokoll wählen soll, ein sog. 'Harvesting Protocol'. Dieses erlaubt gezielte Anfragen im Stil "Gib mir alle Metadaten, die du hast (seit dem 1.1.2006)".