Jedermann ein Wissensproduzent

(und natürlich auch jede Frau)

Verteilte soziale Netzwerke als Basis für ein freies Web des Wissens

Keynote zum edenspiekermann_ nach mittag in stuttgart, 27. Mai 2011, Jörg Kantel

(Photo: Norbert Spitzer)

Jörg Kantel, Jahrgang 1953, studierte Mathematik, Informatik und Philosophie. Nach einigen Jahren in der Industrie ist er seit 1994 EDV-Leiter am Max-Planck-Institut für Wissenschaftsgeschichte (MPIWG) in Berlin und dort unter anderem mit der Frage beschäftigt, wie man Forschungsergebnisse und -Quellen im Web sinnvoll präsentiert.

Von 2006 bis 2009 war er außerdem Lehrbeauftragter für Multimedia im Fachbereich »Angewandte Informatik« an der Fachhochschule für Technik und Wirtschaft (FHTW), jetzt Hochschule für Technik und Wirtschaft (HTW) in Berlin.

Seit dem 24. April 2000 gibt er außerdem das Weblog Der Schockwellenreiter heraus und ist damit vermutlich der »dienstälteste« noch aktive deutschsprachige Blogger.

Autor diverser Bücher und Aufsätze zum Web 2.0.

The Web is a Writing Environment – Dave Winer

Das sah übrigens Tim Berners-Lee auch schon so.

Seit Bestehen des Netzes tobt ein heftiger Kampf zwischen denen, die das Netz als einen Kommunikationskanal betrachten und denen, die darin nur einen weiteren Kanal zur Distribution herkömmlicher Medieninhalte sehen.

»Das Internet ist von einem Distributions- in einen Kommunikationsapparat zu verwandeln.« (Frei nach Bertolt Brecht: Radiotheorie)

»Jeder heutige Mensch kann einen Anspruch vorbringen, gefilmt zu werden.« (Walter Benjamin: Das Kunstwerk im Zeitalter seiner technischen Reproduzierbarkeit)

Soziale Netze wie Facebook, Xing, StudiVZ oder Twitter verkommen mehr und mehr zu Datensilos, in denen der Nutzer seine Daten hineinsteckt, aber nicht mehr herausbekommt.

• Einschränkungen der APIs (Mashups)
• Einschränkungen im RSS-Feed (Alternative Reader)

Das Problem ist, daß APIs und alternative Reader die Nutzer von der eigentlichen Webseite weglocken (Werbung).

Zudem ist der Nutzer nicht mehr Herr seiner Daten (AGBs räumen dem Betreiber ein Nutzungsrecht ein)

»Like Google, Twitter and the other leading commercial Internet sites have made tremendous contributions to the functionality of the Internet and have earned both their popularity and (where it exists) their revenue. But the end-to-end principle and the reliability of distributed processing must have their day again, whenever some use of the Internet becomes too important to leave up to any single entity.« (Andy Oram: Why social networks need to be decentralized)

• Wie kommunzieren die einzelnen Peers miteinander?
• Wie werden sie über Änderungen informiert?
• Wie können sich Gruppen bilden und wie werden die Rechte verteilt?

Etwa 2000 gründete Dave Winer mit EditThisPage einen kostenlosen Weblog-Service. Doch nach kurzer Zeit war dieser völlig überlastet und brach ständig zusammen. (Ich nannte das damals das Manila-Syndrom.)

Daher machte er etwa 2002 einen seiner berüchtigen cornerturns und mit Radio UserLand etwas ganz anderes.

• Webserver auf dem Desktop als Redaktionsserver
• Statische Seiten auf dem Produktionsserver
• Community-Server: Kommunikation via Ping und XML/RPC
• Inhalte werden auch via RSS zur Verfügung gestellt

Das sind die Tools, die benötigt werden:

• Webserver auf dem Desktop / Arbeitsgruppenserver (Django, Rails, DokuWiki, Google App Engine)
• Ping, Trackbackping und/oder Pingback
• XML-RPC, SOAP (?), XMPP (auch dazu später noch mehr) und REST
• RSS und Atom

Ausgehend von diesen Tools habe ich schon 2003 in einer Keynote auf der BlogTalk in Wien folgendes Szenario vorgeschlagen:

• Jede Peer stellt seine Sammlungen und Ergebnisse (wie auch immer) online
• Ein oder mehrere Community-Server werden per Ping informiert
• Diese Server rufen die Inhalte per RSS/Atom ab und erstellen automatisch daraus Inhaltsverzeichnisse …

• Auf den Community-Servern läuft die Suche und sie zeigt die Suchergebnisse als Links auf die (verteilten) Originalseiten
• Redundanz ist kein Problem, sondern dient im Gegenteil eher als ein primitives Load-Balancing

• Der Community-Server als one point of failure störte mich …
• Daher kommen wir später noch einmal darauf zurück

• Da alle Beteiligten mit den Tools ihres Vertrauens arbeiten, müssen diese Werkzeuge untereinander über offene Protokolle kommunizieren
• Und natürlich macht das Ganze nur Sinn, wenn die Inhalte frei zur Verfügung stehen

