Zu den Dokumenttypen

Zurück

Text

Anhang

Zu den Dokumenttypen

Unter Kategorie I fallen alle Dokumente, d. h. sowohl die postalischen Dokumente wie Briefe, Postkarten, Telegramme etc., als auch Arbeitsdokumente zu Werken oder zeitgenössische Besprechungen (bspw. Werkrezensionen, Konzertkritiken etc.).

Ergänzt werden die Datensätze zu den Primärdokumenten durch katalogartig geführte „Referenzdatensätze“ (Kategorie II) wie Personen, musikalische und literarische Werke, Institutionen, Orte, Bibliographika, sowie Ereignisse1. Die Datensätze, die musikalische Werke und ihre Quellen verzeichnen, sind im Gegensatz zu den restlichen Datensätzen mit dem MEI-Standard codiert.

Zahlreiche Objekte, die im Kontext von Henze-Digital in Erscheinung treten sind in Normdatenbanken wie der GND, geonames oder VIAF verzeichnet. Je nach Dokumenttyp wird eine geeignete Datenbank für Verweise verwendet. Es findet keine direkte Verlinkung statt! Die Datensätze von Henze-Digital werden mittels der Identifikatoren der entsprechenden Normdatenbanken z.B. mit <idno> (für TEI) zugeordnet.

Dokumenttypen I (Volltexterfasste Datensätze)

Gesperrte Inhalte

Um der Wahrung von Persönlichkeitsrechten Sorge zu tragen kommt es bei der Publikation von Dokumenten des 20. Jahrhunderts vor, dass Inhalte gesperrt, d. h. von den Rechteinhabern nicht zur Publikation freigegeben sind. Solche Passagen werden durch eine Auslassung markiert, die den Umfang der Auslassung anzeigt, z.B. „[zweizeiliger Absatz]“.

Dokumente, die im Ganzen gesperrt sind, d. h. in der bestandshaltenden Institution nicht einsehbar sind, werden bis zu ihrer Freigabe im Datenbestand von Henze-Digital nicht geführt.

Zur allgemeinen Struktur volltexterfasster Dokumente

Grundstruktur des Textes

Ein Dokument ist grundsätzlich ein <text> Element, bestehend aus <div> und <p> Elementen, wobei gewöhnlich ein Brief oder ein Dokument auch nur ein <div> Element enthält. Die Verwendung des Elements <p>, welches zur Abtrennung von Absätzen Anwendung findet, orientiert sich an der Struktur, welche der zu edierende Textes vorgibt.2 Ausnahmen hiervon entstehen zwangsläufig bei Inhalten von komplexer Struktur und an denjenigen Stellen, an denen, bedingt durch das Schema, ein <div> oder <p> erforderlich ist wie z. B. als Wrapper-Element für <address>.3

Einzüge werden abstrakt behandelt, d.h. ihre Breite wird in relativen Einheiten erfasst. Bei Typoskripten kann die Ausdehnung auch als Anzahl von Zeichen angegeben werden.

<closer>
   <space unit='indent' quantity='2'></space>
   <salute>love</salute>
   <lb></lb>
   <handShift script='manuscript'></handShift>
   <signed>
      <space unit='indent' quantity='3'></space>
      <persName key='A00006DC'>
         <hi rend='underline'>Wystan</hi>
      </persName>
   </signed>
</closer>

(Beispiel aus A0402725)

Listen und Tabellen

Listen werden den Regeln der TEI folgend als <list> codiert, Tabellen als <table>. Beides erfolgt ohne projektspezifische Anpassung. Wann für eine Auflistung eine Liste und wann eine Tabelle verwendet wird, hängt vom jeweiligen zu beschreibenden Text und dessen optischer Erscheinung ab. Grundsätzlich kann festgehalten werden, dass Aufzählungen als Listen codiert werden, sofern nicht eine streng schematische Liste mit mehreren wiederholenden Parametern (Tabelle mit Spalten) vorliegt. Der Fokus bei der Codierung liegt nicht auf der visuellen Realisation. Ziel ist es eine Repräsentationsform zu finden, die dem Inhalt adäquat ist. Sofern diese beiden Aspekte stark divergieren, ist der entsprechende Fall in einer Anmerkung dokumentiert.

Für Listen gilt: Sind die einzelnen Listenpunkte gezählt, wird die Liste als geordnet typisiert (<list type="ordered">). Werden nicht-numerische Aufzählungszeichen verwendet, gilt die Liste als unsortiert (<list type="unordered">). Im Falle, dass keine Aufzählungszeichen die Liste kenntlich machen, wird die Liste nicht typisiert.

Lyrik im Text

Die Auszeichnung lyrischer Passagen (eingefügte Verse oder Gedichte) erfolgt jeweils durch einen eigenen Abschnitt (<p>). Darin sind Strophen (<lg>) und Verse (<l>) der Vorlage folgend strukturiert. Ausnahmen hiervon sind in einer entsprechenden Anmerkung dokumentiert.

Postalische Dokumente

