Tagung: Mit Pixel und Netz zu bewegtem Wissen
Informationsgesellschaft im Aufbruch
Wissenschaftlich-kulturelles Tagungszentrum

Format-transparente Kommunikation

Julean Simon fuer Fa. Wohlhart/Graz (jsimon(at)uea-io.de)

Worum geht es: wir kommunizieren auf unterschiedlichen Geraeten und Kanaelen (also fest, mobil, voip, sms, mail, webmail, chat, etc.). Auch wenn einzelne Applikationen die Kommunikationen moeglicherweise geloggt haben, haben wir oft den Ueberblick bald verloren.

Dazu kommt dass Kommunikationen sich aufeinander beziehen. Um den Kontext von Kommunikationen abzubilden benoetigen wir also eine moeglichst vollstaendige Integration aller Kommunikationsdaten, sowie die referenzielle Struktur der Kommunikationen.

Was behindert eine solche Integration? Formate. Und zwar nicht nur Datenformate; auch Applikationsformate und die durch sie forcierten Interaktionsformate. Also benoetigen wir eine format-transparente Integration.

Was ist ein Format: von lat. formatum: Geformtes. Also schematisierte Form. Wir denken an Papierformate. Medienlingo bezeichnet damit das (wiederverwendbare, verkaufbare, patentierbare) Konzept einer Sendung. In der Datenverarbeitung verstehen wir darunter die Struktur von Eingabe/Ausgabe-Daten, aber auch Nutzungsformate.

In der automatisierten Verarbeitung helfen uns Formate Prozesse zu optimieren, zu koppeln und mittels Routinen wiederverwendbar zu machen. Formate zeugen allerdings von der Prioritaet der Verarbeitungsaspekte gegenueber dem was verarbeitet wird. Jedoch soll nicht bestritten werden, dass Formate (etwa als Transportprotokolle) unverzichtbar und selbstverstaendlich sind.

Formate haben einen optimierenden Effekt, wenn ihre Restriktionen weitgehend angewandt werden. Zuviele Ausnahmen machen Formate ineffizient. Andererseits wirken Formate restriktiv auf den so formatierten Content.  Als Reaktion sehen wir riesige Monolite (z.b. Office Suite)  die man als Format-Ausnahme-Management bezeichnen koennte.

Neuerdings beobachten wir einen Paradigmenwechsel: von den monolitische Formaten zum Kredo Mikro-Formate. Etwa im Zusammenhang von Web 3.0 - Prognosen. Dies betrifft auch inhaltliche Formate: also z.B. die Aufloesung des Autors in Welblogs, die zunehmend den Charakter von Portalen erhalten.

Mikroapplikatioen erscheinen mittlerweile auf unseren Mobilen Devices (etwa iPhone). Also sehen wir uns ein solches Programmformat genauer an:

Die Phone.app des iPhone:

Phone ist nicht mehr, wie bei frueheren Handys die zentrale Applikation, um die sich weitere Funktionen und Einstellungen gruppieren. Es ist eine von vielen moeglichen Anwendungen, die auf einem Betriebsystemslayer laufen. Die Oberflaeche zeigt mir dieses Konzept als eine Ansammlung antippbarer Piktogrammen an.

Starte ich die Phone.app gelange ich ins Adressbuch, eine Listendarstellung mit Optionen fuer deren Filterung. Tippe ich auf einen Listeneintrag gelange ich zum entsprechenden Kontakt und kann einzelne Felder editieren, die Person anrufen oder an sie eine SMS oder mail schreiben. Die Phone.app ist also mit dem Adressbuch verkoppelt und dieses wiederum mit der Mail.app und der SMS.app.

Wir haben es mit einer dezidierten Nutzerfuehrung zu tun, die einige Verzweigungsoptionen anbietet, aber doch einen bestimmten Usecase standardisiert. Fuer diesen wird der Zugang optimiert. Dieser waere also das Applikations-Format. Diese Optimierung nimmt in Kauf dass andere Funktionen fehlen. Z.b. das Suchen nach einer Nummer (derzeit nur als 3rd Party app).

Das dazugehoerige Datenformat wird durch weitergehende Restriktionen proprietaer gehalten, auch durch die Art der Datensynchronisation. Es fehlen Funktionen wie vollstaendige Logs, oder das Aufzeichnen von Gespraechen. Insbesondere Funktionen wie Copy/Paste (zum manuellen Datentransfer innerhalb und vor allem zwischen Applikationen).

