Logo heiEDITIONS

Register

Die Registerfunktionalität in ›heiEDITIONS‹ dient besonders zweierlei Zwecken:

Zum Einen wird dadurch eine Annotation von Texten ermöglicht, durch die namentliche oder nicht-namentliche Erwähnungen von Personen, Orten, Körperschaften, Ereignissen, Werken und Sachbegriffen mit einer Verknüpfung zu einem Referenzeintrag versehen werden. Ein solcher Referenzeintrag kann an einer zentralen Stelle Namensformen, Links zu Normdateien und anderen externen Ressourcen, strukturierte Erschließungsinformationen, bibliographische Angaben, Bilder, aber auch kurze beschreibende Texte (wenn sinnvoll, auch mit Bildern) beinhalten. Derartige Textannotationen können immer dann Stellenanmerkungen ersetzen, wenn die erschließende Information zu einer Entität unabhängig von einer Einzelstelle im Text Gültigkeit besitzt und dadurch potenziell viele Textstellen, an denen die betroffene Entität erwähnt wird, erläutern kann. So können etwa wiederholte Erwähnungen eines Ortes in einem Text jeweils durch eine Verknüpfung zu ein und demselben Registereintrag im Ortsregister annotiert werden. In einer Visualisierung des Textes können dann an allen derart annotierten Textstellen die Angaben aus dem Registereintrag angezeigt werden, die dort nur einmal abgelegt wurden.

Zum Anderen können – ähnlich wie bei herkömmlichen Buchregistern – aus annotierten Texten Listen erstellt werden, die jeweils für einen Textabschnitt oder einen ganzen Text die Entitäten auflisten, die im gegebenen Text erwähnt werden, und auch mehr oder weniger genau die Textstellen gesammelt aufzählen, an denen einzelne Entitäten eine Rolle spielen. In einer digitalen Visualisierung können solche Textstellenauflistungen selbstverständlich auch direkte Links zu den jeweiligen Textstellen in der digitalen Edition enthalten.

Der erstgenannte Aspekt macht Register in ›heiEDITIONS‹ potenziell zu einem wissenschaftlichen Produkt an sich, das editionsbegleitend auch Formen eines Personenlexikons, eines geographischen Gazetteers oder eines Sachglossars annehmen kann.

Hinsichtlich der TEI-Kodierung sind zwei verschiedene Bereiche der Anwendung von TEI-Konstrukten zu unterscheiden: Die Anreicherung von Textstellen mit Verknüpfungen zu kanonischen Repräsentationen von Entitäten einerseits und entsprechende kanonische Referenzeinträge, typischerweise in dedizierten eigenständigen Registerdateien, andererseits. Beim Ersteren geht es darum, mit welchen Konstrukten einzelne Textstellen markiert werden können, wenn sie z. B. eine Person oder einen besonderen Begriff nennen; beim Letzteren geht es um die Struktur der Referenzeinträge, auf die von konkreten Textstellen aus verwiesen werden kann.

Auszeichnung für Register im Text

Die Kennzeichnung relevanter Textsegmente mit Verweisen zu Registereinträgen kann sowohl in Primärtexten als auch in Sekundärtexten (editorische Anmerkungen, laufende Kommentare, begleitende oder eigenständige Sekundärtexte) erfolgen.

Die Markierung eines Textsegments (Personenname, Erwähnung eines Ortes, Sachbegriff u. Ä.) als registerrelevant setzt normalerweise voraus, dass eine entsprechende Registerliste mit einem zu verknüpfenden Eintrag existiert oder zeitgleich angelegt wird. Bei einem Verweis von einer Textstelle aus zu einem Normeintrag in einer Registerliste handelt es sich technisch um den Verweis auf die @xml:id eines XML-Elements und damit um den Verweis auf einen URI. In einer Standardsituation in ›heiEDITIONS‹ befinden sich TEI-Dokumente mit edierten Primärtexten (bzw. ›Expressionen‹) in einem Verzeichnis texts, Registerdateien in einem Verzeichnis indexes, wobei die Verzeichnisse texts und indexes auf derselben strukturellen Ebene stehen. Ein Verweis von einer Textstelle aus auf einen Registereintrag müsste also einen Pfad beschreiben, der natursprachlich etwa wie folgt ausgedrückt werden könnte: ›Gehe vom Verzeichnis texts eine Ebene höher, dann ins Verzeichnis indexes und in die Registerdatei AB.xml zum Eintrag mit der @xml:id XY.‹ Technisch würde eine solche Pfadbeschreibung so aussehen: ../indexes/AB.xml#XY.

Da wir in Editionsdateien bei Registerverweisen solche umständlichen und bei manueller Eingabe auch fehleranfälligen Pfadangaben vermeiden wollen, verwenden wir eine abgekürzte Syntax, bei welcher der Pfad zu einer Registerdatei durch ein frei festlegbares Präfix repräsentiert wird. Ein solches Präfix muss in jedem TEI-Dokument für jedes zu verknüpfende Register in <teiHeader> > <encodingDesc> > <listPrefixDef> deklariert werden, ähnlich wie an derselben Stelle in jeder TEI-Datei von ›heiEDITIONS‹ auch das Präfix hc deklariert wird.

