Jakoblog — Das Weblog von Jakob Voß

Kurz-URL-Archive als Beacon-Linkdumps

Kurz-URL-Dienste wie bit.ly, goo.gl und t.co gehören zu den eher merkwürdigen Auswüchsen des Web. Eigentlich haben sie vor allem Nachteile, trotzdem werden sie eifrig genutzt. Spätere Generationen werden sich vielleicht sicher fragen, warum die Menschen Anfang des 3. Jahrtausend ihre eigene Infrastruktur kaputt gemacht haben – unter anderem die einfache Adressierung von Webseiten mittels URLs. Weil Kurz-URL-Dienste so eine blöde Idee sind und damit nach ihrem Ableben spätere Generationen die ganzen Kurz-URLs zurückverfolgen können, hat eine Gruppe von Freiwilligen Archivaren 2011 das URLTeam gegründet (siehe Vortrag auf der Defcon 2011). Auf der Wiki-Seite des URLTeam sind zahlreiche, teilweise schon nicht mehr aktive Linkresolver aufgeführt. Der letzte Linkdump ist etwa ein Jahr alt und umfasst 48 Gigabyte (gepackt!). Ich habe das Dateiformat etwas aufgebohrt, so dass die archivierten Linkdumps dem Beacon Text Format entsprechen. Hier ein Beispiel:

Felix hatte zur GBV Verbundkonferenz 2009 in einem Tweet auf ein „Wordle“ des GBV Strategiepapiers verwiesen. Der Tweet enthielt die URL http://tr.im/ykr2. Den Kurz-URL-Dienst tr.im gibt es jedoch inzwischen nicht mehr. Bevor tr.im abgeschaltet wurde, hat das URLTeam allerdings geschafft, knapp zwei Millionen URL-Mappings zu sichern. Im frei verfügbaren Torrent befindet sich die Datei tr.im.txt.xz, in der auch der gesuchte Kurz-Link steckt:

ykr2|http://www.wordle.net/show/wrdl/1114322/GBV_Strategiepapier

Ich habe den Linkdump mit diesem Perl-Skript um folgende Metadaten im Beacon-Format erweitert:

#FORMAT: BEACON
#CREATOR: URLTeam
#HOMEPAGE: http://urlte.am/
#RELATION: http://dbpedia.org/resource/HTTP_301
#DESCRIPTION: Shortened URLs from http://tr.im
#PREFIX: http://tr.im/
#SOURCESET: http://tr.im/
#TIMESTAMP: 2011-12-31

Der so in eine Beacon-Datei umgewandelte Linkdump steht (gepackt mit XZ) unter http://uri.gbv.de/downloads/links/tr.im.beacon.xz als Beispiel zur Verfügung.

Die Maker-Community Knowable.org

Über die Berichterstattung zur Retune-Konferenz bin ich auf das Berliner Startup knowable.org gestoßen, dessen Gründer Simon Höher auf der Retune einen Vortrag gehalten hat. Retune ist eine Platform zum Austausch von Bau- und Bastelanleitungen, also so ähnlich wie Instructables, WikiHow, Make: Projects und ähnliche Seiten. Knowable.org vergleicht sich allerdings lieber mit GitHub und mit physischen Hackerspaces. Was bedeutet das und was ist das Besondere an der Plattform?

1. Die auf Knowable veröffentlichten Projekte sind unter CC-BY-SA lizensiert. So können Teilnehmer beispielsweise auf Inhalte von Wikipedia und Wikibooks zurückgreifen (und umgekehrt).

2. Die Anleitungen sind absichtlich einfach gehalten. Dass eine Beschränkung des Umfangs vorteilhaft sein kann hat schon Twitter gezeigt. Bei Knowable besteht jeder Schritt einer Anleitung aus bis zu 320 Zeichen und ggf. einem Bild fester Größe, wodurch das Layout der Seite einfach bleibt. Lediglich die Möglichkeit, zu jedem Schritt einzelne Hyperlinks hinzuzufügen, z.B. auf Quellcode und exakte Maßzeichnungen, würde ich noch aufnehmen.

3. Anleitungen können von allen Nutzern bearbeitet werden. Dabei hat jeder Nutzer seine eigene Version, die von anderen übernommen, verworfen oder weiterentwickelt werden kann. Mit diesem Prinzip einer verteilten Versionsverwaltung unterscheidet sich Knowable von ähnlichen Wiki-basierten Seiten wie bildr.org und Wikibooks.

Leider ist der letzte Punkt noch nicht umgesetzt. Ich wünsche mir allerdings auch lieber ein durchdachtes Datenmodell als eine schnelle Lösung, die später Probleme bereitet. Beispielsweise sollte klar sein wie Projekte mit ihrer Versionsgeschichte im- und exportiert werden können und wie Diffs zwischen zwei Versionen aussehen können. Dies ist nicht trivial, wie folgendes Beispiel zeigt (wer kein Interesse an Datenmodellierung hat, möge jetzt aufhören zu lesen):

Eine Möglichkeit zur Kodierung von Anleitungen wäre das Dateiformat oManual. Die Versionsgeschichte ließe sich in einem git-Repository speichern, dass der Ordnerstruktur von oManual entspricht. Das von oManual benutze XML-Format eigent sich jedoch nicht gut, um Änderungen darzustellen. Ein wesentlicher Grundsatz, der für Dateiformate in Versionsverwaltungen eingehalten werden sollte ist die Beschränkung auf das Wesentliche durch Normalisierung. Beispielsweise ist folgendes oManual-Fragment nicht normalisiert:

<step number="1">...</step>
<step number="2">...</step>

Der größte Teil des XML-End-Tags (/step>) ist prinzipiell redundant, so ist XML aufgebaut. Die Nummerierung der Schritte ergibt sich eigentlich automatisch aus der Reihenfolge, so dass das „number“-Attribut redundant ist. Außerdem müsste die Nummerierung aller folgenden Schritte geändert werden, wenn zwischen Schritt 1 und Schritt zwei ein weiterer Schritt eingefügt wird. Aus diesem Grund tendiere ich zu kompakten textbasierten Formaten (wie z.B. Markdown), aus denen sich bei Bedarf verschiedene Formate in JSON, XML, RDF etc. erzeugen lassen.

Ein kleiner Tipp an die Entwickler von Knowable.org: Achtet auf die Normalisierung von Leerzeichen und verschiedenen Unicode-Formen (NFC) und vereinheitlicht auch die Bilddateien (incl. Metadaten). Außerdem ließe sich die Bildeinbindung über die MediaWiki-API mit Wikimedia Commons anbinden. Dabei sollte zu jedem Bild grundsätzlich eine Quelle (URL) und ein Autor angegeben werden können, um der CC-BY-SA Lizenz genüge zu tun und um einen Verweis auf hochauflösende Versionen der Bilder zu haben. Für die Erschließung der Anleitungen mit Tags und Werkzeugen kommt auch Wikipedia/DBPedia in Frage, um gleich ein kontrolliertes Vokabular zu haben.

P.S.: Es gibt übrigens noch einige andere Projektseiten, bei denen einige Inhalte unter einer freien Lizenz veröffentlicht sind, z.B. bei Fritzing Projects und Thingiverse. Wenn Knowable.org tatsächlich sowas wie GitHub für physische Dinge wird, sollten sich Projekte von anderen Plattformen übernehmen und weiterentwickeln lassen.