Liebe Liste,
Bei dem von Herrn Heiligenhaus am Dienstag angesprochenen Punkt geht es
um die Frage, ob es notwendig ist, alle Verknuepfungen zwischen
logischer und physischer Struktur vollstaendig in der METS Datei
aufzunehmen. Zentraler Punkt hierbei sind Verknuepfungen von
untergeordneten logischen Einheiten zu physischen Struktureinheiten
(d.h. Unterkapitel zu Seiten). Derzeit haben sowohl Unterkapitel als
auch Kapitel Verknuepfungen zu den jeweiligen Seiten. Diese
Verknuepfungen sind tatsaechlich redundant, da auf Grund der
hierarchischen Stuktur Kapitel und Unterkapitel auf diesselben Seiten
verweisen. Diese Redundanz fuehrt in der METS Datei zu einer relativ
grossen structLink-Sektion und zu grossen Dateien.
Zunaechst moechte ich mal annehmen,dass das Datenmodell fuer alle
seitenbasierten Medienarten gelten soll - unabhaengig davon, ob die
Beschreibung einer digitalen/digitalisierten Resource alle Teile des
Modells in voller Granularitaet ausschoepft oder nicht. Es ist weiterhin
wichtig zu verstehen, dass das Modell mehr Funktionalitaet erlaubt als
derzeit im DFG Viewer umgesetzt ist - gerade hinsichtlich der physischen
Struktur (=Seiten/Spalten/Textbereichte).
Generell stellt sich also die Frage, warum Verknuepfungen auf
ueberliegender Ebene gespeichert werden, wenn sie auf unterliegender
Ebene vorhanden sind:
1) Ein Kapitel kann laenger sein als die Summe aller Unterkapitel - oder
allgemein: Die summe aller logischer Unterstrukturen ist kleiner als die
ueberliegende Struktur. Dies kann damit zusammenhaengen, dass sich nicht
alle Unterstrukturen (automatisiert) erfassen lassen oder aber das die
ueberliegende Struktur tatsaechlich noch ueber zusaetzlichen
Inhalte/Seiten verfuegt.
2) D.h. Lesereihenfolge von ueber- und untergeordneten logischen
Einheiten kann unterschiedlich sein. Diese Reihenfolge wird jedoch durch
die Verknuepfung in der log. und phys. Einheit in der structLink Section
angegeben. Die smLink Elemente muessen in entsprechender
Blaetter/Lesereihenfolge angeordnet sein. Das ist zugegebenermassen
nicht sehr explizit ausgedrueckt; eine solche Moeglichkeit gibt es
allerdings erst ab METS 1.8.
Als Beispiel mag hier eine Tageszeitung dienen. Die einzelnen Sektionen
(Sport, Wirtschaft, Feuilleton) werden als uebergeordnete Einheit
betrachten und durch ein entsprechendes logisches <div> in der METS
Datei aufgenommen. Die Seiten werden mit dieser ueberliegenden Einheit
verknuepft - vermutlich in der Reihenfolge der Seitenpaginieren. Denn so
wuerde man durch diese Sektion durchblaettern/lesen.
Unterliegende Artikel werden als Kind <div> Element implementiert. Die
Lesereihenfolge der Artikel allerdings koennen unterschiedlich der
Seitenpaginierung sein. Zum einen kann Artikel auf Seite 1 beginnen und
anschliessend auf Seite 3 fortgefuehrt werden. Zum anderen koennen
Artikel aber auch auf der letzten Seite beginnen und innen fortgefuehrt
werden. Dies ist zumindest hier in UK regelmaessig beim Sportteil der
Fall. Dieser stellt die Rueckseitige Titelseite und wird von "hinten
nach vorne" gelesen.
3)
Bislang sind wir davon ausgegangen dass logische Verknuepfungen aus
unterscheidlicher Hierarchieebene auf physische Einheiten derselben
Hierarchiestufe (=Seiten) zeigen. Sobald die physische Seite jedoch auch
weiter untergliedert wird in Spalten und Textbloecke, wird die
Verknuepfung unterliegender logischen Einheiten nicht mehr auf
Seitenebene geschehen, sondern auf Textblockebene. Dies ist zumindest
bei Tageszeitungen der Fall, kann jedoch auch bei Monographien und
Zeitschriften passieren: Auch fuer diese Strukturtypen laesst sich eine
Seite in verschiedene Textbloecke aufteilen. Angenommen eine Seite
beherbergt das Ende eines und den Start eines zweiten Unterkapitels, so
laesst sich die Seite in zwei Textbloecke zerteilen. Aus den
Unterkapiteln wird neben den anderen Seiten nur der jeweilige Textblock
(Start bzw. Ende) verwiesen.
In dem Fall, wird also auf sehr granulare Einheiten von den
Unterkapiteln verwiesen. Fuer die uebergeordnete Einheit sind die
Textbloecke jedoch unwichtig. Da die komplette Seite zu dem Kapitel
gehoert, wird auch nur auf sie verwiesen und nicht auf die Textbloecke.
Weitere Untereinheiten koennten naemlich ebenso zu dem Kapitel gehoeren,
nicht jedoch zu einem der Unterkapitel (siehe (1)).
Das Datenmodell ist nun einmal so komplex, wie es derzeit im METS Profil
dokumentiert ist. Die serialisierung in METS liesse sich vereinfachen,
wenn bestimmte Annahmen getroffen werden. Diese Annahmen muss der
DFG-Viewer beruecksichtigen; d.h. diese muessen implementiert werden.
Das ist fuer viele Faelle sicherlich machbar, wenn auch kompliziert,
wenn tiefere Strukturen als Seiten oder zusaetzliche Funktionalitaeten
beruecksichtig werden. Derzeit muss die Software lediglich log/phys
Relationen beruecksichtigen; Hierarchien in der log. Struktur koennen
unberuecksichtigt bleiben.
Entsprechend ausfuehrliche und grosse METS Dateien automatisiert zu
generieren scheint mir da das kleinere Uebel zu sein. An welcher Stelle
wirkt sich denn die Groesse der METS Datei nachteilig aus? Beim parsen?
uebertragen?
Ich sehe zumindest kein Problem, dem nicht mit etwas mehr Resourcen
beizukommen waere.
Ciao
Markus Enders
Liebe Liste,
nach unserem Treffen letzte Woche habe ich versucht ein Beispiel für die Zeitungsnavigation zu erstellen. Folgendes ist dabei herausgekommen:
(Ich bitte zu berücksichtigen, dass ich im Moment alles manuell erstelle und daher die meisten Links ins Leere führen. Ich hoffe jedoch, dass der Ansatz klar wird.)
Die Navigation findet in zwei Schichten statt
1. Übersicht des Titels mit Erscheinungsjahren und eventuellen Beilagen und "Ausgaben"
* Erscheinungsjahre werden auf die zweite Schicht (Jahresschicht) gelinkt.
* Beilagen in dieser Schicht werden auf die oberste Schicht der Beilage gelinkt.
* "Ausgaben" sind so etwas wie Regional-Ausgaben und werden wie Beilagen behandelt (nicht im Beispiel vorhanden)
* Ansicht im Viewer: http://dfg-viewer.de/demo/viewer/?set[mets]=http%3A%2F%2Fzefys.staatsbiblio…<http://dfg-viewer.de/demo/viewer/?set%5bmets%5d=http%3A%2F%2Fzefys.staatsbi…>
* METS-Datei: http://zefys.staatsbibliothek-berlin.de/fileadmin/mets/kreuz.xml
2. Übersicht des Erscheinungsjahres eventuellen Beilagen und "Ausgaben"
* Vorhandene Monate werden nur als Strukturelement genutzt und verweisen auf die aktuelle Schicht
* Vorhandene Tage und Editionen (Morgen-, Abend-, Extra-Ausgabe) verweisen auf die Standard-Ansicht der Ausgabe
* Beilagen in dieser Schicht werden auf die Jahresschicht der Beilage gelinkt (analog zu dieser Schicht).
* Ausgaben in dieser Schicht werden auf die Jahresschicht der Ausgabe gelinkt (analog zu dieser Schicht).
* Ansicht im Viewer: http://dfg-viewer.de/demo/viewer/?set[mets]=http%3A%2F%2Fzefys.staatsbiblio…<http://dfg-viewer.de/demo/viewer/?set%5bmets%5d=http%3A%2F%2Fzefys.staatsbi…>
* METS-Datei: http://zefys.staatsbibliothek-berlin.de/fileadmin/mets/kreuz_1857.xml
In der Jahresschicht würden somit maximal 378 (1 Titel + 12 Monate + 365 Tage) Strukturelemente + Ausgaben, Beilagen und Editionen vorkommen. Ich denke, dass das noch recht übersichtlich sein dürfte.
Über Kritik und Anmerkungen würde ich mich sehr freuen.
Mit freundlichen Grüßen,
Carsten Schulze
*********************************************************
Carsten Schulze
Staatsbibliothek zu Berlin
Zeitungsinformationssystem
Postanschrift: 10772 Berlin
Hausanschrift: Potsdamer Str. 33, 10785 Berlin
Telefon: +49 (0) 30 - 266 435781
E-Mail: carsten.schulze(a)sbb.spk-berlin.de<mailto:carsten.schulze@sbb.spk-berlin.de>
*********************************************************
Liebe Kollegen,
wir hatten ja in Berlin beschlossen, die Normdaten in MODS über xlink anzubinden. Herr Heiligenhaus wollte dazu Beispiele bringen(?) Haben Sie da eventuell schon eines parat? Die Frage (z.B. bei den Personen) ist ja z.B., ob man nur das xlink-Attribut href verwendet oder noch weitere, um die Normdatei zu bezeichnen ... Hat vielleicht schon jemand hierzu konkretere Vorstellungen?
Danke und einen schönen Feiertag wünscht
Maria Federbusch
Wissenschaftliche Referentin
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz
Abteilung Historische Drucke
Unter den Linden 8
D-10117 Berlin
Tel.: ++49-(0)30-266-43 66 01
E-Mail: maria.federbusch(a)sbb.spk-berlin.de<mailto:maria.federbusch@sbb.spk-berlin.de>
http://staatsbibliothek-berlin.de/historische-drucke.html
Sehr geehrte Damen und Herren,
zur Zeit bin ich mit einem Projekt der Universitätsbibliothek Würzburg betraut, in dem es darum geht,
Material für die Ansicht im DFG-Viewer aufzubereiten (xml Dateien erstellen/konvertieren).
Dabei bin ich auf zwei Probleme gestoßen:
1. Könnten Sie mir bitte kurz erläutern, wie man die zum Download bereitgestellte TYPO3 Extension benutzt.
Leider konnte ich dazu keine Dokumentation finden.
Ist es des Weiteren möglich, diese Extension auf dem Server zu betreiben, so dass keine Verlinkung der xml Datei
auf die Seite des DFG-Viewers nötig ist?
2. Beim Testen mittels Verlinkung auf die DFG-Viewer Seite tritt der Fehler auf, dass die Datei nicht gefunden wird.
Ich vermute, dass das Problem darin liegt, dass die Datei nicht mittels http sondern https übertragen wird.
Könnten Sie mir bitte diesbezüglich Klarheit verschaffen.
Für die Beantwortung meiner Fragen danke ich im Voraus
Andreas Wendl
