Qualitätsaussagen - Quality Assurance

Langzeitarchivierte Daten sollten für die Weiternutzung eine Qualitätsaussage (QA) begleiten. Um dieses zu erstellen muss ein zugehöriger Workflow definiert und dokumentiert werden. Der Workflow sollte die Qualitätskriterien enthalten und welche Personengruppe diese durchführen kann. In diesem Prozess kann es dazu kommen, dass bereits bestehende Daten durch neue ersetzt werden. Dieses beinhaltet die Gefahr, dass bereits zugänglich gemachte Daten nicht mehr zugreifbar sind und diese Daten bereits für Journal Publikationen genutzt worden sind und damit die Beweiskette unterbrochen wurde. Abhilfe kann eine Versionierung schaffen und die Vergabe von Zugriffsidentifier auf die Daten ohne Löschen alter veröffentlichter Versionen.

Die Phase in der Daten geändert werden dürfen, sollte im Projekt klar erkennbar sein. Sie ist in dem Moment beendet, wo ein persistenter Identifier vergeben wurde. Ergänzungen der Daten oder neue Versionen dieser ist jederzeit möglich und führt zur Vergabe eines neuen Identifiers.

Die Qualitätsaussagen betreffen die Datenqualität, die Metadatenqualität, die Qualität der Methode und allgemeine Aussagen.

Dabei soll zwischen technischen Qualitätsaussagen (TQA – Technical Quality Assurance) und wissenschaftlichen Qualitätsaussagen unterschieden (SQA - Scientific Quality Assurance) werden.

Personengruppen, die Qualitätsaussagen treffen und einen Review durchführen können sind:

Scientist (Datenerzeuger, Datennutzer, Reviewer (peer))
Repository (Supervision (Review Controller), Review (nicht peer), Metadata Editor)
Journal (Review Controller)

TQA

Die technischen Qualitätsaussagen beziehen sich auf die Integrität (Konsistenz Daten zu Metadaten), Vollständigkeit, Zugreifbarkeit(access) und Datenformat der Orginaldaten und ihrer Metadaten nach deren Transfer in ein Langzeitarchiv. Zu den technischen Qualitätsfragestellungen zählen wir:

· Ist die Datensatzgröße korrekt in den Metadaten eingetragen? Sind Checksummen vorhanden und wurden diese für die Kontrolle des Datentransfers in das Langzeitarchiv genutzt?

· Falls eine zeitliche Beschreibung der Daten existiert, ist diese in den Metadaten korrekt wiedergegeben (calendric aspects, gaps, doubles, step widths) und gibt es Lücken im zeitlichen Ablauf, die dokumentiert sind?

· Wurden fehlende Daten mit missing values aufgefüllt?

· Sind lat, lon und Gitterbeschreibung korrekt

· Sind Filenamen (bei Projektfestlegung dieser und für automated access) und extension korrekt

· Stimmt die Paramterbeschreibung des Langzeitarchivs mit der überein, die in den Datenheadern hinterlegt ist. Bei Codelisten, die die Abbildungen der Codenummern auf die Parameter enthalten, kann dieses recht schwierig sein, da im Header nur eine Zahl steht, die erst interpretiert werden muss. Dieses ist z.B. beim GRIB Datenformat der Fall. Unter Umständen muss auf eine Kontrolle der Parameterbeschreibung verzichtet werden.

· Werden ‚controlled vocabularies‘ genutzt? Hier ist z.B. cf netcdf http://cf-pcmdi.llnl.gov/ zu nennen, das für die Parameterbeschreibung eine Liste von Standardnamen vorgibt.

· Die Konsistenz von Daten auf verteilten Systemen muss gewährleistet sein bzw. dokumentiert werden, welche Komponenten geprüft worden sind.

· Sind Daten und Metadaten im Langzeitarchiv vorhanden? – hier können die Anzahl der Datensätze getestet werden. Diese sollte auf keinen Fall 0 sein und die vorhandenen Daten sollten nicht die Größe 0 Bytes besitzen.

