wiki:tei

TEI

  • Ich beschränke mich hier im wesentlichen auf chinesische Texte.
  • Bei unserem XML ist ganz wichtig, dass alle XML-tags von unserem Anzeigesystem irgendwie angezeigt werden. Das führt zu bestimmten Design-Entscheidungen.
  • Wir haben auch bestimmte best practices, das XML zu formatieren, um es möglichst menschenlesbar zu machen. Das hat auf die XML-Struktur keinen Einfluss.
  • TEI ist auch kein eindeutiger Standard. Mit Design-Entscheidungen innerhalb von TEI habe ich keine Erfahrung. Meine Beschreibung von TEI kann also Fehler enthalten.

1. Metadaten-Block

Aus den Bibliotheks-Metadaten kann man sicher auch einen TEI-Header machen. Mit dem TEI-Header habe ich mich noch nicht beschäftigt.

Wichtigste Erkenntnis: der TEI-Header ist viel ausführlicher als unsere Metadaten. Die Funktion unserer Metadaten ist lediglich, das Dokument zu identifizieren, es self-contained zu machen und zu sagen, wo man es in ECHO finden kann. Außerhalb der Datei selbst haben wir mehr Metadaten. Und die Langatmigkeit des TEI-Headers erinnert an METS. Man braucht also ein Skript, das den Metadaten-Block erstellt.

Konkrete Beispiele: bei TEI muss man sich <TEI> <teiHeader> davordenken, bei uns <echo> <metadata>.

  • <dcterms:title> --> <fileDesc> <titleStmt> <title> <title type=main">
  • Dinge wie "Bearbeiter des XML" fehlen bisher bei uns.
  • etc.

2. Grobstruktur

  • <text xml:lang="zh" type="free"> --> genauso, bis auf @type
  • <div>
    • <div type="front" level="1" n="1"> --> TEI: <front>
    • <div type="body" level="1" n="1"> --> TEI: <body>
    • <div type="toc" level="2" n="1"> --> TEI: ?
    • @n andere Bedeutung?

Design-Entscheidung bei uns, solche Dinge allgemein mit <div> und einem @type-Attribut statt mit eigenen Elementen auszudrücken. (Nachträgliche) Grundidee ist, das man alle <div> entfernen kann und der Text immer noch genauso angezeigt wird, nur gibt es keine Informationen für das automatisch erstellte Inhaltsverzeichnis mehr.

3. Feinstruktur

  • <head> @indent: Bedürfnisse von Chinesisch in TEI nicht berücksichtigt?
  • <p> @indent: Bedürfnisse von Chinesisch in TEI nicht berücksichtigt?
  • <s>

4. Milestones

<pb/>

TEI:

<fw type="head" place="top-centre">Poëms.</fw>
<fw type="pageNum" place="top-right">29</fw>

bei uns: Running head ist bei uns ein Attribut: @rhead="...", genauso die Seitenzahl: @o="..."

  • Nachteil: man kann in diesen Texten keine <reg> (siehe unten) verwenden, sondern müsste weitere Attribute wie @rhead-reg verwenden.
  • Vorteil: Wenn das <pb> zum Beispiel mitten in einem Satz ist, steht kein "Müll" im Satz. (Insbesondere wenn man sich den Text mit Arboreal anzeigen lassen will.)

<lb/>: ok?

5. Fremd-Vokabular

Tabellen und Listen mit XHTML: geht wohl auch in TEI. Etwas angepasst, z.B. ist bei uns <pb> erlaubt, und wir verwenden unser Text-Modell. Ich weiß nicht, ob das ein Problem ist.

6. Text

allgemeiner Unterschied zu TEI: bei uns ist @xml:space="preserve" ein Schlüsselreiz, dass ein Element direkt Text enthält.

<reg>: in TEI anderer Ansatz: buchstabenweise mit Elementen, bei uns wortweise mit Attributen. Also zum Beispiel:

  • TEI: d<choice><ex>em</ex><am>e&#x304;</am></choice>
  • bei uns: <reg norm="dem" type="context">dē</reg>

(nebenbei: bei uns direktes Unicode, wo immer möglich)

Leichter zu verarbeiten, leichter für Menschen zu lesen.

Für Chinesisch evtl. kein so großer Unterschied. Aber wie geht TEI mit Zeichenvarianten um?

