<

allegro und Koha : Gegenüberstellung

von Bernhard Eversberg und Andreas Wolf

Erstellt nach einer Fortbildung in Potsdam am 17.3.2017

allegro Koha


Plattform
Windows: Graphischer Client (a99/alcarta); Kommandozeile (acon); Browser (a35)
Linux:  Browseroberfläche (a35); Kommandozeile für Admin (Konsolprogramm acon);
System: Linux-Server; Cloud + MySql + Zebra-Suchmaschine
Benutzung und Administration: Browser


Entwicklung
1980-2015: UB Braunschweig, www.allegro-c.de
ab 2016: Open Source, Projekt zur Modernisierung mit allegro-Experten ab 2017 ,
Ziele u.a.: SQL für die Datenverwaltung, Unicode
Für englischsprachige Version gibt es viele kommerziellen Supporter
         https://koha-community.org/support/paid-support/country/
Deutsche Version: betreut vom BSZ Konstanz
        https://www.bsz-bw.de/bibliothekssysteme/koha.html


Programmierung
Quelltexte der Kernprogramme in C und C++ (OpenSource). Komplierbar unter Windows und Linux. Graphische Oberfläche jedoch nur für Windows.
Web-Oberfläche a35 nutzt JavaScript im Browser und PHP im Server, jedoch sind die Skripte standardisiert und müssen nicht angepaßt werden. Alles, was lokal modifiziert werden soll, wird in allegro-eigenen Skriptsprache FLEX geschrieben. Diese ist schnell, weil sie direkt auf die Datenbank zugreifen kann. Sie ist auch das wichtigste Mittel für funktionale Erweiterungen, d.h. Programmierung in C ist dazu nicht erforderlich.
Quellprogramme in Perl nur für Linux nutzbar, Oberfäche HTLM5 und CSS3.
Alle Programmteile (ca. 450) sind entsprechend vollständig lesbar. Die Perl-Skripte werden ergänzt durch zahlreiche Templates (.tmpl), die für eine leichtere Modifizierbarkeit der Oberfläche incl. Sprache sorgen sollen. Dazu braucht man gute Perl-Kenntnis und eine Einarbeitung zum Kennenlernen der Module und ihrer Struktur.
Eine eigene Skriptsprache hat Koha nicht, es wird alles mit Perl gemacht.


Download
http://www.allegro-b.de/download/
Windows:    Installpaket ca. 5 MB, incl. Demo-Datenbank mit 1200 Sätzen
                   entpackt: 23 MB, 41 Ordner, 1.680 Dateien
a35 Web-Installation:  3.5 MB, ca. 10 Ordner mit 250 Dateien
Linux-Programme:  http://www.allegro-b.de/download/linux-prog.tar.gz
 https://koha-community.org/download-koha/.
  Installpaket ca. 21 MB;
  entpackt: 143 MB, 1.800 Ordner, 4.400 Dateien
                     darunter 476 .pl-Skripte, 467 .tmpl-Dateien
  Hinzu kommen MySQL und Zebra; (Perl ist Teil von Apache)


Installation
Das "Gesamtpaket" install.exe enthält eine komplette Windows-Installation incl. Demo-Datenbank.
Das Linux-.tar-Paket enthält alles, was unter Linux gebraucht wird.
Für die Web-Oberfläche a35 existiert ebenfalls ein Komplettpaket.
Die Installation muss zwingend auf einem Linux-Server erfolgen. Dabei ist darauf zu achten, die 'richtige' Linux-Version zu installieren !
Auf Linux Ubuntu neueste Version erfolgte die Installation komplett problemfrei.
'In-House'-Installationen im eigenen Netzwerk sind möglich sofern man einen Linux-Server dafür bereitstellt.


