Im folgenden Abschnitt soll untersucht werden, wie ein Wissenschaftler zurzeit arbeitet und wie Entwicklungen im Web 2.0 ihn dabei unterstützen können.

Aus diesem Grunde wurden Aspekte dargelegt, die für Projekte relevant sind, wie sie zurzeit am Max-Planck-Institut für Wissenschaftsgeschichte (MPIWG) in Berlin von Wissenschaftlern bearbeitet werden. Diese Aspekte sind auf andere Institute oder Gesellschaften anwendbar, da sich eine spätere Anwendung an dem Leitsatz „the long tail“ aus Abschnitt 2.5.1 orientiert. Die Umgebung sollte die breite Masse von Wissenschaftlern ansprechen und nicht eine spezielle Anwendung sein, die auf die Bedürfnisse einer Projektgruppe oder eines Forschungskreises zugeschnitten ist. Die Implementierungen können bei Bedarf nachträglich als Modul oder API in das System integriert werden.

Um eine effektive Umgebung für einen Wissenschaftler zu schaffen, ist es wichtig, seine Arbeitsweise zu untersuchen. So entstand in Zusammenarbeit mit dem MPIWG eine Liste von Schlagworten, mit denen die Anforderungen eingegrenzt werden konnten (Abschnitt 7.1.1). Des Weiteren fand anhand dieser Ergebnisse ein Vergleich mit den Möglichkeiten des Web 2.0 statt, sodass untersucht werden konnte, welche Teile implementierbar sind. Insbesondere sollen in diesem Abschnitt Ideen, die von Jörg Kantel [6] in seinem Vortrag „Web 2.0: Werkzeuge für die Wissenschaft“ [7], erläuterte, mit eingearbeitet werden, da sie als wegweisende Ansätze für die Bearbeitung von wissenschaftlichen Projekten zu werten sind. Kantel entwickelte außerdem die Idee eines gemeinsamen kollektiven Repositoriums[52], welches erweitert und in die Arbeitsumgebung adaptiert werden soll. Im Zusammenhang der Speicherung/Bereitstellung und Archivierung von Daten werden kurz die Entwicklungen im Bereich von Open Access dargestellt, einem Projekt, das sich für die freie Publikation von wissenschaftlichen Daten einsetzt. Dieses ist für eine gemeinsame Publikations- und Arbeitsplattform von entscheidender Bedeutung, denn es muss geklärt sein, wie mit den Daten umzugehen ist, die von einigen Wissenschaftlern zum Arbeiten benutzt und hochgeladen werden. Sind die Informationen frei verfügbar, so erübrigt sich diese Problematik. Wenn es sich, wie bei wissenschaftlichen Ausarbeitungen meistens der Fall, um Inhalte handelt, die einem Copyright oder anderen Urheberrechten unterliegen, muss geklärt werden, wie und in welcher Form diese auf der Plattform zur Verfügung gestellt werden können.

Ein weiteres Problem, das sich aus dieser Datensammlung ergibt, ist die gewünschte Langzeitverfügbarkeit der Daten und des Services, die nicht durch eine kommerzielle Organisation bewerkstelligt werden – dies würde nicht zu der gewünschten Akzeptanz bei den Wissenschaftlern führen. Somit kann diese Plattform oder dieser Service nur von einem Rechenzentrum wie z.B. der Gesellschaft für Wissenschaftliche Datenverarbeitung Göttingen (GWDG[53]), oder dem Gemeinsames Netzwerkzentrum der MPG in Berlin GNZ[54]) zur Verfügung gestellt werden. Weiterhin muss darauf geachtet werden, dass es zu einer vorsichtigen Einführung des Systems in Teilschritten kommen muss, weil die meisten Wissenschaftler, auf ihre Arbeit fixiert, nur schwer von den gewohnten Arbeitprozessen abrücken, auch wenn neue, weitaus effektivere zur Verfügung stehen. Mit dieser Problematik haben auch andere Anwendungen zu kämpfen, denn es wird immer versucht, im ersten Entwurf alle Kriterien von allen erarbeiteten Anwendungsszenarien mit einzubauen bzw. zu berücksichtigen. Dabei scheitert das Projekt meistens genau an dieser Komplexität, denn diese zieht meist eine steile Lernkurve nach sich, wobei sich dem User die Effektivität verschließt und die ersten Arbeitserfolge ausbleiben.

