Gespräch zwischen Cornelia Sollfrank und Richard Leopold
Forchheim, 15.4.2003
R.L.: Ja, duchaus. Zuerst habe ich mich mal mit Dada-Kunst beschäftigt und versucht zu verstehen, was das überhaupt ist. Ich habe eine Idee davon bekommen und arbeite zur Zeit an einem eigenen Netzkunstgenerator.
C.S.: Was ist die Grundidee des neuen Generators?
R.L.: Die Grundidee ist, dass ich nicht nur das gefundene, in HTML-Dokumente eingebundene Material, also Text und Bilder, zu einem neuen Dokument zusammenbaue, sondern dass auch die Struktur des neuen Dokumentes sich dynamisch errechnet aus den Strukturen der gefundenen Dokumente.
C.S.: Das heisst, du gibst nicht vor, in welches Layout die Inhalte eingefüllt werden, wie es etwa bei nag_01 von Ryan Johnston der Fall ist, sondern das Erscheinungsbild jeder neuen, generierten Seite ist vollkommen anders und hängt ausschliesslich davon ab, welche HTML-Tags *2 in den vorgefundenen Websites gefunden wurden.
R.L.: Der Inhalt eines Dokumentes, der Content, ist logisch strukturiert über die HTML-Struktur, d.h., ich kann einerseits den Content herausholen und verarbeiten, aber ich kann auch die Struktur selbst nehmen und daraus eine neue Struktur ableiten.
Zuerst ziehe ich also den Content aus der Struktur heraus, um ihn dann als Dada-Content, also entsprechend rekombiniert, in eine neue Struktur wieder einzufüllen. Und die neue Struktur leitet sich ebenfalls von den vorgefundenen Strukturen ab.
C.S.: Die neue Struktur könnte man also entsprechend als Dada-HTML oder Dada-Struktur bezeichnen!
R.L.: Ja, genau. Und ich hoffe, dass diese lesbar ist, bzw. im Browser darstellbar.
C.S.: Wow, das ist toll. Ich denke, das greift die Idee von Bulhak auf eine ehrwürdige Weise auf. Können wir uns das mal ansehen, und du erläuterst, wie es funktioniert?
R.L.: Lass uns schrittweise durch das Programm gehen... Schritt 1: Eingabe eines Titels für das neue "Kunstwerk". Also, zuerst kommt natürlich die Eingabe eines Suchbegriffes bzw. des Titels. Wir machen mal einen Test mit dem Begriff "Hexe". Nun erfolgt Schritt 2: Füttern der Suchmaschinen-Backends *3 mit dem Titel.
Eine Anfrage mit "Hexe" als Suchbegriff wird bei den spezifizierten Suchmaschinen gemacht. Nimmt man nur ein Wort und nicht einen längeren Titel, ist natürlich die Suchmenge entsprechend groß.
C.S.: Welche Suchmaschine hast du benutzt?
R.L.: Ich habe die Backends benutzt, von denen ich Schnittstellenbibliotheken habe. Aus diesem Pool der Schnittstellen verwende ich z.Zt. "Hotbot" und "AltaVista". Eine Google Schnittstelle ist ebenfalls in diesem Pool, doch braucht man ein Passwort und muss sich registrieren, um die Schnittstelle bedienen zu können. Das Passwort erhält man nur kostenfrei für "Personal Use Only" and "No Automated Querying". Es gibt auch andere, kommerzielle Lizenzen, aber darauf wollte ich im Moment verzichten. Und es kommt darauf an, welche Backend-Schnittstellen gerade funktionieren. Als Ergebnis erhalten wir - hoffentlich - eine Menge URLs zu entsprechenden Dokumenten.
C.S.: Du hast doch sicher irgendwie eingeschränkt, welches Material zur Weiterverarbeitung in Frage kommt?
R.L.: Ja - Das passiert in Schritt 3: Auswahl aus der Menge der URLs.
Das Programm holt sich nur HTML-Dokumente, genauer: nur Dateien mit dem Content-Type: text/html, also zum Beispiel keine PDF-Dateien. HTML deswegen, da sich das zu generierende Dokument ja auf die HTML-Struktur der gefunden Dokumente bezieht und somit für das weitere Processing notwendig ist.
C.S.: Wie beschränkst du die Suchmenge, ausser durch das Format? Oftmals kommen doch bestimmt Hunderte von Seiten als Suchmenge heraus?
R.L.: Aus den Ergebnissen der Anfrage wird ausgewählt, was verwendet wird für die neue Seite - nur mengenmässig, nicht inhaltlich, z.B. fragen wir nur die ersten 30 ab. Dabei muss die Anzahl nicht festgelegt bleiben, sondern ist konfigurierbar. Und es gibt weitere Parameter, die die Auswahl einschränken.
C.S.: Was ist zur Zeit festgelegt in den Parametern?
R.L.: Die Dateien dürfen nicht größer als 200KB sein (Content-Size). Die Beschränkung der Größe ist ein Filter, der sicherstellt, dass nicht zu große Dokumente die Maschine "platzen" lassen. Die Anzahl der Dokumente 30 multipiziert mit der maximalen Größe 200KB ergeben 6MB möglichen Speicherbedarf nur für das Laden der Dokumente.
C.S.: Was passiert dann mit der verbleibenden Suchmenge?
R.L.: Mit den übrig gebliebenen URLs kommen wir dann zu Schritt 4: Herunterladen der HTML-Dokumente.
Nun holen wir nicht nur die Attribute der Dateien von den Servern, sondern die Dokumente selbst. Jetzt beginnt der eigentliche Prozess mit dem Schritt 5: Parsen der HTML-Dokumente.
C.S.: Was bedeutet hier "parsen"?
R.L.: "Parsen" bedeutet, die klassische HTML-Datei wird interpretiert und als Baum von Knoten im Arbeitsspeicher des Computers organisiert.
Vereinfacht enspricht so jedes HTML-Element einem Knoten im Baum und kann ein oder mehrere "Kinder-Knoten" und einen "Eltern-Knoten" haben. In Bezug auf den Inhalt gibt es Text-, Bild-, Link- und viele andere Knoten, die in dieser Abstraktion das ursprüngliche HTML-Dokument repäsentieren. Sind alle HTML-Dokumente geparsed kommen wir zu Schritt 6: Einzelbetrachung der Knoten.
Den Textknoten wird ihr Inhalt entnommen, womit dann die "Dada-Text-Maschine" gefüttert wird. Jeder Knoten kommt in die "Dada-Knoten-Maschine". Bei diesem Schritt werden bestimmte Knoten herausgefiltert, wie z.B. leere Textknoten, die als Futter unsinning sind. Auch werden Knoten modifiziert, so dass ggf. Bilddaten unabhängig vom Ursprungsdokument des Knotens gefunden und dargestellt werden können.
C.S.: Dada-Text-Maschine;, Dada-Knoten-Maschine; füttern? Was heisst das?
R.L.: Da muss ich etwas ausholen. Meine Dada-engine folgt nicht dem Prinzip einer statischen Sprachbeschreibung à la Bulhak. Bulhaks Beschreibungssprache beinhaltet bereits alle möglichen Wörter für den zu generierenden Text. In unserem Fall kennen wir die Wortmenge noch nicht.
Hier werden aus bestimmten, vorhandenen Texten neue Texte generiert. Das Interessante dabei ist, dass die Beschreibungssprache ja auch generiert werden muss. Man weiss nicht, in welcher Sprache der vorgefundene Text sein wird, d.h. ich kann gar keine formale Beschreibung der Sprache bilden, die sich nur auf eine Sprache beziehen würde. Alle Sprachen unterscheiden sich in ihrer Grammatik, deshalb muss man erst einmal die Texte formal untersuchen.
Das von mir verwendete Prinzip bildet Markov-Ketten: Ich analysiere, was kommt nach einem Wort "A", was kommt nach dem Wort "B" oder "C" und was wie häufig, usw. Dann baue ich Ketten auf und zähle die Verbindungen hoch. Das ergibt eine weitere Baumstruktur, und ich kann sehen, aha, nach dem Wort "A" ist nicht nur das Wort "B", sondern auch noch das Wort "D" und das Wort "X" gefallen. So erfahre ich, welche Wörter nach dem Wort "A" kommen können und so fort. Für die Knoten gilt dasselbe, nur dass ich hier die Namen der Knoten verwende.
Die erwähnten Dada-Maschinen sind als Bibliotheken umgesetzt. Diese stellen im Programm die Funktionen der Dada-Maschine zur Verfügung: 'feed()' - füttern - und 'get Dada()' - Dada ausgeben. Die Funktionen sind implementiert für die bleibenden Dada-Kategorien: Text und Knoten. Und das Bilden der Markov-Ketten ist das Füttern ...
C.S.: Wie wird im Moment die entstehende Struktur generiert?
R.L.: Zu 'get Dada' kommen wir nun in Schritt 7: Generierung eines neuen HTML-Dokumentes als Zieldokument aus der Dada-Knoten-Maschine
Hier generieren wir, beginnend mit dem Dokumentwurzelknoten eine zufällige Dokumentstruktur.
C.S.: Und welche Rolle spielt der Zufall bei der ganzen Sache?
R.L.: Der Zufallsgenerator wählt einen der möglichen "Kind-Knoten" aus, die im Dokumentwurzelknoten liegen, und dann werden von hier aus die möglichen Verbindungen mit anderen Knoten ebenso zufällig bestimmmt. Ich komme von Knoten "A" zu Knoten "C" über einen bestimmten Weg. Der Weg ergibt sich aus Knotenbeziehungen der gefütterten Knoten. Ist eine Beziehung einmal verwendet worden, zählt das Programm deren Anzahl um eins runter, so dass der Knoten "C", wenn er nur einmal in den Quellen vorkam, nicht noch einmal verwendet werden kann. Die neue Dokumentstruktur wird also aus den sogenannten Markov-Ketten gebildet.
C.S.: Und das Abholen der Knoten unterliegt welchen Regeln?
R.L.: Anfangs hatte ich sehr große Dokumente. Jetzt limitiere ich die Anzahl der Knoten im Ergebnisdokument, z.Zt. beträgt diese 777.
Ein Knoten ist immer ein "tag" in HTML. Wenn wir mal in den Source-Code des Dokumentes schauen, wird das deutlicher. Die "tags" des Dokumentes werden als Knoten gesehen innerhalb des Objekt-Baumes. Und die Verschachtelungstiefe bzw. Iterationstiefe des Baumes wird festgelegt. Der aktuelle Wert dafür beträgt 13. In unserem Fall bedeutet die Iterationstiefe 13 die 13te Verzweigung, wenn man sich im Baum von seinem Stamm aus zu den Astspitzen bewegt.
Ich weiss natürlich nie, ob die neu zusammengesetzte Dokumentstruktur überhaupt funktionsfähig ist. Es kann auch fehlerhaftes HTML dabei herauskommen, was einfach nicht interpretiert bzw. dargestellt werden kann. Doch die Generierung mit Hilfe der Markov-Ketten erzeugt verwertbarere Strukturen, als wenn ich die Knoten einfach so mischen würde. Kommen wir nun zu Schritt 8: Auffüllen der "Text-Knoten" des Zieldokumentes mit Textfragmenten aus der Dada-Text-Maschine.
Alle "Textknoten" des Zieldokumentes werden mit 'get Dada'-Ergebnissen der Dada-Text-Maschine gefüllt. Das 'get Dada' für den Text folgt dem gleichen Prinzip wie das der Knoten. So, nun ist unser Kunstwerk fertig. Es manifestiert sich in Schritt 9: Speichern des Kunstwerkes als HTML-Datei im Filesystem... wo es für den Benutzer sichtbar wird.
C.S.: Das sollten wir uns gleich mal genauer ansehen. Das Dokument, das wir jetzt als Ergebnis unseres ersten Versuches bekommen haben, sieht so aus, als beinhalte es nur deutsch-sprachigen Text. Ist das Zufall, oder ist das Programm in irgendeiner Weise auf eine Sprache begrenzt?
R.L.: Nein, der Generator ist vollkommen sprachunabhängig. Er kann mit allen Zeichen unserer Sprache umgehen. Schwierigkeiten entstehen nur, wenn andere Zeichensätze ins Spiel kommen, wie z.B. beim Japanischen.
C.S.: Wie ist das denn bei der originalen Dada-engine?
R.L.: Es gibt unterschiedliche Dada-engines. Die, auf die du referenziert hast, die von Bulhak, erzeugt die "Dada-Texte" nach einer formalen Beschreibungssprache, die den gesamten Wortschatz enthält.
C.S.: Das vorläufige Ergebnis, das wir jetzt bei unserem Suchbegriff "Hexe" bekommen haben, enthält auch Bilder. Wo kommen die her, denn sie waren bisher nicht als Option bzw. als Content möglich gewesen.
R.L.: Da ich die Knoten kopiere, kopiere ich automatisch die "Bilderknoten" mit, das bedeutet, ich setzte die "Bilderknoten" per Zufall durch die Struktur des Dokumentes ein. Ich habe also keine Wahl, welche Bilder genommen werden oder wohin sie kommen. Sie erscheinen einfach durch das Kopieren der Knoten.
C.S.: Das ist im Vergleich dazu, wie das Programm mit Texten umgeht, ziemlich banal.
R.L.: Es ist strukturell betrachtet genauso banal wie bei den Texten.
Wie man sehen kann, kommt wirklich Material unterschiedlichster Sprachen in den Speicher. Hier sind japanische Zeichen, und Sonderzeichen gibt es auch. Meistens handelt es sich jedoch um englische Texte, da die Backends englisch-sprachige Suchmaschinen anfragen.
C.S. Wir haben in unserem Ergebnisdokument jede Menge Links. Wohin führen die?
R.L.: Die führen zum gleichen Ziel wie im originalen Text der originale Link auch. Die Informationen des Links bleiben erhalten. Ebenso die Formatierung, was Schriftarten und Schriftgrößen anbelangt. Praktisch wird nur der Text-Inhalt dieser Knoten duch ein neues Textfragment ersetzt. Das erklärt auch, warum so unterschiedliche Schriftarten zu sehen sind.
C.S.: Woran musst du noch weiterarbeiten?
R.L.: Im Moment geht es mir hauptsächlich darum, die grundlegende Idee zu überprüfen und festzuklopfen. Es werden einige Module als Bibliothek entstehen, die später mit einem "Frontend" versehen werden. Wie das "Frontend" genau aussehen soll, kann man später entscheiden. Man muss auch sehen, was sinnvoll ist, denn das Generieren der neuen Seiten benötigt doch einige Zeit. Man sollte es vom direkten Betrachten entkoppeln, d.h. der Auftrag zum Generieren wird erteilt, und man kommt etwas später zurück, um das Ergebnis zu sichten. Je nachdem wie groß die Ergebnismenge ist, kann es durchaus einige Minuten dauern. Es hängt davon ab, wie der Generator parametrisiert ist.
C.S.: Wenn man weiß, was in dieser Zeit alles passiert, kommt es einem gar nicht mehr lange vor...
R.L.: Prinzipiell ist das ganz einfach: abholen, zerlegen, neu zusammenbauen, ausgeben. ... das könnte man auch im "Frontend" transparent machen... als Zeitvertreib.
C.S.: Ja, aber allein das ganze Material auf die Festplatte zu schreiben, ist schon sehr aufwendig.
R.L.: Der Vorgang spielt sich eigentlich nur im Arbeitsspeicher ab bis das Resultat auf die Platte geschrieben wird, hierbei ist lediglich die Ermittlung eines Dateinamen notwendig, der als URL dann auf das Ergebnis verweist. Und bei dem gesamten "geschriebenen" Material handelt es sich um eine HTML-Datei.
C.S.: Nach der Ausgabe des ersten Ergebnisfiles ist noch jede Menge Material in den Speichern. Können wir versuchen, daraus noch eine neue Seite zu generieren?
R.L.: Klar. Können wir. Nein, leider doch nicht. Fehlermeldung. Um diesen Fehler zu vermeiden, bedarf es noch programmtechnischer Änderungen.
C.S.: Also ich finde, das sieht doch alles schon sehr gut aus. Bist du selbst auch zufrieden?
R.L.: Ja, eigentlich schon. Wir können sicher mit dem Generator von Luka mithalten, was die Komplexität des Ergebnisses anbelangt.
C.S.: Allerdings hat seiner nicht nur ein HTML-file erzeugt, sondern ein ganzes Konglomerat von neuen Seiten, eine richtige Website, die untereinander und nach außen verlinkt war. Entsprechend dauerte bei ihm die Bearbeitung auch bis zu 30 Minuten. Leider scheint der Generator zu komplex gewesen zu sein, um längerfristig lauffähig zu sein. Im Moment gibt es nur noch ein Archiv von früher hergestellten Seiten. *4
R.L.: Ich versuche natürlich einen Kompromiss zu finden zwischen Komplexität, Geschwindigkeit und Wartbarkeit. Es ist durchaus denkbar, aufgrund des Datenbestandes, den man ja sowieso vorliegen hat, zum Beispiel noch ein "Link-Dada" zu machen, eben eine ganze Website zu erzeugen, wie du gerade sagtest. Dann würde ich die "Linkknoten" nicht einfach nur kopieren, sondern sie ebenfalls als Material behandeln, einen Pool von Links speichern, und für jeden der "Link-Pool-Knoten" könnte ich ein neues Dokument aus dem Fundus erzeugen. Wäre denkbar.
C.S.: Würde das die Dauer des Generierens sehr verlängern?
R.L.: Ja schon, weil entsprechend der internen Linkanzahl eine entsprechende Menge an Dokumenten erstellt werden müsste.
C.S.: Die Frage ist auch, ob ein Betrachter diese Komplexität überhaupt nachvollziehen könnte und sich durch all diese Seiten klicken würde.
R.L.: Meistens verliert man nach der dritten Navigationsebene sowieso den Überblick. Vielleicht ist es interessanter für einen Benutzer stattdessen einfach wieder mit neuem Titel eine neue Seite zu erzeugen.
C.S.: Oder mit dem gleichen Titel, und die Ergebnisse vergleichen. Ich finde diese Art serieller Produktion sehr spannend.
R.L.: Inzwischen habe ich wieder eine neue Seite generiert, aber mir wird gar nichts angezeigt... Es scheint eine leere Seite produziert worden zu sein.
C.S.: Was sagt der Source-Code? Ist die Seite tatsächlich leer?
R.L.: Nein, sie ist nicht wirklich leer, sondern enthält etwas, was wir nicht sehen können (lacht). Ah ja, wenn ich jetzt einen Browser hätte, der KEINE Frames anzeigen könnte, würden wir den Inhalt sehen... sehr interessant. Können wir gleich mal ausprobieren.
C.S.: Du benutzt ja, wie Andrew Bulhak und die anderen Programmierer von Netzkunstgeneratoren auch, als Programmiersprache PERL. Kannst du kurz erläutern, warum dir diese Programmiersprache für die vorliegende Aufgabe besonderes geeignet erscheint.
R.L.: Es wäre ohne weiteres möglich, den Netzkunstgenerator auch mit anderen Programmiersprachen zu schreiben; einige böten die Möglichkeit, existierende Bibliotheken zu nutzen. Aber die Entscheidung für PERL fiel bei mir schon lange vor dieser Aufgabe und ist ihr übergeordnet. Der Grund dafür ist, dass es einfach Spass macht, mit PERL zu arbeiten! Sogar in der Dokumentation finden sich hier und da kleine Spässchen. Systemprogrammierer und Web-Entwickler haben diese Sprache sehr früh für sich entdeckt, was der Grund für ihre große Verbreitung ist.
Zur Lösung der Aufgabe Netzkunstgenerator bietet das Comprehensive Perl Archive Network (CPAN) einige Module an, die zu Grundbausteinen des Netzkunstgenerators geworden sind. Z.B: das Modul zum Anzapfen der Suchmaschinen wird man dort als "WWW::Search" finden. Zum Herunterladen den Client "LWP::UserAgent". Der verwendete Parser kommt aus der Bibliothek "XML::LibXML", die auch das "Document-Object-Model" (DOM), uns bekannt als Baum, zur Verfügung stellt. PERL und die Module sind freie Software *5 oder damit kompatibel! Was das bedeutet, hat viel mit Freiheit zu tun, aber das zu erklären, würde den Rahmen unseres Gespräches sprengen. Und - ich habe immer etwas PERL-Training nötig.
C.S.: In welchem Zusammenhang hast du in deiner beruflichen Praxis als Programmierer mit vergleichbaren Verfahren zu tun?
R.L.: Dokumente zerlegen und wieder zusammenbauen mit Hilfe von Software passiert z.B in Zeitungsverlagen. Die Software wird dann meist "Content-Management-System (CMS)" genannt und in diesen Fällen als Redaktionssystem eingesetzt. Ich habe erst kürzlich am neuen Konzept und der Realisierung einer größeren WebSite eines grünen Hamburger Verlages mitgearbeitet. Der große Unterschied ist allerdings, dass man im kommerziellen Bereich eine klare Vorstellung davon mitgeteilt bekommt, wie das Ergebnis aussehen soll.
C.S.: Ja, in der Tat ein großer Unterschied.
R.L.: Es gibt in der Regel auch genaue Design-Vorgaben mittels "Templates" etc. Nichtsdestotrotz sind die grundsätzlichen Verfahren ähnlich. Wir suchen nach Inhalten in der Datenbank, und dann werden die Inhalte in ein bestimmtes Aussehen verpackt.
Das Schöne am Netzkunstgenerator ist, wir suchen erst nach Inhalten und rauben dem gefundenen Inhalt seine logische Struktur - z.B. semantische Zusammenhänge. Dann formulieren wir einen komplett neuen Inhalt nach dem Zufallsprinzip aus den Elementen der logischen Struktur. Das Gleiche machen wir mit der Struktur des Dokumentes, welches den Inhalt beheimatet.
Und dann kommt noch der Betrachter ins Spiel, der einen Sinn drin sieht - oder auch nicht.
C.S.: Ich finde ein interessantes Phänomen, als Ergebnis all dieser komplexen Rechenleistung ein Dokument zu bekommen, das nicht darstellbar ist. Theoretisch darf das durchaus passieren. Die Frage ist nur, wie kann man das einem User vermitteln? Eigentlich müsste man in diesem Fall eine Information an den User rausgeben, damit er den Unterschied zwischen einem Nicht-funktionieren und einem nicht-darstellbaren Ergebnis erkennen kann, was eine ganz andere Art des Nicht-funktionierens ist.
R.L.: Fast ein philosophpisches Problem! Wenn wir ein Ergebnis erhalten - und auch ein Nicht-Ergebnis ist ein Ergebnis -, ist dies immer darstellbar, nur in diesem Fall offensichtlich nicht zu sehen. Es kann durchaus sein, daß dieses Kunstwerk zur Irritation des Users führt, der einen Titel eingegeben hat, um eine von ihm unbestimmte Aktion auszulösen und als Ergebnis ein "Kunstwerk" erwartet.
Für solche Fälle wäre es toll, eine Website als WIKI *6 zu haben, mit sogenannten "Friendly Asked Questions", die dem Netzkunstgenerator den ihm gebührenden Kultstatus verschaffen würde.
C.S.: Keine schlechte Idee! Glaubst du, es gibt genügend Verrückte, die sich mit so etwas beschäftigen würden?
R.L.: Warum nicht? Es steckt ein enormes Potential in der Idee des Netzkunstgenerators. Man stelle sich eine sehr große Menge von automatisch generierten Websites vor, die dann von Suchmaschinen indexiert werden. Damit wäre der Kreis geschlossen.
C.S.: Ja toll - Rückkopplung! So lange bis das ganze Netz nur noch aus "Dada-Sites" besteht!
R.L.: Vorausgesetzt die Seiten und die Generatoren würden sich wirklich auf vielen verschiedenen Servern befinden, hätten auch die Suchmaschinen Probleme, zu unterscheiden, ob sie nun eine "Dada-Website" oder eine reguläre erwischt haben. Und wären dann all die "Dada-Seiten" unter den entsprechenden Suchbegriffen registriert, würden die Leute irgendwann keinen vernünftigen Content mehr bekommen. Das als Grenzwertbetrachtung natürlich. Auf dem Weg dahin gibt es noch Zwischenstufen...
C.S.: Eine schöne Vision auf jeden Fall. Wir arbeiten daran.
Fußnoten
*1 Die Dada-engine von Andrew Bulhak ist ein System zur Generierung von Text unter spezifischen Vorgaben. Bei den Vorgaben handelt es sich um ein Regelwerk in der Form einer Grammatik. Die Regeln daraus werden in die Dada-engine geladen, die sie verarbeitet und entsprechende Texte wieder ausgibt. Mit der Bezeichnung "Dada" verweist Bulhak auf das Zufalls-/Collageprinzip der Dada-Künstler.
*2 "Tags" sind in spitzen Klammern stehende HTML-Steueranweisungen.
*3 "Backends" sind nachgestellte Systeme, auf die zugegriffen wird; in diesem Zusammenhang sind es Suchmaschinen.
*4 Das Archiv kann eingesehen werden unter: http://nag.ljudmila.org/?view
*5 Was ist freie Software: http://www.fsfeurope.org/documents/freesoftware.de.html
*6 WIKI ist die Kurzform von WikiWikiWeb, einem offenen Autorensystem für Webseiten. http://de.wikipedia.org/wiki/Wiki