· Sind die Metadaten im Langzeitarchiv vorhanden, die für eine Zitatbeschreibung notwendig sind und die auf der beschreibenden Internetseite (DDD Data Description Document) stehen? Hierzu gehören z.B. Titel, Autorenliste…

· Sind die Daten und Metadaten im Langzeitarchiv zugreifbar? Dieses kann natürlich nur für den Zeitpunkt des Testes zugesichert werden. Später erfolgter Datenverlust durch einen Crash oder durch Löschen kann nicht erfasst werden. Langzeitarchive sollten deshalb immer ein Backup der Daten vorhalten, so dass ein späteres Recovery möglich ist.

· Ist das Datenformat akzeptabel? – Es sollten möglichst selbstbeschreibende Formate gewählt werden, die Standards folgen. Die Formate werden meistens im Projekt festgelegt und orientieren sich an den Formaten, die in der jeweiligen Nutzergruppen genutzt werden. Wurde Komformität überprüft z.B. cf netcdf checker (completeness and necessary header keywords will be checked)

Die technischen Qualitätschecks können vom Publikationsagenten und damit dem Datenarchiv (Repository) durchgeführt und dokumentiert werden. Bei all diesen Checks kann es sein, dass sie nicht durchgeführt werden können. Wichtig dabei ist, zu dokumentieren, welche Checks durchgeführt worden sind, damit der Datennutzer eine Einschätzung der Qualität vornehmen kann. Das Langzeitarchiv sollte die zugehörigen Metadaten so darstellen, dass sie mit Standard übereinstimmen bzw. dass diese erzeugt werden können z.B.: ISO 19115 oder NASA DIF. (todo Ergänzungen?)

SQA

Die wissenschaftlichen Qualitätschecks (SQA) können wir in drei Teilbereiche aufteilen:

SQA der Metadaten des Repositories

Hierzu gehören alle relevanten Details der Erstellung und des Processing der Daten, wie (nicht Methode), wer, wann und wo die Daten erzeugt hat. Es sollte dargestellt werden, welche Basisparameter erzeugt wurden mit welchen Werkzeugen (Instrumente, Rechner…).

Provenance und Prozessketten

Wie sehen die Prozessketten aus (pre-, post-processing), Vorgänger - Nachfolger?

Für Messmetadaten sollten Metadaten über Ort, Zeit, benutzte Instrumente, Level z.B. http://www.godae.org/Data-definition.html und allgemeine Beschreibung vorhanden sein.

Für Modelldaten sollten Metadaten über die benutzten Rechner und Modelle vorhanden sein

Für die Referenzierung der Daten sind Zitatbeschreibung notwendig. Hierzu gehören z.B. Titel, Autorenliste…

Es sollte immer eine beschreibenden Internetseite (DDD) existieren (dieses sollte in der TQA getestet werden) auf die man über die Angabe eines Identifiers in der Referenzierung zugreifen kann. Deren Inhalte sollten ebenfalls geprüft werden z.B. http://cera-www.dkrz.de/WDCC/ui/Compact.jsp?acronym=CLM_B1_2_D2 (dieses ist Teil der SQA).

Die Metadatenbeschreibung (SQA der Metadaten) sind von dem Datenerzeuger und dem Publikationsagent gemeinsam zu bearbeiten, da Teile die Inhalte der Daten betreffen und Teile den Datenzugriff. Hier sollten beide eng kooperieren.

SQA der Daten

Diese Aussagen müssen durch durchgeführte Tests erhärtet werden. Es soll die Glaubwürdigkeit der Daten dargestellt und die Bereiche aufzeigen, die besondere Beachtung der Datennutzer brauchen. Hierfür müssen die entsprechenden Algorithmen mit ihren Ergebnissen dargestellt werden, damit die Qualitätschecks entsprechend klassifiziert werden können z.B.: (Düsterhus et al., 2012). Wir unterscheiden drei Bereiche, Konsistenz der Daten, spiegeln die Daten mit genügender Genauigkeit die Wirklichkeit wieder und sind die Daten für die entsprechende Fragestellung brauchbar?

Basic (Konsistenz der Daten)

