Integration von Daten-Tests aus dem INSPIRE Validator in die neue GDI-DE Testsuite

Vielen Dank, Frau Hogrebe für die Veröffentlichung der Fragestellung im Wiki.  Ich hoffe, auf rege Diskussion. Auf den Kontaktstellentreffen hatten wir uns ja dafür ausgesprochen.

Ich hatte bislang einen Austausch mit Peter Kochmann. Hierdurch habe ich den Hintergrund etwas besser verstanden und zwar dahingehend, dass aktuell in der Testsuite der GDI-DE bei den Datentests nach seiner Einschätzung zu wenige Konformitätsklassen (CC) vorgesehen sind um "Interoperabilität" zu erreichen.

Was ich nicht verstehe:

• Warum quälen wir uns mit der Entscheidung und binden nicht genau die CC aus dem INSPIRE-(Reference-)Validator ein, die dort vorgesehen sind. Das umfasst m.E. auch die Einstufung in „verpflichtend“ und „optional“. Das, was die GDI-DE zuätzlich möchte wäre das "on top".

• Warum schätzen Sie die Nachbildung der CC aus dem INSPIRE-Validator (im Datenbereich)  als „schwer umsetzbar“ ein? Das beinhaltet die Frage, wie diese Nachbildung oder Einbindung der CC  erfolgt. Ist das ein aufwändiger schwer zu „korrigierender“, also zu ändernder Schritt?

Ich habe inzwischen exemplarisch für das Thema Adressen eine Tabelle der im EU-Validator möglichen "Einstiege" in die Tests erstellt und die abhängigen, d.h. jeweils automatisch zugeordneten Konformitätsklassen dokumentiert. Dazu eine Gegenüberstellung der Auswahlmöglichkeiten in der momentanen Realisierung zur neuen Testsuite (Stand aus "Anwenderakzeptanztest").

Für mich ergibt sich die Schlussfolgerung, dass es keinen Sinn hat, nur die Konformitätsklasse "INSPIRE GML encoding" verpflichtend vorzusehen und alle weiteren Konformitätsklassen (sowohl "General requirements" als auch themenbezogen) optional und wild kombinierbar anzubieten. Ich halte eine höhere Mindestanforderung und auch tlw. Zuordnung untereinander (wie im EU-Validator, bei dem es z.B. kein "Data consistency" ohne zusätzlich "Data consistency General requirements" gibt) für notwendig.

Der Vorschlag aus NRW (den ich in o.g. Tabelle als "A" dokumentiert habe) wäre daher, ein Mindestmaß zu schaffen, das alle GML- und Application schema-Tests verpflichtend beinhaltet, da ich diese als Grundvoraussetzung für interoperable Daten betrachte. Die "große Lösung" (B) wäre sogar, alle Konformitätsklassen verpflichtend vorzusehen, um immer gegen den höchsten Anspruch zu testen. Wozu gibt es diese Tests sonst?

Was ein guter und vor allem fachlich sinnvoller Weg ist, sollte aber letztlich z.B. durch die AG Geodaten bewertet werden, da mir die Relevanz der Stichpunkte "Data consistency", "Information accessability" und "Reference systems" in diesem Kontext nicht bekannt ist.

Ups, ich hatte übersehen, dass du erläutert hast, Peter. Danke.

O.K. Wichtig erscheint mir, dass am Prüfergebnis erkennbar wird, welcher einzelne Testschritt beanstandet wird und ob es sich um eine optionale oder verpflichtende Anforderung handelt. Darf ich mir das so vorstellen? Das hieße, wir durchlaufen verpflichtend alle CC, erkennen aber im Fehlerfalle ob eine Pflichtangabe verletzt wurde (und natürlich welche). (Ich finde den EU-Validator nach einem ersten Test eines interoperablen ATOMS ziemlich überzeugend).

In der GDI-Be fehlt es bislang leider an der Beschäftigung mit der neuen Testsuite. Daher fehlt offenbar die Vorstelllungskraft.

Aus Sicht der Kontaktstelle Brandenburg möchten wir hierzu folgende Einschätzung geben:

Um eine Konformität zu den Datenspezifikationen vollumfänglich bewerten zu könne, sollten natürlich auch alle Test durchlaufen werden. Prinzipiell ist es wünschenswert, die Auswahlmöglichkeiten des INSPIRE-Validators auch in der neuen Testsuite abzubilden. Wenn die technische Umsetzung jedoch einen unverhältnismäßig hohen Aufwand bedeutet, kann ein Kompromiss gefunden werden.

Die Frage optional/verpflichtend stellt sich unserer Ansicht nach vor allem aus Nutzersicht: Dabei sollte unterschieden werden nach a) dem versierten Experten, welcher die tieferen Zusammenhänge sowohl verstanden als auch vor Augen hat und b) einem Nutzer, dem die Zusammenhänge nicht augenscheinlich klar sind.

