Social Reporting basiert auf der Idee, dass Mitglieder eines ortsbezogenen sozialen Netzwerks in der realen Welt für Mitglieder des Netzwerks relevante Ereignisse beobachten und Berichte über diese Beobachtungen anderen Nutzern zur Verfügung stellen. Ein grundlegendes Problem des Social Reporting ist die Auswertung der Berichte und hierbei vor allem die Bewertung der Zuverlässigkeit eines Berichts. Es stellt sich die zentrale Frage: Wie sehr kann einem Bericht auf Basis anderer verwandter Berichte vertraut werden und wie lässt sich dieses "Vertrauen" ohne menschliches Eingreifen bestimmen?
Viele Anwendungsszenarien des Social Reporting bilden einen recht kleinen und klar umrissenen Teil der Wirklichkeit ab. Als Beispiele lassen sich hier die Beobachtung von Wildvögeln oder Meldung aktueller Verkehrsereignisse nennen. Die Nutzer bilden also eine recht homogene Gruppe, die sich auf Basis des entsprechenden Anwendungsfalles nur für bestimmte Informationen interessieren. Ebenso ist auch die Auswertung der verschiedenen Berichte und deren Zuverlässigkeit an einen engen Rahmen gebunden, der eine automatische Verarbeitung mit recht einfachen Mitteln erlaubt. Allerdings ist zu beachten, dass die Bewertungskriterien für die Bestätigung von Berichten durch andere Berichte sehr unterschiedlich ausfallen können und absolut vom betreffenden Anwendungsfall abhängig sind.
Die Folge des Bewertungsprozesses ist ein Bestätigungsgraph – auch confirmation graph genannt. Dieser bildet das durchaus komplexe Geflecht von bestätigenden und widersprechenden Berichten ab und erlaubt eine Aussage über die Zuverlässigkeit einzelner Berichte.
Da in der bisherigen Nutzung des Social Reporting aufbauend auf einen beliebigen Anwendungsfall stets nur komplexe spezifische Regel- und Auswertungssysteme zum Einsatz kamen, wird in der vorliegenden Arbeit ein generischer Ansatz vorgestellt. Mit diesem ist es möglich auch komplexe und völlig unterschiedliche Anwendungsfälle mit einem Regelsystem abzubilden und einen davon ausgehenden Bestätigungsgraphen zu generieren.
Inhaltsverzeichnis
1 Social Reporting
1.1 Aktuelle Entwicklungen und Anwendungen
2 Grundlagen
2.1 Definitionen, Festlegungen und Einschränkungen
2.2 Definition und Struktur eines Bestätigungsgraphen
3 Generischer Ansatz zur Erstellung eines Bestätigungsgraphen
3.1 Ausgewählte Anwendungsfälle
3.1.1 Beobachtung von Wildvögeln
3.1.2 Storm Chasing
3.1.3 Meldung von Gewalttaten
3.2 Struktur eines Berichts und Relationen zwischen Berichten
3.2.1 Grundlegender Aufbau eines Berichts
3.2.2 Beschreibung der Beobachtung
3.2.3 Zeitintervall der Beobachtung
3.2.4 Position der Beobachtung
3.2.4 Optionale Attribute
3.3 Aufbau eines Regelwerks und dessen Grammatik
3.3.1 Nutzung der Lernumgebung AtoCC
3.3.3 Datenbankbereich des Regelwerks
3.3.4 Attributbereich des Regelwerks
4 Umsetzung und Implementierung des Ansatzes
4.1 Use Cases und Systementwurf
4.2 Auswahl der Spatial Database auf Serverseite
4.2.1 MySQL in der Version 5.5.13
4.2.2 Oracle Datenbank 11g Standard Edition One (SE1)
4.2.3 PostgreSQL in der Version 9.0.4
4.3 Entwurf des Datenbankaufbaus
4.4 Implementierung auf Serverseite
4.4.1 Subsystem Server Console
4.4.2 Subsystem Network Communication
4.4.3 Subsystem Controller
4.4.4 Subsystem Database Management
4.4.5 Subsystem Rules Management
4.4.6 Subsystem Rules Scanner and Parser
4.4.7 Subsystem Confirmation Graph
4.5 Implementierung auf Clientseite
4.5.1 Subsystem User Interface
4.5.2 Subsystem Controller
4.5.3 Subsystem Network Communication
5 Evaluation der Generic Social Report Confirmation Software
5.1 Aufbau des genutzten Regelwerks
5.2 Parsen des Regelwerks und Erstellen der Tabellenstruktur
5.3 Regelanwendung und Bestätigungsgraph
6 Fazit und Rückblick
7 Literatur
A Anhang
1 Vollständige Grammatik der Regelsprache
2 Übersicht über den beiliegenden Datenträger
Abbildungsverzeichnis
Abbildung 1: Beispielhafter gerichteter und gewichteter Bestätigungsgraph
Abbildung 2: Einblick in die Datenbank von naturgucker.de zur Vogelbeobachtung
Abbildung 3: Berichtserfassung bei naturgucker.de
Abbildung 4: Dreizehn mögliche temporale Relationen nach Allen (vgl. Allen, 1983, S. 835)
Abbildung 5: Genutzte räumliche Relationen nach dem Open GIS Consortium
Abbildung 6: Beispielhafte Reports und deren Grundattribute
Abbildung 7: Mögliche Kategorien optionaler Attribute
Abbildung 8: Grammatik des Regelwerks - Grundaufbau
Abbildung 9: Grammatik des Regelwerks - Datenbankbereich
Abbildung 10: Beispielhafte Nutzung des Datenbankbereichs des Regelwerks
Abbildung 11: Grammatik des Regelwerks - Attributbereich
Abbildung 12: Beispielhafte Nutzung des Attributbereichs des Regelwerks
Abbildung 13: Grundlegende Struktur einer Bestätigungsregel
Abbildung 14: Grammatik des Regelwerks - Grundlegender Aufbau von Regeln
Abbildung 15: Beispielhafter grundlegender Aufbau von Regeln
Abbildung 16: Grammatik des Regelwerks - Erweiterung für räumliche Konditionen
Abbildung 17: Grammatik des Regelwerks - Erweiterung für temporale Konditionen
Abbildung 18: Grammatik des Regelwerks - Erweiterung für attributive Konditionen
Abbildung 19: Use-Case-Diagramm als Basis der Implementierung
Abbildung 20: Systementwurf nach dem MVC-Architekturmuster
Abbildung 21: Entwurf des Datenbankaufbaus
Abbildung 22: Klassendiagramm für das Server-Subsystem "Server Console"
Abbildung 23: Klassendiagramm für das Server-Subsystem "Network Communication"
Abbildung 24: Beispiel einer Server-Konfigurationsdatei
Abbildung 25: Klassendiagramm für das Server-Subsystem "Controller"
Abbildung 26: Klassendiagramm für das Server-Subsystem "Database Management"
Abbildung 27: Klassendiagramm für das Server-Subsystem "Rule Management"
Abbildung 28: Grundsätzlicher SQL-Aufbau einer Bestätigungsregel
Abbildung 29: Umsetzungstabelle von Regelkonditionen zu SQL-Statements
Abbildung 30: Klassendiagramm für das Server-Subsystem "Rules Scanner and Parser"
Abbildung 31: Klassendiagramm für das Server-Subsystem "Confirmation Graph"
Abbildung 32: Beispiel eines Clients
Abbildung 33: Klassendiagramm für das Client-Subsystem "User Interface"
Abbildung 34: Klassendiagramm für das Client-Subsystem "Controller"
Abbildung 35: Klassendiagramm für das Client-Subsystem "Network Communication"
Abbildung 36: Regelwerk für den Anwendungsfall Wetterbeobachtung
Abbildung 37: Genutzte Regionen für die Evaluierung der Software
Abbildung 38: Vom Server automatisch angelegte Datenbankstruktur für Wetterberichte
Abbildung 39: Bestätigungsgraph nach zwei eingefügten Reports
Abbildung 40: Bestätigungsgraph nach drei eingefügten Reports
Abbildung 41: Bestätigungsgraph nach sieben eingefügten Reports
Abbildung 42: Bestätigungsgraph nach zehn eingefügten Reports
1 Social Reporting
Social Reporting basiert auf der Idee, dass Mitglieder eines ortsbezogenen sozialen Netz- werks in der realen Welt für Mitglieder des Netzwerks relevante Ereignisse beobachten und Berichte über diese Beobachtungen anderen Nutzern zur Verfügung stellen (vgl. Schlieder et al., 2010). Ein grundlegendes Problem des Social Reporting ist die Auswertung der Berichte und hierbei vor allem die Bewertung der Zuverlässigkeit eines Berichts. Es stellt sich die zen- trale Frage: Wie sehr kann einem Bericht auf Basis anderer verwandter Berichte vertraut wer- den und wie lässt sich dieses "Vertrauen" ohne menschliches Eingreifen bestimmen?
Viele Anwendungsszenarien des Social Reporting bilden einen recht kleinen und klar umrissenen Teil der Wirklichkeit ab. Als Beispiele lassen sich hier die Beobachtung von Wildvögeln oder Meldung aktueller Verkehrsereignisse nennen. Die Nutzer bilden also eine recht homogene Gruppe, die sich auf Basis des entsprechenden Anwendungsfalles nur für bestimmte Informationen interessieren. Ebenso ist auch die Auswertung der verschiedenen Berichte und deren Zuverlässigkeit an einen engen Rahmen gebunden, der eine automatische Verarbeitung mit recht einfachen Mitteln erlaubt. Allerdings ist zu beachten, dass die Bewertungskriterien für die Bestätigung von Berichten durch andere Berichte sehr unterschiedlich ausfallen können und absolut vom betreffenden Anwendungsfall abhängig sind.
Die Folge des Bewertungsprozesses ist ein Bestätigungsgraph - auch confirmation graph genannt. Dieser bildet das durchaus komplexe Geflecht von bestätigenden und widersprechen- den Berichten ab und erlaubt eine Aussage über die Zuverlässigkeit einzelner Berichte.
Da in der bisherigen Nutzung des Social Reporting aufbauend auf einen beliebigen Anwendungsfall stets nur komplexe spezifische Regel- und Auswertungssysteme zum Einsatz kamen, wird in der vorliegenden Arbeit ein generischer Ansatz vorgestellt. Mit diesem ist es möglich auch komplexe und völlig unterschiedliche Anwendungsfälle mit einem Regelsystem abzubilden und einen davon ausgehenden Bestätigungsgraphen zu generieren.
Um die Komplexität des vorliegenden Ansatzes gering zu halten beschränkt sich der Ansatz zunächst nur auf nicht-metrische, temporale und attributive Relationen zwischen Berichten. Eine Erweiterung um soziale Aspekte ist jedoch eine denkbare Möglichkeit um den Funktionsumfang des folgenden generischen Ansatzes auszuweiten.
1.1 Aktuelle Entwicklungen und Anwendungen
Social Reporting ist ein noch recht junger Forschung- und Anwendungsbereich, der bisher bis auf wenige Ausnahmen keine große Rolle gespielt hat oder spielt. Allerdings zeigt die aktuelle Entwicklung, dass Social Reporting auf dem Weg ist eines der kommenden großen Themen im Bereich der sozialen Netzwerke zu werden.
Ein sehr bekanntes Beispiel ist das Ushahidi1 Projekt: "Ushahidi [ … ] describes itself as a tool for people who witness acts of violence in Kenya to report incidents that they have seen. The incidents are then placed on a map-based view for others to see. Most incidents listed on the website are verified by local groups working on the ground." (Okolloh, S. 66)
Zu Beginn des Projekts konnten Berichte über aktuelle Gewalttaten per SMS oder direkt über die Webseite eingeschickt werden. Hierbei mussten jedoch alle Berichte manuell über- prüft und freigeschaltet werden, was vor allem durch stetiges Wachstum immer mehr Arbeit bedeutete. Eine Überprüfung der Verlässlichkeit eines Berichts war ebenso ein Problem, da man immer auf der Suche nach einer sicheren Quelle war, wie zum Beispiel nach einem Re- port vor Ort, den man telefonisch erreichen konnte und um Bestätigung bitten konnte.
"This is the risk with any crowdsourcing social media tool. 'Truth' is not guaranteed - but the idea behind crowdsourcing is that with enough volume, a ‘ truth ’ emerges that diminishes any false reports. To avoid the risk of the website being used for propaganda, reports were monitored before they went 'live'. Anything that appeared to be patently false, inflammatory or inaccurate was not posted." (Okolloh, S. 67)
Auch bei diesem Projekt zeigte sich schnell, dass man nur sehr schwer bestimmen kann, wie sehr man einem Bericht vertrauen darf. Sei es nun die Beobachtung von Wildvögeln oder auch die Beobachtung und Meldung von Gewalttaten. Die Frage die sich hier immer stellt: Wie soll man mit Berichten umgehen, deren Zuverlässigkeit umstritten ist?
Sicherlich kann man durch manuelles Eingriff besonders falsche Berichte sofort aussortieren, aber je größer und komplexer ein Anwendungsfall wird, desto schwieriger wird es auch für einen Menschen eine richtige Entscheidung in dieser Hinsicht zu treffen. Daher ist auch hier eine automatische Auswertung sinnvoll. So gesehen könnte auch das Ushahidi Projekt von einem generischen Ansatz zur Bestätigung von Meldungen profitieren.
Inzwischen wird die Software, die hinter dem ursprünglichen Ushahidi Projekt zum Ein- satz kommt auch für anderen ähnliche Anwendungsfälle eingesetzt: So wurde zum Beispiel unter dem Titel "Nürnberg steigt (bald) auf"2 eine Plattform zur Verbesserung des Fahrradwegenetzes in Nürnberg gestartet. Nutzer können hier direkt auf einer Karte der Stadt Orte für Verbesserungen der Fahrradwege eintragen.
Alle Anwendungsfälle haben jedoch meist das Problem die eintreffenden Berichte automa- tisch auswerten zu können. Welche Berichte bestätigen einen anderen Bericht? Welcher Be- richt widerspricht einem anderen Bericht? Wie sehr kann man einem bestimmten Bericht auf Basis der anderen Berichte vertrauen? Ein generischer Ansatz, der es einem Nutzer erlaubt mit einfachen Mitteln ein automatisches Bestätigungssystem für den eigenen spezifischen An- wendungsfall zu erhalten, ist also ein weiterer wichtiger Schritt für das Social Reporting.
2 Grundlagen
Nachdem die grundlegende Einordnung des vorliegenden generischen Ansatzes im Bezug auf aktuelle Anwendungen und Entwicklungen bestimmt wurde, müssen zunächst noch einige Grundlagen für diesen Ansatz festgelegt werden. Auf den folgenden Seiten werden zunächst einige allgemeine Festlegungen und Einschränkungen beschrieben. Im Anschluss folgen dann Definition und Struktur eines Bestätigungsgraphen.
2.1 Definitionen, Festlegungen und Einschränkungen
Für die Entwicklung des generischen Ansatzes war es nötig eine Reihe von Festlegungen und Einschränkungen vorzunehmen und bestimmte Aspekte genauer zu definieren:
- Der generische Ansatz muss eine Vielzahl unterschiedlicher Anwendungsfälle abbil- den können: Dies beinhaltet während der Entwicklung als Ausgangsbasis genutzte Fälle (siehe Kapitel 3.1), aber auch jede Art weiterer Anwendungsfälle.
- Der Ansatz darf nur inhaltsgleiche Berichte bei der Anwendung der Bestätigungsre- geln nutzen. Es muss daher eine klare Regelung getroffen werden, wie inhaltsgleiche Berichte innerhalb eines Anwendungsfalls zu bestimmen sind (siehe Kapitel 3.2.2).
- Es wird davon ausgegangen, dass Berichte sich grundsätzlich nur bestätigen (Wert gleich +1) oder widersprechen (Wert gleich -1) können. Dazwischen liegende Werte werden zur Minimierung der Komplexität nicht in Betracht gezogen. Zu Beachten ist jedoch: Da verschiedene Bestätigungsregeln unter Umständen zu mehreren bestätigenden oder widersprechenden Kanten zwischen zwei Berichten führen können, muss die Menge aller Kanten sinnvoll zu einer einzigen bestätigenden oder widersprechenden Kante akkumuliert werden.
- Der Ansatz soll nicht-metrische, temporale und attributive Relationen innerhalb der Bestätigungsregeln erlauben. Hierbei ist darauf zu achten, dass alle erdenklichen Möglichkeiten abgebildet werden können (siehe Kapitel 3.2.3 bis 3.2.5).
- Es soll eine einfache Sprache für die Beschreibung eines Regelwerks erstellt werden, die es dem Nutzer erlaubt auch komplexe Systeme abzubilden. Das erstellte Regel- werk soll mit Hilfe eines Compilers in ein für den Server nutzbares Format gebracht werden. Hierfür bietet sich SQL-Code an, der dann direkt vom Server für Anfragen bei der im Hintergrund liegenden Datenbank genutzt werden kann (siehe Kapitel 3.3).
- Grundlegende Trennung zwischen Server und Client: Der Server auf Java-Basis nimmt eintreffende Berichte an, validiert deren Integrität und speichert die Berichte bei Erfolg und erstellt bzw. aktualisiert den Bestätigungsgraphen. Der rudimentäre Client auf Android-Basis dient nur zum Erstellen von Berichten und zum Versenden dieser an den Server. Weitere Funktionalitäten werden zur Minimierung der Komple- xität vermieden.
- Die Serverarchitektur soll einen Austausch des Datenbanksystems ohne große Neupro- grammierung ermöglichen, auch wenn die Implementierung zunächst nur ein Datenbanksystem unterstützen wird (siehe Kapitel 4.2).
- Validierungsswerte einzelner Berichte werden auf Basis der eintreffenden Kanten von anderen Berichten berechnet. Hierzu soll die Serverarchitektur verschiedene Algorithmen theoretisch unterstützen, wobei in der Implementierung und bei der Evaluierung nur ein einziger Algorithmus zum Einsatz kommen wird.
2.2 Definition und Struktur eines Bestätigungsgraphen
Der Bestätigungsgraph aller Berichte eines bestimmten Anwendungsfall im Sinne des vor- liegenden generischen Ansatzes ist ein Graph mit gerichteten und gewichteten Kanten, wobei die einzelnen Berichte die Knoten des Graphen darstellen. Hierbei sind in Anlehnung an die in Kapitel 2.1 getroffenen Einschränkungen nur die Werte +1 und -1 als Kantenwerte und zugleich als Bestätigungswerte - oder auch confirmation value - möglich. Hierbei lehnt sich der An- satz an den Ansatz von Schlieder und Yanenko (vgl. Schlieder et al., 2010, S. 5) an. Ein Bestätigungswert [Abbildung in dieser Leseprobe nicht enthalten] sagt aus, dass der Bericht r 1 dem Be- richt r 2 widerspricht. Ein Bestätigungswert [Abbildung in dieser Leseprobe nicht enthalten] sagt aus, dass der Bericht r 1 den Bericht r 2 bestätigt. Natürlich kann es hierbei vorkommen, dass zwei Berichte sich in der einen Richtung bestätigen und in der anderen Richtung widersprechen. Dies ist aber durchaus gewollt, da es zum Beispiel möglich ist, dass einem älterer Bericht von einem neuen Bericht widersprochen wird, der ältere Bericht jedoch zugleich den neuen Bericht an sich bestätigt. Sollte es durch die Regelstruktur dazu kommen, dass mehrere gerichtete Kanten von einem Report zu einem anderen Report zeigen, so müssen diese auf eine einzelne gerichtete Kante akkumuliert werden. Dies geschieht einfach dadurch, dass man die Werte aller gerichteten Kanten addiert und dann durch die Anzahl der Kanten teilt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Beispielhafter gerichteter und gewichteter Best ä tigungsgraph.
Abbildung in dieser Leseprobe nicht enthalten
[Abbildung in dieser Leseprobe nicht enthalten] ist der akkumulierte Bestätigungswert. Hierdurch ist es natürlich möglich, dass sich auch andere Bestätigungswerte als Ÿ1 oder 1 ergeben. Dies ist jedoch durchaus so ge- wollt, um auch genauere Aussagen über den Bestätigungswert zwischen zwei Berichten dar- stellen zu können. Sollte der Fall[Abbildung in dieser Leseprobe nicht enthalten] eintreten, so werden alle gerichteten Kanten ent- fernt, da keine Aussage über Bestätigung oder Widerspruch getroffen werden kann.
Aufbauend auf den Bestätigungswerten kann dann ein spezifischer Validierungswert - oder auch validation value - für einen einzelnen Bericht berechnet werden. Hierfür soll jedoch wie in Kapitel 2.1 festgelegt ein beliebiger Algorithmus zum Einsatz kommen. Dieser Aspekt wird in der Implementierung (siehe Kapitel 4) nochmals angesprochen.
3 Generischer Ansatz zur Erstellung eines Bestätigungsgraphen
Das folgende dritte Kapitel beschreibt die Vorüberlegungen des generischen Ansatzes. Zu- nächst werden eine Reihe von ausgewählten Anwendungsfällen vorgestellt. Die Untersuchung dieser Fälle dient zur Beantwortung der Frage, welche Typen von raum-zeitlichen und attribu- tiven Bestätigungsregeln von praktischem Interesse für den generischen Ansatz sind.
Im Anschluss folgt eine Erläuterung der Grundüberlegungen den Aufbau eines Berichts und eines Regelwerks betreffend. Daran anschließend eine Ausführung der Grammatik, die zum Erstellen von Regelwerken beliebiger Anwendungsfälle zum Einsatz kommt.
3.1 Ausgewählte Anwendungsfälle
Drei ausgewählte mögliche Anwendungsfälle sollen auf den folgenden Seiten vorgestellt werden. Dies sind die Beobachtung von Wildvögeln, Storm Chasing und die Meldung von Gewalttaten - angelehnt an das Ushahidi Projekt (siehe Kapitel 1.1).
3.1.1 Beobachtung von Wildvögeln
Die Beobachtung von Wildvögeln und die Dokumentation der Beobachtungen ist weltweit eine sehr beliebte Tätigkeit. Allein in Deutschland finden sich unzählige Webseiten, die sich mit dieser Thematik befassen und viele dieser Seiten versuchen auch die Sichtungen zu doku- mentieren. naturgucker.de3 ist zum Beispiel eine sehr große deutschsprachige Seite, die mit einer Datenbank aktueller Sichtungen aufwartet, wie in Abbildung 2 zu sehen ist:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Einblick in die Datenbank von naturgucker.de zur Vogelbeobachtung
Die Erfassung eines Berichts bei naturgucker.de ist eine sehr gute Grundlage für die Erarbeitung ei- nes generischen Ansatzes zur automatischen Be- stätigung von Berichten. Neben der Angabe eines Ortes ist zudem die Angabe eines Datums und ei- ner Uhrzeit und natürlich die gesichtete Vogelart anzugeben (siehe Abbildung 3). Desweiteren ist die Anzahl der gesichteten Vögel und zusätzlich eine Beobachtung den Vogel oder die Vögel be- treffend - wie "schwimmend" oder "fischend" - zu machen. Desweiteren gibt es noch die Möglichkeit detaillierter auf Geschlecht oder dergleichen der einzelnen Vögel einzugehen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Berichtserfassung bei naturgucker.de
Hierbei lässt sich bereits sagen, dass ein generi- scher Ansatz auf jeden Fall den Ort einer Beobachtung und die Zeit einer Beobachtung in Be- tracht ziehen muss. Die Zeit ist bei naturgucker.de ein Zeitpunkt und kein Zeitintervall. Hier bleibt die Frage offen, ob ein Zeitintervall oder Zeitpunkt geeigneter für einen Bericht im ge- nerischen Sinne ist. Desweiteren ist natürliche eine eindeutige Angabe der Beobachtung nötig. Im Falle der Beobachtung von Wildvögeln bietet sich hier eine Liste mit möglichen Vogelar- ten an. Zusätzlich scheinen weitere Attribute wie "Anzahl der Tiere" oder "Verhalten" für einen generischen Ansatz nötig zu sein. Diese müssen jedoch abhängig vom Anwendungsfall bestimmbar und festlegbar sein.
Bezug nehmend auf mögliche Bestätigungsregeln sind neben nicht-metrischen und tempo- ralen Relationen auch attributive Relationen wichtig: So lässt sich beispielsweise das Attribut "Anzahl der Tiere" sehr gut dazu nutzen um an sich inhaltsgleiche Berichte miteinander zu vergleichen und deren Zuverlässigkeit zu bestimmen. Stehen zwei Berichte zur Überprüfung an, von denen der eine Bericht von zwei Elstern berichtet und der andere Bericht von fünfzig Elstern, so findet sich hier ein gravierender Unterschied, der erklärbar sein muss. Dieser Um- stand lässt sich sicherlich sehr gut in Bestätigungsregeln nutzen um die Verlässlichkeit eines Berichts zu bestimmen. Für den generischen Ansatz bedeutet dies, dass Regeln sich auch di- rekt auf für den Anwendungsfall spezifische Attribute beziehen können müssen.
3.1.2 Storm Chasing
Vor allem in den Vereinigten Staaten ist Storm Chasing eine sehr beliebte und ebenso auch oft sehr gefährliche Beschäftigung. Nach Vasquez definiert sich Storm Chasing wie folgt:
"Storm chasing, in its simplest terms, is the art and science of meeting with a thunder storm, for any reason. Tornadoes are widely regarded as the main target for storm chasing activity, but anything photogenic, unique in structure, or awe-inspiring fits the definition of a chase target." (Vasquez, 2008, S. 1)
Storm Chaser - wie sich die Anhänger des Storm Chasing nennen - sind also immer auf der Suche nach besonderen Wetterphänomenen, wobei vor allem Tornados im Fokus stehen. Hierbei muss man jedoch beachten, dass viele Wetterphänomene nur kurzfristiger Natur sind und deshalb auch eine sehr schnelle Verbreitung des Berichts darüber nötig ist, was der vor- liegende generische Ansatz durch seine automatische Auswertung unterstützen kann.
Ebenso wie bei der Beobachtung von Wildvögeln sind auch hier drei Informationen von großer Bedeutung: Der Ort der Beobachtung, das Zeitintervall der Beobachtung und natürlich die Beschreibung der Beobachtung. Daneben sind auch hier weitere Attribute denkbar, wie beispielsweise Informationen über Windgeschwindigkeit oder Regenfall.
Mit Blick auf mögliche Bestätigungsregeln zeigt sich an diesem Anwendungsfall sehr schön, dass vor allem räumliche und temporale Relationen eine Rolle spielen: Stehen sich zwei Berichte gegenüber, die das gleiche Zeitintervall und die gleiche Region beschreiben, dabei allerdings der eine Bericht ein Unwetter meldet und der andere Bericht ein Aufklaren des Himmels, so stehen diese beiden Berichte zunächst im Widerspruch. Es muss also in den Bestätigungsregeln die Möglichkeit geben, nicht-metrische und temporale Relationen sinnvoll und in ihrer Gesamtheit abbilden zu können. Denkbar sind hierbei vor allem überschneidende Zeitintervalle. Aber auch direkt aneinander grenzende Zeitintervalle können sinnvoll sein.
Daneben haben Wettererscheinungen wie Unwetter die Eigenschaft, dass sie in recht kurzer Zeit große Strecken zurücklegen und dabei auch verschiedene Regionen nach und nach durchqueren. So ist es denkbar, dass ein späterer Bericht in einer Nachbarregion das gleiche Unwetter beschreibt, diese jedoch einfach nur weiter gezogen ist. Der neuere Bericht würde dann durch den älteren bestätigt werden, wobei dem älteren Bericht möglicherweise durch den neueren Bericht widersprochen wird.
Bei den nicht-metrischen Relationen muss eine Abfrage möglich sein, inwiefern die Regio- nen zweiter Berichte zueinander in Beziehung stehen: Überschneiden sich diese beiden Re- gionen? Grenzen die beiden Regionen direkt aneinander? Auch hier bietet es sich an nicht nur auf diesen Anwendungsfall bezogen sinnvolle Relationen zur Verfügung zu stellen, sondern über eine umfassende Möglichkeit aller denkbaren nicht-metrischen Relationen zu verfügen.
3.1.3 Meldung von Gewalttaten
Bereits in Kapitel 1.1 wurde auf das Ushahidi Projekt verwiesen, dass sich vor allem auf dem afrikanischen Kontinent um die Meldung und Sichtung von Gewalttaten kümmert: "Ushahidi [ … ] describes itself as a tool for people who witness acts of violence in Kenya to report incidents that they have seen." (Okolloh, S. 66)
Ebenfalls in genannten Kapitel wurde bereits darauf verwiesen, dass der hier vorliegende generische Ansatz auch eine Option zur Erweiterung des Ushahidi Projekts wäre. Betrachtet man das Projekt und dessen Ziel genauer, so erkennt man, dass auch hier die Prüfung der Ver- lässlichkeit einzelner Berichte in großes Problem ist. Ein geeignetes Regelwerk zur automati- schen Überprüfung und der Auswertung der Berichte ließe sich sicherlich erarbeiten.
Auch hier spielen nicht-metrische Relationen eine Rolle, wobei zwei inhaltsgleiche Berich- te sich eher in der gleichen Region abspielen und regionsübergreifende Relationen eher selten sein mögen, da eine Gewalttat in der Regel regional sehr gebunden ist. Temporale Relationen spielen hingegen eine sehr viel wichtigere Rolle, da eine zeitliche Einordnung von zeitlich eher kürzeren Ereignissen sehr wichtig für die Bestätigung ist. Hier sind umfangreiche tempo- rale Relationen nötig, die nicht nur ein einfaches Überschneiden der Zeitintervalle beinhalten, sondern auch weitere Relationen wie "zeitgleicher Beginn" oder "zeitgleiches Ende".
Allgemein sind auch hier wieder grundlegende Informationen für einen Bericht nötig: Dies beinhaltet Ort und Zeit der Gewalttat, sowie eine Beschreibung der Gewalttat. Mit diesen Informationen muss es dann möglich sein inhaltsgleiche Berichte zu bestimmen um darauf aufbauend mit Hilfe der Bestätigungsregeln des Regelwerks die Verlässlichkeit der einzelnen gemeldeten Gewalttaten bestimmen zu können.
3.2 Struktur eines Berichts und Relationen zwischen Berichten
Rückblickend auf die bisherigen Ausführungen besteht im Social Reporting grundsätzlich der folgende Sachverhalt: Nutzer generieren Berichte - oder im weiteren Text auch "Reports" genannt - zu einem ausgewählten Anwendungsfall. Diese Reports werden zu einem zentralen Server gesendet und dort ausgewertet. Bei Bedarf werden die Daten im Anschluss für die Nut- zergemeinschaft aufbereitet und nutzbar gemacht. Für einen generischen Ansatz zur Auswer- tung von Reports muss daher zunächst auch ein generischer Ansatz für den Aufbau von Re- ports ausgearbeitet werden. Darauf aufbauend muss eine grundlegende Struktur für Bestäti- gungsregeln erarbeitet werden, die anschließend für die Implementierung des Systems kon- kretisiert und spezifiziert werden muss. Die Grundüberlegungen hierzu finden sich auf den folgenden Seiten.
3.2.1 Grundlegender Aufbau eines Berichts
Bei genauerer Betrachtung der Anwendungsfälle, die in Kapitel 3.1 vorgestellt wurden, zeigt sich, dass alle Reports - unabhängig von ihrem eigentlichen Anwendungsfall - eine grundlegende Struktur teilen. Jede Beobachtung eines Sachverhalts ist einfach ausgedrückt die Antwort auf folgende Frage: Was wurde wann und wo beobachtet?
Die Frage nach dem "was" wird durch die Beschreibung der Beobachtung, die Frage nach dem "wann" durch das Zeitintervall der Beobachtung und die Frage nach dem "wo" durch die Position der Beobachtung beantwortet. Da nur mit diesen drei Informationen eine Beobachtung ausreichend dokumentiert ist, erscheint es logisch, dass auch diese drei Informationen die grundlegende Struktur eines Reports bilden müssen.
In den folgenden Kapiteln 3.2.2 bis 3.2.4 wird nun genauer auf diese fortan als "Grundat tribute" bezeichneten Informationen eingegangen. Vor allem bezugnehmend auf die vorgestellten Anwendungsfälle werden mögliche Relationen zwischen Berichten betrachtet und mögliche Funktionen zur Beschreibung dieser Relationen herausgearbeitet.
3.2.2 Beschreibung der Beobachtung
Um verschiedene Reports eines Anwendungsfalles miteinander vergleichen zu können, muss man zunächst bestimmen können, welche Reports grundsätzlich inhaltsgleich sind. Um beim Beispiel "Storm Chasing" (siehe Kapitel 3.1.2) zu bleiben: Reports über eine besonders interessante Wolkenformation haben in der Regel nichts mit einem Report über eine Tornado- sichtung zu tun. Diese Reports sind nicht inhaltsgleich und sollen daher auch nicht auf eine mögliche Bestätigung oder einen möglichen Widerspruch untersucht werden.
Stattdessen sollen nur Reports, die grundsätzlich die gleiche Thematik beschreiben, auch wirklich für eine gegenseitige Untersuchung in Betracht gezogen werden. Hierfür dient die Beschreibung der Beobachtung, wobei sich auch zugleich ein Hindernis zeigt: Frei verfasste Beschreibungen haben in der Regel das Problem, dass sie nur schwer automatisch auf semantische Ähnlichkeit untersucht werden können.
Um dieses Problem zu umgehen gibt es zwei Möglichkeiten: Man versucht entweder ein umfangreiches System aufzubauen, dass je nach Anwendungsfall semantische Ähnlichkeiten bestimmen kann oder man schränkt die Beschreibungsmöglichkeiten derart ein, dass der Nut- zer nur noch aus einer vorgegeben Liste auswählen kann. Beide Ideen haben ihre Vor- und Nachteile. Im ersten Fall erhält man die Möglichkeit, dass Nutzer sehr genau ihre Beobach- tung beschreiben können, läuft aber Gefahr die einzelnen inhaltsgleichen Reports nicht mehr bestimmen zu können. Im zweiten Fall ist das Bestimmen von inhaltsgleichen Reports ein- fach, da nur bestimmte Beschreibungen - abhängig vom Anwendungsfall - dem Nutzer zur Verfügung stehen und diese eindeutig zuzuordnen sind. Im Gegenzug verliert man jedoch die potenziell sehr genaue Beschreibung der Beobachtungen durch den Nutzer.
Im vorliegenden generischen Ansatz wird vor allem auch aus Gründen der einfacheren Handhabung und Implementierung die zweite Möglichkeit gewählt. Der Nutzer erhält beim Erstellen eines Reports eine Liste möglicher Beschreibungen um die primäre Zuordnung der Beobachtung zu beschreiben. Zusätzlich wird ein Freitextfeld zur Verfügung gestellt um die Beobachtung sekundär zu konkretisieren. Dieser Freitext wird jedoch nicht zur Bestimmung inhaltsgleicher Reports genutzt, sondern dient nur als zusätzliche Informationsquelle für Nutzer des Systems bei der Sichtung von Reports.
3.2.3 Zeitintervall der Beobachtung
Da Beobachtungen nur selten genau in einem Augenblick passieren, sondern immer inner- halb eines Intervalls geschehen - selbst wenn dieses Intervall nur eine Sekunde beträgt - ist es sinnvoller für die Zeit einer Beobachtung einen Anfang und ein Ende zu ermöglichen. Zudem sind temporale Relationen deutlich eingeschränkt, wenn man nur Timestamps nutzt, da eine interessante Wolkenformation haben in der Regel nichts mit einem Report über eine Tornadosichtung zu tun. Diese Reports sind nicht inhaltsgleich und sollen daher auch nicht auf eine mögliche Bestätigung oder einen möglichen Widerspruch untersucht werden.
[...]
1 Siehe: http://www.ushahidi.com/
2 Siehe: http://nuernbergsteigtauf.crowdmap.com/
3 Siehe: http://www.naturgucker.de/
-
-
-
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X. -
-
Téléchargez vos propres textes! Gagnez de l'argent et un iPhone X.