Wie muss eine einfache Benutzerkonto-API beschaffen sein?

[sieh...@googlemail.com]

Liebe Kollegen,

Seit einiger Zeit arbeite ich an der Spezifikation einer API für Benutzerkontos aus Bibliothekssystemen. Solch eine API ist notwendig zur Anbindung an Discovery-Systeme, für mobile Apps und andere Anwendungen. Beispielsweise ließe sich mit einer Benutzerkonto-API sehr einfach eine Bücherwecker-Funktion umsetzen.

Ich habe mir vorher angeschaut, was es bereits an APIs gibt (NCIP, DLF-ILS, VuFind-Treiber...) und finde das alles nicht sehr überzeugend. Alles was ich bisher gesehen habe ist zu komplex, zu ungenau spezifiziert und zu sehr auf eine Anwendung fixiert. Deshalb halte ich eine einfache, genau spezifizierte und gut dokumentierte eigene API für sinnvoller als bestehende Standards umzuinterpretieren, so dass am Ende doch wieder etwas eigenes herauskommt. Natürlich habe ich das Rad nicht neu erfunden, sondern versucht, den Kern aus bestehden Lösungen herauszudistillieren.

Unter https://docs.google.com/document/d/1OR-RMjsFZRoEzohGMiBXpiaQludDREHe9X9eWUUAy9U/edit findet ihr einen aktuellen Entwurf einer Benutzerkonto-API, der bis nächsten Donnerstag noch verändert werden kann, danach geht hoffentlich ein Auftrag zur Umsetzung raus. ich würde mich freuen, wenn ihr euch die Spezifikation mal anschaut und noch Raum für Vereinfachungen und für genauere Spezifikation seht. Vor allem folgende Fragen sind noch offen: 

1. Welche Arten von Benutzerstatus gibt es? (z.B. aktiv und gesperrt)

2. Welche Arten von Ausleihen und Bestellungen gibt es? (z.B. ausgeliehen, vorgemerkt, bestellt, im Vormerkregal, etc.)

Vielleicht könnt ihr mal in eurem Bibliothekssystem schauen, was es da für Fälle gibt. Der übliche Weg wäre es, solche Felder einfach frei zu lassen. Gerade dass möchte ich aber mit der Spezifikation der API aber vermeiden: lieber es wird der Allgemeinfall genau abgedeckt als zu dass jeder Speziallfall ausdrückbar ist und wieder jeder seine eigene Terminologie benutzt.

Schöne Grüße

Jakob Voß

[sieh...@googlemail.com]

Hallo,

Ich habe auch nochmal auf Inetbib und Code4lib nachgefragt, Vielen Dank für die bisherigen Rückmeldungen. Nach dem Einarbeiten des Feedbacks sieht die Spezifikation so aus wie unter 

https://docs.google.com/document/d/1OR-RMjsFZRoEzohGMiBXpiaQludDREHe9X9eWUUAy9U/edit

dokumentiert. Viel Raum für Vereinfachung ist anscheinend leider nicht mehr. Für den Benutzerstatus reichen vier Fälle, wobei nur die ersten beiden Unterstützt werden müssen:

0: aktiv

1: gesperrt

2: gesperrt aufgrund abgelaufenes Ausweises

3: gesperrt aufgrund ausstehender Gebühren

Die "Arten von Ausleihen und Bestellungen" habe ich als "Dokumentstatus" zusammengefasst. Hier gibt es etwas Verwirrung mit dem Verfügbarkeitsstatus, der ja bereits mit DAIA spezifiziert ist. Es reichen nach aktuellem Stand folgende Werte für die aktuelle Beziehung zwischen einem Nutzer und einem Titel oder Exemplar:

- vorgemerkt: der Nutzer möchte das Dokument aber es kann noch nicht bereitgestellt werden, i.d.R. weil ein anderer Benutzer es hat.

- bestellt: der Nutzer bekommt das Dokument in Kürze, die Bereitstellung ist in Bearbeitung, z.B. weil es aus dem Magazin kommt oder zugeschickt wird.

- entliehen: der Nutzer hat das Dokument bzw. Zugriff auf das Dokument. 

- bereitgestellt: Dokument liegt für den Nutzer bereit

- abgelehnt: der Wunsch des Nutzers nach dem Dokument wurde abgelehnt, z.B. weil der Nutzer nicht (mehr) berechtigt ist oder weil das Dokument nicht auffindbar ist.

Sonderfälle, wie zum Beispiel Handapparate oder Lesesaalausleihen müssen je nach Eigenheiten des Bibliotheksystems auf einen dieser Ausleihstatus gemappt werden. Unter "Übergänge des Dokumentstaus" sind die üblichen Veränderungen des Dokumentstatus illustriert.

Folgende Punkte habe ich bislang aus der API rausgelassen, da wäre noch Feedback hilfreich:

- Anzahl der Mahnungen, Mahnstufen etc.

- Information darüber ob ein Exemplar verlängerbar ist

- Information darüber ob eine Bestellung/Vormerkung stornierbar ist

- Adresse, Telefon u.A. Eigenschaften eines Nutzers

- Spezielle Fehlercodes, *warum* eine Bestellung, Vormerkung 

  oder Verlängerung nicht möglich ist

- Auswahl des Ortes an den eine Bestellung geliefert werden soll

Schöne Grüße

Jakob