On the social bookmarking site del.icio.us, you can add other users to your network to see their recent bookmarks aggregated on one page. There are two kinds of people in my network: 1. Friends and 2. Users I don’t know personally, but who regularly post interesting links. People who bookmark the same things that I bookmark are likely to have similar interests and are thus likely to continue bookmarking interesting things in the future. Since the information on who bookmarked what URL is public, the process of finding people with similar interests can be automated.

Urban Hafner brought up this idea three years ago, but I could not find an implementation. Yesterday, I wrote a short Python (2.5) script that implements the following ideas:

1. Look at every link in your bookmarks: Who bookmarked the same page? Add these users to a list of people possibly similar to you.
2. The more bookmarks another user has in common with you, the higher your similarity.
3. The smaller the number of people who bookmarked a page, the more significant the fact that another user has this bookmark in common with you.
4. If a user has lots of bookmarks, common bookmarks are less remarkable. The percentage of common links counts.

Here is what you need to do to find people whose interests are similar to yours:

1. Download delicious_mates.py
2. Run python ./delicious_mates.py
3. Wait — this takes some time.

Then, what you will see will look something like this:

andreas> python ./delicious_mates.py
Your del.icio.us username? andreas.s
Your del.icio.us password?

Fetching list of bookmarks ... (485)

Fetching list of users for each bookmark ...
    1. http://en.wikipedia.org/wiki/Langton's_ant (7)
    2. http://www.nytimes.com/2008/05/13/science/13coat.html?_r=2&partner=rssnyt&emc=rss&oref=slogin&oref=login (0)
    3. http://sifter.org/~simon/journal/20080509.2.html (2)
    4. http://www.intercult.su.se/cultaptation/tournament.php (16)
    5. http://www.pnas.org/cgi/content/abstract/0801268105v1 (49)
    6. http://atlas-conferences.com/c/a/n/i/15.htm (0)
	[..]
    480. http://lifeboat.com/ex/main (129)
    481. http://prize.hutter1.net/ (137)
    482. http://www.psg.com/~dlamkins/sl/cover.html (194)
    483. http://www.idsia.ch/~juergen/ (157)
    484. http://sl4.org/wiki/ShannonInformation (1)
    485. http://www.scottaaronson.com/writings/ (13)

Finding 50 candidates from list of 49937 users ...
    rainer (42/9367) ok
    siggiB (36/1006) ok
    fhtagn (35/2471) ok
    anissimov (35/6281) ok
    jbone (41/19982) ok
    invisibleandpink (16/203) ok
    irchans (16/610) ok
    ferrouswheel (14/946) ok
	[..]
    eggywat (14/4290) ok
    Cunya (8/3133) ok
    getpost (13/9787) ok
    hannu (12/3915) ok
    lispmeister (11/2967) ok
    dean.vanniekerk (12/5873) ok
    rgrant (9/1769) ok

Top 50 del.icio.us mates:
username             weight               # common bookmarks   # total bookmarks    % common
——————————————————————————————————————————————————————————————————————————————————————————————
siggiB               54.92937             36                   1022                 3.52250
invisibleandpink     53.05635             16                   203                  7.88177
fhtagn               20.61878             36                   2474                 1.45513
irchans              15.61606             16                   611                  2.61866
fogeli               12.85109             16                   628                  2.54777
ferrouswheel         7.99177              14                   946                  1.47992
rainer               7.60971              43                   9423                 0.45633
anissimov            6.46154              34                   6309                 0.53891
pdorrell             4.10251              19                   3041                 0.62479
jefallbright         3.87392              12                   1193                 1.00587
ladro                3.76458              12                   1526                 0.78637
miguel1626           3.04347              11                   1039                 1.05871
jbone                2.62672              41                   20039                0.20460
hartmut              2.15612              9                    1316                 0.68389
asciilifeform        2.04304              10                   1581                 0.63251
tmalin               1.89627              12                   2181                 0.55021
herrmann             1.84991              21                   5410                 0.38817
jas0nm               1.82646              20                   3808                 0.52521
[..]

If you look at the script, you will find a few settings you might want to change. For each of these holds: The higher you set them, the more time it takes for the script to finish.

• MAX_MATES

  is the maximum number of similar users the script suggests.

• MAX_BOOKMARKS

  defines how many of your bookmarks the script will look at.

• BOOKMARK_FILTER

  defines which types of bookmarks are analyzed. Remove

  , "no"

  from

  {"shared" : [None, "yes", "no"]}

  to exclude private bookmarks.

• MATE_MIN_BOOKMARKS

  sets a minimum for the number of bookmarks a del.icio.us user needs to have before he can be considered to be similar to you.

• MATE_MIN_COMMON

  sets a minimum to the number of bookmarks a user has to have in common with you to be included in the list of similar users.

The script needs two Python modules, the parser BeautifulSoup and Michael Noll’s del.icio.us Python API. If the script does not find one of the modules, it will download the missing module to the current directory and import it from there. If you don’t like this because you believe this is a security nightmare (which it is), don’t run delicious_mates.py install the two modules beforehand.

Do you know some Javascript and have spare time? I would love to see the script converted into a direc.tor-like bookmarklet. The need to download and run a Python script makes finding similar users more complicated than it chould be.

The feature I like best about the online bookshelf LibraryThing is its Unsuggester: Name a book you have read and it suggests those books that are least likely to be on your bookshelf. I like it because it is a means to counteract the temptation to adjust your sources of information such that whatever you read reinforces your point of view. Seeing how easy it is to give in to this temptation, is a script that makes it easier to surround yourself with like-minded people just one more sign of a general trend towards biased, largely isolated online communities?

Das Messverfahren

Lernverfahren wie rekurrente neuronale Netze, Markov-Modelle und genetische Algorithmen sollen akkurate Vorhersagen liefern. Wissenschaftliche Veröffentlichungen sprechen davon, dass der jeweils vorgestellte Algorithmus “auf gewisse Weise” optimal ist. Für das Gebiet der allgemeinen künstlichen Intelligenz ist interessant, zu wissen, welcher Algorithmus allgemein am besten geeignet ist, d.h. für die Vorhersage von Sequenzen, über die wir lediglich wissen, dass sie von einem berechenbaren Prozess generiert wurden und dass einfache Erklärungen wahrscheinlicher sind als komplizierte.

