IOException.de

Im Vergleich zu klassischen SQL-Datenbank erfordern NoSQL-Datenbank vor allem bei der Datenabfrage ein Umdenken. Im Falle von CouchDB lässt sich zwar mit View Collation schon einiges erreichen, allerdings bei weitem nicht alles. Auf eine solche Grenze bin ich gestoßen, als ich Zeiträume speichern und abfragen wollte, also Einträge die ein Start- und Enddatum besitzen. Anfragen auf diese Daten könnten nun zu einem fixen Zeitpunkt alle darin ablaufenden Einträge erfragen, oder ausgeweitet auf einen Zeitraum auflisten, welche Einträge innerhalb eines Zeitfensters liegen. All dies ist mit CouchDB nicht wirklich lösbar.

Einen kleinen Workaround bietet die Idee, die Zeitleiste zu segmentieren und immer dann für einen Eintrag einen Key zu emitten, wenn der Zeitraum des Eintrages innerhalb dieses Bereichs liegt. Eine solche Map-Funktion könnte wie folgt aussehen. Hierbei wird für einen Eintrag jeweils ab dem Beginn für alle 5 Minuten ein Schlüssel in den Index emittiert.

Dokumentaufbau:

{
   "_id": "s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de",
   "begin": "2010-08-05T09:11:52.156Z",
   "end": "2010-08-05T09:23:13.457Z"
}

Map-Funktion:

//length of time segment (here 5 min)
var periodLength = (60*5);

function(doc)
{
        if(doc.begin && doc.end)
        {
                //start and end time as UNIX timestamps (seconds, not milliseconds)
                var begin =  Math.round(new Date(doc.begin).getTime()/1000);
                var end =  Math.round(new Date(doc.end).getTime()/1000);

                //calculate first matching segment of period
                var p = (begin - (begin%periodLength));

                //emit key for each matching period
                while(p<=end)
                {
                        emit([p, doc._id], null);
                        p = p + periodLength;
                }
        }
}

Der resultierende View sieht dann in etwa so aus:

Oder als Abfrage:
http://localhost:5984/entries/_design/entries/_view/docsByPeriodList?startkey=[1280998800]&endkey=[1281000193,{}]

{"total_rows":3,"update_seq":2,"offset":0,"rows":[
{"id":"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de","key":[1280999400,"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de"]15,"value":null},
{"id":"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de","key":[1280999700,"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de"],"value":null},
{"id":"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de","key":[1281000000,"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de"],"value":null}
]}

Eine viel bessere Lösung bietet jedoch die CouchDB-Erweiterung GeoCouch. Dank des R-Trees lassen sich Bereichtsabfragen effizient durchführen. Da GeoCouch eigentlich für zweidimensionale Geokoordinaten gedacht, muss sie und die GeoJSON-Syntax etwas missbraucht werden. Anstatt einer WGS84-Koordinate emittieren wir einfach einen UNIX-Zeitstempel und lassen den anderen Grad leer:

function(doc)
{
        if(doc.begin && doc.end)
        {
                //start and end time as UNIX timestamps (seconds, not milliseconds)
                var begin =  Math.round(new Date(doc.begin).getTime()/1000);
                var end =  Math.round(new Date(doc.end).getTime()/1000);

                emit(
                        {
                                type: "Point",
                                bbox : [0,start,0,end]
                        }, null
                );
        }
}

So lassen sich nun effiziente Bereichsabfragen durchführen:
http://localhost:5984/entries/_design/entries/_spatial/entriesByPeriod?bbox=0,1280998800,0,1281000600

{"update_seq":16,"rows":[
{"id":"s-ffc0b6b0-59d4-4a3b-ad36-7ec05e7db1de","bbox":[0,1280999512,0,1281000193],"value":null}
]}

