Stylesheet style.css not found, please contact the developer of "arctic" template.

This is an old revision of the document!


Table of Contents

Web 2.0 und der Einsatz in der Wissenschaft

In Zusammenarbeit mit dem Max-Planck-Institut für Wissenschaftsgeschichte in Berlin und der Cuneiform Digital Library Initiative (CDLI) in Kalifornien Mit Unterstützung durch Jörg Kantel und Peter Damerow (MPIWG, Berlin), sowie Dr. Robert Englund und Jacob Dahl (CDLI, Kalifornien)

1 Einleitung

1.1 Thema

In dieser Arbeit sollen die Einsatzmöglichkeiten und der Nutzen des Web 2.0 für die Verwendung in wissenschaftlichen Projekten evaluiert werden. Die daraus resultierenden Anwendungen sind in Zusammenarbeit mit dem Max-Planck-Institut für Wissenschaftsgeschichte (MPIWG[1]) und der Cuneiform Digital Library Initiative (CDLI[2]) entstanden. Im Vorfeld wurde untersucht, welche Technologien und Verhaltensweisen sich unter dem „Buzzword Web 2.0“ vereinen lassen. Des Weiteren wurde die Gestaltung eines Webservices erarbeitet, um Wissenschaftler bei der Arbeit zu unterstützen und Daten verfügbar zu machen. Inbegriffen sind dabei die effektivere Bearbeitung von Projekten, sowie die Kommunikation und der Austausch von Wissenschaftlern untereinander. Die in diesem Webservice enthaltene GIS-Anwendung wird als Testimplementierung vorgestellt. Dabei sollen Ausgrabungspunkte und Ruinen im alten Irak visualisiert und bearbeitet werden.

1.2 Motivation

Es gibt seit Jahrhunderten wissenschaftliche Forschungen und Ausgrabungen. Dabei haben sich Archäologen stets darum bemüht, ihre Funde und Ausgrabungen zu kartographisieren und in Form von Büchern, Publikationen oder Ausstellungen sowohl Wissenschaftlern als auch interessierten Laien zugänglich zu machen. Leider sind diese Arbeiten nur auf das den Autoren oder Veranstaltern zugängliche Material begrenzt. In den meisten Fällen sind die Verbindungen von Funden und Ausarbeitungen aber durch politische oder geografische Grenzen beschränkt. Dies lässt sich am Beispiel des heutigen Irak veranschaulichen: Es ist zurzeit nicht möglich, die Ausgrabungen des Zweistromlandes zu besichtigen bzw. an diesen zu arbeiten. Auf Basis dieser Schwierigkeiten stellt das Internet als Plattform eine der besten Möglichkeiten der Visualisierung von Ausgrabungspunkten und der wissenschaftlichen Bearbeitung dar. Neue Techniken und Verhaltensweisen, die das Internet zurzeit unter dem Synonym Web 2.0 vereint, bieten effektivere Möglichkeiten, Grenzen zu überwinden. Darüber hinaus wird eine neue Art der Publikation geschaffen, die nicht auf einen einzelnen Verfasser begrenzt ist. Dies führt wiederum dazu, dass sich der Peer-Review-Prozess nicht über Monate oder Jahre hinzieht, da Informationen schneller mit anderen im Netz befindlichen verglichen und gegebenenfalls erweitert oder verbessert werden können. Als Schlagworte sind in diesem Zusammenhang Google Earth/Maps/GIS, Blog/Wiki-Technologien und Foto/Videohoster zu nennen. Unter dem Gesichtspunkt des Desktop-Replacement kann man diese Punkte zusammenfassen und als angepasste Arbeitsumgebung für Wissenschaftler realisieren. In einer solchen Anwendung sind alle benötigten Services per Mashup implementiert, was die Administration wesentlich vereinfacht. Somit würde eine Plattform geschaffen, die einfach strukturiert sowie leicht anpass- und erweiterbar ist. Außerdem ist diese Form der Implementierung weitaus billiger und entwickelt sich durch die verteilten Ressourcen schneller und effektiver weiter. Sie ist klein, wendig, kann auf Änderungen schneller reagieren und sich an neue Anforderungen anpassen. Eine Kombination von all diesen Tool’s könnte eine Antwort auf die Aufforderung „gebt uns Tool’s“ [20] des Direktors des Max-Planck-Institutes für Wissenschaftsgeschichte, Jürgen Renn, sein.

1.3 Gliederung der Arbeit

Diese Arbeit gliedert sich in vier Teilgebiete. Im ersten Abschnitt wird kurz auf die Vorgeschichte des Web 2.0 eingegangen und eine ausführliche Definition entwickelt. Diese bezieht sich auf die Ausführungen von Tim O’Reilly und John Battle aus der ersten Web 2.0 Konferenz im Jahre 2004. Es werden alle Veränderungen und Entwicklungen erläutert, die sich damit vereinen lassen. Dabei wird die Veränderung im Userverhalten, wie auch die neue Sicht auf Webanwendungen und ihr Stellenwert in der Gesellschaft erläutert. Inbegriffen ist auch eine Gegenüberstellung von Technologien und ihren Entwicklungszeiträumen. Mit diesen kann dargestellt werden, wie neu diese Entwicklungen wirklich sind. Des Weiteren wird die Verwendung bzw. Vermarktung von Userdaten, die Änderung im Produktionsverhalten von Anwendungen und die darin inbegriffene Transformation vom Desktop zum Webtop aufgezeigt.

Im nächsten Abschnitt werden die zuvor dargestellten Technologien und Verhaltensweisen definiert und anhand von Beispielen erläutert. Dabei kommen nur die populärsten Punkte zum tragen, da eine vollständige Auflistung aus Gründen der schnellen Entwicklung der Internets und des begrenzten Umfanges der Arbeit nicht möglich ist. In einem weiteren Schritt wird ein Webservice entwickelt, der bei der effektiven Bearbeitung von wissenschaftlichen Projekten helfen soll. Dazu wurde im Vorfeld die Arbeit des Wissenschaftlers untersucht, um festzustellen wie ihn Technologien und Verhaltensweisen des Web 2.0 unterstützen können. Es werden dabei unterschiedliche Szenarien mit ihren einbegriffenen Formaten und Möglichkeiten dargestellt. Dazu gehören Kommunikationsmittel, wie Blog, Wiki oder VoIP ebenso wie Editoren, GIS- und Comunity-Funktionen. In diesem Zusammenhang wird auch die Aufnahme, Speicherung und Langzeitarchivierung in einem gemeinsamen Repositorium betrachtet. Aus der zuvor erläuterten Entwicklung wird die GIS- Komponente als Einzelanwendung herausgenommen und testweise implementiert. Dabei sollen Ausgrabungsstätten und Punkte in einen Webmapping Service aufgenommen, dargestellt und gespeichert werden. Zu diesem Zweck wurden im Vorfeld einige Webserverices untersucht, die Satellitenkarten für die Weiterverarbeitung anbieten. Auf Basis dieser Ergebnisse sollen Daten und Pläne auf Satellitenkarten des Irak übertragen und visualisiert werden. In diesem Zusammenhang wird auf eine derartige Speicherung und Verteilung der Daten eingegangen, dass diese auch für getrennt arbeitende Projektgruppen nutzbar sind. Die zu implementierenden Daten werden aus der CDLI-Datenbank entnommen, wobei ebenfalls betrachtet werden soll, wie diese Daten in einer späteren Anwendung verknüpft werden können. Abschließend werden in einer kurzen Zusammenfassung einige Aussichten und Erweiterungen vorgestellt. Diese können als direkte Weiterentwicklung der Testanwendungen angesehen werden und können somit ohne Probleme nach erfolgreicher Implementierung integriert werden.

2 Definition Web 2.0

Was beinhaltet das „Buzzword“ Web 2.0?

Nicht erst seit einige Firmen dieses als Marketing-Schlagwort verwenden, ist unklar, was genau der Begriff „Web 2.0“ überhaubt bezeichnen soll. Web 2.0 ist keine Technologie, die sich durchgesetzt hat, kein neues Protokoll und keine neue Programmiersprache. Es ist vielmehr eine Verbindung vieler kleiner Faktoren, die in ihrer Kombination eine neue Sichtweise auf das Internet ergeben. Dieses wurde durch eine Rückbesinnung auf die Ursprünge des Internets möglich, die klar werden liess, dass dieses Medium nicht nur als Verkaufsplattform und zur Spamverteilung genutzt werden sollte (vgl. die Zeit vor der Dot-Com-Blase), sondern auch dazu dienen kann, Menschen zusammenzuführen, um mit ihnen zu kommunizieren und Informationen auszutauschen bzw. ein Medium zu schaffen, welches wieder von User für User nutzbar ist. Diese neue Sichtweise, gepaart mit Technologien wie Ajax, RSS, Ping, Mashup, offenen Schnittstellen und Social Networking, kann als Definition für das Web 2.0 genutzt werden. Im folgenden Abschnitt wird kurz auf die Entwicklungsschritte des Web eingegangen. Dabei wird auf Basis der Theorien von Tim O’Reilly eine ausführliche Definition des Web 2.0 erarbeitet [4].

2.1 Das Web in der Zeit von 1988-1995

Die Anfänge des Web 2.0 entwickelten sich bereits in der Zeit um 1988. Dabei wurde das Web vorrangig für die Kommunikation von Wissenschaftlern oder Universitäten untereinander und dem Militär genutzt. In dieser Epoche war das Web ein schreibendes Medium und es wurde für Mail und Datenkommunikation genutzt. Dabei waren die ersten Browser bereits so aufgebaut, dass jeder Nutzer Inhalte selbst einstellen und editieren konnte. Hier wurden die Grundsteine für das „two way Web[3]“ gelegt, welche aber erst im Web 2.0 umfassend realisiert werden sollten [1] [27].

2.2 Das Web in der Zeit von 1996-1997

Das Web wie wir es aus dem Jahre 1996 kennen basierte vorrangig darauf, statische HTML- Seiten für die Selbstpräsentation oder den Verkauf respektive die Werbung von Produkten ins Netz zu stellen. Die Option, dass Inhalte editiert werden, war nicht mehr erwünscht, ebenso wenig wie der Austausch von Inhalten und die Verlinkung zu anderen Webseiten. Die Betreiber versuchen die User auf ihren Seiten zu halten und veranlassen sie so zum reinen Konsumieren von Inhalten [1].

2.3 Das Web in der Zeit von 1997-2001

In der Zeit zwischen 1996 und 2001 wurde das Web dynamisch. Die angewandten Lösungen waren allerdings – meist aus Kostengründen – nur auf Shops und Foren begrenzt, die noch härter um Hit & Eyeballs (Seitenaufrufe) kämpfen. Jeder Betreiber wollte die Nutzer auf seinen Seiten halten. Dadurch entstand eine mangelnde Vernetzung der Informationen und Inhalte. Ein Anwender hatte nur begrenzt die Chance, Daten selbst einzugeben. Nach dem Zusammenbruch der Dot-Com-Blase zogen sich die meisten Investoren wieder zurück. Dadurch wurde der Weg frei für die Open-Source-Gemeinde, die durch Offenheit und Zusammenarbeit den Grundstein für den Erfolg des Web 2.0 legte [1].

2.4 Web 2.0

Der Begriff „Web 2.0“ wurde durch Tim O’Reilly und John Battle geprägt, die Anwendungsmöglichkeiten und interessanten Entwicklungen seit der Dot-Com-Blase unter dem Synonym Web 2.0 zusammenfassten (diese waren nicht unbedingt neu, wurden aber in einem anderen Zusammenhang betrachtet und neu definiert). Einen Eindruck von der Verfügbarkeit der Technologien, Verhaltensweisen und Anwendungen gibt Abbildung 1: Es ist zu erkennen, wie lange diese jeweils bereits vor dem Web 2.0 existierten und benutzt wurden [2].



Abbildung 1: Technologiebaum Web 2.0 [23]


Dieses neue (alte) Web baut (wieder) auf Offenheit, Freiheit und Standardisierung auf. Möglich wurde dieses, wie bereits erwähnt, durch die starke Open Source Bewegung, die nach dem Platzen der Dot-Com-Blase zunehmend im Internet an Einfluss gewann, nachdem die großen kommerziellen Organisationen das Interesse am neuen Markt verloren hatten. Sie entwickelten Anwendungen, Schnittstellen, Frameworks und stellten diese allen zur Verfügung. Dadurch ist es möglich, attraktive Anwendungen kostengünstig herzustellen, die früher nur selten bezahlbar waren. Offene Schnittstellen machen einen Datenaustausch von unterschiedlichen Systemen und Anwendungen möglich (siehe Flickr, Google Maps, …). Zusätzlich ist Standardisierung ein weiterer wichtiger Faktor für den Erfolg des Web 2.0, da nur durch einheitliche Protokolle und Formate wie XML, REST, GML/KML, SOAP, RSS/Atom (siehe Kapitel 3) der Gebrauch von Schnittstellen (API’s) überhaupt erst möglich wurde. Die Freiheit in diesem Web besteht zum großen Teil aus der Möglichkeit des Nutzers, Daten überall zu publizieren. Web 2.0 Systeme basieren auf der Mitarbeit der Benutzer, die Inhalte verfügbar machen, pflegen, erweitern und verbessern bzw. darüber (mitunter lang und ausgiebig) diskutieren. Durch Ajax ist zudem eine flache Navigation und starke Interaktivität der Seiten realisiert worden. Entgegen vieler Behauptungen muss ein erfolgreicher Web 2.0 Service aber keineswegs immer nur Ajax verwenden. Es ist vielmehr nur eine der Technologien, die zurzeit auf Grund der verfügbaren Bandbreite erfolgreich sind. (weiterführend Kapitel 3). Des Weiteren resultiert aus höheren Übertragungsraten eine Änderung im Kommunikationsverhalten, wodurch auch die Möglichkeiten der mobilen Nutzung von Software und Internetanwendungen stark angestiegen sind. All diese Faktoren tragen gemeinsam dazu bei, dass das Internet wieder eine erfolgreiche Entwicklung erfährt [3]. Einen groben Überblick dieser Veränderungen im Web 2.0 geben die Vergleiche in Abbildung 2, die die Wandlung von Zusammenarbeit und Offenheit im neuen Web illustriert.


