Application Schema for Observation Data

From ABCD 3.0 (Access to Biological Collection Data)
Jump to: navigation, search

Contents

Einleitung

Diese Seite dient der Zusammenstellung von Datenelementen, die in dem 2. BfN Workshop "Standards für den Austausch von Beobachtungsdaten von Organismen" am 3.-4. Mai als obligatorisch für den Austausch von Beobachtungsdaten und zur Umsetzung einer gemeinsamen Schnittstellen-Spezifikation angesehen werden.

Tagesordnung zum Workshop am 3. und 4. Mai 2018 in Bonn

Workshop-Programm

Do., 3. Mai

  • 13.00 – 13:20: Begrüßung
  • 13.20-13.30: Einführung in den Veranstaltungsablauf und das angestrebte Ziel
  • 13:30 – 13:45: Impulsvortrag Rolf Walter - Die REST-Schnittstelle des Artenfinders
  • 13:45 – 14:15: Auswahl der UseCases, Vorbereitung der Grupenarbeit
  • 14:15 – 14:45: Gemeinsame Bearbeitung eines UseCase im Plenum

Anschließend Aufteilung in die beiden Arbeitsgruppe

  • 14:45 – 15:30 Weiterarbeit in der Arbeitsgruppe (AG 1: Beschreibung und Festlegung obligatorischer und fakultativer Datenelemente für die ausgewählten UseCases, AG 2: Beschreibung von Schnittstellen-Funktionalitäten)
  • 15.30-16.00: Kaffeepause
  • 16.00 -17:30: Parallele Arbeitsgruppensitzungen: Fortsetzung der Gruppenarbeit
  • 17:30-17:45: AG 1 - Vorstellung der Ergebnisse der Gruppenarbeit im Plenum
  • 17:45-18:00: AG 2: Vorstellung der Ergebnisse der Gruppenarbeit im Plenum
  • 18:00: Abendimbiss in den Tagungsräumen
  • 20:00: Nachtreffen

Fr., 4. Mai

  • 8.30-9:30: Datenbereitstellung / Lizensierung Nutzungsbedingungen (Plenum).
  • 9.30-10:30: Abschluss der Arbeit in den beiden AGs und Erarbeitung einer Ergebnisdarstellung
  • 10.30-10.45: Kaffeepause
  • 11:45-11:00: Vorstellung der Ergebnisse aus der Arbeitsgruppe 1
  • 11:00-11:15: Vorstellung der Ergebnisse aus der Arbeitsgruppe 2
  • 11:15-13:00: Diskussion im Plenum, Festhalten der erzielten Ergebnisse
  • 13:00 - 14:00: Gelegenheit für Gruppengespräche beim Mittagessen (BLE-Kantine)
  • 14:00: Ende der Veranstaltung

Begrüßung und Einleitung

Nach der Begrüßung der Teilnehmer wurde zunächst noch einmal die Motivation des Veranstalters zur Durchführung dieses Workshops herausgestellt:

Worum es geht

  • Einen Mindeststandard an Datenelementen zum Austausch von Beobachtungsdaten von Organismen zu definieren (orientiert an den 5 Ws und mit Angaben zum verwendeten Datentyp).
  • Empfehlungen zur Implementierung von Schnittstellenfunktionalitäten auf der Systemebene zu erarbeiten.
  • Bessere Voraussetzungen zum Datenaustausch und zur redundanzfreien Integration von Daten in vernetzte Architekturen zu schaffen.
  • Eine bessere Datenbasis für vielfältige Aufgaben in den unterschiedlichsten Anwendungsfeldern zu schaffen.

Worum es nicht geht

  • Systembetreibern ein bestimmtes Datenmodell vorzuschreiben
  • Druck auf Systembetreiber zur Bereitstellung ehrenamtlich erhobener Daten für behördliche Naturschutzaufgaben auszuüben.

Impulsvortrag Dr. R. Walter (processware GmbH)

Anschließend wurde am Beispiel der für die Software "Artenfinder" entwickelten REST-Schnittstelle durch den Entwickler Dr. R. Walter die technischen Möglichkeiten zum Datenaustausch über diese Webtechnologie vorgestellt. Zur Anbindung an die Schnittstelle ist eine öffentliche Dokumentation vorhanden. Im Rahmen der der bereitgestellten technischen Möglichkeiten kann dieses von jedermann genutzt werden.

Walter verwies dabei in seinem Vortrag auch auf die Notwendigkeit einer abgestimmten Datenstruktur für einen effektiven Datenaustaussch:

"Wir verständigen uns auf einen gleichlautenden Satz von Attributen, deren gewählten Benennungen und Wertebereichen, die oft auch durch einheitliche Schlüssellisten definiert sind."

ArtenFinder Web Service API Version 2.0

Impulsvortrag von Dr. R. Walter zur REST-Schnittstelle des Artenfinders

REST-Schnittstelle des Artenfinders

Use Cases zur Ermittlung obligatorischer Datenelemente

Zur Identfikation von als obligatorisch zu betrachtenden Datenelementen wurde eine auf UseCases basierende Herangehensweise gewählt. Anhand von Anwendungsbeispielen aus der Praxis sollten die dafür erforderlichen Datenelemente zusammengetragen und anschließend fallübergreifenden auf ihre "Allgemeinbedeutung" hin bewertet werden. Hierbei galt es einerseits die Menge der Datenelemente nicht ausufern zu lassen, andererseits jedoch eine Katalogreferenz zu liefern, die für viele praktische Fragestellungen im Natur- und Artenschutz Verwendung finden kann.

