Jangle-API für Bibliothekssysteme

10. Juli 2008 um 15:00 2 Kommentare

Im VuFind-Projekt wird überlegt, Jangle als allgemeine Schnittstelle für Bibliothekssysteme zu verwenden, anstatt für jedes System die Anbindung neu anzupassen. Jangle wird von Ross Singer (Talis) vorangetrieben und steht anscheinend sowohl in Konkurrenz als auch in Kooperation mit der DLF working group on digital library APIs. Ob Jangle etwas wird und ob es sich durchsetzt, ist noch offen – zumindest ist mehr technischer Sachverstand dabei als bei anderen bibliothekarischen Standards.

Ich halte es zumindest für wichtig, in etwa auf dem Laufenden zu sein und bei Bedarf zu versuchen, Einfluss zu nehmen, falls die Entwicklung völlig an den eigenen Bedürfnissen vorbeigeht. So ganz verstanden habe ich Jangle allerdings bisher noch nicht. Statt eine neue Gesamt-API zu entwickeln, sollte meiner Meinung nach besser bei den existierenden Schnittstellen aufgeräumt werden – anschließend können diese dann ja in Jangle o.Ä. zusammengefasst werden.

Larry stellt Jangle und Primo gegenüber: auf der einen Seite der systematische OpenSource-Ansatz, in den man sich erstmal einarbeiten muss und der dafür insgesamt effizienter und flexibler ist und auf der anderen Seite das teure, unflexible Gesamtprodukt, das dafür schick aussieht. Leider geht es bei den Entscheidungsträgern meist primär um die Fassade, so dass sich OpenSource nur langsam (aber sicher) durchsetzt.

2 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Der Vergleich von Jangle und Primo passt nicht ganz, da sie doch sehr unterschiedlichen Zwecken dienen. Ein Open Source Projekt, das man mit Primo vergleichen könnte, wäre VuFind. Beide fallen in die Kategorie „Discovery Interface“ (altdeutsch „OPAC“).
    Jangle kann/soll ein Layer zwischen einem solchen Discovery Interface und einem Bibliothekssystem sein. Die Idee dabei ist es, grundsätzliche Funktionalitäten eines Bibliothekssystems über diesen einheitlichen Layer in verschiedenen Discovery Tools (oder anderen Anwendungen wie Lernplattformen usw.) zur Verfügung zu stellen.
    Klassische Bibliothekssysteme bieten leider entweder keine oder sehr „individuelle“/geschlossene Schnittstellen (auf die man ohne lizenzrechtliche Probleme mitunter nichtmal zugreifen darf) zum Zugriff auf ihre Funktionalitäten und Daten (z.B. zur Abfrage des Ausleihstatus, zum Abrufen einzelner Datensätze oder Authentifizieren von Benutzern). Will man nun also über so eine Anwendung wie VuFind, Primo oder eine Lernplattform Funktionalitäten des Bibliothekssystems nutzen, braucht man für jedes Bibliothekssystem derzeit eine indivduelle Anpassung (wenn sie denn technisch und rechtlich überhaupt möglich ist).
    VuFind realisert das derzeit über sogenannte Treiber für unterschiedliche Bibliothekssysteme (am besten wird wohl Voyager unterstützt, es existieren aber auch Treiber für andere vor allem im amerikanischen Raum verbreitete Bibliothekssysteme). Bei VuFind ist man nun auch auf die Idee gekommen, statt für jedes Bibliothekssystem individuelle Schnittstellen zu VuFind zu bauen, doch lieber ein allgemeines Framework wie Jangle (auf das eben auch andere Anwendungen aufsetzen können) einzusetzen. Gute Idee: So kann man vielleicht verhindern, dass die gleiche Arbeit mehrfach gemacht wird (Treiber für VuFind, Schnittstellen für Lernplattform A, Interfaces für Tool X…).
    Was man dazu aber braucht, ist eine Vorstellung davon, was denn so eine Abstraktionsschicht zwischen Bibliothekssystem und Anwendung leisten muss. Ãœberlegungen dazu mündeten z.B. in der Spezifikation für „ILS Discovery Interfaces“, an der sich nach meinem Verständnis auch Jangle orientiert.
    Mal gespannt, wann zum ersten Mal in Deutschland ein Bibliothekssystem mit „ILS-DI Layer“ bestellt wird oder explizit eine Schicht nach Jangle gefordert wird…

    Comment by till — 10. Juli 2008 #

  2. Noch ein Kommentar: Der erste war ja eher von technischen Argumenten geprägt. Daneben gibt es aber auch eine … hmmmm … weitere Ebene: Nehmen wir mal an, sowas wie Jangle (kann von mir aus auch etwas anderes sein) stellt über eine offene(!) Schnittstelle Funktionalitäten eines Bibliothekssystems bereit. Und diverse Discovery Tools, OPACs, vielleicht auch Fernleihsysteme, Lernplattformen, Literaturverwaltungen, Bücherwecker … (all das, was derzeit mühsam auf irgendwelchen[tm] Wegen mit Bibliothekssystemen kommuniziert) können wiederum solch eine Schnittstelle nutzen, um ihre tolle Funktionalität auf das Bibliothekssystem aufzusetzen. Dann hätte man ja die Wahl: Nehme ich VuFind oder Primo oder …? Und könnte zur Entscheidung ganz andere Kriterien heranziehen als die technische Machbarkeit. Und wenn man wollte, könnte man natürlich auch das System auf der anderen Seite der Schnittstelle austauschen, oder vielleicht sogar Teile davon… (OK, Bibliothekssysteme wechselt man nicht wie Unterwäsche, aber vielleicht ja gerade auch, weil sie sie monolithisch daherkommen).
    Wie auch immer: Die Folge davon könnte mehr Wettbewerb um bessere Software für Bibliotheken sein.
    Interessant ist doch, dass der Anstoß zu solchen offenen Schnittstellen oft aus der Open Source Ecke kommt. Ist das vielleicht ein Indiz für die Qualität, die da „produziert“ wird? Man scheut da nicht den Wettbewerb.
    Kommerzielle Hersteller müssten aber doch auch ein Interesse an offeneren Bibliothekssystemen haben. Der Markt für Bibliothekssysteme ist doch eigentlich aufgeteilt, die Anteile verschieben sich doch nicht mehr großartig (gerade weil es eben nicht so einfach ist, so ein System zu wechseln). Mit zusätzlichen Produkten, die mehr aus dem Bibliothekssystem machen, kann man aber doch zusätzliche Kunden gewinnen. Wenn ich mein Discovery Interface nicht nur meinen „eh-schon-Kunden“ (die dann auch noch Stammkundenrabatt wollen) anbieten kann, sondern auch Betreibern anderer Bibliothekssysteme, kann ich doch neue Kundschaft gewinnen. Wenn die dann erstmal mein Discovery Interface toll finden, kaufen sie ja vielleicht auch …

    Comment by till — 10. Juli 2008 #

Sorry, the comment form is closed at this time.