Jakoblog — Das Weblog von Jakob Voß

Bibliographies of data repositories

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?

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

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:

http://opacplus.bsb-muenchen.de/search?pnd=11858295X

Die URI des GND-Eintrags von Modotti ist:

http://d-nb.info/gnd/11858295X

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:

#FORMAT: BEACON
#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

11858295X|8

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
  http://d-nb.info/gnd/11858295X
• Einem Ziel (link target), beispielsweise der URL
  http://opacplus.bsb-muenchen.de/search?pnd=11858295X
• Einem Beziehungstyp (link relation type), beispielsweise der URI
  http://www.w3.org/2000/01/rdf-schema#seeAlso
• 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"
       prefix="http://d-nb.info/gnd/"
       target="http://opacplus.bsb-muenchen.de/search?pnd="
  description="Links auf Literatur zu Personen im Katalog der BSB"
      message="{annotation} Einträge im BSB-Katalog">
   <link source="11858295X" annotation="8" />
</beacon>

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://d-nb.info/gnd/11858295X>
rdfs:seeAlso
<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.

Why do Wikimedia projects fail to deliver open content?

From time to time I’d like to link to a famous quotation. I then remember Wikiquote, a wiki-based “quote compendium” similar to Wikipedia, also run by the Wikimedia Foundation. Or I’d like to link to a famous text, and I visit Wikisource, an “online library of free content publications”, also Wikimedia project since years. But even when the quotation or text is included in Wikiquote/Wikisource, I most times leave depressed. This also applies to other Wikimedia projects, such as Wiktionary, Wikibooks, Wikimedia Commons, and even Wikipedia to some degree.

failed open content or just perpetual beta?