In diesem Zusammnhang waren drei UseCases zur Bearbeitung im Seminar vordefiniert worden:


UseCase 1 (Kartierer): Area of interest

Hier steht die Erstellung Geländeliste der vorkommenden Arten in einem durch den Anwender vorgegebenen Bezugsraum im Mittelpunkt (etwa als Funktion in einer KartierApp). Es können verschiedene Datenquellen integriert werden. Die Liste soll Angaben zur Häufigkeit, dem letztmaligen Auffinden, der Datenherkunft und kann zum Beispiel in einer App für den Geländeeinsatz integriert sein. Die Funktion lässt sich in der Verwendung von offenen Quellen und Quellen, die eine Authentifizierung erfordern differenzieren.

Nach der Vorstellung dieses UseCases wurden durch die Teilnehmer Datenelemente identifiziert und auf Moderationskarten festgehalten. Diese wurden anschließend auf Pinwänden in das Raster der fünf W´s (Was-Wer-Wo-Wann-Wie plus Metadaten) eingeordnet und geclustert.

Das folgende Fotoprotokoll zeigt die Ergebnisse dieses Arbeitschrittes:

UseCase 1 wurde von allen Teilnehmern gemeinsam erarbeitet. Danach erfolgte eine Aufteilung in zwei parallele Arbeitsgruppen, die sich in einer Gruppe mit weiteren Anwendungsfällen und ihren Datenelementen und in einer zweiten Gruppe mit der Schnittstellenthematik und exemplarischen Umsetzungsmöglichkeiten beschäftigten.

UseCase 2 (Fachgesellschaft, Behörde): Rote-Liste-Bearbeitung

Ein Spezialist einer Artgruppe benötigt zur Bearbeitung des Rote-Listen-Status einer Art die Verbreitungsinformationen aus den relevanten Datenquellen. Neben der Verbreitungskarte werden Informationen zum Kontext der Entstehung, zur Datenqualität, zu Bestandsgrößen, zu Zeitpunkt des letzten Nachweises, zur verwendeten Nachweismethode, … benötigt.

Nach der Trennung der Teilnehmer in zwei Teilgruppen wurde durch die Gruppe "Datenelemente" der zweite UseCase bearbeitet. Die Zusammenstellung der hier festgehaltenen Datenelemente findet sich in dem folgenden Fotoprotokoll.

UseCase 3 (Kommunale Umweltämter, Landesämter): Frühwarn- und Bekämpfungssystem zur Verbreitung invasiver Arten

Aus heterogenen Quellen sollen zum Betrieb eines Frühwarn- und Bekämpfungssystems für invasive Arten zusammengetragen werden.

Aus Zeitgründen wurde auf die Bearbeitung von UseCase 3 verzichtet. Es herrschte zudem die Meinung vor, dass über die in den beiden zuvor bereits bearbeiteten Anwendungsfälle hinaus, hier keine weiteren Datenelemente zu benannt werden könnten.

Schnittstellen-Spezifikation

Die Arbeitsgruppe "Schnittstellen" beschäftigte sich zunächst mit grundsätzlichen Fragestellungen zur Technik und zum Einsatz von Schnittstellen. In einem zweiten Teil wurden exemplarische Lösungsansätze für die die diskutierten UseCases und den dort vorgesehenen Datenelementen vorgesehen.

Grundsätzliche Fragestellungen:

Können wir uns auf http(s)-basierte REST-Schnittstellen beschränken? >> OGC- WebServices (WMS, WFS), SOAP

Bleich: Anspruch Versuch Schnittstelle zu formulieren ambitioniert genug, häufig verwendete Umsetzung

Nordhoff-Vergien; Graph QL (Facebook) Integrierte Möglichkeit Datenmenge einzuschränken (kann mit unstrukturierten Daten umgehen)

Frau Triebel: REST häufig verwendet (z.B. Sammlungen), möglichst keine parallele Entwicklungen

Bleich: Einfach wie möglich, out of the box

May: Kaskadierende Anfragen (capabilities, filter,..)

Bleich: mit Minimallösung starten, regelmäßig darüber austauschen

Walter: unterschiedliches Verständnis von Schnittstellen; wichtige AG ist die zum Datenmodell; Festlegung auf REST nicht notwendig, Steht am Ende der Entwicklung

Brauchen wir nur Abfragen (GET-requests) zu berücksichtigen oder sollen auch andere Anfrage-Methoden (POST, DELETE, PUT, HEAD, OPTIONS) bereitgestellt werden?

>> Bedeutung im Kontext von Nutzungsrechten, Systembetreiber Diskussion um Bedeutung der Methoden >>

Nordhoff-Vergien kurze Erläuterung

Bleich: Keep it simple, Plädoyer für Post und Get!

May: Unterschiede bei Nutzungsbeschränkungen bezgl. der Daten, im einfachsten Fall GET

Walter: Macht es Sinn sich festzulegen?

Triebel: "Rüber schielen", wie bsp. müssen Schnittstellen definiert sein, wenn andere Adressaten Daten anfragen möchten; nach Bedarf schauen;

Bleich: Standard definieren, um Ressourcen zu sparen

Nordhoff-Vergien: Wenn Schnittstelle einfach kompakt gehalten, ist die Umsetzung/Implementierung für die meisten Betreiber einfacher, im zweiten Schritt weitere möglich.

May: Beispiel App für Geländearbeiten >> Über Schnittstelle Daten abrufen (GET als Mindeststandard) aus verschiedenen Quellen möglich Post nicht für alle umsetzbar)

Triebel: Bsp. Verweis auf per GET abrufbare Infos zu Rote Listen (dokumentiert); Mit zunehmbarer Nutzung wir Schnittstelle weiterentwickelt (am Bedarf orientiert)

