Ein neuer Ansatz für die Langzeitarchivierung von Twitter-Accounts
von Michael Jerusalem (Stadtarchiv Münster),
Marc Malwitz (LWL.IT Service Abteilung)
und Peter Worm (Stadtarchiv Münster)
Einleitung
Vor rund einem Jahr hat das Stadtarchiv Münster damit begonnen, sich im Vorfeld der Kommunalwahl mit der Archivierung von Twitter Accounts (insbesondere des Oberbürgermeisters) zu beschäftigen[1]. Der damalige Beitrag war bewusst als Werkstattbericht gedacht, der zunächst die grundsätzliche Frage der Archivwürdigkeit und dann signifikante Eigenschaften sowie Erhaltungsziele diskutierte. Der Abgleich mit den damals vorhandenen Lösungswegen machte eines klar: Es gab keinen „Königsweg“, mit dem alle Erhaltungsziele vollständig abgedeckt wurden. Die am Schluss skizzierten technischen Maßnahmen lieferten zumeist provisorische Ergebnisse oder mussten miteinander kombiniert werden, um alle Erhaltungsziele abzudecken. Den höchsten Abdeckungsgrad versprach noch die Verwendung des Webrecorder.io und eine Sicherung des Ergebnisses als WARC-Container[2]. Bei der Durchführung verursachte das Harvesten damit einen erheblichen „Klickaufwand“, umso größer war die böse Überraschung, als es an die Validierung des im Anschluss erzeugten WARC-Containers ging[3]. Alle Versuche mit der Online- und der Desktop-Version des Webrecorder.io zufriedenstellende Ergebnisse zu erzeugen, scheiterten leider.
TWINT als erfolgversprechender Ansatz
Ein alternativer Lösungsweg musste her. Hier half uns eine Reaktion auf den Archive 2.0 Beitrag von Michael Schmalenstroer weiter[4]. Er verwies auf gute Erfahrungen mit dem in der Programmiersprache Python geschriebenen Harvesting-Tool TWINT[5]. Nach kurzer Orientierung über die Möglichkeiten ließen sich damit bereits überzeugende Ausgaben von Follower- und Following-Listen als JSON erzeugen[6]. Es stellte sich die Frage, ob mit dieser Software nicht auch die Timeline inklusive der Kommentare zu den Tweets gesichert werden könnte. Nativ war das zunächst nicht möglich – in der Grundfunktionalität
(twint -u [username])
fehlten bei den Exporten die Bilder und Mulitmediadateien genauso wie die Kommentare. Aber es gab drei Lichtblicke:
- TWINT nutzt zur Erstellung seiner Berichte nicht die Twitter-API, die eine strenge Zuordnung der Informationen zu den Accounts des Tweetenden vornimmt, und eine Verknüpfung der Kommentare zu den Tweets, auf die sie sich beziehen, nicht zulässt, sondern eine alternative Methode.
- Die Software ist quelloffen und kann durch eigene Skripte angepasst und erweitert werden.
- Ein neuer Mitarbeiter, Herr Marc Malwitz, nahm seine Tätigkeit beim Kundensupport von DIPS.kommunal auf und war bereit, sich in die Frage und in die Programmierung einer geeigneten Exportschnittstelle einzuarbeiten. Herr Malwitz beschäftigte sich zu dem Zeitpunkt bereits mit der Frage einer Web-Archivierung und prüfte, ob Werkzeuge wie Heritrix oder Brozzler erfolgreich zum Einsatz kommen könnten. Auch Twitter-Scraper wie GetOldTweets3[7], twitter-scraper[8] oder das bereits erwähnte Twint wurden evaluiert. Letztendlich fiel die Wahl wegen der guten Dokumentation, der aktiven Entwicklergemeinde hinter dem Projekt und nicht zuletzt wegen der guten Erfahrungen seitens des Stadtarchivs Münster auf Twint.
Schon die ersten Versuche ermöglichten außer dem Tweet selbst eine Ausgabe der Kommentare (zumindest der ersten Ebene) und der angehängten Bilder, die in einem separaten Ordner abgelegt wurden (vgl. Abb. 1). Aus technischer Perspektive erfasst das von Herrn Malwitz entwickelte Python-Skript zunächst mittels Twint die Daten der Tweets des zu archivierenden Nutzers. Mit diesen „Rohdaten“ erzeugt das Skript dann einen Zwischenstand in JSON-Dateien[9], über die anschließend ein Bericht erzeugt und in HTML ausgegeben wird. Die Darstellung ist nicht ganz unähnlich zur Twitter-Timeline und hält sich vor allem strikt an ihre inhaltiche Logik.
Die weitere Entwicklung konzentrierte sich darauf, die Antworten der zweiten (und tieferen) Ebene(n) rekursiv auszulesen und die zentrale JSON-Datei zu einer Baumstruktur mit sämtlichen Tweets auszubauen. Da während des Harvestens viele separate Twint-Durchläufe erforderlich sind, wurde es erforderlich, die Performanz des Prozesses zu optimieren. Dabei war hilfreich, dass das Skript nun mit einem “Cache” aus JSON-Dateien arbeitete, um die eingelesenen Inhalte nicht immer erneut erfassen zu müssen.
Eine wesentliche Hürde war die korrekte Zuordnung der Antworten zu den vorherigen Autoren. Da Twint die Abhängigkeiten nicht anhand von Parent-IDs aus dem Quelltext auslesen kann, ist ein Abruf aller Antworten an den entsprechenden Nutzer sowie eine Filterstrategie aus Vergleich der Tweet-ID, der Benutzernamen und der Zeitstempel erforderlich.