2_web1.0vs_web2.0.jpg


Abbildung 2: Unterschiede Web 1.0 – Web 2.0 (O’Reilly) [2]


An diesem Punkt soll aber darauf hingewiesen werden, dass es trotz der Zusammenfassung von einigen Unterschieden und der Verwendung als Marketingschlagwort keine eindeutige Definition von Web 2.0 gibt. Das Internet entwickelt sich stetig weiter und es ist nur möglich, Teilabschnitte grob zusammenzufassen. Eine realistischste Betrachtungsweise kann Abbildung 3 vermitteln: das Web 2.0 steht im Zentrum der Beschreibung, die unterschiedlichen Entfernungen und Größen stellen jeweils die entsprechende Bedeutung für die zugehörigen Prinzipen und Praktiken dar. Diese Art der Illustration ermöglicht es, eine genaue Definition zu umgehen.



Abbildung 3: Web 2.0 System [2]


2.5 Die 7 Prinzipen des Web 2.0

Tim O’Reilly ist durch seinen Konferenzbeitrag im Herbst 2004 (USA) zu einem Pionier des Web 2.0 geworden. Seine Ausführungen und Definitionen gelten als wegweisend in der Web-Entwicklung. In dieser Konferenz wurden die wichtigsten Entwicklungen und Erweiterungen des Internet zusammengefasst. Diese werden bis heute von vielen Menschen verwendet, kommentiert und verbessert. Sie stellen einen großen Teil des in Abbildung 3 dargestellten Diagramms dar und können gleichzeitig als repräsentative Zusammenfassung von Web 2.0 dienen. Im folgenden Abschnitt soll auf die wichtigsten Punkte näher eingegangen werden.

2.5.1 Das Web als Plattform

Das erste Prinzip ist das Web „als Plattform“ zu sehen. Dieses wurde bereits zum Teil von DoubleClick[4] oder Akamai[5] vor dem Web 2.0 angestrebt. Weiterhin ist die veränderte Sichtweise auf Softwarelösungen durch die Einführung von Multiplattformen[6] (siehe auch Punkt 2.5.6) zu benennen. Diese hat zur Folge, dass Webanwendungen als Service angeboten, zentral verwaltet und kontinuierlich verbessert werden, wobei der Nutzer direkt oder indirekt für die Verwendung bezahlt. Ein Zitat von Tim O’Reilly aus der ersten Web 2.0 Konferenz erläutert dies näher, indem es einen Vergleich von Netscape (Web 1.0) und Google (Web 2.0) zieht, bei dem entscheidende Punkte auf der Suche nach einer Beschreibung abgeleitet werden können. Darin heißt es:

„ … Google benötigt vor allem Kompetenzen in einem Bereich, den Netscape niemals brauchte: Datenbank Management. Google ist nicht nur eine Ansammlung von Software-Tools, es ist eine spezialisierte Datenbank. Ohne Daten sind die Tools nicht nutzbar, ohne die Software sind die Daten nicht handhabbar. Der Wert der Software verhält sich proportional zu Ausmaß und Dynamik der Daten, die sie verwalten soll. Man glaubte an die Ansicht der 90er Jahre, dass es beim Web um Verbreitung und nicht um Beteiligung geht…“

Damit wird die Wandlung des Internet beschrieben, bei der es nicht mehr auf das Konsumieren von Dateninhalten ankommt. Vielmehr werden Services geschaffen, die durch freiwillige und kostenlose Mitarbeit der Nutzer Informationen sammeln und anderen wieder zur Verfügung stellen (siehe Punkt 2.5.2). Dabei ist für den Erfolg die breite Masse („The Long Tail“[7]) einer Plattform entscheidend. Dieses wird zurzeit aus zwei Richtungen heraus beschrieben: Zu unterscheiden sind der Marketing-Aspekt und der Entwicklungs- bzw. Verwendungs-Aspekt.

Marketing-Aspekt: Er besagt, dass sich Werbung und der Produktverkauf weitaus effektiver gestalten, wenn man mehrere einzelne Seiten im Internet bedient und vermarktet. Ein gutes Beispiel dafür ist Google Adsense[8]. Durch diesen Service kann Werbung leicht auf jede noch so kleine Webseite eingebunden werden. Anhand von Metadaten der Seite wird sie mit personalisierter Werbung versehen. Entwicklungs- und Verwendungs-Aspekt: Dieser beschreibt die Anpassung von Webservices auf das Nutzerverhalten, um die breite Masse anzusprechen, sowie die Sammlung und Beschreibung von Daten und Metainformationen. Dadurch kann ein breites Spektrum des Nutzerwissens dargestellt werden, in dem die gesammelten Informationen in ihrer Schnittmenge eine wahrheitsgetreue Sicht liefern (vergl. 2.5.2, 2.7.2) [2] [22].

2.5.2 Die Nutzung kollektiver Intelligenz

Ein weiteres zentrales Prinzip, welches für den Erfolg von Web 2.0 steht, ist die Nutzung von kollektiver Intelligenz. Zurzeit zeichnet sich ein Trend bei allen erfolgreichen Internetfirmen ab, die sich diese Eigenschaft auf verschiedene Weise zu Nutze machen. Zum einen verwenden Yahoo oder Google diese Gemeinschaft, um ein Verzeichnis von Informationen aufzubauen, wobei sie die Daten durch die kollektive Arbeit von allen Anwendern auswerten. Neuere Firmen wie del.icio.us[9] und Flickr[10] verwenden dieses auch als „Folksonomy“ (vergl. 3.5) bezeichnete Verfahren für das gemeinsame Beschreiben (auch Taggen genannt) von Inhalten (Bilder, Bookmarks, etc). In diesem Zusammenhang ist auch die Online-Enzyklopädie Wikipedia zu nennen, die ihren Grundgedanken aus einer Maxime von Eric Raymond[11] (Def. für Open Source Software) ableitet:

“Mit genügend wachsamen Augen werden alle Bugs beseitigt“.

Dadurch wurde ein Informationssystem geschaffen, bei dem alle Nutzer Information (Daten) eintragen und sie wechselseitig und selbständig verbessern und erweitern können. Ein weiterer wichtiger Punkt für die Nutzung von kollektiver Intelligenz sind die im Web 2.0 populären Webblogs, die durch RSS, Ping und Trackbackping (siehe 3.3 und 3.5) in letzter Zeit einen hohen Verbreitungsgrad erreicht haben und sich immer größerer Beliebtheit erfreuen. Ihre Zahl wird auf rund 75 Millionen (März 2007) geschätzt, wobei alle 1,4 Sekunden (Abbildung 4) ein Blog hinzukommt. Durch die Verwendung dieser Techniken bzw. die Verknüpfung mit Community-Servern (siehe 3.5) entsteht ein inkrementelles Web, wodurch Informationen aktuell und schnell verteilt werden können. Zugleich stellt die kollektive Intelligenz einen Filter für die Informationen dar [28]. Zusammenfassend kann man dieses Prinzip mit den Worten von James Suriowecki[12] am besten als “die Weisheit der Massen“ beschreiben.

Dabei sind die Zuschauer von einst (Konsumenten im Web 1.0) die aktiven Betreiber von heute (Web 2.0) [2] [22].

—-


Abbildung 4: Blogstatistik [28]


2.5.3 Daten als Kapital

Web 2.0 Anwendungen basieren immer stärker auf einzigartigen Datensammlungen. Dadurch schaffen sich Firmen wie Google oder Yahoo ihren enormen Wettbewerbsvorteil. Jeder erfolgreiche Internet-Service beruht heutzutage darauf, Daten aufzunehmen, in einer Datenbank abzulegen und aufgearbeitet wieder zur Verfügung zu stellen – in einem solchen Ausmaß, dass SQL auch als das neue HTML gesehen wird. Datenbanken bzw. Daten sind der zentrale Punkt bei Web 2.0 Anwendungen. Tim O’Reilly bezeichnete sie als Infoware, in der die Daten – wie im vorherigen Abschnitt beschrieben – oft durch kollektive Intelligenz erstellt werden. Dabei wird eine Verknüpfung zwischen den Punkten 2.5.2 (Kollektive Intelligenz) und 2.5.3 (Daten als Kapital) deutlich, wodurch ein neues Bewertungssystem von Webservices abgeleitet werden kann:

Ein Webservice ist nur so gut wie die Daten, die er in der Lage ist zu sammeln, zu verwerten und wieder zur Verfügung zu stellen. Ein Dienst gewinnt immer mehr an Bedeutung und Vollständigkeit, je mehr Menschen ihn nutzen und sich beteiligen.

Aber wem gehören die Daten?

Vielleicht sollte man sich die Allgemeinen Geschäftsbedingungen einiger Webservices einmal genauer durchlesen, bevor man Daten zur Verfügung stellt. Zum Beispiel erhebt Amazon in seinen Copyright-Rechten Anspruch auf jede abgegebe Beurteilung, so dass diese theoretisch nicht an anderer Stelle im Web verwendet werden dürfte. Welche Rechte haben User dann noch an ihren eigenen Daten, die sie so freizügig preisgeben? Man kann in den meisten Fällen davon ausgehen, dass der Nutzer durch die Eintragung alle Rechte an den Webservice abtritt. Dies soll keine negative Bewertung des kollektiven Erfassens von Informationen sein, sondern vielmehr ein Hinweis, genau zu überlegen, wo man überall Daten hinterlässt („das Netz vergisst nichts“) [2] [22] [35].

2.5.4 Abschaffung des Software Lebenszyklus

Die neue Sicht auf Webanwendungen und ihre Weiterentwicklung zu Webservices führt in diesem Zusammenhang auch zu einer anderen Auslieferungscharakteristik. Grund hierfür ist die Verlagerung von Desktopanwendungen in das „Betriebsystem Internet“[13]. Dadurch sind tägliche oder stündliche Erneuerungen möglich, wodurch sich diese immer in einem Beta-Zustand befinden. Dabei ist auch ein Wandel der Definition von Software zu beobachten. Diese kann mit Verwendung als Webservice eher als Dienstleistung bezeichnet werden. An dieser Stelle wird auch eine Verbindung zu der in Punkt 2.5.2 behandelten, „kollektiven Intelligenz“ deutlich. Diese sorgt dafür, dass Echtzeitbeobachtungen des Nutzerverhaltens oder die Mitwirkung von Usern eine schnellere bzw. effektivere Verbesserung und Erweiterung des Services zur Folge haben. Dadurch entwickelt sich ein völlig neues Auslieferungsmodell, welches sich von dem einer Desktopanwendung unterscheidet. Dies kann anhand eines Vergleichs der Softwareauslieferung von Flickr und Microsoft erläutert werden (Abb.5):



Abbildung 5: Release History Microsoft vs. Flickr [5]


Microsoft benötigt für die Weiterentwicklung bzw. Auslieferung seiner Software weitaus mehr Zeit als der Webservice Flickr, denn es kann diese nicht in einem Beta-Zustand verkaufen und dann mit den Kunden weiterentwickeln, wie es im Internet der Fall ist. Vielmehr müssen diese Systeme bei der Auslieferung theoretisch die vollständige Funktionalität anbieten, die im Vorfeld angekündigt und bezahlt worden ist. Des Weiteren kann bei Systemen, die serverseitig lagern, der Updateprozess schneller bewerkstelligt werden. Bei einem fehlerhaften Update bzw. wenn dieses nicht die gewünschte Akzeptanz beim Nutzer erreicht, kann es in wenigen Sekunden wieder vom System genommen und die alte Version zurückgespielt werden. Bei allen Desktop-Anwendungen wissen die Hersteller dagegen nicht, wie die Software durch andere Programme oder Treiber in Mitleidenschaft gezogen bzw. verändert worden ist. Dadurch ist es schwer, ein hundertprozentig funktionierendes Update für eine Version zu liefern. An diesem Punkt müssen Webservices nur auf die Spezifikationen der verschiedenen Browsertypen achten. (Allerdings werden auch hier meist aus Kostengründen nur vorherrschende Programme wie IE oder Mozilla angepasst und Safari-Nutzer sind zum Teil ausgeschlossen [2] [22]).

2.5.5 Lightweight Programming Models