Eine typische Deklaration eines Präfixes pers als Repräsentation des Pfades zur Registerdatei mit einer Personenliste würde wie folgt aussehen:

                
            

Wenn die namentliche Erwähnung einer Person an einer edierten Textstelle als Registerverknüpfung ausgezeichnet wird, kommt am Element <persName> im Attribut @ref dann die abgekürzte Syntax für den URI-Verweis in der Form [Präfix]:[xml:id] zum Einsatz, konkret z. B.:

                
            

Bei einigen Entitätentypen stehen für die Auszeichung eines Textsegments und dessen Verknüpfung mit einem Registereintrag mehrere Elemente zur Auswahl. Grundsätzlich lässt sich so unterscheiden, ob in einem so auszuzeichnenden Textsegment eine Entität namentlich genannt oder ggf. nur anderweitig erwähnt wird. Für die ggf. nur anderweitige, jedenfalls aber nicht näher spezifizierte Erwähnung steht für alle Registertypen das generische Element <rs> (referencing string) zur Verfügung. Wenn in einem Projekt keine Unterscheidung zwischen namentlichen und sonstigen Erwähnungen von Entitäten für die Registerverknüpfung erwünscht ist, kann auch immer nur das Element <rs> (mit einer Typangabe der betroffenen Entität) verwendet werden, so etwa statt des obigen Beispiels mit <persName>:

                
            

Die Typangabe des Verweises an @ana ist bei <rs> obligatorisch, es sei denn, sie würde gemäß einer projektspezifischen Regelung anhand des verwendeten Präfixes erst während der Verarbeitung maschinell ergänzt.

Wenn Projekte zwischen namentlichen und sonstigen Erwähnungen unterscheiden wollen, sollte <rs> Textstellen vorbehalten bleiben, die eine Entität nicht namentlich nennen, sondern in irgendeiner Weise umschreiben, z. B. ›der große Dichter‹, ›die Tante‹, ›die ewige Stadt‹ u. Ä.

Gerade bei nicht namentlichen Erwähnungen können manchmal an einer Textstelle kollektiv mehr als nur eine Entität referenziert werden. In solchen Fällen können in @ref mehrere URIs angegeben werden, z. B.:

                
            

Gelegentlich können sich aber auch namentliche Nennungen auf mehrere Individuen beziehen,1) die im Register einzelne Einträge haben. Dann können auch an spezifischen Elementen wie <persName> mehrere URIs gesetzt werden, z. B.:

                
            

Ob in solchen Fällen Wörter wie ›Gebrüder‹ als Teil des Namens markiert werden oder nicht, obliegt dem Ermessen des Herausgebers. Alternativ ist bei solchen Phrasen immer auch die Verwendung von <rs> statt eines spezifischeren Elements möglich.

Für die Auszeichung von Entitätenerwähnungen stehen je nach einschlägigem Registertyp diese Elemente zur Verfügung:

  • Auszeichnungen fürs Personenregister: <persName> oder <rs> mit Wert hc:PersonReference in @ana
  • Auszeichnungen fürs Ortsregister: <placeName> oder <rs> mit Wert hc:PlaceReference in @ana
  • Auszeichnungen fürs Körperschaftsregister: <orgName> oder <rs> mit Wert hc:OrganizationReference in @ana
  • Auszeichnungen fürs Ereignisregister: <name> mit Wert hc:EventName in @ana oder <rs> mit Wert hc:EventReference in @ana
  • Auszeichnungen fürs Werkregister: <title> oder <rs> mit Wert hc:WorkReference in @ana
  • Auszeichnungen fürs Sachregister: <term> oder <rs> mit Wert hc:SubjectReference in @ana

Für die Angabe der URI eines Registereintrags (d. h. des Pfades zum Normeintrag einer Entität in einer Registerdatei mittels der @xml:id des Normeintrags) wird in allen genannten Fällen das Attribut @ref verwendet.

Übersicht der genannten Klassen:

hc:PersonReference ( ›Verweis auf Person‹ ): Namentlicher oder sonstiger verbaler Verweis auf eine oder mehrere Personen.

hc:PlaceReference ( ›Verweis auf Ort‹ ):

hc:OrganizationReference ( ›Verweis auf Organisation‹ ):

hc:EventName ( ›Ereignisname‹ ): Benennung eines Ereignisses, die als Eigenname fungiert.

hc:EventReference ( ›Verweis auf Ereignis‹ ): Namentlicher oder sonstiger verbaler Verweis auf ein Ereignis (oder ggf. mehrere Ereignisse).

hc:WorkReference ( ›Verweis auf Werk‹ ): Verweis auf ein Werk (unter Nennung des Werktitels oder nicht), mit einer möglichen Verwendung für die Aufnahme ins Werkregister.

hc:SubjectReference ( ›Verweis auf Sache‹ ): Verweis auf eine Sache, typischerweise ein Konzept, ein Thema oder einen Begriff, mit einer möglichen Verwendung für die Aufnahme ins Sachregister.

Registerlisten