In der digitalen Briefedition werden die postalischen Dokumente der ausgewählten Korrespondenzen – also Briefe und Gegenbriefe – wiedergegeben. Es handelt sich dabei um verschiedene Dokumenttypen wie Briefe (zum Teil mit Umschlag), Post- und Briefkarten sowie Telegramme, die unterschiedliche Anforderungen an das Datenmodell stellen, weshalb diese im Folgenden getrennt behandelt werden.

Briefe (allgemein)

Bei den Briefen sind grundsätzlich zwei Formen zu unterscheiden: Die formell gestalteten Briefe enthalten (meist zu Beginn des Briefes) eine Adresse. Die informelleren Briefe beginnen dagegen in der Regel direkt mit dem Datum und der Anrede. Hier ist anzunehmen, dass die Adresse nur auf dem Umschlag notiert wurde, der aber nicht in jedem Fall überliefert ist.
Die Grobstruktur eines Briefes besteht also ggf. aus der Adresse (<address>), die sich wiederum aus mehreren Adresszeilen (<addrLine>) zusammensetzt,

<address>
   <addrLine>
      <persName key='A001000A'>Ill:mo maestro hans werner henze</persName>
   </addrLine>
   <addrLine>la leprara</addrLine>
   <addrLine>
      <settlement key='A13020B0'>marino (roma)</settlement>
   </addrLine>
   <addrLine rend='right'>
      <country>italia</country>
      <hi rend='underline'>par avion</hi>
   </addrLine>
</address>

(Beispiel aus A040C8D9)

einem zu Beginn stehenden <opener>, der z. B. aus einer Datumszeile (<dateline>) und oder einer oder mehreren Anredezeilen bestehen kann. Komplementär zur Eröffnung ist ggf. eine Abschlusssektion (<closer>) mit Grußfloskel (<salute>), ggf. mit Unterschrift (<signed>), vorhanden, die das Ende des Briefes bildet. Dazwischen steht der eigentliche Brieftext.

Die einzelnen Abschnitte (Absätze/Paragraphen) des Briefes werden mit <p> gekennzeichnet. In der Regel bestehen die Briefe aus einer Einheit, die insgesamt durch das Element <text> strukturell verankert ist. Der Wert des Attributs @type klassifiziert die Art des Textes; bspw. <text type="letter">.

Beginn und Ende der Abschlusssektion <closer> sollten nicht nach der räumlichen Anordnung auf dem Papier (also nach typographischen Gesichtspunkten), sondern nach inhaltlichen Kriterien (wirklicher Beschluss des Briefes) festgelegt werden: Sie beginnt also nicht mitten in einem Satz, sondern umfasst den ganzen Satz (oder mehrere Sätze) bzw. einen Absatz einschließlich der Unterschrift. Zusätzlich zu der Auszeichnung als <closer> wird die graphische Anordnung im wesentlichen codiert, indem Einrückungen mit <space> Elementen nicht exakt, aber in der Proportion zum Haupttext beschrieben werden. (Zu Einzügen vgl. auch Grundstruktur des Textes)

Schließt die Grußformel direkt in der laufenden Zeile eines Textes an, lässt sich eine Absatzbildung des <closer> durch das Attribut @rend mit dem Wert "inline" (<closer rend="inline">) verhindern.
Nachschriften am Ende des Briefes (also nach dem <closer> ggf. mit Unterschriftsformel) können, wenn es sich um kürzere Zusätze handelt, innerhalb eines <postscript>-Elements erscheinen oder – falls eine längere bzw. stärker strukturierte Nachschrift vorliegt – in ein weiteres <p> Element eingeschlossen werden.

<text type='letter'>
   <body>
      <div>
         <p>
            <address>[...]</address>
         </p>
         <opener>
            <dateline rend='right'>
               <settlement>berlin</settlement>
               <date when='1968-09-05'>5. 9. 68</date>
               <lb></lb>
            </dateline>
            <salute> lieber 
               <persName key='A001000A'>hans</persName>
            </salute>
         </opener>
         <p></p>
         <closer>
            <foreign xml:lang='es'>¡abrazos y abrazos!</foreign>
            <space unit='chars' quantity='10'></space>
            <persName key='A0002EA0'>mang</persName>.
         </closer>
         <postscript>
            <p>P.S. ist 
               <persName>orsini</persName> nun definitiv aus dem spiel? hoffen wirs!
											
               <lb></lb> aber man müßte sich dessen versichern; mit ihm ist
											
               <lb></lb> die 
               <rs type='work'>oper</rs>
               <hi rend='underline'>nicht zu machen</hi>
            </p>
         </postscript>
      </div>
   </body>
</text>

(Beispiel aus A040C8A0)

Enthält ein Brief einen Umschlag oder Beilagen, so werden diese separat erfasst (siehe Umschläge bzw. Schriftstücke). Der Verweis ist obligatorisch:

<sourceDesc>
   <msDesc>
      <msIdentifier></msIdentifier>
      <physDesc></physDesc>
   </msDesc>
   <listRelation>
      <relation name='hasEnclosure' key='{DocumentId}'></relation>
   </listRelation>
</sourceDesc>

Ist ein Brief nur durch einen Durchschlag überliefert, so wird dies in der <supportDesc> angegeben.

<supportDesc>
   <support>
      <material function='copy.carbon'>Durchschlagpapier (nicht gefaltet)</material>
   </support>