Software-Updates
In unregelmäßigen Abständen gibt es ein neues "Gesamtpaket", das man einfach über die bisherige Version installiert. (Lokal modifizierte Parameter oder Skripte kopiert man in den eigenen Datenordner, dann bleiben sie von Überschreibung verschont.)
Halbjährliche Update-Pakete mit meistens sehr langen "Bugfix"-Listen, die nur dem Kenner des Systems etwas sagen. Viele Änderungen sind jedoch rein intern und müssen nicht lokal besonders beachtet werden.

Server
In lokalen Netzen wird kein Serverprogramm gebraucht, nur ein freigegebener Ordner im Dateisystem. Windows-PCs als Clients arbeiten mit dem Programm a99.
Für dezentrales Arbeiten kann die Browseroberfläche a35 verwendet werden; dafür wird auf der Servermaschine das avanti-Programm gebraucht (im Gesamtpaket enthalten, verfügbar für Windows und Linux) Clients brauchen dann nur einen Browser.
In jederm Fall wird ein Linux-Server gebraucht, es gibt 2 geeignete Versionen.

Clients (PCs o.a.) brauchen nur einen Browser.


Fremdkomponenten
Keine
Perl: >= 5.14.,    MySQL: >= 5.1.59,    Zebra (Suchmaschine)


Performance
Kein Tuning nötig. Unangenehm langsame Vorgänge gibt es nicht.

Für Koha ist zunächst einiges Performance-Tuning nötig. Welche Faktoren der Konfiguration hier zusammenwirken ist nicht leicht durchschaubar.
Sehr langsam sind dennoch der Datenbank-Neuaufbau und die Index-Erneuerung



Suchmaschine, Discovery-System (OPAC)
allegro hat eigenes Suchsystem mit alphabetischen Registern und schneller Direktsuche mit Stichworteingabe, beides im Windows-Client und in der Web-Oberfläche a35.
Ferner integriertes Verfahren zur Volltextsuche. Für das Suchen ist keine eigene Konfigurierung nötig.
Zusätzlich kann man die Daten auch in einem parallelen VuFind-System bereitstellen.

Demo für Windows: Demo-Datenbank installieren! (geht schnell)
Demo-Beispiele Web-OPAC: http://www.allegro-b.de
Koha hat keine eigene Suchmaschine, sondern man setzt dazu Fremdsoftware ein, standardmäßig ein System namens "Zebra" mit Solr (wie bei VuFind). Man muss gelegentlich den Suchindex erneuern; dies braucht Zeit, kann aber nachts geschehen.
Eine eigene Suchstruktur aufzubauen mit selbst definierten Registern / Suchmustern ist auch für Bibliothekare mit Programmierkenntnissen extrem aufwendig.
Alphabetische Register zum Blättern sind möglich im "Advanced Search".
Demo zum Ausprobieren: https://bbf.bsz-bw.de/
OPAC-Eigenschaften und Referenzen: http://www.koha-de.org/wiki/Koha/OPAC


Oberfläche
Windows: Eigenkonstruktion (a99 / alcarta).  [Einen DOS-Client gibt es auch noch]
Web: a35, auf Basis von HTML5, CSS3 und JavaScript. Für Anpassungen keine eigenen JavaScripte oder PHPs nötig, sondern nur FLEX-Skripte.
Benutzungsoberfläche nur Browser; in Teilen definierbar/anpassbar, es lässt sich sehr viel abschalten/zuschalten. Tiefe Kenntnisse sind nötig, um, eigene Vorstellungen in der Optik und den gewollten Funktionalitäten zu berücksichtigen. 