Abbildung 1: Erste Exportversuche mit dem TWINT-Skript: die Ausgabe erfolgt als HTML-File.

Abbildung 2: Heutiges Ergebnis des TWINT-basierten Exports.
Features des TWINT-basierten Exports
Der Export erreicht nun aus archivischer Sicht deutlich vielversprechendere Ergebnisse. Tweets und deren Struktur werden vollständig rekonstruiert. Die Darstellung des Beitragstextes mit Hashtags und Links sowie den Gefällt-mir-Angaben und Retweets stellt kein Problem dar. Grafiken und Fotos weist das Skript durch den eindeutigen Verweis zur Twitter-ID mit Dateinamen dem jeweiligen Beitrag zu. Notfalls können die Bilder, welche durch den Export im Datenverzeichnis separiert zusammengestellt sind, durch Kennzeichnung der UUID auch manuell einem Tweet zugeordnet werden. Kommentare können nun in allen Ebenen chronologisch eingruppiert und durch Einrückung abgebildet werden. Lediglich bei der Archivierung von bewegten Bildern stieß das Skript an seine Grenzen. Videos und Gifs kann man auf diese Weise deshalb nicht überführen.
Der TWINT-basierte Export liefert eine festgelegte Datenstruktur, welche letztlich die Grundlage zur Langzeitarchivierung bildet. Die Rohdaten werden als JSON gespeichert und Bilder als JPEG separiert. Die gesammelten Hashtags des Exports stellt das Skript in Form einer einfachen Text-Datei zusammen. Diese können als Vorstufe für eine inhaltliche Erschließung beim Ingest genutzt werden. Die von TWINT abgerufenen Daten visualisiert das Skript letztlich im HTML-Format. Die Formatierung orientiert sich zwar an der Dialogstruktur von Twitter, aber die eigentliche Optik sollte durch die Archivierung zusätzlicher Screenshots der Website realisiert werden (Vgl. Abb. 2 und 4). Eine übergeordnete CSV-Datei ermöglicht schließlich die Anreicherung der Beiträge mit Metadaten für den Ingest ins Langzeitarchiv.

Abbildung 3: Datenverzeichnis nach Export

