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