Webservices kann man grob in zwei Kategorien einteilen: Die einen nutzen strenge Formalien wie SOAP (Siehe Kap. 3.6), die anderen verwenden einen einfachen Aufbau mit XML und HTTP à REST (Siehe Kap. 3.6). Die zweite Variante findet bei den Webdesignern eine Verbreitung von 95%. Daraus kann ein Wunsch nach einem einfachen Aufbau von Webservices abgeleitet werden. Als Beispiel sei an dieser Stelle auf Google Maps als „GIS-Lösung“[14] verwiesen, die durch den einfachen Aufbau und die Verwendung von Ajax einen durchschlagenden Erfolg gegenüber schon länger existierenden Web-basierten Kartendiensten wie MapQuest[15] und MapPoint (Microsoft)[16] hatte. Ein weiterer wichtiger Punkt des Lightweight-Programming-Models (LPG) lässt sich hieran demonstrieren: Durch die offene Schnittstelle (API) wird jeder Person die Möglichkeit eröffnet, diese Anwendung zu nutzen und für ihre Zwecke zu verwenden bzw. zu erweitern. Dieser Punkt war bei allen herkömmlichen Anbietern nur mit Hilfe eines förmlichen Vertrages und unter hohem Aufwand möglich. So können neue Arten von lose gekoppelten Diensten entstehen, die sich von der traditionellen Denkweise der IT lösen und dadurch einen grundverschiedenen Aufbau darstellen. Es ist des Weiteren eine Kooperation bei Web Services nach einem „Endnutzer zu Endnutzer“- Prinzip möglich, ohne dass es eine Koordination des Anbieters erfordert. Resultierend aus der Einfachheit von RSS, XML, Ajax, etc. reduzieren sich aber auch die Barrieren der Wiederverwendbarkeit. Folglich sinkt als negativer Effekt auch der Schutz des geistigen Eigentums. Als positiven Effekt muss man aber wiederum das Prinzip der kollektiven Intelligenz sehen (2.5.2), wonach sich ein Webservice schneller zu den Bedürfnissen des Users entwickelt. Damit vollzieht sich bei diesen Anwendungen auch eine Änderung der AGBs[17] von „alle Rechte vorbehalten“ in „einige Rechte vorbehalten“. Als weiterer positiver Effekt ist das Kombinationsprinzip zu nennen, das Folgendes festlegt:

„Wenn bereits alle grundlegenden Services erfolgreich existieren, kann ein neuer Nutzen aus der Kombination dieser gewonnen werden.“

Prinzipiell kann somit angenommen werden, dass Web 2.0-Firmen in Zukunft auch durch die Verbindung von Diensten innovativer und erfolgreicher sein werden als Firmen, die das Web 2.0 nicht nutzen[2] [22].

2.5.6 Multiplattforming

Durch die Entwicklung von Anwendungen in einem Browser, wie es im Web 2.0 gemacht wird, kann zum ersten Mal der Gedanke der Plattformunabhängigkeit realisiert werden. Durch das Internet als Trägermedium und entsprechende Clients können mehr Menschen auf verschieden Geräten erreicht werden als seinerzeit durch die Entwicklung von Java-Anwendungen gehofft wurde. Schon Dave Stutz[18], ein ehemaliger Microsoft- Entwickler betonte: “Nützliche Software, die über die Grenzen einzelner Geräte hinaus geschrieben wurde, wird die hohe Marge für lange Zeit beherrschen“.

Es muss bei einem Webservice also nicht immer ein Browser als Anzeigemedium dienen. Die Entwicklung von Services in Widgets oder in alternativen Clients wie Handy/PDA gewinnen zurzeit immer mehr an Popularität. Diese sind prinzipiell von der gleichen Struktur und ihre Anwendungs- und Nutzerdaten werden meist auch serverseitig bezogen. Resultierend daraus sind auch verstärkt Bemühungen unternommen worden, Services von Anfang an als verteiltes System zu implementieren. Durch diese Einbindung von Geräten werden völlig neue Anwendungsmöglichkeiten sichtbar, besonders wenn man daran denkt, dass diese Clients in Zukunft nicht nur in der Lage sein werden zu konsumieren, sondern auch Daten für andere Dienste oder Personen bereitzustellen (zu produzieren), getreu dem Motto „Jeder Sender ist auch ein Empfänger“. Interessant ist dieser Punkt auch für die Idee des Bürgerjournalismus [2] [22].

2.5.7 Benutzerführung

Webdienste waren in der Vergangenheit kaum mit den Desktopanwendungen vergleichbar. Durch die Verfügbarkeit schnellerer Anbindungen und die Nutzung von Ajax können im Web 2.0 nun diese Benutzerführungen (Rich User Experience) bereitgestellt werden. Dadurch stehen die Anwendungen im Web denen vom Desktop um nichts mehr nach. Im Gegenteil, sie bieten Vorteile, die mit einer Desktopanwendung nur schwer zu realisieren sind. Zusätzlich liegen diese vollständig mit den Userdaten auf dem Server, was zur Folge hat, dass kein Speicher auf einem lokalen Gerät benötigt wird. Des Weiteren gibt es auch viel versprechende Entwicklungen im Bereich des „Office im Web“. So können z.B. mit Hilfe des Textverarbeitungsservices Writely[19] mehrere Menschen an einer Textversion gleichzeitig arbeiten und alle gängigen Formate im- und exportieren. Die Firma Ajax13.com (Abbildung 6) hat die vier wichtigsten Komponenten des Office Paketes bereits in einer interessanten Betaversion vollständig im Browser implementiert bzw. in ihrer Funktionalität nachempfunden. Zum Teil werden diese Tools – wie z.B. Thinkfree[20] – auch kostenlos und mit freiem Speicher (in diesem Falle 1GB) angeboten. Diese Art von Programmen sind zwar noch nicht mit einem vollständigen Desktopprogramm wie Word oder Exel vergleichbar, sie sind aber für die meisten Zwecke ausreichend und bieten, wie Writely, Funktionen die in einer lokalen Anwendung nur schwer realisierbar sind. Darüberhinaus werden die ständig weiterentwickelt und verbessert (vgl. 2.5.4). Weitere erfolgsversprechende Re-Implementierungen von Desktopanwendungen sind zum Beispiel der Terminkalenderservice „Google Gmail[21]“, der Bildbearbeitungsservice Neximage[22] oder der MP3-Player Ajax Tunes[23] [2] [22].





Abbildung 6: Ajax Office Implementierung [8]


3 Technologien und Verhaltensweisen

Mit Bezugnahme auf die oben erläuterten Prinzipien wird im folgenden Abschnitt kurz auf die genannten Technologien und Verhaltensweisen eingegangen, die im Zusammenhang mit Web 2.0 genannt werden oder Verwendung finden. Wie bereits erwähnt, ist es keine neue Technologie, die für den plötzlichen Erfolg des Webs verantwortlich ist, denn die meisten der verwendeten Techniken sind schon seit längerer Zeit bekannt. Vielmehr ist es ihr gleichzeitiges Auftreten in Verbindung mit der jetzt verfügbaren Bandbreite des Internet. Dazu kommen Wikis, Blogs und „Soziale Netzwerke“, die ihren Anteil am Web 2.0 haben.

3.1 Ajax

Ajax leistet einen der wichtigsten Beiträge für das Web 2.0. Mancher behauptet gar, Ajax sei Web 2.0. Es bietet aber eher interessante Möglichkeiten, um eine neue Browseroberfläche zu schaffen, worauf im folgenden Abschnitt eingegangen wird. Ajax ist ein Akronym für „asynchrone Javascript and XML“. Durch diese Kombination können Seiteninhalte verändert oder neu angefordert werden, ohne die Seite neu laden zu müssen. Dadurch ist es möglich, eine desktopähnliche Oberfläche in den Browser zu implementieren.

3.1.1 Geschichte

Die Technologien, die sich hinter Ajax verbergen, gibt es in ähnlicher Form schon seit 1998. Hier ist vor allem an die von Microsoft entwickelte Remote-Scripting[24]-Komponente zu denken, die es ermöglichte, clientseitig eine HTTP-Anfrage abzuschicken. Diese Technik wurde im Microsoft Exchange Server integriert und fand später (1999) auch im Internet Explorer 4.0 Verwendung. Die Bezeichnung „Ajax“ prägte Jesse James Garrett[25] mit seinem im Februar veröffentlichten Artikel, in dem er die Bezeichnung „Ajax“ in Verbindung mit dem XMLHTTP-Request vorstellte. Warum aber wurde diese Technik trotz ihrer erstmaligen Implementierung durch Microsoft 1999 erst mehrere Jahre später effektiv genutzt? Hier ist zum einen an die fehlende Einbindung in andere Browser zu denken – da das XMLHTTP-Request-Objekt war eine Microsoft-Implementierung – zum anderen an die gravierenden Sicherheitsmängel, die dazu führten, dass nicht nur Dateien oder Inhalte vom Server geladen wurden, sondern auch die Möglichkeit bestand, lokale Daten des Benutzers auszulesen und zu verändern. Zudem fand DHTML[26] bis 2001 nur für kleine Animationen Verwendung und wurde wegen fehlender Leistungsfähigkeit und mangelnder Einheitlichkeit in den vorherrschenden Browsern durch Flash abgelöst. Javascript stürzte häufig ab und war wegen langsamer Hardware auch nicht zu komplizierten Anwendungen fähig. Da jetzt diese Probleme unter anderem durch den W3C Standard, schnellere Geräte und die Implementierung von Javascript in einer Sandbox behoben sind, wird die Verwendung dieser Technologie wieder interessant und wird wohl auch für die Webentwicklung in der Zukunft ein interessanter Baustein sein [14].

3.1.2 Vorteile

Der Vorteil von Ajax ist, dass Seiten, auf denen Veränderungen stattfinden, nicht in einem neuen Browserfenster geladen werden müssen. Somit kann eine desktopähnliche Oberfläche geschaffen werden, auf der Veränderungen sofort sichtbar sind und die Bearbeitung somit schneller vonstatten geht. Darüber hinaus wird teilweise die Serverlast verringert, da nicht immer die komplette Seite neu übertragen werden muss. Dieses kann aber nicht für alle Anwendungen verallgemeinert werden, denn durch Ajax werden die Webseiten weitaus komplexer und umfangreicher und verursachen damit gleichzeitig mehr Serverlast. Ein weiterer Vorteil ist die Unterstützung von mobilen Endgeräten, auf denen aufgrund von Speichermangel nicht alle Programme und Daten installiert werden können. Mit Ajax wird einfach ein Word- oder Photoshopdokument im Browser geladen und es kann damit gearbeitet werden. Darüber besteht in Ajax nicht die Notwendigkeit, Plugins zu installieren, weil alle Komponenten bereits vorhanden sind.

3.1.3 Nachteile

Ajax ist nur verwendbar wenn auch Javascript im Browser aktiviert bzw. implementiert ist. Gleichzeitig ist eine Ajaxanwendung in ihrer Programmierung und Wartung deutlich aufwendiger als normale Webseiten und somit auf wenige Anwendungen beschränkt. Bei dynamischer Änderung des Layouts besteht auch die Gefahr, dass die Trennung von Struktur (XHTML) und Design (CSS) nicht mehr gegeben ist. Ein weiterer negativer Punkt ist, dass Zurück- und Vorwärtsbuttons in einer Standard Ajax-Anwendung nicht funktionieren, da diese auf Änderungen in der URL beruhen. Diese Funktionen können zusätzlich implementiert werden, dies ist aber gegenwärtig noch eine sehr komplizierte Prozedur. Die Webseiten können nur in ihrem Ausgangszustand als Lesezeichen im Browser hinterlegt werden, was dazu führt, dass Folgeseiten schlechter wieder zu finden sind. Ebenso ist Ajax nicht mit dem Grundsatz der Barrierefreiheit im Netz zu vereinbaren, da dieser verlangt, dass Seiten auch ohne Javascript zu bedienen sein müssen. Suchmaschinen können sich nur auf den statischen Inhalt der Seiten beziehen und nicht auf die mit Ajax erstellten dynamischen Seitenteile. Dies kann auch nur mit zusätzlichem Programmieraufwand überwunden werden. Drei Möglichkeiten können hier unterschieden werden:

Lightweight Indexing: Die Indizierung erfolg ausschließlich über Meta-Tags und/oder Überschriften, es werden keine Änderungen im Programmcode vorgenommen.

Extra Link Strategy: Für die Indizierung werden unsichtbare Links auf der Webseite eingebaut, denen die Suchroboter folgen können.

Secondary Site Strategy: Es wird eine vom Inhalt her identische Seite mit auf den Webserver gelegt, welche die Suchroboter indizieren können. Dieser Ansatz kann auch für das Problem der barrierefreien Webseiten als Lösungsansatz dienen.

Die Serverlast wird dabei nicht in jedem Fall verringert, weil bei komplexen Services immer wieder Anfragen auf der Suche nach Änderungen an den Server geschickt werden. Die Latenzzeiten[27] sind je nach Geschwindigkeit der Internetverbindung und Serverlast unterschiedlich und der User muss mit Statusanzeigen über den Zustand der Applikation informiert werden [14].

3.1.4 Aufbau von Ajax

Wie der Name Ajax (Asynchrones Javascript and XML) schon erkennen lässt, benötigt es zwingend Javascript. Es wird für den asynchronen Zugriff auf Objekte des Dokumentenbaumes, kurz DOM (Document Object Model), verwendet. Das heißt, es können zur Laufzeit neue Elemente hinzugefügt oder verändert werden. Für diesen Vorgang muss, wie erwähnt, die Seite nicht noch einmal neu geladen werden. Im Prinzip besteht es aus einer Client- und einer Serverkomponente (Abbildung 7). Im Client ist die Ajax-Engine für die Verarbeitung und die Anzeige zuständig. Des Weiteren bezieht sie bei Bedarf neue Daten vom Server und fügt diese asynchron auf Basis des Dokumentenbaumes in die Seite ein (vgl. 3.1.5). Auf dem Server ist die eigentliche Programm-Logik implementiert, die auf die Anfrage der Client-Anwendung reagiert und neue Daten und Elemente an diese zurückgibt. Aufgrund der Sicherheitseinstellungen der Browser ist aber ein XSS[28] nicht vorgesehen. Daraus resultierend muss der Webserver auch Daten von anderen Servern einbinden, um diese dem Client zur Verfügung zu stellen. Dadurch soll verhindert werden, dass sich jemand in die Ajax-Verbindung einklinkt und seine eigenen Daten an den Client sendet [21] [24] [14].



