Ergänzend zu den folgenden Informationen können auch die Vorträge zu diesem Thema vom Ansprechpartner-Workshop der GDI-DE im März 2018 als Wissensbasis und Anleitung genutzt werden:

2018-03-21_Einfuehrung_Namensraeume.pdf
2018-03-21_Namensraeume_Registry.pdf



Grundlagen zu Namensräumen:

  • Ein Namensraum (englisch "namespace") ist der Geltungsbereich eines Namens, in welchem der Name nur ein einziges Mal (für ein bestimmtes Objekt) vorkommt und damit eindeutig ist.
  • Namensraum und Name bilden eine Einheit  und ergeben z.B. einen Objektidentifikator.
  • Der selbe Name kann in einem anderen Namensraum ebenfalls vorkommen und dort ein anderes Objekt repräsentieren. Die Eindeutigkeit insgesamt wird erst durch die Kombination mit dem Namensraum erreicht!
  • Beispiel: Die Telefonnummer 123456 (= Name) wird erst in Verbindung mit einer Vorwahl (= Namensraum) eindeutig. Die Telefonnummer 030 123456 repräsentiert ein anderes "Objekt" als die Telefonnummer 069 123456. Fortgesetzt wird diese Sichtweise für dieses Beispiel noch durch die internationale Vorwahl für Deutschland.

Zweck von Namensräumen in einer Geodateninfrastruktur:

  • In einer Geodateninfrastruktur werden Namensräume z.B. eingesetzt, um
    • verschiedenartige Objekte unterscheidbar zu machen (Metadatensätze, Daten-Objekte (z.B. INSPIRE-Features zu verschiedenen Themen), Regionalschlüssel etc.);
    • eine Funktion für oder Zugriff auf diese Objekte mittels Diensten zuzuordnen. Die Funktion ist abhängig von der Art des Objekts: Metadatensätze → CSW-Command; Daten-Objekte → Downloadservice (WFS, Atom-Feed); Regionalschlüssel → Auflösung zum Namen der Verwaltungseinheit und ggf. zur räumlichen Ausdehnung;

    • insbesondere die "Auflösbarkeit", d.h. das Auslösen einer Funktion oder eines Zugriffs aufgrund des aus Namensraum und Name bestehenden Objektidentifikators, zu realisieren.

Namensräume in der GDI-DE:

  • In der GDI-DE können Namensräume nach verschiedenen "Architekturen" angelegt werden, d.h. die hierarchische Gliederung (ob überhaupt und in welcher Detaillierung) obliegt grundsätzlich der jeweils verantwortlichen Stelle. Eine Art Entscheidungshilfe zur Frage, mit welcher Architektur und technischer Unterstützung (GDI-DE Registry?, lokale Lösungen?) die o.g. "Auflösbarkeit" in Anbetracht der jeweiligen Gegebenheiten am sinnvollsten realisert werden kann, bietet die Zusammenstellung unter Weitere Informationen bzw. die vollständige (Registry-unabhängige) Auflistung unter Entscheidungshilfe für Namensraum-Architekturen aus dem Ansprechpartner-Workshop im März 2018.
  • Für die Namensräume in der GDI-DE, die über die Registry verwaltet werden sollen, existiert eine Konvention bzgl. der Benennung des "Einstiegs"-Namensraums, d.h. für alle diese Namensräume gilt, dass sie mit "https://registry.gdi-de.org/id/de" beginnen. Weiter untergliedert werden sie dann in ".bund" für die Bundesverwaltung einerseits bzw. für jedes Bundesland mittels dem jeweiligen Länderkürzel als oberstem Namensraum. Unter Konvention zur Bildung von Namensräumen in der GDI-DE sind weitere Erläuterungen dazu zu finden.
  • Ein Beispiel für den Objektidentifikator eines Metadatenobjekts aus der GDI-NW ist: https://registry.gdi-de.org/id/de.nw/geobasisnrw-sekdatbestand-alkis
  • Weitere Untergliederungen (thematisch, verwaltungsbezogen etc.) sind möglich und liegen im Ermessen und Zuständigkeit der jeweiligen GDI-Kontaktstelle. Kriterien für die Detaillierung der jeweiligen Untergliederung können sein:
    • Eindeutigkeit des Identifikators (ggf. werden separate Namensräume benötigt, weil dasselbe Fachkennzeichen eines Objekts mehrfach als Name verwendet wird)

    • Abgrenzungen der Objekte gegeneinander zwecks thematischer Zuordnung (obwohl Eindeutigkeit gegeben)

    • Trennung von Zuständigkeiten (Pflege der Namensräume durch unterschiedliche Stellen möglich)

    • Festlegung von festen Zugriffswegen für die o.g. "Auflösbarkeit"

  • Für die Bildung von Objektidentifikatoren in definierten Namensräumen sind momentan zwei Anwendungsszenarien bekannt und unter Szenarien zur Nutzung des Registers Namensräume näher beschrieben:
    • Bildung von eindeutigen Ressourcenbezeichnern (in den Metadaten) zur Umsetzung der Daten-Dienste-Kopplung

    • Bildung von INSPIRE-Objekt-IDs zur eindeutigen Verlinkung

