Raumordnerische, landschaftsplanerische und städtebauliche Pläne und auch ihre Änderungen einzeln zu beschreiben kann durchaus sinnvoll sein, ist jedoch keine Bedingung. Eine große Anzahl an Metadaten garantiert noch keine gute Auffindbarkeit der Daten. Metadaten können jedoch strukturiert abgebildet werden, was eine spätere Auffindbarkeit einer benötigten Information zum Plan erleichtern kann. So können Metadatensätze (children) über einen zusätzlich angegebenen <parentIdentifier> verfügen. Der <parentIdentifier> bezieht sich auf einen thematisch übergeordneten Metadatensatz (parent). Wenn Kind-Datensätze (children) den gleichen <parentIdentifier> besitzen, bilden sie eine verwandte Gruppe an Metadaten, die z.B. eine räumliche und / oder inhaltliche Einheit bilden. Diese hierarchische Beziehung der Metadaten untereinander kann in einer GUI (Graphical User Interface, graphische Benutzeroberfläche) abgebildet werden und zum inhaltlichen Verständnis der Beschreibungen beitragen.

Die Anzahl an Metadaten wird durch verschiedene Faktoren, wie beispielsweise ihre Ausprägung als Raster- oder Vektordaten und ihre INSPIRE-Relevanz und der damit verbundenen Transformierbarkeit beeinflusst. Es ist daher wichtig vorab zu analysieren, welche Verständnis-Vorteile sich aus dem Vorhandensein von bestimmten Metadaten für die jeweiligen Daten ergeben. Beispielsweise lassen sich Metadaten nutzen, um Listen aller vorhandenen Pläne mit ergänzenden Angaben wie dem Datum der Rechtskraft oder einem zugehörigen Kartenausschnitt gesondert zu präsentieren - auch in anderen Portalen wie beispielsweise einem UVP-Portal (UVP=Umweltverträglichkeitsprüfung).

Fachlich standardisierte komplexe Geodaten ohne einheitliches Datenmodell (z. B. Pläne)

Pläne wie ein Bebauungsplan, Flächennutzungsplan, Raumordnungsprogramm, Landschaftsrahmenplan u. w. haben einen per Gesetz definierten fachlich homogenen Inhalt. Das Datenmodell, in dem sie geführt werden, kann jedoch insbesondere bei alten und damit sehr langlebigen Plänen unterschiedlich sein. In ihrer Gruppe gesehen bilden Pläne nach einer Transformation in ein Zielmodell jedoch stets gleichförmige neue Datensätze. Alte Pläne (Scans) sind nur zum Teil transformierbar. Neue Pläne werden hingegen immer als Vektordatensätze erfasst/bereitgestellt. Hier kann auch der eigentliche Planinhalt in ein anderes Datenmodell transformiert werden. Ein einziger Plan wie ein Landschaftsrahmenplan kann im Original aus sehr vielen einzelnen Datenbeständen bestehen, die ihrerseits einzeln mit Metadaten zu beschreiben sind oder beschrieben werden können. Eine Beschreibung dieser einzelnen Daten mit Metadaten sollte immer dann erfolgen, wenn die Beschreibung "nützlich" ist und eine verbesserte Auffindbarkeit der Daten garantiert.

Fachlich standardisierte komplexe Geodaten in einem einheitlichen Datenmodell (XPlanung)

Je nachdem, ob der Ursprungsplan transformierbar war, ergibt ein Plan mindestens einen Umring (INSPIRE Spatial Plan). Bei Plänen, die als Vektoren vorliegen, kann zusätzlich der Planinhalt in ein anderes Datenmodell überführt werden. Liegt der Originalplan noch nicht in XPlanGML vor, wird aus den Originaldaten entweder eine on-the-fly Ableitung nach XPlanGML erstellt oder aber der Plan wird dauerhaft nach XPlanGML überführt (in der Regel also neu erfasst) und fortan nur noch in diesem Datenmodell verwendet. Neue Pläne werden bereits originär im Datenmodell XPlanung erstellt. Da sie fachlich den gleichen Inhalt aufweisen, ergeben Vektoren in XPlanGML immer gleichförmige neue Datensätze im INSPIRE-Datenmodell. Regionale Raumordnungsprogramme (RROP in Niedersachsen) setzen sich nach ihrer Transformation nach INSPIRE nur aus Spatial Plan, Supplementary Regulation und ggf. einer Official Documentation zusammen. Flächennutzungspläne (FNP) beinhalten bei vollständiger Transformation zusätzlich ein Zoning Element. 

