Mapping bibliographic record subfields to JSON

13. April 2011 um 16:26 4 Kommentare

The current issue of Code4Lib journal contains an article about mapping a bibliographic record format to JSON by Luciano Ramalho. Luciano describes two approaches to express the CDS/ISIS format in a JSON structure to be used in CoudDB. The article already provoked some comments – that’s how an online journal should work!

The commentators mentioned Ross Singer’s proposal to serialize MARC in JSON and Bill Dueber’s MARC-HASH. There is also a MARC-JSON draft from Andrew Houghton, OCLC. The ISIS format reminded me at PICA format which is also based on fields and subfields. As noted by Luciano, you must preserves subfield ordering and allow for repeated subfields. The existing proposals use the following methods for subfields:

Luciano’s ISIS/JSON:

[ ["x","foo"],["a","bar"],["x","doz"] ]

Ross’s MARC/JSON:

"subfields": [ {"x":"foo"},{"a":"bar"},{"x":"doz"} ]

Bill’s MARC-HASH:

[ ["x","foo"],["a","bar"],["x","doz"] ]

Andrew’s MARC/JSON:

"subfield": [
  {"code":"x","data":"foo"},{"code":"a","data":"bar"},
  {"code":"x","data":"doz"} ]

In the end the specific encoding does not matter that much. Selecting the best form depends on what kind of actions and access are typical for your use case. However, I could not hesitate to throw my encoding used in luapica into the ring:

{ "foo", "bar", "doz", 
  ["codes"] = { 
    ["x"] = {1,3}
    ["a"] = {2}
}}

I think about further simplifying this to:

{ "foo", "bar", "doz", ["x"] = {1,3}, ["a"] = {2} }

If f is a field than you can access subfield values by position (f[1], f[2], f[3]) or by subfield code f[f.x[1]],f[f.a[1]],f[f.x[2]]. By overloading the table access method, and with additional functions, you can directly write f.x for f[f.x[1]] to get the first subfield value with code x and f:all("x") to get a list of all subfield values with that code. The same structure in JSON would be one of:

{ "values":["foo", "bar", "doz"], "x":[1,3], "a":[2] }
{ "values":["foo", "bar", "doz"], "codes":{"x":[1,3], "a":[2]} }

I think a good, compact mapping to JSON that includes an index could be:

[ ["x", "a", "x"], {"x":[1,3], "a":[2] },
  ["foo", "bar", "doz"], {"foo":[1], "bar":[2], "doz":[3] } ]

And, of course, the most compact form is:

["x","foo","a","bar","x","doz"]

Zwei Jahre PICA::Record

20. Juli 2009 um 17:06 3 Kommentare

Heute vor zwei Jahren habe ich die erste öffentliche Version von PICA::Record auf CPAN hochgeladen. Das Comprehensive Perl Archive Network (CPAN) ist ein umfassendes Repository von Open-Source-Modulen für die Programmiersprache Perl. Mit Perl habe ich erst relativ spät angefangen, die die Sprache nicht sauber definiert und für ihre mögliche Unleserlichkeit bekannt ist. Andererseits trifft zu, was Larry Wall, der Autor von Perl 1999 sagte:

The very fact that it’s possible to write messy programs in Perl is also what makes it possible to write programs that are cleaner in Perl than they could ever be in a language that attempts to enforce cleanliness.

Die Tatsache, dass Programme (und damit ist hier der Quellcode gemeint) als „schön“ bezeichnet werden können zeigt, dass Programmieren auch als eine Kunst angesehen werden kann – und die Bühne für Perl ist dabei CPAN 🙂 Ãœbrigens habe ich bislang noch keine schöne kommerzielle Bibliothekssoftware gesehen – aber Bibliotheken geht es beim Erwerb von Software ja auch weniger darum, dass sie etwas schönes und sinnvolles mit der Software anfangen können, sondern darum dass sie die Verantwortung an einen Softwarehersteller abschieben können.