Abbildung 7: Client- Serververbindung einer Ajax Anwendung [19]


3.1.5 DOM

DOM (Document Object Model) ist nach dem W3C Standard ein plattformunabhängiger Zugriff auf Elemente eines XHTML-Dokumentenbaums. Mit dem DOM ist der erste Grundstein der Ajax-Programmierung gelegt, denn dadurch ist es möglich, Elemente aus dem Dokumentenbaum der Seite auszulesen und dynamisch zu verändern, ohne dass diese neu geladen werden müssen. Als Basis für diese Schnittstelle dient Javascript als Standard, aber natürlich finden auch andere Scriptsprachen bei der Veränderung von Objekten aus dem Dokumentenbaum Anwendung.

Funktionsweise:

Um die Funktionsweise zu erläutern, ist hier ein kurzes Beispiel für einen Dokumentenbaum aus dem DOM- Inspektor des Firefox (Abbildung 8) dargelegt, es stammt von der Google Startseite. Dieses kann in Firefox unter dem Menüpunkt „DOM“ nachvollzogen werden. Man erkennt, wie die einzelnen Elemente eine sogenannte Mutter/Kind Beziehung miteinander eingehen und in einer Baumstruktur aufgebaut sind [21] [24].



Abbildung 8: Aufbau DOM Struktur


Zum näheren Verständnis soll zunächst erläutern werden, was der Unterschied zwischen den einzelnen Knoten in der Baumstruktur ist.

- Der Mutterknoten stellt die gesamte Baumstruktur dar. - Ein Dokumentfragmentknoten stellt einen Teil der Baumstruktur dar. - Ein Elementknoten entspricht einem Element in HTML oder XML. - Ein Attributknoten entspricht einem Attribut in HTML oder XML. - Ein Textknoten stellt den textuellen Inhalt eines Elements oder Attributs dar.

Verarbeitung eines DOM-Objektes: Im ersten Schritt wird ein bestehendes Dokument durch das Programm eingelesen und ein Dokument-Objekt erzeugt. Anhand dieses Objekts kann mittels der Methoden der API auf die Inhalte, Struktur und Darstellung zugegriffen werden. Insbesondere erlaubt das DOM die Navigation zwischen den einzelnen Knoten eines Dokuments, das Erzeugen, Verschieben und Löschen von Knoten sowie das Auslesen, Ändern und Löschen von Textinhalten. Am Ende der Verarbeitung kann aus dem Dokument-Objekt durch so genannte „Serialisierung“ ein neues XML- oder HTML-Dokument generiert werden, wie in Abbildung 9 verdeutlicht wird. Dabei ist HTML der Mutterknoten, Head und Body sind Kindknoten, die ebenfalls wieder Kindknoten besitzen können [21] [24].



Abbildung 9: Suche im DOM


Somit kann man die gesamte Webseite (Dokumentenbaum) durchlaufen und alle Knoten (Elemente) dargestellen bzw. erreicht werden. Diese können nun verändert und neu eingefügt werden [14].

3.1.6 XMLHttp Request Objekt

Ein XMLHTTP-Request-Objekt ist eine Schnittstelle zum Übertragen von Daten über das HTTP- Protokoll. Eine Anfrage kann z.B. als normaler String oder XML zurückgegeben werden. Somit ist es einer der wichtigsten Eckpfeiler der Ajax-Kommunikation. Erst mit diesem Objekt ist es möglich, Daten von einem Webserver zum Client zu schicken, ohne die Seite neu laden zu müssen. In der Vergangenheit wurden auch IFrames[29] dazu genutzt, Daten asynchron vom Server zu laden. Diese haben sich aber als nicht so leistungsfähig erwiesen und dem XMLHTTP-Request das Feld überlassen. Bei der Implementierung ist zwischen den Browsern wie Mozilla, Explorer, Safari etc. mit einer Objekterkennung[30] zu unterscheiden [21].

3.2 JSON (Java Script Object Notation)

JSON ist eine Technik zum Austausch von Informationen zwischen Anwendungen jeglicher Art. Es gibt Implementierungen für C, C++, Java, JavaScript, PHP, Python, Ruby und Smalltalk. JSON wird wie XML zum Datenaustausch verwendet und hat einige Vorteile: Zum einen produziert JSON durch seine kompakte Kodierung weniger Datenoverhead. Zum anderen hat er bei der Ajaxprogrammierung den Vorteil, dass ein zu übertragenes Objekt, z.B. aus einer Datenbank, nicht in eine String verpackt werden muss, um es in Javascript wieder zu zerhacken und die einzelnen Elemente des Objektes aufzuteilen und zuzuordnen. Mit JSON muss das Objekt zwar auch in eine Zeichenkette verpackt werden, kann aber mit einfachen Funktionen für Javascript in ein Objekt zurückverwandelt werden. Somit können auch ganze Arrays mit Objekten übertragen und verarbeitet werden. Diese Art der Übertragung findet häufig in Bereichen Verwendung, bei denen auf Geschwindigkeit und Datenvolumen Wert gelegt wird [30].

3.3 RSS/Atom

3.3.1 RSS

RSS (Abkürzungfür Rich Site Summary[31]) ist ein XML-basiertes Dateiformat zum Auslesen und Übertragen von Inhalten (content) einer Webseite. Der Inhalt wird durch so genannte Aggregatoren gesammelt und dem User aufbereitet wieder zur Verfügung gestellt. Die Art der Aufbereitung ist vom Benutzer konfigurierbar, so dass er sich die gewünschten Inhalte selbst zusammenstellen kann. Das hat den Vorteil, dass nicht jede Webseite einzeln besucht werden muss, um nachzusehen, ob es dort etwas Neues gibt. Mit RSS bedarf es keiner Unterscheidung zwischen Bild- oder Layoutinformationen und Inhalt, weil beides via RSS in einem standardisierten Format vorliegt. Dadurch eignet RSS sich auch für die maschinelle Weiterverarbeitung, denn es ermöglicht beispielsweise die automatische Einbindung von Texten einer Webseite in eine andere Webseite. Entwickelt wurde dieses System ursprünglich für Portalseiten, bei denen sich User von diversen Quellen wie Blogs oder Nachrichtenseiten eine persönliche Infoseite zusammenstellen konnten. Es gibt von RSS verschiedene Formate mit unterschiedlichen Eigenschaften, die mit der Zeit entwickelt wurden. Der Vorreiter war das 1997 von Dave Winer[32] entwickelte ScriptingNews2XML- Format, welches für sein Radio-Userland[33] entwickelt wurde [29].

RSS selbst kam in der Version 0.9 (zwei Wochen später 0.91), von myNetscape.com[34] entwickelt, auf den Markt und war lange Zeit das gebräuchlichste Anwendungsformat.

Parallel wurde das RSS 1.0 Format entwickelt, welches mit einer offiziellen DTD[35] und RDF (vgl. 3.5.1) ausgeliefert wurde. Damit sollte RSS um die Möglichkeiten des Semantic Webs erweitert werden. Dieses war aber so komplex, dass es selten zur Anwendung kam. Mit der sich entwickelnden Idee, Audio- und Videoinhalte im Netz zu verbreiten, wurde von Dave Winer 2002 RSS 2.0 vorgestellt. Dies beinhaltete in den Enclosures[36] alle Formen binärer Dateien, so dass auch Audio- und Videoinhalte transportiert werden konnten. Dieses Rechte an diesem Format wurden von Dave Winer der Harvard University übertragen, wodurch eine freie Verfügbarkeit in der Zukunft sichergestellt wird [18].

—-  This is the caption

Mit diesem Zeichen wird auf verschieden Webseiten auf die Möglichkeit aufmerksam gemacht, einen RSS Feed (meist RSS 2.0) zu abonnieren. Dieser wird einem automatisch zugesendet und in einem Feed-Reader dargestellt oder in die eigene Webseite eingebunden.



3.3.2 Atom

Die Spezifikationen von RSS 2.0 sind an einigen Stellen teilweise nicht ganz eindeutig. Aus diesem Grunde entwickelte eine Gruppe um Mark Pilgrim[37] eine eigene Syndizierungsspezifikation namens „Atom“. Atom ist ein Weblog-Publishing Format, das nicht unbedingt als Nachfolger für RSS zu sehen ist, sondern vielmehr versucht, alle unterschiedlichen RSS- Formate zu verknüpfen und neue Elemente mit einzupflegen. In Atom wurden Inhalt tragende Elemente eingefügt, wodurch genau festgelegt werden kann, um welchen Art von Inhalt es sich handelt . Atom ist als Publishing- und Archivierungsformat entwickelt worden und legt die Informationen im XML-Format[18] ab.

3.3.3 Geotagging

Geotagging ist eine spezielle Art des Taggings und wird an dieser Stelle zusätzlich erwähnt, weil es für die Testanwendung relevant ist. GeoTagging oder Geocoding (Georeferenzierung) ist ein Vorgang, mit dem Medien wie Bilder, Filme, Blogs oder andere Informationen mit Koordinaten versehen werden können. Die Koordinaten werden als Metadaten zur betreffenden Information abgelegt. So erweitert man die Metadaten um eine geografische Komponente und kann die Information realen Punkten auf der Erde zuordnen. Diese Informationen werden z.B. in einem Weblog, Wiki oder anderweitig eingetragen, um so eine bessere Verbindung zur Information herstellen zu können. Mit GeoRSS wiederum ist es möglich, Geodaten als RSS-Feed zu übertragen und auszuwerten (Abbildung 10).



Abbildung 10: Schockwellenreiter.de [49]


3.4 Folksonomy und Ontology

Im Zusammenhang mit Web 2.0 werden häufig die Begriffe Ontology und Folksonomy kontrovers diskutiert. Grund hierfür ist die Frage, wie Informationen im Internet oder in Anwendungen mit Metadaten versehen werden, seien es nun Blogeinträge, Fotos, Videos oder PDF-Dateien. Im Wesentlichen geht es hier aber um eine Standpunktfrage, denn beide Technologien haben ihre Vor- und Nachteile, wie die folgenden Definitionen verdeutlichen sollen.

3.4.1 Ontology

Als Ontologie wird ein Zweig der Philosophie bezeichnet, der bereits in der griechischen Antike diskutiert wurde: Die Frage nach dem Sein. Philosophen wie Platon teilten die Dinge der Welt in Hierarchien ein und versuchten diese zu definieren oder zu beschreiben. Schon hier findet sich also der Grundsatz „alles Existierende in ein vordefiniertes Muster (Liste) einzuteilen und die Wahrheit über Realität zu erforschen“. In der Informatik geht es im Vergleich zum philosophischen Ansatz um Datenbankmodellierung oder künstliche Intelligenz, bei der eine Liste von Definitionen für einen bestimmten Anwendungsfall entwickelt wird [9]. In diesem Zusammenhang wird auch häufig die Definition „ein formales Modell eines Wissensraumes“ angewendet [12]. Dabei wird ein Netz von Hierarchien mit logischen Beziehungen untereinander festgelegt. Diese Beziehungen sind speziell von einer Arbeitsgruppe oder Ähnlichem zugewiesen. Vergleichend dazu wird bei der Taxonomy[38] eine monohierarchische Klassifizierung verwendet. Diese Informationen (Ontology), die mit einer logischen Beziehung verknüpft sind, werden als semantisch erzeugt definiert. Für die Ontologie gibt es verschiedene Komponenten. Die Wichtigste für Webanwendungen ist die Annotation[39] von Webseiten durch OWL[40] oder seinen Vorgänger RDF[41]. Dadurch soll die Qualität von Informationen im Netz und die Zusammenarbeit zwischen Mensch und Maschine so verbessert werden, dass es zu einer verbesserten Automatisierung bei der Verarbeitung von Daten bzw. Webinhalten kommt [10].

Semantic Web:

Diese Erweiterung der Datenbeschreibung wird auch als „Semantic Web“ bezeichnet. Es ist eine Erweiterung des eigentlichen Webs. Dabei wird einer Information eine eindeutige Bedeutung zugeordnet. Der Dublin Core[42] ist z.B. eine dieser Gemeinschaften, die RDF-Schema-Metadatenmodelle für die Beschreibung von Informationen entwerfen. Aber es geht nicht nur um die Zuordnung, sondern vielmehr um die Interpretation von Informationen. Wenn heutzutage ein Text im Internet gesucht wird, werden bestimmte Textstellen ausgewertet und angezeigt. Die Interpretation der Daten und die Sortierung nach Relevantem kann von Computern nur bedingt übernommen werden, dazu ist immer noch ein Mensch notwendig. Im Semantischen Web allerdings werden diese Daten von den Maschinen interpretiert, verarbeitet und transformiert. Es geht sogar soweit, dass die Computer auf den Daten operieren und diese wieder auf sinnvolle Art und Weise zusammensetzen [15]. Diese Komplexität setzt, wie schon erwähnt, eine Expertenkommission voraus, die in zeitaufwendiger Arbeit das Vokabular für die Maschinen festlegt. Diese Vorgehensweise hat bis zum heutigen Tage aber zu keinem effektiven Ergebnis geführt, da man sich bis heute auf kein einheitliches Vokabular bei der Bezeichnung von Daten einigen konnte. Aus diesem Grunde hat sich in letzter Zeit auch eher der alternative Ansatz des Web 2.0 durchgesetzt , der als Folksonomy bezeichnet wird [13] [31].

