Bot für openlibrary.org

Ein umfassender Bot-Entwicklungsprozess für OpenLibrary.org folgt strengen infrastrukturellen und rechtlichen Vorgaben. Die Plattform basiert auf der Philosophie des Internet Archive; verlangt jedoch höchste Akribie hinsichtlich Rate Limits, Account-Nomenklatur, Freigabeprozessen und Code-Repositorien.

Der strukturierte Arbeitsplan für das Bot-Projekt ist in folgende Phasen gegliedert:

Phase 1: Aufgabenstellung & Anwendungsfall

• Zieldefinition: Klärung der genauen Operation (z. B. automatisierter Metadaten-Import, Dubletten-Säuberung oder automatisiertes Auslesen lokaler Bestände).
  
  
• Datenfluss: Festlegung der Quelle (lokale CSV/JSON/Markdown-Dateien) und des Ziels (OpenLibrary-Instanz) sowie der zu modifizierenden Entitäten (Editions, Works, Authors).
  
  

Phase 2: Spezifikation & Regelkonformität (OpenLibrary Policy)

• Account-Nomenklatur: Registrierung eines separaten Bot-Accounts. Der Benutzername muss auf Bot enden (z. B. AtestaLibraryBot), um Bot-Aktivitäten im öffentlichen Änderungsprotokoll (Recent Changes) sauber filtern zu können.
  
  
• Rechteerteilung: Erstellen eines GitHub-Issues im offiziellen OpenLibrary-Repository zur Vergabe von Bot-Privilegien und Aufnahme in die API-Gruppe durch Administratoren (z. B. @mekarpeles).
  
  
• Bibliotheken-Standard: Strikte Nutzung der offiziellen Python-Bibliothek openlibrary-client für Schreiboperationen anstelle manifester HTTP-POSTs.
  
  
• Rate Limiting & User-Agent: Drosselung auf maximal 1–2 Anfragen pro Sekunde sowie Mitsenden eines spezifischen User-Agent-Headers mit Kontaktmöglichkeit.
  
  

Phase 3: Architektur & Entwurf

• Modulare Struktur:
  
  
  • Config Module: API-Keys, User-Agents, Pfade und Credentials.
    
    
  • Fetch/Parse Module: Lesen und Validieren der Quelldaten.
    
    
  • Client Integration Module: Einbindung von openlibrary-client zur Interaktion mit den Datensätzen.
    
    
  • Logging & Error Handling Module: Abfangen von HTTP 429 (Rate Limit), 503 (Service Unavailable) und Erstellung von Protokolldateien.
    
    
• Ordner-Layout: Auslegung nach den Vorgaben des offiziellen Bot-Repositorys (Skript, README.md, requirements.txt und optionale Quelldateien).
  
  

Phase 4: Voraussetzungs-Check (Environment)

• Systemumgebung: Linux-Laufzeitumgebung mit Python 3.x.
  
  
• Versionskontrolle: Lokales git und GitHub-Account für den PR-Workflow.
  
  
• Berechtigungen: Verifizierter Bot-Account mit Admin-Freigabe.
  
  

Phase 5: Implementierung (Schreiben des Skripts)

• Hinweis: Gemäß den Richtlinien erstelle ich im aktuellen Schritt keinen Code.
  
  
• Implementierung der Transformationslogik, der Fehlerbehandlungs-Schleifen und der openlibrary-client-Anbindung.
  
  

Phase 6: Lokal-Test & Trockenlauf (Dry-Run)

• Integration eines DRY_RUN-Modes im Skript (Simulieren von Lese- und Schreibzugriffen ohne tatsächliche API-Mutationen).
  
  
• Testen gegen kleine, dedizierte Datensätze zur Vermeidung fehlerhafter Massenänderungen.
  
  

Phase 7: GitHub-Workflow & Code-Review

• Fork & Branch: Forken des offiziellen Repositories internetarchive/openlibrary-bots, Erstellen eines Feature-Branches.
  
  
• Commit-Richtlinie: Quelldateien, aus denen der Bot Metadaten liest oder generiert, müssen zwingend mit im Repository committet werden.
  
  
• Pull Request (PR): Einreichen des Code-Requests bei GitHub.
  
  
• Strikte Regel: Der Bot darf erst nach expliziter Durchsicht und Freigabe durch die OpenLibrary-Maintainer live betrieben werden.
  
  

Phase 8: Live-Betrieb & Überwachung

• Ausführung unter kontinuierlicher Protokollierung (Logging) und Überwachung der Server-Antworten.
  
  
• Nachbereitung und Archivierung der Protokolle im Repository.