Annotationsstandard für TUSNELDA

0. Einführung

Der Workshop "Annotationsstandard für TUSNELDA" wurde veranstaltet mit dem Ziel, einen gemeinsamen Annotationsstandard für die im SFB 441 gesammelten und aufbereiteten Korpora zu entwickeln. Diese Korpora sollen in die Korpussammlung TUSNELDA (Tübinger Sammlung nutzbarer empirischer linguistischer Datenstrukturen) integriert werden.

Ein Standard für TUSNELDA ist notwendig, damit zum einen die Vergleichbarkeit der Teilkorpora im SFB gegeben ist. Zum anderen soll durch die Standardisierung die Wiederverwendbarkeit der Korpora unter Benutzung einheitlicher Tools gewährleistet werden. Gleichzeitig soll der Standard so flexibel gestaltet werden, dass die unterschiedlichen Bedürfnisse der einzelnen Projekte im SFB 441 berücksichtigt sind.

Bei der Erarbeitung des Standards für TUSNELDA wurde ausgegangen von dem von EAGLES (Expert Advisory Group on Language Engineering Standards) entwickelten Corpus Encoding Standard (CES). Ziel des Workshops war, zu überlegen, wieweit dieser Standard für den SFB modifiziert bzw. erweitert werden muss.

1. Allgemeines zur Annotation des gesamten Korpus

1.1 Das Element tusneldaCorpus

<!ELEMENT tusneldaCorpus  - -  (tusneldaHeader, (tusneldaDoc+ | tusneldaCorpus+)) >
<!ATTLIST tusneldaCorpus       %a.global;
             type                 CDATA     #IMPLIED
             version              CDATA     #REQUIRED
             TEIform              CDATA     'teiCorpus.2'   >

1.2 Metasprache

Neben dem beliebig ausführlichen Text in einer frei wählbaren Sprache ist eine englische Kurzfassung wünschenswert.

1.3 Aufwärtskompatibilität

2. DTD des Headers: Das Element tusneldaHeader

<!ELEMENT tusneldaHeader   - -  (fileDesc, encodingDesc?, 
                                profileDesc, revisionDesc?) >
<!ATTLIST tusneldaHeader        %a.header;
          type                  CDATA               text
          creator               CDATA               #IMPLIED
          date.created          CDATA               #REQUIRED
          date.updated          CDATA               #REQUIRED
          version               CDATA               #REQUIRED      
          TEIform               CDATA               'teiHeader' >

2.1 File Description

2.1.1 Title Statement

<!ELEMENT titleStmt  - -  (h.title, restpStmt)        >

<h.title>

Titel des gesamten Korpus: TUSNELDA,
Titel eines elektr. Textes in TUSNELDA: Originaltitel - TUSNELDA electronic version

<respStmt>

Die Reihenfolge der Elemente <respType> und <respName> sollte einheitlich festgelegt sein, und es scheint sinnvoll, zu jedem <respName> auch einen <respType> anzugeben. Daher wird das Element <respStmt> definiert als

<!ELEMENT respStmt  - -  ((respType, respName)+)      >

Empfohlene Inhalte von <respType> sind Project, Annotation, Correction.
Beispiel für Paare von <respType> und <respName>:

          <respType>Project</respType>
          <respName>C1 (Marga Reis)</respName>
          <respType>Annotation (POS-Tagging)</respType>
          <respName>Student A</respName>
          <respType>Correction</respType>
          <respName>Student B</respName>
            

2.1.2 Edition Statement

<!ELEMENT fileDesc        - -   (titleStmt, editionStmt, 
                                    extent?, publicationStmt, sourceDesc+) >

<!ELEMENT editionStmt     - o   (EMPTY) >

2.1.3 Extent Statement

<!ELEMENT extent          - -   (wordCount, tokenCount, characterCount?, 
                                    byteCount, extNote*) >
<!ATTLIST extent                %a.header; >

