Talk:Digitization Lifecycle Data Format
In der Sektion Mögliche Formate/ Logische Struktur ist im Kommentar zu lesen
METS verknüpft Ressourcen (Seiten-Scans) zu einer logischen Struktur, ist aber ungeeignet für eine Binnendifferenzierung innerhalb der Ressourcen (Seiten).
Würde ich so nicht stehen lassen wollen. In der DmSec von METS kann man jedes einzelne inhaltliche Element des Buches beschreiben. In einer logischen Structmap kann man dann auf diese DmSec-Elemente verweisen. Das widerspricht zwar nicht der oben zitierten Aussage. Diese lenkt aber davon ab, dass man auch komplett unabhängig von einer etwaig vorhandenen Menge an Buchseitenscans auf Inhalte des Buches referenzieren kann. Im Übrigen: Hat man eine Transkription des Buches im XML Format vorliegen, und etwaige "Binnendifferenzierungs"-geeignete IDs darin, kann man in der FileSec ganz normale XPath-Links dahin angeben - und die in der Structmap einbauen. Auch Digilib-URLs, die auf einen bestimmten Bildausschnitt verweisen, sind hier denkbar - für den Fall, dass es keine Transkripte gibt.
Wenn es keine grundlegenden Widersprüche gibt, bin ich gern bereit, den Kommentar entsprechend zu "verfeinern".
--Zieger 16:09, 11 March 2011 (CET)
METS Beschreibungs Widersprüche und andere seltsame Punkte[edit]
Auch auf die Gefahr hin, dass ich hier als "METS"-Fan in die Geschichte eingehe (bin ich gar nicht!) - ein paar Dinge, die mir auffielen...
Im Abschnitt "Das METS-Format" liest man...
METS (...) entstand 2001
Und unten dann...
Das Format ist somit eng zugeschnitten auf die Digitalisations-Beduerfnisse der 90er Jahre
Das passt irgendwie nicht zusammen.
Außerdem.
Die Tabellenstruktur ahmte ganz bewusst die Struktur damaliger relationaler Datenbanken nach. Leider - denn man musste jetzt die relationale Struktur bis zum Ende durchziehen. Hatte man also nun Tabellen angelegt, welche die einzelnen Scans auflistete, sowie die einzelnen Seiten, plus noch eine weitere Tabelle, welche die einzelnen Kapitel auflistete (und jedem Element war eine ID zugewiesen worden) - so musste man jetzt (Relational!) noch eine weitere Tabelle hinzufuegen: eine Tabelle, welche jede einzelne Seite anhand ihrer ID einem Kapitel zuwies.
METS ist doch reines XML und gerade in den Struct Maps kann man irre Verschachtelungen machen, um irgendwelche logischen Strukturen des behandelten Werkes zu kennzeichnen. Wir zum Beispiel verzichten im KHI auf die structLink Sektion, weil diese Aufgabe (Verknüpfung Seite und Artikel) auch direkt in der Structmap möglich ist. Die Einarbeitung in relationale Datenbanken, wie sie ja auch heute noch gern verwendet werden, wird natürlich mit der structLink Sektion vereinfacht.
Dass Volltext nicht zu METS gehört, ist ja keine Schande - METS war absichtlich nie darauf ausgelegt. Dass es damit nicht die "eierlegende Wollmilchsau" ist, mit der alle eSciDoc Anforderungen erschlagen werden, ist ja noch mal ein anderes Thema - aber welcher Standard ist das schon. Immerhin - dank XPath kommt man trotzdem recht weit damit.
Und nun noch:
Zugleich hat METS aber auch den Status "end-of-life"
Huch? Wer sagt denn das? Zumindest die METS Mailing list seems to be pretty much alive und es gibt des öfteren neue Standardrevisionen.
--Zieger 16:34, 11 March 2011 (CET)