Abbildung 4: Originäres Layout der Twitter Website
Twitter-Archivierung – eine kontinuierliche Herausforderung
Generell ist zu sagen, dass die Archivierung komplexer Websites wie der Social-Media-Site Twitter ein anspruchsvolles Thema darstellt. Es handelt sich bei derartigen Sites nicht mehr um klassische Webauftritte, die primär der Verbreitung von Informationen dienen. Vielmehr handelt es sich um interaktive Anwendungen, welche die Beteiligung der Nutzer als zentrales Element ihres Geschäftsmodells innehaben. Die Betreiber streben ein Maximum an Bedienungsfreundlichkeit an und betreiben große Anstrengungen, ihre Dienste über möglichst viele Kanäle anzubieten. Zugleich findet eine starke Personalisierung statt: Inhalte werden in Bezug auf individuelle Interessen der Nutzer gefiltert und sortiert ausgeliefert.
Auf die technische Ebene bezogen bedeutet dies, dass moderne Websites wie Twitter komplexe Gebilde darstellen. Die Oberflächen im Browser bestehen häufig aus modularen, javascript-basierten Frontends, welche schnell an neue Anforderungen und Erwartungen angepasst werden. Die Inhalte werden über Schnittstellen von einer Vielzahl Server bezogen. Selbst wenn keine explizite Anmeldung stattfindet, wird stets eine Sitzung gestartet, um die technische Anmeldung an den Frontend-Schnittstellen zu gewährleisten. Die gleichen Schnittstellen speisen auch Smartphone-Apps oder andere Clients. Das komplette System wird permanent weiterentwickelt und optimiert. Eine derartige Microservice-Architektur erlaubt partielle Aktualisierungen, ohne eine komplett neue Website in Betrieb nehmen zu müssen. Das Gegenstück zu diesem Konzept sind eher monolithische Web-Auftritte, welche fast immer über Content-Management-Systeme betrieben werden.
Für die Technik der Archivierung stellen Web-Architekturen wie bei Twitter eine Herausforderung dar. Das Harvesting-Modul Twint wird stets an die aktuelle Twitterversion angepasst, Änderungen bei Twitter müssen stetig analysiert, der Twint-Code angepasst werden. Dies kann zeitweise zur Fehlfunktion des Skripts führen, bis ein Update der Twint-Entwickler freigegeben und in die Python-Umgebung eingespielt ist. Insofern ist das Skript nie komplett fertig, sondern es bedarf analog zur Website permanent einer gewissen Pflege. Soweit es unsere Kapazitäten erlauben, stellen wir an dieser Stelle Informationen und aktualisierte Versionen des Skripts zur Verfügung.
Wir hoffen, mit diesem Ansatz dennoch ein hilfreiches und interessantes Werkzeug zu bieten. Sehr interessiert sind wir an Ihren Rückmeldungen, an Anregungen und Berichten über die durchgeführten Archivierungen.
Sie finden das als ZIP gepackte Skript sowie eine Anleitung unter folgendem Link: https://cloud.lwl.org/s/PykLmmBBL9cLRay
Wir wünschen viel Erfolg beim Einsatz unseres Skripts!
Anleitung/Technische Umsetzung
Das Skript zum Export der Tweets besteht primär aus der Logik zur Verknüpfung der Antworten mit den Ursprungstweets, dem Harvesten nicht-textueller Inhalte sowie der Funktionalität zur strukturierten Ausgabe. Twint wird als Harvesting-Modul eingebunden, durch ein Mapping ist aber gegebenenfalls auch eine andere Komponente möglich. Das Skript basiert auf Python und kann plattformunabhängig eingesetzt werden.
Die folgende Anleitung beschreibt die Inbetriebnahme auf einem Windows-System. Mit anderen Betriebssystemen wie Linux ist eine Installation in grundsätzlich gleicher Weise durchzuführen, wobei die zugrundeliegenden Komponenten hier einfach über die Distribution installiert werden können.
Voraussetzungen
Für den eingesetzten Rechner gelten einige Bedingungen, unter denen die Installation und der Betrieb durchgeführt werden:
- Berechtigung zur Installation von Software
- Kein Proxy, da das zugrundeliegende Projekt Twint in der derzeitigen Version keine Proxyunterstützung bietet
- Keine Modifikation der SSL-Zertifikate durch zwischengeschaltete Netzwerkkomponenten, da ansonsten Fehler wegen nicht vertrauenswürdiger Quellen erzeugt werden.
Eine Inbetriebnahme des Skripts ist zwar auch ohne diese Rahmenbedingungen möglich, erfordert aber den Eingriff in die Dateien von Twint oder die Implementierung eines Context-managers. Von diesem Vorgehen wird abgeraten, da die Gefahr von man-in-the-middle-Angriffen gegeben ist.
Installation der Grundlagen
Python Laufzeitumgebung
Entwickelt und getestet wurde das Skript unter Python 3.8.6.
Laden Sie sich die aktuelle Version der Python3-Laufzeitumgebung für Ihr System herunter. In der Regel dürfte der „Windows x86-64 executable installer“ zum Einsatz kommen. Die offizielle Seite für Python-Downloads finden Sie hier: https://www.python.org/downloads/.
Andere Versionen – etwa 3.8.6 für Windows 7 – finden Sie unter folgender Adresse: https://www.python.org/ftp/python.
Starten Sie den Installer und aktivieren Sie das Kontrollkästchen „Add Python 3.8 to PATH“. Eine Installation der Laufzeitumgebung mit den Standardoptionen genügt. Falls Sie keinen individuellen Anpassungen benötigen, wählen Sie „Install Now“.