Auf einem gehackten iPhone (jailbreak) koennen 3rd Party Applikationen installiert werden, die fehlende oder neue Funktionen bieten: da gibt es zb. Adressbuch-Suche, Archivierung von SMS, Gespraechsaufzeichnung. etc. vor allem auch Zugriff auf das Filesystem, der von Apple offenbar nicht gewuenscht wird.

Bringen uns Mikro-Formate weiter? Die Kopplung von Mikro-Applikationen scheint zwar elegant, hat aber Tuecken. Z.b. in der Adressuche kann eine gefundene Adresse nicht editiert werden und es wird nicht angezeigt in welcher Gruppe sie sich befindet. Voraussetzung fuer Mikroformate waere jedenfalls ein durchdachter Integrationslayer.

Was heisst das fuer jemanden der u.a. sein iPhone etwa fuer Projektarbeit verwendet, also inhaltlich aufeinander bezogenen Kommunikationen in unterschiedlichen Medien mit unterschiedlichen Personen fuehrt. Er oder sie hat es mit mehreren (wenn ueberhaupt vorhandenen) Archiven zu tun die er hoechstens manuell integrieren kann um Arbeits- und Entscheidungsprozesse zu dokumentieren und weiterzuverarbeiten.

Was waere notwendig:
1. content-orientierte Prozesse statt applikations-orientierte (derzeit sind die Daten eines Kontexts in Datenfiles mehrerer Applikationen verteilt)
2. Wahl des Mediums sollte nachgeordnet und funktions-transparent sein
3. globale Logs (Daten unterschiedlicher apps integrieren)
4. editierbar (Labels, Annotationen, Referenzen)
5. synchronisierbar und filterbar hinsichtliche unterschiedlicher Projekte, Mitarbeiter, Devices, Plattformen, etc

Koennen wir das von Web3.0 erwarten? Es wird mit intelligenten Verfahren assoziiert, intelligent agents, "Internet of Services", Service-orientierte Architekturen, semantic web, micro-formats, omni-functional/single-interface platform. Das klingt alles einwenig nach der richtigen Richtung. 
Und doch sind Zweifel berechtigt. Heutige Mikro-Applikationen kooperieren schon deshalb miteinander nicht hinreichend, weil sie eventuell getrennt abrechnen moechten.

Wie sich die Erweiterung des gegenwaertigen Internetprotokolls IPv4 in ein IPv6 (das die Adressierbarkeit jedes einzelnen Datenobjekts ermoeglicht) auswirkt ist schwer vorherzusehen. Wuerde es sich um generische Datenobjekte handeln waere dies eine brauchbare Basis. Allerdings ist es ebenso denkbar dass sich die Formatkriege auf die Ebene dieser Objekte verlagern und vom Nutzer nur noch schwer kompensiert werden koennen.

Hauptforderung: Daten sollten generisch - also allgemein verfuegbar vorliegen und duerfen nicht einzelnen Applikationen "gehoeren" (etwa durch proprietaere Formatierung). Wenn eine app Daten in spezifischer Form benoetigt dann sollte sie diese on-the-fly konvertieren oder zusaetzlich in konvertierter Form vorhalten.

Eigentlich beduerfte es eines anderen Betriebssystems-Ansatzes. Naemlich eines Content- oder zumindest Daten-orientierten und vor allem Prozess-orientierten. Weniger eines Applikations- und File-orientierten. Auch der Ansatz von Android (Googles offenes Betriebssystem fuer mobile Devices) perpetuiert den herkoemmlichen Ansatz: fuer den Fall dass andere Applikationen auf die Daten zugreifen will, sieht es sognannte "Content Provider" vor.

Oder Tim Berner-Lee's Giant Global Graph: ohne es als Formatproblem zu bezeichnen beklagt er die mangelnde Wiederverwendbarkeit von Userdaten in Social Networks (z.b. Facebook). Statt zu fordern dass diese Daten generisch vorliegen schlaegt er wiederum die Verwendung neuer Formate vor (Graph, FOAF).

Ein fuer alle mal: wenn ich eine SMS schreibe so gehoert dieser Text nicht der SMS-app sondern mir! heisst, ich moechte in der Lage sein, ihn ohne irgendwelche Konvertierungen weiterzuverarbeiten! Damit meine kontextuellen Formatierungen erhalten bleiben gibt es z.b. XML (ok, auch ein Format, aber ein relativ generisches).

protocoller: ein kleines Beispielsprogramm

Diese Programmidee der Fa. Wohlhart/Graz versteht sich als Zwischenloesung und soll die Moeglichkeiten des skizzierten Ansatzes testen.

