Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /kunden/116716_10965/jakoblog.de/wp/wp-content/plugins/mendeleyplugin/wp-mendeley.php on line 548
« Jakoblog — Das Weblog von Jakob Voß

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 | http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Kunze/

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
where: http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Kunze/

Ironically the given URL is obsolete, the host ‚jodi.ecs.soton.ac.uk‘ 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 http://www.rice.edu/perl4lib/archives/2002-09/msg00017.html – 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.

Überlegungen zur Modellierung von Bibliotheksdienstleistungen

13. März 2013 um 12:44 1 Kommentar

P.S: Mit Beschränkung auf Bibliotheksdienstleistungen, die sich auf Dokumente beziehen, habe ich inzwischen mit der Spezifikation einer Document Service Ontology begonnen.

Im Rahmen der Entwicklung der Patrons Account Information API (PAIA) und der Document Availability Information API (DAIA) bin ich wiederholt auf die Frage gestoßen, was für Arten von Dienstleistungen Bibliotheken eigentlich anbieten. Auf meine Frage bei Libraries.StackExchange antwortete Adrian Pohl, der sich in seiner Masterarbeit für lobid.org mit dem Thema beschäftigt hat.

Meine Fragestellung ist natürlich einseitig und zwar ausgerichtet auf die mögliche Verwendung in APIs, mit denen Nutzer und Programme verschiedene Bibliotheksdienstleistungen abrufen oder anfordern können sollen. Das bekannteste Beispiel ist die Dienstleistung der Ausleihe. PAIA und DAIA wurden primär dafür entworfen, damit Dienste wie die Ausleihe von Büchern aus Bibliotheken offen und maschinenlesbar möglich ist. Offen heisst, dass praktisch jeder oder zumindest alle Bibliotheksnutzer direkt per gut dokumentierter API auf die Dienste zugreifen können statt nur über bestimmte Benutzeroberflächen.

Dieser Blogartikel ist erst einmal ein lautes Denken, bei dem ich Adrians Klassifikation auf Eignung für meine Fragestellung untersuche. Wie jede Klassifikation sind sowohl die von Adrian bereitgestellte Liste als auch meine Kommentare also nicht neutral sondern nur eine mögliche Sichtweise.

1. Webbased services without direct personnel involvement:

  • OPAC and other research services
  • List of recent acquisitions
  • Online Tutorials
  • Place an order
  • Renewal of a loan
  • Online acquisition request service
  • Digitization Service
  • Consulting Service

Ein Katalog ist keine Dienstleistung die angefordert oder reserviert werden müsste, ebenso sieht es für andere Informationen auf der Webseite der Bibliothek aus. Die Punkte „place an order“ und „renewal of a loan“ gehören zur Dienstleistung Ausleihe (bzw. Ansicht bei Präsenzexemplaren). Zu klären ist noch, wie sich Anschaffungsvorschläge einordnen lassen. Die Digitalisierung von Bibliotheksbeständen (z.B. DigiWunschbuch ist vermutlich eine eigene Dienstleistung, die zu den bestehenden DAIA-Services hinzukommen könnte. Wieso „Consulting Service“ hier eingeordnet ist, verstehe ich nicht.

2. Webbased services with direct personnel involvement:

  • Chat reference/consulting

Ist ein Chat eine Dienstleistung? Wie sieht es mit anderen Kommunikationswegen (Telefon, Gespräch vor Ort…) aus)? Ich würde das alles unter Auskunft zusammenfassen.

3. In-house services with direct personnel involvement

  • In-house guided tours and courses
  • Digitization Service
  • Microfiche readers
  • Reference Desk
  • Loan Desk
  • Registration Desk
  • Consulting Service
  • 3D printer
  • Makerspace