Eine Sequenz ist eine endliche oder unendliche Folge von Symbolen eines Alphabets (z.B. {0, 1}). Die meisten endlichen Sequenzen sind nicht effektiv lernbar, da kein Programm mit im Vergleich zur Sequenz kurzer Beschreibung existiert, das diese Sequenzen deterministisch ausgibt. Das heißt: Die Kolmogorov-Komplexität der meisten endlichen Sequenzen entspricht der Länge der Sequenzen. Für den Vergleich verschiedener Lernalgorithmen beschränken wir uns auf unendliche Sequenzen mit endlich langen Erzeugerprogrammen.

Ein Vorhersagealgorithmus ist dann allgemein besser als ein anderer, wenn er lernen kann, Sequenzen mit höherer Kolmogorov-Komplexität vorherhersagen (und beide einfache Sequenzen gleich gut vorhersagen können). Praktisch jeder Algorithmus wird folgende Sequenz von sehr niedriger Komplexität lernen können:

111111111111111111111111111111111111111111...

Bei etwas höherer Komplexität werden einige Algorithmen Probleme bekommen:

011011100101110111100010011010101111001101...

Hätte man eine Datenbank, die jedes sequenzerzeugende Programm (oder jede Sequenz) sowie die Komplexität der von jedem Programm generierten Sequenz speichert, so könnte man für eine Reihe von Algorithmen Tests durchführen, um herauszufinden, in welchem Umfang und bis zu welcher Komplexität jeder Algorithmus Sequenzen lernen kann. Mit den Ergebnissen dieser Tests ließe sich ein Ranking erstellen, das auf einen Blick verrät, welcher Algorithmus die meisten und komplexesten Sequenzen lernen kann.

Eine solche Datenbank ist unmöglich: Es gibt unendlich viele sequenzerzeugende Programme, die Sequenzen sind unendlich lang und deren Komplexität ist nicht algorithmisch bestimmbar.

Die Menge der sequenzerzeugenden Programme ist eine Teilmenge aller Programme, und diese Menge ist aufzählbar unendlich. Die Kolmogorov-Komplexität ist definiert als die Länge des kürzesten Programms, das eine Sequenz erzeugt. Generiert man alle Programme, angefangen mit dem kürzesten, so ist bekannt, ob bereits ein kürzeres Programm den gleichen Sequenzbeginn (eine festgelegte Anzahl von Zeichen, z.B. 10.000) erzeugt hat oder ob die Länge des gerade betrachteten Programms als Abschätzung der Komplexität der erzeugten Sequenz verwendet werden kann — Abschätzung deshalb, weil nur eine endliche Anzahl der Zeichen zweier Sequenzen verglichen werden können und nach Rice nicht algorithmisch festgestellt werden kann, ob zwei Programme die gleiche Funktion berechnen.

Mit einigen Abschätzungen ist es möglich, Ausschnitte der beschriebenen Datenbank zu erstellen, die in der Komplexität nach oben beschränkt sind:

1. Wir generieren der Reihe nach Turingmaschinen mit leerem Eingabe- bzw. Arbeitsband und nur in einer Richtung beschreibbarem Ausgabeband, angefangen mit der kürzesten.
2. Uns interessieren nur Turingmaschinen, die unendliche Sequenzen generieren:
   • Hält eine Turingmaschine an, so verwerfen wir diese Turingmaschine.
   • Hat eine Turingmaschine nach 10^12 Schritten noch keine 10.000 Ausgabesymbole erzeugt, so verwerfen wir diese Turingmaschine.

   Andernfalls nehmen wir an, dass die aktuelle Turingmaschine eine der Turingmaschinen ist, die eine unendliche lange Sequenz ausgeben (Abschätzung I).

3. Wenn die ersten 10.000 Zeichen der Sequenz, die eine Turingmaschine erzeugt, noch von keiner anderen Turingmaschine erzeugt wurden, speichern wir die Länge der Beschreibung der Turingmaschine sowie die 10.000 Zeichen der Sequenz in einer Datenbank.
4. Die gespeicherte Länge entspricht in etwa der Länge der kürzesten Turingmaschine, die die Sequenz generiert und ist damit ein Maß für die Kolmogorov-Komplexität der Sequenz (Abschätzung II).

Das wiederholen wir, bis die Datenbank “groß genug” ist. In einer 150 GB großen Datenbank lassen sich bei 10.000 Zeichen pro Sequenzabschnitt etwa 100 Millionen unterschiedliche Sequenzabschnitte speichern.

Der kritische Punkt

Ist die Komplexität der einfachsten in der Datenbank gespeicherten Sequenzen so gering, dass diese mit den meisten Vorhersagealgorithmen gelernt werden können und die Komplexität der komplexesten Sequenzen so groß, dass das Lernen der Sequenz mit aktuellen Vorhersagealgorithmen nicht mehr möglich ist?

Werden in dieser Datenbank “interessante” Sequenzen — Sequenzen von nichttrivialer Komplexität — vorkommen? Oder lediglich 50 Millionen unterschiedliche, sich wiederholende Muster? Wie sieht es aus, wenn die einfachsten Sequenzen herausgefiltert und verworfen werden? Wie sieht es aus, wenn stets der Großteil der Sequenzen verworfen wird, die von den Top 20 Algorithmen zuverlässig vorhergesagt werden?

Bei zwei Bandzuständen (0 und 1) und n internen Zuständen gibt es (4*n)^(2*n) verschiedene Turingmaschinen mit einem in beide Richtungen bewegbaren Band. Die Anzahl der Turingmaschinen steigt schon bei wenigen Zuständen sehr schnell an:

1 interner Zustand: 16 TM
2 interne Zustände: 4096 TM (25 unterschiedliche)
3 interne Zustände: 2.985.984 TM (16.400 unterschiedliche)
4 interne Zustände: 4.294.967.296 TM
5 interne Zustände: 10.240.000.000.000 TM
6 interne Zustände: 36.520.347.436.056.576 TM
7 interne Zustände: 182.059.119.829.942.534.144 TM

Nach Stephen Wolfram stößt man auf interessantes Verhalten, sobald man Turingmaschinen mit mindestens vier internen Zuständen betrachtet. Die minimale Zahl der internen Zustände einer Turingmaschine, die eine bestimmte Sequenz berechnet, dient als Maß für die Komplexität der berechneten Sequenz. Ist das Ranking brauchbar, wenn keine Turingmaschinen mit mehr als sieben internen Zuständen betrachtet werden? Lambda Calculus, wie von John Tromp vorgeschlagen, könnte die bessere Wahl sein. Das Ranking könnte sich jedoch auch damit als unbrauchbar erweisen.