Registerlisten sind das Mittel, um Referenzeinträge für Entitäten eines bestimmten Typs zu verwalten, auf die aus einem Text heraus verwiesen werden kann. Die Einträge solcher Listen können unterschiedlichen Umfangs sein. In einer Minimalform kann ein Registereintrag allein aus einem Identifikator und einer Ansetzungsform bestehen, wobei selbst die Ansetzungsform noch aus einer externen Quelle, etwa einer Normdatei wie der GND, automatisiert übernommen werden könnte.2) Im Gegensatz dazu können Registereinträge auch zu umfassenden wissenschaftlichen Produkten werden und neben einer Reihe datenbankartig strukturierter Informationen auch einen Prosaabschnitt enthalten, der auch die Form einer kleinen eigenständigen Abhandlung annehmen kann. Links zu externen Internetquellen sowie Bibliographielisten können ebenfalls Teil eines Registereintrags sein.

In Anlehnung an einige von der TEI (allerdings nicht nur für Registerzwecke) bereits vorgesehene Listentypen und ausgehend vom bisherigen Bedarf hauseigener Projekte definiert ›heiEDITIONS‹ folgende Typen von Registerlisten:

  • Personenregister
  • Ortsregister
  • Körperschaftsregister
  • Ereignisregister
  • Werkregister
  • Sachregister

Als eine Sonderart, die als Liste von Referenzeinträgen viele Gemeinsamkeiten mit Registern im eigentlichen Sinne hat, ist die Bibliographie zu betrachten.

Register zu führen und entsprechende Auszeichnungen in Texten vorzunehmen, ist in ›heiEDITIONS‹ keine Pflicht. Von den vorgesehenen Registertypen können auch nur einige wenige geführt werden. Es steht einem Herausgeber aber andererseits auch frei, für sein Projekt bei Bedarf mehrere unterschiedlichen Register desselben Typs anzulegen, wenn es als sinnvoll erscheint, die darin zu verwaltenden Entitäten als separate Kategorien zu betrachten. Beispielsweise ist es möglich, für verschiedene thematische Kategorien mehrere Sachregister zu führen.

Jedes Register ist in einer eigenen, nur dafür vorgesehenen TEI-Datei zu führen. Eine solche TEI-Datei richtet sich formal nach dem ›heiEDITIONS Index Schema‹, einer besonderen Schemaspezifikation für Registerdateien. Das ›heiEDITIONS Index Schema‹ wird im RELAX-NG-Format (mit Schematron-Anreicherungen) unter der URL ↪ https://digi.ub.uni-heidelberg.de/schema/tei/heiEDITIONS/tei_hes_index.rng bereitgestellt.

Unter Beispieldateien sind Beispieldateien für einzelne Registertypen aufgelistet, die als Vorlage beim Anlegen eines eigenen Registers genutzt werden können. Die grobe Struktur des XML-Baumes einer Registerdatei innerhalb des TEI-Wurzelelements ist wie folgt:

                
            

Das Element <text> trägt am Attribut @ana die Angabe, um welchen Registertyp es sich handelt. Entsprechend der obigen Liste von Registertypen ist genau eine dieser Angaben erforderlich:

hc:IndexOfPersons ( ›Personenregister; Personenverzeichnis‹ ): Eine Form des Namensregisters, in dem nur Personen erfasst sind. Einträge in einem Personenregister gruppieren jeweils Informationen über eine Person. Dieser Registertyp darf nicht mit einem Autor-Werk-Register verwechselt werden, das Einträge über Werke enthält.

hc:IndexOfPlaces ( ›Ortsregister; Ortsverzeichnis‹ ): Register, dessen Einträge Informationen über Orte enthalten.

hc:IndexOfOrganizations ( ›Körperschaftsregister‹ ): Register, dessen Einträge Informationen über Körperschaften, also identifizierbare Personengruppen mit einer eigenen Identität, enthalten.

hc:IndexOfEvents ( ›Ereignisregister‹ ): Register, dessen Einträge Informationen über Ereignisse enthalten.

hc:IndexOfWorks ( ›Werkregister; Autoren- und Werkregister‹ ): Register, dessen Einträge Informationen über Werke und ggf. deren Urheber enthalten. Unter Werken sind in erster Linie geistige, immaterielle Schöpfungen zu verstehen, nicht konkrete materielle Gegenstände; dennoch können Einträge dieses Registertyps auch Informationen über entsprechende physische Objekte enthalten.

hc:IndexOfSubjects ( ›Sachregister; Sachverzeichnis; Schlagwortregister; Schlagwortverzeichnis; Begriffsregister; Glossar‹ ): Register, dessen Einträge Informationen zu Sachverhalten enthalten, die keiner namentlich identifizierbaren individuellen Entität entsprechen.

Als einziges Kindelement von <body> kommt dann in Abhängigkeit vom festgelegten Registertyp eines dieser listenartigen Elemente vor:

Jedes der genannten Listenelemente kann zunächst mit <head> eine oder mehrere Überschriften enthalten. Sind mehrere <head>-Elemente gesetzt, müssen sie das Attribut @xml:lang mit jeweils unterschiedlichen Sprachcodes tragen. Ein einziges <head> muss keine Sprachangabe tragen. Die explizite Verwendung von <head> ist besonders dann sinnvoll (und dann auch praktisch unentbehrlich), wenn eine Edition mehrere Register deselben Typs führt. Dann erfolgt die Unterscheidung der Register auch nach dieser Überschrift. Wenn das Element <head> nicht belegt wird, kann für Visualisierungszwecke auf eine in ›heiEDITIONS‹ voreingestellte Überschrift (die Klassenbezeichnung des Registertyps) zurückgegriffen werden.