Abbildung 5: Start des Installationsvorgangs für Python 3.8.6
Unter Windows wird die Dateiendung „py“ durch den Installationsvorgang mit Python verknüpft.
Weitere Pakete
Neben der Laufzeitumgebung werden noch weitere Python-Pakete sowie deren Abhängigkeiten benötigt, ansonsten erzeugt das Skript Ausgaben wie „No module named …“.
Python verwendet den Paketmanager PIP zur Installation zusätzlicher Pakete. PIP ist in der Python-Installation enthalten und wird über die Kommandozeile (Tastenkombination Windows-R, cmd) aufgerufen. Wo die ausführbare Version liegt, können Sie über folgenden Befehl ermitteln:
py -m pip –-version
Im Ergebnis sehen Sie die genutzte Versionsnummer sowie den Pfad auf PIP.

Abbildung 6: Pfad auf pip, hier invers markiert
Den Pfad benötigen Sie, um PIP zu starten. Das Schema dabei ist stets
py <Pfad auf pip> install <Paket>
Ein beispielhafter Befehl für eine Paketinstallation ist
py C:\Users\Malwitz\AppData\Local\Programs\Python\Python38\Lib\site-packages\pip install twint
Abbildung 7: Installation eines Pakets, im gezeigten Fall ist kein Update nötig.
Falls es bei der Paketinstallation zu Fehlermeldungen wegen nicht vertrauenswürdiger Quellen kommen sollte, können Sie pip mit dem zusätzlichen Parameter „–trusted-host“ aufrufen:
--trusted-host pypi.org --trusted-host files.pythonhosted.org
Dieses Vorgehen birgt jedoch das Risiko kompromittierter Installationspakete. Wir empfehlen es daher nicht.
Folgende Pakete müssen installiert werden:
- twint
- bleach
- pillow
- unicodecsv
Das Paket twint erfährt in einem späteren Schritt zwar ein Upgrade, wegen der Abhängigkeiten wird die Version von PyPi aber schon jetzt installiert.
GIT
Da aktuelle Updates für Twint über GIT bereitgestellt werden, benötigen Sie eine installierte GIT-Umgebung. Laden Sie das passende Installationspaket unter https://git-scm.com/downloads herunter und installieren Sie die Umgebung. Im Installationsdialog können Sie die Standardeinstellungen beibehalten.
Twint-Upgrade
In diesem Schritt wird die neueste verfügbare Version von Twint installiert. Der unten beschriebene Vorgang muss stets dann durchgeführt werden, wenn die Entwickler eine überarbeitete Version bereitgestellt haben.
Legen Sie zunächst das Verzeichnis an, in welchem Sie das Twiter-Skript später ablegen möchten. Beispielsweise können Sie ein Verzeichnis „bin“ in Ihrem Nutzerverzeichnis anlegen:
C:/Users/Malwitz/bin
Wechseln Sie mit cd in das erzeugte Verzeichnis.
Mittels der im vorigen Schritt installierten GIT-Umgebung können nun Upgrades für twint bezogen werden. Über PIP wird die neueste Version (Version 2.1.21, Stand 13.01.2021) per „git clone“ bei github heruntergeladen und als Upgrade im Unterverzeichnis src installiert:
py C:\Users\Malwitz\AppData\Local\Programs\Python\Python38\Lib\site-packages\pip install --user --upgrade -e git+https://github.com/twintproject/twint.git@origin/master#egg=twint
Der Befehl aktualisiert, falls erforderlich, auch die abhängigen Pakete. Falls kein neueres Paket vorliegt, wird „Requirement already satisfied“ ausgegeben.
Ausführung des Skripts
Kopieren Sie das Python-Skript „twitter-report.py“ in das zuvor erzeugte Verzeichnis.