Namensraum-Register:

  • In einem Namensraum-Register werden Namensräume "verwaltet", d.h. es geht um Definition, Änderungsmanagement und Funktionszuordnung für jeden Namensraum.
  • Die Informationen zu einem Namensraum sind dabei:
    • Bezeichnung
    • Pfad (technische Adresse) und hierarchische Einbettung entsprechend der gewählten Untergliederung
    • Eigentümer / Verantwortlicher

    • Funktion / Zugriffsweg auf Objekte ("Auflösbarkeit")

    • sofern durch das Register Prozesse gem. ISO 19135 unterstützt werden: Historisierung der Einträge (Vorgänger-Nachfolger-Prinzip bei Änderungen)
  • In der Verwaltung der zum Namensraum zuzuordnenden Funktionen bzw. Zugriffswege liegt ein wesentlicher Mehrwert eines Namensraum-Registers: Nur der Namensraum "kennt" die zugeordnete Aktion bzw. den damit verbundenen Dienst. Bei Änderungen an diesem Dienst (z.B. neue URL zum Aufruf) sind die Objektidentifikatoren gar nicht betroffen! Lediglich der Register-Eintrag zum jeweiligen Namensraum muss daraufhin angepasst werden! Bezeichnung und Pfad (und damit alle Objektidentifikatoren) bleiben unverändert!

"Auflösung" eines Objektidentifikators:

  • "Auflösung" bedeutet hier das Übersetzen in eine Aktion, d.h. es wird gezielt eine Funktion oder ein Zugriff genau für dieses Objekt generiert und ausgelöst.
  • Dazu müssen zum jeweiligen Namensraum Zugriffswege festgelegt werden, indem ein Aufruf eines bestimmten Dienstes (z.B. zwecks Download) zugeordnet wird (für das Namensraum-Register der GDI-DE Registry erfolgt dies im sog. "ID-Resolver", s.u.).
  • Bei der Auflösung wird der komplette Objektidentifikator (Namensraum plus Name) dann getrennt interpretiert: für den Namensraum wird aus dem Register der hinterlegte Dienst gesucht und eine Anfrage genau für dieses Objekt generiert (der Name wird damit zum Suchargument). Für die Anfrage selbst ist ein Muster zu hinterlegen.
  • Für das o.g. Beispiel aus der GDI-NW https://registry.gdi-de.org/id/de.nw/geobasisnrw-sekdatbestand-alkis bedeutet dies, dass an den zum Namensraum "https://registry.gdi-de.org/id/de.nw" hinterlegten Dienst (hier: CSW auf den Metadatenkatalog) eine Anfrage gem. dem hinterlegten Muster (hier: GetRecords-Request), in der der Name "geobasisnrw-sekdatbestand-alkis" zum Suchargument wird, gesendet wird. Resultat der Anfrage ist dann die Anzeige des kompletten Metadatensatzes (XML-Dokument) im Browser.