Nach der optionalen Überschrift enthält die Registerliste eine beliebige Anzahl von Einträgen des jeweiligen Registers. Das Element für die einzelnen Einträge ist innerhalb eines Registers immer gleich und hängt vom jeweiligen Registertyp ab:

Beispiel für die grobe Struktur eines Personenregisters ab dem Element <text>:

                
            

Beispiel für die grobe Struktur eines Werkregisters mit einer spezifischen Überschrift:

                
            

Allgemeine Struktur eines Registereintrags

Jeder Registereintrag richtet sich, unabhängig vom Registertyp, in der allgemeinen Struktur seines Inhalts nach Regeln, die im Folgenden dargelegt sind.

Identifikatoren

Die genannten Elemente <person>, <place>, <org>, <event> und <item>, die jeweils einen Registereintrag und damit eine Entität repräsentieren, müssen immer mit dem Attribut @xml:id versehen werden, dessen Wert als eindeutiger Identifikator innerhalb des Registers dient. Für den Aufbau des Identifikatorwertes gelten diese Regeln:

  • Wenn es für die erfasste Entität eine Entsprechung in der ›Gemeinsamen Normdatei‹ (GND) der Deutschen Nationalbibliothek gibt und diese Verknüpfung zu einem Normdatensatz der GND innerhalb des Registereintrags auch hergestellt wird, setzt sich die @xml:id aus der Zeichenkette gnd- und der GND-Nummer3) des entsprechenden Normdatensatzes zusammen.
  • Andernfalls gilt es, statt der Zeichenkette gnd ein für das konkrete Register festgelegte Präfix (s. weiter oben TODO) und statt der GND-Nummer eine innerhalb des Registers (für nicht mit der GND verknüpfte Einträge) laufende Nummer zu verwenden, Letzteres ggf. in einheitlicher Ziffernanzahl mit vorangestellten Nullen.

Beispiele für das Attribut @xml:id an Registereinträgen in einem Personenregister.

Identifikator einer Ressource mit GND-Verknüpfung:

                
            

Identifikator einer Ressource ohne GND-Verknüpfung in einem Personenregister mit dem Präfix pers und laufender Nummer:

                
            

Identifikator einer Ressource ohne GND-Verknüpfung in einem Personenregister mit dem Präfix pers und laufender Nummer, mit vereinheitlichter Ziffernanzahl:

                
            

Vom obligatorischen Identifikator mittels des Attributs @xml:id abgesehen ist es auch möglich, mit dem Element <idno> einen Fremdidentifikator anzugeben. <idno> sollte jedoch grundsätzlich nicht für die Angabe von URIs oder URLs vergleichbarer Ressourcen verwendet werden, die mit der Registerentität lose in Verbindung stehen (hierfür sind die Elemente <ptr> oder <ref> innerhalb von <listRef> vorgesehen), sondern nur dann, wenn die durch den Fremdidentifikator identifizierte Ressource mit der Registerentität durch eine enge Beziehung der völligen Identität verknüpft werden soll, also wenn die Registerentität und die Fremdressource als identisch gleichgesetzt werden sollen.

Primär ist in ›heiEDITIONS‹ die Verwendung von <idno> für die Gleichsetzung mit Normdatensätzen der GND vorgesehen. Die Liste der unterstützten Normdateien ist aber grundsätzlich erweiterbar. In Ortsregistern und sonstigen Lokalisierungsangaben mithilfe von <location> ist etwa auch die Angabe eines Normdatensatzes von Geonames möglich. In einem Registereintrag darf nur ein <idno> eines Typs vorkommen, d. h. Gleichsetzungen mit mehreren Normdatensätzen derselben Normdatei sind nicht möglich.

Beispiel für die Angabe einer GND-URI als Fremdidentifikator in einem Eintrag des Personenregisters:

                
            

Beispiel eines vollständigen Eintrags des Ortsregisters mit der Angabe einer GND-URI und einer Geonames-URI:

                
            

Namen und Bezeichnungen

Jeder Eintrag in jedem Register trägt eines oder mehrere Elemente, die den Namen, die Bezeichnung oder den Titel4) (dies je nach Registerart) der repräsentierten Entität wiedergeben. Dabei muss es mindestens einen Namen, eine Bezeichnung oder einen Titel geben, der als bevorzugt gilt und für die Anzeige herangezogen wird. Je nach Registerart stellen folgende Elemente jeweils die Benennung (wir verwenden hier und im Folgenden den Begriff ›Benennung‹ als Oberbegriff für den Namen, die Bezeichnung oder den Titel) dar:

Jedes dieser Elemente darf mehrfach gesetzt sein, weil jede Entität mehrere verschiedene Namen, Bezeichnungen oder Titel tragen kann. Die jeweils bevorzugte Benennung muss dabei aber am Attribut @ana der Klasse › hc:PreferredAppellation ‹ (oder einer der spezielleren Unterklassen › hc:AppellationForDisplayInIndex ‹ und › hc:AppellationForDisplayInEdition ‹, dazu s. u.) zugewiesen werden, es sei denn, es gibt überhaupt nur eine Benennung – dann gilt diese implizit auch als bevorzugt.