Beantwortete Fragen

Bislang ist es schwierig, einige Fragen aus dem Bereich des maschinellen Lernens zu beantworten. Lässt sich ein Ranking für Lernalgorithmen umsetzen, so wird sich das für folgende Fragen ändern:

Wie sieht der aktuelle Stand der Forschung aus? Oder: Das Ranking.

1. Alle bekannteren Vorhersagealgorithmen werden in einer festgelegten Programmiersprache implementiert und zum Ranking hochgeladen.
2. Jeder Algorithmus wird mit allen oder mit einer statistisch relevanten Auswahl an Sequenzen getestet und erhält einen Score zugeteilt, der besagt, für wie viele Sequenzen und bis zu welcher Komplexität der Algorithmus zuverlässige Vorhersagen macht.
3. Ein Ranking wird erstellt, bei dem die Algorithmen mit dem höchstem Score an der Spitze stehen.

Wie gut ist mein Vorhersagealgorithmus?

1. Ein in einer festgelegten Programmiersprache geschriebener Algorithmus wird auf der Website des Rankings hochgeladen.
2. Der Algorithmus wird mit allen oder mit einer statistisch relevanten Auswahl an Sequenzen getestet und erhält einen Score zugeteilt (s.o).
3. Die Leistung des Algorithmus kann dadurch mit der anderer Algorithmen verglichen werden und der Algorithmus kann in die Highscore-Liste aufgenommen werden.

Welcher Algorithmus ist für mein Vorhersageproblem geeignet?

1. Sequenzen, die typisch für das Problem sind, werden auf der Website des Rankings hochgeladen.
2. Alle Algorithmen, die am Ranking teilnehmen, werden auf die hochgeladenen Sequenzen angewendet.
3. Ein nach Korrektheit der Vorhersagen sortiertes, problem-spezifisches Ranking wird ausgegeben.

Offene Fragen

• Soll die Programmlänge mit in die Berechnung des Scores eines Algorithmus einbezogen werden oder soll es lediglich ein generelles Limit für alle Programme geben?
• Welche Limits sollen für Laufzeit und Programmlänge gesetzt werden?
• Wie lange sollen die Sequenzabschnitte sein, die in der Datenbank gespeichert werden? 10.000 Zeichen?
• Wie sollen die Sequenzabschnitte in Lernsequenz (die den Algorithmen präsentiert wird) und Testsequenz (die vorherzusagen ist) aufgeteilt werden? Wie lang soll der vorherzusagende Abschnitt sein?
• Wie wird die Vorhersage bewertet? Gelten nur komplett richtige Vorhersagen?
• Sollen auch die kürzeren Ausgaben von anhaltenden Turingmaschinen miteinbezogen werden?
• Ein praxistauglicher Algorithmus könnte stark von zusätzlichen Annahmen über seine Umgebung abhängig sein. Ideal sind Vorhersage- und Komprimierungsalgorithmen nur für jeweils eine einzige Wahrscheinlichkeitsverteilung an Eingaben. Ob ein Algorithmus, der für die allgemeinste berechenbare Wahrscheinlichkeitsverteilung an Eingaben ideal ist, auch in der wirklichen Welt brauchbar ist, ist nicht geklärt.
• Ist es zweckmäßiger, probabilistische Sequenzen und Vorhersagealgorithmen statt exakter Algorithmen zuzulassen?
• Wie wird der Score berechnet? Zählen Sequenzen mit niedrigerer Komplexität mehr oder weniger? Wie wird ein Vorhersagealgorithmus bewertet, der zwar komplexe Sequenzen vorhersagen kann, aber bei sehr vielen Sequenzen von niedriger Komplexität fehlschlägt?
• Welche Implementation eines universellen Computers ist am sinnvollsten? Turingmaschinen? Lambda Calculus?

Fazit

Marcus Hutter hat in seiner Doktorarbeit bewiesen, dass die optimale Vorgehensweise einer künstlichen Intelligenz darin besteht, nach einer beliebigen Anzahl von Beobachtungen der Umgebung das kürzeste Programm zu finden, das diese Beobachtungen vorhersagt und anzunehmen, dass die Umgebung durch dieses Programm kontrolliert wird. Verbesserte allgemeine Vorhersagealgorithmen sind demnach mit Fortschritt auf dem Gebiet der künstlichen Intelligenz gleichzusetzen.

Alles, was gemessen wird, verbessert sich. Ich schlage vor, eine Datenbank mit Sequenzabschnitten und zugehöriger (geschätzter) Kolmogorov-Komplexität anzulegen, diese Sequenzen von verschiedenen Lernalgorithmen vorhersagen zu lassen und den Erfolg der Algorithmen in einem Ranking sichtbar zu machen.

Ist diese Idee realistisch?

Abstract

I suggest a general method offering a public and private API for existing Django models. New generic views will simplify data retrieval and modification via different web services in a resource-centric REST architecture, providing model data in formats such as XML, JSON and YAML with very little custom code.

Implementation

The most widely used browsers don't support PUT and DELETE in web forms without using AJAX, therefore it is impossible to achieve a pure REST implementation. Nonetheless a more RESTful resource-centric approach makes sense: With a unique hyperlink address for every resource, resource discovery from content becomes much easier. With all resources sharing a common interface, programs written in any language can talk to Django instances in a standardized way. The partial lack of browser support for PUT and DELETE can be compensated by adding an extra hidden field to forms that carries the method information.

The code that tells Django which web service should be provided for which model at which URL will not to be attached to the individual model classes but will live at the view level. There are two reasons for this:

1. REST is only one way of looking at a Django application and therefore should not be part of the underlying model.
2. There is no one-to-one mapping between resources and models. Resources have more to do with the user interface than with the underlying database structure. Sometimes it will be sufficient to apply the CRUD actions to models, but sometimes there will be the need for more complex resources (e.g. one resource that consists of several related models, service discovery). It is important to me that there is an obvious way of using both the generic views and custom developments consistently in one Django project.