The reason has been mentioned by Gerard Meijssen at the Wikimedia Berlin Hackathon (#wmdevdays) a few days ago. He wrote that “Both #Wikibooks and #Wikisource do a terrible job promoting their finished product.” I’d like to stress that Wikimedia projects do not (only) fail promoting, but they fail delivering their products. That’s sad, because Wikimedia projects are about collecting and creating open content, which anyone should be able to reuse. But conrtent is not truly open when it is only available for reuse by experts. For instance, why can’t one just…

• …link to a single quotation in Wikiquote? (WTF?!)
• …highlight a section in Wikipedia and get a stable link to this selection?
• …download content from Wikibooks, Wikisource, or Wikipedia in different formats such as EPUB, LaTeX, MarkDown, OpenDocument etc.?
• …find out the precise license of a media file from Commons?

Most of these tasks are possible if you are an expert in Wikimedia projects. You have to learn a crude WikiSyntax, know about MediaWiki API and dozens of license tags, know about extensions, do error-prone conversion on your own, deal with full dumps etc. Maybe I am too harsh because I love Wikimedia. But if you are honest about its projects, you should know: they are not designed for easy reuse of content, but more about work-in-progress collaborative editing (and even editing capability is poor compared with Google Docs and Etherpad).

Gerard suggested to create another Wikimedia project for publishing but I doubt this is the right direction. There is already a feature called Quality Revisions for marking a “final” state of a page in MediaWiki. The core problem of reusing content from Wikimedia projects is more how to actually get content in a usable form (deep link, eBook formats, LaTeX… etc.).

First draft of Patrons Account Information API (PAIA)

Integrated Library Systems often lack open APIs or existing services are difficult to reuse because of access restrictions, complexity, and poor documentations. This also applies to patron information, such as loans, reservations, and fees. After reviewing standards such as NCIP, SLNP, and the DLF-ILS recommendations, the Patrons Account Information API (PAIA) was specifed at the Common Library Network (GBV).

PAIA consists of a small set of precisely defined access methods to look up patron information including fees, to renew and request documents, and to cancel requests. With PAIA it should be possible to make use of all patron methods that can be access in OPAC interfaces, also in third party applications, such as mobile Apps and discovery interfaces. The specification is divided into core methods (PAIA core) and methods for authentification (PAIA auth). This design will facilitate migration from insecure username/password authentification to more flexible systems based on OAuth 2.0. OAuth is also used by major service providers such as Google, Twitter, and Facebook.

The current draft of PAIA is available at http://gbv.github.com/paia/ and comments are very welcome. The specification is hosted in a git repository, accompanied by a wiki. Both can be accessed publicly to correct and improve the specification until its final release.

PAIA complements the Document Availability Information API (DAIA) which was created to access current availability information about documents in libraries and related institutions. Both PAIA and DAIA are being designed with a mapping to RDF, to also publish library information as linked data.

Goethe erklärt das Semantic Web

Seit Google vor einigen Tagen den “Knowledge Graph” vorgestellt hat, rumort es in der Semantic Web Community. Klaut Google doch einfach Ideen und Techniken die seit Jahren unter der Bezeichnung “Linked Data” und “Semantic Web” entwickelt wurden, und verkauft das ganze unter anderem Namen neu! Ich finde sowohl die Aufregung als auch die gedankenlose Verwendung von Worten wie “Knowledge” und “Semantic” auf beiden Seiten albern.

Hirngespinste von denkenden Maschinen, die “Fakten” präsentieren, als seien es objektive Urteile ohne soziale Herkunft und Kontext, sind nun eben Mainstream geworden. Dabei sind und bleiben es auch mit künstlicher Intelligenz immer Menschen, die darüber bestimmen, was Computer verknüpfen und präsentieren. Wie Frank Rieger in der FAZ gerade schrieb:

Es sind „unsere Maschinen“, nicht „die Maschinen“. Sie haben [...] kein Bewusstsein, keinen Willen, keine Absichten. Sie werden konstruiert, gebaut und eingesetzt von Menschen, die damit Absichten und Ziele verfolgen – dem Zeitgeist folgend, meist die Maximierung von Profit und Machtpositionen.

In abgeschwächter Form tritt der Irrglaube von wissenden Computern in der Fokussierung auf “Information” auf, während in den meisten Fällen stattdessen Daten verarbeitet werden. Statt eines “Knowledge Graph” hätte ich deshalb lieber einen “Document Graph”, in dem sich Herkunft und Veränderungen von Aussagen zurückverfolgen lassen. Ted Nelson, der Erfinder des Hypertext hat dafür die Bezeichnung “Docuverse” geschaffen. Wie er in seiner Korrektur von Tim Berners-Lee schreibt: “not ‘all the world’s information’, but all the world’s documents.” Diese Transparenz liegt jedoch nicht im Interesse von Google; der Semantic-Web-Community ist sie die Behandlung von Aussagen über Aussagen schlicht zu aufwendig.

Laut lachen musste ich deshalb, als Google ein weiteres Blogposting zur Publikation von gewichteten Wortlisten mit einem Zitat aus Goethes Faust beginnen lässt:

Yet in each word some concept there must be…

Im “Docuverse” wäre dieses Zitat durch Transklusion so eingebettet, dass sich sich der Weg zum Original zurückverfolgen ließe. Hier der Kontext des Zitat von Wikisource:

Mephistopheles: [...] Im Ganzen – haltet euch an Worte! Dann geht ihr durch die sichre Pforte Zum Tempel der Gewißheit ein.

Schüler: Doch ein Begriff muß bey dem Worte seyn.

Mephistopheles: Schon gut! Nur muß man sich nicht allzu ängstlich quälen; Denn eben wo Begriffe fehlen, Da stellt ein Wort zur rechten Zeit sich ein. Mit Worten läßt sich trefflich streiten, Mit Worten ein System bereiten, An Worte läßt sich trefflich glauben, Von einem Wort läßt sich kein Jota rauben.

Die Antwort von Google (und nicht nur Google) auf den zitierten Einwand des Schülers gleicht nämlich bei näherer Betrachtung der Antwort des Teufels, wobei das “System” das uns hier “bereitet” wird ein algorithmisches ist, das nicht auf Begriffen sondern auf Wortlisten und anderen statistischen Verfahren beruht.

In der Zeitschrift für kritische Theorie führt Marcus Hawel zu eben diesem Zitat Goethes (bzw. Googles) aus, dass Begriffe unkritisch bleiben, solange sie nur positivistisch, ohne Berücksichtigung des “Seinsollen des Dings”, das bestehende “verdoppeln” (vgl. Adorno). Wenn Google, dem Semantic Web oder irgend einem anderen Computersystem jedoch normative Macht zugebilligt wird, hört der Spaß auf (und das nicht nur aufgrund der Paradoxien deontischer Logik). Mir scheint, es mangelt in der semantischen Knowledge-Welt an Sprachkritik, Semiotik und kritischer Theorie.

Was ist XML?

Mein letzter längerer Artikel für das Lexikon der Bibliotheks- und Informationswissenschaft (LBI), dessen letzter Band dieses Jahr erscheinen wird, beschreibt die Extensible Markup Language (XML). Wie bei den anderen Artikeln (vgl. Ontologie und Ontologiesprache sowie Metadaten) besteht die Kunst darin, sich auf das wesentliche zu Beschränken und sinnvoll mit den bereits festgelegten Artikeln zu verlinken.

Wer Cloud sagt muss auch Bullshit sagen

In den letzten beiden Tagen fand in Göttingen ein GBV-Workshop zur Entwicklung der Lokalsysteme statt. Lokale Bibliothekssyteme (LBS, wobei im GBV dabei das LBS der Firma OCLC/PICA gemeint ist) oder Library Management Systems (LMS) sind für die zentralen Geschäftsgänge einer Bibliothek verantwortlich, d.h. für Ausleihe, Erwerbung, Nutzerverwaltung etc.

Von üblichen LMS wird die Recherche-Funktion zunehmend in so genannten Discovery Interfaces abgekoppelt. Idealerweise sollten auch andere Funktionen entkoppelt werden (z.B. die Benutzerverwaltung als LMS-unabhängiges Identity-Management). In der Realität sind die einzelnen Module von unterschiedlichen Herstellern aber nicht frei kombinierbar, womit deren ganzes Gerede von Schnittstellen und Services Augenwischerei ist.

Eine weitere Form der Verdummung von Bibliotheken ist mir auf der Veranstaltung mit mit dem Begriff Cloud aufgefallen. Cloud-Computing ist ein Buzzword, das anscheinend vor allem zur Verschleierung verwendet wird. Wenn wie im Workshop davon die Rede ist, dass “Daten in der Cloud verschwinden”, “eine eigene Cloud geschaffen werden soll” oder gar Forderungen nach einer “Deutschland-Cloud” laut werden, sollte eher von Nebel als von Wolke gesprochen werden. Denn ohne Angabe, was genaue für Dienste in eine Cloud ausgelagert werden sollen, ist der Begriff praktisch bedeutungslos und kann z.B. durch “Computer”, “Netzwerke”, “Server” oder “Hosting” ersetzt werden.

Dabei gibt es im Cloud-Computing eine etablierte Unterscheidung von drei groben Arten von Diensten: Bei Infrastruktur as a Service (IaaS) geht es um virtuelle Server. IaaS ist nicht mehr und nicht weniger als eine Alternative dazu, sich physische Rechner in die eigenen Räume zu stellen. Ein Beispiel für einen IaaS-Anbieter ist Amazon mit seinem Dienst Elastic Cloud Computing (EC2). Bei Platform as a Service (PaaS) wird eine Umgebung für eigene Programme bereitgestellt. PaaS ist nicht mehr und nicht weniger als eine Alternative zum Selber-Installieren und -Konfigurieren von Webservern, Programmiersprachen und allgemeinen Standard-Programmkomponenten. Die verschiedenen PaaS-Anbieter wie zum Beispiel Heroku, dotCloud und OpenShift unterscheiden sich vor allem darin, welche Programmiersprachen unterstützt werden.

Während verschiedene Anbieter von IaaS bzw. von PaaS jeweils in etwa vergleichbar sind, sieht es bei der dritten Art von Cloud anderes aus: Software as a Service (SaaS) bedeutet dass eine bestimmte Software nicht selber installiert und aktualisiert, sondern von einem Anbieter als Black-Box bereitgestellt wird. Ein populäres Beispiel für SaaS ist Google Docs. Während man bei IaaS und PaaS die Anbieter ähnliches bieten und man zwischen ihnen wechseln kann, hängt bei SaaS der Funktionsumfang völlig vom Anbieter ab und ein Wechsel ist praktisch nicht möglich. Im Gegenzug muss man sich als Nutzer keine Gedanken darum machen, wo die Software installiert ist und wie Updates durchgeführt werden. Beide Fragen wurden aber komischerweise auf dem GBV-Workshop diskutiert.

Vereinfacht gesagt lassen sich die drei Cloud-Arten so darstellen: Mit IaaS gibt es keine einzelnen Rechner mehr, mit PaaS gibt es keine einzelnen Installationsumgebungen mehr und mit SaaS gibt es keine einzelnen Updates mehr. Vor allem der letzte Punkt ist nach meinem Eindruck vielen nicht klar: bei SaaS gibt es keine Versionen oder Updates sondern nur neue Funktionen die im laufenden Betrieb aktiviert werden. Dieser Luxus wird erkauft mit (neben Geld) einer Einschränkung des Funktionsumfangs und mit einer Abhängkeit vom Anbieter.

So wie ich die Teilnehmer des GBV-Workshops verstanden habe, wollen Bibliotheken gerne die Vorteile aller Arten von Clouds zusammen: keine lästige Installation, Wartung und Auszeiten von Hard- und Software, kein Verzicht auf bisherige Funktionen (“alte Zöpfe”) und alles am Besten so, dass Anbieter gewechselt werden können. Wer Bibliotheken so etwas verkaufen möchte, hat aber entweder keine Ahnung oder er begeht mutwillige Täuschung. Software ist immer entweder Arbeit in Form von selber zu erbringender Programmierung und Konfiguration, oder sie ist in ihrem Funktionsumfang auf einen kleinsten gemeinsamen Nenner beschränkt. Ich ziehe dabei die erste Variante vor, zumal Programmierung ja auch über Einstellungen, Skripte und Plugins möglich ist. Es bleibt aber eigene Programmierung – wer als Anwender davor zurückschreckt, muss sich mit Einschränkungen Abhängigkeiten und Auszeiten abfinden, sei es im Bibliothekswesen oder anderswo.

HTTP Content negotiation and format selection

In University of Southampton’s WebTeam Blog Christopher Gutteridge just complained that HTTP content negotiation could do better. And he is right. In a nutshell, content negotiation allows to retrieve different forms, versions or representations of a digital document at the same URI.

Content negotiation is an important part of the Web architecture, but sucks for several reasons. The main problem is: there is no consensus about what defines a format/version/representation etc. and how to refer to selected forms of a digital document. At least for selection by different versions in time, there is a good specification with Memento and Accept-Datetime header. Content negotiation by language (Accept-Language) is similar unless you want to query by other aspects of language (slang, readability…), because language tags are clearly defined and precise. But the concept of “content types” (Accept header, also known as MIME types) is rather fuzzy.

Earlier I wrote about the difficulties to define “publication types” – it’s the same problem: there is no disjoint set of content types, document types, publication types, or formats! Each document and each representation can belong to multiple types and types may overlap. The easiest case, described by Christopher, is a subset relation between two types: for instance every XML document is also a Unicode string (be warned: there is no hierarchy of types, but maybe a Directed Acyclic Graph!). Not even this simple relationship between content types can be handled by HTTP content negotiation.

Anyway, the real reason for writing this post is yet another CPAN module I wrote: Plack::App::unAPI implements unAPI. unAPI is a kind of “poor man’s content negotiation”. Instead of sending additional HTTP headers, you directly select a format with format=... parameters. In contrast to HTTP Content negotiation, an unAPI server also returns a list of all formats it supports. This is a strong argument for unAPI in my opinion. I also added a method to combine unAPI with HTTP content negotiation.

BibSonomy usability disaster

In addition to other citation management systems, I use BibSonomy. It’s one of the less known social cataloging tools. Not as commercial and shiny as Mendeley, but useful, especially if you happen to collect many papers in computer sciences. The BibSonomy team is open and friendly and the project is connected to the local University in Kassel (by the way, they are hiring students!). I still like BibSonomy – that’s why I wrote this rant.

Since last week BibSonomy has a new layout. Sure people always complain when you change their used interface, but this change is a usability desaster – at least if you work on a netbook with small screen, like me. To illustrate the problems here is a screenshot with my quick notes in red:

The screen is crowded with irritating and ugly user interface elements. The actual usage area is put into a little frame. Yes, a frame, in 2012! You cannot just scroll down to get rid of the header, because the frame is fixed. There are more flaws, for instance the duplication of account elements, scattered at not less than four places (logged in as…, logout, user:…, myBibsobomy) and the ugly custom icons (there are several great icon sets that could be used instead, for instance Silk, GCons, Glyphicons, Picol…). It does not get better of you try to edit content. I am sorry, but this is a usability disaster.

P.S: The BibSonomy team has responded and they fixed part of the problem with a nasty hack, based on actual screen size.