Das Modul PICA::Record hat wahrscheinlich nur einen ziemlich begrenzten Anwenderkreis, da das PICA+ Datenformat sogar bei vielen Bibliothekaren eher unbekannt ist. Inzwischen ist wahrscheinlich PICA::Record mit allen Beschreibungen, Tests und Beispielen selbst die umfangreichste Dokumentation zu PICA+. Seit dem Bibliothekstag 2009 gibt es auch eine Kurzbeschreibung als Faltblatt auf Deutsch („Verarbeiten von PICA+ Daten mit PICA::Record„). Die aktuelle Version enthält als neuestes die Möglichkeit, PICA-Daten in einer SQL-Datenbank (bislang: SQLite) zu speichern (PICA::SQLiteSTore) und über ein Wiki (PICA+Wiki) darauf zuzugreifen. Für kommende Versionen ist der Ausbau dieses „CMS-Light“, einer Erweiterung der SOAP-API zum Lesen und Schreiben von Datensätzen sowie eine bessere Unterstützung von Lokaldaten geplant.

Sicher gibt es schönere Programmiersprachen als Perl, aber wenn schon mehr Personen im Bibliotheksumfeld programmieren (oder zumindest skripten) lernen – was unbedingt notwendig ist – könnte Perl die richtige Wahl sein, da sich mit PICA::Record bereits nach kurzer Zeit praxistaugliche Ergebnisse erzielen lassen. Zum deutschsprachigen Austausch zwischen Entwicklern im Bibliotheksbereich gibt es übrigens die Mailingliste bibcode.

Umfrage und Studie zu Bibliothekssystemen

29. April 2008 um 10:47 6 Kommentare

Die Ergebnisse einer 2007 durchgeführten internationalen Umfrage zu Bibliothekssystemen (ILS) sind seit Januar verfügbar. Marshall Breeding hat die Umfrage durchgeführt und stellt mehrere Statistiken bereit (ansonsten schreibt Breeding an verschiedenen Stellen zur „New Generation of Library Interfaces„). Die in Deutschland verwendeten Bibliothekssysteme sucht man vergeblich: PICA LBS: 1 Antwort, LIBERO: 3 Antworten, Allegro: 0 Antworten, SISIS-SunRise: 0 Antworten. Angesichts der niedrigen Beteiligung aus Deutschland ist das aber auch nicht verwunderlich: von 1783 Antworten kamen genausoviele von Deutschen Bibliotheken, wie beispielsweise aus Malaysia, Libanon oder Singapur: nämlich 2. Es sei aber bemerkt, dass auch aus den im Vergleich zu Deutschland hinsichtlich ihrer Bibliothekssysteme aktiveren Niederlanden nur 5 Antworten kommen, die Masse ist aus dem Englischsprachigen Raum.

Ein wenig seltsam finde ich das schon, was ist die Schlussfolgerung? Deutsche Bibliotheken interessieren sich nicht für ihre Bibliothekssysteme? Deutsche Bibliotheken nehmen nicht an internationalen Umfragen teil? Die in Deutschland verwendeten Bibliothekssysteme sind sowieso hoffnungslos irrelevant? Was Softwaremäßig außerhalb des deutschen Bibliothekstellerands geschieht interessiert nicht? Umfragen werden überbewertet? …

Auf eine weitere Studie weist Lorcan Dempsey hin: „Library Management Systems Study: An Evaluation and horizon scan of the current library management systems and related systems landscape for UK higher education“ (PDF). Die Studie enthält einige sehr bemerkenswerten allgemeinen Aussagen („Key trends“) über die Entwicklung von Bibliothekssystemen: Standards, Web Services, Konsortien, Open Source, Open Data, Entkoppelte Systeme (Serviceorientierte Architektur). Es lohnt sich also auch hier mal reinzuschauen (wenn man sich für die Zukunft von Bibliothekssystemen interessiert). [via Web4lib].