Schulungen und Führungen sind sicher eine eigene Art von Dienstleistung, allerdings gibt es hier verschiedene Arten. Ausleihtheke und Anmeldung sind keine eigene Dienstleistung sondern Teil anderer Services. Bei den Arbeitsmitteln wie Mirofiche-Leser, 3D-Drucker etc. kommt es darauf an, ob diese direkt nutzbar sind oder reserviert werden müssen und ob sie nur vor Ort nutzbar oder auch ausleihbar sind.

4. In-house services without direct personnel involvement

  • Reading Room
  • Study room
  • Wifi
  • Computers with Internet Access
  • Photocopier
  • Scanner for use by visitors
  • 3D printer
  • Computer for self-loan
  • Cafeteria
  • Drinks machine

Arbeitsräume und Arbeitsplätze, Kopierer, Scanner, Kaffeeautomat etc. gehören zu den oben genannten Arbeitsmitteln. Ich denke dass sich DAIA einfach erweitern lässt, so dass Nutzer per API abrufen können, ob ein Arbeitsmittel frei ist und PAIA erweitern lässt, so dass Nutzer Arbeitsmittel per API reservieren können.

Access to library accounts for better user experience

8. Februar 2013 um 11:10 5 Kommentare

I just stumbled upon ReadersFirst, a coalition of (public) libraries that call for a better user experience for library patrons, especially to access e-books. The libraries regret that

the products currently offered by e-content distributors, the middlemen from whom libraries buy e-books, create a fragmented, disjointed and cumbersome user experience.

One of the explicit goals of ReadersFirst is to urge providers of e-content and integrated library systems for systems that allow users to

Place holds, check-out items, view availability, manage fines and receive communications within individual library catalogs or in the venue the library believes will serve them best, without having to visit separate websites.

In a summary of the first ReadersFirst meeting at January 28, the president of Queens Library (NY) is cited with the following request:

The reader should be able to look at their library account and see what they have borrowed regardless of the vendor that supplied the ebook.

This goal matches well with my activity at GBV: as part of a project to implement a mobile library app, I designed an API to access library accounts. The Patrons Account Information API (PAIA) is current being implemented and tested by two independent developers. It will also be used to provide a better user experience in VuFind discovery interfaces.

During the research for PAIA I was surprised by the lack of existing methods to access library patron accounts. Some library systems not even provide an internal API to connect to the loan system – not to speak of a public API that could directly be used by patrons and third parties. The only example I could find was York University Libraries with a simple, XML-based, read-only API. This lack of public APIs to library patron accounts is disappointing, given that its almost ten years after the buzz around Web 2.0, service oriented architecture, and mashups. All all major providers of web applications (Google, Twitter, Facebook, StackExchange, GitHub etc.) support access to user accounts via APIs.

The Patrons Account Information API will hopefully fill this gap with defined methods to place holds and to view checked out items and fines. PAPI is agnostic to specific library systems, aligned with similar APIs as listed above, and designed with RDF in mind (without any need to bother with RDF, apart from the requirement to use URIs as identifiers). Feedback and implementations are very welcome!


4. Dezember 2012 um 15:48 3 Kommentare

On my flight back from the Metadata and Semantics Research conference (MTRS) I thought how to proceed with an RDF encoding of patron information, which I had presented before at the Sematic Web in Libraries conference (SWIB). I have written about the Patrons Account Information API (PAIA) before in this blog and you watch my SWIB slides and a video recording.

As I said in the talk, PAIA is primarily designed as API but it includes a conceptual model, which can be mapped to RDF. The term „conceptual model“ needs some clarification: when dealing with some way to express information in data, one should have a conceptual model in her or his head. This model can be made explicit, but most times people prefer to directly use formal languages, such as OWL, or they even neglect the need of conceptual modeling languages at all. People that deal with conceptual modeling languages, on the other hand, often underestimate the importance of implementations – to them RDF is just a technology that is subject to change while models are independent from technology. Examples from the cultural domain include the CIDOC Conceptual Reference Model (CIDOC-CRM) and the Cultural Heritage Abstract Reference Model (CHARM), which I got to know in a talk at MTSR.