</supportDesc>

(Beispiel aus A040C872)

Briefe (auf Briefpapier)

In den überwiegenden Fällen sind die Briefe auf einem blanko Papier geschrieben, doch kommt es auch vor, dass Briefe auf eigenem Briefpapier mit aufgedrucktem Namen und/oder Adresse oder bspw. auf Hotel-Briefpapier geschrieben werden. In diesen Fällen müssen die vorgedruckten Elemente über das Element <fw> (forme work) erfasst werden.

<div>
   <fw>
      <hi rend='capital'>La Leprara</hi>
      <lb></lb> 00047 
      <hi rend='capital'>Marino</hi> (
      <hi rend='capital'>Roma</hi>)
   </fw>
   <opener>
      <dateline>
         <date when-custom='0000-06-06'>6 Juni</date>
      </dateline>
      <salute>
         <foreign xml:lang='es'>Querido</foreign>
         <persName key='A0002EA0'>Mang</persName>,
							
      </salute>
   </opener>
</div>

(Beispiel aus A040C9CB)

Nach demselben Prinzip ist mit vorgedruckten Kopf- und Fußzeilen zu verfahren. Auf die Verwendung von gedrucktem Briefpapier wird in der Quellenbeschreibung (<physDesc>) verwiesen.

Karten/Postkarten

Bei Karten sind folgende Typen zu unterscheiden: Sogenannte Briefkarten, also Faltkarten mit Motiv, werden für gewöhnlich in einem Umschlag verschickt und enthalten daher keine Adress- oder Absenderangaben; daher werden diese wie Briefe behandelt. Die Tatsache, dass es sich um eine Briefkarte handelt, wird in der <physDesc> beschrieben. Ggf. vorhandene Bildmotive werden mit <figureDesc> beschrieben.

Als Postkarten sind die sogenannten Ansichtskarten anzusehen, die zum sofortigen postalischen Versand gedacht sind, sowie die Postkarte (ohne Bild).

Die von der Post vertriebene Karte (Postkarte, z.T. mit vorgedruckter Briefmarke), die direkt zum Versand vorgesehen ist, enthält zahlreiche vorgedruckte Angaben, die mit <fw> erfasst sind (vgl. Adressen), die aufgedruckten Briefmarken eingeschlossen. Da der Absenderbereich bei solchen Postkarten nur die halbe linke Seite einnimmt, entsteht hier freier Platz, der häufig noch für den Briefschluss, andere Notizen oder auch Bilder genutzt wird. Absender und Adressfeld werden mit Angabe der vorgedruckten Informationen (<fw>) wiedergegeben. Der üblichen Leserichtung (links nach rechts) folgend, wird zuerst der Absender und dann der Empfänger wiedergegeben.

Zur Erfassung der Struktur (Bereiche auf der Karte) siehe .