Das Web ist mit HTTP fest an ein Client/Server-Modell gebunden und eine dadurch implizierte Asynchronität der Kommunikation. Requests können ausschließlich von Clients initiiert werden und immer von Servern in Form von Responses beantwortet. Ein solches Modell ist ausreichend für den Abruf von Informationen, setzt allerdings Schranken bezüglich anderer Interaktionsformen. Andere Protokolle wie XMPP, SIP oder auch Technologien wie nachrichtenbasierte Middlewaresysteme besitzen oft keine so deutliche Trennung zwischen Client/Server und erlauben weniger eingeschränkt die Kommunikation zwischen Knoten. Dadurch enstehen neben dem Request/Reply Muster weitere typischen Muster für den Austausch von Nachrichten. Ein Muster für die Benachrichtigung über Ereignisse ist das Publish/Subscribe Muster. Interessierte Knoten subskribieren sich für bestimmte Ereignisse und ereigniserzeugende Knoten publizieren diese.

Ein solches Kommunikationsmuster ist mit HTTP direkt nicht möglich, auch wenn es insbesondere für Feeds interessant wäre. Zwar bestehen mit Server Pushes / Long Polling oder dem aufkommenden WebSocket Standard vereinzelte Lösung für das prinzipielle Problem, dass HTTP keine serverinitiierte Kommunikation erlaubt, jedoch sind diese Insellösungen bisher kaum in der Breite verwendbar.

Google hat mit dem PubSubHubbub-Protokoll ein einfaches offenes Protokoll erschaffen, dass auf reinem HTTP basiert und ein solches Publish/Subscribe Muster unterstützt. Der Trick hierbei ist die Tatsache, dass alle beteiligten Knoten selbst sowohl Server wie auch Client sind und somit sowohl Requests empfangen wir auch versenden können.

Im Rahmen des diretto Projekts habe ich für unseren Client eine java-basierte Subscriber-Implementierung entwickelt. Als Feed kann jeder PubSubHubbub-fähige Atom-Feed benutzt werden. Im Falle einer Änderung des Feeds, zum Beispiel der Veröffentlichung eines neuen Eintrags, wird das “Delta” des Feeds, also der neue Teil an die Callback-Methode übergeben.

Subscriber subscriber = new SubscriberImpl("subscriber-host",8888);
Subscription subscription = subscriber.subscribe(URI.create("http://feed-host/my-push-enabled-feed.xml"));

subscription.setNotificationCallback(new NotificationCallback()
{

    @Override
    public void handle(SyndFeed feed)
    {
        //TODO: Do something more useful with the new entries
    	WireFeed inFeed = (WireFeed) feed.originalWireFeed();
    	if(inFeed instanceof Feed)
    	{
    		List<?> entries = ((Feed) inFeed).getEntries();
    		for (Object o : entries)
    		{
    			if(o instanceof Entry)
    			{
    				final Entry entry = (Entry) o;
    				System.out.println("New entry: "+entry.getId());
    			}
    		}
    	}
    }

} );

Der Client benutzt intern Rome für die Auswertung der Atom-Feeds und Jetty als leichtgewichtigen, internen Webserver. Der Subscriber muss übrigens für den Hub erreichbar sein, insofern sollte er an eine öffentliche IP und den angegebenen Port gebunden werden.

Projekt auf github: java-sub-pubsubhubbub

Node.js ist ein serverseitiges, hochskalierbares Framework für die Entwicklung von asynchronen Netzwerkanwendungen in JavaScript. Aufgrund der Asynchronität ist das Framework in der Lage, tausende Verbindung gleichzeitig offen zu halten und zu verarbeiten. Ein wesentliches Merkmal hier von ist, dass ausschließlich mit Callbacks gearbeitet wird, um auf Beendigungen von Operationen zu reagieren.

Im Normalfall führt das zu einem Chaining von Callback. Im folgenden Beispiel sollen zwei Dateien geöffnet werden und ihr kompletter Inhalt zurückgegeben werden:

var size = 0;

fs.readFile('/home/benjamin/file1', function(err, data)
{
	if (!err)
	{
		// first file read
		size += data.length;
		fs.readFile('/home/benjamin/file2', function(err, data)
		{
			if (!err)
			{
				// second file read
				size += data.length;
				fs.writeFile('/home/benjamin/size', size, function(err)
				{
					if (!err)
					{
							// both file read and content written to file
							sys.log('done');
						}
					});
			}
		});
	}
});