3.4.2 Folksonomy

Gemeinschaftliches Indexieren (Free Tagging) ist eine Form des Bezeichnens von Blogeinträgen, Fotos, Videos, Artikeln oder Ähnlichem durch zahlreiche Nutzer und wird mit Folksonomy bezeichnet. Der Begriff setzt sich aus dem engl. Wort „folk“ (Leute) und „taxonomy“ (sprachwissenschaftliche Klassifikation von Gegenständen) zusammen und wird auf Thomas Vander Wal[43] zurückgeführt. Anwendung fand er zum ersten Mal bei del.ici.ous im Jahre 2003. Die Art der Indexierung unterliegt keinen Kontrollen und keinen Regeln, es wird davon ausgegangen, dass die User sich selbst Tags wählen, die dem Inhalt entsprechen. Im Zusammenhang mit anderen Tags von anderen Usern ergeben sie ein Schlagwortsystem, welches sich optimal für die Suche des Inhalts eignet. Diese Zusammenfassung von Tags wird auch als Folksonomy bezeichnet. Als Vorteil ist klar die breite Masse an Benutzern zu nennen, die sich mit den Inhalten beschäftigen. Dadurch entsteht ein größerer Überblick und Zusammenhänge werden ersichtlich, die dem einzelnen Benutzer vielleicht verborgen geblieben wären. Die Benutzer erziehen sich dabei selbst untereinander und verwenden die Tags, die populär und sinnvoll sind – aus dem einfachen Grunde, dass ihre getaggten Inhalte von vielen Usern gefunden und gelesen werden sollen. Zusätzlich wird der Inhalt von anderen Usern weitergetaggt, was dazu führt, dass der Inhalt noch besser bezeichnet und gefunden werden kann [9].

Vergleich von Ontology und Folksonomy:

Beide Konzepte haben ihre Vor- und Nachteile, wie in Abbildung 11 zu sehen ist. Der entscheidende Punkt ist aber, dass Folksonomy billiger, schneller und einfacher zu realisieren ist. Dafür weist die Ontology eine sehr hohe Präzision auf. Diese ist zwar teuer, aber die einzige Möglichkeit, um verlässliche Verbindlichkeiten zu schaffen, wie sie durch Folksonomy nur schwer realisierbar sind, da man sich immer auf die Meinung der breiten Masse verlassen muss.



Abbildung 11: Vergleich Folksonomy und Ontology [9]


Diese hohe Präzision wird aber zurzeit noch nicht von den Anwendern gefordert und wird daher erst in späteren komplexeren Implementierungen Anwendung finden (vergleichend Ajax OS, Web 3.0), so dass zurzeit Folksonomy das Mittel der Wahl ist. Hierfür spricht auch der sogenannte „Desire Lines[44]“ Ansatz, der besagt, dass von den Usern bereitgestelltes Vokabular immer die derzeitige Terminologie und Wortwahl der Benutzer reflektiert und somit einen aktuellen Stand ihrer Bedürfnisse darstellt. Bei der Ontology müssten diese Aktualisierungen und Erweiterungen immer durch eine Expertenkommission festgelegt und hinzugefügt werden. Dieser Prozess ist zeit- und geldaufwendig und wird in der Aktualität immer der Folksonomy nachstehen. Auf Dauer wird man dennoch eine semantische Implementierung bei der Beschreibung von Webinhalten brauchen, da man sich bei komplexen Anwendungen nicht immer auf das Urteil von anderen Usern verlassen kann [9][13].

3.5 Weblog/Wiki/Social Software

3.5.1 Weblogs

Weblog ist ein Newsletter, der es möglich macht, zu jeder Zeit über verschiedene Themen Artikel zu veröffentlichen, die von allen Usern gewertet (Kommentare) oder in ihre eigenen Weblogs übernommen werden können. Sie entstanden als ursprüngliche Linksammlungen, die Ausflüge in das Internet aufzeichnen sollten. Daraus entstand das erste Publikationsmedium im Internet, mit dem es ähnlich einem CMS einfach und schnell möglich ist, Informationen datumsspezifisch, also wie eine Tageszeitung, zu veröffentlichen. Weblogs haben entsprechend häufig ein klassisches dreispaltiges Layout, wobei der Mittelteil für die regelmäßigen Informationen und die beiden Außenspalten für Archiv und Werbung Verwendung finden. Für die starke Verbreitung von Weblogs tragen Techniken wie RSS, Ping und Trackbackping zusätzlich bei (vgl.3.10-3.11). Man muss Weblog nicht nur als Tagebuch oder Newsletter verwenden. Im MPIWG wird z.B. der von Jörg Kantel angepasste Manila[45]-Weblog für das Support Ticketsystem bzw. die EDV Verwaltung (Abbildung 13) genutzt [7].



Abbildung 12: Blog für die Arbeitsaufteilung in der EDV des MPIWG


3.5.1.1 Ping

Ping wurde entwickelt, um Informationen, die auf einer Seite eines Weblogs neu vorhanden sind, dem restlichen Internet bekannt zu machen. Ein Weblog z.B. setzt einen Ping ab, wenn etwas Neues auf einer Webseite eingestellt ist. In diesem Moment können Spider die Seite direkt anlaufen und die neuen Informationen im RSS/ATOM Format aufsammeln und über Community- Server verteilen. Dadurch wird eine Begrenzung von Spideraktivität im Netz erreicht, weil diese nicht ständig alle Webseiten anlaufen müssen, um neue Informationen zu suchen.

3.5.1.2 Trackbackping

Trackbackping setzt einen Ping an den Eigentümer eines Eintrages ab, wenn dieser Content auf einem anderen Weblog kommentiert wurde, um so dem Eigentümer der Information mitzuteilen, was mit seiner Information im Netz passiert und wer sie wie kommentiert.

3.5.2 Wikis

Ein Wiki, auch WikiWiki und WikiWeb genannt, ist eine im World Wide Web verfügbare Seitensammlung, die von den Benutzern nicht nur gelesen, sondern auch online geändert werden kann. Wikis ähneln damit Content-Management-Systemen. Der Name stammt von wikiwiki, dem Hawaiianischen Wort für „schnell“. Wie bei Hypertexten üblich, sind die einzelnen Seiten und Artikel eines Wikis durch Querverweise (Links) miteinander verbunden. Dazu gibt es in der Regel eine Bearbeitungsfunktion, die ein Eingabefenster öffnet, in dem der Text des Artikels bearbeitet werden kann [16]. Wikis werden als eine Art Lexikon verwendet und bei den unterschiedlichsten Anwendungen eingesetzt, meist als Projekt-Wiki für die Koordination und den Austausch getrennt arbeitender Projektgruppen oder für die Bereitstellung und Aufbereitung von erarbeitetem Wissen (Abbildung 12). Es gibt zurzeit eine Vielzahl von angebotenen Wiki-Engines. Die Komplexeste ist wohl mit Abstand die Mediawiki-Implementierung des Wikipedia-Projektes. Diese bietet von allen die meisten Anwendungsmöglichkeiten und lässt sich auch ohne Probleme zu einem Cluster erweitern. Dazu bringt sie allerdings hohe Systemanforderungen und eine schwierige Installation mit sich. Aus diesem Grunde kann für einfachere Anforderungen, wie projektbezogene Wikis, das etwas simpler gehaltene Dokuwiki oder Twiki verwendet werden. Bei der Implementierung eines Wikis sollte auf die Interwikifähigkeit geachtet werden, das eine Vernetzung von Wikis bzw. Artikeln untereinander ermöglicht wird [17] [7].



Abbildung 13: Dokuwiki


3.5.3 Social Software/ Social Network/ Community-Server

Unter „Social Software“ versteht man Plattformen oder Anwendungen, die das Kommunikationsverhalten ihrer Nutzer verändern sollen. Dabei gehen sie weit über die eigentliche Funktion von Communityservern für die Updatesuche und Bereitstellung von Weblog-Inhalten hinaus. Gute Beispiele dafür sind Xing[46] oder mySpace[47], aber auch Flickr[48] oder Youtube[49].

3.6 Mashup und Services

Ein Mashup ist eine Webanwendung, die auf sinnvolle Weise Daten aus verschiedenen Quellen miteinander verbindet, um somit einen neuen Webservice zu schaffen. Meist werden diese Verknüpfungen über offenen Schnittstellen (API[50]) realisiert. Diese Informationen aus den verschiedenen Übertragungsarten werden dann meist mit Scriptsprachen oder Ajax in die Webseite eingebunden. Dadurch können mit wenigen Schritten komplette Anwendungen im Netz fertig gestellt werden, unter dem Leitsatz: „Wenn alles Greifbare entwickelt und erfolgreich benutzt wird, kann durch Kombination von vorhandenem ein neuer Mehrwert erreicht werden“. Die am meisten verwendeten Protokolle werden im Folgenden besprochen.

3.6.1 XML- RPC

Diese Methode wurde von Dave Winer entwickelt. Die Abkürzung steht für „Extensible Markup Language Remote Procedure Call“. Für den Transport wird auf HTTP und für die Darstellung der übertragenen Daten auf XML zurückgegriffen. XML-RPC kann als Vorgänger von SOAP betrachten werden, ist aber wesentlich schlanker und weitaus einfacher in der Implementierung [34] [32].

3.6.2 SOAP (Simple Object Application Protocol)

Diese Übertragungsmethode ist eher für große komplizierte Enterprise-Anwendungen entwickelt worden. Es ist ein XML basiertes RPC-Protokoll, welches meist in Verbindung mit der Webservice Description Language[51] auftritt. Diese erwartet auf eine Nachricht im Gegensatz zu XML-RPC keine direkte Antwort [50].

3.6.3 Rest (Representational State Transfer)

Bei diesem Protokoll werden die Anfragen per Get, Put, Post und Delete verschickt. Die Antworten sind meistens XML oder reiner Text bzw. wie bei JSON ein Javascript Objekt. Der Unterschied zu SOAP ist, dass Informationen über die URL angefordert und per XML oder in einem anderen gewünschten Format zurückgegeben werden.

3.6.4 JSON

JSON ist eine weitere Möglichkeit Daten in einem Mashup zu übertragen und anzuzeigen. Für die genaue Erläuterung sei auf den Punkt 3.2 verwiesen. Zurzeit sind die meisten Mashups aus Googlemaps, YouTube oder Flickr zusammengesetzt (Abbildung 14) [7].




Abbildung 14: Google Maps Mashup Beispiele


4 Web 2.0 und der Arbeitsplatz des Wissenschaftlers

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.

4.1 Arbeit des Wissenschaftlers

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])

4.2 Web 2.0 als Werkzeug (Implementierung)

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.

4.3 Arbeitsmodule

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?

4.4 Open Accesss

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.

4.4.1 Vorteile

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.

4.4.2 Nachteile

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].

5 Beispielanwendung

In den folgenden Beispielapplikationen wird ein Teil der zuvor beschriebenen Arbeitsumgebung (Wissenschaftlerarbeitsplatz) entwickelt. Bei diesem Prozess sollen die Anwendungsmöglichkeiten des Web 2.0 respektive des GIS-Webservice am Beispiel der Ausgrabungsstätten von Ur, Uruk und Nimrut im Irak evaluiert werden. Für die Bearbeitung der gestellten Aufgaben wurden einige Beispieldaten vom CDLI- Projekt ausgewählt und testweise implementiert. In diesem Fall wurden die Informationen in einem Filesystem und als Mashup bei Flickr hinterlegt, da zum Projektzeitpunkt kein Zugriff auf die CDLI-Datenbanken bestand. In dieser Anwendung sollen die zuvor erwähnten alten Städte unter zu Hilfenahme von Satellitenkarten visualisiert und mit Ausgrabungs- und Fundplänen verknüpft werden.

5.1 Untersuchung Webmapping Tools

Für die Beispielanwendung wurden einige Webmapping bzw. Geocoding Tools untersucht. Im Vorfeld der Untersuchung wurden in Zusammenarbeit mit Peter Damerow (MPIWG Berlin) und Jacob Dahl (CDLI Kalifornien) einige grundsätzliche Bedürfnisse und Funktionen definiert, die für die Arbeit des CDLI einen Mehrwert in ihren Arbeitsprozessen darstellen.

Zunächst wurde überprüft, welche Qualität Geocoding Tools bieten, die eine Visualisierung erlauben. Auf Basis dieser Erkenntnisse soll eingeschätzt werden, mit welchem Tool die Visualisierung am effektivsten ist und in welchem Maße diese stattfindet. In einem weiteren Schritt wurde untersucht, in welchen Datenformaten die Inhalte hinterlegt werden und ob diese auch in lizenzfreie Formate umgewandelt werden können. Auf Basis der Formate fand eine Evaluierung für die Erstellung, Editierung und Verteilung von Geo- und ihren Metadaten in einer späteren Anwendung statt. Nach Klärung der Datenverteilung wurde die Einbeziehung von dreidimensionalen Objekten und die Berechnung der Polygone und die Größe der Texturen bzw. der Overlay auf den Objekten und auf dem Kartenmaterial evaluiert.

Google Earth/Maps:

Google Earth und Maps besitzen durch den Aufkauf der Firma Keyhole[75] und deren Arbeit für den Geheimdienst der USA bzw. den vergangenen Krieg gegen den Irak die besten Satellitenbilder in diesem Bereich. Diese können in Google Earth (Desktop Client) und Google Maps (Browser Client) benutzt werden. Für die eigene Browser-Entwicklung steht eine umfangreiche API zu Verfügung. Diese kann auch in andere Programme wie Widgets eingebunden werden. Darüber hinaus bieten diese Applikationen ein eigens entwickeltes Geo XML Format (KML/KMZ) für die Speicherung von Geodaten. Der Datensatz beruft sich zurzeit auf 150 TByte an Kartenmaterial, welches stetig erneuert und erweitert wird. Diese Daten sind im Schnitt zwischen 2 Monaten und 3 Jahren alt und beinhalten Überflug- und Satellitenbilder mit einer Auflösung von bis zu 30 cm pro Pixel.

Yahoo Maps:

Auch Yahoo[76] entwickelte einen eigenen Webmapping-Service. Dieser richtet sich allerdings mehr an den amerikanischen Markt. Er verwendet schlechtere Satelliten- und Überflugkarten als Google Maps. Es werden zur Zeit nur gute Auflösungen in Großstädten und auf dem amerikanischen Festland angeboten. Die für das CDLI relevanten Gebiete sind, wie in Abbildung 15 zu sehen, in nicht ausreichender Qualität vorhanden. In der Version 3 steht allerdings eine AJAX- und eine Flash- API zur Verfügung, was den Einsatzbereich gegenüber Google Maps erweitert. Mit dieser ist es möglich, in einer Browseranwendung auch dreidimensionale Objekte darzustellen.



Abbildung 15: Yahoo Maps [38]


Microsoft Virtual Earth (Windows live local):

Microsoft[77] versucht ebenso wie Yahoo auf der Erfolgswelle von Google Maps/Earth mit zu schwimmen, jedoch mit mäßigem Erfolg. Es verwendet auch nur in den Großstädten relativ gute Satellitenbilder, bietet aber auch die Eigenschaft, dreidimensionale Modelle darzustellen. Darüber hinaus wird versucht, vom Boden aufgenommene 360° Videostreams einzubinden, um eine realistische Umgebung nachzubilden. Diese ist qualitativ hochwertiger als bei Google Earth, dessen Kartenmaterial nur aus Überflugkarten besteht.



Abbildung 16: Microsoft Local Search [39]


Nasa World Wind:

Die Nasa stellt die einzige Open Source Anwendung mit relativ detailliertem Kartenmaterial zur Verfügung und gilt somit als die einzige echte Alternative zu Google Earth/Maps. Auch hier können dreidimensionale Modelle und Strukturen dargestellt werden. Allerdings besitzt die Nasa nur einen Datensatz von etwa 4,9 TByte. Dafür stehen bei Nasa World Wind auch Karten vom Sternensystem und von Mond, Mars Jupiter und Venus zur Verfügung. Alle Datensätze und die erzeugten Bilder sind ebenfalls Open Source.



Abbildung 17: Nasa World Wind [40]


5.2 Zusammenfassung Google Earth/Maps

Resultierend aus dieser Überprüfung der Webmapping Tools wurde bei der Testimplementierung der Anwendung Google Maps/Earth verwendet, das sich durch seinen Funktionsumfang und die detaillierten Satellitenbilder auszeichnet. Im Folgenden werden alle zurzeit angebotenen Produkte von Google Earth Clients (Standard, Plus, Pro, EC) und Google Maps/API kurz erläutert. Welche Variante bei einer späteren Anwendung im Institut implementiert wird, muss anhand der Projektanforderungen noch einmal genauer spezifiziert werden. Des Weiteren wird kurz auf die geographischen Eigenschaften der Google Earth/Maps Tools eingegangen [25].

5.2.1 Google Earth

Google Earth ist ein freies Desktop Tool zum Erforschen und Erstellen von Geodaten. Mit dieser Anwendung können auf einfachste Weise Geodaten aufgenommen und verarbeitet werden. Der Funktionsumfang reduziert sich allerdings auf minimale Ein- und Ausgabe der Daten. Es können KML/KMZ Dateien erstellt und ex- oder importiert werden.

5.2.2 Google Earth Plus

Google Earth Plus ist eine 20$ teure Erweiterung des Goolge Earth Client’s. Sie beinhaltet Erweiterungen in der Ansicht und der Arbeitsweise. Inbegriffen sind dabei ein verbesserter Netzwerkzugriff und höhere Arbeitsgeschwindigkeit, ein Import von einem GPS-Gerät[78] in Echtzeit (GPS-Tracking) wie Punkte und Polygonzüge. Zusätzlich ist ein Ausdruck höherer Auflösung als die Bildschirmauflösung inbegriffen und es können Positionen aus .CSV-Dateien[79] importiert werden.

5.2.3 Google Earth Pro

Google Earth Pro ist die leistungsfähigste Version und kann für 400$ erworben werden. Hier wird der Funktionsumfang um verbesserte Druckfunktionen, höhere Arbeitsgeschwindigkeit (gegen über der Plus-Version) und implementierte Forschungs-, Präsentations- und Kollaborationswerkzeuge für ortsabhängige Informationen erweitert. Dieses Tool ist für den kommerziellen Einsatz in großen Firmen vorgesehen.

5.2.4 Google Earth EC

Mit dieser Enterprise Lösung können eigene oder Google Datenbestände in einer Organisation oder Firma selbst gehostet werden. Dazu werden zwei Optionen angeboten (Abbildung 18).

Google Earth Enterprise Pro: Vollständige Unternehmenslösung zum Entwerfen und Bereitstellen eigenständiger Earth-Datenbanken.

Google Earth Enterprise LT: Hybride Lösung, kostengünstiger als die EC-Pro Version, die ermöglicht das lokale Hosting unternehmenseigener Datenebenen (Punkte, Vektoren, bewegte Objekte) mit der Google Earth Basiskarte zu verbinden (Preisanfragen sind aber trotz mehrmaliger Versuche von Google nicht beantwortet worden).



Abbildung 18: Google Earth EC Pro und LT [33]


Google Maps/API: Über diese API können Geodaten und eigene Anwendungen direkt mit Google Maps in die eigene Webseite eingebunden werden. Dabei steht eine umfangreiche Schnittstelle zur Verfügung, mit der individuelle Funktionen auf die Karte als „Layer“ implementiert werden können.

5.2.5 Datenformate

Vektordaten bestehen aus Punkten, Pfaden, Linien und Polygonen. Diese Daten werden in der Geographie für die genaue Darstellung von Punkten oder Flächen verwendet. In Google (EC, Pro) können Vektordaten von anderen Anbietern importiert, angezeigt und in das KML Format umgewandelt werden.

GIS-Bilddaten sind Luftaufnahmen oder Topographische Karten. Diese können in Google Earth importiert und dargestellt werden. Bei diesem Prozess werden sie als Bild-Overlay auf das Kartenmaterial des Google Earth Client adaptiert. Es können folgen Formate importiert und verwendet werden:

- TIFF (.tiff), einschließlich GeoTiff[80] und komprimierte TIFF-Dateien - National Imagery Transmission Format (.ntf) - Erdas Imagine Images (.img) - Atlas MFF Raster (.hdr) - PCIDSK Database File (.pix) - Portable Pixmap Format (.pnm) - Device Independent Bitmap (.bmp)

Die zu importierenden Daten müssen die richtigen Projektionsangaben enthalten, um richtig dargestellt zu werden. Unter Projektion versteht man den Prozess, die Geodaten von der dreidimensionalen Erde auf eine zweidimensionale Karte zu übertragen. Es werden zurzeit keine Daten in der NAD83 Projektion für den Import in Google Earth unterstützt [33].

5.2.6 Projektion und Koordinatensystem

Geo-Daten, in Google Earth importiert, sind in einem bestimmten geographischen Koordinatensystem erstellt worden. Dieses unterteilt sich nach Projektion und Koordinatensystem wie z.B. die UTM –Projektion (Universal transversale Mercator-Projektion) mit dem ETRS89- Bezugsystem. (Abbildung 20)



Abbildung 19: Mercator Projektion [33]


Jedes dieser Koordinatensysteme weist einer Koordinate immer einen unterschiedlichen Punkt auf der Erde zu. Wenn Geodaten nach Google Earth importiert werden, müssen diese entweder im selben geographischen Koordinatensystem sein oder vorher in diese umgewandelt werden. Geschieht das nicht, interpretiert Google (wie auch andere GIS) die Geodaten nach seinen eigenen Spezifikationen und es kann dadurch zu Abweichungen in der Darstellung kommen.

Für die Projektion der Geodaten verwendet Google das lat/log WGS84-Bezugssystem in einer einfachen Zylinderprojektion. Dabei sind Längen- und Breitengrad abstandstreu und gerade parallele Linien, die sich im rechten Winkel kreuzen (Abbildung 20). Es gibt zahlreiche Projektionsarten, die aber alle (auch WGS84) eine Verzerrung von Karteneigenschaften in Fläche, Form, Richtung und Größe beinhalten. Jede Projektion hat andere Eigenschaften und geht für die genauere Darstellung von Länge oder Fläche einen Kompromiss ein, z.B. bei Form und Richtung [33].



Abbildung 20: Zylinderprojektion [33]


Ein Bezugssystem (Datum oder Kartendatum) wird benötigt, um eine Projektion der Welt auf der Karte abzubilden. Benötigt wird es resultierend aus der Tatsache, dass die Erde keine perfekte Kugel sonder ein Ellipsoid[81] ist (Abbildung 21). Somit kann man die tatsächliche Form mathematisch ausdrücken und eine Zuordnung von Breiten- und Längenkoordinaten zu Punkten auf der Erdoberfläche treffen. Erweiternd dazu hat man auch eine Basis für die Höhenmessung, Berechnung und Darstellung. Auch gibt es wieder eine Vielzahl von Bezugsthemen, Google verwendet das WGS84 Bezugssystem. In Europa ist z.B. das WMF, welches auch von der UNO genutzt wird, vorherrschend. In den USA finden eher NAD 1927 / 1983 und WGS84 Anwendung [33].



Abbildung 21: Bezugssysteme der Erde [33]


5.3 Testumgebungen

Resultierend aus der Untersuchung wurden eine Browser- (Google Maps) und eine Client- Applikationsvariante (Google Earth) als Testumgebung aufgesetzt. Diese sollen im folgenden Abschnitt näher betrachtet werden. Der Testaufbau ist in der Abbildung 22 dargestellt. Dabei dient ein Mac OS X 10.4.8 in der Standardinstallation als Web- und KML- Server.



Abbildung 22: Aufbau Testanwendung


Auf den verwendeten Servern müssen die „Mime Typs[82]“ in der Konfigurationsdatei angepasst werden, damit diese Formate richtig verarbeitet werden. Geschieht dies nicht, wird an die Formatendung „.KML“ beim Download oder Zugriff auf den Server ein „.XML“ angehängt.

Mime Type für das KML/KMZ Format:

application/vnd.google-earth.kml+xml kml application/vnd.google-earth.kmz kmz

5.3.1 Google Maps

Für den Server wird ein Zugangsschlüssel für die Verwendung von Google Maps aus dem Verzeichnis des Webservers und der Domain generiert. Dieser muss in Zusammenhang mit der API in die eigene Webseite eingebunden werden. Dieses ist im folgenden Scriptbeispiel dargestellt.

<script src="http://maps.google.com/maps?file=api&amp;v=2&amp;key=ABQIAAAAXmNcEj8ygMFn078
dx9qXjhQcgqnNjU5tZZGcKbwzYjHjpAewIRR1rS8rtKQvYljbbGv7XV890ZG3_w"type="text/javascript">
</script>
 

Die Option „v=2“ gibt an, welche API genutzt werden soll. Bei einem neuen Release belässt Google standardmäßig die alte Version noch einige Monate auf dem Server, damit sich alle Entwickler darauf einstellen und ihre Anwendungen anpassen können. Die Karte selbst wird über ein DIV-Element in die Webseite eingebunden. Die API basiert auf Java-Script, sodass alle Funktionen in einem <script> Tag eingebunden werden müssen. Nachfolgend ist der Quellcode einer einfachen Karte mit dem Overlay eines Ausgrabungplanes von Uruk abgebildet. Das zuvor erwähnte DIV-Element beinhaltet die Attribute „id=“, welches für die Identifikation des Elementes zuständig ist, und „style=“ , was die Größe der Karte in Pixel angibt. Während des Ladens der HTML-Seite wird die Funktion „load()“ über das Attribut „onload=“ aufgerufen. Diese ist im <script> Tag eingebunden und beinhaltet alle Funktionen und Variablen, die zum Start für die Google Maps Karte nötig sind. Die Load-Funktion beginnt mit einer if-Schleife, in der die Funktion „GBrowserIsCompatible()“ aufgerufen wird. In dieser testet die API, ob der Browser für Google Maps geeignet ist. Wenn das der Fall ist, wird in der Funktion „true“zurückgegeben und die weiteren Funktionen der Schleife ausgeführt. Dazu gehören „var map = new GMap2 (document.getElementById("map"));“ wodurch das DIV-Elemet mit der id=map durch ein neues Objekt GMap2 ersetzt wird. Auf diese Standardkarte werden nun durch „map.addControl(new GSmallMapControl());“ und „map.addControl(newGMap TypeControl());" die Steuerelemente für die Navigation[83] und den Type[84] eingesetzt. Der sichtbare Startpunkt wird durch „map.setCenter(new GLatLng (31.322261, 45.638800),14);“ festgelegt. Dabei stehen die ersten beiden Zahlen für Latitude, Longitude und die letzte Zahl für die sichtbare Höhe der Karte. Nach diesem Schritt ist die Karte geladen, aber es wird noch nichts in ihr angezeigt. Die Darstellung von Punkten oder Overlays erfolgt in Google Maps auf unterschiedliche Arten. Zum einen statisch durch Eintragung von allen sichtbaren Elementen in die HTML-Datei, Nachladen von Inhalten aus einer Datenbank oder unter zu Hilfenahme einer KML- oder XML-Datei. Im nachfolgenden Quellcode ist die erste Variante durch Anzeige eines Overlays dargestellt. Dabei werden die Variablen „point“ mit einem Koordinatenpunkt durch Angabe von Lat/Lng und „icon“ erstellt. Die Variable „icon“ wird über „icon.image = "http:///uruk.png";“ mit dem erstellten Plan verknüpft. Dieser muss nun über „icon.iconSize = new GSize(400, 600);“ und „icon.iconAnchor = new GPoint(195, 209);“ angepasst und ein Bezugspunkt auf der Karte festgelegt werden. Mit diesen Variablen und Einstellungen kann nun ein neuer Punkt für die Karte über „var marker =new GMarker(point, icon);“ angelegt werden. Dieser enthält Größe, Art und Koordinaten des Punktes bzw. in diesem Falle Overlays. Diese Variable wird nun unter zu Hilfenahme der Funktion „map.addOverlay(createMarker());“ auf die Karte übertragen und angezeigt. Als Erweiterung kann in „createMarker()“ mit „GEvent.addListener(marker, "click",function() {marker.openInfoWindowHtml("Marker");})“ ein so genanntes „Clickevent“ implementiert werden. Durch dieses kann nun, wie im Falle des Beispielcodes, ein beschreibender Inhalt zu dem angezeigten Marker in einem neuen Fenster per „click“ geöffnet werden.

