Seitenhistorie

Anwendungsfälle

Eine Vielzahl von Anwendungsfällen erfordert, dass einzelne Ressourcen, z.B. Geoobjekte eindeutig adressiert bzw. refrerenziert referenziert werden können.

Beispiele Anwendungsfälle:

• Geoobjekte in einem Datensatz können gegenseitig in Bezug stehen, z.B. referenzieren sich Straßenzüge und Straßenknoten, so dass sich eine Straßennetztopologie ergibt.
• Um Bezüge über Datensatzgrenzen hinweg herzustellen, können Geoobjekte benachbarter Geodatensätzen referenziert werden. Wenn sich ein Gewässer beispielsweise über die Datensatzgrenze erstreckt und die Abschnitte der benachbarten Flussegmente Flusssegmente im Oblauf oder Unterlauf als Geoobjekte eines anderen Datensätzen verfügbar sind, so soll es auch möglich sein, diese zu referenzieren.

Die genannten Anwendungsfälle können leicht unterstützen werden, wenn jedes Geoobjekte über einen eindeutigen persistente Identifier verfügt, über den es eindeutig in der Geodateninfrastrukur nutzbar und abrufbar ist. Aus diesem Grund existiert auch bei INSPIRE die Anforderung, eindeutigen Identifikatoren für Geoobjekte zu vergeben. INSPIRE fordert hier, dass URLs als Identifikatoren verwendet werden, so dass jedes einzelne Geoobjekte über das Internet addressierbar ist.

Linked Data

Mit Linked Data bezeichnet man die Verknüpfung von Daten im WorldWideWeb, die über eindeutige Webadressen bereitgestellt werden. Damit Geodaten auf gleiche Art und Weise auch mit anderen Daten verknüpft werden könne, müssen diese ebenfalls eindeutig adressiert und refrerenziert referenziert werden können. Linked Data und INSPIRE haben diesbezüglich die gleichen Anforderungen.

Namensraum-Register

Das Namensraum-Register unterstützt Datenbereitsteller auf folgende Weise, um den genannten Anforderung nachzukommen:

1. Organisationen können im Namensraum-Register einen eigenen Namensraum erhalten. Mit Hilfe dieses Namensraum können Sie eine beliebige Anzahl von persitenten und eindeutigen Objektidentifikatoren für ihre Geodaten bilden.
2. Organisationen können in der Registry konfigurieren, dass Aufrufe zu Adressen in ihrem Namensraum auf ihre eigenen Datenbereitstellungskomponenten weitergeleitet werden. So werden diese Objekte im Web abrufbar.

Aufbau Namenraum-Register

Für alle Namensräume der GDI-DE Registry gilt folgende Bildungsregel:

# Muster für Namensraum (namespace):
https://registry.gdi-de.org/id/<domain>

Der Platzhalter <domain> steht für den Pfad einer Domain in einem hierarchischen Domain-Baum.

de           # verwaltet von der Kst. GDI-DE
de.bund      # verwaltet von der Kontaktstelle Bund (IMAGI Geschäftsstelle)
de.bund.bkg  # verwaltet von BKG
de.bund.bfg  # verwaltet von BfG
de.nrw       # verwaltet von Kontaktstelle NRW

• Jede Ebene bildet eine eigene Domain.
• Jede Ebene kann von einer anderen Organisation verwaltet werden.
• Eine Organisation, die für eine Ebene zuständig ist, entscheidet, welche weitere Ebenen direkt unterhalb eingerichtet werden können.
• Die Domainstruktur kann organisatorische Zusammenhänge wiederspiegeln widerspiegeln wie "de.bund.bkg", aber auch andere Aspekte z.B. "de.nrw.basisdaten" (fiktives Beispiel). Dies liegt in der Entscheidung der jeweils zuständigen Organisation.

Konvention zur Bildung von Namensräumen in der GDI-DE