· Sind die Daten intern konsistent?

Dazu gehört der Test, ob die Werte in einem Bereich liegen, der sinnvoll für eine Simulation oder Beobachtung ist? Hier sollten z.B. Ausreißer erkannt werden.

· Sind die Daten zeitlich konsistent?

Ist der zeitliche Ablauf der Daten plausibel oder gibt es Sprünge in den Werten, die nicht erwartet werden.

· Sind die Daten räumlich konsistent?

Diese Tests können in der horizontaler und vertikaler Richtung erfolgen. Hierbei wird getestet, ob die Daten zu den umgebenden räumlichen Werten passen.

Intermediate

· Spiegeln die Daten mit genügender Genauigkeit die Wirklichkeit wieder?

Gibt es eine Einordnung in ein Quality Level System? Hier seien die Systeme für CMIP5 (http://cmip5qc.wdc-climate.de ) und Beobachtungsdaten (http://www.godae.org/Data-definition.html ) genannt. (todo bitte ergänzen)

· Gibt es Fehlerabschätzungen für Messdaten? siehe hierzu: http://hss.ulb.uni-bonn.de/2013/3100/3100.htm

Es gibt 3 Typen von Fehlern: random
systematic (changes in mean, var and trends)
rough errores (outliers, missing data)

Zu large errors siehe Zahumensky, 2007.

Fehlerquellen können sein:
measurement
recording
digitisation
transmission processing

· Gibt es eine Fehlerabschätzung für Modelldaten?

Die Modelldaten bestehen aus Modelloutput von Simulationsrechnungen. Für eine Fehlerabschätzung müsste der Code und der Compiler auf Fehler untersucht werden. Ebenfalls Einfluss hat die Rechnergenauigkeit mit der der Algorithmus berechnet wird. Beim Wechsel des Rechners für eine Simulation können andere Ergebnisse entstehen.

· technische Probleme führen zu Modellprobleme. Kann man hierfür sollten Checkliste erstellt werden?
Numerische Stabilität · Was passiert bei sehr grossen und was bei sehr kleinen Zahlen?
· Robustheit des Modells bei Extremwerte. Werden bei Exceptions Daten gedeckelt? Wie geht das Modell mit overflow und zero um
· Welche Einheiten werden genutzt z.B. bei precipitation mm/d oder m/sec ?
· Rundungsfehler abhängig vom Rechner
· Verdrehen lat, long, Level, rotated poles, Gitterkonvertierung Einfluss z.B. auf Wind
· Zeitprobleme bei Mittelungen
· Umrechnungen: Welche sind erlaubt?

· Sind die Daten plausibel?

Wurden die Daten gegen andere unabhängige Daten validiert? ERA, NCEP, CRU, HOAPS
Diese Evaluation kann mit Biasschätzung und Statistik mit Taylor Diagramme erfolgen.
Beispielchechliste aus Exarch:
surface tempretarue, preciptiation, zonal mean zonal wind, ORL, shortwave absorbed by the atmoshpere comlumn.

· Gibt es eine Beschreibung der Daten, die die oberen Kriterien beschreiben und deren Anwendungsmöglichkeiten aufzeigen?
Dieses kann auch in Projekte erfolgen, die Modelle vergleichen.
z.B. für globale Modelle in amip (vorgegebener Ozean zeitraum 80-90 ?) , cmip3, cmip5

Advanced

Sind die Daten für die entsprechenden Fragestellungen brauchbar?

Advanced diagnostics auf Strukturen:

Welche Phänomäne (realistische, seansonale, monatliche oder mehrjährige Strukturen) und regionalen Effekte
lassen sich in den Modeldaten finden, ohne das Modell extra zu tunen durch-Parameter und Auflösungsanpassung

· Benchmarktest checklist ExArch: Monsoon Systems, Atmosperic Dynamics: Cyclones, Eddy-fluces, Extretropical modes of variability, Snow Cover, hydrology, Moist Thermodynamics, General Circulation

· QBO Oszillation in Tropopause

· Ozzilation in Stratosphere

· El Nino

· Hurracans (Physik und Dynamik)

· Nordatlantische Tiefenwasserproduktion

· Erwartete Drifts zu erkennen
-driften Energie und Massenerhaltung - Gleichungen gehen davon aus, dass dieses nicht der Fall ist.

SQA der Methoden

Besteht aus Evaluation (Beschreibung, Analyse und Bewertung), Verfikation und Falsifikation der Methoden

Beobachtungsdaten

· Kalibrierung der Instrumente

· Präzise Zeit- und Ortsbeschreibung

· Situation im Bereich der Messung

· Physikalische Beschreibung der gemessenen Daten

Diese Beschreibungen sind sehr detailliert und sollten in einem Journal oder Data Journal publiziert werden.

Modelldaten

· Für die Modelldaten gehören hierzu die Beschreibung der Modelle und ihrer Gleichungen. Dieses ist ebenfalls sehr detailliert und sollte in einem Journal oder Data Journal publiziert werden.

· Existiert Modellbeschreibung, Beschreibung der Komponenten

· Läufe zu Validierung der Simulationen

Parametrisierung: Wie sieht diese aus?

Auflösung
Welche Auflösung haben die Komponenten
Was passiert bei höherer Auflösung
Zeitschritt abhängig von Auflösung (z.B. wenn max Windgeschwindigkeit über die Zelle hinweggeht)

Randbedingungen, Input und Konstante

· Stammbaum der Modellfamilien z.B.: http://www.gfdl.noaa.gov/jrl_gcm http://www.aip.org/history/climate/xAGCMtree.htm

Die wissenschaftlichen Qualitätsaussagen sollten vom Datenerzeuger bestätigt werden. Die zugehörige Dokumentation sollte als Metadaten zur Verfügung stehen. Dieses können Texte, Reverenzen zu bestehende Journal Publikationen, beliebige Dokumente mit Grafiken sein. Eine Einordnung in ein Quality Level System sollte falls möglich vorgenommen werden.

Checklisten sollen erstellt werden, welche Parameter angeschaut werden (prognostische, diagnostische)
atm, ocean, rest
Nicht alles kann getestet werden, es soll checklisten geben , die ein level system repräsentieren.

Projekt: exarch

http://proj.badc.rl.ac.uk/exarch http://proj.badc.rl.ac.uk/exarch/wiki/CDB http://proj.badc.rl.ac.uk/exarch/wiki/DeliveryPlanWp3#no1

In exarch_wp3_v07.doc gibt es ein qa schema design und in 4.2 ein accompanying paper intended for peer-review should be under way. Das Schema unterscheidet zwischen TQA und SQA in unserem Sinne. Es gibt dort Listen und diesqa advanced diagnostics.

Projekt: preparde

http://www2.le.ac.uk/projects/preparde

Deliverable

Workflows:

BADC 3 Typen
-data submitter engaged(DOI) checks cmip5
-data dumper(nur Speicherung wir bei uns LTA)
-BADC broker transfer

NCAR
QC consistency and completeness, Perform qc and final dat checks, general statistics

NERC 
Erst bei data paper 
( 1) passt es inhaltlich?)
2) scientific review of data set. Eg is it accurate in its methods of data acquisition, statistical info
and error calculations etc? Is the data scientifically useful?

3) review of Data Paper. Eg does the paper adequately describe the data set? Does it explain
the data acquisition methodology etc?

Im Blog:

https://docs.google.com/file/d/0ByE-kVBE6aUVMERJLTh4UDY5VDA/edit

WDCC/DKRZ

Infrastrukturfragen und geforderte (technical and scientific) Checklisten für reviewer.
Wie diese genauer aussehen sollen, wird nicht beschrieben.

Review Beobachtungdaten

Doktorarbeit von Andre:
http://hss.ulb.uni-bonn.de/2013/3100/3100.htm

Review Modelldaten

WDCC TQA, SQA mit atarrabi QA cmip5 und cordex

liste QA vorm ingest

MadWiki: DMIntern/Data_Publication/reviewDATA (last edited 2013-06-27 09:46:54 by HeinkeHoeck)