Abbildung 8: Inhalt Ihres Verzeichnisses zu diesem Zeitpunkt.
Wechseln Sie in das Verzeichnis und starten Sie das Skript mit dem Aufruf nach dem Schema
py twitter-report.py –u <Twitter-Nutzername>
Beispiel: py twitter-report.py –u lwl_aktuell

Abbildung 9: Ausgabe des Skripts nach dem Start
Falls der Benutzer nicht existiert, wird ein leerer Report erzeugt. Das Verhalten ist identisch zu einem Szenario der Erfassung eines Accounts, der noch keine Inhalte publiziert hat.
Folgende Parameter werden unterstützt:
Parameter | Bedeutung | Beispiel |
---|---|---|
-u –user |
Benutzername des zu harvestenden Twitter-Accounts. Hier ist der Benutzername und nicht der volle Name gemeint. |
-u lwl_aktuell |
-s –since |
Datum, welches den Zeitpunkt des ältesten zu harvestenden Tweets markiert. Format: JJJJ-MM-TT | -s 2021-01-01 |
-t –till |
„till“ Datum, welches den Zeitpunkt des neuesten zu harvestenden Tweets bestimmt. Format: JJJJ-MM-TT | -t 2021-01-31 |
-c –cache |
Erzwingt die Nutzung der Daten aus dem Cache. Die Option ist sinnvoll, falls ein vorheriger Durchlauf mit einem Netzwerkfehler abgebrochen ist. Standardmäßig werden alte Cache-Informationen verworfen. |
-c (ohne weitere Angaben) |
-h –help |
Erzeugt eine kurze Übersicht über die Parameter | -h (ohne weitere Angaben) |
Einen Abbruch des Skriptlaufs erreichen Sie mit der Tastenkombination Ctrl-C.
Das Twint-Modul erzeugt Ausgaben auf dem Bildschirm, die sich unter die normalen Ausgaben des Skriptes mischen. Diese Ausgaben werden nicht abgefangen. Es ist daher wahrscheinlich, dass zwischendurch ein Hinweis „No more tweets. Scraping will stop now.“ in der Ausgabe erscheint. Diese Ausgabe ist darauf zurückzuführen, dass innerhalb eines Schleifendurchlaufs der Rekursion keine weiteren Antworten für einen Tweet ermittelt werden können. Die Meldung ist unkritisch.

Abbildung 10: Twint-Ausgabe während des Harvestens von Antworten.
Falls Sie das Harvesten desselben Twitter-Accounts mehrfach durchführen möchten, können Sie auch ein Batch-Skript herstellen und bei Bedarf modifizieren. Batch-Skripte sind einfache Textdateien, welche die auch in der Kommandozeile verwendeten Befehlen enthalten. Die Dateiendung ist „.bat“. Das Batch-Skript kann bequem per Doppelklick gestartet werden. Im folgenden Beispiel würden die Tweets des Accounts lwl-aktuell aus Cachedaten für das Jahr 2021 neu verarbeitet:

Abbildung 11: Inhalt eines Batch-Skriptes
Beachten Sie bitte, dass ein Skriptlauf recht viel Arbeitsspeicher benötigen kann. Bei Stresstests ist es vorgekommen, dass auf einem Rechner mit 4GB RAM wegen des RAM-Bedarfs die Netzwerkverbindung weggebrochen ist. Zudem kann die Erzeugung der HTML-Datei am Ende etwas Zeit in Anspruch nehmen. Falls Sie Probleme mit Skriptabbrüchen haben, versuchen Sie bitte, den zu erfassenden Zeitraum mittels der Parameter s und t einzuschränken und mehrere separate Durchläufe zu machen.
Ergebnis
Jeder Durchlauf erzeugt folgende Verzeichnisse:
Cache-Verzeichnis
Das Verzeichnis wird benötigt, um Daten zwischenzuspeichern. Dateien in diesem Verzeichnis sind temporär und dienen nur der Beschleunigung des Skripts.
Ausgabe-Verzeichnis
Innerhalb des Verzeichnisses „output“ werden die erzeugten Daten abgelegt.
Im Verzeichnis Output werden für jeden Durchlauf weitere Unterverzeichnisse abgelegt. Sie werden nach dem Schema <Twitter-Nutzername>_<Erzeugungsdatum_JJJJ-MM-TT> benannt. Falls mehrere Zeitschnitte innerhalb eines Tages benötigt werden, muss das Verzeichnis manuell umbenannt werden.