Nehmen wir mal das hypothetische Beispiel, dass im Originaltext das Zeichen 國 steht, das es aber (und hier wird es hypothetisch) nicht in Unicode gibt. Dann würden wir schreiben:

  • Schritt 1: 中<reg norm="国" type="V" resp="script">国</reg>
  • Schritt 2: 中<reg faithful="{⿴口或}" type="V">国</reg>
  • Schritt 3: <reg faithful="中{⿴口或}" type="V">中国</reg>

Als Konsequenz würde bei der automatischen Verlinkung des Textes mit einem Wörterbuch 中国 einen link bekommen und nicht die einzelnen Zeichen.

Das Beispiel führt vielleicht in die Irre, weil es hier gar nicht um Langzeichen versus Kurzzeichen geht.

7. speziell für Chinesisch

  • small text: <emph style="sm">, <small>, <smlb/>

Ich kenne kein direktes Gegenstück in TEI. Ich habe, wie gesagt, überhaupt den Eindruck, dass Bedürfnisse von Chinesisch in TEI nicht berücksichtigt sind.

  • <sl> etc.: ?

8. speziell für Wörterbücher

bei uns vorläufig:

  • <entry>
  • <form>
  • <pronunciation>: TEI <pron>
  • <translation xml:lang="en">: TEI <cit type="translation" xml:lang="en">

Das habe ich im wesentlichen nach TEI modelliert, allerdigns die Wörter ausgeschrieben. Aber im TEI-Buch werden nur westliche Wörterbuch-Einträge diskutiert. Zum Beispiel soll

  • <entry> <form>

den Eintrag nicht direkt enthalten, sondern erst in einem zusätzlichen <orth>. Das ist für Chinesisch wohl Unsinn.

<def> habe ich vorläufig weggelassen, denn zum einen sind die Beispiel im TEI-Buch nur ganz kurze Einträge ohne Zeilenumbrüche, wo man es klarer dazusagen muss, was nun die Definition ist. Zum anderen ist das teilweise eine nicht-triviale Aufgabe, die ich erstmal auslasse.

<translation> und <foreign>: Ich habe mich vorläufig für

<translation xml:space="preserve"><foreign xml:lang="en">Art</foreign>, 德 <foreign xml:lang="de">Kunst</foreign>.</translation>

entschieden. Ganz glücklich bin ich damit noch nicht.

9. Bilder

Bilder kommen nicht in den beiden Beispieltexten nicht vor, das lasse ich daher erstmal aus.

Workshop TEI und Chinesisch

Marcus Bingenheimer: Workshop TEI und Chinesisch

  • TEI-ChinLoc-2ndPrintEd.pdf (auf Chinesisch)
  • Sein Kapitel: dort p.18/19: 既不得其味<g ref="#id003">嘴</g>傷而虛還. Das würde dem Ansatz mit IVS-Sequenzen statt IDS-Sequenzen entsprechen, allerdings mit einem lokalen authority file.

zu "Marking Up Encyclopedias"

Allgemein: man sollte wohl unterscheiden zwischen Dingen, wo wir einfach einen anderen Namen verwenden, und Dingen, wo wir einen anderen Ansatz haben.

Insgesamt glaube ich, dass die Umwandlung relativ geradlinig ist, sobald klar ist, wie es genau aussehen soll.

  • <div type="entry">

Damit habe ich kein Problem, aber das TEI-Buch sagt <entry>, deshalb bin ich ein bisschen verwirrt.

Unser Standpunkt zu "<div> versus eigenes Element" ist nicht ganz konsistent. Meine aktuell favorisierte Idee ist: Alles was bei der Anzeige der Seite relevant ist, bekommt ein eigenes Element. Dinge, die nur für das Inhaltsverzeichnis sind, bekommen <div>. Und <div> darf man entfernen, ohne dass sich die Darstellung des Textes ändert.