I will solve this by writing a general Resource class as an interface. Each method of Resource raises a Http404 exception by default. Custom resources inherit from Resource and may implement the methods __call__ (thus providing the equivalent of current view functions), create, retrieve, list, update, delete, get_create_form and get_update_form (cf. djangocollection). The ModelResource class that covers all the cases where there is a one-to-one mapping between a model and a resource inherits from the class Resource.

When using the ModelResource class we need to be able to set a few options:

• Which data should be accessible?
• Which CRUD actions should be possible?
• Which model fields should be visible?
• Which type of authentication is required?
• How should the output look like (xml, json, html, yaml, ...)?

I imagine the urls.py to look like this (similar to a draft by Jacob Kaplan-Moss):

In order for our resource implementation to be REST-friendly, each resource needs to have a unique URL. If the content format is not specified by the URL and if there is more than one content format per app, looking at the HTTP headers may be sufficient to choose which content to deliver (we could set output_format to restapi.DETECT_FORMAT).

The functionality of the new generic RESTful views will comprise a large part of the functionality of the current generic create_update and list_detail views. This includes the ability to supply the views with a filtered queryset, pagination, response mimetype, allow_empty, post_save_redirect and post_delete_redirect.

In contrast to the current generic views the ModelResource class will not use templates by default. Instead, in order to follow the DRY principle, they could call a user-supplied output function (e.g. xml_response, json_response) depending on which type of response (xml, json, ...) to return. I'm still thinking about how the most elegant solution will look like. I'll be happy to hear suggestions.

Another issue that still needs to be resolved is how to get authentication right. The consensus of ticket #115 seems to be that HTTP Basic Authentication over SSL is "secure enough" but that the risk of people not using SSL is quite high. Both public and private web services will be possible.

Web development shouldn't be monotonous. Setting up APIs can be. I'd like to automate this as far as possible without taking away the freedom to extend or replace the API with more complex solutions.

Existing Code

There exists a fair amount of code that might be useful for this project.

There is john@sneeu.com who wrote at ticket #2553:

I've written a RESTful API (similar urls to the 'oldforms' Admin), it needs a bit of a tidy up, and a few more tweaks but I'm more than happy for it to be incorporated in to Django in any way.

Jason Huggins mentions in the discussion of ticket #115 (Models CRUD via web services):

I have a fair enough amount of code already written for this ticket. If possible, I'd like a branch in subversion set up so I can check in my code and we can start talking about real example code.

Jacob Kaplan-Moss to whom the ticket is assigned may have started writing some code that can be used for both REST and RPC. He wrote:

Jason (and others): if you've got code that's not attached to this ticket or to #356, #547 or #552 please attach it to this one as I'm going to try to get some work done on this Any Day Now™.

More recently, Adam Smith has started working on django-restful-model-views which intends to make it easier to create ReSTful Web applications with Django. In the current stage this is still more of a proof-of-concept, but the code written by Adam Smith might turn out to be a good point to start.

The wsgicollection-inspired project djangocollection which provides a set of generic RESTful urls for all the models of a project and a GenericCollection which uses the django generic views illustrates a few interesting and relevant ideas, too.

Before getting started I will talk to those who have written possibly useful code and to the Django community in order to find out how my suggested approach can be improved and how much reusable code already exists.

Benefits to Django

There will be a standard interface for applications to communicate with Django projects. Making it easier for Desktop applications to use Django as a server-side backend will encourage Desktop applications to use Django as a backend. Yay.

An API that can return data in JSON format will make AJAX integration much easier — both for the admin app and for Django users who complain about AJAX not being as easy as with competing frameworks.

The value of having a dead easy way to get data in and out of Django databases is obvious. Let's make extending existing applications with a fully-fledged REST API a matter of less than five minutes.

Success Criteria

1. A few lines of code in urls.py are sufficient to make model data CRUD-accessible via XML and JSON.
2. It is possible to create custom API resources that don't correspond directly to models. These should be integrated seamlessly into the rest of the API.

Roadmap

1. Assess together with those who have already written similar code whether it makes sense to start from scratch. Get feedback from the community on issues such as how ModelResource should generate different output formats and how authentication should look like.
2. In-depth planning "on paper".
3. Initialize a restapi branch.
4. Implement the Resource "interface" class.
5. Implement the ModelResource class and an elegant way to return output in at least xml and json.
6. Add authentication.
7. Write and perform unit tests.
8. Prepare the code to be merged to trunk. The Django API will likely change before v1.0. Some of the things that will be improved in a possibly backwards-incompatible way and that might play a role for this project are validation, serialization and the authentication framework.

About me

I'm a 21 year old bachelor student of Cognitive Science at the University of Osnabrück in Germany. When I'm not in Osnabrück, I live in the small town of Dinkelscherben which is located in Bavaria. After finishing school about two years ago I decided to postpone University and spent the next year developing web applications instead. At that time I had two years of Python experience. Django became — and still is — my web framework of choice.

During that year, I spent quite some time making sure I understood how Django works under the hood. I participated in the Django discussion groups, wrote a few patches and submitted a few tickets. My largest Django project to date is the e-learning application Mindpicnic which is fairly popular in Germany.

I have been planning to add a RESTful API to Mindpicnic for about as long as the project exists. I'm committed to seeing this proposal become reality. I believe I would enjoy getting more involved with the Open Source community a lot.

My proposal got accepted, the latest source code is available at Google Code.

Zunächst stellt sich jedoch die Frage: Wozu brauche ich überhaupt einen Text-Generator? Abgesehen davon, dass die Antwort in den meisten Fällen "überhaupt nicht" lauten dürfte, fallen mir spontan einige Anwendungsmöglichkeiten ein (eine sinnvoller und ernstgemeinter als die andere):

• Reports, Aufsätze oder Facharbeiten in letzer Minute
• Täglich neue Versionen von "Alice im Wunderland" [5]
• Spaß mit Usenet-Gruppen [4]
• Suchmaschinenspam
• Sinnentleerte Poesie
• Antworten auf Nigeria-Connection-Scam-Mails [6]
• E-Mail-Antworten auch in stressigen Zeiten [6]
• ... just for fun

Das Prinzip eines Text-Generators

