Von der API bis zur Prüfabfrage

Der Datenweg

Schritte 1 bis 4 sind das Originalprogramm, Stand des Laufs: 30. August 2026. Schritt 5 ist die Ergänzung für dieses Portfolio. Beide Teile sind getrennt gehalten – der Originalcode wurde nicht angefasst.

Wie ein Bild ausgewählt wird

Die Auswahl ist ausdrücklich nicht „die ersten zwei Treffer". Jedes Foto bekommt Punkte, und jeder Punkt trägt seine Begründung mit in den Bericht. Die Reihenfolge der Kriterien ist die eigentliche Entscheidung – sie legt fest, was was überstimmt.

Danach kommt die Regel, die im Bericht am häufigsten sichtbar wird: Erst wird je Beobachtung das beste Foto genommen, und nur wenn keine zweite Beobachtung übrig bleibt, ein zweites Foto derselben. Deshalb stammen bei allen 189 Arten die beiden Bilder aus verschiedenen Beobachtungen – Prüfabfrage 7 rechnet das nach.

Gegenüber der API verhält sich das Programm zurückhaltend: eine Sekunde Pause zwischen zwei Anfragen, höchstens 50 pro Minute bei erlaubten 60, vier Versuche mit wachsender Wartezeit. Im dokumentierten Lauf kam über 396 Anfragen keine einzige Abweisung wegen Überlastung zurück.

Das Datenmodell

Vier Tabellen. Was in den Quelldaten nicht vorkommt, steht auch nicht im Modell: Ein Anki-Deck mit botanischen Namen kennt keinen deutschen Trivialnamen, und welche Suchvariante am Ende gegriffen hat, hält kein Metadatensatz fest. Zwei leere Spalten mitzuführen wäre die unehrlichere Lösung gewesen.

Der Import ist wiederholbar und nicht additiv: Ein zweiter Lauf legt die Datei neu an, statt Zeilen zu verdoppeln. Fehlende Werte bleiben NULL – nichts wird stillschweigend ersetzt, denn genau diese Lücken sollen die Abfragen ja finden.

Dass die Tabelle observations genauso viele Zeilen hat wie images, ist kein Modellierungsfehler, sondern das Ergebnis der Auswahlregel: Weil je Bild eine eigene Beobachtung gewählt wurde, steht hinter jedem Bild genau eine. Ein Modell, das das nicht abbilden könnte, könnte Prüfabfrage 7 nicht stellen.

Die acht Prüfabfragen

Jede Abfrage hat einen Sollwert. Bestanden heißt: Die Abfrage findet nichts. Befund heißt: Sie findet etwas – und das ist dann das Ergebnis, kein Fehler des Programms.

Die acht Abfragen ausführen Prüfbericht (CSV)

Der Befund: sechs fehlende Dateien

Der Download-Bericht des Programms meldet 378 Bilder vorhanden, Ziel 378. Im Bildordner liegen aber 372 Dateien. Die Abfrage, die Metadaten gegen Dateibestand hält, benennt die Differenz:

SELECT i.filename, p.scientific_name, i.license_code
FROM images i
JOIN plants p ON p.plant_id = i.plant_id
WHERE i.file_present = 0
ORDER BY p.scientific_name, i.selected_rank

Es sind nicht sechs beliebige Dateien. Es sind genau die Bilder der drei Arten, die das Programm im Problembericht selbst als REVIEW markiert hat. Spiraea × arguta und Spiraea × vanhouttei fallen bei iNaturalist auf dasselbe Taxon zusammen – ohne Gegenmaßnahme hätten beide Arten identische Fotos bekommen. Das Programm hat das nach dem Durchlauf erkannt, für die zweite Art auf Ersatzfotos ausgewichen und beide Fälle zur Prüfung vorgelegt. Lonicera pileata* wurde auf das breitere Taxon Lonicera ligustrina aufgelöst.

Die achte Abfrage zählt, statt zu urteilen

Bei 36 der 189 Arten weicht der Name bei iNaturalist vom Namen im Deck ab. Als Zahl ist das wertlos: Bei 15 davon ist es nur die Schreibweise – das Deck führt Prunus avium* mit einer Merkhilfe, iNaturalist schreibt Prunus avium. Solche Zusätze werden vor dem Vergleich gestrichen, in SQL wie in der Browserfassung nach derselben Regel.

Übrig bleiben 21 Fälle, in denen der Name selbst ein anderer ist. Auch diese sind nicht gleichartig, und genau deshalb bewertet die Abfrage sie nicht:

Die ersten drei Zeilen sind unbedenklich, die letzten beiden nicht – und diesen Unterschied kann keine SQL-Abfrage entscheiden. Sie kann nur die Liste erzeugen, die jemand ansehen muss. Deshalb hat Abfrage 8 als einzige keinen Sollwert und den Status gezählt statt bestanden. Eine Prüfung, die hier ein Urteil fällte, wäre genau die Sorte Automatisierung, die hinterher niemand mehr auffängt.

Zweiter Fall: eine Rechtsdatenbank

Dieselbe Arbeitsweise an einer ganz anderen Datenbank. Das Rechtsinformationssystem des Bundes (RIS) führt österreichisches Recht mit Fassungsständen. Wer daraus ohne Fassungsangabe zitiert, zitiert möglicherweise aufgehobenes Recht – und merkt es nicht.

Das Protokoll ist ein Skript, kein Text: Derselbe Aufruf fragt dieselben Dokumente erneut ab. Kommt ein anderer Fassungsstand zurück, hat sich die Rechtslage geändert – genau dafür steht das Abfragedatum im Kopf der Datei.

Rechercheprotokoll (Textdatei)

Quelle: Rechtsinformationssystem des Bundes, OGD-Schnittstelle v2.6, data.bka.gv.at/ris/api/v2.6/. RIS-Daten stehen unter CC BY 4.0, Republik Österreich. Rechtsverbindlich ist allein der kundgemachte Text im Landesgesetzblatt, nicht die konsolidierte Fassung im RIS.

Woher die Regeln für die Rechtsrecherche stammen

Nicht aus einem Jusstudium. Sie stammen aus einem Werkzeug, das ich gebaut habe – einem Claude-Skill für österreichisches Recht, entstanden für eine Wirtschaftsrecht-Studentin an der WU Wien. Die Arbeit daran war nicht juristisch, sondern die Sorte Arbeit, die eine Fachanwendung braucht: festlegen, welche Quelle wann gilt, und absichern, dass das Werkzeug lieber schweigt als plausibel danebenliegt.

Zum Skill gehört ein Bundle, das den RIS-Zugang installierbar macht. Der Server darin ist nicht meiner: Es ist das unveränderte npm-Paket ris-mcp-ts (MIT) von philrox / Honeyfield-Org. Eigene Arbeit war der Vergleich von vier verfügbaren Servern nach Lizenz, Wartungsstand und Abdeckung, die begründete Auswahl und die Verpackung.

Grenzen dieses Belegs