So thinking about conceptual models, RDF and patron information I came up with an expression of loan status in a library. In PAIA expressed as API we have defined six (actually five) status:

  • 0: no relation
  • 1. reserved (the document is not accesible for the patron yet, but it will be)
  • 2. ordered (the document is beeing made accesible for the patron)
  • 3. held (the document is on loan by the patron)
  • 4. provided (the document is ready to be used by the patron)
  • 5. rejected (the document is not accesible at all)

This list defines a data type, which one can happily work with without need to think about RDF, models, and all this stuff. But there is a model behind the list, which could also be expressed in different forms in RDF.

The first decision was to express each status as an event that connects patron, library, and document during a specific time. The second decision was to not put this into a PAIA ontology but into a little, specialized ontology that could also be used for other services. It turned out that lending a book in a library is not that different to having your hair cut at a barber or ordering a product from an online shop. So I created the Simple Service Status Ontology (SSSO), which eventually defines five OWL classes:

Service events can be connected through time, for instance a service can be executed directly after reservation or it could first be prepared. Putting this tiny model into the Semantic Web is not trivial: I found not less than eight (sic!) existing ontologies that define an „Event“, which a SSSO Service is subclass of. Maybe there are even more. As always feedback is very welcome to finalize SSSO.

Kurz-URL-Archive als Beacon-Linkdumps

13. November 2012 um 16:16 2 Kommentare

Kurz-URL-Dienste wie bit.ly, goo.gl und t.co gehören zu den eher merkwürdigen Auswüchsen des Web. Eigentlich haben sie vor allem Nachteile, trotzdem werden sie eifrig genutzt. Spätere Generationen werden sich vielleicht sicher fragen, warum die Menschen Anfang des 3. Jahrtausend ihre eigene Infrastruktur kaputt gemacht haben – unter anderem die einfache Adressierung von Webseiten mittels URLs. Weil Kurz-URL-Dienste so eine blöde Idee sind und damit nach ihrem Ableben spätere Generationen die ganzen Kurz-URLs zurückverfolgen können, hat eine Gruppe von Freiwilligen Archivaren 2011 das URLTeam gegründet (siehe Vortrag auf der Defcon 2011). Auf der Wiki-Seite des URLTeam sind zahlreiche, teilweise schon nicht mehr aktive Linkresolver aufgeführt. Der letzte Linkdump ist etwa ein Jahr alt und umfasst 48 Gigabyte (gepackt!). Ich habe das Dateiformat etwas aufgebohrt, so dass die archivierten Linkdumps dem Beacon Text Format entsprechen. Hier ein Beispiel:

Felix hatte zur GBV Verbundkonferenz 2009 in einem Tweet auf ein „Wordle“ des GBV Strategiepapiers verwiesen. Der Tweet enthielt die URL http://tr.im/ykr2. Den Kurz-URL-Dienst tr.im gibt es jedoch inzwischen nicht mehr. Bevor tr.im abgeschaltet wurde, hat das URLTeam allerdings geschafft, knapp zwei Millionen URL-Mappings zu sichern. Im frei verfügbaren Torrent befindet sich die Datei tr.im.txt.xz, in der auch der gesuchte Kurz-Link steckt:


Ich habe den Linkdump mit diesem Perl-Skript um folgende Metadaten im Beacon-Format erweitert:

#HOMEPAGE: http://urlte.am/
#RELATION: http://dbpedia.org/resource/HTTP_301
#DESCRIPTION: Shortened URLs from http://tr.im
#PREFIX: http://tr.im/
#SOURCESET: http://tr.im/
#TIMESTAMP: 2011-12-31

Der so in eine Beacon-Datei umgewandelte Linkdump steht (gepackt mit XZ) unter http://uri.gbv.de/downloads/links/tr.im.beacon.xz als Beispiel zur Verfügung.