Das Problem hierbei ist, dass zwei Aktionen, die eigentlich parallel ablaufen könnten, nämlich das lesen beider Dateien, nacheinander ablaufen müssen. Für einen parallelen Ablauf ist eine zusätzliche Koordination notwendig, da die Resultate beider Aufrufe in Verbindung stehen. Hierfür habe ich mich an den CyclicBarrier Klassen von Java orientiert und eine einfache Klasse für die Koordination von asynchronen Callbacks geschrieben. Eine Barriere wird erzeugt unter Angabe der Anzahl von teilnehmenden Parties. Desweiteren können optional ein Callback für die Beendigung sowie ein optionaler Callback im Abbruchsfall registriert werden. Anschließend können die einzelnen Aufgaben der Parties angestoßen werden. Im Erfolgsfall müssen diese an der Barriere mit submit() anzeigen, dass sie beendet sind. Durch abort() kann auch ebenfalls ein Abbruch signalisiert werden. Eine Propagation der Ergebnisdaten lässt am besten durch eine externe Variable realisieren, auf den die Funktionen ebenfalls Zugriff haben.

Der Code des Beispielszenarios ändert sich dann wie folgt:

var size = 0;

var b = new Barrier(2, function()
{
	//Success callback
	fs.writeFile('/home/benjamin/size', size, function(err)
	{
		sys.log('done');
	});
}, function()
{
	//Aborted callback
	sys.log("aborted");
});

fs.readFile('/home/benjamin/file1', function(err, data)
{
	if (err)
	{
		b.abort();
	}
	else
	{
		size += data.length;
		b.submit();
	}
});

fs.readFile('/home/benjamin/file2', function(err, data)
{
	if (err)
	{
		b.abort();
	}
	else
	{
		size += data.length;
		b.submit();
	}
});

Wie im Vergleich zu erkennen ist, lässt sich die Ausführung deutlich beschleunigen. Ein paar Rahmenbedingungen gibt es jedoch. Zunächst dürfen die Teilaufgaben keine Abhängigkeiten untereinander besitzen. Dann darf ein Abbruch einer Teilaufgabe keine Auswirkung auf noch laufende Teilaufgaben besitzen, dessen Ergebnis später verworfen wird. Schließlich muss bei der Programmierung darauf geachtet werden, dass in jedem Fall eine Teilaufgabe mit submit() oder abort() terminiert, da ansonsten ein Lock entsteht.

Die Klasse ist relativ einfach:

/**
 * @class
 *
 * Creates a new barrier for the given amount of parties.
 * @param parties
 * @param barrierCallback
 * @param abortCallback
 * @return
 */
var Barrier =  function(parties, barrierCallback, abortCallback)
{
	this.parties = parties;
	this.barrierCallback = barrierCallback;
	this.abortCallback = abortCallback;

	this.running = true;
	this.count = 0;
};

/**
 * Signals a completion of one of the parties.
 * @return
 */
Barrier.prototype.submit = function()
{
	if (++this.count === this.parties && this.running)
	{
		this.barrierCallback();
	}
};

/**
 * Signals an abort by one of the parties. If not callback is passed, the default abort callback will be executed.
 * @param customAbortCallback Optional callback that should be executed due to the abort.
 * @return
 */
Barrier.prototype.abort = function(customAbortCallback)
{
	if (this.running && customAbortCallback)
	{
		customAbortCallback();
	}
	else if (this.running && this.abortCallback)
	{
		this.abortCallback();
	}
	this.running = false;
};

Klasse auf github: http://gist.github.com/464179

Wer Matlab mag wird Sage lieben, insbesondere wenn die Ausgangsdaten sowieso in Python vorliegen. Ein einfaches Histogram für Ganzzahlen lässt sich wie folgt realisieren:

from sage.all import *
import numpy
import matplotlib.pyplot as plt
import matplotlib.mlab as mlab