Abbildung 12: Ausgabe eines Durchlaufs
„Ausbeute“ einer Archivierung
Der Inhalt des im Durchlauf erzeugten Verzeichnisses besteht primär aus dem Datenverzeichnis, wie weiter oben bereits erläutert wurde. Die Inhalte mit ihren Details aus technischer Perspektive sind:
- Der Report im Format html5 (fmt/471). Die HTML-Datei ist so aufgebaut, dass sie sämtliche für das Layout und die einheitliche Darstellung benötigten Informationen enthält. Schriften sind eingebettet. Graphiken und Fotos sind verlinkt, die Datei muss also „neben“ den Graphikdateien liegen. Die Graphiken werden verkleinert dargestellt, ein Klick auf die Graphik öffnet das Original.
- Alle erfassten Graphiken und Fotos in den Formaten jpg (fmt/43), png (fmt/13) und gif (fmt/4), je nach Nutzung durch den Autor der Tweets. Die Dateien werden direkt von Twitter heruntergeladen und nicht modifiziert.
- Die Struktur der Tweets im Format JSON (fmt/817). Das JSON-Format (JavaScript Object Notation) ist ein standardisiertes, textbasiertes Austauschformat für strukturierte Informationen. Die Dateien sind beispielsweise mit dem Browser Firefox gut lesbar. Das Archivierungsskript erzeugt eine Baumstruktur aus Schlüsseln und Inhalten der Tweet-Daten. Falls Antworten existieren, werden sie in Objekten unter dem Schlüssel „replies“ abgelegt. Weitere Datentypen sind Nummern, Zeichenketten und Boolean-Werte. Die JSON-Datei enthält sämtliche Rohdaten des Harvestens. Mit ihrer Hilfe lassen sich beliebige andere Layouts für Reports erstellen oder Auswertungen durchführen.
Von einer über die Twitter-Api erzeugten JSON-Datei (fmt/1311) unterscheidet sich die hier erzeugte Datei dadurch, dass weniger Informationen zu den Tweets selbst, dafür aber die Antworten enthalten sind.
- Eine Textdatei (x-fmt/111) mit den gefundenen Hashtags, sortiert in absteigender Häufigkeit.
Sofern Grafiken oder Fotos erfasst wurden, wird auf der Ebene des Datenverzeichnisses die oben bereits erwähnte Metadatendatei zu den Dateien erzeugt. Die CSV-Datei ist zur Nutzung im Rahmen des Ingests mit dem Programm PIT.plus ausgelegt.

