Am heutigen Vorlesungstag auf dem Programm stand mit Git zunächst ein Punkt, für den es in der letzten Vorlesung nicht mehr gereicht hatte. Anschliessend sind wir mit dem Metadatenstandard MARC21 und der Software Koha in die Welt der Bibliothekssysteme eingestiegen.

Doch vorweg ein kurzer Exkurs beziehungsweise Nachtrag zu CodiMD. CodiMD wird nämlich umbenannt werden in HedgeDoc. Die Geschichte von CodiMD/HackMD/HedgeDoc ist nicht uninteressant und auch recht verwirrend bezüglich Namensgebungen und Abspaltungen. Kurzfassung: Aus CodiMD, also der open-source-Variante von HackMD, wird nun HedgeDoc. Diese verzweigte Geschichte lässt sich hier nachlesen. Der Prozess zur Logofindung zeigt zum einen schön auf, wie in einem Community-Projekt vorgegangen wird, zum andern fand ich es interessant zu sehen, was für Vorschläge es gab und welche Varianten kreiert wurden. Das HedgeDoc-Projekt arbeitet mit GitHub, wo der Quellcode und auch das Logo abgelegt sind. Und damit wäre auch gleich mehr oder weniger geschickt übergeleitet zu unserem eigentlichen ersten heutigen Thema: GitHub Pages.

GitHub, GitHub Pages, Gitlab, Git? Wer ist wer?

GitHub Pages ist eigentlich sowas wie eine Erweiterung von GitHub (also keine WordPress alternative oder so). Damit wäre das schonmal geklärt, bleiben also noch Git, GitHub und GitLab übrig. Mich verwirren diese ähnlich klingenden Namen und ich kann mir das am besten via die Logos merken: GitLab ist das mit dem Fuchs, GitHub das mit der Katze und Git ist ganz trocken einfach Git und führt im Logo einen zentralen Aspekt: die branches. (Die Abbildungen mit den Logos habe ich den jeweiligen Webseiten entnommen.)

Logo GitHub Das Logo mit der Katze von GitHub

LogoGitLab Das Logo mit dem Fuchs von GitLab

Logo Git Das Logo von Git

Git ist eine freie, eigenständige Software zur Versionskontrolle: Mittels verschiedener Entwicklungs-Zweige (branches)1 und Abspaltungen kann jede Änderung an Textdateien nachvollzogen werden (via die einzelnen commits) und die gemachten Arbeitsschritte können rückgängig gemacht werden. Das ist nützlich, wenn z.B. in einem Programm ein Fehler hineinprogrammiert wurde, so kann eruiert werden wo dies geschah (und was geschah und durch wen); oder es kann nützlich sein eine Arbeit so zu versionieren. Git ist sowas wie die Basis für GitLab und GitHub – Git steckt ja auch bereits im Namen mit drin. Git ist, wie bereits erwähnt, eine eigenständige Software, wohingegen GitLab, wie auch GitHub Plattformen sind, mittels denen auf kollaborative Weise versionskontrollierte Projekte geschrieben werden können. (Für ausführlicheres siehe auch die verschiedenen Wikipediaeinträge zu Git, GitLab und GitHub.)

Bei der Arbeit mit Git (und GitLab, GitHub) gibt es einige typische Ausdrücke: fork, commit, branch, merge, pull request… diesen bin ich im Laufe des Studiums schon einige Male begegnet, allerdings blieben sie mir rätselhaft. Durch die Übung, welche wir nun in BAIN gemacht haben – nämlich den Link zu unserem Lerntagebuch ins GitHub-Repository des Kurses BAIN einzufügen – wurden mir diese Begriffe zum ersten Mal klarer. So bedeutet fork, dass eine Art Abspaltung geschieht, indem eine Kopie des Repository (des Verzeichnisses) erstellt wird. Gleichzeitig schwingt auch das Wort Gabel mit, in dem Sinne, dass die Abspaltung dann wie auf eine Gabel aufgespiesst wird und so dann eingefügt werden kann (pull request und anschliessend merge), also dass die beiden Abspaltungen nun wieder zusammengeführt werden und so das Übernehmen der angefragten Änderung vollzogen wird. Zumindest diesen Lerneffekt hatte die Übung für mich. Allerdings stellt sich die als «kleine Übung» angekündigte Aufgabe für mich als doch grösseres Projekt heraus. Dank tatkräftiger und geduldiger Kommilitoninnenhilfe (Danke, Gaby) während der gesamten Pause, gelang die Aufgabe dann doch noch. Allerdings ist es mir noch nicht bei allen Schritten klar geworden, warum man nun was tut. Sollte ich eines Tages mit irgendeiner Form von Git in der Praxis konfrontiert sein, so merke ich mir für diesen Moment die entsprechende Library Carpentry zu Git vor, um gezielt damit vertraut zu werden. Für den jetzigen Zeitpunkt genügt es mir, einen ersten Einblick erhalten zu haben, um was es geht mit der Versionskontrolle, wozu diese da ist und wie die Arbeit mit Git und in GitHub aussieht.

Bibliothekssysteme – Metadatenstandards in Bibliotheken (MARC21)

MARC21 ist ein Begriff, der mir im Studium doch schon einige Male begegnet ist und daher nicht mehr ganz so fremd anmutet. Im Modul zu Standards und Regelwerken wurde MARC21 durch das Katalogisieren bereits etwas anschaulicher. MARC steht für Machine-Readable-Cataloging und ist ein Datenformat für den Austausch von Bibliotheksdaten.