def plot_hist(subplot,name,x_data,x_var,y_var,b_width):

  #create array
  n_array = numpy.array(x_data)

  #labels
  subplot.set_xlabel('variable '+x_var+' [min = '+str(n_array.min())+', max='+str(n_array.max())+' ]')
  subplot.set_ylabel(y_var)

  #create bins
  mmin = n_array.min()
  mmax = n_array.max()
  b = numpy.arange(mmin-(1.0/2),mmax+1+(1.0/2))

  #set ticks
  subplot.set_xticks(b)

  #hist
  n, bins, patches = subplot.hist(x_data,bins=b, rwidth=b_width)

  #title
  subplot.set_title(r'Histogram of '+x_var)

Benutzt wird das Ganze dann mittels:

f = matplotlib.pyplot.figure()
a = f.add_subplot(111)

plot_utils.plot_hist(a,'Decimals', [1,1,1,2,2,3,3,3,4,4,5,5,6,6,7,7],'decimal','# of decimals',0.8)

matplotlib.pyplot.savefig('plot.png')

Für die Interaktion mit Feeds gibt es in Java die weit verbreitete ROME-Library. Diese Library unterstützt sowohl RSS als auch ATOM in den verschiedenen Versionen. Außerdem bietet es eine Abstraktion an, die den Umgang mit den verschiedenen Feedarten vereinfachen soll. Ihre sogenannten Syndication Feeds bieten eine einheitliche Schnittstelle an, und sind unabhängig vom darunter liegenden Format. Dies mag allgemein sehr hilfreich sein und für viele Fälle auch ausreichen. Typische Operationen sind somit entkoppelt vom Format und können wiederverwendet werden, oder das konkrete Format kann problemlos ausgetauscht werden.

Der Nachteil hierbei ist, dass bei dieser Abstraktion Besonderheiten der einzelnen Formate verborgen werden. Problematisch wird es zum Beispiel, wenn man explizit ein bestimmtes Format lesen möchte, um auf bestimmte Elemente zuzugreifen. So muss in Atom jeder Feed und Einträg ein ID Element besitzen, in RSS existiert dies jedoch nicht. Leider existiert nun auch keine Methode, ein solches Feld in einem Syndication Feed direkt abzufragen.

Nach einigem Suchen bin ich nun auf die Lösung gestoßen. Beim Einlesen des Feeds muss explizit ein Flag aktiviert werden, dass das zugrunde liegende Format ebenfalls mitgespeichert werden soll. Erst wenn dieses Flag gesetzt ist, lässt sich später der Feed im Originalformat (WireFeed) abrufen:

InputSource source = new InputSource(...);
SyndFeedInput feedInput = new SyndFeedInput();
feedInput.setPreserveWireFeed(true);
SyndFeed feed = feedInput.build(source);

Später bietet dann der Syndication Feed Zugriff auf den konkreten Feed:

WireFeed wireFeed = (WireFeed) feed.originalWireFeed();
if(wireFeed instanceof com.sun.syndication.feed.atom.Feed)
{
   String feedId = ((Feed) wireFeed).getId()
}

Auf dem gestrigen Webmontag in Ulm habe ich Node.js vorgestellt, ein Framework für serverseitiges JavaScript für skalierbare Netzwerkanwendungen. Dabei hat es sich um eine eher kurze und oberflächliche Präesentation gehandelt, die die Grundidee des asynchroner I/O Operationen betonen sollte. Detailliertere Beiträge zu Node.js wird es aber hier in Kürze geben.

Die Küche ist wohl weiterhin einer der traditionsreichsten Plätze in der modernen Gesellschaft. Auch wenn es Feministinnen nicht gefallen wird, so steht „Oma“ für ein Qualitätsmerkmal im Bereich der zünftigen Küche. Handschriftliche Rezeptsammlungen sind auch heute noch in modernen Küchen zu finden. Dabei handelt es sich nicht selten um über Generationen gesammelte Werke. Als Kind lernt man meist schon durch Selbstversuch, dass der Topf über eine Herdplatte erwärmt wird und lernt so recht schnell wie unsere Gesellschaft zu warmen Speisen gelangt.