Abbildung 13: Metadaten-Datei für die Bilder und Grafiken
Zusätzlich wird eine Log-Datei mitgeschrieben, in der die vom Skript durchgeführten Vorgänge protokolliert werden. Die Logdatei liegt im Verzeichnis des Skripts.
Archivierung der Ergebnisse in DiPS.kommunal
Die erzeugte Ausgabe ist zur Verarbeitung durch das Werkzeug PIT.plus („PreIngestTool“) der Langzeit-Archivierungslösung DiPS.kommunal ausgelegt. Das Programm ermöglicht die Archivierung unstrukturierter Dateisammlungen. Es enthält eine erste Formatvalidierung, dient der Strukturierung der inhaltlichen Einheiten und nimmt die Angaben zu einer Lieferung entgegen.
Das Datenverzeichnis kann als Grundlage für ein neues PIT.plus-Projekt genutzt werden. Zu bearbeiten sind zuvor einige Inhalte, deren Formate nach derzeitigem Stand nicht für einen Ingest zugelassen sind. Dabei handelt es sich um folgende Dateien bzw. Formate:
Der Report im Format HTML5
Obwohl die HTML-Datei auf einem offenen Standard basiert und ohne externe Abhängigkeiten aufgebaut ist, wird sie im Zuge des Ingests zusätzlich in eine zweite Repräsentation in das Format PDF/A-2 konvertiert. Um die Struktur des Layouts nicht zu unterbrechen, sollten dabei Seitenumbrüche durch die Einstellung eines sehr langen Papierformats verhindert werden[10].
Die Rohdaten im Format JSON
Das Format JSON (fmt/817) ist z.Zt. nicht als Archivierungsformat in DiPS.kommunal zugelassen und kann in dieser Form nicht direkt eingeliefert werden. Da der Inhalt aber aus reinem Text besteht, ist eine Übernahme als Reintext möglich. Für das Vorgehen im zweiten Fall reicht es, die Endung „.txt“ an die Datei anzuhängen. Wenn die alte Endung zusätzlich erhalten bleibt, ist deutlich, um welchen Inhalt es sich handelt. Natürlich wird in diesem Fall keine JSON-spezifische Validierung des Inhalts durchgeführt[11].
Anmerkungen
[1] Peter Worm, Twitter Accounts von kommunalen Wahlbeamten. Bewertung und Überlieferungsstrategien. In: Archive 2.0 (https://archive20.hypotheses.org/8710).
[2] P. Worm, Twitter Accounts (wie Anm. 1), nach Abb. 4.
[3] Auf das Problem machte dankenswerter Weise Heike Beimfohr von der LWL.IT im Rahmen des DiPS.kommunal Kundensupports aufmerksam.
[4] Unter der Anmeldung „Michael“ vom 4. Februar 2020, https://archive20.hypotheses.org/8710#comment-30285.
[5] TWINT steht für Twitter Intelligence Tool und ist quelloffen und kostenfrei (MIT License) verfügbar unter https://github.com/twintproject/twint.
[6] Vgl. „Ergänzung vom 10.02.2020“ in: P. Worm, Twitter Accounts (wie Anm. 1), nach Abb. 9.
[7] Der Python3-basierte Twitter-Scraper GetOldTweets3 ist eine verbesserte Version der Projekts GetOldTweets von Jefferson Henrique und steht offen kostenfrei unter der MIT-Lizenz zur Verfügung https://github.com/Mottl/GetOldTweets3
[8] Auch das ebenfalls Python3-basierte Projekt twitter-scraper steht kostenfrei unter der MIT-Lizenz bei GitHub zur Verfügung: https://github.com/bisguzar/twitter-scraper
[9] Hinter dem Kürzel JSON steckt „Javascript Object Notation“ ein kompaktes Datenformat in einer einfach lesbaren Textform. Es dient dem Zweck des Datenaustausches zwischen Anwendungen und ist von der Programmiersprache unabhängig, vgl. s.v. „JavaScript Object Notation“ in der Wikipedia (https://de.wikipedia.org/wiki/JavaScript_Object_Notation); zu den Umwandlungsmöglichkeiten in archivfähige Formate P. Worm, Twitter Accounts (wie Anm. 1), bei Abb. 8 sowie die Hinweise von Kai Naumann in seinem Kommentar https://archive20.hypotheses.org/8710#comment-30560.
[10] Der Seitengröße ist im PDF-Standard nicht begrenzt, die technischen Implementierung setzen aber Grenzen. Zum Beispiel erlaubte der Adobe Acrobat in älteren Versionen nur Dokumente von 200 Zoll × 200 Zoll (5,08 m × 5,08 m); seit der Version 7 (PDF-Version 1.7) können nun 15.000.000 Zoll × 15.000.000 Zoll (381 km × 381 km) große Dokumente erzeugt werden. Die PDF/A-2 Standard basiert auf dieser PDF-Version.
[11] Sollte der Dateityp sich stärker etablieren, wäre eine Validierung grundsätzlich möglich und könnte ggf. in DiPS.kommunal implementiert werden vgl. http://json-schema.org/specification.html.
OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Peter Worm (9. März 2021). Ein neuer Ansatz für die Langzeitarchivierung von Twitter-Accounts. Archive 2.0. Abgerufen am 8. Februar 2025 von https://doi.org/10.58079/ckk2
Ich höre gerade vom DLM-Forum, dass noch jemand sich ein Tool ausgedacht hat:
https://github.com/Digitalia-Xamk/Twitter-study/blob/main/TwitterStudy-init-collect.py
Liebe Autoren,
herzlichen Dank für diesen Nachschlag zu “Twitter Accounts von kommunalen Wahlbeamten”. Es mir eine große Freude, Ihnen bei diesem Vorantasten und Wegbereiten für die deutschsprachige Community zuzuschauen, auch wenn ich vermutlich selbst diesen Weg in näherer Zukunft nicht nachgehen werde(n kann).
Unter welcher Lizenz wurde das Skript veröffentlicht? Wäre es möglich, es auf GitHub/Lab oder einen anderen GIT-Server zu laden?