MARC21 ist der Metadatenstandard in Bibliotheken, entwickelt durch die Library of Congress (1999) und mittlerweile weltweit im Einsatz, wenn auch mit je nach Region oder sogar je nach Institution stark abweichenden Regeln (z.B. gibt es grosse Unterschiede bei Katalogisierungsregeln zwischen den USA und Europa). Zudem gibt es MARC21 in zwei Formaten: Einem Binärformat (.mrc) und in XML. Um mit dem Binärformat zu arbeiten, braucht es spezielle Software. All diese Verschiedenheiten machen einen Austausch schwieriger.
Unter anderem aus diesem Grund soll MARC21 durch BIBFRAME, welches auf RDF basiert und dadurch flexibler ist, abgelöst werden (BIBFRAME und MARC21 werden in Beitrag 10 nochmals aufgegriffen werden). Heute aber ist MARC21 noch immer das Format für den Austausch von Bibliotheksmetadaten und so basieren auch die grossen Bibliothekssysteme auf MARC21 - so auch Koha, welches wir uns gleich ansehen werden.

Doch zuvor, um uns Unterschiede in den Metadatenstandards zu bewusst zu machen und zu sehen, wie solche Datensätze aussehen, haben wir einen Vergleich zwischen MARC21 und Dublin Core gemacht: Via die SRU-Schnittstelle von Swissbib haben wir je Datensätze im Format MARC21 und im Format Dublin Core geladen und uns die Unterschiede angesehen. Das Format Dublin Core kommt schlanker und leserlicher daher, dies deswegen, weil in MARC21 mehr Metadaten enthalten sind und zudem die einzelnen Felder nicht mittels sprechender Bezeichnungen, sondern mit Zahlen und Buchstaben, versehen sind. Die folgenden Screenshots mit Ausschnitten aus den Datensätzen veranschaulichen diese Unterschiede.

Datensatz im Format Dublin Core Der Datensatz im Format Dublin Core.

Datensatz im Format MARC21 Ein Auschnitt desselben Datensatzes, diesmal im Format MARC21. Es ist offensichtlich, dass hier nun viel mehr Metadaten enthalten sind.

Wichtig zu wissen ist zudem, dass bei der Übertragung von einem Format ins andere es immer auch zu Verlusten kommen kann – sei es aus technischen Gründen oder auch weil beispielsweise Dublin Core, der ja als kleinster gemeinsamer Nenner der Standards gilt, die entsprechenden Felder gar nicht erst vorgesehen hat. Es gibt also gute Gründe, warum Bibliothekssysteme MARC21 verwenden.

Bibliothekssysteme – Koha

Koha ist eine Bibliothekssoftware (basierend auf MARC21) und wurde seit 1999 in Neuseeland entwickelt. Es ist heute ein weltweites Open-Source-Projekt mit Beteiligung verschiedenster Unternehmen und Personen. Zum rätseln gebracht hat mich ein Aspekt, den der Wikipedia-Artikel zu Koha mir verrät: Koha leite sich nämlich vom Maori-Wort koha ab und bedeute dort ein Geschenk, bei welchem ein Gegengeschenk erwartet werde. Da bin ich ja nun gespannt, wie dies gemeint sein könnte… oder anders gefragt: Was das System wohl von mir erwartet?

Kleiner Exkurs: Auf Webseiten wie zum Beispiel Open Hub lässt sich herauslesen, wie gesund eine Open Source Software ist, indem beispielsweise betrachtet wird, ob und in welchen zeitlichen Abständen die Software weiterentwickelt wird, wieviele Commits es gibt, wie gross die Anzahl damit beschäftigter Personen, und vieles mehr.

Installation von Koha

Koha wird nur lokal auf der Virtuellen Maschine installiert, darum können wir auch nur via Firefox im Ubuntu darauf zugreifen. Während der Installation von Koha haben wir zudem MariaDB installiert. Dank der ausführlichen Anleitung auf der BAIN CodiMD-Seite gelang die Installation auf Anhieb. Im Anschluss an die Installation habe ich sogleich das Tutorial von Zefanjas durchgearbeitet und so die Grundkonfiguration von koha vorgenommen (Kapitel 1 und 3 des Tutorials). Zwar habe ich nicht immer gewusst, was genau ich da nun tue, aber dadurch, dass ich mich einfach strikt an die Anleitung im Tutorial gehalten habe, hat es ohne Zwischenfälle geklappt. Dass das so reibungslos funktioniert hat, hat mich sehr gefreut und als dann die Erfolgsmeldung pünktlich zum Feierabend aufploppte, war ich rundum zufrieden.

Screenshot nach erfolgreicher Installation von koha Koha erfolgreich installiert.

Für mich, die*r ich nicht im Bibliotheksbereich tätig bin, es mir aber vorstellen könnte, war es eine sehr gute Erfahrung, anschliessend in aller Ruhe in koha und den verschiedenen Einstellungen herumzustöbern.

  1. Der Hauptzweig wird master genannt, allerdings ist aktuell im Zuge der Black-Lives-Matter-Bewegung ein Umdenken im Gange, und der Begriff master soll nicht mehr verwendet werden. Eine alternativer Begriff wäre beispielsweise main. ↩