• Google Wave (Open Source) war ein neuartiges Kommunikations- und Kollaborationswerkzeug des Suchmaschinengiganten, das die Arbeit im Netz völlig umkrempeln sollte.
• Es war eine zentrale Kommunikationsplattform, die Email, Instant-Messaging, Chat, Photos, Videos, Karten und Dokumente verbindet.
• Wave erlaubte unter anderem die gemeinsame Arbeit an Texten und anderen Dokumenten und die Änderungen konnten in Echtzeit verfolgt werden.
• Über APIs sollte sich Wave in andere Internetseiten einbetten oder mit Anwendungen anderer Entwickler kombinieren lassen.

Doch Wave wurde leider von Google wieder eingestellt.

Es war von Google sicher nicht so geplant, aber Wave ist der Prototyp einer Peer-to-Peer-Anwendung.

• Denn wie sieht das Internet heute aus, wenn Google einmal ausfällt
• oder die Wikipedia? (Von nervenden Relevanzdiskussionen will ich gar nicht erst reden)

• Google hat versprochen, Wave als Anwendung unter einer Open Source-Lizenz freizugeben (Teile sind seit Herbst 2009 downloadbar, auf den »Rest« warten wir leider noch immer).
• Damit ist a) die Kritik des BSI an Google Wave hinfällig.
• Und b) eine dezentrale Wave-Umgebung denkbar.
• denn Wave basiert auf einer Erweiterung des XMPP-Protokolls (Jabber)

Der Community-Server ist weg.

• denn XMPP kann abfragen, ob die Gegenstelle erreichbar ist und erst dann entsprechend reagieren
• soll auch mit PubSubHubbub gehen (noch nicht getestet)
• So entfällt die Notwendigkeit eines Community-Servers selbst dann, wenn der Redaktionsserver nicht ständig online ist

Bleibt nur noch das Problem der Suche, doch …

• Warum sollen wir dies nicht Google überlassen?
• Solange sichergestellt ist, daß wir mit einem »Knopfdruck« auf Yahoo!, Bing oder andere Alternativen umschalten können
• Und Inhaltsverzeichnisse kann sich jeder Anwender aus den Suchergebnissen generieren

Also besteht unsere Umgebung jetzt nur noch aus …

• einem Redaktionsserver
• einem Produktionsserver
• offenen Protokolle wie XML-RPC, XMPP, REST und RSS/Atom
• dynamische Elemente auf dem Produktionsserver werden als Gadgets/Widgets dazugeladen

• Winer hat vorgeschlagen, daß der Redaktionsserver nur RSS herausschreibt
• Damit werden die Datensilos der sozialen Netzwerke »gefüttert« (der Nutzer spart sich die Kosten für den Produktionsserver)
• Da das Originalmaterial auf dem Redaktionsserver liegt, kann der Nutzer beliebig auswählen, wohin er sein Material schickt und bleibt so Herr seiner Daten
• Der Redaktionsserver kann auch in der Cloud liegen (Amazon EC2: EC2 for Poets, Google App Engine etc.)

Ich selber arbeite zur Zeit an einem erweiterten Prototyp:

• Der Redaktionsserver besteht aus einer Template-Engine (entweder Perl Template Toolkit oder RubyFrontier), die statische Seiten und RSS 2.0 herausrendert.
• Die Google App Engine dient als Widget-Server für dynamische Elemente und als Schnittstelle (Three Tier Model) zur Asset-Verwaltung (Bilder und Videos hochladen)

→

• Die Assets liegen auf Amazon S3 oder (alternativ) auf Picasa Web Albums (man sollte allerdings immer ein Backup haben)
• Der Produktionsserver liegt auf Amazon S3, kann aber jederzeit auf einen anderen Hoster meines Vertrauens (z.B. in Island) umgestellt werden (gilt übrigens auch für die Asset-Server)
• Kommentare via Facebook (warum? weil es geht!)

Gerade bei kleinen Sammlungen ist die Trennung zwischen Redaktions- und Produktionsserver nicht immer sinnvoll:

• Hier lassen sich (erweiterbare) Wikis wie das DokuWiki nutzen
• Wenn sie (durch einen Plugin-Mechanismus) einfach erweiterbar sind und …
• mindestens XML-RPC, XMPP und RSS/Atom »verstehen«

• Jeder Netzkonsument wird zum (potentiellen) Wissensproduzenten (dezentrales Netz)
• Dieses Wissen steht allen frei zur Verfügung (Open Access, Creative Commons)
• Dieses Wissens wird mittels einfachster Tools (KISS) miteinander vernetzt (Open Protocols)
• Diese Tools können von den Wissensproduzenten selber auf ihre Bedürfnisse angepaßt werden (Open Source)

»Sollten Sie dies für utopisch halten, so bitte ich Sie, darüber nachzudenken, warum es utopisch ist.«

(Bertolt Brecht: Radiotheorie)

Danke für Ihre Aufmerksamkeit.

URL: http://www.cognitiones.de/doku.php/jedermann_ein_wissensproduzent

→ Zurück zum Wiki