Übersicht:

Favoritenliste:

Favorite Pages

There are currently no pages on your favorites list. You can add pages to this list by selecting Favorite from the Tools menu on the page you're viewing.
Skip to end of metadata
Go to start of metadata

In die neue GDI-DE Testsuite sollen u.a. Interoperabilitätstests aus dem INSPIRE Reference Validator integriert werden. Die Interoperabilitätstests im INSPIRE Reference Validator umfassen relativ viele Conformance Classes mit Abhängigkeiten untereinander. Wir stehen nun vor der Herausforderung wie wir diese Abhängigkeiten in der GDI-DE Testsuite abbilden können. Hier haben wir unterhalb einer Testklasse die Möglichkeit verpflichtende und optionale Konformitätsklassen (die zusätzlich ausgewählt werden können) zu bilden.

Beispiel Adressen:

Wenn ich hier im INSPIRE Reference Validator die Conformance Class (CC)

  • Application schema, Adresses

auswähle, werden automatisch die CC

  • INSPIRE GML application schemas,
  • General requirements, GML application schemas, Addresses und
  • INSPIRE GML encoding

ausgewählt.

Wenn ich die CC

  • Data consistency, Addresses

auswähle, werden automatisch die CC

  • Data consistency, General requirements und
  • INSPIRE GML encoding

ausgewählt.

Und so weiter.

In der GDI-DE Testsuite würden wir eine Testklasse "INSPIRE data theme Addresses (3.1)" anlegen und alle relevanten CC (neben den im INSPIRE Reference Validator in dem Block "Data Theme: Addresses (Data Specification version 3.1)" aufgelisteten CC alle "basic tests", die im INSPIRE Validator automatisch mit getestet werden) als Konformitätsklassen zuordnen.

Frage ist nun, welche dieser Konformitätsklassen klassifizieren wir als verpflichtend und welche als optional? Ist es ausreichend alle "General requirements" zu erfüllen und die speziellen "on top" zu betrachten? Oder sollen unabhängig davon exakt die Möglichkeiten des INSPIRE Validators nachgebildet werden (was wir als nur schwer umsetzbar einstufen)? Ist vielleicht den GML- und Application Schema-Tests besondere Bedeutung beizumessen, weil sie entscheidend sind für die Interoperabilität? Oder anders gefragt, welche Tests (CC) sind auf jeden Fall notwendig, um eine Konformität zu den Datenspezifikationen vollumfänglich zu bewerten?