Die Konvention zur Bildung von Namensräumen in der GDI-DE orientieren sich an der etablierten Koordinierungsstruktur der GDI-DE.

Die Konventionen enthalten zurzeit noch keinen Vorschlag für die Berücksichtigung von Organisationen oder Gruppen, die sich nicht in der Koordiniderungsstruktur abbilden lassen, wie 

• Bund-Länder arbeitsgruppen-Arbeitsgruppen
• AdV
• Unternehmen
• Forschungseinrichtungen

Damit auch diese Organisationen bald in der Lage sind, eigene Namensräume für ihre Zwecke in der GDI-DE Registry zu erstellen und zu nutzen arbeitet die PG Registry an einer Ergänzung der Konventionen für Namensräume.

Objektidentifikatoren

Hat eine Organisationen einen Namensraum registriert, so kann sie nach den folgenden Regeln beliebige Objektidentifikatoren in diesem Namensraum bilden:

# Muster: Objektidentifikator:
<namespace>/<localId>[/<versionId>]

# Muster: Objektidentifikator ohne Versionierung:
https://registry.gdi-de.org/id/<domain>/<localId>

# Muster: Objektidentifikator mit Versionierung:
https://registry.gdi-de.org/id/<domain>/<localId>/<versionId>

Ein Auszug aus einem Geoobjekt, das dieses Konzept nutz ist im folgenden dargestellt.

ID-Resolver

Stellen Datenanbieter ihre Geodaten mit Objektidentifikatoren nach diesem Konzept über Downloaddienste bereit, so sind diese Geoobjekte bereits über das Internet verfügbar. Ohne weitere Maßnahme sind diese Geoobjekte jedoch noch nicht über ihren Identifikator, d.h. ihre URL beginnend mit https://registry.gdi-de.org/id/ erreichbar.

Um dies zu erreichen, bietet die GDI-DE Registry die Möglichkeit dass Organisationen ihren Namensraum so konfigurieren, dass beim Aufruf des Objektidentifikators eine Weiterleitung auf das Geoobjekt, d.h. auf ihren Downloaddienst aufgerufen wird. Diese Konfiguration wird ID-Resolver genannt.

• ID-Resolver ist eine Konfiguration für die Weiterleitung einer Namensraumanfrage auf eine konfigurierbare Zieladresse.
• In einem Namensraum können mehrere ID-Resolver konfiguriert werden.
• Bei einem Aufruf wird die local-id des Aufrufs mit den im ID-Resolver angegebenen ID-Mustern verglichen. Es kommt derjenige ID-Resolver zum Einsatz, dessen local-id auf das Muster passt und der die höchste Proiorität Priorität hat.
• Neben HTTP/GET Anfragen werden auch HTTP/Post-Anfragen unterstützt.

Ein Beispielkonfiguration kann unter folgendem Link eingesehen werden: https://registry.gdi-de.org/id/de.bb.inspire.ge-core.eem

Ausführliches Beispiel

Das oben verwendete Beispiel ist hier ausführlich beschrieben.

ID-Konzept

Das Namensraum-Konzept bietet verschiedene Möglichkeiten der Umsetzung:

• Eine Organisation kann selbst untergeordnete Namensräume erstellen, beispielsweise für jeden Datensatz einen eigenen.
• Eine Organisation kann unterschiedliche Weiterleitungen im gleichen Namensraum einrichten, beispielsweise um anhand der local-id auf unterschiedliche Downloaddienste weiterzuleiten.
• Es können für einzelne Datensätze unterschiedlche Namensräume unterschiedliche Namensräume gebildet werden.
• Es können für einzelne Datensätze eigene Konzepte in der local-id verwendet werden, wie es beispielsweise für die Datenhaltungskomponenten der AdV gemacht wird.
  
  

Die folgende Anleitung enthält ein Beispiel-ID-Konzept, das als Basis für die eigene Organisation verwendet werden kann:

 Anleitung: Geodaten als Linked-Data bereitstellen