Dead End Electronic Resource Citation (ERC)

29. März 2013 um 11:51 Keine Kommentare

Tidying up my PhD notes, I found this short rant about „Electronic Resource Citation“. I have not used it anywhere, so I publish it here, licensed under CC-BY-SA.

Electronic Resource Citation (ERC) was introduced by John Kunze with a presentation at the International Conference on Dublin Core and Metadata Applications 2001 and with a paper in the Journal of Digital Information, Vol. 2, No 2 (2002). Kunze cited his paper in a call for an ERC Interest Group within the Dublin Core Metadata Initiative (DCMI) at the PERL4LIB mailing list, giving the following example of an ERC:

erc:  Kunze, John A. | A Metadata Kernel for Electronic Permanence
      | 20011106 |

An ERC is a minimal „kernel“ metadata record that consist of four elements: who, what, when and where. In the given example they are:

who:   Kunze, John A.
what:  A Metadata Kernel for Electronic Permanence
when:  20011106

Ironically the given URL is obsolete, the host ‚‘ does not even exist anymore. The ERC is pretty useless if it just uses a fragile URL to cite a resource. How about some value that does not change over time, e.g:

where: Journal of Digital Information, Volume 2 Issue 2

As ERC is defined as „a location or machine-oriented identifier“, one could also use stable identifiers:

where: ISSN 1368-7506, Article No. 81

Both ISSN and article numbers 81 are much more identifiers then URLs. Citing an URL is more like

where: at the desk in the little reading room of my library

By the way the current location is – but who knows whether Texas A&M University will still host the journal at this URL in 20 years?

There are some interesting ideas in the original ERC proposal (different kinds of missing values, TEMPER date values, the four questions etc.), but its specification and implementation are just ridiculous and missing references to current technology (you know that you are doing something wrong in specification if you start to define your own encodings for characters, dates etc. instead of concentrating to your core subject and refering to existing specifications for the rest). The current draft (2010) is a typical example of badly mixing modeling and encoding issues and of loosing touch with existing, established data standards.

In addition to problems at the „low level“ of encoding, the „high level“ of conceptual modeling lacks appropriate references. What about the relation of ERC concepts to models such as FRBR and CIDOC-CRM? Why are ‚who‘, ‚when‘, ‚where‘, ‚what‘ the important metadata fields (in many cases the most interesting question is ‚why‘)? How about Ranganathan’s colon classification with personality, matter, energy, space, and time?

In summary the motivation behind ERC contains some good ideas, but its form is misdirected.

Who identifies the identifiers?

10. Mai 2009 um 16:39 7 Kommentare

A few days ago, after a short discussion on Twitter, Ross Singer posted a couple of open questions about identifiers for data formats on code4lib and other related mailing lists. He outlined the problem that several APIs like Jangle, unAPI, SRU, OpenURL, and OAI-PMH use different identifiers to specify the format of data that is transported (MARC-XML, Dublin Core, MODS, BibTeX etc.). It is remarable that all these APIs are more or less relevant only in the libraries sector while the issue of data formats and its identifiers is also relevant in other areas – looks like the ivory tower of library standards is still beeing build on.

The problem Ross issued is that there is little coordination and each standard governs its own registry of data format identifiers. An inofficial registry for unAPI [archive] disappeared (that’s why I started the discussion), there is a registry for SRU, a registry for OpenURL, and a list for Jangle. In OAI-PMH and unAPI each service hosts its own list of formats, OAI-PMH includes a method to map local identifier to global identifiers.

On code4lib several arguments and suggestions where raised which almost provoced me to a rant on library standards in general (everyone want’s to define but noone likes to implement and reuse. Why do librarians ignore W3C and IETF?). Identifiers for data formats should neither be defined by creators of transport protocols nor do we need yet another über-registry. In my point of view the problem is less technical but more social. Like Douglas Campbell writes in Identifying the identifiers, one of the rare papers on identifier theory: it’s not a technology issue but a commitment issue.

