Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

Bei gleichartigen Ressourcen verschiedener Stellen, z.B. Denkmale/Schutzgebiete bei Kommunen, sollten Absprachen über ein einheitliches Benennungsmuster getroffen und berücksichtigt werden. Dies ist auch für weitere Metainformationen wie Kurzbeschreibung, Schlüsselwörter, Herkunft etc. sinnvoll. Im Bereich der Vermessungsverwaltung existieren solche Regelungen beispielsweise.
Eine  Schlagwortsuche berücksichtigt dieses Feld häufig nicht. Daher empfiehlt es sich, den Titel der Ressource bzw.  die charakteristischen Bestandteile daraus  zusätzlich  auch  als Schlüsselwörter unter der Registerkarte „Kategorisierung“ zu erfassen.

...

Geodaten und Geodatendienste, die einen räumlichen Bereich in Form einer bestimmten Verwaltungseinheit abdecken, können über deren 12-stelligen Regionalschlüssel gezielt auffindbar gemacht werden, wenn der entsprechende Schlüssel in den Metadaten hinterlegt wird. Die Angabe in den Metadaten ist optional, wird aber empfohlen, um detaillierte Auswertungen im Zusammenhang mit dem INSPIRE-Monitoring zu ermöglichen.

...

  • Schlüsselwörtern mit Zuordnung zum gleichen Thesaurus sind in verschiedenen separaten Eingabefeldern zu gruppieren
  • Schlüsselwörtern ohne Thesaurus-Zuordnung werden in einem separaten eigenen Feld erfasst

Durch die Verwendung der Schaltfläche mit einem + Symbol  lassen sich für jeden Thesaurus und für freie Schlüsselwörter getrennte Eingabefelder anlegen.

...

Wenn die als „inspireidentifiziert“ gekennzeichneten Datensätze für die europäischen Berichtspflichten von besonderer Bedeutung sind, so müssen sie zusätzlich mit dem Schlüsselwort „Priority Data Set“ gekennzeichnet werden.

Datensätze, die unter Open Data fallen und mit entsprechenden Lizenz- bzw. Nutzungsbedingungen versehen sind, sollen nach Vorgaben des IT-Planungsrates mittels DCAT-AP.de als formalem Austauschformat beschrieben werden. Zur Vermeidung von Doppelerfassungen wurde in der GDI-DE eine Vorgehensweise etabliert, um die Metadaten via Geodatenkatalog.de automatisiert in das GovData-Portal des Bundes zu integrieren.

Metadaten müssen dazu in ausgewählten Elementen definierte folgende Inhalte aufweisen:

  • In den Schlüsselwörtern wird der Begriff „opendata“ eingetragen. Dieses freie Schlüsselwort ist keinem Thesaurus zugeordnet.
  • Die Angaben zur Lizenz werden als Nutzungsbedingung erfasst und zusätzlich strukturiert in genau einem Element im Datenformat JSON (JavaScript Object Notation) hinterlegt.
  • Zusätzlich zu den o.g. Anforderungen müssen Zugriffswege auf die Daten dokumentiert sein, die bei GovData als sog. „Distributionen“ (Online-Verfügbarkeit) dargestellt werden. Daher muss in den Metadaten mindestens eine der folgenden Verlinkungen existieren:
    • Eine Datensatzverknüpfung (Daten-Dienste-Kopplung) zu den Metadaten eines frei zugänglichen Dienstes für den (freien) Zugriff auf die dokumentierten Daten (s. 2.4.5.3.2.2.)
    • Link zum unmittelbaren Download der Daten

...

Werden die Angaben zu Open Data und die HVD-Kennzeichnung entsprechend dieser Vorgaben eingetragen, erfolgt die Übernahme der HVD-relevanten Metadatensätze automatisiert in das europäische Geoportal.

Verschiedene Weitere freie Schlüsselworte wie GDIMRH oder AdVMIS steuern darüber hinaus die automatisierte Übernahme von Metadaten aus dem GeoMIS.MV in andere Metadatenkataloge.