„Die Vorderseite der Postkarte ist die Adressseite. Diese Definition gilt für deutsche philatelistische und philokartistische Fachsprache für alle Arten der Postkarten, auch für Ansichtskarten.“ (Zitat siehe Artikel „Postkarte“ in Wikipedia (letzter Abruf 5. Juni 2023), vgl. auch den Eintrag auf Philawiki.ch.

<div type='row'>
   <div>
      <p>
         <address type='sender'>
            <addrLine>
               <fw>Absender:
										
                  <lb></lb> (Vor- und Zuname)
               </fw>Henze
            </addrLine>
            <addrLine>17a</addrLine>
            <addrLine>Heidelberg</addrLine>
            <fw rend='center'>Wohnort, auch Zustell- oder Leitpostamt</fw>
            <addrLine>Rohrbacher Str. 40 V</addrLine>
            <fw rend='center'>Straße, Hausnummer, Gebäudeteil, Stockwerk oder Postschließfachnummer;
										
               <lb></lb> bei Untermietern auch Name des Vermieters
            </fw>
         </address>
      </p>
   </div>
   <div>
      <p>
         <address type='receiver'>
            <fw rend='left'>Postkarte</fw>
            <fw rend='right'>Briefmarke</fw>
            <stamp>Rundstempel: Heidelberg
										
               <lb></lb>29.6.49
										
               <lb></lb>-17
										
               <lb></lb>an
            </stamp>
            <addrLine>Dr. Walter Jockisch</addrLine>
            <addrLine>EGERN am Tegernsee</addrLine>
            <addrLine>Fürstenstrasse</addrLine>
            <fw rend='center'>Straße, Hausnummer, Gebäudeteil, Stockwerk oder Postschließfachnummer;
										
               <lb></lb> bei Untermietern auch Name des Vermieters
            </fw>
         </address>
      </p>
   </div>
</div>

(Beispiel aus A0428840)

Es folgt dann der Brieftext der Rückseite. Da dieses Medium in der Regel nur die eine Seite umfasst, zeigt ein <pb> in diesem Fall den Beginn der Rückseite an <pb n="verso">. Im übrigen folgt die Codierung des Textes den Regeln für Briefe.

Telegramme4

Die Erfassung von Telegrammen in TEI soll zusätzlich zum Inhalt auch die Formular-Struktur des Mediums abbilden, um diesem Medium im Ganzen gerecht zu werden. Hierzu wird ein eigenes Datenmodell erarbeitet, welches sich derzeit noch in der Entwicklung befindet. Daher wird bisher primär der Inhalt erfasst und aufbereitet.

Der Modellansatz für die Erschließung der Formular-Struktur ist am Bootstrap-Framework orientiert, das Bereiche mit <div>s organisiert. Zur Nutzung dieser Technik wurde die TEI-Definition von <div> für Henze-Digital erweitert: „(text division) contains a subdivision of the front, body, or back of a text or is used to represent the structure of the text for special documents (e.g., postcards, telegrams)“.

Analog zum Bootstrap-Framework wird jeweils ein <div> als Wrapper für eine Zeile verwendet. Die Kind-Elemente – in diesem Fall ist <div> obligatorisch – stellen dann Bereiche in einer Zeile (Spalten) dar.

<div type='row'>
   <div></div>
   <div></div>
</div>

Werden in den <div>-Elementen innerhalb von <div type="row"> keine weiteren Spezifikationen angegeben, so bedeuted dies eine gleichmäßige Verteilung bzw. gleichmäßige horizontale Ausdehnung der Bereiche. Ungleichgroße Bereiche können durch die Werte "col-1" bis "col-11" spezifiziert werden, wobei die Summe 12 (analog zu Bootstrap) nicht überschreiten darf.

Eine Zeile mit zwei Bereichen im Verhältnis 1:2 (1/3 der Gesamtbreite + 2/3 der Gesamtbreite) kann wie folgt codiert werden:

<div type='row'>
   <div type='col-4'></div>
   <div type='col-8'></div>
</div>

Werden nur einzelne Bereiche in ihrer horizontalen Ausdehnung spezifiziert, so sind alle anderen Bereiche als gleichmäßig verteilt (bezogen auf den zur Verfügung stehenden Platz) zu verstehen.

<div type='row'>
   <div type='col-2'></div>
   <div type='col'></div>
   <div type='col'></div>
</div>

Der Wrapper <div type="row"> kann in jedem Bereich verwendet werden, außer in sich selbst. Auf diese Weise lassen sich auch komplexe Formularstrukturen erfassen und mit Hilfe des Bootstrap-Framework darstellen.

Vorgedruckte Formular-Texte werden mit <fw> ausgezeichnet. Für die Codierung von Positionsangaben ist ein Modell zu erarbeiten.

Umschläge

Die Überlieferung des zum postalischen Dokument gehörigen Umschlags ist nicht häufig, aber in jedem Fall zu berücksichtigen. Gelegentlich kommt es vor, dass ausschließlich ein Umschlag überliefert ist. Der Umschlag wird als eigener Datensatz angelegt und mit dem zugehörigen postalischen Dokument verlinkt.

<sourceDesc>
   <msDesc>
      <msIdentifier></msIdentifier>
      <physDesc></physDesc>
   </msDesc>
   <listRelation>
      <relation name='isEnvelopeOf' key='{LetterId}'></relation>
   </listRelation>
</sourceDesc>

Die Adressseite wird als Vorderseite und die Absenderseite als Rückseite, eingeleitet mit <pb n="verso">, erfasst. (Vgl. auch Karten/Postkarten)

<text type='Umschlag'>
   <body>
      <div>
         <p>
            <address>
               <addrLine>Air Mail / Par Avion </addrLine>
               <addrLine>StempeL. Par Avion</addrLine>
               <addrLine>Herr Hans Werner Henze</addrLine>
               <addrLine>La Leprara</addrLine>
               <addrLine>Marino (Roma)</addrLine>
               <addrLine>Italia</addrLine>
            </address>
         </p>
         <pb n='verso'></pb>
         <p>
            <address>
               <addrLine rend='center'>H.M.E. c/o Casa de las Américas</addrLine>
               <addrLine rend='center'>G y Tercera, Vedado</addrLine>
               <addrLine rend='center'>La Habana</addrLine>
            </address>
         </p>
      </div>
   </body>
</text>

(Beispiel aus A040C883)

Als zusätzliche Elemente finden sich auf Umschlägen oft vorgedruckte Texte und vor allem Briefmarken und Stempel – in den 1950er Jahren sowohl Ausgangs- als auch Eingangsstempel. Die vorgedruckten Elemente werden – wie im Abschnitt zu den Briefpapieren beschrieben – in <fw> wiedergegeben. Mit der Codierung dieser Aspekte befasst sich der Abschnitt zu Stempel und Briefmarken.

<text type='envelope'>
   <body>
      <div>
         <p>
            <fw>
               <hi rend='spaced_out'>Center for Advanced Studies</hi>
               <lb></lb>
               <hi rend='capital'>Wesleyan University . Middletown . Connecticut</hi> 06457
            </fw>
         </p>
         <p>
            <foreign xml:lang='es'>companero</foreign> hans werner henze
            <space unit='chars' quantity='3'></space>la leprara
            <space unit='chars' quantity='3'></space>marino (roma)
            <space unit='chars' quantity='3'></space>italia 
								
         </p>
         <pb></pb>
         <p>
            <stamp type='rundstempel'>Poste Roma - Arrivi E distribuzione [darin:] 14 - 15
               <lb></lb> 25 -1
               <lb></lb> 1968
            </stamp>
         </p>
      </div>
   </body>
</text>

(Beispiel aus A040C885)

Stempel/Briefmarken

Die Codierung von Stempeln und Briefmarken befindet sich im Entwicklungsstadium. Bisher werden vor allem die Inhalte der Stempel als Text wiedergegeben. Informationen zu den Briefmarken finden sich in der <physDesc>. Zum Problem der Codierung dieser Bestandteile der postalischen Dokumente vgl. TEI Guidelines. Vgl. auch Obert, Dewi Josephine/Trautmann, Marjam: Postage stamps, seals, and postmarks, https://web.archive.org/web/20230213065004/https://encoding-correspondence.bbaw.de/v1/stamps-seals-postmarks.html

Schriftstücke

Weitere Dokumente, die im Zusammenhang mit der Korrespondenz überliefert sind, das sind in der Regel Beilagen zu Briefen wie Aufstellungen, Listen, Rechnungen, Zeitschriftenartikel etc., werden einzeln erfasst. Sind die Dokumente eindeutig als Beilage eines Briefes nachzuweisen, so werden diese mit dem entsprechenden Brief verlinkt:5

<sourceDesc>
   <msDesc>
      <msIdentifier></msIdentifier>
      <physDesc></physDesc>
   </msDesc>
   <listRelation>
      <relation name='isEnclosureOf' key='{LetterId}'></relation>
   </listRelation>
</sourceDesc>

Übersetzungen

Übersetzungen von postalischen Dokumenten werden angefertigt, wenn die Dokumente in einer anderen Sprache als deutsch oder englisch vorliegen. Bisher betrifft dies vor allem Dokumente in spanischer oder französischer Sprache. Die Übersetzungen werden mit demselben Schema erfasst wie das Originaldokuemnt, sie erhalten aber nur minimale Metadaten, in denen vor allem auf das Original-Dokument verwiesen wird.

<sourceDesc>
   <msDesc>
      <msIdentifier>
         <repository>Henze-Digital</repository>
      </msIdentifier>
   </msDesc>
   <listRelation>
      <relation key='A04037E7' name='isTranslation'></relation>
   </listRelation>
</sourceDesc>

(Beispiel aus A140065B)

In den Übersetzungen werden lediglich Personen, Institutionen und Orte ausgezeichnet. Anmerkungen zur Textkonstitution und Zeilenkommentare bleiben dem Original vorbehalten.

Dokumenttypen II (Katalogdatensätze)

Personen

Personen-Datensätze enthalten innerhalb des Root-Elements <person> die grundlegenden Angaben zur jeweiligen Person: Familienname <surname>, Vorname <forename> und ggf. Namenszusätze wie z. B. „von“ <nameLink> sowie <roleName>. Dabei gibt es eine reguläre Ansetzungform <persName type="reg">, es können aber auch Alternativnamen erfasst werden <persName type="alt">, näher spezifiziert durch das Attribut @subtype, welches beispielsweise Angaben zu Taufnamen oder Namensänderungen durch Heirat usw. beschreibt: <persName type="alt" subtype="married">.

Weitere Bestandteile von Personendokumenten sind Geburtsdaten

<birth>
   <date when='1926-07-01'></date>
   <settlement key='A13014E4'>Gütersloh</settlement>
</birth>

(Beispiel aus A001000A)

und Sterbedaten

<death>
   <date when='2012-10-27'></date>
   <settlement>Dresden</settlement>
</death>

(Beispiel aus A001028C)

sowie Angaben zu Geschlecht <sex>, zu Beruf <occupation> und ggf. zu Wohnorten <residence>. Auf Grund der Verknüpfung mit den Normdaten und die Anzeige dieser (und weiterer durch diese Angabe bereit gestellter Dokumente) in der HenDi-WebApp werden für Personen nur diese Rahmendaten erfasst. Zusätzliche Informationen werden in den Personendatensätzen nur erfasst, wenn sie im Rahmen von Henze-Digital wünschenswert/notwendig sind, da sich diese nicht aus den Normdaten herleiten lassen, keine Normdaten existieren oder sie von diesen abweichen. Diese Informationen werden in einer <note type="bioSummary"> erfasst.

Ist eine Person innerhalb einer Organisation tätig oder tätig gewesen, so wird diese Beziehung mit <affiliation> angegeben. <affiliation key="{OrgId}">. Handelt es sich um eine zeitlich begrenzte Tätigkeit, deren Dauer für die Edition relevant ist, so kann dieser Zeitraum mit den Attributen @from und @to angegeben werden.

Bei biblischen und mythologischen Personen wird der Datensatz verschlankt auf die Angabe des Namens innerhalb des Elements <persName>. Die Auszeichnung innerhalb der Briefe klassifiziert diese als biblische oder mythologische Figur.

<person>
   <persName>Orpheus</persName>
   <occupation>Sänger</occupation>
   <occupation>Dichter</occupation>
   <sex>m</sex>
   <note>mythologische Figur</note>
</person>

(Beispiel aus A001148F)

Werke

Dieser Datentyp ist äußerst komplex, da musikalische und literarische Werke auf unterschiedliche Weisen erfasst werden müssen. Für die musikalischen Werke finden die Kodierungsempfehlungen der Music Encoding Initiative (MEI) Anwendung; für literarische Werke die der Text Encoding Initiative (TEI). Aus diesem Grund werden die beiden Untergruppen dieses Dokumententyps im Folgenden separat besprochen. Beide Werkgruppen sind noch im Aufbau und werden im Laufe des Projektes weiter differenziert.

Musikalische Werke (MEI)

Bei den musikalischen Werken wird in der Erfassungstiefe zwischen den Werken Hans Werner Henzes und denen anderer Komponisten unterschieden. Allen gemeinsam ist die Angabe von Titel, Komponist ggf. weiterer beteiligter Personen und Entstehungsjahr und/oder Uraufführungsdatum. Wenn vorhanden wird ein Verweis auf Normdaten ergänzt.

Beie den Werken von Hans Werner Henze werden darüber hinaus Angaben zur Besetzung, zu Aufführungen und zu Versionen erfasst. Diese Dateien befinden sich im Aufbau.

Werke, die an AV-Medien gebunden sind, werden analog zu den musikalischen Werken mit MEI erfasst und entsprechend klassifiziert.

Literarische Werke (TEI)

Die literarischen Werke, hierbei ist es unerheblich von wem das Werk stammt, werden als TEI-Dokumente erfasst. Auch wenn hierfür zunächst nur der <teiHeader>, also die Metadaten relevant sind, so besteht die Möglichkeit später den Inhalte des verzeichneten Werkes hinzuzufügen.

Verzeichnet werden die Werke mittels eines <biblStruct> Elements. Auf Grund der starken Restriktion dieses Elementes, z. B. die starke Fixierung auf eine Publikation, die u. a. für Theaterstücke nicht günstig ist, werden die Erfassungsmöglichkeiten im Laufe des Projektes noch erweitert.

<biblStruct type='book'>
   <monogr>
      <title>Les amitiés particulières</title>
      <title xml:lang='de'>Heimliche Freundschaften</title>
      <author key='A0010785'>Peyrefitte, Roger</author>
      <imprint>
         <date when='1944'>1944</date>
         <pubPlace></pubPlace>
         <publisher></publisher>
      </imprint>
   </monogr>
</biblStruct>

(Beispiel aus A0201319)

Im vorangehenden Beispiel wurde zusätzlich ein übersetzter Titel angegeben. Der erste Titel ist stets als originär zu betrachten und lediglich die u. U. folgenden Titel bedürfen das @xml:lang Attribut, um anzugeben in welche Sprache der originäre Titel übersetzt wurde.

Die Sprache(n), in der/denen das Werk selbst verfasst ist, werden über die <langUsage> angegeben.

<langUsage>
   <language ident='fr'></language>
</langUsage>

(Beispiel aus A0201319)

Es kommt immer wieder vor, dass Texte übersetzt werden. Da Übersetzungen auch in mehrere Sprachen angefertigt werden können, ist es überaus wichtig, neben den Übersetzern auch die Sprache zu erfassen, in die der Text übersetzt wurde. Dies geschieht über das Attribut @label, das den im Projekt verwendeten Sprachcode enthält.

<monogr>
   <title level='m'>The Rise and Fall of the City of Mahagonny</title>
   <author key='A00110DF'>Brecht, Bertolt</author>
   <editor role='trl' label='en' key='A00006DC'>Wystan Hugh Auden </editor>
   <editor role='trl' label='en' key='A0005702'>Chester Kallman</editor>
</monogr>

(Beispiel aus A02014EA)

Bildnerische Werke (TEI)

Die Erfassung von bildnerischen Werken (z. B. Gemälden), erfolgt analog zu den literarischen Werken. Im Unterschied zu literarischen werken wird in <biblStruct> der @type "painting" angegeben. Zudem ist der <author> mit einer @role ("art" = Artist/Künstler*in) zu versehen.

Orte

Referenzdatensätze zu Orten werden einzeln angelegt, dabei ist es nicht von Belang, ob es sich um ein Land, eine Stadt oder z. B. ein Gebirge handelt, jeder identifizierbare Ort wird durch einen eigenen Datensatz repräsentiert. Als Normdatenbank wird primär GeoNames verwendet. GeoNames stellt eine äußerst umfangreiche Datensammlung bereit, die neben Städten auch Örtlichkeiten, wie Schlösser, öffentliche Gebäude u.a. enthält; zudem sind die Datensätze von GeoNames hierarchisch organisiert (bspw. Kontinent, Land, Region, Stadt).

Das Datenmodell für Orte ist von einfacher Struktur.

<place xml:id='A13025E2' source='HenDi'>
   <idno type='geonames'>5128581</idno>
   <placeName type='reg'>New York</placeName>
   <placeName type='alt'>New York City</placeName>
</place>

(Beispiel aus A13025E2)

Für den Fall, dass ein Ort nicht in der GeoNames-Datenbank verfügbar ist, können ggf. die Koordinaten ermittelt und im Datensatz nach folgendem Schema hinterlegt.

<place xml:id='A130109C' source='HenDi'>
   <placeName type='reg'>Falkenmühle</placeName>
   <location>
      <geo>49.0957712 7.8051705</geo>
   </location>
</place>

(Beispiel aus A130109C)

Organisationen/Institutionen

Bei Referenzsdatensätzen zu Organisationen werden neben den Normdaten vorwiegend Name und Ort erfasst. Die Art der Orgnaisation (z. B. Verlag, Theater, Rundfunkanstalt) wird durch das Element <state> wiedergegeben. Das Schema sieht eine geschlossene Liste für die Klassifizierung vor (hendi.orgType.list). Die verwendung mehrerer <term>-Elemente ist zulässig. Literaturangaben bzw. Links sind in <listBibl> möglich.


                                                    
                                                        2061014-2Bayerisches Staatstheater am GärtnerplatzMünchenDeutschland
                                                        
                                                            
                                                                organizer
                                                                theater
                                                            
                                                        
                                                        
                                                            http://www.staatstheater-am-gaertnerplatz.de/public
                                                        
                                                    

(Beispiel aus A08003E0)

Unterorganisationen wie Abteilungen, Projektgruppen und organisationshierarchische Untersektionen werden als eigene Organisation erfasst. Dies gilt auch für Firmen bei Namenswechsel. Die Zuweisung zum Übergeordneten Datensatz erfolgt mittels <relation>:

<listOrg>
   <relation name='isAssociatedWith' key='{OrgId}'></relation>
</listOrg>

Rollen und Charaktere

Erwähnte Rollen aus dramatischen Werken oder Charakteren in Prosawerken oder Lyrik werden im Brieftext ausgezeichnet – <name type="role"> bzw. <name type="character"> – ein Register für diese Namen ist jedoch noch in Diskussion.

Literatur/Schriften

In dieser Kategorie werden Bibliographika erfasst, die als Sekundär-, Sachliteratur oder Schriften bezeichnet werden können. Texten mit literarischer Qualität sind als Werke erfasst.

Die Datensätze zu den Bibliographika bestehen aus einem <biblStruct>-Element, mit dessen Hilfe Informationen zu den Autor*innen (<author>) und zum Titel (<title>) hinterlegt werden können. Mittels <analytic> werden unselbstständige Publikationen erfasst. Das Element <monogr> verzeichnet eigenständige Publikationen oder dokumentiert Angaben zum Veröffentlichungsort durch die Elemente <imprint>, <biblScope>, <date>, <pubPlace> etc.

Bei den selbstständigen Publikationen besteht die Möglichkeit zur umfassenden Datenerfassung,

<biblStruct>
   <monogr>
      <title></title>
      <imprint>
         <pubPlace></pubPlace>
         <date></date>
      </imprint>
   </monogr>
</biblStruct>

während bei unselbstständigen Publikationen nur diejenigen Daten erfasst werden, die im übergeordneten Datensatz nicht enthalten sind. Hierzu zählen u. a. Seitenzahlen. Das Attribut @sameAs im Element <monogr> verweist auf die selbstständige Publikation, in welcher der erfasste Artikel publiziert wurde.

<biblStruct type='article' xml:id='A1100BF8' status='approved' source='HenDi'>
   <analytic>
      <title level='a'>Il poeta e la sua elegia del desiderio inappagato</title>
      <author key='A0003CFE' role='aut'>Marsico, Federica</author>
   </analytic>
   <monogr sameAs='A11001F3'>
      <biblScope unit='pp' from='11' to='30'>11-30</biblScope>
   </monogr>
   <note resp='EM' type='commentary'>La Fenice prima dell&apos;opera</note>
</biblStruct>

(Schriften-)Reihen erhalten ebenfalls einen Datensatz, sodass diese direkt referenziert werden können.

<biblStruct>
   <series>
      <title></title>
      <editor></editor>
      <date></date>
   </series>
</biblStruct>

Um selbstständige Publikationen einer Reihe zuzuordnen, wird analog das Attribut @sameAs werdet.

<biblStruct>
   <monogr>
      <title></title>
      <imprint>
         <pubPlace></pubPlace>
         <date></date>
      </imprint>
   </monogr>
   <series sameAs='{SeriesId}'></series>
</biblStruct>

Periodika werden mit dem Element <monogr> erfasst. Hier ist zu beachten, dass ausschließlich allgemeine Informationen zum Periodikum erfasst werden, wie Titel, Herausgebende, Erscheinungszeitraum. Der Katalogdatensatz zu den Periodika ist hier lediglich als Ankerpunkt vorgesehen. Informationen wie Jahrgang, Ausgabe bzw. Ausgabennummer oder Band gehören zur Ebene der Artikeln werden im entsprechenden Datensatz erfasst.

Erfassung von Ereignissen

Das Datenmodell zur Erfassung von Ereignissen befindet sich im Aufbau.

Briefwechsel/Korrespondenz

Um einen korrespondenzbezogenen Zugang zu den postalischen Dokumenten zu ermöglichen, wurde ein eigener Dokumenttyp eingeführt. Dieser dient als Ankerpunkt für Korrespondenzen.

ID-Systematik

Im Projekt Henze-Digital sind die IDs nach einheitlichen Patterns organisisert. Jede ID beginnt mit einem Präfix, welches aus einem führenden ’A’ und zwei Ziffern besteht. Darauf folgt eine vierstellige Hexadezimalzahl, bevor die ID mit einer ebenfalls Prüfziffer (ebenfalls hexadezimal) abschließt. Buchstaben in den IDs von Henze-Digital werden grundsätzlich großgeschrieben. Diese Struktur kann als regulärer Ausdruck dargestellt werden: A\d{2}[0-9A-F]{5}

Präfixe der Dokumenttypen
A00 Personen
A01 derzeit nicht belegt
A02 Werke (musikalisch, literarisch, autoreigen sowie -fremd)
A03 Schriften (Henzes)
A04 Postalische Dokumente (Briefe, Postkarten, Telegramme etc.)
A05 News (Aktuelle Nachrichten aus dem Projekt)
A06 derzeit nicht belegt (WeGA: Tagebücher)
A07 Varia (Impressum, Projektbeschreibung et al.)
A08 Organisationen
A09 Themenkommentare
A10 Dokumente
A11 Bibliographika
A12 derzeit nicht belegt (WeGA: Addenda)
A13 Orte
A14 Übersetzungen
A15 Korrespondenzen
A16–A21 derzeit nicht belegt
A22 derzeit nicht belegt (WeGA: [musikal.] Quellen)

Die Präfixe wurden analog zur Weber-Gesamtausgabe gewählt, um größtmögliche Kompatibilität zur WeGA-WebApp herzustellen. Daher kommt es zu Lücken in der Zählung, die aus unbelegten Präfixen resultieren.

Zur Berechnung der Prüfziffern siehe die constraint-Definition <constraintSpec ident="idCheckDigit">, GitHub-Repository zum ODD, common-specs.odd.xml, die Zeilen 928–976 (hash: 9cde2a7628).

Revisionen

In der <revisionDesc> werden alle Veränderungen an der Datei in einer summarischen Beschreibung festgehalten (dies dient u. a. dazu, die Versionierung der Überarbeitungsstadien inhaltlich besser zuordnen zu können).

Status/Zustand der Datensätze

Mit dem Attribut @status, welches immer im root-Element des jeweiligen Datensatzes zu finden ist, wird der Bearbeitungsstand des Dokuments innerhalb der Veröffentlichungen von Henze-Digital festgehalten. Hierfür sind derzeit drei Stufen vergeben:

proposed Dieser Status gibt an, dass ein Datensatz für eine Veröffentlichung vorgesehen ist, derzeit aber noch in einer unkorrigierten Entwurfsfassung vorliegt. In der Darstellung werden solche Datensätze als „in Bearbeitung“ gekennzeichnet.
candidate Dieser Status gibt an, dass der Datensatz überarbeitet (d. h. angereichert und korrekturgelesen) wurde, jedoch noch nicht entgültig bearbeitet worden ist. Der Datensatz sollte bereits zitierfähig sein. Ist diese Stufe erreicht, wird der Datensatz mit „Kommentar in Bearbeitung“ gekennzeichnet.
approved Für die Veröffentlichung freigeschaltete Datensätze erhalten diesen Status, d. h. dass sie korrekturgelesen, ausgezeichnet und mit den augenblicklich möglichen Anmerkungen versehen sind. Veränderungen der Datei beziehen sich dann in der Regel nur noch auf die Kommentare. Solche Datensätze erhalten den Vermerk „bearbeitet“.

Zum Umgang mit Dubletten

Im Fall der fehlerhaften Verdopplung von Datensätzen werden diese, sofern sie bereits veröffentlicht sind, nicht gelöscht; stattdessen wird eine Referenz gesetzt, die eine Weiterleitung zum korrekten Datensatz ermöglicht. Realisiert wird diese Referenz durch das Element <ref> und dem dort verfügbaren Attribut @target dessen Attributwert die ID der entsprechenden Zieldatei enthält. Zusätzlich wird mit @type="duplicate" dokumentiert, dass es sich beim vorliegenden Datensatz um eine Dublette handelt. Bsp. für eine Dublette bei Personendokumenten:

<person xml:id='A00ID' source='HWH' status='approved'>
   <ref type='duplicate' target='A00ID'></ref>
</person>

(Beispiel aus A00ID)

Einzelnachweise

  1. 1Dieser Datentyp befindet sich derzeit im Aufbau.
  2. 2Zu Zeilenumbrüchen siehe Grundsätze der Textübertragung und -auszeichnung und Trennstriche.
  3. 3Zu den Besonderheiten bzgl. Postkarten und Telegramme siehe Karten/Postkarten bzw. Telegramme.
  4. 4Die Erfassung von Telegrammen in TEI befindet sich noch im Entwickliungsstadium.
  5. 5Der Verweis erfolgt in beide Richtungen. Vgl. auch Briefe (allgemein).

XML

Wenn Ihnen auf dieser Seite ein Fehler oder eine Ungenauigkeit aufgefallen ist,
so bitten wir um eine kurze Nachricht an henze-digital [@] zenmem.de.