Epic Data Logo

Data for People

Projekt Website: https://www.dataforpeople.net

Diese Seite hier beschreibt unseren Beitrag für den #WirVsVirus Wettbewerb der Bundesregierung.

Was wir gemacht haben

  • Wir (Jürgen, Johanna, Fabrice, Ruben, Valentin) sind Samstag spontan für den Hackathon zusammen gekommen, um eine für 0008 Corona Tracking, 0024 Krankenhäuser, 0038 Daten relevante neue Lösungsidee zu entwicklen. Unser Ansatz ist sehr flexibel und trägt daher zu mehreren Challenges bei: zum Beispiel ID 1388, ID 0004 Registrierung medizinisches Personal, ID 0193 Eine globale und zentrale Datenbank/Datalake mit Schnittstellen APIs, ID 1474 Data Hub für Deutschland, ID 1591 Datengetriebene Entscheidungsfindung ID 1932 Echtzeit Infektionsmonitoring, ID 1958 Korrekte aktuelle Informationen, ID 1294 Echtzeitdaten statt Fake News und wahrscheinlich noch einigen anderen.
  • Unser Ansatz kann generell für gesellschaftliche Herausforderungen angewendet werden, die dieselben Charakteristika zeigen: massiv verteiltes Datenaufkommen, Notwendigkeit zeitnaher multiperspektivischer Analysen, Informieren von unterschiedlichsten Entscheidungsträgern und der Öffentlichkeit.
  • In der Kürze der Zeit war eine Erstellung von Code nicht zu machen. Unser Ziel war es daher nur, einen Grundstein zu legen. Weiter unten findet sich eine verständliche Beschreibung der Grundideen. Diese könnten von jedem beliebigen anderen Team aufgegriffen werden. Aber auch wir sind bereit, weiter dran zu bleiben. Dafür würden wir aber Unterstützung brauchen (Kontakte, Entwickler, finanzielle Ressourcen, etc.)! Das Ziel ist ambitioniert aber mit genügend Entschlossenheit und der Dialogbereitschaft der Stakeholder (siehe unten) machbar.

Welches Problem wir lösen

Gesellschaftlich relevante Daten fallen oft über das ganze Land, ja sogar die ganze Welt verteilt an (COVID-19, CO2 Ausstoß, etc.). Probleme:

  • Erfassung und Weiterleitung der Daten ist mühselig, langsam und uneinheitlich.
  • Es existieren keine einheitlichen Datenformate.
  • Verifizierte Datensätze sind schlecht zugänglich.
  • Oftmals werden (wenn überhaupt) nur Zusammenfassungen veröffentlicht. Entscheidungsträgern (Regierungen auf allen Ebenen, Krankenhäuser, Versorgern, etc.) und der Öffentlichkeit mangelt es an hochwertig aufbereiteten, aktuellen, viele Perspektiven abdeckenden Informationen. Nur wenige Stakeholder sind an der Informationskette beteiligt. Viel Potential bleibt auf der Strecke, weil keine Möglichkeit zur Partizipation besteht.

Das Ziel

Big Data im Dienst des Einzelnen. Eine dezentrale, hoch skalierbare, offene Plattform für die Aggregation, Verarbeitung und Veröffentlichung von verifizierten, anonymen gesellschaftlich relevanten Daten. Privacy by Design ist unabdingbare Grundlage.

Beispiel: Erst dieses Wochenende hat das Robert Koch Institut falsche Schlussfolgerungen veröffentlicht, weil sie sich auf unvollständige Daten bezogen haben. Mit unserem System würden solche Pannen der Vergangenheit angehören.

Netzwerk

Die Idee …

… besteht darin, in den letzten Jahren gereifte Open Source Projekte, offene Datenformate und Konzepte für eine möglichst günstige Erreichung des Ziels zu verknüpfen. Insbesondere stehen uns mit dezentralen peer-to-peer Architekturen heute ganz neue Möglichkeiten offen, ein fundamental demokratisch strukturiertes System zu schaffen.

Wichtige Eigenschaften

  • Existierende Datenquellen, Analyse und Visualisierungswerkzeuge werden eingebunden. Das Rad wird nicht neu erfunden.
  • Garantie der Authentizität der Daten und Qualität der Analyse.
  • Die sorgfältig anonymisierten Daten sind frei öffentlich verfügbar (Open Data).
  • Hoch skalierbar und krisenresistent. Live Updates.
  • Daten können dezentral eingespeist werden.