Codierung
DOS, Windows oder Unicode-UTF-8 möglich. Web-Oberfläche ist stets Unicode (automatische Umcodierung über Tabellen, siehe http://www.allegro-c.de/codier.htm
Ausschließlich Unicode-UTF-8


Datenverwaltung
Eigenkonstruktion; potentiell bis zu 2 Mrd. Datensätze in einer Datenbank. MySQL. Es sind auch andere SQL-Systeme möglich, die aber das eingesetzte Linux unterstützen muss. Wechsel zu anderem System ist aufwendig.


Datenstruktur
Feld- und Unterfeldstrukur konfigurierbar in der CFG-Datei (Standard $a.cfg)
Realisiert sind auch MAB- und MARC-Konfigurationen sowie viele andere für Projekte mit anderen, nichtbibliographischen Daten. Übersicht Standardschema:
http://www.allegro-b.de/download/doku/form2016
Intern in SQL-Tabellen. Anwender sieht die Daten in Formularen mit MARC21-Feldern und Unterfeldern (10 Formulare je Satz). Lokale MARC-Felder können eingerichtet werden.
Weitere Tabellen für Erwerbungs- und Leihdaten. Vollständige Übersicht (180 Tabellen):
http://schema.koha-community.org/16_05/index.html


Normdaten
GND-Daten sind integrierbar, eigene Normdaten genauso.
Besonderheit: An jeder Stelle in jedem Datensatz kann man eine Normsatz-ID eingeben in der Form _nummer. Bei Anzeige, Export und Indexierung wird dann auf Wunsch an der Stelle automatisch der Namens- oder Schlagwort-Klartext eingesetzt. D.h. der Klartext braucht nicht im Datensatz zusätzlich zu stehen.
Gemäß den Gepflogenheiten von MARC21, d.h. GND-Nummer plus Klartext stehen in jedem Datensatz. Deshalb müssen die Klartexte periodisch erneuert werden, damit geänderte Ansetzungen wirksam werden. (So ist es in allen amerikanischen Systemen üblich.)


Datensatz-Anzeige
Freie Gestaltung der Indexierung und der Datenanzeige (Parameterdateien)
Viele lokale Einstellungen in .ini-Dateien bzw. FLEX-Skripten realisierbar

Eine Standard-Anzeige ist vorgegeben. Im Prinzip ist diese anpassbar, doch sind dazu tiefe Perl- und MARC-Kenntnisse nötig.



Datenexport
Ein "Export" ist für allegro alles, was aus den Daten gemacht wird, auch die Datenanzeige und sogar der Index. Die universelle Sprache dafür ist die Exportsprache. Exporte incl. Indexierung sind deshalb in jeder Hinsicht flexibel und schnell.
Viele Standard-Parameter, z.B. für MARC21, XML, MAB2, Pica3 oder auch Tabellen für externe Zwecke (z.B. Excel oder SQL) sind im Standardumfang enthalten.
Export ist als Unterfunktion auch in der Skriptsprache FLEX verfügbar, wobei FLEX die Exportsprache aber nur für wenige Spezialzwecke noch braucht. Mit FLEX ohne Parameter ist eine Schnellmethode für tabellarische Exporte vorhanden, mit der man beliebige Felder und Unterfelder in Tabellenzeilen verwandeln kann.
Exporte erfolgen in der Regel über SQL-Reports, d.h. die Grundstruktur von Exporten ist tabellarisch. Es gibt eine Reihe von fertig ausgearbeiteten Reports sowie einen menügeführten Report-Assistenten. Sollte das nicht ausreichen, können eigene SQL Reports geschrieben werden. Dazu muß man SQL beherrschen und braucht Kenntnisse der zugrundeliegenden SQL-Tabellen, und Zeit, die Reports auszuprobieren.
Ein eigentlicher Datenexport z.B. für Fremdsysteme kann nur mit MARC21 erfolgen oder in Form von CVS-Tabellen.


Datenimport
Standard-Importe: MAB2, Citavi, MARC21 (z.B. für Z39.50-Daten), u.a.
Ad-hoc Direkt-Importe aus DNB, GBV und anderen Z39.50-Quellen (mit FLEX-Skripten).
Älter ist die Importsprache, die nur noch für Spezialzwecke gebraucht wird; Beispiele: Pica-, MAB2- oder MARC21-Daten aus Download- oder Exportdateien anderer Systeme, auch CSV-Daten. Fremdstrukturen sind zwar vielfältig, aber mit FLEX oder mit der Importsprache stets beherrschbar.
Alle Einspeisungen in die Datenbank können im laufenden Betrieb geschehen.
Eigentlich nur Marc21 in einer etwas eigenwilligen Variante (Bereich Lokaldaten) kann importiert werden; d.h. andere Formate sind vorher mit anderen Mitteln in MARC21 zu wandeln.
Der Import der Standard-Marc21-Lieferungen erzeugt keine Exemplarsätze  oder Lokaldatensätze). Datenimport legt das System auf Stunden lahm.
Alternativ sind auf Systemebene CSV-Dateien möglich, die dann über SQL-Befehle importiert werden. Gute Kenntnisse in SQL sind Voraussetzung.
Direkte Übernahme möglich aus Z39.50/SRU-Serversystemen, z.B. DNB und GBV, falls man lokal katalogisiert und nicht im Verbund.


