Difference between revisions of "Digitization Lifecycle Data Format"
| Line 329: | Line 329: | ||
[[Category:Digitization Lifecycle|Data Format]] | [[Category:Digitization Lifecycle|Data Format]] | ||
[[Category:TEI]] | |||
Latest revision as of 08:23, 22 July 2013
Arbeitsgruppe Format[edit]
Koordinator[edit]
Klaus Werner, Markus Haarländer (mögliche Übergabe ab 12.4.2011)
Teilnehmer[edit]
- Wilhelm Frank
- Lisa Pegelow
- Wolfram Zieger
- Anna Klug
- Ingo Caesar
Ziele und Arbeitspakete[edit]
Arbeitspakete:
1. Generierung und Definition des Datenformats
2. Einholen von Know How externer ExpertInnen zum Thema TEI
Telcos[edit]
Datenformat[edit]
(erstes brainstorming MPI Bibliotheca Hertziana)
allgemeine Anforderungen[edit]
- sollte ein XML-Format sein
- sollte durch ein Schema definiert und dokumentiert sein (DTD, Relax-NG, XML-Schema)
- sollte den Zusammenhang zwischen physischer Struktur (Buchseiten bzw. deren Scans) und semantischer Textstruktur (Vorwort, Teile, Kapitel etc.) so beschreiben, wie er IST, und zwar so zuverlässig wie möglich
- das gesamte Strukturdokument soll Metadaten enthalten können, die durch Schemata definiert werden, insbesondere:
- bibliographische/bibliothekarische Metadaten (OPAC)
- Metadaten zum digitalen Dokument (Urheber, Institution, Datum etc)
- kodikologische Metadaten (Exemplar-Beschreibung alla fiorentina)
- weitere allgemeine Metadaten zum Buch (SWD etc)
- Metadaten zu den Scan-Dateien (Server-URL, Urheber, Datum, technische Angaben)
- falls Volltext vorhanden oder beabsichtigt, sollte er nachträglich ohne Änderungen an den Strukturdaten eingefügt werden können
- sämtliche Strukturelemente sollten durch unique Identifier ansprechbar sein, nicht nur durch XPath-Ausdrücke, dadurch sollen punktgenaue Verweise auf Seiten/Textstellen/ möglich sein
- jedes Strukturelement sollte durch frei definierbare Metadaten-Sets ergänzt werden können; mglw. kann ein gemeinsames Basis-Schema erstellt werden
- es soll die Möglichkeit bestehen, weitere logische Strukturen mit der Strukturdatei zu verknüpfen bzw. im Viewer virtuell "über" die Seiten zu blenden, z. B.:
- logisch/inhaltlich korrigierte Textabfolge
- Abbildungs-/Inhalts-/sonstige Verzeichnisse
- Konkordanz-Dateien zu anderen Ausgaben (zum Editionen-Vergleich etc.)
- Links zu Datenbanken
Transformationen[edit]
Die Strukturdatei soll umgewandelt werden können in
- TEI
- METS/MODS (DFG-Viewer)
- OAI (Metadata-Harvesting)
- andere bibliothekarische Exportformate?
Das METS-Format (kew)[edit]
METS (http://www.loc.gov/standards/mets/) entstand 2001 im Nachklang an die ersten Digitalisierungskampagnen im Rahmen des Projektes "Making Of America II" (MOA2), das zum Ziel hatte, moeglichst viele bedeutende Werke digital zugaenglich zu machen.
Das Problem - das dann mit METS geloest werden sollte - war, dass sich in kurzer Zeit Berge von TIFFs/JPEGs anhaeuften, plus Buchbeschreibungen in TXT/DOC Form, es jedoch noch keine allgemein verbindliche Norm gab, die Bilder (bzw. die Pfade hierzu) und die bibliographischen Metadaten zusammen mit ev. noch einer Kurzhierachie in einem gemeinsamen Austauschformat abzulegen (http://onlinelibrary.wiley.com/doi/10.1002/bult.268/full).
METS erledigte das auf folgende Weise:
1. Die Abspeicherung der Metadaten zur Erstellung des METS Dokuments sowie zum eigentlichen Werk:
- metsHdr (METS Header): Metadaten zum METS Dokument selbst (Produktion, Datum etc.)
- dmdSec (descriptive metadata Section): Metadaten zum Werk selbst (wobei man diese - und dies ist aeusserst praktisch - auch in MODS beschreiben und in METS lediglich einbinden (wrappen) lassen kann) sowie ev. eine Auflistung aller Kapitel und Kapiteltitel. Hier mischen sich reine Metadaten ("front") mit tatsaechlichem Inhalt ("Trattato di tutte l'opere pie dell'alma città di Roma").
- amdSec (administrative metadata Section): Angaben zu Copyright, Aufbewahrung etc.
2. Die damals vordringlichste Aufgabe, die einzelnen Seiten an die Buchstruktur und die einzelnen Scans zu verknuepfen, erledigte METS damit, dass es fuer jede der Aufgaben eine spezifische Tabelle vorsah:
- fileSec (file Section): tabellarische Auflistung aller Scans, ev. mehrmals bei verschiedenen Aufloseungen, und deren ID.
- structMap / logical (logical structural Map): tabellarisch/hierarchische Abbildung des Inhaltes (in dmdSec war es ja nur eine reine Auflistung!) mit Kapiteln, Kapiteltiteln und deren ID.
- structMap / physical (physical structural Map): tabellarische Auflistung der einzelnen Seiten und deren ID.
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.
- structLink (structural Links): tabellarische Verbindung (mit Hilfe der IDs) zwischen physischer und logischer Struktur (structMap physical/logical), also Seite <-> Kapitel.
Diese komplexe, aber unendlich redundante Struktur (man haette ja auch gleich jeder Seite einem Abschnitt zuordnen sowie einen Scan zuweisen koennen, nicht wahr?) ist aus heutiger Sicht nur dann verstaendlich, wenn man sich die gewollte Imitation relationaler Datenbanken vor Augen haelt, die zu damaliger Zeit eben nur jeweils ganz simple A-B Tabellen vorhalten konnten: fuer Daten, die eine Zuweisung von Seiten an Scans und zugleich an Abschnitte noetig machten, war nur der Umweg ueber mehrere Tabellen moeglich, die dann wiederum ueber weitere (Beziehungs-)tabellen verknuepft werden mussten.
Das Format ist somit eng zugeschnitten auf die Digitalisations-Beduerfnisse der 90er Jahre, und zwar sowohl mit seiner Replikation der Datenstruktur ehemaliger relationaler Datenbanken als auch auf seine Beschraenkung der Verknuepfung der einzelnen Scans auf eine (mehr oder weniger) hierarchische Struktur Titel/Kapitel/Unterkapitel. Eine Einbindung von bzw. eine Ausweitung auf Volltext war damals weder vorgesehen (das war nicht Teil des MOA2 Projektes!) noch technisch vom Format her moeglich.
Damit bietet sich das Format zum Einen als ideales Exportformat(sic) zur - auch internationalen - Beschreibung von Digitalisaten an, mit jeweils einer einfachen Kapitel-Strukturierung. Zugleich hat METS aber auch den Status "end-of-life", da es den komplexeren Anforderungen (full text, deep-referencing, cross-linking, ...) nicht Genuege leisten kann.
Das METS Format mit eingebetteten MODS Teilen im praktischen Einsatz (Darstellung aus Sicht des KHI)[edit]
Bei seinen Projekten "PRO FIRENZE FUTURISTA" und "translatio nummorum" verwendet das KHI das METS XML Format mit einbetteten MODS META-Datenblocks. Im Folgenden soll sich vor allem auf das Projekt "PRO FIRENZE FUTURISTA", kurz "Futurismus" bezogen werden, dass mit einer stark heterogenen Ausgangsbasis befasst, handelt es sich doch weitgehend um eine Bestandsaufnahme des Schaffens italienischer Futuristen. Das METS Format eignet sich hierfür besonders gut, da es sich nicht auf ein bestimmte physische Medien wie z.B. Bücher festlegt. Bilder, Postkarten, Briefe, Notizblattsammlungen, Manuskripte, Zeitungen, Bücher, Filmaufnahmen und Audioschnipsel können damit uneingeschränkt und problemlos in ihren Metadaten erfasst werden - gleichzeitig kann eine Verknüpfung mit Digitalen Repräsentationen (Image-Dateien, OCR-Dateien, XML-Transkripte, Video- und Audiofiles) der originalen physischen Medien bzw. Ausschnitten daraus erfolgen.
Das METS Format ist flexibel genug, all das abzubilden. Dabei ist es nicht einmal nötig, die komplette, historisch gewachsene XML Struktur zu verwenden.
Von den möglichen sechs METS-Blöcken, verwenden das Futurismus-Projekt und das Translatio-Nummorum-Projekt des KHI nur vier:
- metsHdr (METS Header): Umfasst lediglich die Aufnahme des Bearbeiters der digitalen Daten und das Datum der letzten Änderung
- dmdSec (descriptive metadata Section): Aufnahme der Metadaten aller inhaltlichen Bestandteile (Bei einer Zeitung Artikel, Abbildungen, Werbeanzeigen und die Zeitung als Ganzes) ohne jegliche hierarchische Strukturierung. Die META-Daten werden dabei im MODS Standard abgelegt.
- fileSec (file Section): Eine Art File-Repository Verwaltung. Es werden URLs gesammelt, die auf Seitenscans, ausgeschnittene Artikel-Images, Abbildungs-Scans, Video und Audiodateien verweisen. Die eigentlichen Digitalen Dateien liegen i.d.R. im lokalen Filesystem, aber auch Links ins WWW werden z.T. genutzt
- structMap / physical (physical structural Map):. Es sind mehrere StructMaps möglich; im KHI wird, wo es sich anbietet, eine physische Structmap (i.d.R. die Einzelseiten eines Buches oder einer Zeitung) und eine logische Structmap (TOC) angelegt. In der Structmap werden die Einzelbestandteile aus der dmdSec in einen hierarchischen Kontext gebracht und mit passenden digitalen Repräsentationen aus der FileSec verknüpft - unter Verwendung von den in dmdSec und fileSec vergebenen IDs.
Zwei Elemente aus METS läßt das KHI außen vor, da dort abgelegte Informationen bereits in den anderen Blöcken vorhanden sind, was zu einer unnötigen Aufblähung des Formates und entsprechenden Redundanzen führen würde.
- amdSec (administrative metadata Section): Eine Auflistung von digitalen Files (praktisch dieselben wie in FileSec) und ihren digitalen Metadaten (Auflösung, Farbraum oder auch Samplefrequenz) sowie eine Auflistung der "originalen analogen" Sourcen und ihrer physichen Eigenschaften (Höhe, Breite etc.). Digitale Metadaten sind bereits im EXIF Block der Images enthalten; bei Audio- und Videofiles gibt es ähnliche Mechanismen. Physische Merkmale des "analogen" Quellenbestandes können bereits in der dmdSec vermerkt werden, wenn es das verwendete Subformat (hier MODS) zuläßt.
- structLink. Die Verknüpfung von DmDSec-Bestandteilen mit Filesec-Bestandteilen kann bereits in der Structmap erfolgen. Weiterhin mögliche Verknüpfungen mit amdSec Objekten fallen mit der amdSec weg.
Die Vorteile von METS liegen klar in der Flexibilität des Formates. So können beliebige Bestandteile eines Werkes, unabhängig von deren Strukturellen Einordnung aufgenommen werden (dmdSec). Dabei kann (und muss mangels weiterer Spezifizierung) ein beliebiges Metadatenformat wie MODS verwendet werden. Dass dabei auch Volltextformate wie TEI oder DOCbook verwendet werden können, versteht sich von selbst. In Sachen Volltexten wäre es "im METS-Sinne" wenn jedes Kapitel/Subkapitel als einzelnes METS-dmdSec Element in einem in sich abgeschlossenen TEI- oder DocBook Block vorliegt. Das wiederum ist aber nicht im TEI Sinne. Denkbar wäre es hier wiederum, das gesamte Hauptobjekt komplett in TEI anzulegen (inklusive TOC Struktur, Metadaten, Imagelinks etc.), und dann rudimentär die TOC-Struktur noch einmal zusätzlich als einzelne DmdSec Objekte anzulegen (durchaus auch automatisiert per XSLT Transformation machbar). Der daraus resultierende (leider redundante) Aufbau würde es ermöglichen, mit einem METS Viewer die grobe Struktur zu erfassen, aber zudem mit einem TEI Viewer den Volltext in allen Details zu bewundern. Dies würde den sukzessiven modularen Aufbau einer Viewerstruktur durch die MPDL möglicherweise begünstigen. Im KHI sind Volltext-Referenzen noch einmal anders gelöst. Im Translatio Nummorum Projekt liegen entfernt TEI ähnliche Transkripte außerhalb des METS Files und werden von METS aus per filesec URL referenziert. Dabei werden mittels XPath auch Links auf eine ID innerhalb des Volltextfiles gesetzt, theoretisch sozusagen "buchstabengenau" (aus pragmatischen Gründen am KHI nur seitengenau). Im Endeffekt ist der Unterschied aber marginal - der Volltext hätte auch innerhalb einer dmdSec liegen können. Die Möglichkeit, spezielle TOCs mittels der structMap anzulegen (phyische Struktur, Paginierung, Original Inhaltsverzeichnis, "logische" TOC, Abbildungsverzeichnisse), ohne dabei jedes Mal die Einzelelemente neu anlegen zu müssen (man verweist immer auf die dmdSec ID bzw. auf eine URL der FileSec), stellt einen weiteren, nicht zu unterschätzenden Vorteil dar, der so meines Wissens in anderen XML-Formaten nicht gegeben ist.
Der Nachteil von METS liegt darin, dass es schnell passieren kann, dass Informationen redundant gespeichert werden. Dem kann aber durch geschickte Reduktion auf die notwendigen Elemente entgegengewirkt werden. Im KHI haben wir z.B. den "Fehler" gemacht, dass wir bisher die Kapitelüberschriften sowohl im MODs Teil innerhalb der dmdSec als auch nochmals im StructMap Teil angaben. Dies ist vor allem deshalb geschehen, weil wir uns zum Zeitpunkt der Erfassung nicht im Klaren waren, wie das Viewerkonzept einmal funktionieren soll. Inzwischen wissen wir, dass wir die Angaben in der logischen Structmap (TOC) weglassen und uns einfach des Links auf den entsprechenden MODS:Titel Block bedienen hätten können. METS ist für sich genommen "absichtlich" kein Volltextformat, könnte also für die Volltextverarbeitung lediglich als Container funktionieren, der ein Volltextformat beinhaltet oder auf externe Volltexte referenzieren.
--Zieger 16:22, 28 March 2011 (CEST)
Das TEI Format (kew)[edit]
TEI (http://www.tei-c.org/) geht in seinen Anfaengen auf Bemuehungen Ende der 80er Jahre zurueck, digitale wissenschaftliche Volltexteditionen zu erstellen. Dabei stand von Anfang die semantische Wiedergabe des Textes im Vordergrund. Die TEI Richtlinien fuer die Auszeichnung des Textes in XML (das tagging der Struktur) sind enorm umfangreich und koennen alle Belange abdecken, von musikologischen Texten ueber Manuskripte bis hin zur Wiedergabe von epigraphischen Dokumenten. Natuerlich lassen sich damit auch ausdruecklich "digital facsimiles" erstellen, d.h. Digitalisate an deren Anfang eine blosse Reihe von Scans mit einigen wenigen Strukturdaten (Abschnitt, Abschnitt-Titel) steht - wie es bei uns zumeist der Fall ist!
Da die Liste der moeglichen Elemente erstaunlich angewachsen ist, hat sich zumeist der Einsatz eines TEI-Subsets durchgesetzt, d.h. man definiert zuanfangs eine Untermenge aller moeglichen Formate, um dem Bearbeiter die Zuweisung der semantischen Elemente an den Textkorpus zu erleichtern. Hierzu gibt es sowohl fertige Module als auch einen Schema-Generator, der mit wenigen Klicks zum fertigen TEI-Schema fuehrt (online! hier der Link: http://tei.oucs.ox.ac.uk/Roma/). Alle diese Schemata bleiben untereinander kompatibel, sie stellen lediglich eine (gewollte) vereinfachte Auswahl der grossen Menge an TEI Elementen dar.
Das TEI Format orientiert sich an der Wiedergabe des Werkes, d.h. nach den ueblichen Metadaten - die auf Wunsche auch extrem spezifisch sein koennen! - beginnt der Textabschnitt, welcher sowohl Seitenumbruche (die mit ihren Verweisen auf die Scans fuer die Digitalisate wichtig sind), Kapitel, Unterkapitel als auch den gesamten Volltext enthalten koennen: wer will, kann auch Personen- oder Ortsnamen oder auch Jahreszahlen semantisch auszeichnen.
1. Der <teiHeader> enthaelt in seiner fileDesc (file Description) alle notwendigen Metadaten wie bibliographische Daten, Angaben zur Erstellung der Transkription sowie - etwa bei Manuskripten - Beobachtungen zum physischen Zustand des Dokumentes, Material, Schrifttypen, etwaigen Nebenautoren, etc.:
- titleStmt (title Statement): Angaben zu Titel, Autor, Verantwortliche, Klassifikation der Publikation etc.
- editionStmt (edition Statement): Angaben zur Edition (*)
- extent (extent statement): Angaben zum Umfang (Seiten oder MB) (*)
- publicationStmt (publication Statement): Angaben zu Publikation, Copyright, etc.
- seriesStmt (series Statement): Angaben zur Reihe oder Serie (optional) (*)
- notesStmt (notes Statement): Zusaetzliche Angaben zum Werk oder seiner Transkription (*)
- sourceDesc (source Description): Angaben zum tatsaechlichen Digitalisat und seiner Vorgeschichte.
- msDesc (manuscript description): Angaben zum Manuskript wie Herkunft, Gestaltung, Schriften, Haende etc. Kann auch fuer Dokumente benutzt werden, die streng technisch keine Manuskripte sind, z.B. Inkunabeln. Vgl. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHPH und http://www.tei-c.org/Activities/Workgroups/MS/FASC-ms-Guidelines/MS.html (*)
- encodingDesc (encoding Description): Angaben zur semantischen Codierung des Textes, der Auswahl der Taxonomien etc. (*)
- profileDesc (profile Description): Angaben zu verwendeten Sprachen, Schlagworten etc. (*)
- revisionDesc (revision description): Angaben zum Digitalisierungs- bzw. Transkriptionsprojekt (*)
Mit (*) gekennzeichnete Abschnitte sind optional. Mehr Informationen hier: http://www.tei-c.org/release/doc/tei-p4-doc/html/HD.html .
Die TEI Metadaten sind von Anfang an so ausgelegt worden, dass eine Weiterverabeitung nach AACR2, Z39.29, ISBD(G), und weiter nach MODS problemlos moeglich ist (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD8).
Trotz seiner moeglichen Komplexitaet kann ein TEI Dokument aber auch ganz bewusst simpel gehalten werden. Ein minimaler TEI Header wuerde etwa so aussehen:
<fileDesc>
<titleStmt>
<title>Thomas Paine: Common sense, a
machine-readable transcript</title>
<respStmt>
<resp>compiled by</resp>
<name>Jon K Adams</name>
</respStmt>
</titleStmt>
<publicationStmt>
<distributor>Oxford Text Archive</distributor>
</publicationStmt>
<sourceDesc>
<bibl>The complete writings of Thomas Paine, collected and edited by Phillip S. Foner (New York, Citadel Press, 1945)</bibl>
</sourceDesc>
</fileDesc>
2. Der nachfolgende <text> enthaelt, wie zu erwarten, den eigentlichen Text in seiner hierarchischen (und ev. semantischen) Struktur. Seitenumbrueche mit Verweisen auf entsprechende Scans <pb n="{$pagenumber}" facs="{$scan}"> legen die physische Struktur dar, wahrend Abschnitte mit Titeln und ev. Untertiteln (div, title) die logische Gliederung enthalten.
Um beim Beispiel zu bleiben - ein minmaler TEI Body koennte etwa folgendermassen aussehen:
<text>
<pb n="1" facs="dcim001"/>
<para>Text auf Seite 1</para>
<pb n="2" facs="dcim002"/>
<para>Text auf Seite 2</para>
</text>
Dadurch, dass TEI sowohl den Inhalt als auch die Struktur gleichsam in einem Atemzug beschreibt (und nicht, wie METS, alles in Tabellen aufsplittet), bleibt das entstehende Dokument auch von Menschen noch lesbar: die Tabellenstrukturen, die in METS hingegen verwendet werden - und die, nebenbei, einen um das siebenfach groesseren Datenumfang besitzen! - sind aufgrund ihrer enormen Komplexitatet nur noch maschinell auswertbar.
TEI zeigt sich auch dadurch auf der Hoehe der Zeit, dass es neueste Schemasprachen (XSD, RNG) unterstuetzt, die es erlauben, die Textaufnahme einerseits auf wenige Elemente zu beschraenken, was den Bearbeitern das Durcharbeiten der Texte enorm die erleichtert, andererseits aber auch (wenn es verlangt wird) enorme Moeglichkeiten zur Anpassung auch an sehr spezialisierte Projekte besitzt. Die grosse Auswahl an schon bereits bestehenden - auch grafischen fuer Windows, Mac und *nix - Tools sowohl zur Erstellung als auch zur Weiterverarbeitung bis hin zur (Kontroll-)Ausgabe als Word-DOC oder PDF machen TEI als Basisformat besonders interessant. Eine einfache Transformation in METS/MODS als zusaetzliches Exportformat ist bei der Hertziana in Arbeit.
Es ist besonders die ungeheuere Flexibilitaet, welche TEI auszeichnet: man kann ein reines Digitalisat erstellen (also lediglich eine Abfolge von Scans), oder eine grobe Strukturierung einbauen, oder auch per OCR automatisiert Text einfuegen, oder schliesslich auch den Text noch wissenschaftlich auszeichnen. An jeder beliebigen Stelle, auch nachtraeglich, kann ein Digitalisat zum Volltext ausgebaut werden.
Wozu TEI faehig ist, zeigt sich etwa im Projekt Deutsches Textarchiv (DTA) der Berlin-Brandenburgischen Akademie der Wissenschaften (BBAW) http://www.deutschestextarchiv.de/ dessen Digitalisierung ausschliesslich ueber TEI laeuft.
Existierende TEI Schemata[edit]
Das schon genannte Deutsche Text Archiv benutzt ein TEI Schema, das mit vergleichsweise wenigen Elementen auskommt, jedoch fuer deutsche Textquellen die dem DTA noetigen Belange abdeckt. Eine Uebernahme dieses Schemas fuer die Belange der dem DLC angeschlossenen Institute ist dennoch nicht empfehlenswert: das vom DTA propagierte Schema (http://kaskade.dwds.de/dtaq/help/basisformat Link "Basisformat") ist besonders im Hinblick auf eine wissenschaftlichen Weiter-Verwendung in seinem Wortschatz (sprich: der Zahl seiner erlaubten Elemente) zu eingeschraenkt: so koennen dort weder Geo-Referenzierungen, noch Metadaten zu kodikologischen Daten oder lediglich impliziert genannte Autoren von Aufsaetzen bzw. Kuenstlern von Abbildungen o.ae. abgelegt werden.
Dennoch ist das DTA Schema interessant fuer die Moeglichkeit, mit relativ geringem Aufwand eine Publikation der in TEI/DLC angelegten Dokumente auch in DTA zu bewerkstelligen. Dazu muss lediglich der groessere Wortschatz von TEI/DLC auf den geringeren Umfang von TEI/DTA zurechtgestutzt werden, entweder beim Export aus DLC (ueber eine Transformation in XSLT) oder beim Import in DTA: beidesmal wird die Transformation "lossy" sein, d.h. es wird Information verloren gehen.
Als weitere Moeglichkeit ist etwa auch der DFG-Viewer zu nennen, der eine noch wesentlich geringeren Wortschatz beherrscht, damit jedoch die ihm gestellten Anforderungen eines TOC abzudecken vermag.
Die Moeglichkeiten, ein "privates" Schema nach Bedarf auf ein "oeffentliches" Schema herunterzudruecken, sind eindrucksvoll von Sebastian Rahtz beim DLC Workshop in Berlin (http://colab.mpdl.mpg.de/mediawiki/Digitization_Lifecycle_Veranstaltungen#Referierende) dargelegt worden, der darin zu recht eine Moeglichkeit sieht, aus einem einzigen Dokumentformat, naemlich TEI, heraus unterschiedliche Belange abzudecken.
Mögliche Formate[edit]
| Daten | Denkbare Format(e) | Info | Kommentar |
|---|---|---|---|
| Files/Scans | METS | Nur das METS Format erlaubt den Aufbau einer File-Section welche die Referenzen zu den Bildern in verschiedenen Auflösungen enthält | direkte Referenzen zu Bildern in verschiedenen Auflösungen sind auf lange Sicht ungünstig (z. B. bei Server-Umzug), besser wären persistente Identifier. Auflösung der Bilder ist Sache des Viewers (z. B. Digilib), nicht des Dateiformats. Dann müßte man z.B. nicht die Buch-Daten ändern, wenn man später höher aufgelöste Scans hinzufügen möchte. Anmerkung KHI: Es ist nicht nötig, verschiedene Auflösungen eines Bildes oder generischer formuliert, verschiedene Inkarnationen des Masterfiles anzulegen. Wenn es Sache des Viewers ist, dann legt man einen XPath auf den Viewer (inklusive übergebenen Parameter). |
| Physische Struktur | METS | Mit METS wären verschiedene physische Strukturen/Paginierungen eines Werks denkbar. Diese können direkt auf die jeweilige File Section verweisen. | Eigentlich hat ein Buch nur eine physische Struktur. Alles darüber hinaus sind semantische Strukturen, die davon abstrahieren. Die Paginierung kann als Benennungs-Attribut der physischen Seite aufgefaßt werden. Zwei oder mehr Paginierungen würden nichts an der physischen Struktur ändern. |
| Logische Struktur | METS, TEI | Problem bei TEI: Wie wird die physische Struktur aus METS an die logische Struktur in TEI gekoppelt und umgekehrt? Nutzung von XML IDs in TEI und METS <BEGIN> und <END> Elementen? | TEI geht von der Idee der Auszeichnung eines "idealen" Textes aus. Es ist zunächst nicht für die Beschreibung eines Buch-Exemplares gedacht. Es ist nicht etwa so, dass METS digitale Ressourcen wie Seiten-Scans zu einer logischen Struktur verknüpft. Sondern man wirft jedes (Sub)Bestandteile eines Buches in die DmSec und strukturiert diese hierarchisch in einer oder mehreren Structmap. Damit können auch einzelne Bilder oder (wenn man den Aufwand nicht scheut) auch einzelne Wörter referenziert werden, sie müssen nur in der DmSec angelegt sein. Ob dazu eine digitale Resource (wie ein Seitenscan) vorhanden ist, ist unerheblich. Aber natürlich kann über die Filesec auch ein Viewer angebunden werden, der das jeweilige Subelement explizit darstellt. Da in der DmSec auch TEI eingebunden werden kann, könnte eventuell sogar eine Binnendifferenzierung innerhalb der Ressourcen (Seiten) möglich sein - damit liegen meines Erachtens aber kaum Erfahrungen vor. |
| Visuelle Struktur | (kew) TEI | Bisher nicht implementiert | Beispiele: gegenüberstehende Seiten. Seitengestaltung, "Layout", Typographische Besonderheiten. Initialen, Vignetten, Buchschmuck. Sonderfälle wie eingeklebte Illustrationen. Visuelle Bezüge zwischen Text- und anderen Elementen (Glossen, Marginalien, Einschübe, Diagramme, Synopsen) (kew) Layout, physischer Zustand, Illustrationen, Kopf- und Fusszeilen etc. lassen sich in TEI durchaus beschreiben, entweder im mssDesc / physDesc Header oder direkt in den jeweiligen Seiten/Scans. Siehe http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msph und http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/PH.html#PHFAX . |
| Metadaten zu logischen Strukturelementen | in METS: TEI Header/MODS in TEI: TEI Header(???) |
Falls logische Struktur in METS: keine Probleme. Falls logische Struktur in TEI: Können dazu Strukturmetadaten direkt im TEI abgelegt werden? Oder kann/soll über eine XML id zurück in eine DMD-Section des METS referenziert werden? |
Der TEI Header ist für "bibliothekarischen" Metadaten gedacht, nicht für Strukturmetadaten (was ist damit gemeint?). Mehrsprachige Angaben? Andere/berichtigte Lesarten? Vermerke der Bearbeiter? |
| bibliographische Metadaten zum Werk | in METS: TEI Header/MODS in TEI:TEI Header |
Hierfür bietet sich eine DMD-Section in METS an, die TEI-Header Daten oder MODS enthalten kann. Bei Verwedung eines reinen TEIs könnten nur TEI Header Metadaten abgelegt werden | (kew) TEI kann fast alle nur denkbare Metadaten (s.o. Vorstellung TEI Header) erfassen. Diese lassen sich auf Wunsch natuerlich auch in Z39.29, MARC oder MODS uebertragen. |
| kodikologische Metadaten zum Werk | in METS: eigenes Metadaten Format in TEI: Modifikation notwendig |
DMD-Section in METS | (kew) TEI kann, wie schon erprobt, kodikologische Metadaten in der mssDesc Abteilung hervorragend erfassen. Eine Modifikation ist dazu nicht notwendig. |
| andere Metadaten (z. B. Schlagwörter) zum Werk | in METS: eigenes Metadaten Format in TEI: Modifikation notwendig |
DMD-Section in METS | (kew) Schlagwoerter, Taxonomien etc. werden zusammen mit Angaben auf ihren Bezugsrahmen (SWG, PND, etc.) in der profileDesc des Headers abgelegt. Eine Modifikation ist dazu nicht notwendig. |
| Metadaten zur Digitalen Edition | in METS: eigenes Metadaten Format in TEI: Modifikation notwendig |
DMD-Section in METS? | (kew) Angaben zu Institution, Projekt, Bearbeiter, Datum, Bearbeitungsstand, Modifikationen, etc. werden im encodingDesc bzw. dem revisionDesc des Headers abgelegt. Eine Modifikation ist dazu nicht notwendig. |
| Volltexte | TEI | Für das Ablegen von Volltexten eignet sich das TEI Format. Problem besteht wiederum in der Koppelung mit der logischen Struktur in METS. Zudem besteht eine nicht wünschenswerte Redundanz falls die logische Struktur in METS abgelegt wurde, aber auch (evtl. in Teilen) im TEI vorhanden ist. | (kew) Hier gbt es kein Problem: METS kann keine Volltexte aufnehmen, sodass bei der Volltextdigitalisierung generell TEI benutzt werden muss. Wenn gewuenscht, kann das TEI auch (unter Verlust des Textes) als METS exportiert werden, das jedoch (gezwungenermassen) nur einen Bruchteil des Original-TEI darstelllt. Ein "Ueberhang" mit redundanten Daten entsteht hierbei nicht. Es wäre interessant zu überlegen, wenn man das TEI so aufbrechen würde, dass die SubObjekte (=Kapitel) innerhalb der DmSec inklusive Volltext vorliegen. |
| Wortgenaue Verweise | (kew) TEI | Bisher nicht implementiert | in METS ist eine Binnendifferenzierung der einzelnen Seite nicht in diesem Sinne vorgesehen, da die grundlegende Metapher nicht die physischen Seiten darstellt, sondern die SubObjekte (=Kapitel) eines Werkes. in TEI nur auf das einzelne Strukturlement, oder "hart kodiert" (hard coded) durch Auszeichnung einzelner Stellen des Volltextes |
| Verweise auf Bildregionen | (kew) TEI und z.T. METS | Bisher nicht implementiert / Bei METS nur über FileSec Verweis auf einen Viewer, der das unterstützt (z.B. Digilib) | (kew) In TEI mittels <surface> und <zone> auf dem Seiten/Scanverweis des Digitalisats implementiert, eine Vorstellung hier: http://tei.oucs.ox.ac.uk/Talks/2010-02-0405-cambridge/talk-08-facsimile.pdf . |
Szenarien[edit]
- Institut besitzt Scans und bibliographische Metadaten, niemals Volltexte
- Beim Hochladen der Scans wird automatisch eine File Section und eine physische Struktur in METS angelegt.
- Die bibliographischen Daten werden als TEI Header im METS gespeichert
- Über den Digi Life Editor kann später eine logische Struktur angelegt werden, die im METS abgelegt wird.
- Falls die logische Struktur in TEI abgelegt werden soll, entstehen folgende Probleme:
- Kopplung zwischen physischer Struktur in METS und logischer Struktur in TEI?
- Wo werden zusätzliche Metadaten eines logischen Strukturelements abgelegt?
- Institut besitzt Scans und bibliographische Metadaten, will später Volltexte hinzufügen über ein komplettes TEI hinzufügen
- Schritte wie bei 1.
- Kommt später ein Volltext TEI, muss dieses irgendwie an die logische METS Struktur gehängt werden, folgende Optionen:
- Falls logische Struktur in DigiLife bereits vorhanden: TEI muss logische Struktur und pagebreak Information enthalten, diese wird von METS über XML IDs im TEI referenziert. Problem: Redundanz und Koppelung der logischen Daten -> Fast unmöglich
- Falls noch keine logische Struktur vorhanden: TEI muss logische Struktur und pagebreak Information enthalten, diese werden in eine logische METS-Struktur transformiert und dann über XML IDs im TEI referenziert. Ebenfalls problematisch: Redundanz und Koppelung der logischen Daten
- Logische Struktur im TEI ersetzt/überschreibt die vorher manuelle angelegte Struktur. Problem: Kopplung der logischen Strukturdaten in XML an die physischen Daten in METS.
- Institut besitzt Scans, bibliographische Daten und logische Struktur in TEI, will später Volltexte hinzufügen
- Hier treten die gleichen Probleme wie bei 2. auf (Koppelung der Daten bzw. Redundanz)
- Institut besitzt Scans und komplettes TEI mit logischen Strukturdaten sowie Volltext:
- TEI Header mit bibl. Daten wird im METS abeglegt.
- Aus den TEI pagebreaks wird eine physische Struktur in METS generiert.
- Problem: Koppelung physischer METS Struktur an TEI Struktur. Hier evtl. noch am einfachsten läsbar über XML ID Referenzen.
Zusammenfassung der größten Probleme:
- Redundanz zwischen METS und TEI Struktur
- Wie vermeide ich diese?
- Kopplung von METS Elementen an TEI Elemente/Bereiche und umgekehrt.
- Bisher kein optimal angepasstes Standard-Format vorhanden
Lösungsvorschläge:
- eigenes Format definieren, das
- den Erfordernissen von digitalen "Faksimiles" gerecht wird
- den Export in Standardformate (METS/MODS, TEI, Dublin Core) ermöglicht
- als neuer Standard für digitalen "Faksimiles" vorgeschlagen wird
Useful links[edit]
TEI[edit]
- Spoken Word / Audio Referenzing:
- CDL Encoding Guidelines for the TEI Header
- Practical considerations in the use of TEI headers in a large corpus
- The TEI Lite Header
- Torsten Schaßan: Dokumentation zur Erstellung von Beschreibungen mittelalterlicher Handschriften in XML Kodierung nach TEI-P5/MASTER gemäß DFG-Richtlinien zur Handschriftenkatalogisierung
DLC-TEI Schema[edit]
Das aktuelle Schema ist immer abgelegt auf:
[3] DLC-TEI Schema und Dokumentation