Die Arbeitsweise eines Wissenschaftlers hat sich in den letzten Jahren grundlegend verändert. Durch die Globalisierung gestaltet sich Forschung zunehmend dezentralisiert, was zur Folge hat, dass Wissenschaftler oder wissenschaftliche Projektgruppen in der ganzen Welt verstreut zusammen arbeiten müssen (vgl. Globalisierungsprojekt am MPIWG)[55]. Zusätzlich werden für Wissenschaftler nur noch selten feste Forschungsstellen an Instituten oder in Organisationen eingerichtet. So arbeiten sie meist in Projektgruppen oder an Einzelforschungsaufträgen mit begrenzter Laufzeit. Nach Beendigung dieser Zeit verlassen sie meist das Institut und bearbeiten andere Forschungsaufträge in anderen Organisationen. Somit sind sie gezwungen, sich nach einer gewissen Zeit an eine neue Arbeitsumgebung in einem anderen Institut zu gewöhnen. Das hat zur Folge, dass die Arbeitseffektivität während der Einarbeitung sinkt. Zusätzlich entsteht das Problem der Daten, die im alten Institut zurückbleiben. Manche Daten werden natürlich auf CD oder anderen Datenträgern mitgenommen, doch diese landen meist in Archiven und werden im schlimmsten Falle vergessen. Ein weiterer negativer Aspekt der „Wissenschaftler-Wanderungen“ ist die fehlende Kommunikation der Wissenschafter nach dem Auslaufen ihrer Verträge. Es gibt zurzeit keinen Workflow, der einen bei der Suche von Wissenschaftlern unterstützt, die man vielleicht aus den Augen verloren hat und für ein neues Projekt benötigt. Ein anderes Szenario ist die Suche von Wissenschaftlern und ihren Publikationen bzw. Spezialgebieten und Ausarbeitungen. Dies alles erzeugt einen begründeten Bedarf nach einer transportablen Umgebung, mit der ein Wissenschaftler eigenständig und zusammen mit anderen Projektmitgliedern arbeiten bzw. sich austauschen kann. Des Weiteren sollte diese Umgebung nicht auf ein Institut, eine Forschungsgesellschaft oder ein Land (Sprache) begrenzt sein. Aus dieser Beschreibung resultierend konnten folgende Schlagworte herausgearbeitet werden:

- einfache, erweiterbare, transportable Arbeitsumgebung - Layout (Desktop, Arbeitsumgebung) persönlich einstellbar - plattformunabhängig - zentrale Datenhaltung (Speicherung, Austausch und Archivierung von allen gängigen Datenformaten, Versionsverwaltung) - gleichzeitiges Arbeiten von mehreren Projektmitgliedern an Dokumenten bzw. Inhalten - Kommunikationskonzept auf der Plattform (Mail, Kalender, VoIP) - „Soziales Netzwerk“ (Plattform), in dem sich alle Wissenschaftler eintragen, vorstellen und finden (vgl. Xing[56])

