| 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 | |
|
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/downloads/linux-prog.tar.gz |
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. |
| 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/downloads/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 (für ERM = Electronic Resource Management) 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. |