Es gilt jedoch nicht, dass nur eine Benennung als › hc:PreferredAppellation ‹ gelten dürfte. Zum Einen ist es möglich, Benennungen in verschiedenen Sprachen anzugeben. Wenn mehrere Elemente jeweils unterschiedliche Werte von @xml:lang tragen, dürfen sie alle gleichzeitig als › hc:PreferredAppellation ‹ gekennzeichnet sein.

Zum anderen ist es mit Hinblick auf die Registervisualisierung möglich, für unterschiedliche Darstellungskontexte jeweils unterschiedliche Benennungen als bevorzugt zu markieren. ›heiEDITIONS‹ unterstützt zwei Anzeigemodi, für die eine solche Unterscheidung relevant sein kann:

  • Anzeige in einer sortierten Liste der Einträge eines gesamten Registers
  • Anzeige beim Aufruf einer Registermarkierung einer Textstelle im Editionstext

Da die genannten Visualisierungskontexte jeweils unterschiedliche Formen der Benennungen für die Anzeige erfordern können, ist es möglich, Benennungen am Attribut @ana wie folgt zu kennzeichnen:

Wenn ein Element als › hc:AppellationForDisplayInIndex ‹ oder › hc:AppellationForDisplayInEdition ‹ markiert ist, gilt es dadurch implizit auch als › hc:PreferredAppellation ‹. Eine zusätzliche explizite Markierung als › hc:PreferredAppellation ‹ ist nicht notwendig.

Die Unterscheidung der bevorzugten Benennung für die beiden Anzeigekontexte ist keine Pflicht. Wenn sie nicht vorgenommen wird, wird für die Anzeige durchgehend die eine bevorzugte Benennung in der gewählten Sprache herangezogen.

In einem Anzeigekontext und einer gewählten Sprache muss eine Benennung eindeutig sein. Als › hc:PreferredAppellation ‹ dürfen bei einem Registereintrag also nur so viele Elemente gekennzeichnet sein, wie viele Sprachen unterschieden werden. Wenn zwischen › hc:AppellationForDisplayInIndex ‹ und › hc:AppellationForDisplayInEdition ‹ unterschieden wird, dürfen nur doppelt so viele Benennungen wie unterschiedene Sprachen als bevorzugte Benennung gelten.

Alle Benennungen, die weder als › hc:PreferredAppellation ‹ noch als › hc:AppellationForDisplayInIndex ‹ oder › hc:AppellationForDisplayInEdition ‹ gekennzeichnet sind, gelten als alternative Benennungenen und können als › hc:AlternativeAppellation ‹ an @ana markiert werden. Wenn diese Markierung nicht vorgenommen wird, gilt sie implizit.5)

Das Attribut @ana kann auch genutzt werden, um bestimmte Benennungen nach Bedarf weiter zu klassifizieren, z. B. um einen Personennamen als Spitznamen oder Künstlernamen oder einen Körperschaftsnamen als Akronym auszuweisen.

Wenn bestimmte Benennungen in einer Listenanzeige des Registers als (Synonym-)Einträge den primären, durch die › hc:PreferredAppellation ‹ vertretenen Eintrag replizieren sollen, wenn also in einer Registerliste derselbe Registereintrag unter mehreren ›Lemmata‹ mit ansonsten identischem Inhalt angezeigt werden soll (double posting), wird die Benennung, die als ein solches Synonym-Lemma fungieren soll, an @ana als › hc:AppellationForDoublePosting ‹ gekennzeichnet.6)

Benennungen von Entitäten, die in Registern verwaltet werden, können möglicherweise nur in bestimmten Zeiträumen im Gebrauch gewesen sein. Um eine zeitliche Einschränkung zum Ausdruck zu bringen, ist es möglich, die für Benennungen vorgesehenen Elemente <persName>, <placeName>, <orgName>, <name>, <label> und <title> mit folgenden Attributen zu versehen, die jeweils einen Wert in der Form JJJJ-MM-TT, JJJJ-MM oder JJJJ erwarten:

  • @when gibt ein mehr oder minder genaues Datum an, also einen Zeitpunkt. Wenn dieses Attribut gesetzt ist, darf keines der vier folgenden gleichzeitig verwendet werden.
  • @notBefore bezeichnet (allein oder mit @notAfter) inklusiv einen Bereich möglicher Daten nach dem hiermit angegebenen Datum. In Kombination mit @to gibt es hingegen eine Dauer (mit einem unspezifischen Anfang) an. Es darf nicht zusammen mit @when oder @from verwendet werden.
  • @notAfter bezeichnet (allein oder mit @notBefore) inklusiv einen Bereich möglicher Daten vor dem hiermit angegebenen Datum. In Kombination mit @from gibt es hingegen eine Dauer (mit einem unspezifischen Ende) an. Es darf nicht zusammen mit @when oder @to verwendet werden.
  • @from bezeichnet, ggf. zusammen mit @to oder @notAfter, eine Dauer ab einem Datum.
  • @to bezeichnet, ggf. zusammen mit @from oder @notBefore, eine Dauer bis zu einem Datum.