Tatsächlich werden also aus "einem Plan" bei entsprechendem Bedarf aus XPlanung oder INSPIRE PLU eine Reihe von Ableitungen in andere Datenmodelle erstellt. Aus der XPlanGML-Variante eines Plans kann per Transformation automatisiert INSPIRE PLU (Planned Land Use) abgleitet werden. Die folgenden Abbildungen illustrieren diesen Vorgang:

Standardisierte Bereitstellung der Daten per Dienst

Grundsätzlich werden alle Pläne per Dienst bereitgestellt. Dadurch ergibt sich in diesem Beispiel eine Anzahl von 6 Dienst-Metadaten, die für die vollständige Bereitstellung eines Plans (Annex-Thema Bodennutzung) in der Praxis notwendig sind. Demnach müssen Dienst-Metadaten zu den folgenden Zugriffsmöglichkeiten vorhanden sein:

• den Darstellungsdienst (Originalplan),
• den Downloaddienst (Originalplan),
• den Darstellungsdienst (XPlanGML),
• den Downloaddienst (XPlanGML),
• den Darstellungsdienst (INSPIRE PLU) und
• den Downloaddienst (INSPIRE PLU)

Die INSPIRE-Dienste beinhalten ihrerseits die entsprechenden Ebenen für Spatial Plan, Supplementary Regulation und ggf. ein Zoning Element.

Um am Beispiel des INSPIRE-Dienstes die Vorgaben der Daten-Dienste-Kopplung im Dienst-Metadatensatz zu erfüllen, wird im Metadaten-Element <operatesOn> eine Verknüpfung (Kopplung) zu den Daten-Metadaten durchgeführt. Diese Kopplung kann grundsätzlich 1:1 (also pro Ebene im Dienst ein Daten-Metadatensatz) oder 1:n (für mehrere Ebenen im Dienst den gleichen Daten-Metadatensatz) erfolgen. In den GetCapabilities des Dienstes kann also ausgehend von mehreren Ebenen auf den gleichen Daten-Metadatensatz verwiesen werden. Im Dienst-Metadatensatz ist dieser Daten-Metadatensatz nur einmal über das Element <operatesOn> gekoppelt.

Ob eine Kopplung 1:1 oder 1:n erfolgt, ist auch abhängig von der Ausgestaltung der Daten-Metadaten und der dargestellten Konformitätserklärung im Daten-Metadatensatz: Ein Nutzer muss, wenn er sich für eine Ebene interessiert über die Metadaten herausfinden können, welche Daten für die Darstellung oder den Download verwendet werden.

Möglichkeiten der Reduzierung bei INSPIRE-Metadaten?

Wird beispielweise die Konformitätserklärung für INSPIRE direkt am Daten-Metadatensatz, die den Original-Plan beschreibt, angefügt, so kann auf einen (oder zwei bis drei für die Ebenen Spatial Plan, Supplementary Regulation und ggf. ein Zoning Element) speziellen Daten-Metadatensatz für die INSPIRE-Umsetzung dieses Plans verzichtet werden.

In der "Abb. 1 Metadaten" stehen rote Kästen für Dienst-Metadaten und damit zugleich Dienste-URLs (also die Dienste an sich), der blaue Kasten zeigt den Daten-Metadatensatz. Hinter dem Datensatz kann sich aus technischer Sicht eine Vielzahl an tatsächlichen Dateien oder nur eine einzige Datei (z. B. ein Scan) verbergen. Sowohl der Darstellungs- als auch der Downloaddienst verweisen ausschließlich auf diesen einen Daten-Metadatensatz. Dies ist möglich, weil davon ausgegangen werden kann, dass die gleiche Art von Plan (z. B. B-Plan, FNP, Raumordnungsplan usw.) immer auch die gleiche Ausprägung an INSPIRE-Daten hervorbringt. Es ist damit nicht zwingend, jede einzelne INSPIRE-Datenschicht (Spatial Plan, Supplementary Regulations und ggf. ein Zoning Element) einzeln erneut und immer wieder für jeden Plan zu beschreiben. In einer GDI geht es immer auch darum, Redundanzen zu vermeiden.

