Versionskontrolle mit Git & Funktion und Aufbau von Bibliothekssystemen 1/2

Heute ging es einerseits um die Kommentare zu den Lerntagebücher, Fragen um dem Blog und einer Versionskontrolle mit Git, anderseits gewannen wir einen Einblick in der Funktion und der Aufbau von Bibliothekssystemen mit Metadatenstandards in Bilbiotheken (MARC21) und mit der Installation und Konfiguration von Koha.

Versionskontrolle mit Git

Da wir nur Grundfunktionen von Git während der Vorlesung, dürfen wir bei Interesse selbst üben mit den ausführliche Lehrmaterialien von Library Carpentry.

Wozu Git?

Git ist eine Software zur Versionskontrolle. Sehr nützlich ist Git, um über mehere Computer oder mit meheren Personen eine Textdatei/eine Software zu schreiben, besonders da es die Versionkontrolle ermöglicht: Das heisst, dass wenn eine Änderung gemacht wird, diese angezeigt wird und ist dann für jeden Mitentwickler sichtbar. Auch kann man die Änderungen mit einer Commit-Message versehen, damit diese ganz genau nachvollziehen werden können. Anhand der Historie wird ermöglicht zu sehen, von wem die Änderung stamm sowie wann diese erfolgte, und solche zu löschen. Dies ist sehr praktisch, wenn man – auch selbst – ein Fehler macht und darauf zurück kommen möchte. Interessanter Hinweis vom Dozent für uns als InformationswissenschaftlerInnen und auch für die Forschung: Es wird nicht nur von Programierer genutzt, sondern immer mehr in anderen Bereichen, da die Versionniertung mit vielen Arten von Dokumenten möglich ist. Wie zum Beispiel mit Forschungsdaten kann Git benutzt werden und damit wir eine bessere Reproduzierbarkeit erreicht, was im Sinn der Wissenschaft ist.

unterschied Git und GitHub

Git auch lokal verwendet werden, aber auch als Repository im Netz. Für das letztere ist es allerdings nötig, git auf einem eigenen Webserver zu installieren oder dann eine Plattform wie GitHub zu nutzen.

Dazu erwähnt auch Herr Lohmeier im gemeinsamen Dokument:

Git mal diese Übung

In Teilgruppensitzungen machten wir eine Übung in der virtuelle Maschine – da git darauf installiert ist –, in welcher wir über das Terminal den Link unseres jeweiligen Tagebuches im Skript vervollständigen lassen. Dafür werden die Kommandos clone, commit und pull request benutzt. In meinem Fall hat die Teilgruppensitzung und die Übung gut geklappt. Bei Verständnisunsicherheiten konnte ich meine Kammaraden eine Erklärung fragen, was bei dieser Übung nicht nötig war. Ich gehe ganz kurz auf die einzelne Schritte nochmals und versuche diese rasch zu erläutern:

  • Im ersten Schritt ging es darum eine Kopie des Repositories zu erstellen. Dafür musste manb den Repository von Herr Lohmeier aufrufen und auf “Fork” klicken. Dies kreiert eine Kopie des Repository von Herr Lohmeier auf unserem eigenen Account.
  • Über den Terminal haben wir die Dateien von unserem Fork mit dem Befehl git clone ... heruntergeladen, wobei die drei Punkte durch den Link unserem Fork ersetzt worden ist.
  • Den Link zu meinem Lerntagebuch habe ich in der Datei README.md eingefügt. Dies wurde auf meinem Rechern bzw. lokal auf der virtuellen Maschine durchgeführt und im Terminal mit git diff die Änderung angezeit – hier wurde also den Link zum meinem Lerntagebuch angezeigt.
  • Dann haben wir in der Gruppe jeweils unsere Änderungen durch den Terminal mit git add README.md mit der Mail-Adresse und dem Name vom Dozent als Ziel hochgeladen. Dem “Päckchen” wurde ein Packzettel mit git commit -m "Link zu meinem Lerntagebuch" beigelgt.
  • Um das Päckchen abzuschicken, haben wir den Befehl git push benutzt.
  • Als Letztes wurde eine Pull Request ertstellt, indem wir unseren Fork geöffnet, auf pull request und auf create pull resquest geklickt, das Formular ausgefüllt und schlussenendlich den Create pull request-Button gedrückt hat.

Hinweis zu git commit -m: Dieser Befehl erstellt einen Commit mit einer Nachricht – gut aus meiner Sicht, um den Commit zu beschreiben. Nur mit git commit wird den Texteditor geöffnet und die Angabe einer Nachricht da gefordert. Mit der Option -m wird stattdesssen eine Inline-Nachricht benutzt, also – wie ich es verstehe – eine Nachricht direkt im Terminal (Atlassian).

So sah den Hinweis meinem Pull Request beim Dozent: das Ergebnis aus meinem Pull Request beim Dozent

Was ist aber die Idee hinter einen Pull Request?