Beispielcode Google Maps API:

 
<script type="text/javascript">
          function load()
{
if (GBrowserIsCompatible())
{ var map = new GMap2(document.getElementById("map"));
                           map.addControl(new GSmallMapControl());
                           map.addControl(new GMapTypeControl());
                           map.setCenter(new GLatLng(31.322261, 45.638800),14);
 }
 
var point = new GLatLng(31.322261, 45.638800);
var icon = new GIcon();
icon.image = "http://uruk.png";
icon.iconSize = new GSize(400, 600);
icon.iconAnchor = new GPoint(195, 209);
var marker =new GMarker(point, icon);
 
function createMarker()
{
GEvent.addListener(marker, "click",
function() {marker.openInfoWindowHtml("Marker");});
return marker;
}
map.addOverlay(createMarker());
marker.openInfoWindowTabsHtml(infoTabs);
}
</script>
</head>
<body onload="load()" onunload="GUnload()">
<div id="map" style="width: 900px; height: 800px"></div>
</body>


KML/XM L-Dateien und Google Maps:
Um sich nicht mit der Anpassung von Größe oder Inhalt der angezeigten Punkte befassen zu müssen, können Geodaten auch über einen in Google Earth oder per Script erzeugte KML- oder XML-Datei in Google Maps eingefügt werden. Dazu wird eine Variable erzeugt, die auf eine KML-Datei verweist, welche durch map.addOverlay(kml) wie ein normales Objekt geladen wird.

var kml = new GGeoXml("http://domain.de/test.kml");
map.addOverlay(kml)

Es besteht darüber hinaus die Möglichkeit, Geodaten durch ein KML File direkt auf der „maps.Google.de“ Seite anzeigen zu lassen. Durch dieses Verfahren ist es möglich, Geodaten über einen Link von der eigenen Webseite anzeigen zu lassen, ohne sich mit der Google API auseinandersetzen zu müssen. Dabei werden die Geodaten vorzugsweise in Google Earth erstellt und als KML bzw. KMZ abgespeichert. Diese werden auf einem Webserver abgelegt und können per Link auf der Webseite hinterlegt werden. Durch Betätigung öffnet sich Google Maps und die gespeicherte „example.kml“ wird angezeigt. Die Option „?q=“ gibt den Ort ,an dem das KML Files zu finden ist [44] [45].



LINK: http://maps.google.com/maps?q=http://www.eigener_Webserver.de/example.kml

5.3.2 KML & Formatierung

Für die Darstellung und Verarbeitung findet das KML/ KMZ Format Verwendung, welches derzeit in der Version 2.1 vorliegt. Generell werden KML und KMZ Dateien unterschieden. KMZ Dateien sind komprimierte KML Dateien und beinhaltet alle Bilder, Overlays und Polygonmodelle. Im nachfolgenden Abschnitt sollen die wichtigsten Komponenten und Funktionen des KML-Formates kurz erläutert werden. Für weitere Spezifikationen und Syntax der KML Struktur soll in Anbetracht des Umfanges der Ausarbeitung auf die googleeigene KML Referenz verwiesen werden.

Eine KML-Datei besitzt als XML-Derivat grundsätzlich immer den gleichen Aufbau. Im nachfolgenden Beispiel ist die Struktur einer einfachen KML-Datei zum Anzeigen eines Punktes dargestellt. Das gesamte Dokument muss in einem „<KML>“ Tag geschachtelt sein. In diesem ist als Attribut die Versionsnummer des Formates mit „<kml xmlns="http://earth.google.com/kml/2.1">“angegeben. In diesem Tag können nun alle Informationen wie Punkte, Ordnerstrukturen, Bilder, Polygonmodelle etc. eingetragen werden [41] [42] [43].
Punkte:

Ein einfacher Punkt beginnt mit „<name>“, dem Tag in dem der KML Dateiname steht. Der anzuzeigende Punkt beginnt mit einem „<Placemark>“-Tag. Dieser beinhaltet als Attribut eine „id=“. Mit dieser können später die einzelnen Punkte angesprochen und verändert werden. Im nachfolgenden „<name>“-Tag wird der Name des Punktes angegeben und der „<description>“-Tag gibt den Inhalt des Beschreibungsfensters an, wenn man auf diesen klickt. Im nachfolgenden „<Point>“-Tag werden als letztes die Koordinaten des Punktes hinterlegt [41] [42] [43].


<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
            <name>point123.kml</name>
            <Placemark id="1">
                       <name>point1</name>
                       <description>point1</description>
                       <Point>
                                   <coordinates>-95.44000000000001,40.42,0</coordinates>
                       </Point>
            </Placemark>
</kml>__
 


Ground Overlay’s:

Ground Overlay’s sind Bilder oder Vektordaten, die in einer neu erzeugten Schicht (Layer) über die Karte gelegt werden können. Damit sind zusätzliche Informationen wie Pläne, Zeichnungen oder Bilder in höherer Auflösung mit dem Google Material verknüpfbar. Diese werden über das „< GroundOverlay >“ Tag eingesetzt. Dabei wird in „<Icon>“ der Ort angegeben, in dem das zu implementierende Overlay zu finden ist. Des Weiteren wird über „<LatLonBox>“ die genaue Position und Größe des Bildes festgelegt [41] [42] [43].

<GroundOverlay>
                                   <name>ur_plan</name>
                                   <Icon>
                                               <href>UR_g.png</href>
                                   </Icon>
                                   <LatLonBox>
                                               <north>30.96776717842454</north>
                                               <south>30.9546810857953</south>
                                               <east>46.11057913647022</east>
                                               <west>46.09949861981426</west>
                                   </LatLonBox>
</GroundOverlay>__
 


Folder:

Die eingetragenen Punkte können für die bessere Übersicht in Orderstrukturen sortiert und angezeigt werden. Dazu kann ein „<Folder>“-Tag Verwendung finden. Dabei unterscheidet man grundsätzlich zwischen „normalen“ und „schaltbaren“ Ordern. In einem schaltbaren Ordner kann immer nur ein Unterpunkt (Punkt oder Ordner) angezeigt werden. Diese wird durch Einfügen des <listItemType> Tags und der Option „radioFolder“ ermöglicht, während sonst alle Elemente ein- und ausgeschaltet werden können. Per Default ist eine normale Ordnerstruktur implementiert. Eine Aufteilung in Unterordner wird durch Verschachteln der „<Folder>“-Tags realisiert (Folder in Folder anlegen). [41] [42] [43].

 
<Folder>
            <name>Test</name>
            <open>1</open>
<Style>
            <ListStyle>
                       <listItemType>radioFolder</listItemType>
                       <bgColor>ff381cbc</bgColor>
            </ListStyle>
</Style>
<Folder>
                       <name>Unterornder1</name>
                       <Folder>
                                   <name>Unterorder1.1</name>
                       </Folder>
                       <Folder>
                                   <name>Unterordner1.2</name>
                       </Folder>
            </Folder>
</Folder>__
 


Polygonmodelle:

In Google Earth können über das Zusatztool Sketchup Polygonmodelle eingesetzt werden. Ein 3D Objekt wird über das Tag „<Model id="model_1">“ eingesetzt. In „<Location>“ wird die Position des Models angegeben und über „<Orientation>“ die Drehung über die x-, y-, z-Achse angezeigt. Die Daten selbst werden über den „<Link>“-Tag eingebunden.


 
<Model id="model_1">
                       <Location>
                                   <longitude>46.10311795758702</longitude>
                                   <latitude>30.96270148740241</latitude>
                                   <altitude>0</altitude>
                       </Location>
                       <Orientation>
                                   <heading>2.59416006139738</heading>
                                   <tilt>0</tilt>
                                   <roll>0</roll>
                       </Orientation>
                       <Link>
                                   <href>SUPreview1.dae</href>
                       </Link>
            </Model>__
 


Screen Overlay:

Durch Screen Overlay könne in Google Earth Bilder in das sichtbare Feld über alle Kartenelemente gelegt werden. Somit könne projektbezogen Icons oder Ähnliches erstellt werden (Abbildung23) [41] [42] [43].



Abbildung 23: Screen Overlay MPIWG-Logo



<ScreenOverlay id="MPIWG">
                       <name>Mpiwg-berlin.mpg.de</name>
                       <open>1</open>
                       <description>Max-Planck-Institut für Wissenschaftsgeschichte</description>
                       <Icon>
                                   <href>
mpiwg_logo.png
</href>
                       </Icon>
                       <overlayXY x="0.05" y="0.98" xunits="fraction" yunits="fraction"/>
                       <screenXY x="0.05" y="0.98" xunits="fraction" yunits="fraction"/>
                       <rotationXY x="0.5" y="0.5" xunits="fraction" yunits="fraction"/>
                       <size x="0" y="0" xunits="pixels" yunits="pixels"/>
</ScreenOverlay>__
 


Load-File:

Ein Load-File wird in Google Earth dazu verwendet, Informationen über eine kleine Initiialisierungsdatei (siehe Abbildung 24) vollständig von einem Server nachzuladen. Dabei wird ein Link angegeben, wo Inhalte zu finden sind. Darüber hinaus kann definiert werden, wie die Daten vom Server zu laden sind. Mit „<refreshMode>onInterval </refreshMode>“ und „<refreshInterval>600</refreshInterval>“ wird angegeben, das diese im Intervall alle 600 Sekunden inkrementell zuladen sind. Nachteilig ist, daß immer alle Daten geladen und abgeglichen werden, was bei großen Projekten zu einer hohen Netzbelastung führen kann. Diese wird mit der Option "<viewRefreshMode>onRegion </viewRefreshMode>" umgangen. Nun werden nur Informationen nachgeladen, wenn die entsprechende Region sichtbar wird. Darüber hinaus kann mit der Option "<refreshMode>onExpire</refreshMode>" ein serverseitiger Updateprozess erfolgen. Somit werden Daten nur übertragen, wenn sich etwas auf dem Server ändert [41] [42] [43].



Abbildung 24: Nachladen von Daten mit Load-File's [42]



 <kml xmlns="http://earth.google.com/kml/2.1">
<NetworkLink>
   <name>loads.kml</name>
   <Link>
                       <href>http://.../irak.kmz</href>
                       <refreshMode>onInterval</refreshMode>
                       <refreshInterval>600</refreshInterval>
 
   </Link>
</NetworkLink>
</kml>__
 


Change-File:

Um bei häufigen Intervallen nicht immer alle Daten neu laden zu müssen, kann ein Change-File eingesetzt werden. Mit diesem ist es möglich, ein Objekt (im folgenden Beispiel ein Punkt) über seine ID anzusprechen und zu ändern. Dabei bleiben alle anderen Daten unberührt. Im <Update> -Tag ist beschrieben, welche KML-Datei bearbeitet werden soll. Danach wird im <Change> -Tag angegeben, was und wie geändert wird [41] [42] [43].

<NetworkLinkControl>
  <Update>
               <targetHref>point.kml</targetHref>
    <Change>
      <Placemark Id="pm123">
        <name>Name changed by Update Change</name>
      </Placemark>
    </Change>
  </Update>
</NetworkLinkControl>__
 


5.3.3 Implementierte Daten

 This is the caption In der Testanwendung sollen die bereit erwähnten Aus-grabungspunkte von Ur, Uruk und Nimrut im Irak visualisiert werden. Dabei wurden Ausgrabungspläne bzw. Material von dem CDLI/ MPIWG freundlicherweise zur Verfügung gestellt. Diese Pläne liegen im Encapsulated PostScript[85] Format vor und müssen für die Darstellung in Google Earth/Maps umgewandelt werden. Dabei wurde PNG durch die Bereitstellung des transparenten Layer für die Anzeige verwendet. Die Polygonenmodele liegen im .max[86]-Format vor und müssen bei der Verarbeitung in das .3ds[87]-Format umgewandelt werden. Dieses Format wird in den von Google kostenlos zu Verfügung gestellten 3d Tool ScetchUp[88] importiert und kann von dort aus in Google Earth eingesetzt werden [47].