Beispiel einer doppelten Konformitätserklärung (für XPlanGML und INSPIRE PLU) in einem Daten-Metadatensatz:

(bei Bedarf bitte die Quelle aufklappen)

<!-->Bitte richten Sie sich bei der konkreten Ausgestaltung nach den Vorgaben der "GDI-DE Konventionen zu Metadaten".<-->
<gmd:dataQualityInfo>
	<gmd:DQ_DataQuality>
		<gmd:scope>
			<gmd:DQ_Scope>
				<gmd:level>
					<gmd:MD_ScopeCode codeListValue="dataset" codeList="http://www.isotc211.org/2005/resources/codeList.xml#MD_ScopeCode"/>
				</gmd:level>
			</gmd:DQ_Scope>
		</gmd:scope>
		<gmd:report>
			<gmd:DQ_DomainConsistency>
				<gmd:result>
					<gmd:DQ_ConformanceResult>
						<gmd:specification>
							<gmd:CI_Citation>
								<gmd:title>
									<gco:CharacterString>XPlanung Version 5.3</gco:CharacterString>
								</gmd:title>
								<gmd:date>
									<gmd:CI_Date>
										<gmd:date>
											<gco:Date>2020-11-16</gco:Date>
										</gmd:date>
										<gmd:dateType>
											<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode" codeListValue="publication"/>
										</gmd:dateType>
									</gmd:CI_Date>
								</gmd:date>
							</gmd:CI_Citation>
						</gmd:specification>
						<gmd:explanation>
							<gco:CharacterString>Diese Daten werden auch in XPlanGML 5.3 zur Verfügung gestellt.</gco:CharacterString>
						</gmd:explanation>
						<gmd:pass>
							<gco:Boolean>true
							</gco:Boolean>
						</gmd:pass>
					</gmd:DQ_ConformanceResult>
				</gmd:result>
				<gmd:result>
					<gmd:DQ_ConformanceResult>
						<gmd:specification>
							<gmd:CI_Citation>
								<gmd:title>
									<gco:CharacterString>VERORDNUNG (EG) Nr. 1089/2010 DER KOMMISSION vom 23. November 2010 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Interoperabilität von Geodatensätzen und -diensten</gco:CharacterString>
								</gmd:title>
								<gmd:date>
									<gmd:CI_Date>
										<gmd:date>
											<gco:Date>2010-12-08</gco:Date>
										</gmd:date>
										<gmd:dateType>
											<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode" codeListValue="publication"/>
										</gmd:dateType>
									</gmd:CI_Date>
								</gmd:date>
							</gmd:CI_Citation>
						</gmd:specification>
						<gmd:explanation>
							<gco:CharacterString>Die Daten entsprechen dem INSPIRE Datenmodell.</gco:CharacterString>
						</gmd:explanation>
						<gmd:pass>
							<gco:Boolean>true
							</gco:Boolean>
						</gmd:pass>
					</gmd:DQ_ConformanceResult>
				</gmd:result>
			</gmd:DQ_DomainConsistency>
		</gmd:report>
		<gmd:report>
			<gmd:DQ_DomainConsistency>
				<gmd:result>
					<gmd:DQ_ConformanceResult>
						<gmd:specification>
							<gmd:CI_Citation>
								<gmd:title>
									<gco:CharacterString>XPlanung Version 5.3</gco:CharacterString>
								</gmd:title>
								<gmd:date>
									<gmd:CI_Date>
										<gmd:date>
											<gco:Date>2020-11-16</gco:Date>
										</gmd:date>
										<gmd:dateType>
											<gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode" codeListValue="publication"/>
										</gmd:dateType>
									</gmd:CI_Date>
								</gmd:date>
							</gmd:CI_Citation>
						</gmd:specification>
						<gmd:explanation>
							<gco:CharacterString>Diese Daten werden auch im XPlanGML 5.3 zur Verfügung gestellt</gco:CharacterString>
						</gmd:explanation>
						<gmd:pass>
							<gco:Boolean>true
							</gco:Boolean>
						</gmd:pass>
					</gmd:DQ_ConformanceResult>
				</gmd:result>
			</gmd:DQ_DomainConsistency>
		</gmd:report>
	<!-->Der ab hier folgende Bereich zeigt keine verbindliche Ausführung der nachfolgenden Elemente!<-->
		 <gmd:lineage>
			<gmd:LI_Lineage>
				<gmd:statement>
					<gco:CharacterString>Woher stammen die Daten?</gco:CharacterString>
				</gmd:statement>
				<gmd:source>
					<gmd:LI_Source>
						<gmd:description>
							<gco:CharacterString>Welche Baunutzungsverordnung gilt für diesen B-Plan?</gco:CharacterString>
						</gmd:description>
						<gmd:scaleDenominator>
							<gmd:MD_RepresentativeFraction>
								<gmd:denominator>
									<gco:Integer>1000</gco:Integer>
								</gmd:denominator>
							</gmd:MD_RepresentativeFraction>
						</gmd:scaleDenominator>
					</gmd:LI_Source>
				</gmd:source>
			</gmd:LI_Lineage>
		</gmd:lineage>
	</gmd:DQ_DataQuality>
