21 Aug
von Oliver Flimm - Kategorie: Allgemein, Ankündigungen, Einblicke und Konzepte
Im Bestreben die Digitalisate von Wikisource – jenseits des schon erfolgten Nachweises im KUG – für unsere Nutzer noch einfacher zugänglich zu machen, haben wir die Idee von Jakob Voss, diese über den DFG-Viewer zu erschließen, weiter verfolgt und nun für den KUG umgesetzt.
Der DFG-Viewer benötigt die Strukturinformationen des Digitalisats im METS-Format, wie es auch vom Zentralen Verzeichnis Digitalisierter Drucke zvdd verwendet wird. Da Jakob für Wikisource bereits einen Proof-Of-Concept-Code veröffentlichte, habe ich diesen mit seiner Erlaubnis erst einmal als Grundlage für unsere Umsetzung genommen und ihn dann sukzessive überarbeitet.
Ausgehend von der Indexseite der jeweiligen Digitalisate, die alle mit Index: beginnen, können dort – ähnlich den Personen- und Textdaten für die bibliographischen Daten in der deutschen Wikisource – z.T. strukturiert vorliegende rudimentäre Metadaten des Digitalisats aus dem XML-Dump von Wikisource entnommen werden. Diese sehen normalerweise so aus:
|BILD=[[Datei:Kafka Der Prozess 1925.jpg|200px]] |AUTOR=[[Franz Kafka]] |TITEL=[[Der Process]] |VERLAG=Verlag die Schmiede |JAHR=1925 |ORT=[[Berlin]] |QUELLE=[http://anno.onb.ac.at/cgi-content/anno-buch?apm=0&aid=318 ÖNB-ANNO] |SEITEN=[[Seite:De Kafka Prozeß I.jpg|I]]
Für den DFG-Viewer sind hier insbesondere die Informationen AUTOR, TITEL, JAHR, ORT und vor allem SEITEN interessant. Die Namen aller im zugehörigen Werk digitalisierten Seiten beginnen mit Seite: gefolgt von der effektiven Seitenzählung, die mit Pipe abgetrennt ist. Leider verfügen nicht alle Einträge über solche Metadaten, die über die Seiten-Verweise hinausgehen. In diesem Fall muss man sie den Textdaten der zugehörigen Wikisource-Seite entnehmen und einfach alle Verweise einsammeln die mit Seite: beginnen. Manchmal wird auch das Container-Format DJVU für Digitalisate verwendet. Dieses können wir bisher leider noch nicht verarbeiten.
Die Kunst ist nun zu den Seiten-Verweisen ala
[[Seite:De Kafka Prozeß I.jpg|I]]
die effektiven Dateinamen und -urls zu bestimmen, die für die METS-Datei benötigt werden. Hier hätte ich aus Effizienzgründen, und um Wikisource nicht allzusehr zu belasten, gerne einen geeigeneten Wikimedia-Dump herangezogen, konnte aber keinen finden. Daher muss man zwingend das Wikimedia-API verwenden, bei dem man zudem an die Beschränkungen der maximalen Request-Menge denken muss.
Eine solche Abfrage hat z.B. folgende Form:
http://de.wikisource.org/w/api.php
?format=json&action=query∝=imageinfo&iiprop=url&iiurlwidth=1000&titles=Image
e Kafka Prozeß I.jpg|Image:De Kafka Prozeß II.jpg|Image:De Kafka Prozeß 001.jpg|Image:De Kafka Prozeß 002.jpg
Zurückgeliefert bekommt man dann alle benötigten Datei-Informationen im JSON-Format und kann diese sehr einfach weiter verarbeiten.
Wichtig ist hier die Forderung des DFG-Viewers nach einer Standardauflösung von 1000 bis 1500 Pixel für die Breite der Bilder, die über den CGI-Parameter iiurlwidth konfiguriert wird. Mit den Metadaten des Digitalisats, den Labeln für die effektive Seitenzählung, den URLs für die Bilder in der geforderten Standard- sowie maximal möglichen Auflösung, hat man nun alle Informationen an der Hand, um die METS-Beschreibung zu erstellen.
Geplant war zuerst die Katalogeinträge im KUG um eine Kategorie zu erweitern und in diese dann die in XML kodierten METS-Informationen abzulegen. Just in diesem Moment haben wir aber bemerkt, daß der DFG-Viewer die METS-Daten von Jakob gar nicht mehr anzeigen kann. Die Seite bleibt einfach weiß – eine Fehlermeldung gibt es nicht und auch der Validator für den DFG-Viewer bescheinigte späteren METS-Kodierungen von uns Korrektheit – nur der DFG-Viewer zeigte nichts an. An dieser Stelle möchte ich darauf hinweisen, daß der DFG-Viewer anscheinend mindestens für einen Tag die METS-Daten eines Digitalisats zwischenspeichert – für jeden fehlerhaften Versuch muss man sich also ein neues Digitalisat suchen…
An diesem Punkt habe ich die Idee mit der fertig abgespeicherten METS-Beschreibung aus Flexibilitätsgründen sehr schnell verworfen, um auch später noch schnell Anpassungen im geforderten METS-Derivat vornehmen zu können. Dazu erfolgte mit unserem Konvertierungsprogramm eine Serialisierung der wesentlichen Basisinformationen (Metadaten, URLs, Label, usw.) in ein Set an neu geschaffenen Kategorien. Aus diesen Kateogorien generieren wir dann erst später über unser Templating-System, dem Template Toolkit, im Template connector_unapi_mets die für den DFG-Viewer geeignete METS-Beschreibung.
Konkret haben wir zur Lieferung der METS-Beschreibung die schon vorhandene unAPI-Schnittstelle um das METS-Format erweitert. Da wir aber noch nicht genau wissen, ob der Hauptnutzer dieser Schnittstelle – Zotero – eventuell Probleme mit diesem zusätzlichen Format hat, wird es erst einmal bei unAPI-Anfragen nicht explizit “beworben” und muss explizit mit format=mets spezifiziert werden (Beispiel).
Die Verlinkung zum DFG-Viewer erfolgt im KUG in den Vollanzeigen der jeweiligen Katalogaufnahme, wie z.B. beim gewählten Beispiel von Kafka’s Prozeß.
Oft ist hier das gesamte Buch verlinkt – dieses ist üblicherweise via INDEXSEITE in den Textdaten spezifiziert, falls Artikelnamen differieren – und man muß erst den durch die Katalogaufnahme beschriebenen Aufsatz darin finden. Aber dafür gibt es ja normalerweise ein Inhaltsverzeichnis – falls vorhanden..
Schön wäre es aber dennoch, sofort passgenau zur entsprechenden Seite zu springen – bisher konnten wir die dazu benötigten Informationen aus den Wikisource-Artikel aber noch nicht extrahieren bzw. verarbeiten.
Es gibt hier also auch noch einiges zu tun.
4 Kommentare
Martin de la Iglesia
21|Aug|2009 1Sehr geehrter Herr Flimm,
tut mir leid, aber ich verstehe den Sinn des DFG-Viewers nicht. Haben Sie ihn verlinkt, weil Sie glauben, damit könne man die Texte besser lesen als direkt in Wikisource? Das Gegenteil ist der Fall, zumindest hier an meinem Rechner, denn selbst die kleinste Ansicht im DFG-Viewer ist so groß, daß man viel scrollen muß. In Wikisource dagegen ist die kleinere der beiden Ansichten genau richtig, und die größere ist ausreichend, um sich Details anzuschauen. Zumindest empfinde ich das beim “Prozess”-Beispiel so.
Mit freundlichen Grüßen
Oliver Flimm
21|Aug|2009 2Vielen Dank für das Feedback. Mit etwas Trickserei habe ich gerade einen zusätzlichen Abschnitt für eine niederaufgelöste Darstellung erzeugt Neben der Vollauflösung und der Standardauflösung mit 1000 Pixel Breite wird nun auch eine 400 Pixel-Version angezeigt. Aufgrund des Cachings im DFG-Viewer wird das für heute bereits aufgerufene Werke allerdings erst morgen sichtbar.
Zu Ihrer Kritik am DFG-Viewer: Ich denke schon, daß der Zugriff auf die Digitalisate für die Nutzer bequemer wird, sei es nun gegenüber der Indexseite in Wikisource oder der deutlich besseren Originalseite in Commons.
Für uns ist der wesentliche Faktor aber, daß wir unseren Nutzern zukünftig sinnvollerweise einen einheitlichen Zugang zu Digitalisaten anbieten wollen – jenseits der sich z.T. massiv unterscheidenden Original-Frontends. Diese bleiben selbstverständlich weiterhin verlinkt und alternativ direkt zugänglich. Und hier bietet sich der DFG-Viewer aufgrund seiner Architektur mit offenen Schnittstellen aus meiner Sicht derzeit sehr gut an.
Martin de la Iglesia
21|Aug|2009 3Das mit der niedrigeren Auflösungsstufe wollte ich gerade ausprobieren. Beim Beispiel http://kug.ub.uni-koeln.de/portal/connector/permalink/wikisource_de/2611/1/kug/index.html kann ich auch durchaus drei verschiedene Zoomstufen-Buttons anklicken – allerdings ohne jeglichen Effekt. Die Ansicht bleibt immer gleich (bis auf die Zoom-Buttons, die je nach Stufe hell oder dunkel sind).
Das Argument mit dem einheitlichen Zugang kann ich nachvollziehen; daran hatte ich nicht gedacht.
Oliver Flimm
21|Aug|2009 4Ich vermute, daß das Problem bei dem von Ihnen genannten PermaLink auf Kafka’s Mord in der maximaler Auflösung der zugehörigen Bilder auf Wikisource/Commons liegt. Diese ist kleiner als die vom DFG-Viewer geforderte Standardauflösung von 1000 bis 1500 Pixel. Damit haben dann auch alle drei Varianten im Viewer diese gleiche Auflösung. Ich werde daher das Ausgabetemplate in den nächsten Tagen um die entsprechende “Intelligenz” erweitern, so dass die Illusion verschiedener Auflösungen in solchen Fällen erst gar nicht entsteht.
Kommentar schreiben
Blog durchsuchen
Kategorien
Archiv
Links
Kalendar