Die nachfolgende Beschreibung ist nur als erster Entwurf gedacht, kann aber durchaus als Basis für die spätere Implementierung Verwendung finden. Bei dieser Arbeitsoberfläche (Plattform) sollte auf große Flexibilität geachtet werden, damit der User nicht eingeengt wird und eine Erweiterung und Anpassung ohne Schwierigkeiten möglich ist. Für diese Aufgabe ist Drupal[57] als Weblog-fähiges CMS[58] mit eingebauter Community-Funktion ein guter Grundstein. Es ist unter Open Source verfügbar und setzt auf PHP und MYSQL auf, wodurch eine leichte Anpassung und Erweiterung möglich ist. Auf Basis dieser Plattform können nun alle benötigten Komponenten implementiert werden. Bei einer späteren Entwicklung der Anwendung sollte aber im Einzelnen geprüft werden, welche Module zuerst und welche später implementiert werden. Dieses resultiert aus der schon erwähnten langsamen Einführung des Systems. Bei diesem Prozess sollte ein Modul angeboten und mit Hilfe der User verbessert und weiterentwickelt werden, sodass erst nach einem erfolgreichen Betatest ein weiteres Modul implementiert wird. Im Grunde würde diese Oberfläche aus mehreren Modulen bestehen, die in einer Art Administrationsoberfläche für die einzelnen Benutzer zusammengestellt werden können. Somit kann sich ein Wissenschaftler genau die Oberfläche erstellen, die er für seine Arbeit benötigt, ohne von der Masse der möglichen Anwendungen abgelenkt oder abgeschreckt zu werden. Erweiternd dazu sollte für die Anwendungsteile eine API zu Verfügung stehen, um Wissenschaftlern die Möglichkeit zu geben, per Script auf Funktionen zuzugreifen oder diese in ihre eigenen Anwendungen bzw. Server zu integrieren. Es ist außerdem auch eine Implementierung in einem Widget[59] denkbar, bei dem bestimmte Funktionen wie Tagging oder Suche im System eingebunden sind. An diesem Punkt sollte für die bessere Übersicht und im Hinblick auf den späteren Implementierungsprozess eine Aufspaltung und nähere Betrachtung der inbegriffenen Komponenten dieser Arbeitsumgebung erfolgen. Zusätzlich wird zu jedem Modul ein Realisierungsbeispiel angegeben, welches in der späteren Implementierung Verwendung finden kann.

Für die Comunityfunktionen soll das bereits erwähnte Drupal Anwendung finden. In diesem System sind alle Module und Pakete bereits enthalten, die eine effektive Communityplattform benötigt. Somit bietet es die Möglichkeit, eine Selbstdarstellung (Steckbrief) des Wissenschaftlers mit Text, Bild, Ton, Filmmaterial inkl. Links zu Veröffentlichungen etc. zu publizieren. Als Beispiel kann hierzu Xing, Youtube, Stayfriends etc. dienen. Gleichzeitig wird das Wiederfinden der „Wanderwissenschaftler“ untereinander erleichtert. Projektgruppen können entsprechend gebildet werden und auch Platzierungen von Stellengesuchen bzw. von offenen Stellen in den jeweiligen Bereichen werden hierdurch erleichtert. Die Kalenderfunktion kann durch das zurzeit am MPIWG genutzte Egroupware-System realisiert werden. Mit diesem System hat man bereits alle fertigen Komponenten für eine effektive Termin- und Kalenderfunktion, die darüber hinaus um die Funktionen Mail und Adressbuch erweitert werden kann. Für die Kommunikation mit Mobilen Clients steht eine SyncML Schnittstelle zur Verfügung. Der Editor[60] sollte sich an den Beispielen von Frame Maker, LaTex oder Word orientieren. Dabei soll die Bearbeitung eines Dokumentes von mehreren Personen gleichzeitig ein zentraler Punkt bei der Implementierung sein, um auch die Arbeit von getrennt arbeitenden Projektgruppen zu ermöglichen. Zu diesem Zweck können bereits fertige Lösungen von Thinkfree oder Ajax13 (vgl. 2.5.7) Anwendung finden. Diese können über eine API oder direkt verlinkt implementiert werden. Zusätzlich sollten diese Komponenten mit Wiki- und Blogtechnologie verknüpft sein, um ein effektives Projektmanagement zu gewährleisten. Erweiternd dazu sollte ein GIS als Webservice (vorzugsweise Google Earth/Maps) in die Anwendung integriert werden. Es ist davon auszugehen, dass alle wissenschaftlichen Projekte in einem geographischen Bezug zueinander stehen und durch dessen Visualisierung besser bearbeitet bzw. mit anderen in Verbindung gesetzt und bearbeitet werden können. Dieser Punkt wird in der Testanwendung (vgl. 5) näher erläutert, sodass an dieser Stelle nicht weiter darauf eingegangen werden soll. Ein gemeinsames Repositorium kann in Teilen bereits sehr einfach mit den schon bestehenden Anwendungen wie YouToube, Sevenload und Flickr realisiert werden. Um aber alle Daten zu speichern und zu verwalten, müsste man eine eigene Anwendung entwickeln. Da dieses zurzeit noch nicht vorhanden ist, muss in diesem Zusammenhang zwischen Archivierung und Präsentation der Daten unterschieden werden. Für die Archivierung sollte klar auf offene Formate zurückgegriffen werden. In der eigentlichen Anwendung bzw. in der Webumgebung sollten eher Datenformate mit anderen (besseren) Codierungs- oder Streamingeigenschaften Verwendung finden. So könnte z.B. bei der Videoverarbeitung ein Flashserver genutzt werden. Dieses würde zu einer höheren Verbreitung in den Browsern führen als es mit Quick Time zurzeit der Fall ist. Für die Archivierung indessen sollte aber auf offene Datenformate wie OGG Vorbis Theora zurückgegriffen werden, da diese auch in Zukunft noch verfügbar sein werden. Dieser Prozess der geteilten Datenformate kann z.B. serverseitig mit Tools wie Ming[61] oder FF Mpeg[62] realisiert werden. Damit besteht nicht die Gefahr, dass diese Formate durch Firmenaufkäufer verschwinden oder ihre Verwendung untersagt wird. Die nachfolgende Liste soll kurz die möglichen zu implementierenden Formate darstellen:

Für die Langzeitarchivierung: Open Office[63] bei Text PNG[64] bei Bildern TIFF[65] bei Vektorbildern OGG Vorbis[66] Theora bei Video OGG Vorbis[67] bei Audio GML[68] bei Geodaten

Für die Darstellung in der Anwendung: PDF[69] als Textformat JPEC[70] bei Bildern/Vektorbildern Flash[71] bei der Videoübertragung MP3[72] bei der Audioübertragung KML[73] bei den Geodaten

Diese Daten müssen durch eine einfache Rechtevergabe klassifizierbar sein und es sollten Lese- und Schreibrechte einzeln vergeben werden können. Damit kann ein Wissenschaftler, solange er an einem Thema arbeitet, dieses als Privat maskieren und nach Fertigstellung und Veröffentlichung mit einem Klick für alle verfügbar machen.

Welt à für alle sichtbar Gruppe (Projekt) à nur für die Projektgruppe sichtbar Privat à nur für den User sichtbar

Wenn aus Gründen der Kapazität nicht alle Daten gespeichert oder aus alten Projekten übertragen werden können, so sollten zumindest die Angaben von Links ermöglicht werden. In diesem Zusammenhang ist auch ein Im- bzw. Export von Bookmark-Dateien für den Browser angedacht. Dazu könnte z.B. auch der Bookmarkservice del.icio.us Anwendung finden. Für die Ansicht der Daten sind Folder und Subfolder vorgesehen, um ein besseres Sortieren zu ermöglichen. Dabei sollte auch das Setzen von Zugriffsrechten auf ganze Ordner bzw. Ordnerstrukturen und die Übertragung auf untergeordnete Objekte möglich werden. Für die Kommunikation kann eine einfache VoIP-Anwendung auf Basis eines Asterisk- Servers[74] integriert werden. Damit kann an allen Stellen der Anwendung mit anderen Mitgliedern über ein eingeblendetes Widget kommuniziert werden (Mail, VoIP, Video-conferencing). Dabei soll die Möglichkeit integriert werden, diese in Teilen oder komplett mitzuschneiden und zu archivieren. Damit können sie dann einem gemeinsamen Repositorium zur Verfügung gestellt werden oder nur im Privatarchiv Verwendung finden.

Für alle Funktionen sollte ein Taggingsystem nach Folksonomy eingesetzt werden, um Inhalte und sich selbst zu beschreiben und so die Wiederverwendbarkeit und Suche von Daten bzw. Personen und Projekten zu ermöglichen. Teile der Anwendung bzw. Funktionen sollten auf Ajax basieren, um ein desktopähnliches Verhalten zu interpretieren.

Implementierung: Bei der Implementierung gibt es drei Varianten der Anwendung: - vollständige Implementierung in eine Browseroberfläche - Browseroberfläche in Verbindung mit einer Widgets oder Client Variante für die Offline Bearbeitung - vollständige Implementierung in einen plattformunabhängigen Desktop-Client der in einem verteilten System die Daten serverseitig ablegt und ähnlich einem Thinclient nur Ein- und Ausgabemaske darstellt