Soll das Caching unterstützt werden (Expiration-Headers)? Sollen bedingte Anfragen unterstützt werden (z.B. Last-Modified)?

Kurze Erläuterung zur Bedeutung >> technisches Details sollen in gesonderter AG bearbeitet werden

Benötigen wir eine Authentifizierung zum Zugriff auf den Service (Authentifizierungs-Methode(n))?

Nutzungsrechte

Technisches Detail; Sache der Systembetreiber; nicht zwingend in AG zu beantworten

Welche Arten von Representations (Ausgabeformate, z.B. json, xml, csv) sollen angeboten werden?

Bedarf

Bleich: Reihenfolge wie oben, json präferiert

Nordhoff-Vergien: json/xml (maschinenverwendbar), csv nicht notwendig

Beschreibung der zu übermittelnden Anfrage-Parameter

May: anhand der UseCases

Nordhoff-Vergien: Bsp. Taxref, nur ID oder Artname

May: Analog zu Bootstrap >> 1. Anfrage zum Taxon, 2. was wird geliefert, 3. Abfrage mit ID


Nordhoff-Vergien: 1. Anfrage auf Beobachtungsdaten (Gibt es neue Daten? (modified_since) 2. Alle Taxa, die du verwendest, welche Taxa kennst Du?

Bleich: Referenzen zu mehr als nur Taxa, Referenzinformationen (Melder), Datum, Referenzlisten z.B. des BfN als WebService zur Verfügung stellen

May: welche Filter wollen wir definieren

Walther: alle Filter, die als Datenelemente definiert werden. Plausibilisierung

MayKann REst generisch alle Parameter leisten? Wie hoch ist der Aufwand?

Triebel: ID der Sample, Client speichert

Nordhoff-Vergien: Cachen, um nicht jedes Mal Daten noch einmal abzufragen; Wenn nochmal angefragt, gib mir nur neue Daten

Walter: kann man das vorschreiben?

Bleich: last_modified notwendig, das immer wieder konkret benötigt

May: Best practice keine Vorschrift

Nordhoff-Vergien: Empfehlungen aussprechen (Schnittstelle 1.0 als "Standard")

Balzer: Vereinbarungen sind notwendig, minimale Standards wünschenswert


Beschreibung der Ergebnisstrukturen und Formate anhand der konkreten Anwendungsfälle

In der Folge wurden zu den skizzierten Anwendungsfällen beispielhafte Umsetzungswege skizziert:


(hier müssen die Festlegungen aus der AG1 berücksichtigt werden)

UseCase1 Geländeliste

Datenelemente aus AG1 (Zwischenstand - noch nicht endgültig)

Was Wer Wann Wo Wie Meta
Artname, wiss. Name Beobachter Zeitpunkt Geokoordinaten Art der Qualitätsprüfung
ID Code Bearbeiter (Name, Institution) Tag, Monat, Jahr Genauigkeit Quellen
Angabe geprüft? Personendaten, E-Mail Zeitraum Raumbezug Quellentyp
Beleg (Bild, Tonaufnahme) Datenquelle Uhrzeit Fundortbeschreibung Beispiel ID
Anzahl, Verbreitungsgebiet Genauigkeit Raster Qualitätslevel

Entwurf eines RESTful Services am Beispiel der Geländeliste


GET services/v1/occurrences >> 50 erste/neueste Beobachtungen (json/xml)

GET services/v1/occurrences?offset=50 >> 50-100 neueste Beobachtungen (json/xml)

GET services/v1/occurrences?...limit=10 >> 50-60 neueste Beobachtungen (json/xml)

GET services/v1/occurrences?...orderby >> Sortierung nach ...


Filter auf Datenbestand

Um zunächst einen Überblick zu erhalten, wonach gesucht werden kann, soll analog zu den OGC-Services eine Art Capabilities-Dokument ausgegeben werden. GET services/v1/capabilities
>> unterstützte Felder

>> Anhand der zur Verfügung stehenden Filterparameter kann danach die Ausgabe eingeschränkt werden. {filter:["TK","Polygon", "WKT", "quality_level", "Artengruppe" ... WGS84, ETRS


Tabellarische Übersicht zu Filterparametern

q verbal Maschine
TK/MTB-ID, WKT, Polygon (WGS84, ETRS) location_type=tk
Artengruppe taxon_group
Taxa taxon_name, taxon_id
Qualitätslevel quality_level=verified

UseCase2: Rote-Liste-Bearbeitung

nicht bearbeitet in AG2


Datenelemente aus AG1

Was Wer Wann Wo Wie Meta
Taxon Bearbeiter möglichst genauer Zeitpunkt der Beobachtung möglichst genauer Ort Status Synonyme
ID Quelldatensatz ID Datenschutzkonforme Ref. für Bearbeiter Start- und Enddatum Genauigkeit, geogr. Unschärfe Grad der Erfassung Tax-ID
BFN Checkliste permanent/episodisch Georeferenzierung Genetik Taxref
EU-Nomen Erhebungsmethodel Wer hat wie geprüft
Präsenz/Absenz Geprüfte Angabe
Status/Stadium Belege
Anzahl

Lizenzmodelle

Am zweiten Tag befasste sich ein eigener Diskussionsblock mit dem Thema Lizenzmodelle und daran angebundenen Fragen des Datenschutzes. Im Kontext des Datenaastausches spielen die zu beachtenden Lizenzbedingungen, neben den technischen Aspekten des Datenaustausches, ein ebenfalls wesentliche Rolle. Komplexe Regularien und all zu starke Einschränkungen der Datennutzung durch Dritte können einem erfolgreichen Datenfluss im Wege stehen.

Zunächst wurde ein kurzer Überblick über die Möglichkeiten zur Nutzung von standardisierten Lizenzmodellen nach nach Creative Commons (CC) für organismische Verbreitungsdaten gegeben. Dabei erfolgt die Reglung des Urheberrechts in Form standardisierter Lizenzverträge und es kann zwischen unterschiedlichen Varianten ausgewählt werden, welche die Verwendung von Daten von vollkommen offen über verschiedene Zwischenstufen bis hin zu sehr stark eingeschränkt festlegen.

Abbildung Lizenzmodelle CC

Ein Blick auf verschiedene in Deutschland im Einsatz befindliche Fachinformationssysteme zeigt jedoch, dass nach wie vor sehr individuelle Lizenzmodelle mit teils komplexen Nutzungsregelungen an der Tagesordnung sind.

Anhand einiger Beispiel wurde das breite Spektrum lizenzrechtlicher Regelungen verdeutlicht:


Ornitho.de Individuelle Nutzungsvereinbarung, Weitergabe der Daten an Dritte nur nach Einzelfallentscheidung einer Fachgruppe

BeachExplorer / Naturgucker Anwender/Erheber erteilt eine dauerhafte Lizenz für Reproduktion, Anpassung, Modifikation, Übersetzung und Veröffentlichung seiner Daten, der Betreiber behält sich die Weitergabe der Daten an Dritte vor.

Deutschlandflora Daten werden auf MTB-Quadranten vergröbert an das BfN weitergereicht, Benutzer kann seine eigenen Daten über CC by (freie Nutzung mit Zitat) freigeben.

BatMAP Individuelle Vereinbarung, Recht zur Löschung der eigenen Daten, jedoch nicht die zu Landesamt weitergereichten Inhalte

Artenfinder Ministerium behält sich vor Änderungen und Ergänzungen an den Daten vorzunehmen, über „öffentliche Meldungen“ werden die Daten an Umweltverbände und den amtlichen Naturschutz für die Naturschutzarbeit freigegeben.


In der Diskussion wurde deutlich, dass die Verwendung von standardisierten Lizenzmodellen von vielen Teilnehmern in der Umsetzung als schwierig, jedoch für einen verbesserten Datenfluss zwischen den Systemen als wesentlich betrachtet wurde.

Ebenfalls intensiv diskutiert wurde die Frage, welche Anforderungen sich durch die neue Datenschutz-Grundverordnung(EU-DSGVO) insbesondere im Hinblick auf die Speicherung und Weitergabe personenbezogener Daten (Namen, Adressen von Kartierern) ergeben. Einigkeit herrschte darüber, dass die Weitergabe der Realnamen ohne eine explizite Zustimmung nicht mit der Richtlinie konform ist. In diesem Zusammenhang wurde die Möglichkeit der Verwendung eines zentralen Anonymisierungsdienstes als möglicher Lösungsweg identifiziert. Damit würde bei der Weitergabe der Daten lediglich ein Verweis auf den jeweiligen Referenzeintrag eines Anonymisierungsdienstes weitergegeben. Dieser Dienst selbst soll dan zentralisiert die personenbezogenen Datenschutzrechte verwalten. Für viele Einzelfragen stehe jedoch noch eine juristische Abklärung in den kommenden Monaten aus, die es abzuwarten gelte.

Obligatorische Datenelemente

Am zweiten Tag des Workshops wurde mit allen Teilnehmern eine Synthese aus den Datenelementen der bearbeiteten UseCases im Hinblick auf eine allgemeinverbindliche Grundmenge durchgeführt.

Die folgenden Charts zeigen den Aufschrieb der als obligatorisch zu betrachtenden Datenelemente. Im Nachgang sollen diese Datenelemente in das ABCD-Schema eingepasst werden und dabei auch die durch den Standard vorgegebenen Feldbezeichnungen Verwendung finden.

Obligatorische Datenelemente zum Austausch organismischer Beobachtungsdaten als Ergebnis des BFN-Workshops im Mai 2108 in Bonn (Gegenstand des Austauschs sind Daten zu Einzelbeobachtungen in Form einer flachen Tabelle). ....

WAS?


In diesem Block war es den Teilnehmern wichtig zusammengesetzte Datenpakete, die sich aus unterschiedlichen Einzelquellen zusammensetzen, verwalten zu können. So sollte in diesen Fällen neben der ID für jeden Datensatz eines Datenpakets auch eine "Fremd-ID" der Original-Quelle und eine Klartext-Benennung dieser Fremdquelle mitgeführt werden. Die verwendeten Namen sollen aus einer etablierten taxonomischen Referenz stammen. Deren Herkeunft soll ebenfalls referenziert werden. Der Taxname soll über die ID in der verwendeten Referenz und als Klartextname geführt werden.
Benannt werden soll auch die zugehörige Artengruppe, dazu soll beim BfN ein entsprechender Webservice als Referenz entwickelt und implementiert werden. (Ohne dieses Hilfsmittel kann alternativ eine textliche Angabe der Artgruppe und des Rangs übergeben werden).
Weiterhin sind hier Angaben zu den festgestellten Häufigkeiten zu machen. Neben einer einfachen numerischen Eingabe ist hier auch fakultativ eine Häufigkeitsangabe anhand ausgewählter Wertebereiche aus einer Listenwahl, die auf die einzelnen Artgruppen hin abgestimmt ist, gewünscht. Auch hier soll ein noch zu entwickelnder Webservice für die einzelnen Artengruppen Auswahllisten zur Verwendung vorgeben. Zusätzlich sollen auch Negativnachweise (-> Art wurde an der Stelle nicht gefunden) verwaltet werden.
Als weitere Angaben sind das Vorhandensein von Belegen vorgesehen. Dabei soll als Minimum die Angabe übergeben werden, ob ein Beleg vorhanden ist (ja-nein). Beim Vorhandensein ist die Art des Belegs anhand einer Werteliste näher zu bestimmen.
Weiterhin soll eine Information geführt werden, ob der Datensatz einer Prüfung unterzogen wurde(ja-nein), dies steht insbesondere mit den wachsenden Datenmengen in Verbindung, die aus Projekten mit einem Citizen-Science-Hintergrund stammen. Weiterhin wird eine Angabe zur Natürlichkeit verwaltet werden, etwa zum floristischen Status. Auch dazu ist für die verschiedenen Artgruppen eine Werteliste zu entwickeln. Dabei ist unter Umständen ein Rückgriff auf eine Referenz aus INSPIRE möglich.

WER?


In diesem Block werden Angaben zum Beobachter gemacht. Als Problem wurden hier die Anforderung aus der neuen DSVGO breit diskutiert. Es herrschte Einigkeit darüber, dass ohne eine explizite Zustimmung von Seiten der Erheber, die in der übergroßen Mehrheit der Fälle auch nicht vorliegt, deren Namensangaben nicht im Klartext weitergegben werden dürfen. Als Minimumangabe kann die Information, ob der Erheber überhaupt namentlich bekannt ist (ja-nein),geführt werden. Für die Zukunft befinden sich Annonymisierungsdienste in der Vorbereitung, bei denen die persönlichen Angaben eines Erhebers in einer zentralen Datenbank verwaltet und die Zugriffsrechte darauf durch die jeweilige Person gesteuert werden können.
Weiterhin sind Angaben zum Quellprojekt des Datensatzes zu verwalten.

WANN?

Hier wurde der Wunsch geäußert neben einem Start- und Enddatum der Erhebung auch die Dauer der Erhebung (erfolgte diese permant über den gesamten Zeitraum oder nur episodisch) verwalten zu können. Dabei solle man sich an den Möglichkeiten orientieren, die durch ABCD 2 vorgegeben werden. Es bestanden darüber seitens der Teilnehmer keine weiteren expliziten Wünsche nach zusätzlichen Datenelementen zur Verwaltung von Zeitangaben.

WO?



Hier herrschte Einigkeit, dass für jeden Datensatz ein expliziter Raumbezug erforderlich ist. Dieser soll über eine WKT-Geometrie transportiert werden. Es sind dabei Punktangaben, freie Polygone oder aus Rasterfeldern abgeleitete Polygone zulässig. Die Daten können in dem jeweils vorliegenden räumlichen Bezugssystem geliefert werden, das zu benennen ist. Zusätzlich ist die räumliche Unschärfe der Daten in einem eigenen Feld zu dokumentieren.

WIE?


Als obligatorisch wurde die Angabe der verwendeten Erfassungsmethode anhand einer Werteliste betrachtet.

METADATEN

Hier wurde von den Teilnehmern des Seminars kein weitergehender Diskussionsbedarf gesehen. Es bestand weiterhin der Wunsch, sich bei der Metadatendokumentation an den zahlreich vorliegenden Projektbeispielen zu orientieren. Hier könnten ein Verweis auf eine den Datenbestand dokumentierende URL, eine Angabe zum verwendeten Lizenzmodell und die Benennung eines fachlichen und technischen Ansprechpartners geeignete Mindestangaben darstellen.

Fazit zur Veranstaltung

Auf der Grundlage der bearbeiteten UseCases wurden in Gruppenarbeit obligatorische Datenelemente identifiziert und festgehalten. Gleichzeitig wurde sich darauf verständigt, die Ergebnisse in einem Wiki-System festzuhalten. Eine tabellarische Zuordnung der Datenelemente zu XML-Elementen in den Schemas von ABCD und DarwinCore soll helfen, bereits praktizierte Anwendungen zu referenzieren und eine mögliche Umsetzung in etablierte internationale Standards vorbereiten. Den Teilnehmern der Arbeitsgruppe soll dieser Bereich zur Bearbeitung/Kommentierung zugänglich gemacht werden. Nachbearbeitungsaufwand wurde insbesondere für die für verschiedene Datenelemente zu verwendenden Wertelisten gesehen. Eine detaillierte Ausarbeitung war im zeitlichen Rahmen der Veranstaltung nicht möglich und soll daher im Nachgang erfolgen.

Umsetzung in das ABCD-Schema

Die folgende Tabelle zeigt die Umsetzung der im Workshop festgehaltenen Datenelemente in die Systematik ABCD.


W Arbeitsbegriff im Workshop Datenelement ABCD Shortname Datentyp Anmerkung Link
Was Beobachtungs ID abcd2:UnitID string Hierbei handelt es sich bei der "Unit" die Beobachtung eines Individuums, die durch die ID eindeutig referenzierbar wird. https://terms.tdwg.org/wiki/abcd2:UnitID
Was Orginal ID in der Quelle abcd2:SourceID string Was ist mit dem Begriffe Quelle gemeint, je nachdem gibt es andere Terme in ABCD die genutzt werden können -> Hiermit waren FremdIDs auf Datensatzebene aus der Original-Quelle bei zusammegefassten Datenbeständen gemeint

FG: Urspünglich ist die SourceID, die Quelle der Daten aus Sicht des Lieferanden gedacht, um für die Daten-Aggregator die (eigene) Quelle (innerhalb einer Institution oder Organisation) eindeutig anzugeben. (Beispiel: Organisation NABU hat mehrere Quellen z.B. "Tagefaltermonitoring" und "Stunde der Gartenvögel"). Aus Sicht eines Aggregators kann das natürlich genutzt werden, um diese Quelle weiterzureichen. Somit ist das im BfN (als Aggregator) absolut legitim. Unschön wäre, wenn der Daten Lieferant (z.B. NABU) selbst das Feld nutzen würde, um eine Dritt-Quelle (wie etwa Literatur als Beobachtungs-Nachweis) zu referenzieren. Da wäre vielmehr das Feld SourceReference und SourceReference-ReferenceGUID geeignet
https://terms.tdwg.org/wiki/abcd2:SourceID
Was Original Quelle abcd2:SourceInstitutionID string s.o., -> hiermit war eine textliche Referenz auf das Quellprojekt bei zusammengeführten Datenbeständen gemeint

FG: Ja, aus Sicht des Datenaggregators: ID des Projektes, der Organisation bzw. Institution, von dem/der die Daten stammen
https://terms.tdwg.org/wiki/abcd2:SourceInstitutionID
Was TaxonID abcd2:TaxonIdentified-FullScientificNameString string Hier wäre der Name in Klartext aus der referenzierten Taxonomie zu finden. (inkl. Autor und Jahr). Alternativ und/oder zusätzlich kann diese Information auch unter dem atomisierten Konzept TaxonIdentified-NameAtomised untergebracht werden, um z.B. Gattung, Art und höhere Taxonomie getrennt zu benennen https://terms.tdwg.org/wiki/abcd2:TaxonIdentified-FullScientificNameString und/oder Unterelemente von https://terms.tdwg.org/wiki/abcd2:TaxonIdentified-NameAtomised
Was Taxonomie Referenz abcd2:Identification-Reference-TitleCitation string https://terms.tdwg.org/wiki/abcd2:Identification-Reference-TitleCitation
Was AcceptedName ID abcd2:Identification-PreferredFlag FG: "PreferredFlag" ist eigentlich nur ein boolscher Wert (true oder false). Dies ist also nur in Bezug auf den FullScientificNameString (s.o.) sinnvoll. Die Kennzeichnung hat den gleichen Informationsgehalt, lediglich die Bezeichnung "Accepted Name ID" ist hier irreführend, da es sich ja nciht um eine ID handelt. Die Prämisse, dass der akzeptierte Name immer der bevorzugte ist wäre zu dokumentieren. (In musealen Sammlungen ist es aus kuratorischen Gründen nicht immer so, dass der valide Name der präferierte ist, aber bei den Beobachtungsdaten kann man das durchaus setzen, um z.B. den Taxonnamen vom urspünglichen Bestimmer und den zugehörigen validen Namen (z.B. im Falle eines Synonyms) parallel angeben zu können. https://terms.tdwg.org/wiki/abcd2:Identification-PreferredFlag
Was Artgruppe abcd2:TaxonIdentified-HigherTaxonName string Werteliste > Hier soll ein noch vom Bfn zu erstellender Webservice referenziert werden https://terms.tdwg.org/wiki/abcd2:TaxonIdentified-HigherTaxonName
Was Artgruppe abcd2:TaxonIdentified-HigherTaxonRank string Werteliste > Hier soll ein noch vom Bfn zu erstellender Webservice referenziert werden https://terms.tdwg.org/wiki/abcd2:TaxonIdentified-HigherTaxonRank
Was Häufigkeit Was wurde gezählt abcd2:Unit-MeasurementOrFact-Parameter string Werteliste https://terms.tdwg.org/wiki/abcd2:Unit-MeasurementOrFact-Parameter
Was Häufigkeit Anzahl abcd2:Unit-MeasurementOrFact-LowerValue num FG: "LowerValue" wird auch verwendet, wenn es nur einen Messwert, statt einerSpanne (LowerValue-UppValue) gibt. https://terms.tdwg.org/wiki/abcd2:Unit-MeasurementOrFact-LowerValue
Was Häufigkeit Werteliste Klassen abcd2:Unit-MeasurementOrFact-Parameter string Abundanz - Werteliste nach Artgruppe

FG: Dieses ABCD Element nur in Verbindung mit mindestens Unit-MeasurementOrFact-LowerValue. Wenn die Klasse und Häufigkeit einem einzigen String beschrieben werden sollen, dann müsste das Element Unit-MeasurementOrFactText verwendet werden
https://terms.tdwg.org/wiki/abcd2:Unit-MeasurementOrFact-Parameter
Was Beleg ja/nein Aufsammlung eines Belegs? Specimen? -> Hier soll nur das grundsätzliche Vorhandensein eines nicht näher spezifizierten Belegs benannt werden
Was Belegtyp string Werteliste In ABCD gibt es hier 2 Möglichkeiten; abcd2:RecordBasis für Art des Belegs oder abcd2:KindOfUnit wenn es nur um Teile eines Individuums geht.

FG: Da es sich hierbei um Beobachtungsdaten geht (die Einzelbeobachtung entspricht also Unit bzw. Record), wäre abcd2:RecordBasis stets mit "HumanObservation" zu füllen. abcd2:KindOfUnit kann dann beschreiben, was beobachtet wurde. Ob das dann aber immer dem hiergemeinten "Belegtyp" (z.B. Herbarbeleg) entspricht, wage ich zu bezweifeln
Was Präsenz/Absenz ja/nein Vom Beleg? Einer Fokusart? -> Nein, gewünscht waren auch Negativnachweise (Art nicht gefunden) abbilden zu können.

FG: Absenz im Sinne von Observationsdaten wird direkt nicht in ABCD abgedeckt, aber man kann das Element abcd2:SpecimenUnit-Disposition nutzen, um mit dem Wert "missing" das Nicht-Vorhandensein zu kennzeichnen. Allerdings ist dann der Taxonname im Sinne einer "Bestimmung" unter abcd2:TaxonIdentified-FullScientificNameString nicht mehr so ganz schlüssig, da ich ja nichts hatte, an dem ich den Bestimmungsvorgang hätte vornehmen können. Aber zur reinen Informationsstrukturierung ginge es dennoch mit der entsprechenden Notiz, das es sich um Absenz-Daten handele.
Was Angabe durch Quelle geprüft abcd2:Identification-VerificationLevel ja/nein FG: wäre sicher besser hier eine (simple) Wertliste wie z.B. "geprüft, ungeprüft" zu haben, da das Feld in ABCD kein Boolean ist. https://terms.tdwg.org/wiki/abcd2:Identification-VerificationLevel
Was Status Natürlichkeit abcd2:ZoologicalUnit-PhasesOrStages string Werteliste (INSPIRE-Liste?) Den Begriff verstehe ich nicht, geht es um das Habitat (Dann wäre es aber vermutlich eher unter Wo)? gewählter ABCD Term vermutlich falsch -> darüber gab es zwischen den Vertretern der verschiedenen Artgruppen in der Veranstaltung auch unterschiedliche Vorstellungen, wie dieser Begriff zu verstehen sei.

FG: Hier ist abcd2:ZoologicalUnit-PhasesOrStages definitiv das falsche ABCD-Element, da hier Lebensstadien (z.B. Nymphe, Larve, Adult) gemeint sind. Etwas, was die "Natürlichkeit des Vorkommens" im hiesigen Sinne adressiert, gibt es in ABCD 2 nur für Herbar-Belege: abcd2:HerbariumUnit-NaturalOccurrence
https://terms.tdwg.org/wiki/abcd2:ZoologicalUnit-PhasesOrStages
Wo Rastersystem abcd2:Gathering-GridCellSystem string https://terms.tdwg.org/wiki/abcd2:Gathering-GridCellSystem
Wo Rasterfeldnumer/bezeichnung abcd2:Gathering-GridCellCode string https://terms.tdwg.org/wiki/abcd2:Gathering-GridCellCode
Wo Koordinate Lat abcd2:Gathering-LatitudeDecimal num https://terms.tdwg.org/wiki/abcd2:Gathering-LatitudeDecimal
Wo Koordinate Lon abcd2:Gathering-LongitudeDecimal num https://terms.tdwg.org/wiki/abcd2:Gathering-LongitudeDecimal
Wo Geometriedaten WKT abcd2:Gathering-FootprintWKT WKT https://terms.tdwg.org/wiki/abcd2:Gathering-FootprintWKT
Wo Geometrietyp string Werteliste (Punkt, Linie, Fläche, Raster)
Wo Räumliche Unschärfe abcd2:Gathering-CoordinateErrorDistanceInMeters num (Meter) https://terms.tdwg.org/wiki/abcd2:Gathering-CoordinateErrorDistanceInMeters
Wo Raumbezugssystem abcd2:Gathering-CoordinateMethod string EPSG-Codes FG: Oder alternativ abcd2:Gathering-GeoreferenceSources https://terms.tdwg.org/wiki/abcd2:Gathering-CoordinateMethod
Wo Unschärfetyp abcd2:Gathering-CoordinateErrorMethod string Werteliste: Erfassungsunschärfe/Maskierierung https://terms.tdwg.org/wiki/abcd2:Gathering-CoordinateErrorMethod
Wann Beginn der Erfassung abcd2:Gathering-DateTime-ISODateTimeBegin string https://terms.tdwg.org/wiki/abcd2:Gathering-DateTime-ISODateTimeBegin
Wann Ende der Erfassung abcd2:Gathering-DateTime-ISODateTimeEnd string https://terms.tdwg.org/wiki/abcd2:Gathering-DateTime-ISODateTimeEnd
Wann Verlauf der Erfassung abcd2:Gathering-DateTime-PeriodExplicit ja/nein kontinuierlich/diskontinuierlich https://terms.tdwg.org/wiki/abcd2:Gathering-DateTime-PeriodExplicit
Wer Projektquelle abcd2:Gathering-ProjectTitle string https://terms.tdwg.org/wiki/abcd2:Gathering-ProjectTitle
Wer BeobachterID string Anonymisierung?! Es gibt die Möglichkeit Namen (abcd2:GatheringAgent-FullName) oder tatsächlich so etwas wie eine ID (abcd2:Gathering-AgentText) anzugeben https://terms.tdwg.org/wiki/abcd2:Gathering-AgentText
Wie Erfassungsmethode abcd2:Identification-Method string Werteliste Ich plädiere hier eher für: abcd2:Gathering-Method, -> braucht es nicht eigentlich doch beides?

FG: Hier ist meines Erachtens mit Erfassungsmethode die "Sampling-Methode" (z.B. Transekterfassung, Plot-Sampling, Malaise-Falle etc.) gemeint. Diese ist in ABCD mit abcd2:Gathering-Method adressiert. Die abcd2:Identification-Method bezieht sich nur auf die Bestimmung des Taxonnamens (z.B. morphologisch, genetisch, akustisch, über Spuren) und nicht auf die gesamt Beobachtung. Sie kann natürlich auch wichtig sein, wurde aber im Workshop meiner Erinnerung nach nicht behandelt.
https://terms.tdwg.org/wiki/abcd2:Identification-Method
Meta Eigentümer abcd2:DataSet-Description-URI string Hier wäre eine URL zu einer beschreibenden Webadresse für das Quellprojekt anzugeben.

FG: Nach der Beschreibung hier, wäre wohl eher abcd2:DataSet-Owner-URI zu verwenden
https://terms.tdwg.org/wiki/abcd2:DataSet-Description-URI
Meta Fachlicher Ansprechpartner abcd2:ContentContact string https://terms.tdwg.org/wiki/abcd2:ContentContact
Meta Technischer Ansprechpartner abcd2:TechnicalContact string https://terms.tdwg.org/wiki/abcd2:TechnicalContact
Meta Lizenz/Disclaimer abcd2:DataSet-License string https://terms.tdwg.org/wiki/abcd2:DataSet-Licenses

Anhang

Recherche - vorhandene Systeme zur Erfassung/verwaltung organismischer Verbreitungsdaten (Desktop/Web/Apps)

Im Nachgang zum ersten Seminar wurden Systeme mit Verwendung im deutschsprachigen Raum recherchiert und dokumentiert.

Die Zusammenstellung enthält Informationen zu den folgenden Systemen:

LocalCosmos, flora-BB.de, MultiBaseCS, science4you, InsectIS,THKART, THKART-Thüringer (Tier)artenerfassungsprogramm, Herpetofauna NRW, Indicia, Gispad, Multibase, MultiMap, MykIS, PC-ASK, ArtenFinder, PC-ASK, Microsoft Access, KORINA-App, DiversityMobile,KORINA Web-Portal,ornitho.de, NaturaList, Tierfund-Kataster, Wildtier-Kataster, eMapper


Die Ergbnisse der Befragung lassen sich als Excel-Tabelle herunterladen.

Der Fragebogen steht weiterhin unter dem folgenden Link zur Eingabe zur Verfügung.


Vorab-Befragung der Seminar-Teilnehmer

Vor Beginn des Workshops wurden die angemeldeten Teilnehmer zum Thema Schnittstellen und Datenaustausch befragt:

Sie haben sich für den BfN-Workshop "Standards für den Austausch von Beobachtungsdaten von Organismen" am 3. und 4. Mai in Bonn angemeldet. Im Vorfeld der Veranstaltung möchten wir von Ihnen gerne zu den Arbeitsgruppen-Sitzungen bereits einen ersten Input einholen.

Bitte benennen Sie uns dazu in einer Mail kurz:

1.)

  • ob Sie bereits webbasierte Schnittstellen betreiben
  • auf welchen Protokollen die Schnittstellen basieren (REST, SOAP, ...)
  • in welchen Datenformaten Sie Informationen transportieren/bereitstellen (XML, JSON, CSV, ...)
  • ob es reine Abfrage-Schnittstellen sind oder auch Daten-Einspeisung oder -Manipulationen (insert/update/delete) realisiert sind

Bitte beschreiben Sie die Schnittstellenfunktion und die verwendete Technologie ggf. stichwortartig.

Schreiben Sie uns auch, wenn Sie in naher Zukunft eine Schnittstelle für die Bereitstellung eigener oder die Nutzung angebotener Beobachtungsdaten einrichten wollen. Skizzieren Sie bitte kurz die für Sie wichtigsten Anwendungsfälle / -bereiche für den standardisierten Austausch von Beobachtungsdaten über Web-Schnittstellen.


2.)

Haben Sie bereits eine Anbindung Ihrer Datenbestände an das GBIF-Netzwerk realisiert?

Wenn ja: können Sie uns eine Dokumentation des mapping ihrer internen Datenfelder auf die XML-Elemente des DarwinCore oder ABCD-Schemas zur Verfügung stellen (oder für die Arbeitsgruppe 1 des Workshops mitbringen)?

++++++++++

Von 10 gemeldeten Teilnehmern wurden Angaben zu den in ihrem Kontext verwendeten Schnittstellen gemacht. Dabei wurden die folgenden Dinge deutlich:

  • Es überwiegen Schnittstellen, die auf den REST-Technologien (zumeist mit JSON) basieren. Bei behördlichen Infrastrukturen werden zudem auch WFS-Dienste benannt, wobei es sich hierbei häufig nicht um organismische Verbreitungsdaten im klassischen Sinne handeln dürfte.
  • Das Einsatzfeld der Schnittstellen liegt dabei häufig im Kontext von Anwendungen, die sich im eigenen Zuständigkeitsbereich befinden, wenn etwa Client-Anwendungen mit einer zentralen Datenbank kommunizieren (überwiegend bei behördlichen Anwendungen).
  • Seltener werden dagegen Schnittstellen zu Fremdsystemen, oder gar offene Schnittstelle genannt. Hier wird teils noch kein konkreter Bedarf gesehen, oder es bestehen grundsätzliche Vorbehalte die eigenen Systeme für Zugriffe von außen auf der Schnittstellenstellenebene zu öffnen. Dies betrifft insbesondere die behördlichen Informationsstrukturen.
  • Intensiver werden Schnittstellen, hier dann häufig auch lesend und schreibend, im Bereich der sich an die breite Öffentlichkeit richtenden nichtbehördlichen Erfassungssysteme verwendet. Auch eine Anbindung an die globalen Informationssysteme zur Biodiversität (GBIF) ist dort in Regel implementiert.
  • Nur in Einzelfällen wurden konkrete Pläne zur Implementierung weiterer Schnittstellen zu Fremdsystemen benannt.== Tagesordnung zum Workshop ==