Stakeholder/Nutznießer

  • Regierungen, Behörden und Ämter (Grundlage für Entscheidungsfindung)
  • Forschungsinstitute (Datengrundlage für Analyse und Forschung)
  • Medien/Öffentlichkeit (Transparenz)
  • Bürger:innen (schnelle vertrauenswürdige Aufklärung)

Die Komponenten der Lösung

Open Data Pool

Die Grundlage ist ein frei zugänglicher, offener Datenpool. Dieser Pool ist dezentral organisiert, was die Abhängigkeit von einem zentralen Server eliminiert. Jeder Teilnehmer (einfacher PC mit Netzzugang) stellt ein Knoten dar. Jeder Knoten hält seine eigenen Daten vorrätig und kopiert externe Daten, die er verarbeitet (Redundanz). Das System skaliert so automatisch mit der Menge der beteiligten Stakeholder. Das System ist ausfallsicher, da der Wegfall einzelner Knoten das Funktionieren des Gesamtsystems nicht beeinträchtigt.

Bürger:innen finden per Smartphone Zugang zu diesem Pool.

Eine solche Architektur wurde in den letzten Jahren als Open Source von einem internationalen Team entwickelt und steht uns ohne Einschränkungen zur Verfügung (technische Details finden sich weiter unten).

Jeder Knoten hat einen öffentlichen Schlüssel (Teil einer Public-Key-Infrastruktur) über den er identifiziert werden kann (Details weiter unten).

Datenquellen

Der Pool ist für alle offen zugänglich (schreiben und lesen). Publizierte Daten müssen mit dem eigenen privaten Schlüssel signiert werden. So kann Authentizität garantiert werden (siehe Zertifikation).

Beispiel: Krankenhäuser, die anonymisierte (!) Krankenberichte oder Auslastung, Versorgungslage (Masken, Beatmungsgeräte, etc.) publizieren.

Der Pool hat weder geographische noch sprachliche Grenzen und kann daher weltweit genutzt werden.

Zertifikation

Zertifizierende Knoten sind spezielle Datenquellen. Sie publizieren Listen von zertifizierten öffentlichen Schlüsseln.

Beispiel: Gesundheitsämter publizieren die öffentlichen Schlüssel aller ihnen zugeordneten medizinischen Einrichtungen. So können an COVID-19 relevanten Daten interessierte Dritte sicherstellen, dass nur verifizierte Krankendaten verarbeitet werden.

Web of Trust

Auf oberster Ebene stehen Regierungen, die verifizierte Listen von Gesundheitsämtern publizieren. Der öffentliche Schlüssel der Regierung kann z.B. auf der offiziellen Website der Regierung veröffentlich werden. So kann jeder an Open Data Interessierte von einem verifizierten Startpunkt aus beginnen und sich durch den Pool navigieren.

Diese Idee lässt sich natürlich auf viele andere Bereiche (nicht nur COVID-19) übertragen. Entscheidend ist, dass Datenquellen offline durch etablierte Verfahren verifiziert werden können.

Aggregation, Analyse und Aufbereitung

Interessierte Stellen (RKI, Ämter, Forschungseinrichtungen, technisch versierte Journalisten, etc.) können nun verifizierte Daten zusammenfassen und auswerten. Die Ergebnisse werden ebenfalls im Open Data Pool publiziert. Die Webseiten dieser Organisationen veröffentlichen ihre öffentlichen Schlüssel. So kann garantiert werden, dass eine Analyse tatsächlich z.B. vom Robert Koch Institut stammt.

Solche verarbeitende Knoten können Spezifikation ihrer Aufbereitungstätigkeit (welche Relationen ihre Analyse-Ergebnisse zu den Eingabe-Daten erfüllen) online veröffentlichen. So können Dritte die Validität der versprochenen Aufbereitung hin und wieder durch Tests verifizieren. Unabhängige Organisationen können so die Qualität der Datenverarbeitung überwachen. Eine Eigenschaft, die vor allem durch die Offenheit und Transparenz unseres Systems ermöglicht wird.

Visualisierung

Visualisierungswerkzeuge können über den Pool die Ergebnisse von ausgesuchten Aggregatoren abonnieren.

Beispiele:

  • Eine Smartphone App für das allgemeine Publikum (siehe Mockup in unserer Galerie).
  • Das Dashboard einer Wochenzeitung, Landrats, Bürgermeister, etc.
  • Versorger und Krankenhäuser sind permanent auf dem Laufenden, wobei sie genau die Daten und Perspektiven bekommen, die ihren Aufgaben am besten gerecht werden.