Mit unserem Projekt wollen wir das Kochen nicht neu erfinden. Vielmehr handelt es sich bei der Multifunctional and Adaptive Meal Preparation Facility (MAMPF) um ein Konzept, welches zeigen soll, dass ubiquitäre Unterstützung auch im Bereich der Küche sinnvoll einzubringen ist. Dafür möchten wir einige der festgefahrenen Methoden aufbrechen und uns überlegen, wie diese sinnvoll zu verändern bzw. zu erweitern sind. Oft beschränkt sich ein Haushalt auf eine gut abzählbare Menge von immer wiederkehrenden Gerichten. Dies hat zum Einen den Grund, dass diese Gerichte Lieblingsspeisen sind, zum Anderen liegt dies an Zeit- und Motivationsmängel, sich die Zubereitung eines neuen Gerichtes anzueignen.
Durch ein System, welches Rezepte bereitstellt und Unterstützung für den Kochvorgang anbietet, kann möglicherweise diese Hürde etwas herabgesetzt werden. Durch maschinenlesbare Rezepte lassen sich auch sehr einfach Inhaltsstoffe überprüfen, beispielsweise zur Vermeidung von Unverträglichkeiten beziehungsweise Allergien oder für eine gesündere Ernährung.

Ein solches Format bringt neben der Möglichkeit zur Kochunterstützung eine Fülle weiterer Eigenschaften. So können Rezepte sehr gut kategorisiert, durchsucht, getauscht, bewertet oder modifiziert werden. Damit wäre es auch möglich Rezepte über eine Online-Plattform für andere zugänglich zu machen. Die klassische Bedienung soll so verändert werden, dass eine einfachere Handhabung möglich ist. Ein Kochvorgang zum Aufkochen von Wasser beginnt meistens, indem man einen Topf mit Wasser füllt, sich eine geeignete Platte auf dem Herd aussucht und anschließend das Bedienelement für diese Platte auf die höchste Stufe stellt.
Bei unserem Konzept soll vor Allem diese letzte Indirektionsstufe wegfallen, indem das System sowohl weiß, wo sich das Kochgeschirr befindet, als auch, wie dieses anzusteuern ist. Dies nennt sich dann ‘zoneless cooking’.

Es handelt sich in diesem Punkt um eine Machbarkeitsstudie, da wir aus Kostengründen keine große Fläche aus vielen kleinen Induktionsspulen zur Verfügung haben. Derartige Produkte werden auch von den großen Firmen erforscht, die leider nicht an einer Beteiligung an diesem Projekt interessiert waren. Daher wird mit drei einfachen Induktionskochplatten das Prinzip der Topferkennung und des gezielten Ansteuerns umgesetzt, welches auf eine großflächige Induktionsmatrix übertragbar ist.

Die MAMPF stellt dann schließlich ein vielseitiges Küchensystem dar, das den Benutzer bei Bedarf in weiten Teilen unterstützt. Dies bedeutet, dass der Benutzer des Systems in keinster Weise in seinen Möglichkeiten eingeschränkt werden soll und auch künftig in gewohnter Weise kochen kann. Die gebotene Unterstützung umfasst mehrere Bereiche wie erhöhte Sicherheit, einen neuen Ansatz der Interaktion sowie Begleitung durch Rezepte.

Die Darstellung des Systemzustandes, sowie aller Anweisungen für ein Rezept, werden auf einem Monitor über der Kochplatte angezeigt. Bedient wird das System über einen in die Kochplatte eingelassenen, berührungsempfindlichen TabletPC. Die Bedienfläche ist somit von der Ausgabe getrennt, kann aber auch die Ausgabe für eine direkte Interaktion darstellen. Hiermit ist es möglich auch von entfernten Geräten auf die Kocheinheit zuzugreifen und Änderungen am System durchzuführen.

Mithilfe einer Datenbank sollen Benutzerinformationen gesammelt werden. Diese Informationen erlauben später eine genauere Berechnung der benötigten Kochdauer oder das sortieren von bestimmten Rezepten.