First there is a misconception about registries of data format identifiers. You should distinguish descriptive registries that only list identifiers and formats that are defined elsewhere and authoritative registries that define identifiers and formats. Yes: and formats. It makes no sense to define an identifier and say that is stands for data format X if you don’t provide a specification of format X (either via a schema or via a pointer to a schema). This already implies that the best actor to define a format identifier is the creator of the format itself.

Second local identifiers that depend on context are always problematic. There is a well-established global identifier system called Uniform Resource Identifier (URI) and there is no excuse not to use URIs as identifiers but incapability, dullness, laziness, or ignorance. The same reasons apply if you create a new identifier for a data format that already has one. One good thing about URI is that you can always find out who was responsible for creating a given identifier: You start with the URI Scheme and drill down the namespaces and standards. I must admin that this process can be laborious but at least it makes registries of identifiers descriptive for all identifiers but the ones in their own namespace.

Third you must be clear on the definition of a format. For instance the local identifier „MARC“ does not refer to a format but to many variants (USMARC, UNIMARC, MARC21…) and encodings (MARCXML/MARC21). This is not unusual if you consider that many formats are specializations of other formats. For instance ATOM (defined by RFC4287 and RFC5023, identified either its Mime Type „application/atom+xml“ which can could expressed as URI or by its XML Namespace „“)* is extended from XML (specified in [XML 1.0] and [XML 1.1], identified by this URLs or by the Mime Type „application/xml“ which is URI*.

The problem of identifying the right identifiers for data formats can be reduced to two fundamental rules of thumb:

1. reuse: don’t create new identifiers for things that already have one.

2. document: if you have to create an identifier describe its referent as open, clear, and detailled as possible to make it reusable.

If there happen to exist multiple identifiers for one thing, choose the one that is documented and adopted best. There will always be multiple identifiers for the same thing – don’t make it worse.

*Footnote: The identification of Internet Media Types with URIs that start with is neither widely used nor documented well but it’s the most official URI form that I could find. If for a particular format there is a better identifier – like an XML or RDF namespace – then you should use that, but if there is nothing but a Mime Type then there is no reason to create a new URI on your own.

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.

Working group on digital library APIs and possible outcomes

13. April 2008 um 14:48 3 Kommentare

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.

Pseudo-URIs als Identifikatoren für Normdaten der Deutschen Nationalbibliothek

7. April 2008 um 03:31 7 Kommentare

Die Deutsche Nationalbibliothek (DNB) hat anscheinend Ende März eine neue Katalog-Oberfläche online gestellt – der alte OPAC ist auch noch verfügbar. Dabei sind unter Anderem die Normdaten (SWD, GKD, PND) teilweise besser integriert. Ich warte ja schon seit einiger Zeit darauf, dass endlich richtige URIs vergeben werden, so dass sich Normdaten global referenzieren lassen. Bei der aktuellen Lösung ist aber leider einiges schiefgelaufen.

Was ist eine URI?
Die Diskussion zum Thema URI/URN/URL auf Inetbib hat mal wieder gezeigt, dass es beim Thema Identifikatoren oft Missverständnisse gibt. Die international allgemeine Form globaler Identifikatoren ist der „Uniform Resource Identifier“ (URI) bzw. die Erweiterung „Internationalized Resource Identifier“ (IRI). Sie sind in RFC 3986 und RFC 3987 standardisiert. Die Vergabe von UR regelt RFC 4395. Verschiedene URI-Schemata (gekennzeichnet durch den Teil einer URI bis zum ersten Doppelpunkt) sind jeweils mit einem eigenen Standard registriert und definiert, zum Beispiel URNs durch RFC 2141.

Viele URI-Schemata legen Namensräume und eigene Regeln zur Struktur und Vergabe von Identifikatoren fest. So zum Beispiel RFC 3406 für URNs und RFC 3044 für den URN-Namensraum urn:issn zur Abbildung von ISSNs. Durch die Formulierung von ISSNs als URI können diese bereits etablierten aber nur begrenzt nutzbaren Identifikatoren auch global genutzt werden, beispielsweise im Rahmen des Semantic Web. Während die Zeichenfolge „0024-9319“ sehr unterschiedliches identifizieren kann, weist „urn:issn:0024-9319“ eindeutig auf die amerikanische Ausgabe des MAD-Magazins hin.

Um welche Identifikatoren geht es?
Zur Identifikation von Personen (PND), Begriffen (SWD) und Körperschaften (GKD) gibt es im deutschen Bibliothekssystem seit vielen Jahren etablierte Normdaten. Abgesehen von wenigen Ausnahmen fristen diese Normdaten bzw. ihre Identifikatoren jedoch eher ein Schattendasein. Andere Identifikatoren, wie beispielsweise die Nummern von OCLC und der Library of Congress werden dagegen auch zunehmend von den „global players“ im Netz verwendet (von Google und LibrayThing). Wenn sie endlich mit URIs versehen und frei veröffentlicht würden, könnten die deutschen Normdateien ebenfalls weitere Verbreitung finden – oder andernfalls an Bedeutung verlieren.

Was hat die DNB falsch gemacht?
Anscheinend ist nun bei der Erstellung von Identifikatoren für Normdaten bei der Deutschen Nationalbibliothek gleich an mehreren Stellen etwas schief gelaufen. Dabei sieht es auf den ersten Blick ganz gut aus: Beim SWD-Eintrag „Poetry Slam“ ist beispielsweise dort als „Id“ die Zeichenkette „info://“ angegeben:

Ist das eine URI? Nein. In der offiziellen Liste von URI-Schemata ist „info:“ als gültiges URI-Schema eingetragen, das durch RFC 4452 definiert wird. Die dort festgelegte Maintenance Authority NISO hat die Verwaltung von Namensräumen an OCLC weitergegeben. Nun bekleckert sich OCLC mit dem seit Wochen nicht erreichbaren Verzeichnis der vergebenen Unternamensräume auch nicht gerade mit Ruhm, aber immerhin gibt es klare Standards (mehr Informationen bei der LOC). Eine info-URI ist aufgebaut nach dem Schema „info:NAMENSRAUM/LOKALTEIL„. Die Zeichenkette „info://“ kann also schon formal keine URI sein. Außerdem ist „“ nicht als gültiger info-URI Namensraum registriert. Zu allem Ãœberfluss wird nicht auf die etablierten SWD-Nummern zurückgegriffen (die SWD-Nummer für den SWD-Datensatz ist „4709615-9“), sondern als lokaler Bestandteil die nicht standardisierte, systemabhängige PND-Nummer (hier: 965692973) verwendet!

Wie lässt sich der Schlamassel beheben?
Leider ist dies nicht das erste mal, dass sich die DNB im Internet lächerlich macht. Zum Glück lassen sich die Fehler relativ einfach beheben.

1. Die bereits existierenden „Standards“ für die existierenden Normdaten-Nummern werden explizit und verlässlich festgeschrieben, d.h. erlaubte Zeichen und Wertebereiche, Berechnung der Prüfziffer und Normalisierung (siehe LCCN-Normalisierung).

2. Die DNB reserviert für die Normdaten-Nummern einen URI-Namensraum (beispielsweise info:swd, info:pnd, info:gkd). Dabei sind die Regeln zur Syntax und Vergabe von URI-Schemata und Namensräumen einzuhalten. Internationale Standards sind zum Lesen und Einhalten da und nicht zum Ignorieren und Uminterpretieren.

3. Die URIs werden verständlich dokumentiert und propagiert. Die Kür wäre eine völlige Freigabe der Normdaten als öffentlicher Datenbank-Abzug unter einer freien Lizenz.

Zur Klärung der Konfusion bezüglich URI und URL sei auf die Artikel URIs, URLs, and URNs: Clarifications and Recommendations (via Kay Heiligenhaus) und On Linking Alternative Representations To Enable Discovery And Publishing hingewiesen.

P.S: Eine bibliotheksrelevante Anwendung von von Identifikatoren für Personen wurde letzte Woche von Arjan Hogenaar and Wilko Steinhoff im Vortrag Towards a Dutch Academic Information Domain auf der Open Repositories 2008 vorgestellt.

Freies Linux-Handy Neo 1973 mit OpenMoko

12. März 2008 um 12:13 4 Kommentare

Angesichts der Verzögerung beim ersten freien Handys „Neo 1973“ von OpenMoko (siehe OpenMoko-Wiki und Fotos) hatte ich die Hoffnung auf ein Linux-Handy schon aufgegeben und war kurz davor, mir ein normalen Mobiltelefon zu kaufen. Seit Wochen bin ich deshalb auf der Suche nach einem einfachen Handy, dass auch als MP3-Player verwendet werden kann (gerne auch Videos) und über einen Standard-Klinkenstecker für Audio (!) und einen (micro-)USB Anschluss zum Aufladen (!) verfügt. Der Speicher für MP3s, Videos und beliebige andere Dateien soll ohne irgendwelche Spezialsoftware per USB zugänglich sein, so dass sich dass Handy mit einem stinknormalen USB-Kabel auch als USB-Stick verwenden lässt. Außerdem sollte wenigstens das Adressbuch unter Linux synchronisierbar sein. Anscheinend ist das zuviel verlangt, denn proprietäre Spezialkabel, Aufladegeräte und Synchronisierungssoftware sind der Normalfall. Wie ignorant die Hersteller in diesem Punkt sind, zeigt die Recherchemöglichkeit nach praktisch allen Eigenschaften der Geräte – außer den von mir geforderten! Ich verlange ja nicht, dass alles Open Source sein muss, aber offene Standards sollten schon sein.

Gestern hat OpenMoko die CAD-Baupläne des Neo 1973 unter der CC BY-SA Lizenz freigegeben – neben der Software ist also auch das Gehäusedesign frei veränderbar. Die für den Massenmarkt geplante, überarbeitete „Neo FreeRunner“ soll noch im „Frühjahr Frühsommer 2008″ verfügbar sein – ich schätze mal, dass heisst dann frühestens im August.

Aktuelle Projekte und Formate zu Strukturdaten

18. Februar 2008 um 18:04 1 Kommentar

Mit zunächst ZVDD und nun TextGrid gibt es im deutschen Sprachraum mindestens ein größeres bibliothekarisches DFG-Projekt, dass sich auch der Erschließung von Dokumenten unterhalb der bibliographischen Ebene annimmt. Inzwischen werden im bibliothekarischen Umfeld diese Erschließungsdaten wie zum Beispiel Kapitelgliederung und Paginierung als „Strukturdaten“ bezeichnet (wie es im Englischsprachigen Umfeld aussieht, weiß ich nicht). Standardformate zur Kodierung von Stukturdaten sind der Metadata Encoding and Transmission Standard (METS) und das Format der Text Encoding Initiative (TEI). Der vor kurzem in einer ersten Version veröffentlichte DFG-Viewer basiert auf Strukturdaten im MODS-Format, bislang werden allerdings noch keine Inhaltsverzeichnisses unterstützt. Bislang werden Strukturdaten vor allem im Rahme der Digitalisierung und Archivierung eingesetzt. Ein Beispiel zur Archivierung ist die Dissertation Markup Language (DiML) – als ich als HiWi daran gesessen habe, hat das allerdings noch niemand ein Strukturdatenformat genannt. Ein weiteres Format, das zur Speicherung von Strukturdaten eingesetzt werden kann ist OpenDocument (ODF). Mit der nächsten Version dürfte ODF noch interessanter werden – derzeit sitzt eine Arbeitsgruppe daran, die Einbindung von Metadaten in ODF-Dokumenten auszubauen – wer sich mit Strukturdaten beschäftigt, sollte sich das aktuelle Proposals anschauen – wie man dort sieht, geht alles in Richtung RDF. Wann welches Format vorzuziehen ist bzw. ob und wie ODF beispielsweise TEI verdrängt oder in welchem Kontext die existierenden Formate nebeneinander existieren werden, bleibt abzuwarten.

Relevant APIs for (digital) libraries

30. November 2007 um 14:50 5 Kommentare

My current impression of OCLC/WorldCat Service Grid is still far to abstract – instead of creating a framework, we (libraries and library associations) should agree upon some open protocols and (metadata) formats. To start with, here is a list of relevant, existing open standard APIs from my point of view:

Search: SRU/SRW (including CQL), OpenSearch, Z39.50

Harvest/Syndicate: OAI-PMH, RSS, Atom Syndication (also with ATOM Extensions)

Copy/Provide: unAPI, COinS, Microformats (not a real API but a way to provide data)

Upload/Edit: SRU Update, Atom Publishing Protocol

Identity Management: Shibboleth (and other SAML-based protocols), OpenID (see also OSIS)

For more complex applications, additional (REST)-APIs and common metadata standards need to be found (or defined) – but only if the application is just another kind of search, harvest/syndicate, copy/provide, upload/edit, or Identity Management.

P.S: I forgot NCIP, a „standard for the exchange of circulation data“. Frankly I don’t fully understand the meaning and importance of „circulation data“ and the standard looks more complex then needed. More on APIs for libraries can be found in WorldCat Developer Network, in the Jangle project and a DLF Working group on digital library APIs. For staying in the limited world if libraries, this may suffice, but on the web simplicity and availability of implementations matters – that’s why I am working on the SeeAlso linkserver protocol and now at a simple API to query availaibility information (more in August/September 2008).

P.P.S: A more detailed list of concrete library-related APIs was published by Roy Tennant based on a list by Owen Stephens.

P.P.S: And another list by Stephen Abram (SirsiDynix) from September 1st, 2009

Von ISBD zum Web 2.0 mit Mikroformaten

26. Juli 2007 um 14:18 15 Kommentare

Den folgenden Beitrag habe ich bereits in ähnlicher Form in INETBIB gepostet. Um ihn in die Blogosphäre einzubinden, poste ich ihn hier nochmal als Blogeintrag.

Um sich nicht im Sommerloch langweilen zu müssen, habe ich hier eine kleine Aufgabe für ISBD-Experten, Bibliothekare und andere Zukunftsinteressierte: Es geht um nicht weniger als die die Entwicklung eines bibliothekarischen Datenformates. Da der Beitrag etwas länger ist, hier eine


1. Im Web sind mehr und mehr Daten direkt und in standardisierten Formaten zur Weiterverarbeitung verfügbar
2. Durchsetzen wird sich am Ende das, was im Browser ohne Plugin unterstützt wird
3. So wie es aussieht, werden dies Mikroformate sein
4. Für Bibliographsche Daten fehlt bislang ein Mikroformat
5. Wenn sich Bibliothekare nicht mit ihrem Sachverstand an der Entwicklung eines solchen Formates beteiligen, tun es andere – und das nicht unbedingt nach bibliothekarischen Gesichtspunkten.

Worum geht es?
Beitrag Von ISBD zum Web 2.0 mit Mikroformaten weiterlesen…

Entwicklungen an der Nationalbibliothek von Australien

23. Juli 2007 um 10:10 Keine Kommentare
National Library of Australia IT Architecture Project Report

Die Nationalbibliothek von Australien (NLA) hat vor einiger Zeit einen sehr ansehnlichen Lucene-basierten Katalog-Prototypen veröffentlicht. Dass die NLA zukunftsweisende Entwicklungen betreibt, zeigt auch die geospatial search (deren Eingabemaske allerdings nicht sehr komfortabel ist) und den im März diesen Jahres veröffentlichten National Library of Australia IT Architecture Project Report auf den ich hiermit hinweisen möchte. Den folgenden Absatz aus dem Report könnte ich direkt unterschreiben:

The benefits of having a native level of support for standard protocols in the architecture cannot be overestimated. A standards-based service-oriented approach for core services such as Contribute, Alert, Harvest and Request will allow protocols such as SRU Update, RSS, OAI-PMH and OpenURL to be supported across all applications. It will also ensure that these protocols are part of the Library’s way of thinking when training new staff or prototyping new requirements; and that gaps in standards are identified and addressed through a testbed approach, as part of the development process.

Ãœbrigens setzt die NLA wie der GBV auch als Zentralsystem das CBS von OCLC PICA ein.