Jakoblog — Das Weblog von Jakob Voß

XML Schema vs. Library APIs (OAI-PMH/SRU/unAPI…)

Much of our work at GBV library network has to do with record formats and APIs. We harvest or get metadata records in a wide range of formats (with many different interpretations and misconstructions of these formats), convert records to a wide range of formats (with many special request how to interpret this formats), and provide records through various APIs. Some of these APIs allow you to select different record formats, for instance OAI-PMH (first published 2001), SRU (2003), and unAPI (2006). These APIs are based on HTTP for transport and XML for encoding of the records. There are also older APIs and encoding formats like Z39.50 and newer APIs like pure Linked Data and SPARQL for RDF. unAPI also supports non-XML formats, but in this article I will concentrate on XML-based formats.

The basic question (that I deal with since years) is “what exactely is a format and how do you refer to it?”. All three APIs provide a method for listing of all formats that are supported by a particular server. unAPI provides a “list of object formats”. Each format has a “name”, a “type” (which must be an official Internet media type), and an optional documentation URL (“docs”), which may refer to some human-readable documentation, or to an XML Schema (XSD) file. Here are three examples:

<format name="oai_dc" type="application/xml"
  docs="http://www.openarchives.org/OAI/2.0/oai_dc.xsd"
/>
<format name="pubmed" type="application/xml"
  docs="http://www.nlm.nih.gov/bsd/licensee/elements_descriptions.html"
/>
<format name="mods" type="application/xml"
  docs="http://www.loc.gov/standards/mods/"
/>
<format name="marcxml" type="application/xml"
  docs="http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"
/>

To avoid the uncertainty whether “docs” references a formal schema or a plain document, there should have been a “schema” attribute (first problem). To refer to a format in an unAPI request, you use the format’s “name”. In OAI-PMH you refer to a format by its “metadataPrefix”. You can get a list of supported formats with the ListMetadataFormats request. In addition to the “metadataPrefix” each format has the location of an XML Schema (“schema”) and an XML Namespace URI (“metadataNamespace”). In theory the latter is dispensable, because each XSD document declares a namespace URI in its “targetNamespace” attribute: Given a format with a schema that defines namespace “http://example.org/” like this

<xs:schema targetNamespace="http://example.org/">

I would expect records in this format to use this namespace, at least for the XML root element:

<record xmlns="http://example.org/">

The OAI-PMH specification does not explicitly say that the “metadataNamespace” must match the namespace in the schema file “schema”. What does it mean if they differ? (second problem).

In SRU a format is known as “schema”. A list of supported formats is contained in an explain request. Each schema has an optional “title”, a “name” (used to refer to schemas in the “recordSchema” HTTP parameter when doing a search query), an “identifier”, and an optional “location”. The “identifier” contains an additional URI, and the “location” contains a link to an XML Schema file or to some human-readable documentation (like the “docs” attribute in unAPI). There is a list of known schemas at the SRU page, for instance:

Note that one name (for instance “mods”) can refer to several schemas, but one particular SRU server can only provide one particular format under this name. The additional identifier neither refers to a particular XML Schema (Third problem). The identifier may only give a hint which particular version or interpretation of a format is provided.

Does anyone really need this diverse methods to refer to formats? I found in practice you cannot rely on the claimed format anyway, unless you can automatically validate it. That’s what XML Schema can be used for. I don’t say that XML Schema is the best or only method to formally describe an XML-based format (personally I much bettter like RELAX NG), but if there is an XML Schema – shouldn’t this schema be enough to identify the format?. Is there really a need of four independent identifiers to refer to an XML-based format? In the worst case we have:

• Schema Name (e.g. mods)
• Schema Location (e.g. http://www.loc.gov/standards/mods/v3/mods-3-3.xsd)
• Schema Identifier (e.g. info:srw/schema/1/mods-v3.3)
• Schema Namespace (e.g. http://www.loc.gov/mods/v3)

This is bad design, because you cannot say which of the four is the right one and how they relate to each other. A clean solution would only have two identifiers for XML-based formats:

• The local name, which is only unique for a particular API and a particular server
• The global schema Location, which is a cool URI that resolves to an XML Schema file.

The Schema Namespace is included as “targetNamespace” in the XML Schema, and the Schema Identifier is delusion anyway. Either you can identify a format by a formal schema (that can also be used to validate records) or you just cannot guarantee which format your records will be in. Sure you can give some hints by linking to documentations, examples, and guidelines. But adding more identifiers is a fakery of control. You are still allowed to provide more specific formats, variants, application profiles, and interpretations under different names. But these formats don’t get more clear or usable if you give them a “Schema Identifier”. Does anyone uses SRU’s Schema Identifiers anyway? I think for XML we can better live with XML Schemas that the XML namespaces can be extracted from. An application can identify a format by its schema location, by the XML namespace, and/or by other information contained in the schema. Additional pointers to human-readable documentation are great. But don’t confuse description with identification if you need to refer to a data format.

P.S. At Code4lib mailing list Rob Sanderson pointed to our discussion we had about the same topic in 2009, and one of my earlier postings on XML4Lib also deals with SRU and namespaces.

How to encode the availability of documents

Since almost a year I work on a simple encoding format and API to just get the current (!) availability status of documents in libraries. Together with Reh Uwe (hebis network) and Anne Christensen (beluga project) we created the Document Availability Information API (DAIA) which is defined as data model with encoding in XML and JSON (whichever you prefer).

This week I finished and published a reference implementation of the DAIA protocol as open source Perl-module at CPAN. The implementation includes a simple DAIA validator and converter. A public installation of this validator is also available. The next tasks include implementing server and client components for several ILS software. Every library has its own special rules and schemas – Jonathan Rochkind already wrote about the problems to implement DAIA because of ILS complexity. We cannot erase this complexity by magic (unless we refactor and clean the ILS), but at least we can try to map it to a common data model – which DAIA provides.

With the DAIA Perl package you can concentrate on writing wrappers from your library systems to DAIA and easily consume and evaluate DAIA-encoded information. Why should everyone write its own routines to grab for instance the HTML OPAC output and parse availability status? One mapping to DAIA should fit most needs, so others can build upon. DAIA can not only be helpful to connect different library systems, but also to create mashups and services like “Show me on a map, where a given book is currently hold and available” or “Send me a tweet if a given books in my library is available again” – If you have more cool ideas for client applications, just let me know!

In the context of ILS Discovery Interface Task Force and their official recommendation DAIA implements the GetAvailability method (section 6.3.1). There are numerous APIs for several tasks in library systems (SRU/SRW, Z39.50, OpenSearch, OAI-PMH, Atom, unAPI etc.) but there was no open, usable standard way just to query whether a copy of given publication – for instance book – is available in a library, in which department, whether you can loan it or only use it in the library, whether you can directly get it online, or how long it will probably take until it is available again (yes, I looked at alternatives like Z39.50, ISO 20775, NCIP, SLNP etc. but they were hardly defined, documented, implemented and usable freely on the Web). I hope that DAIA is easy enough so non-librarians can make use of it if libraries provide an API to their system with DAIA. Extensions to DAIA can be discussed for instance in Code4Lib Wiki but I’d prefer to start with this basic, predefined services:

• presentation: an item can be used inside the institution (in their rooms, in their intranet etc.).
• loan: an item can be used outside of the institution (by lending or online access).
• interloan: an tem can be used mediated by another institution. That means you do not have to interact with the institution that was queried for this item. This include interlibrary loan as well as public online ressources that are not hosted or made available by the queried institution.
• openaccess: an item can be used imediately without any restrictions by the institution, you don’t even have to give it back. This applies for Open Access publications and free copies.

Link Resolver und Widgets im OPAC

Jonathan Rochkind hat in seinem Blog SeeAlso und Umlaut verglichen, die beide eine Form von Link Resolver darstellen. Während über SeeAlso ausgehend von einer ID (ISBN, ISSN, DOI, PPN, …) eine Liste von passenden Einträgen mit Links zurückgeliefert wird, liefert Umlaut ausgehend von einer OpenURL auch leicht komplexere Inhalte, wie zum Beispiel ein Formular, mit dem in verschiedenen Quellen im Volltext eines Buches gesucht werden kann. Die Abfrage geschieht jedoch leider nicht über eine standardisierte API sondern proprietär (d.h. nur Umlaut kann lesen was Umlaut liefert).

Nach meiner Auffassung ist Umlaut (wie Link Resolver im Allgemeinen) eine spezielle Form einer Metasuche. Über eine OpenURL-Anfrage können mehrere Dienste und Quellen (SFX, CrossRef, Amazon, OCLC Worldcat, ISBNdb, LibraryThing, Google Books, HathiTrust, OpenLibrary, the Internet Archive, Worldcat Identities …) gemeinsam abgefragt werden und die Ergebnisse werden auf einer Seite zusammengefasst (siehe Beispiel). Das Zusammenfassen von Inhalten aus mehreren Quellen kann allerdings auch im OPAC bei einer Titelanzeige geschehen (siehe Beispiel).

Allgemein ist für die Zusammenfassung von Inhalten aus unterschiedlichen Quellen (Mashup-Prinzip) hilfreich, wenn auf einheitliche APIs und Datenformate zurückgegriffen wird. Das populärste Beispiel ist RSS (bzw. ATOM). SeeAlso kann als API und Format für einfachere Listen dienen und für komplexere Inhalte käme vielleicht die Universal Widget API (UWA) in Frage. UWA-Widgets können auch in eigene Seiten eingebunden werden. Einen OPAC als Widget gibt es ja schon – wie wäre es umgekehrt einen OPAC aus Widgets zusammenzusetzen? Ich denke, dass es noch einige Zeit dauern wird, bis sich neben ATOM/RSS weitere gute Standards für die Aggregierung von Inhalten auf Webseiten durchsetzen. Praktische Beispiele gibt es ja inzwischen immer mehr, gerade hat Lorcan Dempsey einige davon zusammengefasst.

Jangle-API für Bibliothekssysteme

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.

Working group on digital library APIs and possible outcomes

Last year the Digital Library Federation (DLF) formed the “ILS Discovery Interface Task Force“, a working group on APIs for digital libraries. See their agenda and the current draft recommendation (February, 15th) for details [via Panlibus]. I’d like to shortly comment on the essential functions they agreed on at a meeting with major library system (ILS) vendors. Peter Murray summarized the functions as “automated interfaces for offloading records from the ILS, a mechanism for determining the availability of an item, and a scheme for creating persistent links to records.”

On the one hand I welcome if vendors try to agree on (open) standards and service oriented architecture. On the other hand the working group is yet another top-down effort to discuss things that just have to be implemented based on existing Internet standards.

1. Harvesting: In the library world this is mainly done via OAI-PMH. I’d also consider RSS and Atom. To fetch single records, there is unAPI – which the DLF group does not mention. There is no need for any other harvesting API – missing features (if any) should be integrated into extensions and/or next versions of OAI-PMH and ATOM instead of inventing something new. P.S: Google Wave shows what to expect in the next years.

2. Search: There is still good old overblown Z39.50. The near future is (slightly overblown) SRU/SRW and (simple) OpenSearch. There is no need for discussion but for open implementations of SRU (I am still waiting for a full client implementation in Perl). I suppose that next generation search interfaces will be based on SPARQL or other RDF-stuff.

2. Availability: The announcement says: “This functionality will be implemented through a simple REST interface to be specified by the ILS-DI task group”. Yes, there is definitely a need (in december I wrote about such an API in German). However the main point is not the API but to define what “availability” means. Please focus on this. P.S: DAIA is now available.

3. Linking: For “Linking in a stable manner to any item in an OPAC in a way that allows services to be invoked on it” (announcement) there is no need to create new APIs. Add and propagate clean URIs for your items and point to your APIs via autodiscovery (HTML link element). That’s all. Really. To query and distribute general links for a given identifier, I created the SeeAlso API which is used more and more in our libraries.

Furthermore the draft contains a section on “Patron functionality” which is going to be based on NCIP and SIP2. Both are dead ends in my point of view. You should better look at projects outside the library world and try to define schemas/ontologies for patrons and patron data (hint: patrons are also called “customer” and “user”). Again: the API itself is not underdefined – it’s the data which we need to agree on.

Bücher, die ich schon mal ausgeliehen hatte…

Haftgrund berichtet, dass es in Wiener Büchereien “aus Datenschutzgründen” nicht mehr möglich ist, im Bibliothekssystem auf Wunsch die Titel zu speichern, die man in der Vergangenheit schon mal ausgeliehen hatte. Schön, dass Bibliotheken anders als die meisten Webanbieter auf Datenschutz achten und nicht bis in alle Ewigkeiten speichern, wer wann was gemacht hat. In diesem Fall ist die Begründung aber wohl eher vorgeschoben, schließlich klingt “Datenschutz” auch kompetenter als “unsere Software kann das nicht und/oder wir wissen nicht wie man sowas technisch umsetzt”. Die Möglichkeit, alle ausgeliehenden Bücher automatisch in einer Liste abzuspeichern, ist meinem Eindruck nach in Bibliotheken ebenso nützlich wie selten.

Wie Edlef bemerkt, kann man ausgeliehene Bücher ja auch “in citavi, Librarything oder beliebigen anderen Literaturverwaltungssystemen für sich selbst [speichern]” – was prinzipiell tatsächlich die bessere Variante ist. Nur sollten Bibliotheken Nutzer dabei nicht in “kenn wa nich, wolln wa nicht, ham wa nich, geht nich”-Manier abspeisen, sondern aktiv für die Verknüpfung von Bibliothekssystemen mit Literaturverwaltungssystemen sorgen. Alles was über ein Feld “Ausleihen automatisch bei BibSonomy/LibraryThing/etc. eintragen” im Benutzerkonto hinausgeht, ist nicht zumutbar und überflüssig.

Ein Lösungsansatz gemäß Serviceorientierter Architektur sähe folgendermaßen aus:

Das Ausleihsystem bekommt eine Webschnitttstelle, über die Nutzer abfragen können, welche Medien sie zur Zeit ausgeliehen haben. Wenn dabei RSS oder ATOM eingesetzt wird (natürlich nur über HTTPS und mit Passwort), sollten gängige Feed-Aggregatoren damit klarkommen. Bisher muss der Zugang zum Ausleihsystem für jede Anwendung wie Bücherwecker einzeln gehackt werden, was mühsam und fehleranfällig ist. Die ausgeliehenen Werke sollten (per URL-Parameter steuerbar) in möglichst vielen Datenformaten beschrieben werden. Prinzipiell reicht aber auch die Standard-Kurztitelanzeige und ein Identifier, mit dem z.B. über unAPI weitere Details in verschiedenen Datenformaten angefordert werden können. Zusätzlich zu diesem Pull-Verfahren sollte die Möglichkeit gegeben werden, á la Pingback andere Dienste zu benachrichtigen sobald ein Benutzer ein Medium ausgeliehen hat.

Den Rest (das automatische Eintragen in eine Literaturverwaltung) kann – und sollte – bei gegebenen APIs eine eigene Anwendung übernehmen. Es würde mich nicht wundern, wenn die fixen Entwickler von LibraryThing das selber basteln oder sich ein Student im Rahmen einer Diplom- oder Bachelorarbeit daran setzt. Sobald saubere, einfache Schnittstellen verfügbar sind, ist der Aufwand für neue “Mashups” und Zusatzdienste minimal.

Schnittstelle für Verfügbarkeitsdaten von Bibliotheksbeständen

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?

thingISBN is getting better – so does SeeAlso

Tim Spalding points out that thingISBN is getting better [via FRBR blog] – a good reason to update the thingISBN data of our SeeAlso Linkserver isbn2librarything. It now includes 2994299 ISBNs, that’s almost 12 times the size of the isbn2wikipedia linkserver. But what’s a linkserver? A linkserver is a server that gets an identifier (for instance an ISBN) and gives you links (for instance a link to a work at LibraryThing). You can try out some SeeAlso linkservers at a demo page or start to implement your own.

To get an impression, look in GBV union catalog, for instance this record: after a short moment, a link to German Wikipedia is included. More and more German libraries follow to include such additional links in their catalog. The Catalog of University Bremen includes both links to (German) Wikipedia and links to LibraryThing (you have to click at “weitere Informationen…” at a selected record):

There is also an experimental ISBN2WorldCat linkserver. But linkservers that only send one or zero links are not very effective. I could combine multiple service to something like ISBN2SocialCataloging or such. Any suggestions for other services that libraries might not be frightened to link to? I’d also like to include more data in the link to LibraryThing (for instance the number of reviews) but unless German libraries wake up to ask for LibraryThing for Libraries I better not reimplement services that LibraryThing already offers.

The linkserver model could also be used to provide links to library holding and thus implement a FRBR-Manifestation to FRBR-Item mapping. As I just wrote at CODE4LIB and PER4LIB, a simple data format for holding information is needed to do so.

First Draft of SeeAlso Simple linkserver API

I finally finished the first draft of the SeeAlso Simple Specification . The webservice API for simple linkservers is based on OpenSearch Suggestions. It will be completed by the “SeeAlso Full Specification” which adds unAPI and OpenSearch Description documents. The service is already implemented and running at the Union Catalog of GBV, see my earlier posting or simply have a look at this example. The same service is installed for testing at the Wikimedia Toolserver. For Wikipedia I drafted a different client that can be tested via a Bookmarklet: Drag the Link “ISBN2W” to you bookmark toolbar, visit an English or German Wikipedia article with ISBNs on it, click the Bookmarklet link in your toolbar and hover the the ISBNs (that will become yellow) with the mouse. German Wikipedia users can also enable the service by adding a line of JavaScript to their user profile.

An implementation (SeeAlso Simple and SeeAlso Full) in Perl is available at CPAN (there was neither unAPI nor OpenSearch Suggestions, so I implemented both). Please note that ISBN to Wikipedia is only one example how the API can be used. In my opinion the concept of a linkserver is highly undervalued but will become more important again (for instance as a lightweigth alternative to simple SPARQL queries). Feedback and usage is welcome!

Linking to Wikipedia via ISBN

Two weeks ago I announced a new beta webservice for linking from title data to German Wikipedia articles that cite a given work by ISBN. Now Lambert pointed me to a message by Eric Hellmann about xISBN supporting links to the English Wikipedia since last week. This makes GBV one week earlier then OCLC and both of us ten month later then LibraryThing. The idea is not new but based on the work of Lars Aronsson, Spiritus rector of future library systems.

The three services have been developed partly parallel based on some same code. Here are two examples of the xISBN service by Xiaoming Liu and the GBV service that I am developing. xISBN is based on a powerfull API with many query parameters and planned to be part of WorldCat Grid Services (more about this maybe here, here, here, and here), while my service is based on a simple API called SeeAlso which is based on OpenSearch Suggestions and unAPI. Both approaches have their pros and cons. I will provide more information as soon as our server is more stable and the scripts are clean enough to get published at CPAN. Meanwhile I encourage everyone to play with OCLC’s xISBN (via an API of its own), WorldCat Idenities (via SRU), LibraryThing for Libraries (via an API of its own), available catalouges (via Z39.50, via SRU and via other APIs), the Wikipedia Query API, and the growing number of other services. Let’s mash up the library systems for the future!