Digitization Lifecycle Data Format

From MPDLMediaWiki
Revision as of 10:37, 26 March 2012 by Kewerner (Talk | contribs)

Jump to: navigation, search

Arbeitsgruppe Format

Koordinator

Klaus Werner, Markus Haarländer (mögliche Übergabe ab 12.4.2011)

Teilnehmer

  • Wilhelm Frank
  • Lisa Pegelow
  • Wolfram Zieger
  • Anna Klug
  • Ingo Caesar

Ziele und Arbeitspakete

Arbeitspakete:
1. Generierung und Definition des Datenformats
2. Einholen von Know How externer ExpertInnen zum Thema TEIText Encoding Initiative

Telcos

Datenformat

(erstes brainstorming MPIMax-Planck-Institut Bibliotheca Hertziana)

allgemeine Anforderungen

  • sollte ein XMLExtensible Markup Language-Format sein
  • sollte durch ein Schema definiert und dokumentiert sein (DTDDocument type definition, Relax-NG, XMLExtensible Markup Language-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 (OPACOnline Public Access Catalogue)
    • Metadaten zum digitalen Dokument (Urheber, Institution, Datum etc)
    • kodikologische Metadaten (Exemplar-Beschreibung alla fiorentina)
    • weitere allgemeine Metadaten zum Buch (SWDSchlagwort Datei etc)
    • Metadaten zu den Scan-Dateien (Server-URLUniform Resource Locator, 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 XPathExpression Language Used to Navigate and to Find Structures in XML Documents-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

Die Strukturdatei soll umgewandelt werden können in

  • TEIText Encoding Initiative
  • METSMetadata Encoding and Transmission Standard/MODSMetadata Object Description Schema (DFGDeutsche Forschungsgemeinschaft-Viewer)
  • OAIOpen Archives Initiative (Metadata-Harvesting)
  • andere bibliothekarische Exportformate?

Das METSMetadata Encoding and Transmission Standard-Format (kew)

METSMetadata Encoding and Transmission Standard (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 METSMetadata Encoding and Transmission Standard geloest werden sollte - war, dass sich in kurzer Zeit Berge von TIFFs/JPEGs anhaeuften, plus Buchbeschreibungen in TXTFilename Extension for Text Files/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).

METSMetadata Encoding and Transmission Standard erledigte das auf folgende Weise:

1. Die Abspeicherung der Metadaten zur Erstellung des METSMetadata Encoding and Transmission Standard Dokuments sowie zum eigentlichen Werk:

  • metsHdr (METSMetadata Encoding and Transmission Standard Header): Metadaten zum METSMetadata Encoding and Transmission Standard Dokument selbst (Produktion, Datum etc.)
  • dmdSec (descriptive metadata Section): Metadaten zum Werk selbst (wobei man diese - und dies ist aeusserst praktisch - auch in MODSMetadata Object Description Schema beschreiben und in METSMetadata Encoding and Transmission Standard 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 METSMetadata Encoding and Transmission Standard 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 IDIdentifier.
  • structMap / logical (logical structural Map): tabellarisch/hierarchische Abbildung des Inhaltes (in dmdSec war es ja nur eine reine Auflistung!) mit Kapiteln, Kapiteltiteln und deren IDIdentifier.
  • structMap / physical (physical structural Map): tabellarische Auflistung der einzelnen Seiten und deren IDIdentifier.

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 IDIdentifier zugewiesen worden) - so musste man jetzt (Relational!) noch eine weitere Tabelle hinzufuegen: eine Tabelle, welche jede einzelne Seite anhand ihrer IDIdentifier 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 METSMetadata Encoding and Transmission Standard aber auch den Status "end-of-life", da es den komplexeren Anforderungen (full text, deep-referencing, cross-linking, ...) nicht Genuege leisten kann.


Das METSMetadata Encoding and Transmission Standard Format mit eingebetteten MODSMetadata Object Description Schema Teilen im praktischen Einsatz (Darstellung aus Sicht des KHIKunsthistorisches Institut, Rom)

Bei seinen Projekten "PRO FIRENZE FUTURISTA" und "translatio nummorum" verwendet das KHIKunsthistorisches Institut, Rom das METSMetadata Encoding and Transmission Standard XMLExtensible Markup Language Format mit einbetteten MODSMetadata Object Description Schema 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 METSMetadata Encoding and Transmission Standard 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, OCROptical Character Recognition-Dateien, XMLExtensible Markup Language-Transkripte, Video- und Audiofiles) der originalen physischen Medien bzw. Ausschnitten daraus erfolgen.
METS MODS Struktur Futurismus-KHI.jpeg
Das METSMetadata Encoding and Transmission Standard Format ist flexibel genug, all das abzubilden. Dabei ist es nicht einmal nötig, die komplette, historisch gewachsene XMLExtensible Markup Language Struktur zu verwenden. Von den möglichen sechs METSMetadata Encoding and Transmission Standard-Blöcken, verwenden das Futurismus-Projekt und das Translatio-Nummorum-Projekt des KHIKunsthistorisches Institut, Rom nur vier:

  • metsHdr (METSMetadata Encoding and Transmission Standard 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 MODSMetadata Object Description Schema 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 KHIKunsthistorisches Institut, Rom wird, wo es sich anbietet, eine physische Structmap (i.d.R. die Einzelseiten eines Buches oder einer Zeitung) und eine logische Structmap (TOCTable of Contents) 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 METSMetadata Encoding and Transmission Standard läßt das KHIKunsthistorisches Institut, Rom 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 MODSMetadata Object Description Schema) 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 METSMetadata Encoding and Transmission Standard 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 MODSMetadata Object Description Schema verwendet werden. Dass dabei auch Volltextformate wie TEIText Encoding Initiative oder DOCbook verwendet werden können, versteht sich von selbst. In Sachen Volltexten wäre es "im METSMetadata Encoding and Transmission Standard-Sinne" wenn jedes Kapitel/Subkapitel als einzelnes METSMetadata Encoding and Transmission Standard-dmdSec Element in einem in sich abgeschlossenen TEIText Encoding Initiative- oder DocBook Block vorliegt. Das wiederum ist aber nicht im TEIText Encoding Initiative Sinne. Denkbar wäre es hier wiederum, das gesamte Hauptobjekt komplett in TEIText Encoding Initiative anzulegen (inklusive TOCTable of Contents Struktur, Metadaten, Imagelinks etc.), und dann rudimentär die TOCTable of Contents-Struktur noch einmal zusätzlich als einzelne DmdSec Objekte anzulegen (durchaus auch automatisiert per XSLTExtensible Stylesheet Language Transformations Transformation machbar). Der daraus resultierende (leider redundante) Aufbau würde es ermöglichen, mit einem METSMetadata Encoding and Transmission Standard Viewer die grobe Struktur zu erfassen, aber zudem mit einem TEIText Encoding Initiative Viewer den Volltext in allen Details zu bewundern. Dies würde den sukzessiven modularen Aufbau einer Viewerstruktur durch die MPDLMax Planck Digital Library möglicherweise begünstigen. Im KHIKunsthistorisches Institut, Rom sind Volltext-Referenzen noch einmal anders gelöst. Im Translatio Nummorum Projekt liegen entfernt TEIText Encoding Initiative ähnliche Transkripte außerhalb des METSMetadata Encoding and Transmission Standard Files und werden von METSMetadata Encoding and Transmission Standard aus per filesec URLUniform Resource Locator referenziert. Dabei werden mittels XPathExpression Language Used to Navigate and to Find Structures in XML Documents auch Links auf eine IDIdentifier innerhalb des Volltextfiles gesetzt, theoretisch sozusagen "buchstabengenau" (aus pragmatischen Gründen am KHIKunsthistorisches Institut, Rom 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" TOCTable of Contents, Abbildungsverzeichnisse), ohne dabei jedes Mal die Einzelelemente neu anlegen zu müssen (man verweist immer auf die dmdSec IDIdentifier bzw. auf eine URLUniform Resource Locator der FileSec), stellt einen weiteren, nicht zu unterschätzenden Vorteil dar, der so meines Wissens in anderen XMLExtensible Markup Language-Formaten nicht gegeben ist.


Der Nachteil von METSMetadata Encoding and Transmission Standard 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 KHIKunsthistorisches Institut, Rom 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 (TOCTable of Contents) weglassen und uns einfach des Links auf den entsprechenden MODSMetadata Object Description Schema:Titel Block bedienen hätten können. METSMetadata Encoding and Transmission Standard 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 (CESTCentral European Summer Time)

Das TEIText Encoding Initiative Format (kew)

TEIText Encoding Initiative (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 TEIText Encoding Initiative Richtlinien fuer die Auszeichnung des Textes in XMLExtensible Markup Language (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 TEIText Encoding Initiative-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 TEIText Encoding Initiative-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 TEIText Encoding Initiative Elementen dar.

Das TEIText Encoding Initiative 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.
  • 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 TEIText Encoding Initiative Metadaten sind von Anfang an so ausgelegt worden, dass eine Weiterverabeitung nach AACR2, Z39.29, ISBDInternational Standard Bibliographic Description(G), und weiter nach MODSMetadata Object Description Schema problemlos moeglich ist (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD8).

Trotz seiner moeglichen Komplexitaet kann ein TEIText Encoding Initiative Dokument aber auch ganz bewusst simpel gehalten werden. Ein minimaler TEIText Encoding Initiative 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 TEIText Encoding Initiative 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 TEIText Encoding Initiative sowohl den Inhalt als auch die Struktur gleichsam in einem Atemzug beschreibt (und nicht, wie METSMetadata Encoding and Transmission Standard, alles in Tabellen aufsplittet), bleibt das entstehende Dokument auch von Menschen noch lesbar: die Tabellenstrukturen, die in METSMetadata Encoding and Transmission Standard hingegen verwendet werden - und die, nebenbei, einen um das siebenfach groesseren Datenumfang besitzen! - sind aufgrund ihrer enormen Komplexitatet nur noch maschinell auswertbar.

TEIText Encoding Initiative zeigt sich auch dadurch auf der Hoehe der Zeit, dass es neueste Schemasprachen (XSDXML Schema Definition, RNGRandom Number Generator) 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 PDFPortable Document Format machen TEIText Encoding Initiative als Basisformat besonders interessant. Eine einfache Transformation in METSMetadata Encoding and Transmission Standard/MODSMetadata Object Description Schema als zusaetzliches Exportformat ist bei der Hertziana in Arbeit.

Es ist besonders die ungeheuere Flexibilitaet, welche TEIText Encoding Initiative auszeichnet: man kann ein reines Digitalisat erstellen (also lediglich eine Abfolge von Scans), oder eine grobe Strukturierung einbauen, oder auch per OCROptical Character Recognition 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 TEIText Encoding Initiative faehig ist, zeigt sich etwa im Projekt Deutsches Textarchiv (DTADeutsches Textarchiv) der Berlin-Brandenburgischen Akademie der Wissenschaften (BBAWBerlin-Brandenburgische Akademie der Wissenschaften) http://www.deutschestextarchiv.de/ dessen Digitalisierung ausschliesslich ueber TEIText Encoding Initiative laeuft.

Existierende TEIText Encoding Initiative Schemata

Das schon genannte Deutsche Text Archiv benutzt ein TEIText Encoding Initiative Schema, das mit vergleichsweise wenigen Elementen auskommt, jedoch fuer deutsche Textquellen die dem DTADeutsches Textarchiv noetigen Belange abdeckt. Eine Uebernahme dieses Schemas fuer die Belange der dem DLCDigitization Lifecycle angeschlossenen Institute ist dennoch nicht empfehlenswert: das vom DTADeutsches Textarchiv 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 DTADeutsches Textarchiv Schema interessant fuer die Moeglichkeit, mit relativ geringem Aufwand eine Publikation der in TEIText Encoding Initiative/DLCDigitization Lifecycle angelegten Dokumente auch in DTADeutsches Textarchiv zu bewerkstelligen. Dazu muss lediglich der groessere Wortschatz von TEIText Encoding Initiative/DLCDigitization Lifecycle auf den geringeren Umfang von TEIText Encoding Initiative/DTADeutsches Textarchiv zurechtgestutzt werden, entweder beim Export aus DLCDigitization Lifecycle (ueber eine Transformation in XSLTExtensible Stylesheet Language Transformations) oder beim Import in DTADeutsches Textarchiv: beidesmal wird die Transformation "lossy" sein, d.h. es wird Information verloren gehen.

Als weitere Moeglichkeit ist etwa auch der DFGDeutsche Forschungsgemeinschaft-Viewer zu nennen, der eine noch wesentlich geringeren Wortschatz beherrscht, damit jedoch die ihm gestellten Anforderungen eines TOCTable of Contents abzudecken vermag.

Die Moeglichkeiten, ein "privates" Schema nach Bedarf auf ein "oeffentliches" Schema herunterzudruecken, sind eindrucksvoll von Sebastian Rahtz beim DLCDigitization Lifecycle 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 TEIText Encoding Initiative, heraus unterschiedliche Belange abzudecken.

Mögliche Formate

Daten Denkbare Format(e) Info Kommentar
Files/Scans METSMetadata Encoding and Transmission Standard Nur das METSMetadata Encoding and Transmission Standard 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. DigilibWeb Based Server Technology for Viewing and Working with Images), 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 KHIKunsthistorisches Institut, Rom: 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 XPathExpression Language Used to Navigate and to Find Structures in XML Documents auf den Viewer (inklusive übergebenen Parameter).

Physische Struktur METSMetadata Encoding and Transmission Standard Mit METSMetadata Encoding and Transmission Standard 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 METSMetadata Encoding and Transmission Standard, TEIText Encoding Initiative Problem bei TEIText Encoding Initiative: Wie wird die physische Struktur aus METSMetadata Encoding and Transmission Standard an die logische Struktur in TEIText Encoding Initiative gekoppelt und umgekehrt? Nutzung von XMLExtensible Markup Language IDs in TEIText Encoding Initiative und METSMetadata Encoding and Transmission Standard <BEGIN> und <END> Elementen? TEIText Encoding Initiative 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 METSMetadata Encoding and Transmission Standard 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 TEIText Encoding Initiative eingebunden werden kann, könnte eventuell sogar eine Binnendifferenzierung innerhalb der Ressourcen (Seiten) möglich sein - damit liegen meines Erachtens aber kaum Erfahrungen vor.
(kew und überarbeitet Zieger) TEIText Encoding Initiative kann durchaus auch ein bestimmtes (Buch-)Exemplar beschreiben, wobei etwa alterthuemliche Schreibweisen entweder als solche gekennzeichnet oder automatisch korrigiert werden koennen - wobei diese automatische Korrektur jedoch im profileDesc des Headers angegeben werden muss. Siehe dazu http://www.tei-c.org/release/doc/tei-p5-doc/fr/html/PH.html#PHCH sowie http://www.tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD5 . Die Beschreibung des spezifischen Exemplars (mitsamt Bibliographie) erfolgt in der sourceDesc http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-sourceDesc.html.

Visuelle Struktur (kew) TEIText Encoding Initiative 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 TEIText Encoding Initiative 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 METSMetadata Encoding and Transmission Standard: TEIText Encoding Initiative Header/MODSMetadata Object Description Schema
in TEIText Encoding Initiative: TEIText Encoding Initiative Header(???)
Falls logische Struktur in METSMetadata Encoding and Transmission Standard: keine Probleme.
Falls logische Struktur in TEIText Encoding Initiative: Können dazu Strukturmetadaten direkt im TEIText Encoding Initiative abgelegt werden? Oder kann/soll über eine XMLExtensible Markup Language id zurück in eine DMD-Section des METSMetadata Encoding and Transmission Standard referenziert werden?
Der TEIText Encoding Initiative 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 METSMetadata Encoding and Transmission Standard: TEIText Encoding Initiative Header/MODSMetadata Object Description Schema
in TEIText Encoding Initiative:TEIText Encoding Initiative Header
Hierfür bietet sich eine DMD-Section in METSMetadata Encoding and Transmission Standard an, die TEIText Encoding Initiative-Header Daten oder MODSMetadata Object Description Schema enthalten kann. Bei Verwedung eines reinen TEIs könnten nur TEIText Encoding Initiative Header Metadaten abgelegt werden (kew) TEIText Encoding Initiative kann fast alle nur denkbare Metadaten (s.o. Vorstellung TEIText Encoding Initiative Header) erfassen. Diese lassen sich auf Wunsch natuerlich auch in Z39.29, MARCMAchine-Readable Cataloging oder MODSMetadata Object Description Schema uebertragen.
kodikologische Metadaten zum Werk in METSMetadata Encoding and Transmission Standard: eigenes Metadaten Format
in TEIText Encoding Initiative: Modifikation notwendig
DMD-Section in METSMetadata Encoding and Transmission Standard (kew) TEIText Encoding Initiative 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 METSMetadata Encoding and Transmission Standard: eigenes Metadaten Format
in TEIText Encoding Initiative: Modifikation notwendig
DMD-Section in METSMetadata Encoding and Transmission Standard (kew) Schlagwoerter, Taxonomien etc. werden zusammen mit Angaben auf ihren Bezugsrahmen (SWG, PNDPersonen Normdatei, etc.) in der profileDesc des Headers abgelegt. Eine Modifikation ist dazu nicht notwendig.
Metadaten zur Digitalen Edition in METSMetadata Encoding and Transmission Standard: eigenes Metadaten Format
in TEIText Encoding Initiative: Modifikation notwendig
DMD-Section in METSMetadata Encoding and Transmission Standard? (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 TEIText Encoding Initiative Für das Ablegen von Volltexten eignet sich das TEIText Encoding Initiative Format. Problem besteht wiederum in der Koppelung mit der logischen Struktur in METSMetadata Encoding and Transmission Standard. Zudem besteht eine nicht wünschenswerte Redundanz falls die logische Struktur in METSMetadata Encoding and Transmission Standard abgelegt wurde, aber auch (evtl. in Teilen) im TEIText Encoding Initiative vorhanden ist. (kew) Hier gbt es kein Problem: METSMetadata Encoding and Transmission Standard kann keine Volltexte aufnehmen, sodass bei der Volltextdigitalisierung generell TEIText Encoding Initiative benutzt werden muss. Wenn gewuenscht, kann das TEIText Encoding Initiative auch (unter Verlust des Textes) als METSMetadata Encoding and Transmission Standard exportiert werden, das jedoch (gezwungenermassen) nur einen Bruchteil des Original-TEIText Encoding Initiative darstelllt. Ein "Ueberhang" mit redundanten Daten entsteht hierbei nicht.
Es wäre interessant zu überlegen, wenn man das TEIText Encoding Initiative so aufbrechen würde, dass die SubObjekte (=Kapitel) innerhalb der DmSec inklusive Volltext vorliegen.
Wortgenaue Verweise (kew) TEIText Encoding Initiative Bisher nicht implementiert in METSMetadata Encoding and Transmission Standard 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 TEIText Encoding Initiative nur auf das einzelne Strukturlement, oder "hart kodiert" (hard coded) durch Auszeichnung einzelner Stellen des Volltextes
Verweise auf Bildregionen (kew) TEIText Encoding Initiative und z.T. METSMetadata Encoding and Transmission Standard Bisher nicht implementiert / Bei METSMetadata Encoding and Transmission Standard nur über FileSec Verweis auf einen Viewer, der das unterstützt (z.B. DigilibWeb Based Server Technology for Viewing and Working with Images) (kew) In TEIText Encoding Initiative 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

  1. Institut besitzt Scans und bibliographische Metadaten, niemals Volltexte
    Beim Hochladen der Scans wird automatisch eine File Section und eine physische Struktur in METSMetadata Encoding and Transmission Standard angelegt.
    Die bibliographischen Daten werden als TEIText Encoding Initiative Header im METSMetadata Encoding and Transmission Standard gespeichert
    Über den Digi Life Editor kann später eine logische Struktur angelegt werden, die im METSMetadata Encoding and Transmission Standard abgelegt wird.
    Falls die logische Struktur in TEIText Encoding Initiative abgelegt werden soll, entstehen folgende Probleme:
    • Kopplung zwischen physischer Struktur in METSMetadata Encoding and Transmission Standard und logischer Struktur in TEIText Encoding Initiative?
    • Wo werden zusätzliche Metadaten eines logischen Strukturelements abgelegt?
  2. Institut besitzt Scans und bibliographische Metadaten, will später Volltexte hinzufügen über ein komplettes TEIText Encoding Initiative hinzufügen
    Schritte wie bei 1.
    Kommt später ein Volltext TEIText Encoding Initiative, muss dieses irgendwie an die logische METSMetadata Encoding and Transmission Standard Struktur gehängt werden, folgende Optionen:
    • Falls logische Struktur in DigiLife bereits vorhanden: TEIText Encoding Initiative muss logische Struktur und pagebreak Information enthalten, diese wird von METSMetadata Encoding and Transmission Standard über XMLExtensible Markup Language IDs im TEIText Encoding Initiative referenziert. Problem: Redundanz und Koppelung der logischen Daten -> Fast unmöglich
    • Falls noch keine logische Struktur vorhanden: TEIText Encoding Initiative muss logische Struktur und pagebreak Information enthalten, diese werden in eine logische METSMetadata Encoding and Transmission Standard-Struktur transformiert und dann über XMLExtensible Markup Language IDs im TEIText Encoding Initiative referenziert. Ebenfalls problematisch: Redundanz und Koppelung der logischen Daten
    • Logische Struktur im TEIText Encoding Initiative ersetzt/überschreibt die vorher manuelle angelegte Struktur. Problem: Kopplung der logischen Strukturdaten in XMLExtensible Markup Language an die physischen Daten in METSMetadata Encoding and Transmission Standard.
  3. Institut besitzt Scans, bibliographische Daten und logische Struktur in TEIText Encoding Initiative, will später Volltexte hinzufügen
    Hier treten die gleichen Probleme wie bei 2. auf (Koppelung der Daten bzw. Redundanz)
  4. Institut besitzt Scans und komplettes TEIText Encoding Initiative mit logischen Strukturdaten sowie Volltext:
    TEIText Encoding Initiative Header mit bibl. Daten wird im METSMetadata Encoding and Transmission Standard abeglegt.
    Aus den TEIText Encoding Initiative pagebreaks wird eine physische Struktur in METSMetadata Encoding and Transmission Standard generiert.
    Problem: Koppelung physischer METSMetadata Encoding and Transmission Standard Struktur an TEIText Encoding Initiative Struktur. Hier evtl. noch am einfachsten läsbar über XMLExtensible Markup Language IDIdentifier Referenzen.


Zusammenfassung der größten Probleme:

  • Redundanz zwischen METSMetadata Encoding and Transmission Standard und TEIText Encoding Initiative Struktur
    Wie vermeide ich diese?
  • Kopplung von METSMetadata Encoding and Transmission Standard Elementen an TEIText Encoding Initiative 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 (METSMetadata Encoding and Transmission Standard/MODSMetadata Object Description Schema, TEIText Encoding Initiative, Dublin Core) ermöglicht
    • als neuer Standard für digitalen "Faksimiles" vorgeschlagen wird


Useful links

TEIText Encoding Initiative

DLCDigitization Lifecycle-TEIText Encoding Initiative Schema

Das aktuelle Schema ist immer abgelegt auf:

[3] DLCDigitization Lifecycle-TEIText Encoding Initiative Schema und Dokumentation