Um dieses Projekt zu realisieren, wird wie bereits erwähnt auf die Technik der Induktion gesetzt. Die Kochplatten werden durch Hardwarenahe-Programmierung über Mikrocontroller angesprochen. Des Weiteren verwenden wir Algorithmen aus der Computer Vision zur Objekterkennung und -tracking, ein selbst spezifiziertes Rezeptformat und ein hohes Maß an Modularität durch die Common Application Library (CAL) des .NET-Frameworks in Verbindung mit dem Model-View-ViewModel-Pattern. Durch dieses Lose-gekoppelte Framework ist es möglich mit fünf Personen unabhängig von den Arbeitsfortschritten der anderen zu entwickeln.

Die Motivation MAMPF umzusetzen besteht darin das Kochen zu vereinfachen. Ungeübte Köche und komplizierte Rezepte sollen nicht mehr im Widerspruch zueinander stehen.

Nach langer Zeit melde ich mich zu diesem Thema auch mal wieder. Seit dem letzten Mal hat sich leider nicht viel an meinem Beamer verändert, da ich nach wie vor vor dem großen Problem, DVI zu LVDS oder VGA zu LVDS wandlen, stehe. Allerdings ist dies auch das einzige Problem, das ich hab. Würde das gelöst werden, könnte ich alles nehmen und in einer kleinen Kiste zusammenführen, um einen anständigen Beamer zu haben.

Trotz mehr oder weniger profesorischem Gehäuse, haben wir den Beamer in den letzten Monaten auf sein Durchhaltevermögen getestet. Hauptsächlich normale Videoabende. Jedoch haben wir uns es nicht nehmen lassen, das Champions League Finale darauf anzuschauen. Aber nicht nur das, sondern davor noch Halbfinale Eishockey-WM und danach noch bis halb 3Uhr Nachts weiter getestet.  Somit haben wir an diesem Abend eine Laufzeit von ca. 7h erzielt. Es traten keinerlei Probleme auf, eine dezente Hitzeentwicklung war zwar vorhanden aber nicht weiter wild, und wir haben auf eine Diagonale von ca 3m Fußball und Co geschaut.

Bisheriges Fazit: Auch wenn ich noch nicht das Optimum aus dem Ding geholt habe, bin ich damit sehr zufrieden und er hat bisher alles mitgemacht. Außerdem hab ich nun einen HD-Ready Beamer für wenig Geld und hab ihn selbst gebastelt. Dies ist viel toller als irgendwas zu kaufen.

Im Laufe eines Studiums muss man ja diverse Praktika machen. Eines davon steht dieses Semester nun auch bei mir an. Nachdem ich lange überlegt hab, ob für einen Nebenfach Medizin Informatiker nun OS im Eigenbau, Autonomous Underwater Vehicle oder Humanoid-Roboter am besten sei, entschied ich mich für letzteres.

Hierbei geht es um einen kleinen Graupner Humanoiden der Serie RB-1000. Diesem Humanoiden, getauft auf T-1000 aka Arnie, müssen wir in einem Teamprojekt das Gehen beibringen.

Arnie hat 21 Servos, 2 LED-Augen(rot) und einen Microkontroller, der an der Uni eigenständig entwickelt wurde, versehen mit einer Bluetooth-Schnittstelle und einem Gyroskop. In zwei Praktika zuvor wurden zwei Interfaces entwickelt, das eine in MatLab und das andere in C/C++. Derzeit können wir uns noch nicht ganz entscheiden, welches von beiden wir verwenden werden. Allerdings ist mir das C/C++ gerade noch lieber, da es weniger Probleme bereitet und von uns in – welch Einfalssreichtum – Skynet umbenannt wurde. Das schöne dabei ist, dass man beispielsweise ein Bashscript schreiben kann für die Ansteuerung und dann das ganze einfach an Skynet pipen kann.

Bisher bestand unsere Tätigkeit darin, Arnie erst einmal komplett zu entrümpeln. Wir haben unnötige Meter an Servokabel entfernt, die Stromversorgung neu angeschlossen, neue Schalter angebracht, die Batterie im Brustkorb durch ein passendes Netzteil ersetzt, was uns die Handhabung um mindestens 120% verbessert, die Interfaces gestestet und vorbereitet. Demnächst werden wir auch noch eine kleine Justierungsstation basteln, damit man ihn vor Inbetriebnahme immer optimal einstellen kann.