</gmd:dataQualityInfo>
</gmd:MD_Metadata>

Falls die Konformität wie im Beispiel mit einem Bezug zum Datenmodell XPlanung angegeben werden soll, sind laut Auskunft der XLeitstelle (Leitstelle XPlanung / XBau) zusätzlich die folgenden Publikationsdatumsangaben für die jeweiligen Versionen des XPlanGML-Datenmodells im Daten-Metadatensatz zu führen:

Wie viele Metadaten muss es geben?

Wie viele Metadaten es für Daten und Dienste geben "muss", ist differenziert zu betrachten.

Festgelegte Anzahl Dienst-Metadaten

Dienst-Metadaten sind in erster Linie „Vehikel“, um die gefundenen Daten bereit zu stellen. Jedoch benötigt jeder Dienst zwingend (also jede URL, die einen Dienst darstellt) einen eigenen Dienst-Metadatensatz. Die semantische (inhaltliche) Ausgestaltung eines Dienst-Metadatensatzes ist nachrangig, da der fachliche Inhalt sich im Rahmen der Daten-Dienste-Kopplung aus den Daten-Metadaten ergibt. Es ist allerdings darauf zu achten, dass die technischen Informationen im GetCapabilities-Dokument des Dienstes denen im Dienst-Metadatensatz entsprechen.

In der Praxis werden Dienst-Metadaten vorrangig automatisiert erstellt. Entweder werden die technisch-inhaltlichen Angaben im GetCapabilities-Dokument des Dienstes gepflegt und in die Dienst-Metadaten übernommen oder aber, die technisch-inhaltlichen Angaben werden im Metadatensatz gepflegt und daraus werden die Inhalte im GetCapabilities-Dokument abgeleitet. Auch die Daten-Dienste-Kopplung kann automatisiert übernommen werden. In welcher Granularität (Kopplung 1:1 oder 1:n) es jedoch eine Daten-Dienste-Kopplung gibt, ist eine Frage dessen, was man selbst als Datenhalter oder in einem Verbund von Datenhaltern (wie zum Beispiel in einem Landkreis oder in einem Bundesland) damit erreichen möchte. Letztlich ist es eine Frage der Nützlichkeit für den konkreten Anwender. Nur Dinge, die hilfreich sind und genug Informationen bieten, werden allgemein akzeptiert und in der Regel gerne angenommen. Alle Ebenen eines Dienstes sind ausreichend mit Metadaten beschrieben, wenn ein Nutzer klar erkennen kann, welche Daten er vor sich hat.

Variable Anzahl Daten-Metadaten

Daten können grundsätzlich unterschiedlich beschrieben werden und die Anzahl der Daten-Metadaten, die daraus resultiert, ist nicht eindeutig festgelegt. Gleichförmige Daten, die sich lediglich durch ihre Lage im Raum und damit im Hinblick auf ihre BoundingBox im Metadatensatz unterscheiden, sind nur einmal zu beschreiben. Pläne, die in großer Anzahl in einer Gemeinde vorzufinden sind (z. B. Bebauungspläne), lassen sich so rasch "ausreichend" beschreiben. Wirklich?