...

Die im GeoMIS.MV unter dem Werkzeugsymbol hinterlegte Liste beinhaltet jedoch weitaus mehr Begriffe als für INSPIRE relevant sind. Diese Einträge beziehen sich auf den Werteumfang der ISO-Norm. Für eine erfolgreiche Validierung bzgl. INSPIRE darf aber nur ein mit „INSPIRE ...“ beginnender Eintrag ausgewählt werden.  Die naheliegenden Auswahlmöglichkeiten zu OGC-konformen Diensten sollten hier nicht genutzt werden, sofern es sich um eine für INSPIRE relevante Ressource handelt und die Metadaten INSPIRE-konform sein sollen. Stattdessen können derartige Informationen im folgenden Feld „Version des Dienstes“ angegeben werden. Die Dokumentation eines Dienstes als „INSPIRE ... Service“ beinhaltet jedoch keine automatische Aussage, dass dieser Dienst die INSPIRE-Regelungen für die jeweilige Dienstart erfüllt. Dies wird erst durch eine entsprechende Angabe unter „Konformität“ (Registerkarte „Qualität“, s.5.5.2.4.) ausgedrückt.

...

Dieses Element ist mindestens einmal zu belegen und muss dabei . Es muss jene URL beinhalten, die den Aufruf des vom Dienst selbst bereitgestellten Dokumentes, das den Dienst beschreibt und automatisiert auswertbar ist, ermöglicht. Diese URL wird auch als Zugang zum Dienst verstanden. Dies kann 

  • die Basis-URL

...

  • sein, unter der mittels eines gezielten Requests das Capabilities-Dokument des Dienstes abgerufen werden kann. Im Gegensatz zum Element „Online-Ressource“ (V.1) ist hier lediglich die Basis-URL bis zum Fragezeichen und nicht der komplette Aufruf (z. B. mit „…SERVICE=WMS&REQUEST=GetCapabilities“) anzugeben. 
  • die vollständige URL sein, die zur Landing Page (OGC API-Features), zum Service-Feed (Atom-Feed) oder zu den Capabilities eines REST-Dienstes führt. 

Begleitet wird diese Angabe vom Element „Name der Operation“. Hierbei ist „GetCapabilities“ aus der Auswahlliste zu verwenden, wenn es sich bei der angegebenen URL um das Anfordern des Capabilities-Dokumentes (s.o., auch bei REST) handelt. Bei Atom-Feeds ist für „Name der Operation“ z. B. „Download“, bei OGC API-Features „LandingPage“ zu setzen. 
Weitere Elemente, d. h. Begleitet wird diese Angabe vom Element „Name der Operation“ = „GetCapabilities“ aus der Auswahlliste. Bei Atom-Feeds ist für „Name der Operation“ der entsprechende Wert „Download“, zu setzen.Weitere Elemente, wie eine URL mit Zuordnung zu anderen Operationen des jeweiligen Dienstes, sind optional möglichsind optional möglich, für die Metadaten selbst und deren Weiterverarbeitung aber nicht erforderlich.

5.3.2.2.      Datensatzverknüpfung (Z.3)
Anker
z3
z3

...

Wie schon unter 2.4. beschrieben, wird die Daten-Dienste-Kopplung auch benötigt, um bei Open Data-Ressourcen die zu den Daten zugehörigen Dienste (WMS, WFS, Atom-Feed,...) bzw. deren Metadaten auffinden zu können. Daraus wird während der Migration ein gemeinsamer Datensatz zur Übernahme in das GovData-Portal generiert.

...

Die Dokumentation von Beschränkungen im Sinne von „Bedingungen für den Zugang und die Nutzung“ bei INSPIRE erfolgt durch (a) die exklusive Auswahl von „andere Beschränkungen“ für das Feld „Nutzungseinschränkungen“ (Z.6) sowie (b) Angabe der Nutzungs- bzw. Zugangs-bedingungen Zugangsbedingungen als Freitext im Feld „Beschreibung“.