Natürlich haben wir auch schon ordentlich an ihm getestet was er kann und wie es geht. Hier sieht man ihn, wie er winkt.

This is only the beginning….

Heutige Mobilgeräte wie Smartphones, Netbooks oder PDAs stellen zu einem großen Teil drahtlosen Zugriff auf das Internet bereit. Zugleich bieten diese Geräte häufig auch die Möglichkeit, multimediale Inhalte wie Bilder, Videos oder Tonmitschnitte überall zu produzieren. Alternativ können sie zumindest als Brücke ins Internet fungieren und dedizierte Geräte wie Digitalkameras anbinden.

Trotz dieser theoretischen Möglichkeiten existieren bisher kaum Anwendungen, die mithilfe dieser Technologien eine multimediale Berichterstattung in quasi Echtzeit ermöglichen. Das Ziel des diretto-Projektes ist es, eine solche Plattform zu entwickeln und Beispiellösungen für die Integration mobiler Geräte aufzuzeigen. Zusätzlich zu Sammlung der mutlimedialen Inhalte liegt ein weiter Fokus auf der Analyse, Bewertung und Verbesserung der erhaltenen Daten – sowohl durch das System als auch durch die Benutzer selbst. So kann zum Beispiel die Genauigkeit von Metadaten wie Orts- und Zeitangaben verbessert werden, Beiträge können mithilfe von Tags klassifiziert und verschiedene mutlimediale Inhalte untereinander sinnvoll verlinkt werden. Durch das System erzeugte Gruppierungen unterstützen den Benutzer zusätzlich bei der Auswertung der Inhalte.

Als Grundlage für das komplette Projekte werden zeitgemäße Web-Technologien eingesetzt. Somit ist die Plattform offen, sehr leicht erweiterbar und skaliert auch bei der Nutzung in größeren Szenarien. Die API steht in Form eines REST-konformen Webservices zur Verfügung. Metadaten werden im leichtgewichtigen JSON-Format kodiert. Ein spezieller PubSubHubbub-Endpunkt ermöglicht Benachrichtigungen über neue Inhalte in Echtzeit. Dezentrale Zusatzdientse steuern zusätzliche Funktionalitäten bei.

Eine mächtige Weboberfläche bietet Zugriff auf die Gesamtheit der erhobenen Daten – auch entfernt über das Internet. Sie bietet die Grundlage für komplexe Auswertungen der vorhandenen Multimediadaten und zugehörigen Metadaten. Im Vordergrund steht hierbei auch die Unterstützung des Benutzers beim Umgang mit den vieldimensionalen Daten.

Für die Integration mobiler Systeme werden verschiedene Clients entwickelt und erprobt. Ein Smartphone-Client erlaubt es dem Besitzer eines Smartphones direkt zum Reporter vor Ort zu werden und Inhalte beizusteuern. Für die Anbindung dedizierter Hardware wie einer digitalen Spiegelreflexkamera wird eine besondere Lösung erabreitet. Ein mobiler Rechner im Rucksack soll als Uplink-Gerät dienen und frisch geschossene Bilder ohne Verzögerung direkt auf die Plattform hochladen. Mithilfe einer solchen Lösung können Fotojournalisten als echte Live-Berichterstatter agieren und Pausen für den Upload entfallen.

Eine solche Plattform eignet sich je nach Ausrichtung für eine Vielzahl verschiedener Einsatzszenarien. So könnte es zur Live-Dokumentation großer Ereignisse dienen. In einem geschlossenen Kontext könnte es Einsatzkräfte bei Großschadenslagen dabei helfen, in kürzerer Zeit einen detaillierteren Überblick zu bekommen und unterstützende Kräfte zur Auswertung fernab einbinden.

Das Projekt wurde im Rahmen des Anwendungsfaches Ubiquitous Computing an der Universität Ulm von einem studentischen Team entworfen und nun in Zusammenarbeit mit einem Team für Interaktive Systeme als Prototyp realisiert. Nähere Informationen gibt es auf der Projektseite www.diretto.org