Geo-Metadaten und GDI: Unterschied zwischen den Versionen

Version vom 3. November 2006, 11:12 Uhr

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

Ueberblick

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

Es gibt folgende Beteiligte, bzw. 'Rollen':

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

So kommen Benutzer/Anwender zu ihren Informationen:

1. Benutzer verwenden Suchdienste um Informationen über Daten, bzw. Datenanbieter und Dienste zu finden.
2. Indexe sammeln Informationen über Daten, Datenanbieter sowie Dienste und Diensteanbieter.
3. Daten- und Diensteanbieter erfassen und publizieren Informationen über ihre Daten und Dienste in ihrem System oder in Katalogen.
4. Benutzer beziehen oder nutzen Daten der Datenanbieter, bzw. Dienste (die ihrerseits auf Daten zurückgreifen).

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

• Als Schnittstelle zwischen Benutzer-Daten dienen http/ftp oder Geo-Webdienste (WMS, WFS, WxS).
• Als Schnittstelle zwischen Suchdiensten und Katalogen 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 unklar. 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)".