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 ak-
tuelle 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 Ushahidi
1
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 aussortie-
ren, 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-
1
Siehe: http://www.ushahidi.com/
4
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 Fahrradwe-
genetzes 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
2
Siehe: http://nuernbergsteigtauf.crowdmap.com/
5
werden zur Minimierung der Komplexität nicht in Betracht gezogen. Zu Beachten ist
jedoch: Da verschiedene Bestätigungsregeln unter Umständen zu mehreren bestätigen-
den 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ög-
lichkeiten 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 Daten-
banksystem 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 Algorith-
men 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
6
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 c
r
1
, r
2
=-1 sagt aus, dass der Bericht r
1
dem Be-
richt r
2
widerspricht. Ein Bestätigungswert c
r
1
, r
2
=1 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 be-
stä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 gerich-
teten Kanten addiert und dann durch die Anzahl der Kanten teilt.
c
acc
=
i
=1
n
c
i
n
c
acc
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 c
acc
=0 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 je-
doch wie in Kapitel 2.1 festgelegt ein beliebiger Algorithmus zum Einsatz kommen. Dieser
Aspekt wird in der Implementierung (siehe Kapitel 4) nochmals angesprochen.
Abbildung 1: Beispielhafter gerichteter und gewichteter
Bestätigungsgraph.
7
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.de
3
ist zum Beispiel eine sehr große deutschsprachige Seite, die mit
einer Datenbank aktueller Sichtungen aufwartet, wie in Abbildung 2 zu sehen ist:
3
Siehe: http://www.naturgucker.de/
Abbildung 2: Einblick in die Datenbank von naturgucker.de zur Vogelbeobachtung
8
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.
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.
Abbildung 3: Berichtserfassung bei
naturgucker.de
9
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 kurz-
er 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.
10
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: "Ush-
ahidi [...] 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 In-
formationen muss es dann möglich sein inhaltsgleiche Berichte zu bestimmen um darauf auf-
bauend mit Hilfe der Bestätigungsregeln des Regelwerks die Verlässlichkeit der einzelnen ge-
meldeten Gewalttaten bestimmen zu können.
11
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 Beobach-
tung 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 vorge-
stellten 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
12
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 seman-
tische Ä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 Nut-
zer 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
13
"Gleichzeitigkeit" von zwei Beobachtungen bzw. Reports so nur noch schwer realisierbar ist.
Nur sehr wenige Beobachtungen werden genau im gleichen Augenblick geschehen und eben-
so wenige Reports werden von Nutzer genau im gleichen Augenblick erfasst.
James F. Allen beschrieb bereits 1983 drei-
zehn Möglichkeiten, wie zwei temporale Inter-
valle zueinander in Beziehung stehen können.
(vgl. Allen, 1983). Wie leicht auf Abbildung 4
zu erkennen ist lassen sich diese dreizehn mög-
lichen Relationen auf sieben Relationen verein-
fachen, da viele nur die inverse Relation einer
anderen Relation darstellen. Da hiermit nach
James F. Allen alle möglichen temporalen Re-
lationen zweier Zeitintervalle abgedeckt sind,
erscheint es auch hier nur logisch die Vorarbeit
von Allen für den vorliegenden generischen Ansatz bei der Erstellung von Bestätigungsregeln
zu übernehmen. Allerdings ist eine kleine Erweiterung nötig.
Um ein weiteres Mal auf den Anwendungsfall "Storm Chasing" zurückzugreifen: Ein Tor-
nado ist eine Wettererscheinung, die zeitlich recht kurz anzutreffen ist. Es reicht also nicht aus
zu wissen, dass eine andere Sichtung eines Tornados davor war, da eine solche Sichtung auch
mehrere Wochen zurück liegen kann und man sich hierbei sicher sein kann, dass es sich hier-
bei niemals um den gleichen Tornado handelt. Daher ist eine Erweiterung der Relation "befo-
re" um eine maximale Abweichung nötig, so dass man z.B. die Möglichkeit hat die Relation
"maximal 30 Minuten davor" oder "maximal 30 Sekunden davor" nutzen zu können. Die Wer-
te werden in Sekunden angegeben.
3.2.4 Position der Beobachtung
Da die Entwicklung des hier vorgestellten generischen Ansatzes den Fokus auf nicht-me-
trische Positionen setzt also je nach Anwendungsfall festgelegte Regionen nutzt wird die
Position der Beobachtung nicht als absolute geographische Koordinate auf einem zuvor aus-
gewählten Referenzellipsoiden angesehen.
Abbildung 4: Dreizehn mögliche temporale
Relationen nach Allen (vgl. Allen, 1983, S. 835).
14