Event Scout

Eine Veranstaltungsseite ist ein schlechtes Datenformat. Dieselbe Angabe steht einmal als Tabelle, einmal im Fließtext eines Newsletters, einmal in einem Kalender, der erst nach dem Scrollen nachlädt. Ein regulärer Ausdruck scheitert daran, ein Sprachmodell nicht. Genau dort, und nur dort, sitzt deshalb das Modell: Es liest die abgerufenen Seiten, entscheidet, was eine künftige Präsenzveranstaltung in Reichweite ist, und füllt für jede die Felder eines festen Schemas.

Alles davor und danach ist gewöhnliches Programm. Welche Quellen heute fällig sind, wie sie abgerufen werden, wann zwei Einträge dieselbe Veranstaltung sind, was nach einem Jahr aus dem Bestand fällt und wie das Dashboard aussieht, steht im Code und nicht in einer Anweisung an das Modell. Das Modell schreibt auch nicht selbst in den Bestand. Es liefert eine Datei, und ein Skript arbeitet sie nach festen Regeln in die Datei events.json ein.

Diese Datei ist der Vertrag. Sie hat ein festgelegtes Schema, sie ist die einzige Quelle der Wahrheit, und jede Ansicht wird aus ihr erzeugt. Eine Datenbank, einen Server oder ein Abonnement gibt es nicht. Daraus folgt der wichtigste praktische Vorteil: Wenn etwas falsch aussieht, lässt sich die Datei öffnen und nachsehen, ob der Fehler beim Lesen oder bei den Regeln liegt.

Dass die Regeln Code sind, heißt nicht, dass sie richtig sind. Die erste Fassung der Entdopplung hielt zwei Einträge schon dann für dieselbe Veranstaltung, wenn sie denselben Link trugen. Viele Veranstalter führen aber alle Termine einer Reihe unter einer einzigen Übersichtsseite, und so verschwanden in einem einzigen Lauf 23 neue Termine in ihren älteren Vorgängern. Aufgefallen ist es, weil der Fehler eine prüfbare Spur hinterließ: vergangene Veranstaltungen, die als heute wiedergefunden markiert waren. Seitdem zählt ein gleicher Link nur dann als Treffer, wenn die Startdaten höchstens drei Tage auseinanderliegen.

Ein Sprachmodell ist gut darin, eine unordentliche Seite zu lesen. Einen Bestand zu führen, ist keine solche Aufgabe.

Eine Quelle, die jede Woche gleich gründlich abgefragt wird, kostet Zeit, auch wenn sie seit Monaten nichts Brauchbares liefert. Deshalb führt jede Quelle eine kurze Ertragsgeschichte: wie viele Veranstaltungen das Modell in den letzten fünf Läufen aus ihr behalten hat. Aus dem Mittelwert ergibt sich eines von drei Bändern. Die Einschätzung des Modells steuert den Zeitplan also nur über eine gezählte Zahl.

Band A wird bei jedem Lauf abgefragt. Dazu gehören Quellen mit einem Mittel von mindestens drei behaltenen Veranstaltungen und solche, die als besonders wichtig eingestuft sind, auch nach einem leeren Lauf. Band B enthält Quellen mit etwas Ertrag oder noch ohne Geschichte; sie sind nach sieben Tagen wieder fällig, höchstens acht je Lauf, die ältesten zuerst. Band C sammelt Quellen, die wiederholt nichts liefern. Sie pausieren sieben, dann vierzehn, dann achtundzwanzig, höchstens dreißig Tage und werden danach erneut versucht, höchstens drei je Lauf.

Eine Seite, die sich laden lässt, aber keine Veranstaltungen zeigt, rückt nur nach hinten. Als defekt gilt eine Quelle erst, wenn sie dreimal hintereinander nicht abgerufen werden konnte. Neue Quellen kommen unter anderem aus einem Register öffentlicher Netzwerke, Acceleratoren, Forschungsinstitute und Cluster in der Region: Hat eine Organisation dort eine Veranstaltungsseite, die noch nicht in der Quellendatenbank steht, kann sie aufgenommen werden. Das Register selbst wird nie als Veranstaltungsquelle gelesen, damit nichts doppelt zählt.