Ein Pull Request lässt Anderen über Änderungen, welche an einem Branch angefragt worden sind, wissen. Sobald verschickt, kann diese Anfrage diskutiert und weitere commits ergestellt werden, bevor man sich entscheidet eine Änderung zu übernehmen (bzw. die Versionen zusammenführen, auch “merge” genannt) (GitHub).

MARC21

MARC21 ist ein International vebreiterer Metadaten-Standard, welcher von der Library of Congress 1999 gegründet worden ist (Skript Tag 2). Interessant nach Herr Lohmeier ist dabei, wenn man mit den Daten arbeitet, dass es ein eigenes Binärformat (.mrc) und auch als XML gespeichert werden kann. Auch zu beachten ist, dass es interschidliche Katalogisierungsregeln sowie die Möglichkeit eigene Felder zu belegen gibt. Je nach Land, Region der Welt – z.B. ob USA oder Europa – oder sogar je nach Instituton können diese varrieren und somit kann MARC21 je nach Ort und Verwendung stark vom Standard abweichen. So heisst es, dass eine MARC-Datei nicht immer gleich aufgebaut wurde und muss zuerst angeschaut werden, bevor man mit einer Solche arbeiten sollte. Die meisten Bibliothekssysteme basieren trotzdem mitllerweile auf MARC, sowie auch Koha oder können es als Austauschformat unterstützen.

Im Studium sind meine Mitstuden’innen und ich diesen Format schon mehermals begegnet, zum Beispiel in den Module WOR2, in DILZA und STAN.

Übung MARC21 vs. Dublin Core

In dieser Übung ging es darum, in der SRU-Schnittstelle von swissbib die Datensätze zwischen Dublin Core und MARC-XML aufgrund einer Suche zu vergleichen. Dublin Core ist viel weniger umfrangreich als MARC21. Dies hat warscheinlich damit zu tun, dass die Verantworlichen einige Felder für Dublin Core weggelassen haben. Somit sind die Informationen in DC schlanker gehalten worden. Dublin Core ist einfacher als Mensch zu lesen, auch die Felder sind mit einem klaren Namen vorgesehen und nicht mit einem Zahlencode wie die Elementnamen in MARC-XML. Allerdings wenn man die Felder der Katalogisierung (RDA) kennt, ist auch das MARC-XML gut lesbar.

Hingegen gibt MARC21 viel mehr Informationen als Dublin Core. Karin testete zum Beispiel die Daten von Beiden in Word zu kopieren. Aus dem MARC-Datensatz erreichte den Word-Dokument 10 A4-Seiten, aus dem von Dublin Core nur zwei Seiten. Dies kann allerdings auch aufgrund der Konvertierung sein, da gewisse Informationen, welche sich in MARC befinden, nicht gut zu Dublin Core zugeordnet werden könnten oder von Swissbib weggelassen worden sind. Bei dieser Übung kamm zum Beispiel die Nummer der Auflage in MARC vor, aber nicht in Dublin Core. Leider somit können Informationen verloren gehen.

Hier einen Ausschnitt aus der Übung, um MARC (links) mit Dublin Core zu vergleichen: MARC vs. Dublin Core

Einführung in Koha

Das Bibliotheksystem Koha, wie schon oben erwähnt, basiert auf MARC21. Es handelt sich dabei um eine Open Source Katalogisierungssoftware, welche auch für kommerzielle Nutzung verwendbar ist.

Auch kann man Open Hub benutzten, um eine Software – in diesem Fall Koha – zu beurteilen. kann man Statistiken auf Openhub schauen: Wie sieht es mit der Nutzung aus? Die Weiterentwicklung? Welche Programmiersprachen werden verwendet? Bei Koha wird SQL als Datenbank-Sprache benutzt, JavaScript für die Oberfläche, aber wird vorwiegend mit Perl geschrieben (37%) (OpenHub). Auch kann man beobachten, dass Koha durch mehrere Entwickler jeden Tag bearbeitet wird. Dies ist schon ein sehr guter Zeichen, da es uns versichert, dass die Software nicht von einem Tag auf dem Anderen aufgegeben wird. Auch findet ein rege Weiterentwicklung anhand der Anzahl von Commits statt.

Stats von Koha bei Open Hub

Koha-Installation & Tutorial

In Teilgruppensitzungen durften wird auf der virtuelle Maschine Koha installieren, dies anhand von Eingabe im Terminal. Da ging alles gut, auch konnte ich wie im Installationsverlauf des Dozenten (Skript Tag 2) die Webseite meiner Koha-Bibliothek im Browser aufrufen. Die Konfiguration erfolgte bei mir an einem anderen Tag als Hausaufgabe. Wie vorgegeben orientierte ich mich an dem sehr gut beschriebenen Tutorial von Stephan Tetzel. Mit unsere Version von koha weichte den Layout in Vergleich zu den Screenshots von Tetzel ab und ich konnte kein Platz füur den Kommentar als Willkommensnachricht finden. Dies lasste ich aber weg und erfuhr beim nächsten Termin, dass man diese Nachricht unter Werkzeuge einstellen kann.

Quellen: GitHub, gemeinsames Dokument, Atlassian, GitHub – Pull Request, Skript Tag 2, Koha, OpenHub.