11 Comments

  1. 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?

     

    1. Das Problem liegt in den unterschiedlichen Teststrukturen von INSPIRE Validator und GDI-DE Testsuite:

      GDI-DE TestsuiteINSPIRE Reference Validator

      Testklassen und den Testklassen zugeordnete Konformitätsklassen (zwei Ebenen); Konformitätsklassen können dabei unterschiedlichen Testklassen zugeordnet werden.

      Conformance Classes (flache Hierarchie).

      Unterscheidung der Konformitätsklassen in verpflichtende (müssen in der ausgewählten Testklasse zwingend durchlaufen werden) und optionale (können zusätzlich durchlaufen werden) Konformitätsklassen.

      Konditionale Abhängigkeiten der Conformance Classes untereinander (bestimmte Conformance Classes können nur in Kombination mit anderen Conformance Classes durchlaufen werden), keine Unterscheidung in verpflichtend und optional.

      Beispiel

      Testklasse: INSPIRE data theme Addresses (3.1)

      Konformitätsklassen:

      • Application schema, Addresses (M/O)
      • Data  consistency, Addresses (M/O)
      • Data consistency, General requirements (M/O)
      • GML application schemas, Addresses (M/O)
      • INSPIRE GML application schemas, General requirements (M/O)
      • INSPIRE GML encoding (M/O)
      • Information accessibility, Addresses (M/O)
      • Information accessibiliity, General requirements (M/O)
      • Reference systems, General requirements (M/O)
      • Reference systems, Addresses (M/O)

      Beispiel

      Ausgewählte Conformance Class: Application schema, Addresses

      Kann nur getestet werden in Kombination mit folgenden Conformance Classes:

      • INSPIRE GML application schemas, General requirements
      • GML application schemas, Addresses
      • INSPIRE GML encoding

      Und so weiter...

      Dadurch ist gerade bei den Daten-Tests mit sehr vielen Abhängigkeiten der Conformance Classes untereinander, eine exakte Nachbildung in der Testsuite schwierig. Ziel ist es natürlich alle Conformance Classes des INSPIRE Reference Validators in die GDI-DE Testsuite zu integrieren. Die Frage bezieht sich auf das WIE.  

  2. 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.


    1. Danke für die übersichtliche Darstellung.

      Wenn ich es richtig lese, entspricht deine Variante „B“ genau dem Testumfang des INSPIRE-Validators. Unabhängig davon, dass ich die Relevanz der einzelnen Tests für die geforderte Interoperabilität im Einzelnen nicht einschätzen kann, halte ich das für die im Grundsatz einzige vernünftige Lösung. Selbst wenn manche Tests wichtiger sind als andere, so sieht der Nutzende ja auch in der GDI-DE-Testsuite das Ergebnis auf den einzelnen „Testschritt“ (hier Konformitätsklasse wie Frau Hogrebe oben erläutert hat) bezogen, nicht wahr?

      Was ich gerne wissen möchte:

      Gibt es – hier im Datenbereich - überhaupt zusätzliche GDI-DE-spezifische Anforderungen? Bei den Metadaten ist das ja so und dort ist mir auch klar, warum wir die Testsuite der GDI-DE nutzen. Hier sind sicher die KollegInnen aus der AG Geodaten gefragt. Ich bin gespannt.

      1. zur Variante "B" und der Entsprechung zum EU-Validator: in der Summe ja, in den Möglichkeiten nein! Der Unterschied zum EU-Validator ist, dass im momentanen Stand der Neuentwicklung der GDI-DE Testsuite nicht die geschilderten konditionalen Abhängigkeiten der Conformance Classes untereinander (bestimmte Conformance Classes können nur in Kombination mit anderen Conformance Classes durchlaufen werden) berücksichtigt wurden. Daher der mögliche Ausweg, gleich alles auf verpflichtend zu setzen, um nichts zu übergehen, was gem. Definition der Conformance Classes als sog. "direct dependencies", also zugehörig und ebenfalls zu durchlaufen, ausgewiesen ist.

  3. 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.



  4. 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 …

    1. Zur Frage bezüglich des Vorliegens der Ergebnisse der Umfrage: die Ergebnisse werden morgen im Rahmen des INSPIRE-Webinars vorgestellt. Aus meiner Sicht haben sie nur indirekte Auswirkungen auf die aktuelle Diskussion (z.B. wurde mehrfach der Bedarf nach Tests für die INSPIRE-Datenspezfikationen geäußert).

  5. 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

  6. 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".

    1. Noch eine kleine Ergänzung, weil mir das erst jetzt bei der Zusammenstellung der einzelnen Testklassen zu den Datenspezifikationen aufgefallen ist:

      Es gibt Datenspezifikationen mit mehreren Applikationsschemata (z.B. Verkehrsnetze oder Hydrographie). In diesen Fällen gibt es auch pro Applikationsschema jeweils eine Conformance Class (z.B. Application schema, Air Transport Networks). Da es unwahrscheinlich ist, dass ein Datensatz alle Applikationsschemata erfüllt, werden wir diese Konformitätsklassen auf "optional" setzen. Die Konformitätsklassen mit den allgemeinen Anforderungen (z.B. Application schema, Transport Networks Common) sind dagegen wie in den anderen Testklassen "verpflichtend".

      Beispiel Transport Networks:

      Conformance Classverpflichtend/optional
      INSPIRE GML encodingverpflichtend
      INSPIRE GML application schemas, General requirementsverpflichtend
      Data consistency, General requirementsverpflichtend
      Information accessibility, General requirementsverpflichtend
      Reference systems, General requirementsverpflichtend
      INSPIRE GML application schemas, Transport Networksverpflichtend
      Application schema, Transport Networks Commonverpflichtend
      Data consistency, Transport Networksverpflichtend
      Information accessibility, Transport Networksverpflichtend
      Reference System, Transport Networksverpflichtend
      Application schema, Air Transport Networksoptional
      Application schema, Cable Transport Networksoptional
      Application schema, Rail Transport Networksoptional
      Application schema, Road Transport Networksoptional
      Application schema, Water Transport Networksoptional