Im Falle von Open Data bietet der Editor des GeoMIS.MV an dieser Stelle eine Unterstützung für die Erfassung der Nutzungseinschränkungen Angaben zu den gebräuchlichsten freien Lizenzen (siehe 5.3.2.3.6.).

Auch das Nicht-Vorliegen von Zugangs- und Nutzungsbeschränkungen muss für INSPIRE entsprechend dokumentiert werden: per Referenzierung des in der INSPIRE-Registry hinterlegten Wertes im Feld „Link“ (als sog. gmx:Anchor-Element) und Angabe der deutschsprachigen Entsprechung „Es gelten keine Bedingungen“ im Feld „Beschreibung“. Die bisherige Erfassung nur per Freitext ist heute nicht mehr zulässig. Im Editor des GeoMIS.MV wird über das Werkzeugsymbol der entsprechende Inhalt in der vorgegebenen Schreibweise eingetragen.

...

Bei Metadaten zu OGC-Diensten gilt darüber hinaus: Aussagen über Zugriffs- und Nutzungsbeschränkungen sollen sollten identisch zu den Informationen im Capabilities-Dokument unter dem Tag „AccessConstraints“ abgebildet werden.

...

  • URL einer Webseite mit Detailinformationen zu den Daten, zum Dienst oder zur Anwendung;
  • bei Datenressourcen auch Downloadlinks, Bestellmöglichkeiten und/oder URL eines entsprechenden Dienstes
  • bei Diensten immer ein Link auf die Abfrage des Capabilities-Dokuments (ein den Dienst bzw. die Schnittstelle beschreibendes Dokument (z. B. Capabilities: hier der komplette Dienstaufruf mit dem Request „GetCapabilities“) bzw. zur Landing Page (bei OGC API-Features). Die Angabe erfolgt zusätzlich zu den Angaben unter „Operationen des Dienstes“ (Z.2) ist hier der komplette Dienstaufruf mit dem Request „GetCapabilities“ zu dokumentieren).

Die Metadatenkonventionen der GDI-DE [REF 4] sehen eine Angabe dieser Links zwar bisher nicht verpflichtend vor, ein fehlen wird in der GDI-DE Testsuite jedoch mit einer entsprechenden Warnung quittiert. Da für die Zukunft von einer Belegungspflicht auszugehen ist, wird an dieser Stelle für die GDI-MV bereits heute für Dienst-Metadaten empfohlen, hier den Link zur Abfrage des Capabilities-Dokuments zu hinterlegen.

Als Interpretationshilfe der Links für den Nutzer sollen diese Angaben mit der entsprechenden Funktion „Information“ bzw. „Download“ oder „Bestellung“ versehen werden.

Bei einen Atom-Download-Dienst ist an dieser Stelle die URL vom Service Feed anzugeben und bei einem OGC API-Features-Dienst die URL zur Landing Page einzutragen sowie unter Protokoll den Wert „OGC API Features“ auszuwählen.

5.4.2.2.      Format (V.2)
Anker
v2
v2

...

  •  Beschreibung: nähere Dokumentation des originären Datensatzes und ggf. eine Information, welche Teile aus diesem in den neuen Datensatz überführt wurden.
  • Titel: (Metadaten-)Titel des originären Datensatzes, aus dem die hier beschriebenen Daten abgeleitet wurden.
  • Datum und Datumstyp: Stand der verwendeten Daten (diese werden i.d.R. selbst auch fortgeführt; so kann der genaue Stand dokumentiert werden)
  • Code: Dies ist hier das wichtigste Element! Darüber werden die Metadaten des originären Datensatzes referenziert. Dies geschieht in Form des Ressourcenidentifikators, der gem. B.16 19 für die Metadaten des originären Datensatzes vergeben worden ist.

...