Bei meiner Arbeit ägert es mich immer wieder, wenn das Thema Digitalisierung und METS zur Sprache kommt. Insbesondere ärgert mich das Verständnis, das meine Gesprächspartner von METS haben.

In der Bibliothekswelt hat es sich wohl rumgesprochen, dass es ein Tool gibt, mit dem es möglich ist mit METS beschriebene digitale Objekte anzuzeigen: den DFG-Viewer.

Nun möchte ich den DFG-Viewer nicht schlecht reden. Er ist sicher ein nützliches Tool um

1. eine gemeinsame Präsentationsoberfläche zu bieten und
2. ein Validationstool für das Bugfixing an der Hand zu haben.

Leider muss ich jedoch feststellen, dass diese Funktionalitäten zu einer Fehleinschätzung der Möglichkeiten und des Sinns von METS führen.

Die Fehleinschätzung besteht darin, dass manche den Schluss ziehen, METS bräuchte man, um digitale Objekte zu präsentieren und somit weiterhin denken, man müsste die Digitalisate in solcher Weise in METS beschreiben, so dass der DFG-Viewer sie anzeigen kann.

Dieser Schluss reduziert den Sinn von METS auf die Präsenation. Dabei ist METS mit nichten für die Präsentation gedacht.

Der Name Metadata Encoding and TRANSMISSION Schema sagt es ja schon fast. Und so wird METS auch folgendermaßen beschrieben:

„[…] that provides the means to convey the metadata necessary for both the management of digital objects within a repository and the exchange of such objects between repositories […]”
[siehe METS-Primer]

Wir brauchen also METS, um unsere Daten in die Repositories einzuspielen und um sie zwischen Repositories auszutauschen. Haben wir die Daten erst einmal in einem Repository, dann können wir auch Disseminiation Information Packages (DIP) definieren, die wunderbar im DFG-Viewer angezeigt werden können.

Aber mal ehrlich, der DFG-Viewer bietet nicht gerade eine projektspezifische Flexibilität. Die Frage ist also: Möchte ich unbedingt meine Daten im DFG-Viewer anzeigen? Es gibt wohl bessere Möglichkeiten (die zugegeben auch mehr Arbeit machen).

Somit bleibt zu konstantieren, dass der DFG-Viewer zu einem "zu kurz Denken" in Bezug auf den Sinn von METS verleitet. Jedenfalls ist das im Großen und Ganzen mein Eindruck.

Cheers!

Was habe ich davon, wenn ich meine Daten mit RDFa auszeichne?

Man fragt sich ja das ein oder andere mal wozu dieser ganze Aufwand mit dem Semantic Web eigentlich gut ist: RDF, RDFS, OWL, SKOS, SPARQL und jetzt auch noch RDFa?
In meiner Reihe "Bibliographische Daten und RDFa" habe ich schon versucht zu erläutern, wie man bestimmte Daten mit RDFa auszeichnen kann. Nur ein konkreten Anwendungsfall habe ich bisher ausgespart.

Use Cases for RDFa

Chris Clarke von Talis und Fiona Greig von der University of Plymouth haben jetzt in ihrer Fallstudie "A Linked Open Data Resource List Management Tool for Undergraduate Students" ein konkretes Einsatzszenario für RDFa beschrieben.

Die beiden beschreiben den Aufbau eines Tools zur Erstellung und Organisation von elektronischen Literaturlisten (Resource List Management (RLM)) für den E-Learning-Bereich. Das Tool arbeitet mit der Talis-Platform (ein ausgefeilter Content- und RDF-Triple-Speicher) zusammen.