protoColler ist eine Applikation mit welcher unterschiedliche Kommunikations-Medien und –Formen integriert und etwa zeitbasiert dargestellt, editiert, organisert und vor allem verknuepft werden koennen.

Das betrifft die Integration und Interkommunikation von diversen Services (fest/mobil-Telefon, voIP, SMS/MMS, mobiles/email, insbesondere zeitrelevante Daten aus Computerprogrammen, Peripheriegeraeten oder mobilen Devices wie Organizer, PDA, GPS-Devices, Fahrtenscheiber, Kamera/Microphone, Sensoren, usw.)

Diese Medien sind teilweise oder voellig isoliert. Kommunikationen werden durch den Nutzer (manuell oder gedanklich) integriert. Es gibt natuerlich Import-Moeglichkeiten, aber dennoch fehlt eine Applikation die sie universell integriert.

Erforderlich ist dafuer ein Layer modulbasierte Schnittstellen, um Daten aus verschiedensten Quellen (vorzugsweise in echtzeit) zu empfangen, zu interpretieren, zu kategoriesieren und in einer nutzerdefinierten Weise zu speichern, darzustellen und zu verknuepfen.

Ferner koennen vorhandene Rueckkanaele verwendet werden, um aus protoColler heraus Funktionen in den Devices aufzurufen. Die Standard-Darstellung waere etwa eine Time-Line von Inhalts-Einheiten, wie wir sie etwa von Chat-Clients kennen: Uhrzeit/Quelle/Message. Fuer bestimmte Daten und Daten-Kommunikationen ist es sinnvoll weitere relationale Kategorien zu nutzen, die beim Setup des protoCollers vom Nutzer definiert werden koennen.

Als Anwendungsszenarien waeren z.B. interaktive Laborpotokolle, Sitzungsprotokolle, Koordinationsapplikationen fuer Lieferservices denkbar.
Ein Setup des protoCollers als ein Laborprotokoll wuerde die verschiedenen echtzeit-Daten aus Laborgeraeten, dem Versuchsaufbau, relevante Kommunikationen mit Mitarbeitern, schriftliche Analysen, Audio-Notes, Vergleichsdaten aus anderen Studien, sowie Daten aus beliebigen Quellen, etc. automatisch in eine Time-Line integrieren. protoColler wuerde userdefinierbare Darstellungs- und Verarbeitungsmoeglichkeiten bieten.

Gegenueber konventionellen Laborprotokollen haette dies den Vorteil, dass ein wesentlich breiterer Kontext erfasst wird. Einzelne Aspekte des Kontexts koennen einfacher in Beziehung zueinander gesetzt werden. Das Protokoll koennte nicht nur durch den Laboranten, sondern auch durch automatische Prozesse analysiert werden. Fehler waeren leichter zu tracken. Teilprozesse leichter zu definieren. Es waere denkbar anhand eines realen Protokolls die Veraenderung einzelner Parameter zu simulieren.  

Soweit Features betreffend die protokollierte Vergangenheit. Bezueglich Protokoll-Gegenwart: es koennen aus der protoColler-Umgebung heraus Kommunikationen mit Menschen oder Maschinen gestartet werden, die sich unmittelbar als Protokoll abbilden. Bezueglich der zu protokollierenden Zukunft: die Umgebung kann dazu verwendet werden Prozesse zu beliebiger Zeit automatisch zu starten und kontrolliert ablaufen zu lassen.

Fazit:
Derartige Szenarien vor Augen ist es erstaunlich dass es bislang keinerlei Plattformen gibt die dies auf einer allgemeinen Basis realisieren. Ich mache dafuer die Formate in ihren unterschiedlichen Erscheinungsformen verantwortlich. Da gegenwaertige Verarbeitungsparadigmen nicht ohne Formate auskommen, muesste man diese transparent machen. Die wesentliche Voraussetzung dafuer besteht darin Userdaten in generischer Form vorzuhalten.

Ref:
Tim Berner-Lee: Giant Global Graph
(http://dig.csail.mit.edu/breadcrumbs/node/215)

ABENDS: windcontroler performance

der windmidicontroler ist ein elektronisches eingabedevice das ein akustisches blasinstrument simuliert oder referenziert. genauer gesagt das interaktionsrepertoire eines akustischen blasinstruments.

im wesentlichen ist es ein sensor-interface, das tastendruck, blas- und lippendruck in midisignale wandelt. ich verwende hardware und software-synthese um mittels der midisignale klaenge zu erzeugen.

in der programmierung geht es zunaechst nicht um klaenge - wie ueblicherweise in der elektonischen musik. vielmehr um virtuelle instrumente, die spezifische spieleigenschaften haben.