Das ist aber nur eine nachträgliche Rationalisierung. Wir haben noch <div multiflow> und <div parallel> für verschiedene Textflows innerhalb des Textes, wie zum Beispiel "Text - Linearübersetzung - freie Übersetzung"; das könnte man einfach in <multiflow> und <parallel> ändern. Aber wir haben auch noch <div float>, wo die Floats (z.B. Abbildungen) gesammelt werden, die aus einem Absatz herausgezogen werden. Das wäre zum einen ein größerer Aufwand, es zu ändern, weil alle unsere Texte es enthalten, und zum anderen ist es eine Stelle, wo wir nicht kodieren, was im Originaltext steht bzw. gemeint ist, sondern dass wir selbst die Reihenfolge der Textversatzstücke geändert haben.

In diesem Text wird ebenfalls geraten, Floats hinter den Absatz zu schieben. Wenn ich es recht verstehe, sogar ganz ohne Markierung, so dass ein Textanzeigesystem die originale Position nicht mehr rekonstruieren kann. Das muss kein Problem sein, wenn man es so haben möchte. (Und es würde vielleicht nahelegen, dass wir bei uns tatsächlich <div float> statt <float> verwenden sollten.) Allerdings gibt es Probleme, wenn man die Seitenstruktur des Originaltextes erhalten möchte.

Im Textmodell machen wir es schon wieder anders: alle einzelnen Textstil-Elemente werden zu <emph>. (Dadurch wird zum Beispiel <emph style="bf it"> möglich.)

  • <head>

Leuchtet mir ein, aber TEI-Buch sagt <form>.

<head type="alt"> ist aber nicht für Übersetzungen gemeint, oder? Also nicht als Ersatz für <translation> bzw. <cit type="translation"> ?

  • <term>

<head> (some headword) </head> aber <head><term xml:id="empire">EMPIRE</term></head>

Wofür ist das zusätzliche <term>?

Und wofür ist das xml:id, das doch wahrscheinlich automatisiert erstellt wird und einfach den Begriff wiederholt? Hat sich das in der Praxis als besser als opake IDs erwiesen?

  • <div type="article">

TEI-Buch: <def>? Ich werde jedenfalls eine Markierung des restlichen Artikels einfügen.

Frage: Ist denn jeweils der gesamte restliche Artikel der Erklärungstext, oder muss man noch weitere Einteilungen vornehmen?

  • <list>, <table>

Wie gesagt, wir verwenden xhtml, und das findet das TEI-Buch okay.

@rows, @cols: Wir verwenden nicht xhtml-table, sondern xhtml-basic-table. Zumindest dort sind diese Attribute in <xhtml:table> nicht vorgesehen. (Einmal pro Jahr fragen wir uns, ob wir doch xhtml-table verwenden sollen, und normalerweise ist die Antwort "nein".) Aber man kann das sicher automatisiert ergänzen.

<row> und <cell> mit @role="label": Das muss man per Hand ergänzen, denn das wird nicht automatisch markiert. Wieder: @role ist in xhtml-basic-table in <xhtml:tr> (entspricht <row>) und <xhtml:td> (entspricht <cell>) nicht vorgesehen. Da es im Gegensatz zu @rows und @cols nicht automatisiert ergänzt werden kann, müsste man es auch bei uns kodieren können. Vielleicht würde sich hier @class="label" anbieten, so dass es bei der Textanzeige mit HTML gleich an das CSS weitergereicht werden kann. Das kommt mir nicht mal allzusehr geschummelt vor.

Aber kommen labels denn bei chinesischen Tabellen überhaupt vor?

  • subje3ct

Ist das als authority file bei Personen und Büchern besser als die existierenden Bibliotheksansätze, also PND / GND, LCCN, VIAF ? Wenn ja, warum? Suche nach "Shimizu, Chō" findet Orte (!), aber nicht die Person.

  • <hi rend="wavy underline">

Ich kann, wenn gewünscht, <emph style="wl"> gerne in <hi rend="wavy underline"> umwandeln, und entsprechend für die anderen Linientypen.

  • <g rend="鎮">鎭</g>

Wir haben hier einen anderen Ansatz. nämlich dass Zeichen wie 鎭, die es in Unicode gibt, einfach so im Text stehen, und die Probleme der Standardisierung für die Suche etc. übernimmt das Anzeigesystem. Wir haben auch einen Modus "normalized" im Anzeigesystem, wo dann das 鎭 als 鎮 angezeigt wird.

(Es geht hier nur um Zeichenvarianten, die in Unicode enthalten sind.)

Last modified 13 years ago Last modified on May 18, 2011, 9:16:36 AM