Das Prinzip hinter solchen Generatoren ist relativ simpel: Ein Text wird zunächst daraufhin analysiert, welche Wörter mit welcher Wahrscheinlichkeit auf welche anderen Wörter folgen. Betrachten wir als Beispiel das Wort "die" in diesem Artikel (so weit er bis jetzt fortgeschritten ist): Mit jeweils 25% Wahrscheinlichkeit folgen die Begriffe "Antwort", "Zeile ", "andere)" und "Frage".

Werden diese Wahrscheinlichkeiten für jedes Wort gespeichert, so lässt sich -- ausgehend von einem Startwort -- ein neuer Text Wort für Wort aufbauen. Für jedes Wort wird zufällig ein Nachfolgewort ausgewählt; die vorher bestimmten Wahrscheinlichkeiten entsprechen dabei den Wahrscheinlichkeiten für die Auswahl der Nachfolgewörter.

Im Wikipedia-Artikel zum Thema Markov-Ketten [2] wird das zunächst mit einer für Nicht-Mathematiker abschreckenden Formel und dann folgendermaßen formuliert:

(..) das heißt, dass die Wahrscheinlichkeit für den Zustand zum Zeitpunkt t+1 nur von dem Zustand zum Zeitpunkt t abhängt. Dies bezeichnet man als Gedächtnislosigkeit oder auch Markow-Eigenschaft.

Verwenden wir als Ausgangstext (wie bereits zu Beginn dieses Artikels) das "Law of Accelerating Returns" von Ray Kurzweil [3], so sieht das Ergebnis zum Beispiel folgendermaßen aus:

Evolution has continuously accelerated. The subsequent emergence of the first step, the first technology-creating species resulted in the environment in power and maintain a technology-creating species, the next generation's design, and of information does not the overall "power" of data from one stage of accelerating returns pertains to biological brains. # A recording information is predictable. Noise is to create new generations of other innovations).

Was auf den ersten Blick interessant aussehen mag, entpuppt sich bei genauerem Hinsehen als völliger Unsinn.

Der Markov-Algorithmus

Wie wird das Modell der Markov-Ketten nun konkret als Algorithmus umgesetzt? Ein kurzes Script in der Programmiersprache Python [1] soll uns hier als Beispiel dienen.

Zunächst wird die Textdatei markov.txt eingelesen und Wort für Wort in einer Liste gespeichert:
#!/usr/bin/python
# -*- coding: cp1252 -*-
from random import random
 
f = open('markov.txt')
TextIn = f.read()
f.close()
 
TextIn = TextIn.replace('\n', ' ')
TextIn = TextIn.split(' ')
TextIn = [n for n in TextIn if n not in '']


Jetzt steht die Analyse des Textes an: Für jedes vorkommende Wort speichern wir in WortDict, wie oft welche anderen Wörter direkt auf dieses Wort folgen:
WortDict = {}
 
for w in range(len(TextIn)-1):
    if (TextIn[w] != ''):
        if not WortDict.has_key(TextIn[w]):
            WortDict[TextIn[w]] = {}
        if not WortDict[TextIn[w]].has_key(TextIn[w+1]):
            WortDict[TextIn[w]][TextIn[w+1]] = 1.0
        else:
            WortDict[TextIn[w]][TextIn[w+1]] += 1.0


Die Anzahl des Aufeinanderfolgens bestimmter Wörter wird in Wahrscheinlichkeiten umgerechnet:
for (Wort, NextDict) in WortDict.items():
    # Gesamtzahl nächster Wörter berechnen
    TotalCount = 0
    for (NextWort, Count) in NextDict.items():
        TotalCount += Count
    # Zahl für jedes nächste Wort durch Gesamtzahl teilen
    for (NextWort, Count) in NextDict.items():
        WortDict[Wort][NextWort] = WortDict[Wort][NextWort]/TotalCount


Schließlich können wir einen neuen Text mit einer dem Ausgangstext ähnlichen Wahrscheinlichkeitsverteilung der Wortfolgen erstellen. CurWort legt fest, mit welchem Wort der Text beginnen soll, LenText die maximale Anzahl an Wörtern. Zur Auswahl des jeweils nächsten Wortes werden die Einzel-Wahrscheinlichkeiten für sämtliche Möglichkeiten als Aufteilung des Bereichs [0;1] gesehen und festgestellt, wo in diesem Bereich sich die Zufallszahl x befindet. Der so gewählte Bereich legt das nächste Wort fest.
CurWort = 'Evolution'
LenText = 30
Text = CurWort
 
for n in range(200):
    x = random()
    ProbSum = 0
    for (NextWort, Prob) in WortDict[CurWort].items():
        if (x >= ProbSum) and (x < ProbSum+Prob):
            Text += " " + NextWort
            CurWort = NextWort
        ProbSum += Prob
 
# Ausgabe des Textes bis zum letzen Punkt.
print Text[:Text.rfind('.')+1]


Beispiele für generierte Texte

Was könnte ein solcher Markov-Prozess nun mit inhaltlich wertvollen Texten wie der Cyberkultur-Reihe [7] des französischen Philosophen Pierre Lévy anstellen? Na, zum Beispiel das:

Die Verbindung von virtuellen Welten, durch die Bildschirme. Dann entdeckte ich, daß die Computernetze zugunsten der modernen Demokratie gekämpft ... und institutionalisiert, die Papierseiten mit der Verteilung ausgehend von allem in dem Cyberspace mehr aus einer Totalität, deren Kommunikationspraxis konnte eine kulturelle Universum an ihren Hervorbringungen haben wir uns in den Seiten anderer Dokumente verbindet, weil er ist, neue Verkaufsargumente. Symmterisch dazu verdammt, den traditionellen Medien legitimiert wird? Diejenigen, die bestehenden Infrastrukturen zu schaffen, Information darstellt, sollte gemäß dem begrenzten Programm der großen Menge von Gruppen, Beziehungsstile zwischen den Cyberspace beeinflussen.

Je kürzer der Text, um so mehr wird das Ergebnis dem Ausgangstext ähneln. Versuchen wir es für etwas kreativere Textgestaltung deshalb mit Kants im Textformat ganze 1.2 MB einnehmender "Kritik der reinen Vernunft":

