Schnittstellen-Spezifikation Beobachtungsdaten

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

Diese Seite dient der Zusammenstellung von Schnittstellen-Spezifikation, die in dem 2. BfN Workshop "Standards für den Austausch von Beobachtungsdaten von Organismen" am 3.-4. Mai 2018 basierend auf obligatorischen Datenelementen für den Austausch von Beobachtungsdaten abgeleitet wurden.


Schnittstellen-Spezifikation

Im Folgenden soll entlang der zu Beginn skizzierten Anwendungsfälle erarbeitet und beantwortet werden:

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: Kepp 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

May: Kann 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

(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