Digitization Lifecycle Data Format

Datenformat

(erstes brainstorming MPI Bibliotheca Hertziana)

allgemeine Anforderungen

• 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

Die Strukturdatei soll umgewandelt werden können in

• TEI
• METS/MODS (DFG-Viewer)
• OAI (Metadata-Harvesting)
• andere bibliothekarische Exportformate?

Das METS-Format (kew)

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 TEI Format (kew)

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.

Mögliche Formate

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.
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. METS verknüpft Ressourcen (Seiten-Scans) zu einer logischen Struktur, ist aber ungeeignet für eine Binnendifferenzierung innerhalb der Ressourcen (Seiten). (kew) TEI 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) 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.
Wortgenaue Verweise	(kew) TEI	Bisher nicht implementiert	in METS nicht möglich, da keine Binnendifferenzierung der einzelnen Seite vorgesehen ist in TEI nur auf das einzelne Strukturlement, oder "hart kodiert" (hard coded) durch Auszeichnung einzelner Stellen des Volltextes
Verweise auf Bildregionen	(kew) TEI	Bisher nicht implementiert	(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

1. 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?

2. 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.

3. 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)

4. 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

Max-Planck-Institut

Extensible Markup Language

Document type definition

Online Public Access Catalogue

Schlagwort Datei

Uniform Resource Locator

Expression Language Used to Navigate and to Find Structures in XML Documents

Text Encoding Initiative

Metadata Encoding and Transmission Standard

Metadata Object Description Schema

Deutsche Forschungsgemeinschaft

Open Archives Initiative

Filename Extension for Text Files

Identifier

International Standard Bibliographic Description

XML Schema Definition

Random Number Generator

Portable Document Format

Optical Character Recognition

Deutsches Textarchiv

Berlin-Brandenburgische Akademie der Wissenschaften

Web Based Server Technology for Viewing and Working with Images

MAchine-Readable Cataloging

Personen Normdatei