Der hypothetische Urteil vom Gegenstande weiß, die Gesetzgebung erforderlich ist. Es besteht das Vermögen vorkommt, Unterarten, unter den Dingen vorhergeht, darin von der Frage: ob man sie die allererst möglich sei, aus irgendeiner Grundkraft, soviel gepriesener und künftigen Zeit existieren. Woran erkennt die Unabhängigkeit von der des intelligiblen Charakter haben, wie es ihm unterworfen ist. Denn der außer mir für Erscheinungen keine bestimmten Erfahrung hineinbringt, müssen mir etwas vorstellen, daß die mir immer sein, niemals etwas Unmögliches, und die transzendentale Ästhetik*.

Alles klar?

Wer das gerne mit eigenen Texten versuchen möchte, kann entweder direkt mit der Python-Datei spielen [8] oder sich an der Online-Version von Elje.net [9] versuchen.

[1] The Python Programming Language
[2] Wikipedia: Markow-Kette
[3] Kurzweil’s Law (aka "the law of accelerating returns")
[4] Markov-Texte im Usenet: Mark V Shaney
[5] Fun with Markov Chains
[6] Fun things to do with a Markov Process
[7] Telepolis: Cyberkultur
[8] AI Playground Download: Markov.py
[9] Elje.net: Markov Text Generator

Ein paar Worte zur Vorgehensweise: Googles Usenet-Archiv, Google Groups [1], erlaubt es, die Suche auf bestimmte Zeiträume einzuschränken. Mit einem kurzen Script, z.B. in der Programmiersprache Python [2], kann so für jedes Jahr zwischen 1980 und 2005 eine Suche nach einem bestimmten Begriff durchgeführt und die Anzahl der Suchergebnisse gespeichert werden. Stellt man die Suchergebnis-Zahlen nun als Diagramm dar, so lässt sich die zeitliche Entwicklung der Popularität eines Themas recht deutlich ablesen.

Um aussagekräftigere Ergebnisse zu erhalten wurden zum Teil mehrere Suchen pro Thema durchgeführt -- etwa für einen englischen und den entsprechenden deutschen Begriff -- und die Anzahl der Suchergebnisse dann addiert.

Die Ergebnisse des Experiments (ein Klick auf die Grafik öffnet eine Version in höherer Auflösung):

Künstliche Intelligenz

Suchbegriffe: "Künstliche Intelligenz" und "Artificial Intelligence".

Nanotechnologie

Suchbegriffe: "Nanotech" und "Nanotechnology".

Neuronale Netze

Suchbegriffe: "Neural Network", "Neural Networks", "Neural Net", "Neural Nets", "Neuronale Netze".

Singularität

Suchbegriffe: "Singularity" und "Singularität".

Übersicht

Nanotechnologie - Singularität - Künstliche Intelligenz - Neuronale Netze

Natürlich lassen sich Newsgroups auch nach den Namen von Personen durchsuchen. Versuchsweise habe ich die Popularität des einflussreichen Science-Fiction-Autors Vernor Vinge und des Singularitätsaktivisten Eliezer Yudkowsky im Laufe der Zeit analysiert:

Vernor Vinge

Eliezer Yudkowsky

[1] Google Groups
[2] The Python Programming Language

Im letzten Teil der "Daten, Daten, Daten"-Serie [1] wurde das Konzept der Web Services vorgestellt. Zur Erinnerung:

Was für uns Menschen Websites sind, das sind für Computer Web Services - Internet-Dienste, die in der Regel von größeren Firmen wie Amazon, Google oder eBay angeboten werden und Unmengen an Informationen in (vornehmlich) maschinenlesbaren Formaten liefern.

Im Gegensatz zu den meisten Websites werden die Informationen bei Web Services als XML-Dateien abgerufen. XML (Extensible Markup Language) ist "ein Standard zur Erstellung strukturierter, maschinen- und menschenlesbarer Dateien." [2]

Diese XML-Dateien werden über das SOAP-Protokoll (Simple Object Access Protocol) vom Server abgerufen und lokal weiterverarbeitet. Erfreulicherweise bleibt es dem Software-Entwickler dabei oft erspart, sich mit den Hintergründen von SOAP, XML und Co zu befassen, wenn bereits Module für die Programmiersprache und den Web Service der Wahl existieren.

Für die Google-API trifft das zu. Ob Visual Basic .Net [3], PHP [4] oder Python [5]: Für die Einbindung der API braucht es nicht mehr als ein paar Zeilen Code. Wie schon im Artikel über die Amazon Web Services verwende ich auch hier zur Demonstration der Möglichkeiten wieder Python, da der Code vergleichsweise einfach zu lesen ist und mit PyGoogle [5] ein exzellentes Modul für die API existiert.

Doch was ist mit der Google-API [6] möglich, welche Daten stellt Google bereit? Neben Suchergebnissen in maschinenlesbarer Form sind die zwischengespeicherten Cache-Seiten, die Google von fast jeder Website erstellt, sowie Googles Rechtschreibkorrektur aufrufbar.

Die Suchergebnisse sind dabei der interessanteste Part. Sie enthalten unter anderem die Anzahl der Resultate für eine bestimmte Anfrage (estimatedTotalResultsCount), die Zeit, die die Suche in Anspruch nahm (searchTime) und die einzelnen gefundenen Seiten mit URL, Titel (title), Ausschnitt aus der Seite (snippet), Dateigröße (cachedSize) und Kategorie (directoryCategory).

Ein Beispiel sagt mehr als tausend Worte, also versuchen wir uns an folgender Fragestellung: Welches der Jahre 1985-2009 wird am häufigsten im Internet erwähnt? Und wie oft wurde es im Vergleich zu den anderen Jahren erwähnt? Unser Beispielprogramm soll also Suchvorgänge nach den Phrasen "year 1985", "year 1986", ..., "year 2009" durchführen und jeweils die Anzahl der Gesamtsuchergebnisse ausgeben.

In Python sieht das folgendermaßen aus:import google, sys
google.setLicense('YourLicenseKey')
 
for k in range(1985,2010):
    try:
        gData = google.doGoogleSearch('\'year ' + \
str(k)+'\'')
        print k, \
str(gData.meta.estimatedTotalResultsCount).rjust(10)
    except:
        print 'Fehler:', sys.exc_info()[0]
        break;

Ist das PyGoogle-Modul installiert und ein gültiger Lizenz-Schlüssel angegeben (kann unter [8] angefordert werden), so wird das Programm der Reihe nach die Phrasen-Suchen auführen und die Suchergebnisse ausgeben:1985     117000
1986     111000
1987     126000
1988     136000
1989     148000
1990     216000
(...)
2003    2100000
2004    2840000
2005    1280000
2006     149000
2007      65400
2008      40100
2009      21400