Schnittstelle für Verfügbarkeitsdaten von Bibliotheksbeständen

21. Januar 2008 um 11:22 4 Kommentare

Letzen Dezember habe ich über Serviceorientierte Architektur geschrieben und bin unter Anderem auf den Heidelberger UB-Katalog eingegangen. Dabei ging es darum, wie Daten einzelner Exemplare von Bibliotheksbeständen – speziell Verfügbarkeitsdaten – über eine Schnittstelle abgefragt werden können. Bislang gibt es dafür keinen einfachen, einheitlichen Standards sondern höchstens verschiedende proprietäre Verfahren. Till hat mich zu Recht auf den Artikel „Beyond OPAC 2.0: Library Catalog as Versatile Discovery Platform“ hingewiesen, in dem die API-Architektur des Katalogs an der North Carolina State University vorgestellt wurde. Die Beispiele zeigen gut, was mit dem Buzzword „Serviceorientierte Architektu“ eigentlich gemeint ist, wie sowas in Bibliotheken umgesetzt werden kann und was für Vorteile der Einsatz von einfachen, webbasierten Schnittstellen bringt. Die als CatalogWS bezeichnete API ist – wie es sich gehört – offen dokumentiert. CatalogWS enthält einen Catalog Availability Web Service, der ausgehend von einer ISBN ermittelt, in welchen (Teil)bibliotheken ein Titel verfügbar oder ausgeliehen ist.

Bei Bedarf könnte ich mal versuchen, diese API für die GBV-Kataloge zu implementieren. Andererseits sollte man sich vielleicht erstmal Gedanken darüber machen, was es noch für Kandidaten für eine Verfügbarkeitsschnittstelle gibt und welche Daten über so eine Schnittstelle abfragbar sein sollten: Das NCIP-Protokoll scheint mir wie Z39.50 nicht wirklich zukunftsfähig zu sein. Janifer Gatenby macht in ihrem Vortrag „Bridging the gap between discovery and delivery“ (PPT) weitere durchdachte Vorschläge. Auf den Mailinglisten CODE4LIB und PERL4LIB habe ich letzte Woche herumposaunt, wie wichtig eine Holding-API wäre und dass das doch alles eigentlich ganz einfach sei. Neben Iinteressanten Bemerkungen zu FRBR bin ich daraufhin auf Holding-data in Z39.50 hingewiesen worden. In den PICA-LBS-Systemen stehen die Verfügbarkeitsdaten soweit ich es herausgefunden, habe im Feld 201@, aber nur teilweise. Für die weitere Umsetzung wäre es wahrscheinlich sinnvoll, erstmal alle in der Praxis vorkommenden Verfügbarkeits-Stati (ausleihbar, Präsenzbestand, Kurzausleihe, ausgeliehen, unbekannt…) zu ermitteln. Für elektronische Publikationen sollte die Schnittstelle außerdem irgendwie mit existierenden Linkresolvern zusammenarbeiten können. Eine einfache Schnittstelle für Verfügbarkeitsdaten von Bibliotheken ist also nicht ganz trivial, aber solange nicht jeder Spezialfall berücksichtigt wird oder erstmal ein Gremium eingesetzt werden muss, dürfte es machbar sein. Hat sonst noch jemand Interesse?

OCLC Grid Services – first insights

28. November 2007 um 10:58 1 Kommentar

I am just sitting at a library developer meeting at OCLC|PICA in Leiden to get to know more about OCLC Service Grid, WorldCat Grid, or whatever the new service-oriented product portfolio of OCLC will be called. As Roy Tennant pointed out, our meeting is „completely bloggable“ so here we are – a dozen of European kind-of system librarians.

The „Grid Services“ that OCLC is going to provide is based on the „OCLC Services Architecture“ (OSA), a framework by which network services are built – I am fundamentally sceptical on additional frameworks, but let’s have a look.

