Geo-Metadaten: Unterschied zwischen den Versionen

Aus Geoinformation HSR
Wechseln zu: Navigation, Suche
(→‎Geo-Metadaten-Applikationen)
Zeile 16: Zeile 16:
 
** [http://geometa.info geometa.info-Suchdienst], die Geo-Suchmaschine, und [http://geometa.info/directory/tags.php/metadaten geometa Directory], das frei such- und erweiterbare Linkverzeichnis.
 
** [http://geometa.info geometa.info-Suchdienst], die Geo-Suchmaschine, und [http://geometa.info/directory/tags.php/metadaten geometa Directory], das frei such- und erweiterbare Linkverzeichnis.
  
−
Weitere Software siehe unten.
+
Weitere Software-Werkzeuge (Tools) siehe unten.
  
 
== Stand heute ==
 
== Stand heute ==

Version vom 16. September 2007, 16:00 Uhr

Metadaten können definiert werden als Daten, die eine oder mehrere Ressourcen beschreiben oder als Daten, die mit einem Objekt verbunden sind und dieses Objekt beschreiben. Prinzipiell stellen Metadaten eine Beschreibung von Dokumenten, (physischen) Objekten oder Diensten dar und enthalten Informationen zu deren Inhalt, Format, Raum- und Zeitbezug, Herkunft, etc.. Etwas abstrakter formuliert sind Metadaten Beschreibungen von Daten bzw. "Daten über Daten".

Katalogeinträge in Bibliotheken oder eben Geodaten und Geodienste können als eine Form von Metadaten gesehen werden. Als Grundlage für die Metadaten soll das aus fünfzehn Basiselementen bestehende Dublin Core Metadata Element Set (kurz Dublin Core bzw. DC) dienen. Dublin Core ist das Ergebnis internationaler Bemühungen, einen gemeinsamen Konsens bei der Beschreibung elektronischer Objekte (im weitesten Sinne) zu finden.


Geo-Metadaten-Applikationen

Geo-Metadaten-Suchportale (Discovery Services und Harvesteres):

Weitere Software-Werkzeuge (Tools) siehe unten.

Stand heute

Metadaten sind der Schlüssel zur Zugänglichkeit und Auffindbarkeit von Daten! Das heisst, dass Geo-Metadaten eine der wichtigsten und ersten Komponenten einer Geodaten-Infrastruktur (GDI) sind. Viele Gründe sprechen auch für die Förderung der Geodaten-Erfassung und Geodaten-Suche innerhalb einer Organistation (siehe dazu auch die Diskussionsseite).

Heute, 2006, muss festgestellt werden, dass aus Anwender-Sicht ein unbefriedigender Zustand herrscht. Das Hauptproblem ist dabei nicht unbedingt bei den (Web-)Applikationen zu suchen, sondern eher einerseits bei der fehlenden Benutzersicht aktueller Realisierungen und Standards und andererseits beim fehlenden gemeinsamen Verständnis über eine gemeinsame GDI-Architektur d.h. über die Zusammenhänge von Prozessen, Geodaten, Metadaten, Webservices und Applikationen.

In Deutschland und der Schweiz haben sich schon verschiedene Stellen mit Geo-Metadaten befasst, vgl. dazu das Kapitel oben. Dazu kommen wie e-geo.ch und INSPIRE.

Wenn es um Standards geht, werden immer wieder ISO und OGC zitiert: Mit ISO 19115 gibt es ein Datenmodell für Geodaten (ohne Geoservices) und mit OGC's CSW 2.0 (ebRIM) wird zurzeit ein Profil diskutiert. Als Vorlage für organisations-interne Kataloge und aufwändige Dienste mögen diese beiden Spezifikationen genügen, doch beides geht in Richtung noch komplizierteren und noch umfangreicheren Spezifikationen.

Zum Zwecke der Dokumentation und zur besseren Verbreitung von Geodaten schlägt die 'OSGeo Geodata Discovery Working Group' ein möglichst einfaches Geometadaten-Austausch-Modell vor zusammen mit einem bestehenden leichtgewichtigen Austausch-Protokoll, namens OAI-PMH 2 (siehe weiter unten). Mit dem Editier-Katalog GMDB und der Geodaten-Suchmaschine geometa.info haben wir vom GISpunkt HSR schon einige Erfahrung auf diesem Gebiet (zu Software siehe Weblinks).

Vision zu Geo-Metadaten und GDI

Geodaten-Infrastrukturen (GDI) gründen u.a. auf Geo-Metadaten. Diesem Thema ist daher eine eigene Vision zu Geo-Metadaten und GDI gewidmet.

Dort wird v.a. auch auf die Beteiligten und ihre Rollen im Zusammenhang mit Geo-Metadaten innerhalb einer GDI hingewiesen, nämlich Benutzer, Datenanbieter, Verarbeitungs-Anbieter, Metadatenanbieter (Kataloge) sowie Index(-Dienste, Directories) und Suche(-Dienste). Eine Erkenntnis daraus ist, dass es nicht einen weltweit einzigen Suchdienst für Geo-Metadaten geben wird, sondern mehrere, die über ein Geo-Metadaten-Netzwerk vernetzt sind.

Passend dazu bieten wir unten einen Lösungsvorschlag dazu an zusammen mit einem Aufruf zur raschen Publizierung von Geo-Metadaten!

  • Die Benutzer benötigen Suchdienste zum einfachen Auffinden von Geoinformationen... und zwar sowohl unbekannter aber auch ihrer eigenen - oft teilweise nur im Intranet zugänglichen - Geodaten.
  • Die Geodaten-Provider brauchen brauchbare Geo-Metadaten-Verwaltungs-Werkzeuge... mit einem Geo-Metadaten-Verwaltungs-Modell und Mechanismen zur leichten Erfassung in Synchronisation mit den eigentlichen Geodaten.
  • Geo-Datenherren, Geo-Metadaten-Katalog- und Suchdienste-Provider benötigen
    • ein Geo-Metadaten-Austausch-Modell mit Encoding (z.B. XML) und ein
    • Protokoll dazu für den Austausch und die Verteilung der Geo-Metadaten.

Zu alledem versuchen wir nachfolgend Lösungsansätze anzugeben.

Metadaten-Netzwerk und der Beitrag der HSR

Der Beitrag der HSR zur GDI-Vision besteht aus dem Katalog-Verzeichnis Geometa-Directory (demnächst) als Implementation des Dublin Core light for Geo (DClite4G), der quell-offenen Geo-Metadatenbank (GMDB) und schliesslich in der geometa.info-Suchmaschine.

Lösungsvorschlag

Generell empfehlen wir Geo-Metadaten schnell zugänglich zu machen! Das bedingt, dass Metadaten intern rasch erfasst werden und dass Schnittstellen für den Austausch rasch bereitgestellt werden.

Das absolute Minimum ist der Dublin Core (DC), mit dem man bereits z.B. BBoxen und Schlüsselworte und natürlich Links auf die eigene Seite zurück auszutauschen kann. Der Aufwand dies zu realisieren ist minimal. Das funktioniert dann praktisch gleich wie hier

Jo Walsh von OSGeo.org geht einen Schritt weiter und überlegte sich was die wichtigsten Konzepte sind: siehe [1] und DClite4G (hier fehlt noch das Encoding).

Beides, DC und DClite4G, sind Untermengen, bzw. Vorstufen von ISO 19115.

Wir wollen darauf hinweisen, dass zwei Geo-Metadaten-Modell-Arten benötigt werden: Eines für den Austausch (vgl. "Metadata Exchange Protocol" in Skizze unten) und eines für die 'interne' Verwaltung und allfällige Dokumentation, Ausstausch und Backup (vgl. "Internal Metadata Exchange" in Skizze unten). Das Geo-Metadaten-Modell für den Austausch muss dringend diskutiert und genormt werden, mehr noch als andere, da davon sowohl Software für die Metadaten-Verwaltung (Kataloge) wie auch für Suchdienste profitieren.

Folgende Regeln, Aussagen und Massnahmen sind unserer Ansicht nach wichtig:

  1. Geo-Metadaten-Verwaltungs-Modell: Dieses ist das Wichtigste für Daten-Provider. Die dazugehörigen Daten und Software werden Katalog oder Inventar genannt. Es kann organisations-intern vereinbart werden wobei ISO 19115/119 (und Profile wie GM03-Core) als Vorlage dienen. Der Zeitpunkt kann selbst bestimmt werden. Um keine Zeit zu verlieren soll jetzt schon Schnittstellen-SW vorgesehen werden.
  2. Geo-Metadaten-Austausch-Modell: Dieses ist das wichtigste Modell für die Verbreitung und Entdeckung von Geodaten. Als Software, welche dieses implementiert wird es einerseits 'Discovery Portale' (Suchmaschine mit Webcrawler/Harvester) und andererseits sog. Kataloge oder (Meta)Data Provider geben. Als Vorlage gilt Dublin Core und ISO 19115/119 (und entspr. Profile wie GM03). Dieses muss aber vereinfacht werden (vgl. 'Fragen und Antworten' unten).
  3. Codierung des Geo-Metadaten-Austausch-Modells: Als Codierung gilt in der Schweiz z.Zt. das GM03/XML, ansonsten gibt es allgemeines XML/RDF.
  4. Geo-Metadaten-Werkzeuge/-Editoren: Webapplikationen und GIS-Desktop-spezifische Editoren werden koexistieren. Wichtig ist die Trennung in Software für die Verwaltung von Geo-Metadaten (Kataloge) und in Suchdienste. Dazwischen gibt es Schnittstellen-Software, bzw. Protokolle.
  5. Geo-Metadaten-Austausch-Protokoll (für Kataloge und Suchdienste): Schnittstellen-Software rasch bereitstellen, zunächst mit 'unqualified Dublin Core'. Es gibt dafür noch kein in der GIS-Welt anerkanntes Protokoll. CSW erscheint ungeeignet. Es gibt jedoch Lösungsansätze wie OAI-PMH. Sobald ein Geo-Metadaten-Austausch-Modell definiert ist, kann die Schnittstellen-Software angepasst werden.

Architektur-Skizze

Architektur: Geodaten, Metadaten und Protokolle.

Abbildung: Architektur: Geodaten, Metadaten und Protokolle.

Diskussion

  • Zu 1 und 2, Verwaltungs- und Austauschmodelle: ISO 19115/119 und Profile wie CH-GM03 waren bisher für die Erfassung wie auch für den gemeinsamen informationsverlustfreien Austausch gedacht. Wir plädieren dafür, dieses als Vorlage für beide Modellarten weiterzuverwenden. Alle müssen sie aber noch verkleinert und ergänzt(!) werden, v.a. durch Beschreibung von Geodiensten (vgl. unten). Vorschläge dazu gibt es unten.
  • Zu 1, Verwaltungs-Modell: Dieses kann selber bestimmt werden, solange die Schnittstellen (3 und 5) erfüllt werden. Für die Verwaltung aus Sicht Datenerfasser sehen gibt es ISO 19115/119 (und Profile wie GM03). In einer Phase der Konsolidierung kann später über den vereinfachten, verlustfreien Austausch nachgedacht werden. Wir haben gute Erfahrungen mit einachten Modellen gemacht (vgl. 'GM03light' mit GMDB). Erfassung, Verwaltung und Nacherfassung ist um so einfacher, je kleiner das Modell ist. Definitions-Vererbungs-Mechanismen, wie sie in Interlis bekannt sind, kommen nicht zum Tragen wegen dem Baukasten-Ansatz von ISO (mit über 300 optionalen Attributen).
  • Zu 2, Austausch-Modell: Es gelten bis auf weiteres ISO 19115-Profile wie z.B. GM03-Core in der Schweiz. Metadaten gemäss Austausch-Modell sind grundsätzlich freie Daten (z.B. mit angepasster LGPL-Lizenz). Man beachte: Geo-Metadaten über Geodaten können Verweise auf Dateien haben, es können aber auch auf Webdienste wie WMS/WFS zeigen! Wir sprechen hier bei WMS/WFS von Data Access Services, die zu der Geodaten-Beschreibung gehören und keine eigenständigen Geo-Webservices sind. Geo-Filterdienste hingegen sind eigenständige Geo-Webdienste, z.B. Webdienste zu Koordinatentransformation, zur Datenkonversion.
  • Zu 3, Codierung: Das soll den Spezialisten überlassen bleiben. Mit UML/Interlis gibt es bereits eine Lösung. Bei Dublin Core gibt es verschiedene Bemühungen.
  • Zu 4, Werkzeuge zur Verwaltung: Editoren sind dann einfach, wenn sie Attributwerte automatisch eruieren (Existenz, Bounding Box und Zeitstempel aus Geodaten), vorgeben (mit Templates/Konfiguration) oder sich über Karten und Gazetteers eingeben lassen. Sehr wahrscheinlich werden Webapplikationen und GIS-Desktop-Editoren koexistieren - dank Schnittstellen. Es erscheint z.Zt. am Sinnvollsten, eine Webapplikation anzubieten und allenfalls die vorhandenen Attributwerte von den Geodaten direkt zu holen (Datum, Ausdehnung, Koord.System) und in Feldern URLs zuzulassen, z.B. auf Datenschema-Beschreibungen oder andere Informationen im Web (z.B. Lizenzinformationen). Unserer Einschätzung nach, sprechen daher mehr Vorteile für Webapplikationen im Gegensatz zu im Desktop-GIS integrierten Editoren. Nachteile/Vorteile Variante Webapplikation:
    • + Unabhängig von Systemversion und mehrere GIS können in einer Version ko-existieren
    • + Metadaten sind im Web sichtbar, Adressen (Abgabestelle/Datenherr) können zentral verwaltet werden.
    • + Gewünschte Metadaten sind für Google und andere Suchdienste auffindbar.
    • - Es muss zwischen den Geodaten und der Webapplikation synchronisiert werden.
  • Zu 5, Geo-Metadaten-Austausch-Protokoll und Software:
    • Das Protokoll soll offen sein für versch. Metadaten-Modelle. Um keine Zeit zu verlieren soll die Software jedoch jetzt schon vorgesehen werden. Diese würde zunächst Dublin Core, dann CH-GM03 und dann noch das zu definierende Metadaten-Austausch-Modells anbieten.
    • Zwei aufeinander aufbauende Protokolle scheinen vielversprechend:
      • Geo-Metadaten als genormtes GM03/XML ins Web stellen (= 'Published XML'),
      • Implementation eines 'Geographic Metadata Harvesting'-Protokolls, z.B. OAI-PMH (Google-API!).
    • Man beachte, dass für beide Protokolle bereits Spezifikationen sowie Implementationen vorhanden sind und sofort eingesetzt werden könnten! Das OAI-PMH-Harvesting-Protokoll, ist seit Jahren in Digitalen Bibliotheken implementiert und wird von Google erkannt!

Minimales Datenmodell für Metadaten-Austausch (DClite4G)

Es gibt einen Vorschlag für ein minimales Datenmodell für den Metadaten-Austausch namens 'DClite4G' von der OSGeo-Geodata Community.

Dieser Vorschlag basiert strikt auf Dublin Core, wovon nur elf Attribute verlangt werden, darunter auch einige, die im ISO 19115-Modell (bzw. GM03) nicht vorgesehen waren, wie z.B. ein Typ ('dataset' oder 'service'), ein Format (XML-Namespace) oder Verweise 'von Geodaten zu Services' und umgekehrt.

Dieses DClite4G-Modell lässt sich weiter zu reinem 'unqualified' Dublin Core Modell reduzieren, welcher auch von digitalen Bibliotheken und Google 'verstanden' wird und von einfachen Protokollen wie OAI-PMH (vgl. unten) verlangt wird.

Minimales Protokoll (OAI-PMH)

OAI-PMH bedeutet Open Archives Initiatice Protocol for Metadata Harvesting. Es ist in diesem Artikel zu OAI-PMH beschrieben und verlangt als obligatorisches Datenmodell 'unqualified' Dublin Core. Weitere Datenmodelle sind möglich. Es gibt dazu auch 'Guidelines for a minimal OAI-PMH implementation'.

Fragen und Antworten

Webapplikationen oder integrierte GIS-Desktop-Editoren?
Webapplikation, allenfalls verknüpft mit Desktop-Editoren. Siehe "Zu 4)" oben.
Was ist ein Harvesting-Protokoll, z.B. im Vergleich zu einem Query-Protokoll?
Ein Harvesting-Protokoll benötigt keine Query-Funktionen und und verlangt daher weniger Implementationsaufwand. Siehe oben.
Wie sollen Geodienste beschrieben werden?
Wir unterscheiden zwei Arten von Geodiensten, einerseits Data Access Services (wie z.B. WMS, WFS; generell OWS) und anderseits 'Filter Services' bzw. 'Web Processing Services'. Siehe oben.
Wie könnte nun ein minimales Geo-Metadaten-Modell aussehen, welches Services und Automatisierung berücksichtigt?
Es kursiert ein Vorschlag namens DClite4G wie oben beschrieben.

Aufruf zur Publizierung von Geo-Metadaten!

Wir empfehlen allen Vertretern allen Geodaten-Besitzern - v.a. den öffentlichen Verwaltungen - dringend Geo-Metadaten zu erfassen und zwar zum Nutzen aller und ganz im Sinne des Öffentlichkeitsprinzips!

Vorgehensvorschlag (Sicht Daten-Provider):

  1. Ein Geo-Metadaten-Verwaltungs-Werkzeug wählen. Ob eine einheitliche Applikation (Web oder Desktop-Tool) vorzuschreiben ist, hängt von der Organisation ab. In jedem Falle müssen jedoch Schnittstellen und Protokolle sichergestellt sein.
  2. Allenfalls vorher ein eigenes Metadaten-Verwaltungs-Modell wählen. Mit welcher Priorität das Metadaten-Verwaltungs-Modell definiert wird, kann selber bestimmt werden. Dokumentierte Datenmodelle sind in jedem Falle eine Investition mit Zukunft.
  3. Export eines einheitlich codierten Metadaten-Austausch-Modells vorsehen/verlangen: zunächst Dublin Core, dann nach geltendem nationalem Profil (CH-GM03 Core/XML), dann gemäss aktuellen Bestrebungen.
  4. Geo-Metadaten-Austausch-Protokoll-Software vorsehen/verlangen.
  5. (Interne) Erfassungs-, Aktualisierungs- und Verwaltungs-Richtlinien erstellen und Schulung berücksichtigen.

Hinweis: Kosten für Anpassung der Modelle, der Verwaltungs- und Schnittstellen-Software und dann der Daten-Nacherfassungen vorsehen.

Werkzeuge (Tools)

Tools für Suche und Austausch von Geo-Metadaten (CSW, OAI-PMH)

Tools für die Verwaltung von Geo-Metadaten (Editoren)

Achtung: Z.T. komplexe Software, besonders diejenigen, die ISO 19115/9 vollständig implementiert haben!

Am GISpunkt HSR im Einsatz oder speziell getestet:

  • Webapplikationen und Desktop Tools, Open Source oder Freie Software:
    • Geometa-Editor (Geo-Metadatenbank GMDB) - Webapplikation, Open Source (PHP, MySQL/PostgreSQL) als Teil der Geo-Metadata Network Suite.
    • GeoNetwork (Open Source, Java, XSLT, MySQL/PostgreSQL)
    • GeoKatalog/geocat.ch (kommerziell, gehostet oder kommerziell lizenziert, Java, ORACLE)
  • Webapplikationen und Desktop Tools, proprietär/weitere:

Liste weiterer Software:

  • Webapplikationen und Desktop Tools, Open Source oder Freie Software:
    • deegree (Open Source, Java)
    • sdi.suite terraCatalog (Open Source, kommerziell)
    • disy Preludio (gratis, Windows, Java)
    • GeoNetwork, (Open Source, Java) CSW implementation. A tool developed by FAO, UNEP and WFP; ab Dezember auch mit OAI-PMH-Support.
    • Mediator (Windows, frei)
    • CatMDEdit, Spanien TelDE (Unix/Windows, kostenfrei, Java)
  • Webapplikationen und Desktop Tools, proprietär/weitere:
    • GeoKey (kommerziell)
    • M3CAT, Canada (ASP, kommerziell)
    • InGeo Services (kommerziell, nur Service)
    • MDWEB, France – IRD (PHP, ?)
    • GIMEF (kommerziell)
    • INdicio (kommerziell)
    • RedSpider Catalog (kommerziell)
    • CorpsMet95 (Windows, eingestellt)
    • Publistar (Windows/Linux, kommerziell/kostenpflichtig)
    • Authentic 2005 (Windows, kommerziell/kostenpflichtig, teil von XMLSpy)

In eigener Sache

Seit unserem ersten Aufruf an der Konferenz GIS/SIT 2000 für möglichst einfache Geo-Metadaten ist es mittlerweile ein halbes dutzend Jahre her!

Am GISpunkt HSR beschäftigen wir uns seit einiger Zeit mit der vereinfachten Erfassung, Dokumentation und Zugänglichkeit von Geo-Metadaten v.a. mit der Open Source Geo-Metadatenbank GMDB und Geometa.info, der Suchmaschine für Geodienste, Geodaten und Online-Karten.

Beachten Sie unsere Geo-Metadata Networking Suite.

Wir bieten auch Kurse an, namentlich den BIZGEO-Einzelkurs "Geo-Metadaten- und Internet-Recherche" (siehe Agenda). Wir helfen auf Anfrage (organisations-) interne Geo-Metadaten-Verwaltungs-Modelle zu definieren oder ein Geo-Metadaten-Werkzeug auszuwählen.

Weblinks

Von «https://giswiki.hsr.ch/index.php?title=Geo-Metadaten&oldid=10168»