<!ELEMENT tokenCount      - -   (#PCDATA) >
<!ATTLIST tokenCount            %a.header; >

<!ELEMENT characterCount  - -   (#PCDATA) >
<!ATTLIST characterCount        %a.header; >

<wordCount>

Anzahl der linguistischen Wörter ohne Satzzeichen

<tokenCount>

Anzahl der Korpuspositionen, d.h. <wordCount> + Anzahl der Satzzeichen

<characterCount>

Anzahl der Zeichen, bezogen auf alles, was bei tokenCount mitgezählt wird. Dabei sollen Character Entities als ein Zeichen gezählt werden, und andere Entities werden vor dem Zählen aufgelöst, d.h. hier wird das gezählt, wofür das Entity steht.

<byteCount>

Angabe der Dateigröße

<extNote>

Hier sollte auf jeden Fall eine Kennzeichnung von Satzzeichen vermerkt sein, d.h. eine Angabe darüber, was als Satzzeichen behandelt und damit nur bei <tokenCount>, nicht aber bei <wordCount> mitgezählt wurde.

2.1.4 Publication Statement

WORLD*

EU

Universität Tübingen

SFB 441

<!ELEMENT publicationStmt - -  (distributor, pubAddress,
                               telephone*, fax*, 
                               eAddress*, idno*,
                               availability+, pubDate ) >

2.1.5 Source Description

Das Element <biblStruct> soll gegenüber der CES DTD modifiziert werden:

<biblStruct>

Um die Entstehungszeit von z. B. diachronen Texten codieren zu können, wird in den Elementen <analytic> und <monograph> ein neues Element <creationDate> eingeführt. Dieses ist zu unterscheiden vom Element <pubDate> (unter <imprint>), welches das Publikationsdatum eines Textes bzw. einer Sammlung von Texten angibt. (Wenn z.B. eine Sammlung von mittelhochdeutschen Texten in diesem Jahrhundert publiziert wurde, sind <creationDate> und <pubDate> verschieden.) Da bei historischen Texten das Entstehungsjahr oft nicht eindeutig bestimmt werden kann, ist hier auch die Angabe eines Zeitraums erlaubt. Hierfür hat <creationDate> die obligatorischen Attribute earliest und latest, in der das früheste bzw. späteste mögliche Entstehungsjahr angegeben werden.

<!ELEMENT analytic      - -  (h.author | respStmt |
                             h.title | creationDate)*           >
<!ATTLIST analytic           %a.header;                         >

<!ELEMENT monogr        - -  (h.title+,
                             (h.author | respStmt)*,
                             (edition, respStmt?)*, 
                             imprint+, idno*,
                             (biblNote | biblScope)*, 
                             creationDate)                      >
<!ATTLIST monogr             %a.header;                         >


<!ELEMENT creationDate       - -  (#PCDATA)                     >
<!ATTLIST creationDate            %a.header;
          earliest           CDATA               #REQUIRED
          latest             CDATA               #REQUIRED      >

2.2 Encoding Description

2.2.1 Project Description und Sampling Description

Der Inhalt von <samplingDesc> soll im Header eines Korpus Auskunft über die Auswahl der Texte geben. Im Header eines Textes dagegen gibt er Auskunft über die Auswahl der Textausschnitte.

2.2.2 Editorial Declaration

Unterelemente von <editorialDecl>:

<correction>

Für TUSNELDA wurde vereinbart, bei Korrekturen immer das Original in einem Attribut zu behalten. Dies soll automatisch kontrolliert werden.
Dementsprechend wurde der Default-Wert des Attributs method auf tags gesetzt:

<!ATTLIST correction     %a.header;
                         %a.declarable;
          status         (high | medium | low | unknown)
                                                  unknown
          method         (silent | tags)          tags        >

<quotation>

wird unverändert übernommen

<hyphenation>

Das Element wird unverändert übernommen. Für TUSNELDA wird vereinbart, jede Änderung zu dokumentieren und das Original zu behalten. In <hyphenation> sollte die Methode beschrieben werden, die bei der Entfernung von Trennungen am Zeilenende angewendet wurde, möglichst unter Angabe des verwendeten Skripts.

<segmentation>

Die Angabe der bei der Segmentierung angewendeten Methoden sollte sorgfältig vorgenommen werden. Er wurde vereinbart, <segmentation> weiter zu strukturieren. Anstelle von #PCDATA sollte es eine beliebige Menge von Paaren enthalten, die jeweils ein Tag und eine Beschreibung der für dieses Tag bei der Segmentierung verwendeten Methode enthalten, gefolgt von einer segmentation Note:

<!ELEMENT segmentation  - -   ((tag, segmMethod)*, segmNote?) >
<!ATTLIST segmentation        %a.header;
                              %a.declarable;                  >

<!ELEMENT tag           - -   (#PCDATA)                       >
<!ATTLIST tag                 %a.header;                      >

<!ELEMENT segmMethod    - -   (#PCDATA)                       >
<!ATTLIST segmMethod          %a.header;                      >

<!ELEMENT segmNote      - -   (#PCDATA)                       >
<!ATTLIST segmNote            %a.header;                      >

<segmMethod> sollte auch Angaben über die jeweils verwendeten Skripte machen. Es wurde außerdem vereinbart, wenn möglich die Skripte zusammen mit TUSNELDA bzw. mit den einzelnen Teilkorpora von TUSNELDA zu distribuieren.

<transduction>

Auch hier sollten soweit möglich verwendete Skripte mit angegeben werden.

<normalization>

Für <normalization> gilt ebenso wie für <correction>, dass die ursprüngliche Form als Attribut beibehalten werden soll. Dies soll auch automatisch kontrolliert werden. Dementsprechend wird auch hier der Default für method auf tags gesetzt:

<!ATTLIST normalization      %a.header;
                             %a.declarable;
             source          CDATA                    #IMPLIED
             method          (silent | tags)          tags        >

<conformance>

Ob für TUSNELDA verschiedene Conformance Level sinnvoll sind, kann man zur Zeit noch nicht sagen. Die CES Level of conformance machen für TUSNELDA wohl keinen Sinn mehr, da die ursprüngliche cesDoc DTD nicht nur erweitert sondern auch verändert wurde.

Als ein für TUSNELDA angestrebter Level of conformance wurde zunächst nur vereinbart, dass für jede Publikationseinheit

• bis auf Paragraphenebene annotiert sein sollte,
• und für alle Tags, die überhaupt vorkommen, das Tagging auch durchgängig sein sollte.

Was als Publikationseinheit betrachtet werden soll, bestimmen die Einzelprojekte.

2.2.3 Tags Declaration

Im Header von TUSNELDA soll unter <tagsDecl> für jedes Tag, das in TUSNELDA verwendet wird, ein <tagUsage>-Element vorhanden sein, in dessen Content die Semantik dieses Tags spezifiziert wird. Damit soll gerährleistst werden, dass die einzelnen Tags in TUSNELDA eine einheitliche Semantik haben.

Sowohl in den Headern der einzelnen Texte als auch in den Headern von Teilkorpora sollen die jeweiligen Häufigkeiten der verwendeten Tags mit Hilfe des occurs-Attributs von <tagUsage> codiert sein.

2.2.4 Class Declaration

Eine Taxonomie zur Klassifikation der Texte in TUSNELDA wird zu einem späteren Zeitpunkt festgelegt werden.

2.3 Profile Description

Da TUSNELDA ein multilinguales Korpus ist, ist die Angabe der verwendeten Sprache(n) in allen Headern unverzichtbar. Deshalb soll das Element <profileDesc> sowie in diesem das Element <langUsage> obligatorisch sein. Das Element <creation> wird nicht benötigt; seine intendierte Verwendung ist unklar. Deshalb wird es gestrichen.

<!ELEMENT tusneldaHeader   - -  (fileDesc, encodingDesc?, 
                                profileDesc, revisionDesc?) >
<!ATTLIST tusneldaHeader        %a.header;
          type                  CDATA               text
          creator               CDATA               #IMPLIED
          date.created          CDATA               #REQUIRED
          date.updated          CDATA               #REQUIRED
          version               CDATA               #REQUIRED      
          TEIform               CDATA               'teiHeader' >

<!ELEMENT profileDesc   - -  (langUsage, wsdUsage?,
                             textClass?, translations?,
                             annotations?)                      >
<!ATTLIST profileDesc        %a.header;                      >

2.3.1 Language Usage

<!ELEMENT language      - -  (#PCDATA)                         >
<!ATTLIST language            
          id                 ID                  #IMPLIED
          wsd                CDATA               #IMPLIED
          n                  CDATA               #IMPLIED     
          type               CDATA               #IMPLIED
          ethnologue         CDATA               #IMPLIED
          iso639             CDATA               #REQUIRED      >

2.3.2 Writing System

2.3.3 Textklassifikation

Unterelemente von <classDecl>:

<catRef>

Bei diesem Element wird das Attribut scheme weggelassen, da alle Texte in TUSNELDA nach dem selben Klassifikationsschema kategorisiert werden sollen und damit die Spezifikation eines solchen Schemas an dieser Stelle unnötig und verwirrend wäre.

<h.keywords>

Zum jetzigen Zeitpunkt wird kein Inventar möglicher Schlüsselwörter festeglegt. Es ist fraglich, ob eine solche Festlegung überhaupt sinnvoll ist oder ob es nicht vielmehr von Vorteil ist, wenn neben einem normierten Textklassifikationsschema eine nicht restringierte, flexible Möglichkeit besteht, Texte zu kategorisieren.

2.3.4 Annotationen in einer separaten Datei

TOKEN Auszeichnung von Token

MORPHSYN morpho-syntaktische Informationen

SYNTAX syntaktische Informationen

SEGMENT Segmentierung in Sätze und Wörter

ALIGN Alignierungs-Links zu einer parallelen Übersetzung

2.4 Revision Description

3. DTD der Texte: Das Element tusneldaDoc

3.1 Elemente auf Paragraphenebene

3.1.1 Geschriebene Paragraphen

3.1.2 Zitate

<!ELEMENT quote   - -   ((%par.seq;) | (%phrase.seq;))      >

3.1.3 Listen

Ein Beispiel, bei dem das Element <label> für die einzelnen Items gebraucht wird:

<list>
   <label>Erstens</label>
   <item>sollte die DTD den Bedürfnissen von Korpuslinguisten, 
         speziell im Rahmen von TUSNELDA, entsprechen,
   </item> 
   <label>zweitens</label>
   <item>sollte die DTD problemlos in XML konvertierbar sei, und
   </item> 
   <label>drittens</label>
   <item>sollte sie sich so weit wie möglich an bestehenden 
	 Standards orientieren.
   </item>
</list>

3.1.4 Anmerkungen

3.1.5 Gedichte

3.1.6 Bilder

<!ELEMENT figure   - -  (head?, p*, keywords?, figDesc?, text?)    >

3.1.7 Tabellen

Ob eine alternative DTD nötig ist und wie sie aussehen könnte, ist zunächst noch offen. Die Diskussion soll im Diskussionsforum Annotationsstandard weitergeführt werden.

3.1.8 Caption

3.1.9 Gesprochener Text

Als Lösung des Problems wurde vorgeschlagen, <stage> zu %m.phrase hinzuzufügen.

<!ENTITY % m.phrase   - -  '%m.token; corr | distinct | foreign |
                            gap | hi | list | mentioned | ptr | 
                            q |	ref | reg | s | title | stage'       >

Dies hat allerdings den Nachteil, dass <stage> auch ausserhalb von <sp> auftreten kann. Im Workshop wurde das Problem nicht weiter diskutiert, aber die Lösung ist noch nicht befriedigend.

Eine Alternative wäre, eine neues Element <spokenPar> für Paragraphen innerhalb von gesprochenem Text zu definieren, das zusätzlich zu den in <p> zugelassenen Elementen auch Elemente <stage> enthalten kann. Da darüber hinaus die Bezeichnung <sp> für ein Element, das Paragraphen enthalten kann, etwas unglücklich ist, könnte man sich eine Umbenennung z.B. in <spokenText> vorstellen. Die neuen Elemente würden dann folgendermaßen aussehen:

<!ELEMENT spokenText   - -   (speaker*, spokenPar+)            >

<!ELEMENT spokenPar    - -   (%phrase.seq; | stage)*           >

3.2 Sätze und Zitate innerhalb von Paragraphen

Es wurde angemerkt, dass innerhalb von Sätzen auch wieder (zitierte) Sätze auftreten können. Die Information, ob ein Satz innerhalb eines anderen Satzes auftritt, könnte für die Verarbeitung des Korpus wertvoll sein. Daher wurde <s> um ein Attribut nested erweitert mit möglichen Werten yes, no und Default no. Dieses Attribut kann automatisch erzeugt werden. Auch bei <q> könnte, je nach Korpus und Verarbeitungswünschen ein entsprechendes Attribut sinnvoll sein. Da dies aber (im Gegensatz zu dem Attribut nested bei <s>) vermutlich nur für einige Korpora relevant ist, ist das Attribut nested in <q> nicht obligatorisch.

Die erweitereten Attributlisten von <s> und <q> sehen demnach wie folgt aus:

<!ATTLIST s          %a.text;
                     next         IDREF             #IMPLIED
                     prev         IDREF             #IMPLIED
                     type         CDATA             #IMPLIED
                     broken       (yes | no)        no
                     nested       (yes | no)        no            >

<!ATTLIST q          %a.text;
                     next         IDREF             #IMPLIED
                     prev         IDREF             #IMPLIED
                     type         CDATA             #IMPLIED
                     direct       (y | n | unspecified)
                                                    unspecified
                     who          CDATA             #IMPLIED
                     broken       (yes | no)        no
                     nested       (yes | no)        #IMPLIED      >

Das Attribut nested bekommt den Wert yes, wenn ein Satz einen eingebetteten Satz enthält. Beispiel:

<s nested="yes">
   <q id=q1 broken="yes" next=q2>
     <s id=s1 broken="yes" next=s2 nested="no">Draußen</s>
   </q>, sprach er, 
   <q id=q2 broken="yes" prev=q1>
     <s id=s2 broken="yes" prev=s1 nested="no">ist es kalt.</s>
   </q>
</s>

3.3 Elemente auf Phrasenebene

3.3.1 Editorische Eingriffe

Das Attribut cert soll angeben, wie sicher man sich ist, dass der jeweilige editorische Eingriff sinnvoll ist. Um die Werte von cert einigermaßen miteinander vergleichen zu können, sollen hier überhaupt nur drei Werte zugelassen werden: sure, probable und presumable (sicher, wahrscheinlich, vermutlich).

Damit ergeben sich folgende modifizierte Attributlisten für <reg> und <corr>:

<!ATTLIST reg        %a.text;
                     orig         CDATA             #REQUIRED
                     resp         CDATA             #IMPLIED
                     cert         (sure | probable | presumable)
                                                    #IMPLIED      >

<!ATTLIST corr       %a.text;
                     sic          CDATA             #REQUIRED
                     resp         CDATA             #IMPLIED
                     cert         (sure | probable | presumable)
                                                    #IMPLIED      >

3.3.2 Hervorhebungen durch Layoutmerkmale

<hi rend="bo">Eine <hi rend="it">teilweise</hi> kursive Überschrift</hi>

<!ELEMENT hi    - -    (%phrase.seq;)                     >

Aus gleichen Gründen sollen auch für die Elemente <foreign>, <distinct>, <mentioned> und <title> Rekursionen erlaubt sein.

3.3.3 Sprachliche Hervorhebungen

3.3.4 Linguistische Daten

3.3.5 Maßangaben

<!ATTLIST measure            %a.text;
                             type         CDATA     #IMPLIED
                             value        CDATA     #IMPLIED  >

3.4 Allgemeines zur Annotation von Texten

3.4.1 Referenzsystem

3.4.2 Kodieren von Namen

Die CES Empfehlungen zu Titeln und Rollen sollten übernommen werden, allerdings vielleicht in einer etwas schwächeren Formulierung. In Sprachen, in denen Titel als Teil des Namen betrachtet werden und mit diesem zu einem Wort verbunden werden, möchte (und kann) man wahrscheinlich keine Trennung in Name und Titel vornehmen.

Die Behandlung von Possessiva und derivierten Formen ist noch problematischer. Für das Englische sind die CES Empfehlungen vermutlich sinnvoll. Aber in anderen Sprachen, z.B. im Deutschen, lässt sich die Possessivendung nicht so ohne weiteres vom Namen trennen, und es gibt auch von Namen abgeleitete Adjektive.

In Fällen von Possessiva, die (im Gegensatz zum Englischen) ein Wort bilden, sollte keine Zerlegung gemacht werden, sondern das ganze als ein Name annotiert werden:

       <name>Tübingens</name> malerische Altstadt

       <name>Hans</name>' neue Theorie

       die malerische <name>Tübinger</name> Altstadt

3.4.3 Behandlung von Satzzeichen

Bei Abkürzungen wird der Punkt als Teil der Abkürzung getaggt, auch am Satzende, wo er gleichzeitig das Ende des Satzes markiert.

Mit Ausnahme von Abkürzungen sollen Satzzeichen nicht in Tags auf Phrasenebene aufgenommen werden.

       Er besucht das malerische <name>Tübingen</name>.

Trennungszeichen sollten entfernt werden, wobei das Original als Attributwert mit angegeben werden muss.

       die malerische <reg orig="Alt-stadt">Altstadt</reg>