9911_ptb

Wissenschaftliches Datenmanagement:
Das CERA-2 Daten- und Metadatenmodell
Frank Toussaint, Potsdam-Institut für Klimafolgenforschung
Zusammenfassung
Um die in jeder Beziehung stark inhomogenen Daten verschiedener Forschungsinstitute zugänglich zu machen, wurde das Daten- und Metadatenmodell CERA
entwickelt. Es ermöglicht für geografisch bezogene Metadaten institutsübergreifenden
Zugang. Inhalt, Qualität, Formate und zahlreiche andere Parameter der beschriebenen
Daten sind damit allgemein abrufbar. Die SQL der auf ORACLE-Basis erfolgten
Umsetzung am PIK ist über das Internet einsehbar. Außerdem wurde eine flexible
Java-Oberfläche (AFRI) entwickelt, mit der die Datenbank-Inhalte in Inter- und Intranet
sichtbar gemacht werden.
1. Einführung
Wie auf allen Gebieten der IT so sind auch im Bereich der raumbezogenen Daten die Datenmengen in
den letzten Jahren exponentiell angestiegen. Sie liegen oftmals weit verteilt auf verschiedenen Medien
und sind nach Struktur, Format, Qualität und Menge extrem inhomogen. In Forschungsinstituten kommen
die unterschiedlichen Sicherheits- und Nutzungsanforderungen der einzelnen Arbeitsgruppen hinzu.
Aus dieser Situation heraus wurde 1997/98 das CERA-2 Datenmodell entwickelt, mit dem Ziel, die ganz
unterschiedlichen raumbezogenen Daten verschiedener Institute gleichermaßen zu beschreiben und die
Beschreibungen transparent zu koppeln. Außerdem sollte das Konzept von CERA (Climate and
Environmental Data Retrieval and Archiving System) offen genug für die Möglichkeit sein, lokale Daten
direkt in das Datenmodell der beschreibenden Daten zu integrieren. Hierdurch können die
beschreibenden Informationen der Meta-Datenbank (MDB) mit den eigentlichen Daten verschmolzen
werden.
In den folgenden Kapiteln sollen die Anforderungen an das Datenmodell skizziert (Kap. 2) und seine
Entstehung beschrieben (Kap. 3) werden. Es folgen eine Beschreibung der Struktur des Modells (Kap. 4)
sowie der aktuellen Implementation (Kap. 5) am Potsdam-Institut für Klimafolgenforschung (PIK).
Zusätzlich wurde eine flexible, webfähige grafische Nutzerschnittstelle (AFRI) entwickelt, die in Kapitel 6
beschrieben wird. Den Abschluss bildet ein kurzer Ausblick auf die geplante Weiterentwicklung (Kap. 7)
von CERA-2 und seiner Implementation im PIK.
2. Motivation und Anforderungen an das Metadatenmodell
Zunächst sind die verschiedenen Anforderungen an das Datenmodell zu formulieren. Dabei sei
vorgegeben, dass es sich um geografisch-raumbezogene Daten (Geospatial Data) handeln soll. Die
Zuordnung zu Raumbereichen erfolgte über bounding boxes (minimale und maximale geografische
Länge und Breite) sowie (optional) über örtliche Bezeichnungen.
Bei der Festlegung der Metadatenstrukturen von CERA-2 standen vor allem folgende, sich teilweise
überschneidende Punkte im Vordergrund:
 Flexibilität der Datenstrukturen hinsichtlich der sehr inhomogenen Daten der verschiedenen
Anwender und ihrer ebenso inhomogenen Bedürfnisse,
 leichte Erweiterbarkeit zur Anpassung an neue Anforderungen, die im Hause aber auch durch
Erweiterung des Kreises der Nutzerinstitute immer wieder auftreten,
 Übersichtlichkeit der Strukturen, da etliche Dutzend Tabellen miteinander in Verbindung stehen und
über Institutsgrenzen hinweg koppelbar sein sollen,