Die für Benennungen vorgesehenen Elemente <persName>, <placeName>, <orgName>, <label> und <title> können als letztes Kindelement das Element <note> enthalten. Darin sind bei Bedarf weitere unstrukturierte Angaben zu einer Benennung möglich.

Verbale Erläuterungen zu Registereinträgen

Zu jedem beliebigen Registereintrag kann eine verbale Erläuterung oder Beschreibung angegeben werden, die von einer kurzen Notiz bis hin zu einer Quasi-Abhandlung reichen kann. Der gesamte Inhalt dieses Textes befindet sich in einem Element <note>. Wird ein Register mehrsprachig geführt, ist pro Sprache ein Element <note> möglich, das dann mit dem Attribut @xml:lang gekennzeichnet sein muss.

Für nicht weiter strukturierte, kürzere Texte kann das Element <note> direkt den beschreibenden Text enthalten. Alternativ kann der Inhalt von <note> mit de Element <p> in mehrere Absätze strukturiert werden.

Literaturangaben

TODO

Abbildungen

TODO

Informationen zu Personen

Einträge zu Personen in einem Personenregister haben die folgende Struktur in festgelegter Reihenfolge:

  • <persName> (obligatorisch, ggf. mehrfach nach den unter Namen und Bezeichnungen dargelegten Regeln)
  • <idno> (optional, nur einmal pro Typ)
  • <birth> (optional, nur einmal)
  • <death> (optional, nur einmal)
  • <occupation> (optional, ggf. mehrfach)
  • <note> (optional, nur einmal pro Sprache)
  • <listBibl> (optional, nur einmal)
  • <listRef> (optional, nur einmal)
  • <figure> (optional, ggf. mehrfach)

Die personenspezifischen Elemente <birth> und <death> können für strukturierte und maschinenlesbare Datumsangaben die Attribute @when, @notBefore, @notAfter, @from und @to tragen. Für die Verwendung dieser Attribute gelten die oben unter Namen und Bezeichnungen beschriebenen Regeln. Außerdem ist in <birth> und <death> das Element <note> für verbale Angaben möglich.7)

Beispiel für <birth> mit maschinenlesbaren Datumsangaben in Attributen und verbalen Angaben in <note>:

                
            

Beispiel für <death> mit maschinenlesbaren Datumsangaben in Attributen und verbalen Angaben in <note>:

                
            

Mit <occupation> kann der Beruf oder die Art der Tätigkeit einer Person angegeben werden. Für jede solcher Angaben sollte ein eigenes Element <occupation> verwendet werden, das Element ist also wiederholbar. Wenn zum Ausdruck gebracht werden soll, dass eine Tätigkeit nur für einen bestimmten Zeitraum gilt, können die Attribute @when, @notBefore, @notAfter, @from und @to eingesetzt werden. Für die Verwendung dieser Attribute gelten die oben unter Namen und Bezeichnungen beschriebenen Regeln. Eine verbale Nennung oder Beschreibung der Tätigkeit wird in <occupation> mit dessen Kindelement <note> angegeben, dass sich ggf. in mehreren Sprachen wiederholen kann.

Beispiel für die einfache Angabe eines Berufs mit einer maschinenlesbaren Angabe des zutreffenden Zeitraums:

                
            

Informationen zu Orten

Einträge zu Orten in einem Ortsregister haben die folgende Struktur in festgelegter Reihenfolge:

  • <placeName> (obligatorisch, ggf. mehrfach nach den unter Namen und Bezeichnungen dargelegten Regeln)
  • <idno> (optional, nur einmal pro Typ)
  • <location> (optional, ggf. mehrfach)
  • <note> (optional, nur einmal pro Sprache)
  • <listBibl> (optional, nur einmal)
  • <listRef> (optional, nur einmal)
  • <figure> (optional, ggf. mehrfach)

Für eine nähere Verortung der Lage des Ortes ist das Element <location> vorgesehen. Grundsätzlich kann es auf dreierlei Weise verwendet werden: Für eine Beschreibung der Ortslage über die Angabe größerer geopolitischer Verwaltungseinheiten; für eine geographische Lokalisierung mittels geographischer Koordinaten; für eine Ortsangabe anhand einer Adresse. Von den genannten drei Verwendungsarten unterstützt ›heiEDITIONS‹ zur Zeit die ersten beiden.

Das Element <location> kann mehrfach vorkommen. Bei einer Lokalisierung anhand größerer geopolitischer Verwaltungseinheiten kann es etwa sinnvoll sein, mehrere historische Phasen zu unterscheiden. Für jede historische Phase sollte dann ein eigenes Element <location> angelegt werden. Anhand der Attribute @when, @notBefore, @notAfter, @from und @to können an <location> einschränkende Zeitangaben gemacht werden. (Für die Verwendung dieser Attribute gelten die oben unter Namen und Bezeichnungen beschriebenen Regeln.)