Verwaltung eines Namensraums im Namensraum-Register der GDI-DE Registry:

  • Das Namensraum-Register der GDI-DE Registry unterstützt die o.g. GDI-DE-einheitliche Benennung des "Einstiegs"-Namensraums nach Konvention zur Bildung von Namensräumen in der GDI-DE und ermöglicht, davon ausgehend weitere Untergliederungen selbst vorzunehmen. Verantwortlich für den "Einstiegs-Namensraum" ist die jeweilige GDI-Kontaktstelle bzw. die Koordinierungsstelle GDI-DE.
  • Mit weiteren Untergliederungen können auch die Zuständigkeiten und Rechte an die entsprechenden Verwaltungen delegiert werden. Diese müssen jedoch zuvor im Organisationen-Register eingetragen werden.
  • Ein Eintrag zu einem Namensraum wird über eine Oberfläche erfasst und besteht i.W. aus:
    • dem langschriftlichen Namen
    • dem Kurznamen (dieser wird Bestandteil des technischen Pfads)
    • einer Zuordnung zum übergeordneten Namensraum (Hierarchie)
    • einer Zuordnung einer verantwortlichen Stelle ("Control-Body") für diesen Namensraum
    • einem sog. "ID-Resolver", d.h. einem Muster, das aussagt, wie Objektidentifikatoren in diesem Namensraum "aufzulösen" sind (s.o. und unten dokumentierte Muster).
  • Für die Anzeige von Informationen zu registrierten Namensräume wird aus der Hierarchie zusätzlich auch eine Auflistung der untergeordneten Namensräume generiert, die sich automatisch ergibt.
  • Änderungen im Namensraum-Register werden gem. der in ISO 19135 beschriebenen Prozesse vorgenommen und ermöglichen so auch eine Historie und damit Nachverfolgbarkeit der vorgenommenen Änderungen. Folgende Prozesse kommen zum Einsatz:
    • Addition: Ergänzen eines neuen Namensraums
    • Supersession: Ändern von Informationen zu einem bestehenden Namensraum (die bisherigen Informationen werden als "Vorgänger" aufbewahrt; der Namensraum in der aktualisierten Fassung bildet den "Nachfolger")
    • Clarification: Ändern (Korrigieren) von Informationen zu einem bestehenden Namensraum (nur für ausgewählte Informationen wie z.B. Name und ID-Resolver; übergeordneter Namensraum und Control-Body sind darüber nicht änderbar; keine Bildung von "Vorgänger" und "Nachfolger")
    • Retirement: der Namensraum wird nicht mehr verwendet und im Register "aufgegeben", bleibt in der Historie aber sichtbar
  • alle vorgenannten Prozesse werden als sog. "Proposal" formuliert und müssen einen Genehmigungsweg durchlaufen. Für die Genehmigung zuständig ist der sog. "Control-Body", d.h. die für den jeweiligen Namensraum verantwortliche Stelle (bei Auswirkungen auf die Hierarchie ggf. auch die zuständige Stelle des übergeordneten Namensraums). Der Control-Body entscheidet und gibt das Proposal frei, kann es aber auch ablehnen oder eine Diskussion starten. Erst mit Genehmigung durch den Control-Body wird eine Ergänzung bzw. Änderung eines Namensraums wirksam!

"ID-Resolver" und URL-Muster:

  • Wie oben unter "Auflösung eines Objektidentifikators" beschrieben, können jedem Namensraum Aktionen bzw. Zugriffswege auf die Objekte zugeordnet werden.
  • Mittels der Einträge unter "ID-Resolver" können ein oder mehrere Muster für Dienst-Aufrufe für Objekte im jeweiligen Namensraum definiert werden.
  • Im einfachsten Fall gilt für alle Objekte eines Namensraums dasselbe Muster, d.h. für jedes Objekt wird derselbe Dienst-Aufruf ausgeführt.
  • Unterschiedliche Muster können in Frage kommen, um in Abhängigkeit vom Objektnamen (z.B. "beginnt mit 'A'") einen anderen Dienst-Aufruf zu generieren als für die übrigen Objekte.
  • In allen Fällen muss das Muster den Aufruf eines konkreten Dienstes beinhalten und den Objektnamen als Variable ${OID} im eigentlichen Request verwenden (siehe unten stehende Beispiele).
  • Die GDI-DE Registry bietet im Namensraum-Register die Möglichkeit, die URL-Muster entweder als GET- oder als POST-Requests zu formulieren. Welche Variante in Frage kommt, hängt vom dadurch jeweils angesprochenen Dienst ab!
  • Beispiele:

GET-Request für ein Metadatenobjekt:

unter "URL-Vorlage:

https://gdk.gdi-de.org/gdi-de/srv/csw?REQUEST=GetRecords&SERVICE=CSW&VERSION=2.0.2&OUTPUTSCHEMA=http://www.isotc211.org/2005/gmd&constraintLanguage=CQL_TEXT&constraint=ResourceIdentifier='https://registry.gdi-de.org/id/de.nw/${OID}'&constraint_language_version=1.1.0&typenames=csw:Record&resulttype=results&elementsetname=full#xpointer(//gmd:identificationInfo[1]/gmd:MD_DataIdentification)

individuell anzupassen sind:

      • die Adresse (URL) der aufzurufenden Katalog-Schnittstelle (hier im Beispiel der Geodatenkatalog.de)
      • der im Parameter "constraint" angegebene Namensraum (hier im Beispiel zu NRW: https://registry.gdi-de.org/id/de.nw): muss auf denjenigen Namensraum, für den dieses URL-Muster gelten soll, angepasst werden! Der nachfolgende "/" muss als Trenner zum eigentlichen Objektnamen (hier per Variabler ${OID} ausgedrückt) erhalten bleiben!


POST-Request für ein Metadatenobjekt:

unter "URL-Vorlage": http://portalu.saarland.de/csw?

unter "POST-Anfragedaten":

<?xml version="1.0"?>
<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" service="CSW" version="2.0.2" resultType="results" outputSchema="csw:IsoRecord">
    <csw:Query typeNames="csw:Record">
<csw:ElementSetName typeNames="">full</csw:ElementSetName>
<csw:Constraint version="1.1.0">
<Filter xmlns="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml">
<Or>
<PropertyIsLike escapeChar="\" singleChar="?" wildCard="*">
<PropertyName>apiso:ResourceIdentifier</PropertyName>
<Literal>https://registry.gdi-de.org/id/de.sl/${OID}
</Literal>
</PropertyIsLike>
</Or>
</Filter>
</csw:Constraint>
</csw:Query>
</csw:GetRecords>

individuell anzupassen sind:

      • die Adresse (URL) der aufzurufenden Katalog-Schnittstelle (hier im Beispiel der Katalog der GDI-SL)
      • der im Parameter "Literal" angegebene Namensraum (hier im Beispiel zu NRW: https://registry.gdi-de.org/id/de.sl): muss auf denjenigen Namensraum, für den dieses URL-Muster gelten soll, angepasst werden! Der nachfolgende "/" muss als Trenner zum eigentlichen Objektnamen (hier per Variabler ${OID} ausgedrückt) erhalten bleiben!


GET-Request für ein (INSPIRE-)Datenobjekt:

https://www.wfs.nrw.de/geobasis/wfs_nw_inspire-adressen_gebref?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&StoredQuery_id=urn:ogc:def:query:OGC-WFS::GetFeatureById&id=${OID}

individuell anzupassen ist:

    • die Adresse (URL) des aufzurufenden Download-Dienstes (hier im Beispiel ein INSPIRE-Download-Dienst der GDI-NW)
  • In allen gezeigten Beispielen gilt zusätzlich, dass im ID-Resolver aufgrund der Möglichkeit, für jeden Namensraum mehrere unterschiedliche ID-Resolver zu definieren, eine "Priorität" sowie ein "ID-Muster" anzugeben sind. Im einfachsten Fall (eine 1:1-Zuordnung zwischen Namensraum und ID-Resolver, d.h. für jedes Objekt in diesem Namensraum gilt das gleiche Muster für die Auflösung zu einem Dienst-Request), wird für "Priorität" der Wert "1" ausgewählt und das "ID-Muster" wie initial in der Oberfläche angegeben mit ".*" belegt, damit die angegebene URL-Vorlage für jedes Objekt gilt!



Kontakt und weiterführende Informationen

Bei weitergehenden fachlichen Fragen zur GDI-DE Registry wenden Sie sich bitte an den Support der GDI-DE.