The basic idea about services is to provide a set of small methods for a specific purpose that can be accessed via HTTP. People can then use this services and build and share unexpected application with them – a principle that is called Mashups.

The OCLC Grid portfolio will have four basic pillars:

network services: search services, metadata extraction, identity management, payment services, social services (voting, commenting, tagging…) etc.

registries and data resources: bibliographic registries, knowledge bases, registries of institutions etc. (see WorldCat registries)

reusable components: a toolbox of programming components (clients, samples, source code libraries etc.)

community: a developer network, involvement in open source developement etc.

Soon after social services were mentioned, at heavy discussion on reviews, and commenting started – I find the questions raised with user generated content are less technical but more social. Paul stressed that users are less and less interested in metadata but directly want the content of an information object (book, article, book chapter etc.). The community aspect is still somehow vague to me, we had some discussion about it too. Service oriented architecture also implies a different way of software engineering, which can partly be described by the „perpetual beta“ principle. I am very exited about this change and how it will be practised at OCLC|PICA. Luckily I don’t have to think about the business model and legal part which is not trivial: everyone wants to use services for free, but services need work to get established and maintained, so how do we best distribute the costs among libraries?

That’s all for the introduction, we will get into more concrete services later.

Mehr zu Schnittstellen von Bibliothekssystemen

14. September 2007 um 11:47 5 Kommentare

Angeregt durch eine Frage zu SNLP auf Inetbib habe ich anknüpfend an meine vorhergehenden Überlegungen etwas weiter im Netz nach Schnittstellen zu Bibliothekssystemen recherchiert. Leider steht der Grad deren Dokumentation im umgekehrten Verhältnis zu ihrer Vielfalt. Die von Marshall Breeding publizierte Übersicht von Bibliothekssystemen ist auch nicht gerade vollständig, so hat er anscheinend von PICA noch nicht gehört. Deshalb erheben folgende Funde auch keinen Anspruch auf Vollständigkeit:

Zunächst einmal sind als Suchprotokolle das altehrwüdige Z39.50 und dessen Nachfolger SRU/SRW zu nennen. Zum asynchronen Abholen von Metadaten gibt es OAI-PMH. OAI wurde im Rahmen der Open Access- Bewegung für Preprint-Server eingesetzt und wird noch immer vor allem für Dokumentenserver eingesetzt. Etwas zwischen Schnittstelle und Format ist OpenURL angesiedelt, das für Linkresolver entwickelt wurde und inzwischen mit COinS auch zur Übertragung von Metadaten verwendet wird.

Was weitere Schnittstellen angeht sieht es leider etwas dürftig aus was die freie Verfügbarkeit betrifft. Die SirsiDynix-Werbeseite auf der statt auf Dokumentation auf Fortbildungen verwiesen wird, finde ich da symptomatisch: Es gibt zwar überall etwas aber jedes System hat seine eigene Schnittstelle, auf die sowieso nicht von Außen zugegriffen werden kann. Dazu gehört auch das Simple Library Network Protocol (SLNP), welches als interne API für Bibliothekssysteme der Sisis Informationssysteme GmbH entwickelt wurde und inzwischen auch von anderen Systemen wie Aleph, Bibliotheca unterstützt wird, um die Fernleihe zu koordinieren. Das alles spielt sich aber rein intern ab und hat mit Web 2.0 und Bibliotheks-Mashups noch nichts zu tun.

Auch im Open-Source-Bereich sieht es nicht besser aus. Für Koha ist bislang nur eine API geplant und die OpenSRF benannte API des ebenfalls freien Evergreen ist in seiner Unübersichtlichkeit und Komplexität auch eher für interne Zwecke gedacht. Die Talis API (siehe Dokumentation) sieht ganz gut durchdacht aus und wäre wahrscheinlich für viele Anwendungen brauchbar, aber ich kenne kein Bibliothekssystem, das sie unterstützt – dass so im luftleeren Raum dauerhaft verlässliche Schnittstellen entstehen, bezweifle ich. Etwas besser sieht die Open Library WebServices aus, die Oliver Flimm zur Anbindung von SISIS-Systemen an OpenBib entwickelt hat.