Die Maker-Community Knowable.org

2. November 2012 um 09:08 1 Kommentar

Über die Berichterstattung zur Retune-Konferenz bin ich auf das Berliner Startup knowable.org gestoßen, dessen Gründer Simon Höher auf der Retune einen Vortrag gehalten hat. Retune ist eine Platform zum Austausch von Bau- und Bastelanleitungen, also so ähnlich wie Instructables, WikiHow, Make: Projects und ähnliche Seiten. Knowable.org vergleicht sich allerdings lieber mit GitHub und mit physischen Hackerspaces. Was bedeutet das und was ist das Besondere an der Plattform?

1. Die auf Knowable veröffentlichten Projekte sind unter CC-BY-SA lizensiert. So können Teilnehmer beispielsweise auf Inhalte von Wikipedia und Wikibooks zurückgreifen (und umgekehrt).

2. Die Anleitungen sind absichtlich einfach gehalten. Dass eine Beschränkung des Umfangs vorteilhaft sein kann hat schon Twitter gezeigt. Bei Knowable besteht jeder Schritt einer Anleitung aus bis zu 320 Zeichen und ggf. einem Bild fester Größe, wodurch das Layout der Seite einfach bleibt. Lediglich die Möglichkeit, zu jedem Schritt einzelne Hyperlinks hinzuzufügen, z.B. auf Quellcode und exakte Maßzeichnungen, würde ich noch aufnehmen.

3. Anleitungen können von allen Nutzern bearbeitet werden. Dabei hat jeder Nutzer seine eigene Version, die von anderen übernommen, verworfen oder weiterentwickelt werden kann. Mit diesem Prinzip einer verteilten Versionsverwaltung unterscheidet sich Knowable von ähnlichen Wiki-basierten Seiten wie bildr.org und Wikibooks.

Leider ist der letzte Punkt noch nicht umgesetzt. Ich wünsche mir allerdings auch lieber ein durchdachtes Datenmodell als eine schnelle Lösung, die später Probleme bereitet. Beispielsweise sollte klar sein wie Projekte mit ihrer Versionsgeschichte im- und exportiert werden können und wie Diffs zwischen zwei Versionen aussehen können. Dies ist nicht trivial, wie folgendes Beispiel zeigt (wer kein Interesse an Datenmodellierung hat, möge jetzt aufhören zu lesen):

Eine Möglichkeit zur Kodierung von Anleitungen wäre das Dateiformat oManual. Die Versionsgeschichte ließe sich in einem git-Repository speichern, dass der Ordnerstruktur von oManual entspricht. Das von oManual benutze XML-Format eigent sich jedoch nicht gut, um Änderungen darzustellen. Ein wesentlicher Grundsatz, der für Dateiformate in Versionsverwaltungen eingehalten werden sollte ist die Beschränkung auf das Wesentliche durch Normalisierung. Beispielsweise ist folgendes oManual-Fragment nicht normalisiert:

<step number="1">...</step>
<step number="2">...</step>

Der größte Teil des XML-End-Tags (/step>) ist prinzipiell redundant, so ist XML aufgebaut. Die Nummerierung der Schritte ergibt sich eigentlich automatisch aus der Reihenfolge, so dass das „number“-Attribut redundant ist. Außerdem müsste die Nummerierung aller folgenden Schritte geändert werden, wenn zwischen Schritt 1 und Schritt zwei ein weiterer Schritt eingefügt wird. Aus diesem Grund tendiere ich zu kompakten textbasierten Formaten (wie z.B. Markdown), aus denen sich bei Bedarf verschiedene Formate in JSON, XML, RDF etc. erzeugen lassen.