5.3.4 Google Maps

Zunächst wurde die Google Maps „API“ in ein HTML-Seite adaptiert. Durch diese ist es nun möglich, Satellitenkartenmaterial in eine selbst gestaltete Webseite einzubinden. Als Koordinaten wurden die zuvor erwähnten Punkte Ur, Uruk und Nimrod in die Testumgebung eingebunden. Die Geodaten wurden in dem Filesystem eines Webservers als KML Dateien abgelegt und können über PHP/Javascript ausgelesen und dargestellt werden. Bei größeren Datenmengen ist auch die Verwendung einer Datenbank vorgesehen. In den KML-Daten sind unter anderem alle georelevanten Informationen und die Ausgrabungskarten als „overlay“ zusammengefasst.

5.3.5 Google Earth

Als nächstes wurden die gleichen Testdaten in eine Google Earth Applikation eingebunden. Vorteil dieser Anwendung ist die maßstabsgerechte Darstellung von Ruinen oder anderen Rekonstruktionen in dreidimensionalen Abbildungen. Die Verteilung der Informationen kann aus Implementierungsgründen nicht wie bei Google Maps über den Webserver erfolgen, daher wurde ein KML-Loadfile[89] generiert, welches auf einen KML-Server[90] referenziert.

5.4 Resultate

Nach der Untersuchung der Testanwendungen wurde festgestellt, dass sich Web 2.0 Technologien und Techniken (Google Earth/Maps) in vollem Umfang für die Bearbeitung von wissenschaftlichen Projekten und deren Visualisierung eignen. Durch den Einsatz von Satelliten- und Überflugkarten ist es erstmals gelungen, Ausgrabungspläne und Fundorte digital für jede Person im Zusammenhang zugänglich zu machen. Im nächsten Abschnitt werden die Vorteile einer Google Earth/Maps Anwendung kurz erläutert.

5.4.1 Ergebnisse Google Map

Google Maps ist – über die Google API in die Webseite integriert – ein vielfältiges Tool für die Produktion von eigenen Geo-Web-Anwendungen und Services. Durch Unterstützung von Ajax kann man eine fast Desktop-ähnliche Arbeitsumgebung schaffen (Abbildung 25 und 26), in der nicht nur Ausgrabungspunkte bearbeitet werden können. Ferner lassen sich Anwendungen für alle Arten von Projekten entwickeln, bei denen es einer Verknüpfung bzw. Visualisierung von Geodaten bedarf. In Verbindung mit Wiki- und Blog- Technologien lässt sich auch eine komplette Arbeitsumgebung für geographisch getrennt arbeitende Projektgruppen entwickeln. Die Geodaten werden in einem XML- konformen Format gespeichert (KML/KMZ). Somit ist es möglich, die angesammelten Informationen bei einer Änderung oder Einstellung des KML Formates von Google in ein anderes XML Format einzufügen. Diese stehen allen weiteren Prozessen zur Verfügung und es ist somit keine direkte Abhängigkeit von dem Google Format gegeben.



Abbildung 25: Testanwendung Google Maps (Grabungsplan Uruk in der Übersicht)



Abbildung 26: Testanwendung Google Maps (Grabungsplan Uruk Großprojektion)


Leider fehlt in Google Maps noch die Möglichkeit der Einbindung von dreidimensionalen Objekten. Dieses kann unter Zuhilfenahme eines Flash Layer in der Anwendung (nur bei der Google API möglich), oder durch Implementierung der Objekte als Quick Time VR nachempfunden werden. In der Testanwendung ist die letztere Variante aus Gründen der einfachen Umsetzung implementiert (Abbildung 27). Dabei werden die Polygonmodelle in C4D angepasst und als Quick Time VR gerendert [47].

Abbildung 27: 3D-Darstellung mit Quicktime VR

5.4.2 Ergebnisse Google Earth

Google Earth ist im Vergleich zu Google Maps eine Applikation, die auf dem Desktop des Users läuft. Diese kann ebenfalls KM-Dateien lesen bzw. erzeugen und hat gegenüber Google Maps den Vorteil, dass eine dreidimensionale Sicht auf das Kartenmaterial ermöglicht wird. In diesem Zusammenhang wird ebenfalls deutlich, dass durch die Implementierung eigener Karten bei schlechten Satellitenbildern durchaus auch eine effektive Visualisierung ermöglicht wird (Abbildung 28). In Google Maps kann dieses ebenfalls realisiert werden.



Abbildung 28: Markierung von Fundorten in Uruk


Ein weiteres Feature ist die Markierung und Beschreibung von Polygonzügen. Dabei wird ein bestimmter Bereich auf der Karte zusammengefasst und mit Informationen versehen. In einer Datenbank hinterlegt, können diese Informationen miteinander in Verbindung gesetzt werden. Es besteht die Möglichkeit, einzelne Koordinaten diesen Feldern zuzuordnen bzw. zu bestimmen (Abbildung 29).



Abbildung 29: Beispiel für die Bezeichnung bzw. Markierung eines Weges in Nimrud



Abbildung 30: Einbeziehung von topographischen Merkmalen

Eine weitere Möglichkeit der Visualisierung ist die Einbeziehung von Höheninformation in die Satellitenbilder. Damit können Ruinen sehr deutlich in ihrem räumlichen Bezug gesehen und dargestellt werden. Somit kann man feststellen, das Nimrud wahrscheinlich auf einer Erhöhung gelegen hat (Abbildung 30). Darüber hinaus können dreidimensionale Modelle z.B. in Form von Ruinen oder Rekonstruktionen in die Karten eingebunden werden. Bei diesem Prozess werden Polygonmodelle anhand von Grabungsplänen und Rekonstruktionen angefertigt. Diese werden (wie oben beschrieben) über ein Google eigenes Tool (Sketchup) in den Earth Client eingebunden und ebenfalls als KML abgespeichert (Abbildung 31-32). Der Datenaustausch läuft nach Upload der Daten auf den KML-Server und Generierung des Loadfiles ohne Probleme. Auch die Flickr Implementierung in der Testanwendung führte zu guten Ergebnissen. Dabei wird ein „Link“ im <description> Tag des KML-Files angegeben, der auf einen Flickr-Account „297268074“ referenziert und von diesem ein Bild „107/297268074 _b53f8f3feb_t.jpg“ lädt. Anschließend werden nur noch die Größe und Bezeichnung angegeben.

<a href="http://www.flickr.com/photos/cdli/297268074/" title="Photo Sharing"> <img src="http://static.flickr.com/107/297268074_b53f8f3feb_t.jpg" width="100" height="54" alt="ur12" /></a>

Wie in Abbildung 33 zu sehen, ist durch die Kombination von Overlays und 3D Modellen eine fast perfekte Visualisierung von Ausgrabungsorten möglich. Diese können in Google Earth editiert und als KML abgespeichert werden. Danach müssen die Daten aber per Hand auf einen Server geladen werden, denn zurzeit ist keine Uploadfunktion von im kostenfreien Client erstellten Geodaten zum eigenen Publishing-Server möglich.


—- Abbildung 31 Polygonmodel in Sketchup



Abbildung 32: fertige 3D Rekonstruktion der Ziggurat von Ur in Google Earth



Abbildung 33: Kombinierter Einsatz von Overlays, 3D Rekonstruktionen und Flickr

5.5 Zusammenfassung

Google Earth und Maps müssen nicht getrennt voneinander betrachtet werden. In ihrer Kombination kann man die Stärken der beiden Tools vereinen und eine völlig neue Arbeit und Präsentationsumgebung schaffen. In der Google Maps Anwendung werden die Koordinaten anlegt oder über eine Upload-Funktion von in Google Earth erstellten KML-Files hochgeladen. Durch die API können alle Funktionen kostengünstig (vergleichend Google Earth Pro oder Enterprise) selbst den Bedürfnissen angepasst werden. Dagegen ist Google Earth ein weitaus besseres Präsentationsmedium in dem es mit der „Plus“ Version möglich ist, Videos von seinen Kameraflügen über projektrelevante Punkte aufzuzeichnen. Daten, die mit Google Maps auf dem Server als KML File hinterlegt wurden, können über das Load-File ganz einfach in Google Earth integriert werden. Dazu muss ein KML-Server entwickelt werden, der die Verwaltung der einzelnen Files übernimmt und die Verknüpfung zwischen Google Earth und Maps realisiert. Außerdem könne auf diesem Server auch die Verbindungen zu andern Datenbanken integriert werden.

Probleme in der Testanwendung: Als Fragestellung ergeben sich aus diesem Projekt die Punkte der Abhängigkeit von Google Earth/Maps und die Verwendung des google-eigenem KML Format als Datenträger. Google kann seinen Service natürlich ohne weiteres einstellen und die Benutzung von KML-Formaten untersagen. Beim Eintreten dieser (aus heutiger Sicht unwahrscheinlichen) Situation besteht die Möglichkeit, einen eigen Map-Server aufzusetzen und die KML-Files wie erwähnt in ein anderes XML-Format wie GML umzuwandeln. Als Ersatz für das GIS kann „Nasa World Wind“ Verwendung finden. Diese steht unter Open Source zur Verfügung und beinhaltet auch frei verwendbares Kartenmaterial. Somit ist die Gefahr einer Abhängigkeit von Google eher gering [48].

6 Aussichten

6.1 Neue Archäologie

Dieses Projekt weiterführend könnte man die geschaffene Arbeitsoberfläche für aktuelle Ausgrabungen verwenden, in dem man sich die Google Earth Pro oder Enterprise Edition zu nutze macht. Diese beinhaltet eine Integration von GPS-Geräten[91] und Empfängern, durch die es möglich ist, in der Ausgrabung sofort die Fundstellen mit Geodaten zu verknüpfen und diese anschließend einfach als KML-File auf einen Server zu laden. Somit können diese Daten in wenigen Minuten, an allen Orten der Welt verfügbar gemacht werden. Über ein Load-File dieses Projektes kann man die Fortschritte in Google Earth beobachten und parallel die Ausgrabungsfunde (-stellen) diskutieren, zuordnen oder übersetzen. Verbunden mit der Wiki- und Blog-Technologie wäre es denkbar, die Bearbeitungszeit von Ausgrabungen oder Ähnlichem auf ein Minimum zu reduzieren, da viele Prozesse wie Archivierung, Zuordnung, Vergleich mit anderen Fundstücken und Visualisierung schon während der Ausgrabung parallel ablaufen könnten. Weitere Vorteile sind die lokale Speicherung von Google Karten auf dem Server. Diese sind durch eigene Satelliten- oder Überflugkarten erweiterbar. Desweiteren erfolgt die Bearbeitung, Speicherung von KML-Daten und die Verknüpfung von Google Maps/Earth Anwendungen auf einem eigenem Produktionsserver. Zusätzlich dazu können von Google geladene Karten gesichert und im Falle einer Löschung oder Verschlechterung durch ein Update, (wie bereits geschehen bei Ur im Irak) wieder zurückgespielt werden. Natürlich ist dieser Workflow nicht auf Ausgrabungen beschränkt, er lässt sich auch für andere Projekte verwenden, die sich mit Kartenmaterial befassen bzw. sich in ihren Arbeiten darauf beziehen.

6.2 Neue Arbeitsumgebungen für das CDLI

Darüberhinaus laufen zurzeit Beratungen mit Jacob Dahl zu der Frage einer Visualisierung der kompletten Datenbank des CDLI mit Google. Hierdurch könnte man mit einem Load-File (vergleichend 5.3.4) eine Visualisierung des gesamten vorderasiatischen Bereichs zum Download anbieten. Dadurch hätten alle Wissenschaftler, die an diesem Projekt arbeiten, immer alle neuesten Informationen in ihrem Google Earth Client. Für diese Aufgabe würde man ein Service benötigen, der die CDLI Datenbank mit einem Google Maps Mashup (Abbildung 22) verbindet. Somit könnten vorhandene Daten (Steintafeln etc.) Koordinaten zugewiesen bekommen und als KML auf dem Server abgelegt werden. Die Implementierung der dreidimensionalen Modelle muss natürlich in Google Earth erfolgen, da diese nicht über den Google Maps Client realisierbar ist. Diese könnte aber mit einem zusätzlichen Flashlayer oder mit Quick Time VR (Abbildung 27) über der Google Maps API realisiert werden. In diesem Layer könnten auch Ausgrabungsstätten als dreidimensionale Modelle dargestellt werden. Damit könnten sogar ganze Zeitabläufe und Animationen in die Karte eingebracht werden.

6.3 Dreidimensionale Visualisierung von Google Earth Projekten

Im Zusammenhang mit der Visualisierung und der digitalen Rekonstruktion von Ausgrabungsstätten besteht die Möglichkeit der Erstellung einer Spritzgussplastik. Diese kann direkt aus dem in ScetchUp importierten dreidimensionalen Model erstellt werden. Somit können wissenschaftliche Ausarbeitungen mit ihren Rekonstruktionen direkt nach der Präsentation im Internet oder im Google Earth Client für Ausstellungen oder zu Lehrzwecken als reales Model erstellt und genutzt werden.



Abbildung 34: Entwicklungslayout 3D-Copy.de [46]



Abbildung 35: fertige 3D Spritzplastik


web_2.0_und_der_einsatz_in_der_wissenschaft.1196686737.txt.gz · Last modified: 2007/12/03 12:58 (external edit)
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0