Metadaten für einzelne Pläne (ein einzelner B-Plan) bieten ein Mehr an Information. Die Vorteile der Einzelbeschreibung ergeben sich in der aktuellen Praxis in erster Linie in Bezug auf die Ausprägung eines Plans als Original-Plan oder als Plan im Datenmodell XPlanGML. Ein Metadatensatz für einen Plan oder dessen Änderungen kann darüber Aufschluss geben, in welcher technischen Form (z. B. XPlanGML-Version, Rasterscan, GIS- oder CAD-Daten) jeder einzelne Plan vorliegt und wo genau sich das Planungsgebiet befindet. Hinzu kommen weitere Details wie das Datum der Rechtskraft des Plans oder eine Angabe zur Baunutzungsverordnung, die zur Interpretation genau dieses Plans herangezogen werden muss. Änderungen von Plänen können so direkt Bezug nehmen auf denjenigen Plan, den sie ändern. Selbst Pläne, die sich erst in der Vorbereitungsphase befinden, können mit Metadaten beschrieben werden und z. B. die öffentliche Auslegung unterstützen, indem weiterführende Informationen zu Öffnungszeiten der Gemeinde hinterlegt werden oder aufgezeigt wird, über welche Medien zum Plan binnen welcher Frist Stellung genommen werden kann. Alle erläuternden Texte zum Plan, ja sogar pdf-Begleitkarten, können im Metadatensatz verlinkt und somit direkt auffindbar über das Element <transferOptions> angeboten werden.

Werden alle Bebauungspläne einer Gemeinde zusammenhängend in einem Daten-Metadatensatz beschrieben (parent), umfasst diese Beschreibung die größte Ausdehnung aller ggf. vorhandenen Einzelpläne (children). Ob die Metadten für die konkreten Pläne später auch relevant für die Beschreibung der Dienste-Inhalte sind, ist abhängig vom Aufbau der Dienste. Bei gleichförmigen Daten ist eine zusammenfassende Beschreibung mit Metadaten ausreichend.

Stellt der INSPIRE-Dienst die Ebenen Spatial Plan, Supplementary Regulation und ggf. weitere also für das gesamte Gebiet der Gemeinde bereit, so erfolgt die Daten-Dienste-Kopplung aus dem Dienst-Metadatensatz über <operatesOn> nur auf diesen parent-Daten-Metadatensatz. Folglich muss auch nur dieser übergeordnete Daten-Metadatensatz (parent) als "inspireidentifiziert" gekennzeichnet werden und in diesem Metadatensatz erfolgt auch eine positive Konformitätserklärung auf die einschlägige INSPIRE Verordnung 1089/2010 (und damit auch den zugehörigen Änderungsverordnungen).

Stellt ein Dienst jedoch für jeden einzelnen Plan separate Ebenen bereit, was insbesondere für die Originaldaten in der Praxis hilfreich ist, muss auch auf die Metadaten der Einzelpläne per <operatesOn> Bezug genommen werden. Hier sollte in den Einzelplan-Metadaten ebenso die Konformität zu INSPIRE erklärt werden, wenn die Daten in INSPIRE PLU über Dienste verfügbar sind. Ob diese Metadaten mit "inspireidentfiziert" zu kennzeichnen sind, ist abhängig davon, ob auch der INSPIRE-Dienst einzelne Ebene zu den Einzelplänen enthält.

Eine Verknüpfung von verwandten Daten mit Hilfe des <parentIdentifier> ist unabhängig von INSPIRE einsetzbar und ist für alle Metadaten in einer GDI zulässig, unabhängig vom System ihrer Erstellung. Daten, die einen Sinnzusammenhang ergeben, können jederzeit über einen <parentIdentifier> zusammengefasst werden, um sie so zu einem späteren Zeitpunkt zusammenhängend darstellen zu können. Zusätzlich kann die Daten-Dienste-Kopplung ausgewertet und graphisch in einer Oberfläche dargestellt werden, um Zusammenhänge aufzuzeigen und Daten-Metadaten in ihrem Sinnzusammenhang zu präsentieren.

Beispiel für eine Parent-Child-Beziehung bei Daten-Metadaten zu Bebauungsplänen:

Bebauungspläne in der Gemeinde Adorf in der Übersicht (parent)

Bebauungsplan 1 "Haupststraße" der Gemeinde Adorf (child zu 'Bebauungspläne in der Übersicht')

Bebauungsplan 2 "Kirche" der Gemeinde Adorf (child zu 'Bebauungspläne in der Übersicht'; parent zu 'Änderungen zum Bebauungsplan 2')

Erste Änderung zum Bebauungsplan 2 "Kirche" der Gemeinde Adorf (child zu 'Bebauungsplan 2 "Kirche"')

Zweite Änderung zum Bebbaungsplan 2 "Kirche" der Gemeinde Adorf (child zu 'Bebauungsplan 2 "Kirche"')