Worauf ich jedoch warte sind weitere Schnittstellen, die ohne großen Aufwand als Webservices auch von Außen benutzt können. Beispielsweise wäre nicht nur für Anbieter wie Bücherwecker eine API hilfreich, mit der Nutzer ihre Ausleihen samt Rückgabedatum abfragen können. Glücklicherweise hat – wie dem Vortrag von Norbert Weinberger auf der GBV Verbundkonferenz zu entnehmen ist – auch OCLC die Zeichen der Zeit erkannt und will in Zukunft mit einem „WorldCat Grid“ mehr in Richtung Serviceorientierte Architektur gehen. Ich bin gespannt, was sich da alles ergibt.

Falls keine API existiert oder diese nicht ausreichend dokumentiert ist, muss man wohl erstmal direkt auf die interne Datenbank des Bibliothekssystems zugreifen und selber etwas stricken. Das ist in der Regel aber nur dem Anbieter möglich und stellt keine nachhaltige Lösung dar. Bei Horizon soll das ganz gut gehen, hab ich mir sagen lassen. Möglicherweise kann auch noch mehr aus den Katalogdaten rausgeholt werden, die über Z39.50 oder SRU erhältlich sind. Bei PICA-Systemen steht der Ausleihstatus eines Mediums (ausleihbar, ausgeliehen, Präsenzbestand…) zum Beispiel anscheinend in Feld 201@, so sicher bin ich mir da aber nicht.

Für weitere Recherchen zum Thema habe ich im GBV Wiki habe ich vor einigen Wochen etwas mehr zu Webservices zusammengesammelt.

GBV-Verbunddaten weiterverarbeiten mit SRU-Schnittstelle und Perl

20. August 2007 um 14:58 2 Kommentare

Ende Juli habe ich im Rahmen meiner Arbeit bei der VZG mit PICA::Record eine Perl-API zur Verarbeitung von PICA+-Daten veröffentlicht. PICA+ ist das interne Katalogformat von PICA-Bibliothekssystemen, die neben dem GBV und den Verbünden HeBIS und SWB auch bei der Deutschen Nationalbibliothek und für Zentralsysteme in den Niederlanden, Australien, Frankreich und England eingesetzt werden. Inzwischen ist PICA übrigens eine vollständige OCLC-Tochterfirma. Mehr zum PICA+ Format findet sich in den jeweiligen Katalogisierungsrichtlinien, zum Beispiel beim GBV und in dieser kurzen Einführung.

PICA::Record ist sozusagen ein Pendant zu Mike Rylanders CPAN-Modul MARC::Record, das bereits seit einigen Jahren bei MARC-Anwendern genutzt und in der Mailingliste perl4lib diskutiert wird. Feedback in Form von Anwendungen, Ideen, Bugreports etc. ist sehr willkommen – zum Beispiel öffentlich bei der Dokumentation im GBV-Wiki. Neben der Erzeugung von Datensätzen in PICA+, um diese in Katalogsysteme einzuspielen, eignet sich PICA::Record auch für die umgekehrte Richtung. Dazu ist ein einfacher SRU-Client implementiert; die entsprechende SRU-Schnittstelle bietet der GBV seit einiger Zeit inoffiziell und nun auch öffentlich an. Für Bibliotheks-Mashups ist die SRU-Schnittstelle ein Baustein und die Perl-API ein mögliches Bindemittel. Natürlich kann der Webservice auch mit anderen Methoden als mit Perl abgefragt werden.

Beispiele und Anleitungen gibt es unter Anderem in der API-Dokumentation, im Quelltext oder hier.