• Alle (eigentlich bedingten) Testklassen optional: Nutzer a) hat mehr Flexibilität beim Testen, Nutzer b) „übersieht“ wohlmöglich Testklassen und denkt, seine Daten seien hinreichend getestet.
• Alle Testklassen verpflichtend: Nutzer a) hat keine Flexibilität beim Testen, Nutzer b) kann keine Testklassen „übersehen“.

Letztlich handelt es sich also um eine Abwägung zwischen Bedienkomfort und Absicherung einer korrekten Interpretation des Test-Settings. Wir neigen dazu, eher mehr Vorgaben zu machen als zu wenige (Variante „B“ aus NRW). Mit der Variante „A“ aus NRW können wir uns aber auch anfreunden. Ein entsprechender Hinweis auf die Abhängigkeiten / Vollständigkeit darf dann aber nicht fehlen.

Unabhängig von dem Vorangestellten sollte das Augenmerk auf die Präsentation der Validierungsergebnisse gelegt werden. Rückmeldungen des Systems müssen leicht verständlich und eindeutig sein, damit die testende Person weiß, was wo zu ändern ist. Wie gut dies gelingt, wird Einfluss auf die Nutzerakzeptanz des Produktes haben.

Zusätzliche Frage: Liegen die Ergebnisse aus der Umfrage "Bedarf bezüglich Qualitätssicherung und spezifischer Auswertungen des INSPIRE-Monitoring" bereits vor und haben diese Auswirkungen auf die aktuelle Diskussion?

Besten Dank und Grüße!

PS: Wir nähern uns dem Thema Validierung der Konformität von interoperablen Daten erst noch. Dies ist auch der Tatsache geschuldet, dass bislang häufig nur beta-Versionen von Testtools vorliegen und Testklassen erst auszugsweise umgesetzt wurden. Daher stehen unsere folgenden Hinweise unter dem Vorbehalt, dass wir den Sachverhalt möglicherweise nicht vollumfänglich korrekt erfasst haben …

Liebe Kolleginnen und Kollegen,

zur Vervollständigung der Diskussionsseite möchte ich gerne noch die Rückmeldung aus dem AK Architektur zum Thema einbringen:

1) Beitrag aus Hamburg

In Hamburg werden folgende CC zZt zum Testen der Interoperabilität genutzt.  
Für Annex-I-Themen: Alle Tests des entsprechenden Blocks, hier zB die vier Tests zu Adressen:

 Für Annex II und III Themen: Alle vier Tests dieses Blocks (weil es keine speziellen Tests gibt):

Wenn man diese Praxis auf die GDI-Testsuite überträgt, wäre grundsätzlich der Spezialtest verpflichtend (und nicht nur General requirements). Nur wenn es keinen Spezialtest gibt, genügen die General requirements.

2) Beitrag aus ST

• lediglich die Konformitätsklasse „INSPIRE GML Encoding“ bei Einstieg via jeweiligem Annex-Thema verpflichtend vorzusehen, erscheint nicht zielführend,
• weiterhin sollten mindestens GML- und Application Schema Tests zu den Annex-Themen verbindlich sein,
• Variante "A" könnte demnach zu favorisierenden Vorschlag darstellen, wobei zu erwarten ist, dass durch die eigenständige Auswahlmöglichkeit weiterer optionaler Testklassen die bundesweite Interoperabilität nicht einheitlich getestet wird,
• Frage: um vollumfänglich (bundesweit einheitlich) zu testen, wäre folglich Variante "B" zu verfolgen?
• aber die Integration von Daten-Tests in die Testsuite wäre nur zwingend erforderlich, wenn im Datenbereich GDI-DE spezifische Erweiterungen existieren, da der Validator bereits für eine vollumfängliche Prüfung der INSPIRE-Konformität im Datenbereich zur Verfügung steht,
• einzig die Gewährleistung/Erfüllung der Interoperabilitätsvorgaben in Zuständigkeit bzw. Eigenregie der einzelnen Geodaten haltenden Stellen (selbst) könnte aufgrund der englischsprachigen Dokumentationen/Fehlermeldungen bei der europäischen Lösung eine größere Herausforderung für die Akteure darstellen

• existieren keine GDI-DE spezifischen Erweiterungen, sollte aus Gründen der Aufwandsminimierung (Berücksichtigung sparsamer Umgangs mit finanziellen und personellen Ressourcen) abgewogen werden, ob die Integration von Datentests aus dem INSPIRE Reference Validator in die GDI-DE Testsuite wirklich erforderlich ist

3) Beitrag aus BW