Erwerbung, Zeitschriftenbearbeitung, Ausleihe
 Alles realisiert mit der Skriptsprache FLEX (nicht in C), deshalb in jedem Aspekt flexibel. Alles realisiert mit Perl-Skripten und in jeder Hinsicht modifizierbar.


Allgemeine Information
 www.allegro-b.de : Aktuelle Downloads, Dokumentationen und Demo-Kataloge
Koha-Migration der Goethe-Institute (Projekt 2016-2018 beim SWB Konstanz)


Hinweise auf andere Systeme

Alle heute eingesetzten Systeme beruhen auf alten Konzepten und Strukturen, wozu insbes. das MARC-Format gehört.
Letzteres ist von der Library of Congress schon ausdrücklich als obsolet bezeichnet worden und soll von der
Initiative "BibFrame" in einigen Jahren abgelöst werden. Auch deshalb wird die Entwicklung neuer Software notwendig.
 
Es gibt Entwicklungsprojekte bei der VZG Göttingen mit dem HBZ Köln als Ablösung für LBS4:
 
Folio (früher Kuali und OLE) und LAS:er (früher VuFind 

FOLIO : Nachfolger von OLE Community, zusammen mit EBSCO:
   (für laufende Projekte s. insbes. Blog)

Die OLE-Community hat ein neues Pflichtenheft auf den Tisch gelegt:
Objectives for the building of an Open Source Next Generation Library Management System
(White Paper of OLE Community.)
Hier ist auch das bekannte Desiderat "Resource Management" mit einbezogen, das die alten
Systeme allesamt nur unzureichend oder gar nicht bedienen können. Zu erwarten ist jedoch,
daß nach dem RDA- und BibFrame-Umbruch in den kommenden Jahren neue Modelle und Produkte
auf dem Markt der bibliothekarischen Software auftauchen, gerade auch im OpenSource-Segment.

Was man aber auch jetzt schon machen könnte und was auf jeden Fall zukunftssicher ist:
Direkt Mitglied werden beim WorldCat (d.h. bei OCLC):  http://www.worldcat.org/librarians/default.jsp
Die Katalogisate von dort kann man auf verschiedene Weise ins eigene System übermittelt bekommen,
auf jeden Fall ist es immer im MARC-Format, also von allegro importierbar.
Es gibt wahlweise unterschiedliche Dienste für Mitglieder. s.a. OCLC FAQ
Wichtig: WorldCat-Daten werden auch in Google indexiert! Noch besser sichtbar kann man nicht werden ...
Es reicht dazu wohl nicht, wenn man nur in einem Verbund katalogisiert. Denn es ist so, dass
nicht die Daten jedes Teilnehmers automatisch in den WorldCat übernommen werden, sondern die
Spezialbibliotheken müssen dazu eigene Verträge mit OCLC abschließen und bezahlen.


2017-04-18 B.Eversberg / A. Wolf