hinreichende Beschreibung der Speicherstrukturen, um automatischen Datenzugriff zu
ermöglichen,
 Kompatibilität zu inhaltlichen Standards wie sie durch den Content Standard of Digital Geospatial
Metadata (CSDGM) des Federal Geographic Data Committee (FGDC 1999) oder das Directory
Interchange Format (DIF) der National Aeronautics and Space Administration (NASA 1999) festgelegt
werden,
 Kompatibilität zu funktionalen Standards. Zum Beispiel fordert die US-amerikanische IEEE (siehe
Bretherton 1994) neben »Browse/Search/Retrieval« Funktionen und der Unterstützung von »Storage
and Archive« auch die Möglichkeit, mittels der Metadaten »Application to Application Transfer«
durchzuführen sowie »Ingest, Quality Assurance and Reprocessing«.
 transparente Vernetzung verteilter Datenbestände soll möglich sein,
 akzeptabler Aufwand für Pflege und Nutzung, damit die DB die Projektlaufzeit ihrer Erstellung
überlebt.
Außerdem spielte bei der Umsetzung eine besondere Rolle, dass die entstehende Datenbank von NichtInformatikern in weitgehend fachlich disjunkten Institutionen verwendet werden sollte.
3. Werdegang von CERA-2
Zunächst entstand am Deutschen Klimarechenzentrum (DKRZ) in Hamburg das CERA-1 Datenmodell in
Zusammenarbeit mit dem Potsdam-Institut für Klimafolgenforschung (PIK) und dem Alfred-WegenerInstitut für Polar- und Meeresforschung (AWI) in Bremerhaven. Auf Basis des Oracle DatenbankManagementsystems (DBMS) wurde ein relationaler Ansatz gewählt. Einer relationalen Struktur wurde
aus verschiedenen Gründen der Vorzug gegeben. Neben der besseren Übersichtlichkeit spielten dabei
Titel:
Core_Modules _loc al_s w .eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nicht
an andere Druckertypen.
Abb. 1:
Die CERA-2 Tabellen teilen sich in einen Kernbereich (CERA Core), die Module (CERA
Modules) und lokal installierte Erweiterungen (local extensions).
vor allem die weite Verbreitung und der hohe Entwicklungsstand entsprechender Systeme eine Rolle, mit
denen für Oracle und Sybase auch bereits positive Erfahrungen vorlagen. Gleichzeitig war mit SQL eine
einheitliche Definitions- und Abfragesprache verfügbar, die eine Zusammenarbeit verschiedener
Entwicklungszentren begünstigte.
Dieser zunächst sehr an der Massendatenhaltung des DKRZ ausgerichtete erste Entwurf war Grundlage
für das CERA-2 Datenmodell, das von den beteiligten Instituten unter Potsdamer Federführung erstellt
wurde.
Die gemeinsame Entwicklung wurde über das Internet (Diskussionsbeiträge, gemeinsame »CERA
Central Page«) koordiniert. Dabei wurde die Entstehung besonders davon beeinflusst, dass die beteiligten
Institute sehr unterschiedliche Interessen haben, bedingt durch ihre unterschiedlichen Datenstrukturen
(AWI: große Mengen mäßig homogener Messdaten; DKRZ: große Mengen relativ homogener
Modelldaten; PIK: relativ geringe Mengen extrem inhomogener Daten).
4. Grundlagen von CERA-2
4.1 Die Struktur: CERA Core und CERA Modules
Flexibilität und Erweiterbarkeit werden vor allem durch die Aufteilung der Tabellen in Gruppen
gewährleistet. Dabei sollte die zentrale Gruppe von gut 40 Tabellen (CERA Core) von allen
Partnerinstituten installiert und in der Regel auch genutzt (i.e. befüllt) werden. Hingegen werden
Tabellengruppen, die nur für einige Teilnehmer von Bedeutung sind, dort als sogenannte CERA Modules
installiert. Schließlich kann jedes Institut natürlich eigene Tabellenstrukturen (»Local Extensions«) in
CERA integrieren (s. Abb. 1).
Titel:
BLOCK-2.4sw .eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nic ht
an andere Druckertypen.
Abb. 2: Der CERA-Kernbereich (CERA Core) ist thematisch in Tabellengruppen (CERA Blocks)
untergliedert.
Titel:
Core12a.eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nic ht
an andere Druckertypen.
Abb. 3:
CERA Core Hauptblock (“Metadata Entry”) mit Blöcken “Status” und “Spatial Information”.
Titel:
Core12B.eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nic ht
an andere Druckertypen.
Abb. 4:
CERA Core Blocks “Parameter”, “Coverage“, “Contact”, “Distribution” und “Reference”.
Titel:
data_acc es s01.eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nic ht
an andere Druckertypen.
Abb. 5:
CERA Module “Data Access”
Titel:
c onnect_sw .eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nic ht
an andere Druckertypen.
CERA Core ist inhaltlich in acht CERA Blocks
unterteilt, die verschiedene Themenbereiche
abdecken: Titel und Datum des Eintrags, die
raumzeitliche Überdeckung der Daten, ihr
Qualitäts- und Bearbeitungsstatus, die
gemessenen physikalischen Größen, die
verwendeten Koordinatensysteme,
Kontaktinformation zu Datennehmern, eignern und Distributoren, die nötigen
Informationen um an die Daten zu gelangen
und schließlich Verbindungen zu eventuellen
Publikationen (s. Abb. 2).
In der CERA Core-Tabellenstruktur (s. Abb. 3
und 4) sind zahlreiche Wertetabellen integriert,
um die Eingaben zu systematisieren. Sie sind
auf der zur Eingabe bestimmten
Benutzeroberfläche als Pull-Down-Menues
zugänglich.
Die CERA Module beschreiben als fakultative
Erweiterungen des Modells beispielsweise die
Speicher- (CERA Module Data Organization)
und Zugriffsstrukturen (CERA Module Data
Access, beispielhaft in Abb. 5) oder auch die
Inputparameter, mit denen bestimmte
Modelldaten erzeugt wurden (CERA Module
Model Input).
4.2 Von Metadaten zu Daten:
CERA Local Extensions
Das CERA Datenmodell lässt Raum für die
Bedürfnisse der einzelnen Anwender.
Beispielsweise kann es lokal um zusätzliche
Tabellen mit Metainformationen erweitert
werden. Hierdurch wird der Tatsache
Rechnung getragen, dass die erforderliche
Detailgenauigkeit der Metadaten von
Anwender zu Anwender stark unterschiedlich
ist.
Abb. 6: Eine Kopplung verschiedener DB an
eine grafische Nutzerschnittstelle (GUI)
kann über JDBC erfolgen, da
entsprechende Treiber praktisch für alle
DBMS erhältlich sind (Fall A, Sun
1998b). Bei gleichen DBMS ist oft eine
Kopplung auf DB-Ebene (Fall B) sehr
viel einfacher durchzuführen (z.B. bei
ORACLE).
Mittels der CERA Local Extensions können
andererseits aber auch die Daten selbst in das
Model integriert werden. Beschreibungen der
Integration finden sich dann ggf. in den
übrigen CERA Tabellen. In dieser Form
erfolgte die Umsetzung am Deutschen
Klimarechenzentrum.
4.3 Vernetzung von DB unter CERA
Die transparente Kopplung der MetaDatenbanken verschiedener Institute ist
grundsätzlich auf verschiedene Weisen
möglich (s. Abb. 6).
Bei der Verwendung gleicher DBMS kann
vielfach direkt auf Datenbankebene gekoppelt
werden. In diesem Fall sorgt die an den verschiedenen Orten gleiche Tabellenstruktur dafür, dass die
lokalen Oberflächen unmittelbar auf die Partnerstrukturen aufsetzen können. So wird zum Beispiel
gegenwärtig zwischen DKRZ und PIK verfahren, die beide Oracle als DBMS verwenden. Auch die
datenbankspezifischen Nutzeroberflächen können dann gemeinsam verwendet werden.
Etwas aufwendiger ist die Vernetzung, wenn verschiedene DBMS vorliegen. Die lokalen
Nutzeroberflächen müssen in der Regel getrennt entwickelt werden, eine Kopplung ist via JDBC oder
CORBA möglich.
4.4 Praktische Umsetzung
Bei der Entwicklung von DB sind gegenüber theoretischen Entity-Relationship-(ER)-Modellen und ihren
Forderungen nach Normalform verschiedentlich Kompromisse nötig, um die Nutzbarkeit nicht unnötig
einzuschränken. In solchen Fällen muss der praktische Nutzwert den Ausschlag geben gegenüber
modelltheoretisch oder ästhetisch ansprechenderen Lösungen.
Unter Normalisierungsgesichtspunkten (Erste Normalform) hätte es sich in CERA zum Beispiel
angeboten, die im Bereich der Beschreibung von Publikationen auftretenden »Autoren« in der sowieso
vorhandenen Tabelle »Personen« abzulegen. Die genauere Betrachtung praktischer Fälle verbietet
solches Vorgehen. Bei der Eingabe von Literaturzitaten sind oftmals von einem Autor nur der Nachname
und der Initial des Vornamens bekannt. In der Personentabelle qualifiziert dies keinen Schlüssel, folglich
ist eine Eintragung dort nicht sinnvoll. Das »Authors«-Feld muss daher als freier Text in der Beschreibung
von Referenzen bleiben.
Auch die Beschreibung der jeweiligen Speicherstruktur ist für die verschiedenen Daten der
unterschiedlichen Institute so spezifisch, dass sie sich nicht ohne Weiteres in eine Datenstruktur abbilden
lässt. In CERA wurde der wohl flexibelst denkbare Weg gewählt. Die Zugriffsbeschreibung erfolgt in vier
freien Textfeldern. Deren Bedeutung wiederum kann abhängig von der konkreten Situation in einer
beschreibenden Tabelle definiert werden. Eine häufige Bezeichnung für die vier Felder ist hier zum
Beispiel Host/Pfad/Datei/Kommentar. Auf diese Weise können auch Zugriffsregeln für in DB gehaltene
große Binärdatenmengen (Binary Large Objects, blobs) in der MDB abgelegt und zur automatisierten
Weiterverarbeitung ausgelesen werden.
Hierarchien werden in CERA nicht als Tabellengruppen mit einer Tabelle pro Ebene abgespeichert, da
dies eine A-priori-Festlegung auf die Zahl der Hierarchieebenen erfordert. Statt dessen ist jeweils eine
einzelne rekursive Tabelle eingerichtet worden. In ihr enthält jede Zeile einen Zeiger auf die Zeile des
übergeordneten Eintrags sowie aus Performanzgründen die (redundante) Information über das
Hierarchieniveau, auf dem sich die Zeile befindet.
Zusammen gefasst mag man die praktische Umsetzung an dem Satz orientieren: Soviel Normalform wie
möglich, aber durchaus Abweichungen wo nötig. In einigen, begründeten Fällen kann also durchaus von
den Normalformen abgewichen werden, generell aber ist eine weitgehende Normalisierung durchaus
wünschenswert. Der eingesparte Speicherplatz spielt beim heutigen Preisniveau von Festplatten zwar
kaum noch eine Rolle, die Datenintegrität ist jedoch sehr viel leichter zu gewährleisten, wenn
Doppelspeicherungen unterbleiben.
Eine andere Maxime für den Strukturentwurf mag sein: So allgemein wie möglich, aber speziell wo nötig.
Bei neuen Anforderungen sind Erweiterungen und Umstrukturierungen in generischen Modellentwürfen
sehr viel leichter durchzuführen.
Schließlich hat sich bewährt, über die reine Tabellenstruktur hinaus auch die Semantik in die
Entwurfsdiskussion mit einzubeziehen. Allein unter dem Begriff “Modell” wird von verschiedenen
Anwendern mal der ein Problem beschreibende Algorithmus verstanden, mal dessen Implementation als
Programm und mal die resultierenden Ergebnisse. Eine sorgfältig gewählte Semantik ist umso wichtiger,
wenn mehrere Personen unterschiedlicher fachlicher Herkunft am DB-Entwurf arbeiten, was für eine
möglichst allgemein nutzbare Struktur gerade wünschenswert ist.
5. Die aktuelle CERA-Implementierung am PIK
Gegenwärtig sind am PIK das CERA Core sowie zwei der CERA Module installiert und in Verwendung;
außerdem eine Gruppe von rund 30 Tabellen (Ladetabellen) in denen Neueingaben aufgefangen werden.
Erst nach einer halbautomatischen Prüfung werden sie dann mittels SQL Skripten in die CERA Tabellen
übertragen. Die Füllung der Ladetabellen erfolgt über Masken (ORACLE Forms). Update der
Datenbankeinträge ist ebenfalls über Masken möglich (s. Abb. 7).
Die Abfrage der Datenbank erfolgt im Wesentlichen auf zwei Wegen: Über die CERA Central Page des
Internets (http://www.pik-Potsdam.de/cera/) ist ein direkter Zugang zu einem Teil der Einträge über ein
Java-Applet (AFRI, s. nächster Abschnitt) möglich, im Intranet zu allen Einträgen. Gleichzeitig kann hausintern (oft performanter) über das analoge Java-Programm zugegriffen werden.
Zusätzlich kann die CERA MDB über ORACLE Masken abgefragt werden, die noch einige besondere
Funktionalitäten bieten.
Titel:
f4.eps
Erstellt v on:
fig2dev Version 3.2 Patchlevel 0-beta3
Vorsc hau:
Dies e EPS-Grafik w urde nic ht gespeichert
mit einer enthaltenen Vors chau.
Kommentar:
Dies e EPS-Grafik w ird an einen
Pos tSc ript-Drucker gedruckt, aber nic ht
an andere Druckertypen.
Abb. 7:
Die CERA-2-Implementierung am PIK. Für Eingabe, Bearbeitung und Abfragen wurden
ORACLE Forms Oberflächen verwendet. Um Konsistenz und Sinnhaftigkeit der Eingabedaten
zu sichern, wurde eine Zwischenschicht von neun Haupt- und rund 20 kleineren Ladetabellen
erzeugt, die eine Kontrolle der eingegebenen Daten ermöglicht, bevor diese mittels eines SQLSkriptes in die CERA-Tabellen eingetragen werden.
Parallel entstand die Abfrage-Oberfläche “AFRI” (s. Kap. 6), die die CERA-Eintragungen in
Intranet und Internet sichtbar macht.
6. AFRI und IDA: Flexible Grafische Nutzer Schnittstellen (GUI) auf Java Basis
Zur komfortablen Abfrage von DB- und MetaDB-Inhalten wurde am PIK ein flexibles Java-Userinterface
mit dem dazugehörigen Server entwickelt (AFRI, s. Abb. 8). Zusammen mit einem interaktiven digitalen
Atlas (IDA) erlaubt es, intuitiv Anfragen auf die räumliche und zeitliche Überdeckung der gesuchten Daten
zu formulieren. Außerdem ist eine Auswahl in Stichwort-Hierarchien und in Einzelfeldern möglich. Die
auszugebenden Spalten können gewählt werden und die gefundenen Daten direkt auf den Client
übertragen. Dabei wird der Kontakt zur Datenbank über JDBC (Sun 1998a) hergestellt.
Abb. 8:
Das Java-Programm AFRI ermöglicht DB-Abfragen über Internet, Intranet und als Standalone-Version. Es passt sich selbstkonfigurierend an die in Steuertabellen beschriebenen DBTabellen an.
Die Datenstruktur, an die sich das GUI anpassen muss, wird in Tabellenform beschrieben und ebenfalls
in der DB abgelegt, so dass bei Änderungen keine Neuprogrammierung erfolgen muss (s. Abb.
AFRI/IDA). Dadurch eignet es sich nicht nur für CERA sondern für jede Art von Tabellengruppen
geografischer Daten, die in einem relationalen DBMS über JDBC zugänglich sind.
Abb. 9:
Die Ausgabe erfolgt bei AFRI in Tabellenform oder mittels IDA als Ortsinformation.
Bei der Ausgabe erlaubt IDA die Darstellung von verorteten Daten als Figuren auf den Karten des
hierarchischen Atlas.
Die aktuelle Version von AFRI hat unkomprimiert eine Größe von ca. 560 KB. Für den Zugriff auf die PIK
MDB CERA ist sie über die CERA Central Page im Netz offen zugänglich.
7. Ausblick
Am PIK ist die Installation von CERA-2 abgeschlossen. Die SQL-Skripte zur Tabellendefinition (DDL)
sowie zahlreiche Tools (DML) können über die CERA Central Page eingesehen und abgerufen werden.
Ebenso stehen dort die Beschreibungen des CERA-Konzepts zur Verfügung.
Gegenwärtig ist CERA an vier Instituten installiert. Eine Kopplung der MDB steht bisher zwischen
Potsdam und Hamburg zur Verfügung, weitere Kopplungen sind geplant.
Noch unvollständig sind die Automatisierungsmöglichkeiten genutzt. Lediglich in der Ladeschicht laufen
Konsistenzprüfungen bereits teilweise automatisch ab. Wenigstens soweit Speicherorte der Daten
beschrieben werden, wäre von Zeit zu Zeit eine automatische Kontrolle auf Aktualität wünschenswert, da
damit zu rechnen ist, dass in den verschiedenen Arbeitsgruppen Daten migrieren, ohne dass die
entsprechenden Korrekturen der Metainformationen vorgenommen werden.
Schließlich ist eine engere Anbindung der Daten an die Metadaten geplant. Nach Selektion der
Metainformationen aus CERA (zum Beispiel mittels AFRI), soll sich der Nutzer schnell einen Überblick
über die Daten selbst verschaffen können, um sie dann gegebenenfalls lokal weiter zu bearbeiten.
Literatur
Bretherton, F., 1994: Reference Model for Metadata: A Strawman. Whitepaper, University Wisconsin.
URL: http://www.llnl.gov/liv_comp/metadata/papers/whitepaper-bretherton.html and whitepaperbretherton.ps
Federal Geographic Data Committee (FGDC), 1999: Content Standard for Digital Geospatial Metadata
(CSDGM), Version 1.0, URL: http://www.fgdc.gov/metadata/contstan.html
Kramer, R. und F. Hosenfeld (Hrsg.) 1999: Heterogene, aktive Umweltdatenbanken, Workshop Vilm
1998, Metropolis-Verlag, Marburg 1999
Lautenschlager, M., F. Toussaint, H. Thiemann, M. Reinke, 1998: The CERA-2 Metadata Model,
Technical Report No.15, Deutsches Klimarechenzentrum Hamburg 1998, URL: http:// www.pikpotsdam.de/cera/Descriptions/Publications/Papers/9807_DKRZ_TechRep15/
National Aeronautics and Space Administration (NASA), 1999: Global Change Master Directory, URL:
http://gcmd.gsfc.nasa.gov/
Potsdam-Institut für Klimafolgenforschung (PIK), 1999: The CERA Central Page, URL: http://www.pikpotsdam.de/cera/
Sun Microsystems, 1998a: The JDBC Database Access API, URL: http://java.sun.com/products/
jdbc/jdbc.html
Sun Microsystems, 1998b: JDBC Drivers, URL: http://java.sun.com/products/jdbc/jdbc.drivers.html
Toussaint, F., M. Lautenschlager und M. Reinke, 1999: CERA-2 - Ein raumbezogenes Daten- und
Metadatenmodell, in: Kramer und Hosenfeld 1999
Wrobel, M., 1999: AFRI/IDA - Ein flexibles Retrieval-Interface für heterogene raumbezogene Daten, in:
Kramer und Hosenfeld 1999