Ein kleiner Tipp an die Entwickler von Knowable.org: Achtet auf die Normalisierung von Leerzeichen und verschiedenen Unicode-Formen (NFC) und vereinheitlicht auch die Bilddateien (incl. Metadaten). Außerdem ließe sich die Bildeinbindung über die MediaWiki-API mit Wikimedia Commons anbinden. Dabei sollte zu jedem Bild grundsätzlich eine Quelle (URL) und ein Autor angegeben werden können, um der CC-BY-SA Lizenz genüge zu tun und um einen Verweis auf hochauflösende Versionen der Bilder zu haben. Für die Erschließung der Anleitungen mit Tags und Werkzeugen kommt auch Wikipedia/DBPedia in Frage, um gleich ein kontrolliertes Vokabular zu haben.

P.S.: Es gibt übrigens noch einige andere Projektseiten, bei denen einige Inhalte unter einer freien Lizenz veröffentlicht sind, z.B. bei Fritzing Projects und Thingiverse. Wenn Knowable.org tatsächlich sowas wie GitHub für physische Dinge wird, sollten sich Projekte von anderen Plattformen übernehmen und weiterentwickeln lassen.

Sind Kommentarfunktionen in populären Blogs notwendig?

20. August 2012 um 18:39 3 Kommentare

Der bekannte Netzaktivist Markus Beckedahl hat sich in seinem Blog netzpolitik.org über die Blog-Kommentare aufgeregt:

Ich habe in der Zeit rund 130.000 Kommentare gelesen und leider waren die meisten Zeitverschwendung. Muss man echt mal sagen. Weil sie mir keinen Mehrwert brachten […] Ich hab da nur keine Lust mehr drauf. Es kostet Zeit. Und es kostet Energie. Die ich lieber in sinnvolle Sachen stecken möchte.

Mein Vorschlag: Statt einer Kommentarfunktion könnten die Leser darauf hingewiesen werden, wie sie möglichst einfach auf einen Artikel eingehen können, indem sie in ihren eigenen Publikationskanälen dauauf verweisen. Zum Beispiel einfach mal einen eigenen Blog eröffnen. Sicher haben Kommentare Vorteile, aber sie fördern auch die Zentralisierung. Es ist natürlich bequemer seinen Senf schnell auf einer populären Seite wie Netzpolitik.org zu hinterlassen, statt sich einen eigenen Blogartikel zu überlegen. Mit einfach und bequem entsteht aber eben selten interessanter Mehrwehrt.

Ich habe den Eindruck, dass in den letzten Jahren die Blogosphäre als sozialer Raum für Diskussionen in den Hintergrund gerückt ist (wobei vermutlich die Gated Communities wie Facebook der Hauptgrund sind). Ein Abschalten der Kommentarfunktion für zentrale Hubs, unter Beibehaltung bzw. höherer Wertschätzung von Pingpack/Trackback wäre da mal eine Maßnahme.

Bibliographies of data repositories

30. Juli 2012 um 13:09 2 Kommentare

Databib, a proposed bibliography of research data repositories is calling for editors. These editors shall review submissions and edits to the bibliography. There is already an advisory board, giving Databib an academic touch.

The number of data repositories is growing fast, so it’s good to have an overview of existing repositories such as Databib. The number of similar collections of data repositories, however, is also growing. For instance, as noted by Daniel Kinzler in response to me, there is datahub.io hosted by the Open Knowledge Foundation and edited by volunteers. There is no advisory board, giving datahub.io an open community touch. And there are lists such as the list of repositories known to DataCite, the wiki-based list at Open Access Directory, the DFG-funded re3data.org project (which will likely be closed after funding stops, as known from most DFG funded projects), and many, many more.

One may ask why people cannot agree on either one list of repositories or at least one interchange format to create a virtual bibliography. Welcome to the multifaceted world of cataloging! I think there are reasons to have multiple collections, for instance there are different groups of users and different definitions of a [research] data repository (if there is any definition at all). At least one should be clear about the following:

Any list or collection of data repositories is an instance of a bibliography similar to a library catalog. Managing bibliographies and catalogs is more difficult than some imagine but it’s nothing new and it’s no rocket science. So people should not try to reinvent the wheel but build on established cataloging practices. Above all, one should (re)use identifiers to refer to repositories and one should not just ask for free-text input but use existing controlled vocabularies and authority files. This should also be familiar to people used to Linked Open Data.

By the way, any collection of data repositories, again is a data repository. Adding another level above may not really help. Maybe one should just treat published research data as one instance of a digital publication and catalog it together with other publications? What defines a „dataset“ in contrast to other digital publications? In the end it’s all a stream of bits isn’t it? 😉

Gibt es Diskurse in Metadaten?

9. Juli 2012 um 00:35 2 Kommentare

Im Libreas Weblog (wahrscheinlich unfreiwillig eines der Instanzen von #newLIS) haben Ben Kaden und Karsten Schuldt eine zwischen ihnen geführte Debatte zu folgender Forschungsfrage zusammengefasst:

Wie viel oder wie wenig Diskurs findet sich in Metadaten beziehungsweise Netzwerken von Metadaten Und was davon kann wie informationswissenschaftlich ausgewertet werden?

Grundsätzlich begrüße ich es sehr wenn die beiden ihre ausführlichen Informations-wissenchaftlichen Beiträge zusammenzufassen. Noch mehr begrüße ich Auseinandersetzungen mit Begriffen von Daten und Metadaten. Ich hoffe, deshalb, dass ihre Forschung nicht nur im Diskurs weiterlebt, sondern sich auch als Ergebnis in einer Beantwortung der Forschungsfrage niederschlägt. In ihrem Blogartikel äußern die beiden Autoren fünf Grundannahmen, von denen ich die ersten vier teile. Die fünfte Grundannahme, dass die „Bibliotheks- und Informationswissenschaft […] vorrangig eine befragende und beschreibende Wissenschaft“ sei, teile ich nicht. Ich befürchte stattdessen, dass die beiden beim Fragen und Beschreiben stehen (bzw. in Bewegung) bleiben. Nach meinem Eindruck ziehen sie es vor, darüber zu diskutieren, „was eine Bibliotheks- und Informationswissenschaft sein soll“ statt die eingangs gestellt Forschungsfrage zielgerichtet zu beantworten.

Mich interessieren jedenfalls Antworten auf die Frage nach Diskursen in Metadaten. Hier nur einige Anregungen:

(1) Zunächst ist es notwendig die Kernbegriffe Diskurs und Metadaten zu definieren.

(2) Interessant am Konzept der Metadaten sind zwei Aspekte: ihre beschreibende Funktion und ihre digitale Struktur.

(3) Hilfreich ist wie so oft der Blick über den Tellerand auf verwandte Phänomene. Aus der Forschungsfrage ergeben sich unter anderem folgende vorläufige Teilfragen:

1. Wie viel oder wie wenig Diskurs findet sich in (reinen) Beschreibungen?

2. Wie viel oder wie wenig Diskurs findet sich (reinen) Strukturen?

Für die Aufgabenstellung eine Master- oder die Ausgangslage einer Doktorarbeit sollte das genügen. Vielleicht lässt sich die Frage zumindest teilweise auch bereits in Form eines Fachartikels beantworten.

Links Sammeln und Verteilen mit BEACON

12. Juni 2012 um 12:45 9 Kommentare

Seit ich Ende letzten Jahres auf der Semantic Web in Bibliotheken (SWIB11) einen Vortrag zur Linkaggregation mit BEACON gehalten haben (hier der Mitschnitt) hat sich einiges getan.

Das BEACON-Format wurde ursprünglich Anfang 2010 von Mathias Schindler als ad-hoc Lösung vorgeschlagen, um über Identifier der Gemeinsame Normdatei (GND) zwischen Wikipedia-Artikeln und passenden Webseiten in Personenlexika und Bibliothekskatalogen zu verlinken. Beispielsweise findet sich Literatur zu Tina Modotti im Katalog der Bayerischen Staatsbibliothek (BSB) unter folgender URL:


Die URI des GND-Eintrags von Modotti ist:


Sofern die Links einheitlich aufgebaut sind, reicht für die Verknüpfung in einer BEACON-Datei die GND-Nummer 11858295X aus. Zusätzlich kann beispielsweise die Anzahl der Treffer im BSB-Katalog (momentan acht) angegeben werden. Hier ein Beispiel für eine BEACON-Datei:

#PREFIX: http://d-nb.info/gnd/
#TARGET: http://opacplus.bsb-muenchen.de/search?pnd={ID}
#DESCRIPTION: Links auf Literatur zu Personen im Katalog der BSB
#MESSAGE: {annotation} Einträge im BSB-Katalog


Diese einfache Form der Weitergabe von Links hat sich inzwischen durchgesetzt und es sind zahlreiche BEACON-Dateien verfügbar. Wie bei ad-hoc Standards üblich, haben sich allerdings unterschiedliche Interpretationen und Erweiterungen von BEACON entwickelt. Wir sind deshalb dabei, BEACON endgültig exakt zu spezifizieren, um es schließlich als Internet-Standard (RFC) zu verabschieden. Die Entwicklung kann auf github verfolgt werden, wobei der aktuelle Stand hier (HTML) bzw. hier (TXT) einsehbar ist.

Im wesentlichen muss zum Verständnis von BEACON zwischen zwei Ebenen unterschieden werden: Ein BEACON Link Dump ist eine Menge von einheitlich aufgebautem Links, die ggf. mit einigen Metadaten angereichert ist. In welchem Format die Links gespeichert werden, ist davon unabhängig. Jeder Link besteht aus genau vier Teilen:

  • Einer Quelle (link source), beispielsweise der URL
  • Einem Ziel (link target), beispielsweise der URL
  • Einem Beziehungstyp (link relation type), beispielsweise der URI
  • Einer Anmerkung (link annotation), beispielsweise der Zeichenkette
    8 Einträge im BSB-Katalog.

Der Beziehungstyp ist für alle Links in einem BEACON Link Dump gleich. Quelle, Ziel und Anmerkung können bei der Speicherung abgekürzt werden. Die Form zur Speicherung und Weitergabe (Serialisierung) ist die Zweite Ebene von BEACON. Neben dem ursprünglichen BEACON-Text-Format gibt es ein einfaches BEACON-XML-Format. Das oben angegebene Beispiel könnte in BEACON-XML folgendermaßen ausgedrückt werden:

<?xml version="1.0" encoding="UTF-8"?>
<beacon xmlns="http://purl.org/net/beacon"
  description="Links auf Literatur zu Personen im Katalog der BSB"
      message="{annotation} Einträge im BSB-Katalog">
   <link source="11858295X" annotation="8" />

Daneben können Links aus BEACON auch nach RDF übersetzt werden, was für die Anwendung als Linked Open Data von Bedeutung ist. Der Link in RDF/Turtle-Syntax (hier ohne Anmerkung) wäre bswp.:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<http://opacplus.bsb-muenchen.de/search?pnd=11858295X> .

Zum Ausdrücken der Anmerkung eines Links ist das Meta-Feld „qualifier“ vorgeschlagen, so dass sich BEACON Dumps auch vollständig in RDF übertragen lassen. In jedem Fall ist BEACON nicht auf GND-Nummern beschränkt und Quelle und Ziel müssen nicht zwangsläufig eine gemeinsame ID verwenden. So stellt beispielsweise lobid.org ein Mapping zwischen Lobid-URIs und Wikipedia-Artikeln bereit. Die dabei verwendete Form von BEACON weicht noch etwas vom endgültigen BEACON-Standard ab. Auch aus diesem Grund benötigen wir zum Aktuellen Entwurf des BEACON-Spezifkation noch Feedback und Korrekturleser.