Für die Beschreibung einer Ortslage mithilfe der Angabe größerer geopolitischer Verwaltungseinheiten kommen die folgenden Kindelemente von <location> in Frage, angeordnet von der größten zur kleinsten Ebene:

  • <bloc> für länderübergreifende geopolitische Einheiten, z. B. die Europäische Union oder Kontinente
  • <country> für Länder und Staaten, ggf. auch für Gliedstaaten in einer Föderation
  • <region> für Regionen unterhalb der Ebene von Ländern und Staaten, ggf. auch für Gliedstaaten in einer Föderation
  • <settlement> für Kommunen, also Städte, Dörfer und sonstige Gemeindetypen
  • <district> für Stadtviertel und andere Typen von Teilen innerhalb von Kommunen

Die genannten Elemente müssen die angegebene Reihenfolge einhalten, alle sind jedoch optional und können sich andererseits auch wiederholen, (z. B. <region> für die Angabe mehrerer, ineinander enthaltener Regionen). Für jedes dieser Elemente ist in ›heiEDITIONS‹ strukturierter Inhalt vorgesehen, der aus einem oder mehreren <placeName> und optional einem oder mehreren Identifikatoren in <idno> besteht. Die Angabe mehrerer Namen durch Wiederholung von <placeName> kann durch alternative, ggf. historische, Namensvarianten bedingt sein, aber auch der Mehrsprachigeit dienen (dann ist jedes <placeName> mit @xml:lang zu kennzeichnen).

Beispiel für die Angabe der Lage eines Ortes mithilfe zweier Ebenen geopolitischer Verwaltungseinheiten, jeweils mit GND-Verknüpfung:

                
            

Bei der Verwendung von <location> zur Angabe geographischer Koordinaten erhält <location> genau ein Kindelement <geo>. <geo> enthält dann zwei Dezimalzahlen (mit Punkt als Dezimaltrennzeichen und einem Leerzeichen zwischen den beiden Dezimalzahlen) für die geographische Breite und Länge, z. B.:

                
            

Informationen zu Körperschaften

Einträge zu Körperschaften in einem Körperschaftsregister haben die folgende Struktur in festgelegter Reihenfolge:

  • <orgName> (obligatorisch, ggf. mehrfach nach den unter Namen und Bezeichnungen dargelegten Regeln)
  • <idno> (optional, nur einmal pro Typ)
  • <location> (optional, ggf. mehrfach)
  • <note> (optional, nur einmal pro Sprache)
  • <listBibl> (optional, nur einmal)
  • <listRef> (optional, nur einmal)
  • <figure> (optional, ggf. mehrfach)

Die Verortung einer Körperschaft mithilfe von <location> folgt denselben Regeln wie bei Orten, s. oben Informationen zu Orten. Zusätzlich kann jedoch, ggf. an letzter Stelle nach den optionalen Elementen <bloc>, <country>, <region>, <settlement> und <district>, ein konkreter Ort wie etwa ein Gebäude mit <placeName> (ggf. mehrfach und ggf. mehrsprachig) und ggf. <idno> (ggf. mehrfach) angegeben werden.

Informationen zu Ereignissen

Einträge zu Ereignissen in einem Ereignisregister haben die folgende Struktur in festgelegter Reihenfolge:

  • <label> oder <name>8) (obligatorisch, ggf. mehrfach nach den unter Namen und Bezeichnungen dargelegten Regeln)
  • <idno> (optional, nur einmal pro Typ)
  • <date> (obligatorisch, nur einmal)
  • <location> (optional, ggf. mehrfach)
  • <note> (optional, nur einmal pro Sprache)
  • <listBibl> (optional, nur einmal)
  • <listRef> (optional, nur einmal)
  • <figure> (optional, ggf. mehrfach)

Die Ortsangabe eines Ereignisses mithilfe von <location> folgt denselben Regeln wie bei Orten, s. oben Informationen zu Orten. Zusätzlich kann jedoch, ggf. an letzter Stelle nach den optionalen Elementen <bloc>, <country>, <region>, <settlement> und <district>, ein konkreter Ort wie etwa ein Gebäude mit <placeName> (ggf. mehrfach und ggf. mehrsprachig) und ggf. <idno> (ggf. mehrfach) angegeben werden. Für den Fall, dass ein Ereignis an mehreren Orten stattfand (z. B. bei einer Konferenz), kann <location> wiederholt und ggf. auch mit Datierungsangaben anhand der Attribute @when, @notBefore, @notAfter, @from und @to präzisiert werden. (Für die Verwendung dieser Attribute gelten die oben unter Namen und Bezeichnungen beschriebenen Regeln.)

Informationen zu Werken

Einträge zu Werken in einem Werkregister haben die folgende Struktur in festgelegter Reihenfolge:

  • <title> (obligatorisch, ggf. mehrfach nach den unter Namen und Bezeichnungen dargelegten Regeln)
  • <author> (optional, ggf. mehrfach)
  • <idno> (optional, nur einmal pro Typ)
  • <date> (optional, nur einmal pro Typ)
  • <note> (optional, nur einmal pro Sprache)
  • <listBibl> (optional, nur einmal)
  • <listRef> (optional, nur einmal)
  • <figure> (optional, ggf. mehrfach)