Bebaungsplan 3 "Am Ufer" der Gemeinde Adorf (child zu 'Bebauungspläne in der Übersicht')

Beispiel für Parent-Child-Beziehungen bei Daten-Metadatensätzen zu den Bebauungsplänen eines kompletten Landkreises:

https://geoportal.geodaten.niedersachsen.de/harvest/srv/ger/catalog.search#/metadata/b37bbd43-31d0-4fb5-93ca-436ee0a98ddf

Beispiel für Beziehungen zwischen Daten und Diensten für ein Raumordnungsprogramm (RROP) wie in "Abb. 2 Metadaten":

https://geoportal.geodaten.niedersachsen.de/harvest/srv/ger/catalog.search#/metadata/8ad0f516-b353-47d6-84ed-4fe2ca48f3c6

In der "Abb. 2 Metadaten" stehen rote Kästen für Dienst-Metadaten und damit zugleich Dienste-URLs (also die Dienste an sich), die blauen Kästen zeigen Daten-Metadatensätze, hinter denen sich zusätzlich eine unbestimmte Anzahl von weiteren Daten-Metadaten, die über den <parentIdentifier> gekoppelt sind verbergen können.  Im Beispiel wird mit einem Metadatensatz für die Official Documentation (gemäß INSPIRE) die Chance wahrgenommen, sämtliche ergänzenden Dokumente für den Plan ebenfalls über Metadaten zugänglich zu machen, ohne dadurch aber den Daten-Metadatensatz für den Plan an sich zu überfrachten.

Fazit

Es gilt bei der Metadatenerstellung stets der Grundsatz: Alles, was per Dienst bereitgestellt wird, ist verständlich und nachvollziehbar zu beschreiben! Daraus resultiert zwar eine feste Anzahl an Dienst-Metadaten, aber keine feste Anzahl von Daten-Metadatensätzen.

Eine große Anzahl an Metadaten allein garantiert noch keine gute Auffindbarkeit von Daten in einer GDI. Daher können Metadaten untereinander strukturiert oder aber schlicht in kompakter Form erstellt werden. Je komplexere Möglichkeiten es gibt, Daten zu beschreiben, desto mehr wächst die Gefahr, dass Metadaten, die per GUI präsentiert werden, nicht mehr durch einen Menschen interpretiert werden können. Im Normalfall kann und möchte niemand „hinter die Kulissen“ (also hinter die GUI) auf das XML eines Metadatensatzes schauen. Dopplungen von Informationen innerhalb unterschiedlicher Elemente eines Metadatensatzes sind unschädlich. Sie können aber durchaus nützlich für die Darstellung von Inhalten per GUI sein. Dies gilt auch für einen möglichen <parentIdentifier>, mit dessen Hilfe Gruppen von inhaltlich-technisch verwandten Daten für eigene Verarbeitungszwecke zusammengefasst und so im Sinnzusammenhang präsentiert werden können. Gerade bei komplexen Plänen wie z.B. Landschaftsrahmenplänen finden sich viele Daten, die erst zusammen eine konkrete Aussage zulassen.

Eine Ausnahme bilden Hilfsdaten, die ausschließlich der kartographischen Gestaltung von Plänen dienen. Sie sind in der Regel nicht mit Metadaten zu beschreiben. Gegebenenfalls sind sie zusammen mit den Hauptdaten zu erwähnen und bereitzustellen. Die Ebenen, die ein Dienst bereitstellt, sind immer mit Metadaten zu beschreiben. Bilden Ebenen einen Sinn- und Verarbeitungszusammenhang, so kann auf eine einzelne Beschreibung durchaus verzichtet werden. Es ergibt sich dann eine 1:n Beziehung in der Daten-Dienste-Kopplung. Wurden Ebenen, die an sich einen Sinnzusammenhang darstellen, einzeln beschrieben, können diese per <parentIdentifier> inhaltlich zusammengefasst werden. Dies gilt insbesondere dann, wenn die Daten so feingranular gestaltet sind, dass sie außerhalb des Sinnzusammenhangs kaum verstanden / begriffen werden können. Der <parentIdentifier> erlaubt es einer GUI, die Datenbeschreibungen im Verbund abzubilden und somit in ihrer Gesamtheit und unabhängig von ihrer INSPIRE-Relevanz auffindbar zu machen.