Das Jahr 2004 wird also zurzeit am häufigsten erwähnt, etwas öfters als das Jahr 2000. Natürlich lassen sich aus der Google-API gewonnene Daten auch graphisch darstellen:

Ein weiteres Beispiel: Wir interessieren uns für alle Websites mit .de-Domain, die in den Top-50 Suchergebnissen für das Stichwort "Neuronale Netze" auftauchen. Eine alphabetisch sortierte Liste der Webadressen soll ausgegeben werden, wobei keine Domain doppelt vorkommen soll. Mit der Google-API kein Problem:import google, sys
 
google.setLicense('YourLicenseKey')
Results = []
 
for k in range(0,50,10):
    try:
        gData = \
google.doGoogleSearch('neuronale netze',k,10)
        for n in gData.results:
            Results.append(n.URL)
    except:
        print 'Fehler:', sys.exc_info()[0]
        break;
 
Results = [n[7:n.find('/',7)] \
for n in Results if (n.find('.de') != -1)]
Results = [n for i,n \
in enumerate(Results) if n not in Results[:i]]
 
Results.sort()
for n in Results:
    print n

Das Python-Programm führt 5 Suchvorgänge mit jeweils 10 Ergebnissen aus und fügt für jede URL eines Suchergebnisses der "Results"-Liste einen neuen Eintrag hinzu. Tritt ein Fehler auf (z.B. keine Internetverbindung verfügbar), so bricht das Programm ab und gibt eine entsprechende Fehlermeldung aus.

Nachdem die Ergebnisse erfolgreich abgerufen wurden, wird die "Results"-Liste auf die Einträge eingegrenzt, bei denen ".de" in der URL vorkommt. Gleichzeitig wird das "http://" am Anfang sowie der Verzeichnisstrang am Ende der URL entfernt.

In der nächsten Zeile des Programms werden sämtliche doppelten "Results"-Einträge gelöscht, danach sortiert und per "print" angezeigt. Die Ausgabe des Programms sieht dann in etwa so aus:
fuzzy.cs.uni-magdeburg.de
home.zait.uni-bremen.de
itb.biologie.hu-berlin.de
rfhs8012.fh-regensburg.de
www-lehre.inf.uos.de
www-ra.informatik.uni-tuebingen.de
www.andreas-mielke.de
www.artifin.de
www.documanager.de
www.faes.de
(...)
www.medi-informatik.de
www.neuro.ct-webspace.de
www.physik.uni-regensburg.de
www.vdi.de
wwwhni.uni-paderborn.de
wwwmath.uni-muenster.de
wwwuser.gwdg.de

Natürlich lässt sich die Google-API auch hervorragend zum Zwecke der Suchmaschinen-Analyse und Optimierung (Search Engine Optimization, SEO) verwenden. Das nächste Beispielprogramm dieses Artikels soll anhand der ersten 50 Suchergebnisse für den Begriff "SEO" feststellen, welchen Wert Google auf das Vorkommen des Suchbegriffes in Titel und URL legt bzw. bei welchem Anteil der Suchergebnisse der Suchbegriff in Titel/URL vorkommt.

Der Python-Quellcode ist weitgehend selbsterklärend:
import google, sys
 
google.setLicense('YourLicenseKey')
InTitle = 0
InURL = 0
KeyWord = 'python'
NumResults = 50
 
for k in range(0,NumResults,10):
    try:
        gData = google.doGoogleSearch(KeyWord,k,10)
        for n in gData.results:
            m = n.URL.lower()
            if (m.find(KeyWord) != -1):
                InURL += 1
            m = n.title.lower()
            if (m.find(KeyWord) != -1):
                InTitle += 1
    except:
        print 'Fehler:', sys.exc_info()[0]
        break;
 
print 'Keyword: ',KeyWord
print 'Keyword in URL: ',InURL,'von',NumResults, \
'(', float(InURL)/float(NumResults)*100, '% )'
print 'Keyword in Titel: ',InTitle,'von',NumResults, \
'(', float(InTitle)/float(NumResults)*100, '% )'
Nachdem eine Suchergebnis-Liste mit 10 Ergebnissen geladen wurde, werden für jedes Element URL und Titel in Kleinbuchstaben umgewandelt und nach dem Schlüsselwort durchsucht. Wird es gefunden, so werden die Variablen InURL bzw. InTitle um 1 erhöht. Vor das Programm endet, werden die Variablen als ganze Zahlen sowie als Prozentzahlen ausgegeben. Konkret sieht das so aus:
Keyword:           seo
Keyword in URL:    33 von 50 ( 66.0 % )
Keyword in Titel:  37 von 50 ( 74.0 % )
 
Keyword:           search
Keyword in URL:    14 von 50 ( 28.0 % )
Keyword in Titel:  25 von 50 ( 50.0 % )
 
Keyword:           python
Keyword in URL:    27 von 50 ( 54.0 % )
Keyword in Titel:  42 von 50 ( 84.0 % )

Erweiterungen sind durchaus denkbar. Das Programm könnte beispielsweise die Prozentzahlen für die ersten 50 Suchergebnisse mit denen der Suchergebnisse 50-100 vergleichen und auf Unterschiede überprüfen. Weiterhin wäre es denkbar, dass ganze Wortlisten automatisch abgearbeitet werden und die Ergebnisse in einer mit Tabellenkalkulationsprogrammen lesbaren (CSV-)Datei gespeichert werden.

Die Analyse von mehr als 20 hochfrequentierten Suchwörtern ergab folgenden Graph, die X-Achse gibt dabei die Nummer der Suchergebnis-Seite an:

Die meisten Seiten, die in den Top-200 für so hart umkämpfte Schlüsselwörter wie "advertising", "business", "estate", "software" oder "marketing" vorkommen, haben das entsprechende Keyword im Titel. Den Unterschied kann die Verwendung von Keywords in der URL machen: Hier unterscheiden sich die Top-20 vom Rest.

Zum Vergleich der Graph, der sich bei der Analyse 20 weniger begehrter Keywords wie zum Beispiel "singularity", "tschebyschew" oder "backpropagation" ergab:

Als Demonstration der Möglichkeiten der Google-API zur Suchmaschinenanalyse sollte das genügen. Was hier an Code vorgestellt wurde, ist das Ergebnis von 15 Minuten Arbeit -- mit etwas größerem Zeitaufwand sind die Möglichkeiten schier unbegrenzt.

Zum Abschluss noch der Quellcode für ein Programm, das vor allem für Website-Betreibern von Nutzen ist: Ein Ranking-Checker. Das Programm ähnelt dem zuvor beschriebenen Analyse-Programm, überprüft aber anstatt des Vorkommens des Suchworts in URL/Titel das Vorkommen der eigenen URL in den Suchergebnissen. So lässt sich schnell feststellen, auf welcher Position der Suchergebnis-Seiten die eigene Website für bestimmte Keywords zu finden ist.
import google, sys
 
google.setLicense('YourLicenseKey')
KeyWord = 'singularitaet'
MySite = 'aiplayground.org'
NumResults = 100
ResFound = 0
 
for k in range(0,NumResults,10):
    try:
        gData = google.doGoogleSearch(KeyWord,k,10)
        rc = 0
        for n in gData.results:
            rc += 1
            m = n.URL.lower()
            if (m.find(MySite) != -1) and (ResFound == 0):
                ResFound = k+rc
                break;
    except:
        print 'Fehler:', sys.exc_info()[0]
        break;
 
print 'Website: ',MySite
print 'Keyword: ',KeyWord
print 'Position: ',ResFoundDie Variable "k" gibt dabei jeweils die aktuelle Seite der Suchergebnisse an (10, 20, 30, ...), die Variable "rc" die Position auf dieser Seite (1, 2, 3, ...). Wird die eigene Website in der URL eines Suchergebnisses gefunden, so wird die Gesamt-Position, d.h. die Summe aus "k" und "rc", in der Variablen "ResFound" abgespeichert, weitere Suchvorgänge abgebrochen und die Position auf dem Bildschirm ausgegeben.

Ein Ablauf des Programms kann zum Beispiel so aussehen:
Website: aiplayground.org
Keyword: singularitaet
Position: 52Die Verwendung dieses Ranking-Checkers ist allerdings nur begrenzt hilfreich: Google verwendet für die API einen anderen, nicht ganz so umfangreichen Index an Websites als für die Suchergebnisse, die auf Google.com zurückgegeben werden. Wer sein genaues Ranking erfahren will und das nicht per Hand tun will, ist also gezwungen, die Suchergebnisse direkt von Googles HTML-Seiten einzulesen.

[1] Daten, Daten, Daten: Amazon Web Services
[2] Wikipedia: XML
[3] Google APIs und VB.Net
[4] Google APIs und PHP
[5] Google APIs und Python: PyGoogle
[6] Google Web APIs
[7] Google Web APIs LicenseKey anfordern
[8] Google: Mehr als 250.000 Server

Im Februar 2004 setzte Philipp Lenssen [1] ein Experiment auf, um genau das auszuprobieren.

Zu diesem Zweck generierte er per Algorithmus 5.000 Seiten mit zufälligen Wortsequenzen als digitalem DNA-Ersatz und stellte sie unter dem Projektnamen "Memecodes" ins Netz [2]. Diese Seiten, die neben einer zufälligen Auswahl von Wörterbuch-Einträgen auch Satzzeichen, Bindewörter, einige bekannte Markennamen sowie die Namen berühmter Persönlichkeiten enthalten, wurden bald darauf von Suchmaschinen besucht und in deren Index aufgenommen.

Wenn nun ein Besucher über Google eine der Seiten aufruft, zählt diese als im Sinne der Evolution erfolgreich und darf Nachkommen erzeugen: Per Datenbank wird eine neue, zufällig veränderte Version dieser Seite erstellt und auf der Memecodes-Startseite verlinkt. Diese Seite wartet nun darauf, erst von Suchmaschinen indiziert zu werden, dann von einem Besucher angeklickt zu werden und wiederum eine Nachfolgeseite zu erschaffen -- so schließt sich der Kreis.

Wird eine Seite lange Zeit von keinem Besucher aufgerufen, so "stirbt sie", d.h. sie wird gelöscht. Die Suchanfragen der Suchmaschinen-Benutzer entsprechen demnach der Nahrung in natürlichen Ökosystemen.

Nach einer Weile ist zu erwarten, dass sich mehr und mehr Seiten auf bestimmte ökologische Nischen konzentrieren, indem sie Wortkombinationen enthalten, die im Internet noch kaum abgedeckt sind. Nur bei solchen Wortkombinationen erscheinen die Memecodes-Seiten unter den ersten Suchergebnissen, und nur solche Seiten "überleben".

Je länger das Experiment läuft, umso interessanter das Ergebnis. Bleibt es lange genug bestehen, so könnten sich aus dem Haufen zusammengewürfelter Zufallssätze mit der Zeit sogar bedeutungstragende Inhalte entwickeln.

Seit Beginn des Experiments sind neun Monate vergangen, und einige der Seiten können bereits auf 4 Generationen an Vorfahren zurückblicken. Ein Blick auf die Statistik der Suchanfragen [3], die zu den Memecodes-Seiten führten, zeigt unter anderem folgende Wortkombinationen -- die Zahl vorweg gibt die Anzahl der Suchanfragen an:
63 sphagnum esplanade lyrics
62 marshmallow blowgun
56 lockout buster
48 WWW£¬5757£¬MY ¡£COM
44 feel the wrath of salivating mushroom (...)
43 shush bikini
40 seagull sandwich riddle
34 caftan marocain
33 sandboy revelation
33 incubus torrent
32 labial infusion
32 girdle.us
29 reticulated stingray
24 Sphagnum Esplanade lyrics
24 lockout buster schematic diagram


Vorläufiges Fazit: Die Idee, Webseiten durch Evolution zu erzeugen ist der näheren Betrachtung wert, das Prinzip der Evolution als Bestandteil von Algorithmen sowieso und das Experiment zeigt auch schon erste Erfolge. Doch auch der Nachteil von auf Evolution basierenden Verfahren zeigt sich hier: Sie brauchen sehr viel Zeit. Nicht umsonst sind zwischen dem Auftauchen der ersten einzelligen Lebewesen und dem der ersten Menschen etwa 3.5 Milliarden Jahre vergangen.

[1] Google Blogoscoped
[2] Memecodes
[3] Memecodes Statistiken