Zentrale Datenhaltung und Archivierung mit Versionskontrolle: Durch die Realisierung als verteiltes System und die Nutzung des Webs als Plattform kann eine Datensicherung und Archivierung serverseitig und in Echtzeit durchgeführt werden. Es entfallen alle Maßnahmen für ein inkrementelles Backup oder eine Versionskontrolle, da diese automatisch ausgeführt werden. Des Weiteren kann dadurch ein weltweiter Zugriff auf gesicherte Daten ermöglicht werden. Es ergeben sich zusätzlich einige grundsätzliche Fragen, die in dieser Ausarbeitung von mir noch nicht beantwortet werden können. Diese sind aber für die Realisierung von grundlegender Bedeutung und müssen an anderen Stellen geklärt werden. Hierzu zählen folgende Fragen:

- Soll die Plattform als MPIWG-, MPG-Anwendung oder generell institutsunabhängig realisiert werden? - Wem gehören die hochgeladen Daten, wenn diese Anwendung auch von „nicht-MPIWG Wissenschaftlern“ genutzt wird? - Gilt eine Veröffentlichung einer wissenschaftlichen Abhandlung in dieser Plattform als Publikation?

Die Frage nach den Rechten der Daten bzw. ihrer Veröffentlichung kann zum Teil durch Open Access beantwortet werden. Open Access steht für „freier, kostenloser Zugang“. Man versteht darunter das Ziel, die wissenschaftlichen Entwicklungen und Materialien (Literatur und Veröffentlichungen) allen Menschen (Wissenschaftlern und wissenschaftlichen Organisationen) frei und kostenlos zur Verfügung zu stellen. Darin eingeschlossen ist auch die freie Verfügbarkeit von digitalisierten Informationen aus Museen und Archiven bzw. deren Aufarbeitung und Verteilung auf fachbezogenen Servern, Universitätswebseiten oder Online-Archiven. Dies ist ein wichtiger Punkt bei der Entwicklung eines Web 2.0-Arbeitsplatzes, denn ohne die gemeinschaftliche Publikation von Inhalten würde ein wissenschaftliches Netzwerk (Plattform) zum Austausch von Daten nicht funktionieren.

Geschichte von Open Access: Die Entwicklung von Open Access begann in den 1990er Jahren, als viele Verlage dazu übergingen, Zeitschriften gegen eine Lizenz an Bibliotheken oder Instituten elektronisch zur Verfügung zu stellen. Ein weiterer wichtiger Schritt war die 2001 von namhaften Wissenschaftlern gegründete Budapester Open Access Initiative. In einer Erklärung dieser Organisation heißt es: „Frei zugänglich im Internet soll all jene Literatur sein, die Wissenschaftlerinnen und Wissenschaftler ohne Erwartung hierfür entlohnt zu werden, veröffentlichen.“

Berliner Erklärung (MPIWG): Ein Meilenstein auf dem Weg zur Realisierung des Open Access- Gedanken war die „Berliner Erklärung“ vom Oktober 2003, an der das MPIWG maßgeblich beteiligt war. Sie wurde von vielen deutschen und internationalen Instituten und Organisationen unterschrieben. Ein Jahr später, im Jahre 2004, sprach sich auch das britische Unterhaus dafür aus, die Ergebnisse der öffentlich finanzierten Forschungen unter den Bedingungen der Open Access Initiative zu veröffentlichen.

Ein großer Vorteil des OA ist, dass stark subventionierte Forschungsergebnisse von Instituten oder äquivalenten Organisationen wie Universitäten, nicht an diverse kommerzielle Verlage gehen und von diesen teuer wieder zurückgekauft werden müssen. Zum Zweiten wird durch diese Initiative die digitale Kluft zwischen finanziell unterschiedlich entwickelten Gebieten oder Organisationen verringert, sodass wissenschaftliches Wissen tatsächlich Allgemeingut sein kann.

Die Nachteile sind meines Erachtens nach nur in der jetzigen Entwicklung bzw. im jetzigen Stand der Technik zu finden, weil sich die einzelnen Organisationen nicht auf eine einheitliche Form des Publizierens einigen können oder wollen. Dazu kommt die Tatsache, dass es zum jetzigen Zeitpunkt keine ausreichenden technischen Möglichkeiten und finanzielle Mittel gibt, welche eine umfassende und vollständige Digitalisierung möglich machen würden [35] [37].