Epic Data Dashboards

Kollektive Intelligenz

Insgesamt ergibt sich ein Bild, das unserem Gehirn ähnelt. Die Datenquellen sind wie Sinnesorgane, so stellen wir fest, was in der Gesellschaft passiert. Die Visualisierer liefern Informationen für Entscheidungsträger und alle Bürger. So wird sinnvolles Handeln angeregt. Dazwischen liegen Knoten, die die Aggregation, Analyse und Aufbereitung von Daten vornehmen. Das entspricht den Nervenzellen unseres Gehirns. Unser Vorschlag – richtig umgesetzt – erhöht die kollektive Intelligenz unserer Gesellschaft.

Kollektiv


Technische Umsetzung

Datenpool

Besonders geeignet hierfür ist das Interplanetary File System IPFS. In IPFS werden Dateien statt durch ihren Ort (URL) per Content Hashes adressiert. Adressen können damit nie veralten. Dateien können nur abgerufen werden, wenn der Content Hash bekannt ist. Content Hashes werden von Datenquellen publiziert.

Dateien können selbst wieder Content Hashes enthalten. So kann eine Datei andere weitere Dateien verlinken. Es ergibt sich ein gerichteter azyklischer Graph, der sog. Merkel DAG.

Datenquellen

Datenquellen können in IPFS durch Einträge in den IPNS (Interplanetary Namespace) realisiert werden. Die ID (Hash eines Public Keys) einer Datenquelle wird so einem Content Hash und damit einer publizierten Datei zugeordnet. Solche Einträge müssen mit dem Private Key der Quelle signiert werden. So wird die Authentizität der publizierten Datei garantiert.

IPFS enthält ein dezentrales PubSub System. Änderungen im IPNS Eintrag einer ID werden sofort an Abonnenten (Aggregatoren, Visualisierer) weitergeleitet, die dann die geänderten Werte berücksichtigen können.

Da Dateien auf andere verweisen können, können Datenquellen tatsächlich ganze Datenbäume veröffentlichen. In unserem Fall besteht ein solcher Datenbaum aus einer effizienten Repräsentation einer mit Change Token indizierten Liste von Updates. Aggregatoren persistieren lokal in ihrem Knoten den letzten gesehenen Change Token und können so bei Änderungen effizient die neuen Einträge identifizieren und laden.

Ein erweiterbares Dateiformat

Als Dateiformat verwenden wir JSON-LD. JSON-LD ist leicht zu lesen und zu generieren. Das besondere daran ist, dass es auf transparente Weise auf beliebige Anwendungsbereiche zugeschnitten werden kann. Der @context Link in einer JSON-LD Datei verweist auf eine maschinenlesbare Spezifikation der in der Datei verwendeten Typen.

So können alle Stakehoder jederzeit ihre eigenen Dateiformate erzeugen oder modifizieren. Somit entfallen langwierige Abspracheprozesse im Vorfeld. Es steht jedem Aggregator oder Visualisierer frei, die maschinenlesbare online verfügbare Spezifikation der Dateiformate anderer Datenquellen zu inspizieren und Importer zu schreiben (eine Sache von wenigen Stunden).

Datenquellen

Aggregatoren und verarbeitende Knoten

Knoten jeglicher Art, welche den von Datenquellen erzeugten Strom von Updates verarbeiten, verwenden WolkenKit. Das Event Sourcing von WolkenKit erlaubt abonnierte Datenströme lokal zu cachen, so müssen nur Änderungen nachgeladen werden. WolkenKit übersetzt zwischen der Welt der Datenquellen und ihren eigenen Dateiformaten auf der einen Seite und dem vom Aggregator/Verarbeiter angestrebten Ergebnismodell auf der anderen Seite (CQRS). WolkenKit kann von interdisziplinären Teams leicht auf den jeweiligen Einsatzbereich angepasst werden (DDD).

Sonstiges

  • Adapter können legacy Formate in JSONLD konvertieren
  • Einfach Web UIs zur manuellen Pflege von Daten
  • Adapter binden existierende Analyse Tools (z.B. http://www.aiit.io, http://covidsim.eu) oder Visualisierungen ein

Built With

  • ipfs
  • jsonld
  • wolkenkit
+ 3 more
Share this project:

Updates