Das Verhalten vom INSPIRE Reference Validator bei Interoperabilitätstests (Testen von Datenspezifikationen der Annex Themen) sollte identisch auf die GDI-DE Testsuite übertragen werden.

Begründung:
o   somit wäre das Testverhalten identisch mit dem des INSPIRE Validators
o   die Tests, die beim JRC entwickelt und nach bestimmten Vorstellungen in die Oberfläche ETF Webapp integriert wurden, sind bereits im ersten Entwurf abgestimmt und EU-weit gültig.
o   einen GDI-DE Sonderweg zu beschreiten, bei dem man sich Gedanken zur Verwendung und ggf. Aufteilen der INSPIRE Tests je Annex Thema macht, ist nicht sinnvoll: da dies dazu führen würde, dass unterschiedliche Ergebnisse beim Testen desselben Sachverhalts erfolgten und bspw. beim INSPIRE-Monitoring ohnehin wieder auf den ETF Validator zurückgegriffen werden müsste.

Vorschlag:
o   die GDI-DE sollte sich an der originären Stelle (JRC, GitHub Issue tracker) aktiv einbringen und dort für eine Neujustierung bzw. Neuausgestaltung bei Interoperabilitätstests hinarbeiten.

4) Weitere Vorschläge wurden insbesondere aus BB & NRW vorgetragen, die bereits oben referenziert sind.

Was wäre jetzt ein Schlussfolgerung aus Sicht der Architektur GDI-DE:

Es gibt wie bereits geschildert ein Mindestmaß an CC, welches zur Sicherstellung der Konformität zu den INSPIRE General requirements auch in der GDI-DE Testsuite benötigt wird. Diese Mindestanforderung könnte in der  Testsuite als eine Art "Basistest" (nur die General-Requirement) angeboten werden. Bei dem Test müsste sichergestellt sein, dass die selben Ergebnisse wie im INSPIRE-Validator zurückgegeben werden.

Daneben sollten, wenn Tests zur Datenspezifikation, vorliegen auch spezifische Tests für ein bestimmtes INSPIRE-Thema angeboten bzw. (vor)konfigieriert werden können. Hierzu wurden auch Vorschläge von Hamburg und NRW vorgetragen und dort beschrieben, z.B. als Variante "A" in der Tabelle aus NRW. Eine Konkretisierung/Festlegung dieser themenspezifischen Tests wäre notwendig; das Beispiel Adressen wurde aufgezeigt

Als Letztes wurde durch NRW noch die Variante "B" als "große Lösung" vorgestellt. Dies wäre ebenfalls eine mögliche Testklasse, die bei Bedarf in der GDI-DE Testsuite ausgewählt werden könnte. Eine Verpflichtung alle Kritierien bei INSPIRE zu erfüllen, gibt es bei der derzeitigen Rechtslage (insbesondere für die datenhaltenden Stellen) und auch in der GDI-DE Architektur bisher nicht.

Mit freundlichen Grüßen

Dr. Falk Würriehausen

Vielen Dank für die Rückmeldungen und die rege Diskussion!

Zunächst noch einmal zur Klarstellung: der Testumfang und die Testinhalte / Testergebnisse sind identisch zu denen des INSPIRE Reference Validators. Es geht uns lediglich um die Festlegung der Struktur in der GDI-DE Tetsuite (Zusammenfassung der CC aus dem INSPIRE Validator zu Testklassen). Spezifische GDI-DE-Tests zu Datenmodellen gibt es (noch) nicht.

Wir werden nun auf Basis der Rückmeldungen die Testklassen für die Beta-Version der GDI-DE Testsuite folgendermaßen umsetzen:

• Themenspezifische Testklassen mit allen relevanten Konformitätsklassen (entsprechen den Conformance Classes im INSPIRE Reference Validator). Die Konformitätsklassen sind alle verpflichtend, d.h. werden alle automatisch bei Auswahl der Testklasse getestet (Variante "B" des Vorschlags aus NRW).
• Eine weitere Testklasse, die für die Anhang II- und III-Datensätze genutzt werden kann bis themenspezifische Tests zur Verfügung stehen. Diese Testklasse enthält nur die "General requirements" Conformance Classes, welche die grundsätzlichen Anforderungen an alle INSPIRE-Datensätze abdecken.

In einer weiteren Ausbaustufe der GDI-DE Testsuite (perspektivisch) werden wir die konditionalen Abhängigkeiten der Conformance Classes untereinander, wie sie im INSPIRE Reference Validator umgesetzt sind, abbilden (Variante "A" des Vorschlags aus NRW). Derzeit ist diese Funktionalität noch nicht in der GDI-DE Testuite implementiert. Diese Funktionalität könnte dann auch für andere Testklassen genutzt werden wie bspw. die Metadatentests zu "Invocable Spatial Data Services".