Der Clue an der ganzen Sache, ohne weiter auf das Tool eingehen zu wollen, ist, dass RDFa im Zusammenhang mit Javascript/Ajax eingesetzt wird, um Daten direkt am Bildschirm zu manipulieren (es kann zum Beispiel mit Drag and Drop gearbeitet werden, wobei die Datenstrukturen erhalten bleiben (siehe diese Beispiele: http://labs.adida.net/rdfa-clipboard/ http://www.w3.org/2006/07/SWD/RDFa/impl/js/rdfa-clipboard/ )), ohne immer wieder den Server anzusprechen.

Nach getaner Arbeit wird dann die mit RDFa strukturierten Daten in RDF/XML serialisiert und dann an den Server geschickt, wo ein Abgleich mit den in RDF/XML vorhandenen Daten gemacht wird, die eventuell aktualisiert werden. Näheres kann man auch noch hier und hier nachlesen.

Meiner Meinung nach kann dies auch mit anderen Datenbasen als ein Triple-Store im Hintergrund funktionieren. Der entscheidende Punkt ist ja, dass man direkt am Bildschirm durch RDFa mit strukturierten Daten arbeitet. Wenn die Daten erst mal strukturiert sind, dann können sie leicht in andere Strukturen überführt werden.

Use Case: unAPI over RDFa

Ich würde gerne noch einen weiteren Anwendungsfall für RDFa hinzufügen. In meiner Diplomarbeit habe ich ja schon über Use Cases für Mikroformate für bibliographische Daten nachgedacht. Bei unAPI bin ich damals zu dem Schluss gekommen, dass Websitebetreiber kein unAPI einsetzen können, wenn sie nicht eine strukturierte Datenbasis im Hintergrund haben. Strukturierte Datenbasis ist auch hier wieder das ausschlaggebende Ausdruck, denn wenn wir davon ausgehen, dass RDFa eine strukturierte Datenbasis ist, dann lässt sich der Schluss daraus ziehen, dass die selbe Webseite sowohl das unAPI-Mikroformat enthält, als auch die Datenbasis für den unAPI-Server darstellt.

Was soll das jetzt bedeuten?

Man stelle sich vor, wir basteln uns eine Webseite wie diese hier. Wir möchten die bibliographischen Daten (es könnten auch anderen Daten sein, aber als Bibliothekar fühle ich mich da sicherer) unseren Nutzern zu Nachnutzung durch ihre Software (hier vielleicht eine Literaturverwaltungssoftware wie Zotero) anbieten. unAPI wäre hier eine elegante Möglichkeit dies zu tun, denn unAPI könnte die Daten in verschiedenen Formaten anbieten (je nachdem, was die Nutzersoftware so verarbeiten kann). Leider haben wir keine Datenbank, in der die Daten strukturiert abgelegt sind und somit fällt die unAPI-Idee ins Wasser. ES SEI DENN... Wir zeichnen unsere Daten mit RDFa aus...

Wie es funktioniert

Jede mit RDFa ausgezeichnete Ressource im Dokument bekommt eine ID (die sie sowieso haben sollte, weil wir sonst mit Blank Nodes arbeiten müssten).
Diese ID bildet zugleich den Identifikator für das unAPI-Mikroformat.

<!-- ID der Ressource -->
<p about="info:doi:10.1119/1.2343039" typeof="bibo:Article" id="lit1">
<!-- unAPI Mikroformat --> 
<abbr class="unapi-id" title="lit1"></abbr>

1. Die anfragenede Software entdeckt das unAPI-Mikroformat auf der Webseite.
2. Die anfragende Software nimmt sich den Identifikator und fragt die unAPI-Schnittstelle mit der nach Auswahl eines geeigneten Formats ab.
3. Der unAPI-Server nimmt sich jetzt den Identifikator (die ID der Ressource) und übergibt die Hash-URI einem RDFa-Parser.
4. Der RDFa-Parser parst das Dokument und gibt das Ergebnis (meist RDF) dem unAPI-Server zurück.
5. Der unAPI-Server wandelt das Parsingergebnis in das gewünschte Format um und
6. gibt die Daten im gewünschten Format der anfragenden Software aus.

Wer Zotero in seinem Firefox installiert hat kann das hier mal ausprobieren. Es dauert allerdings eine kurze Zeit bis das Zotero-Artikelicon in der Adressleiste erscheint, da ich einen externen RDFa-Parser abfrage. Auch die RDF-MODS-Transformation ist erst mal nur ein Test.

Vision

Ich gehe davon aus, dass mit RDFa ausgezeichnete Daten in jedes andere Datenformat transformiert werden können. Die Menge der mit RDFa ausgezeichneten Daten im Web stellen somit eine einzige stukturierte Datenbasis dar. Jede Ressource dieser Datenbasis hat durch seinen URI einen eindeutigen Bezeichner, welcher einem beliebigen unAPI-Server übergeben werden könnte. Die unAPI-Server müssten nur so reagieren, dass sie bei Übergabe eines externen URI einen Parser bemühen, der die entsprechende Ressource parst.

Ich könnte somit meinen eigenen unAPI-Server bauen, der Daten nach meinem Belieben extrahiert. Das Identifizieren meines eigenen unAPI-Servers könnte ich durch Manipulation der aktuellen Webseite mit Hilfe eines Javascripts bewirken, welches das Link-Tag

<link rel="unapi-server" type="application/xml" title="unAPI" href="PFAD_zu_meinem_unAPI-Server" />

in die Seite einspielt, bzw. das originale Link-Tag überschreibt.

RDFa bietet noch weitere Einsatzmöglichkeiten, aber so langsam entdecke ich die wirklichen Stärken dieser Technologie.

Ich würde gerne von euch wissen, was ihr von meinem Anwendungsfall haltet. Irgendwie beschleicht mich das Gefühl, dass ich den Wald vor lauter Bäumen nicht sehe und alles noch viel einfacher geht, denn im Prinzip könnte jede anfragende Software ja auch ihren eigenen Parser haben. Das hätte wohl Vor- und Nachteile...

Die Library of Congress (LOC) hat sich entschlossen, das kürzlich geschlossene lcsh.info-Projekt von Ed Summers zu ersetzen und kündigt damit einen neuen Service an: id.loc.gov

ID.LOC.GOV soll ähnlich wie lcsh.info die Library of Congress Subject Headings (LCSH) nach dem Linked-Data-Prinzip anbieten.

Zusätzlich zu den Subject Headings sollen laut LOC in sechs bis acht Wochen auch ein Thesaurus für "Graphic Materials", "MARC Geographic Area Codes", "MARC Language Codes" und "MARC Relator Codes" per URI referenziebar gemacht werden.

Mensch und Maschine können sich dann unter einem URI in der Form id.loc.gov/authorities/{identifier} nach dem Content Negotiation Prinzip zwischen verschiedenen Serialisierungen (RDF mit SKOS, JSON, XHTML, CSV oder MADS) entscheiden.

Näheres erfährt man unter http://id.loc.gov/.

Projekte wie der Schwedische Verbundkatalog LIBRIS, der seine Titel ebenfalls nach dem Linked-Data-Prinzip bereitstellt und seine Sacherschließung auf die ehemals unter lcsh.info referenzierbaren LCSH gemappt hatte, sind jetzt aufgefordert ihre URIs zu erneuern.

Ich persönlich finde es schon in Ordnung, wenn die LOC die Verantwortung für ihre Subject Headings auf diesem Gebiet übernehmen möchte. So ist eine langfristige Bereitstellung des Angebots auch gesichert.

Auf der anderen Seite muss man Ed Summers den größeten Lob ausprechen, denn ohne sein Handeln und dem entsprechenden öffentlichen Protest beim Schließen von lcsh.info, wäre die LOC wohl nicht so schnell darauf gekommen, in dieser Richtung etwas zu unternehmen.