Die Angabe des Werkurhebers im Element <author> erfolgt alternativ mit <persName> oder <orgName>, je nach dem, ob der Urheber eine Person oder eine Körperschaft ist. <persName> oder <orgName> können mehrfach angegeben werden, wenn die Erfassung unterschiedlicher Namensformen erwünscht ist. Es darf jedoch nicht gleichzeitig <persName> und <orgName> vorkommen. Nach <persName> oder <orgName> kann mit <idno> ein Identifikator angegeben werden. Bei mehreren Urhebern ist <author> entsprechend zu wiederholen. Falls bei mehreren Urhebern eine Zeitangabe für die jeweilige Urheberschaft notwendig wäre, kann dies an <author> mit den Attributen @when, @notBefore, @notAfter, @from und @to erfolgen. Für die Verwendung dieser Attribute gelten die oben unter Namen und Bezeichnungen beschriebenen Regeln.

Beispiel für eine einfache Angabe eines Urhebers mit einer Namensform und einem GND-Identifikator:

                
            

Für die Angabe von Datierungs- bzw. Zeitangaben zu einem Werk kann <date> verwendet werden. Es trägt obligatorisch das Attribut @ana, das zur Unterscheidung verschiedener Typen von Zeitangaben dient. Vorerst ist allerdings nur die Angabe des Typs › hc:DateOfCreation ‹ vorgesehen. Die maschinell lesbare Erfassung der Zeitangabe erfolgt an <date> mithilfe der Attribute @when, @notBefore, @notAfter, @from und @to. Für die Verwendung dieser Attribute gelten die oben unter Namen und Bezeichnungen beschriebenen Regeln. Innerhalb von <date> kann mit <note> eine freie Textangabe vorgenommen werden, ggf. nur einmal pro Sprache.

Beispiel für eine einfache Angabe des Entstehungszeitpunkts eines Werkes:

                
            

Informationen zu Einträgen in Sachregistern

Einträge in einem Sachregister haben die folgende Struktur in festgelegter Reihenfolge:

  • <label> (obligatorisch, ggf. mehrfach nach den unter Namen und Bezeichnungen dargelegten Regeln)
  • <idno> (optional, nur einmal pro Typ)
  • <note> (optional, nur einmal pro Sprache)
  • <listBibl> (optional, nur einmal)
  • <listRef> (optional, nur einmal)
  • <figure> (optional, ggf. mehrfach)



Anmerkungen

1 In besonderen Fällen kann <rs> auch mit mehr als einer Typangabe in @ana versehen werden, um gleichzeitig Entitäten in mehreren Registern zu verknüpfen, z. B. im Orts- und Körperschaftsregister, wenn sich eine Textstelle nach Meinung des Herausgebers gleichzeitig auf einen Ort und eine Körperschaft bezieht. Die in den URIs in @ref verwendeten Präfixe müssen sich dann selbstredend auf unterschiedliche Registerdateien beziehen. Ob eine solche Mehrfachverknüpfung sinnvoll ist, obliegt dem Ermessen des Herausgebers.
2 In bestimmten Fällen kann in ›heiEDITIONS‹ zumindest während der manuellen TEI-Redaktion eine Registerliste in statischer Form sogar ganz fehlen. Dies kann dann der Fall sein, wenn allein auf Normdatensätze der GND Bezug genommen wird, ohne dass vom Herausgeber eigene Inhalte für die Referenzeinträge des Registers erstellt würden. Selbst die Ansetzungsformen der einzelnen Einträge würden dann aus der GND übernommen.
3 Die GND-Nummer gewinnt man, wenn man von der URI einer GND-Ressource vorn den Teil http://d-nb.info/gnd/ abtrennt. Die GND-Nummer der GND-Ressource ↪ http://d-nb.info/gnd/118540238 (Johann Wolfgang von Goethe) ist beispielsweise 118540238.
4 Diese Sprachunterscheidung ist dadurch bedingt, dass wir nur für Eigennamen den Begriff ›Name‹ verwenden wollen. Bezeichnungen für Ereignisse, Werke und andere Dinge sind meist keine Eigennamen, bei Werken hat sich allerdings die spezielle Bezeichnung ›Titel‹ eingebürgert. Diesem Sprachgebrauch trägt auch die Elementverwendung Rechnung.
5 Wie oben ausgeführt, gilt aber eine Benennung dann implizit als bevorzugt (und nicht als alternativ), wenn es sich um die einzige angegebene Benennung (ggf. pro Sprache) handelt.
6 › hc:AppellationForDoublePosting ‹ ist als Unterklasse von › hc:AlternativeAppellation ‹ definiert, eine zusätzliche Kennzeichnung der Benennung als › hc:AlternativeAppellation ‹ wäre daher redundant.
7 Sollten zu einem späteren Zeitpunkt maschinenlesbare Angaben weiterer Informationen zur Geburt und zum Tod einer Person erforderlich werden, wäre dies u. a. durch Markup innerhalb der verbalen Angabe innerhalb von <note> vorstellbar.
8 <label> ist zu verwenden, wenn die Benennung des Ereignisses nicht den Charakter eines Eigennamens hat; andernfalls sollte <name> genutzt werden. Die Verwendung von <label> und <name> gleichzeitig ist nicht erlaubt.
decoration