From bcfddc213a0c4f456cb5b648f0b63eabe56206f3 Mon Sep 17 00:00:00 2001 From: Ismail Prada Date: Mon, 11 Nov 2024 15:28:26 +0100 Subject: [PATCH 1/2] Implemented issues #34, #29 and some mixed other stuff. --- 1_introduction.md | 114 ++-- 2_entities.md | 580 ------------------ 2_entities/2_1_entity_annotation.md | 283 +++++++++ 2_entities/2_2_entity_typology.md | 293 +++++++++ 2_entities/2_3_coreferences.md | 28 + 2_entities/2_entities.md | 15 + 3_values.md | 2 +- 4_relations.md | 147 +++-- .../5_1_project_setup.md | 0 {anno_guide => 5_anno_guide}/5_2_doc_anno.md | 0 .../5_3_postprocessing.md | 0 {anno_guide => 5_anno_guide}/5_anno_guide.md | 4 +- index.md | 16 + 13 files changed, 784 insertions(+), 698 deletions(-) delete mode 100644 2_entities.md create mode 100644 2_entities/2_1_entity_annotation.md create mode 100644 2_entities/2_2_entity_typology.md create mode 100644 2_entities/2_3_coreferences.md create mode 100644 2_entities/2_entities.md rename {anno_guide => 5_anno_guide}/5_1_project_setup.md (100%) rename {anno_guide => 5_anno_guide}/5_2_doc_anno.md (100%) rename {anno_guide => 5_anno_guide}/5_3_postprocessing.md (100%) rename {anno_guide => 5_anno_guide}/5_anno_guide.md (93%) diff --git a/1_introduction.md b/1_introduction.md index 5a2d0ee..d5a0847 100644 --- a/1_introduction.md +++ b/1_introduction.md @@ -20,7 +20,7 @@ aushelfen. Diese Richtlinien sollen eine einheitliche Annotation von Texten in vormodernem Deutsch ermöglichen, wobei semantische Informationen bezüglich relevanter Entitäten (Personen, Orte, Organisationen, etc.) -und Beziehungen zwischen diesen Entitäten extrahiert werden. +und Beziehungen sowie Interaktionen zwischen diesen Entitäten extrahiert werden. Computerlinguistisch gesprochen sollen die gegebenen Informationen das maschinelle Training für die folgenden Informationsextraktions-Aufgaben @@ -28,8 +28,8 @@ ermöglichen: - Entity Detection - Named Entity Recognition -- Relation Extraction - Coreference Resolution +- Relation Extraction - Event Extraction Das Ziel ist hierbei sowohl Konsistenz, wie auch Vollständigkeit. @@ -60,34 +60,30 @@ Wir zielen in diesem Dokument darauf ab, eine solche Typologie vorzulegen, und weitere Unterklassen, welche Projekte verwenden, dieser hinzuzufügen um möglichst grosse Kompatibilität mit späteren Projekten zu gewährleisten. -Als Beispiel sei zum Beispiel genannt, dass unsere Beziehungstypologie im Moment -alle Familienbeziehungen unter "fam" (family) versteht. Ein Projekt, für welches -diese Beziehungen aber in grösserem Detail festgehalten werden müssen, würde +Verdeutlichen wir das an einem Beispiel mit der Beziehung vom Typ "Familie". +Vielen Projekten würde diese grobe Einordnung der Beziehung zwischen zwei Personen ausreichen. +Ein Projekt, für welches diese Beziehungen aber in grösserem Detail festgehalten werden müssen, würde eventuell feinere Kategorien wie "Ehe", "Geschwister", "Kinder", etc. festlegen. -Diese würden dann alle "fam" untergeordnet und dies im Schema, oder zumindest -in der Projektspezifischen Dokumentation (siehe 1.7.) festzuhalten, würde Kompatibilität -mit Projekten sicherstellen, welche die detaillierteren Unterscheidungen nicht verwenden. +Diese würden dann alle "Familie" untergeordnet und diese Verbindung würde im Schema, oder zumindest +in der Projektspezifischen Dokumentation (siehe 1.7.) festgehalten. +Das würde Kompatibilität mit Projekten sicherstellen, welche die detaillierteren Unterscheidungen nicht verwenden. ## 1.4. Komplexität BeNASch mag auf den ersten Blick überwältigend wirken. Es ist weitaus komplexer als eine flache Named Entity Annotation und beansprucht auch mehr Zeit. Leider ist nur so das Ziel einer konsistenten, vollständigen -Annotation zu erreichen.\ +Annotation zu erreichen. Um den Annotationsprozess zu beschleunigen, empfehlen wir, nicht direkt nach dem Schema zu annotieren, sondern "Abkürzungen" zu verwenden. Im -Dokument -[[Annotationsanleitung]](https://docs.google.com/document/u/0/d/1EL__O2yvNSZROLAoKgpeucuP032SEG1BDlfEx_mS_Sc/edit) -geben wir praktische Tipps mit welchen Werkzeugen die Dokumente am +Kapitel 5 geben wir praktische Tipps mit welchen Werkzeugen die Dokumente am schnellsten aus gängigen Formaten (Transkribus-Export, TEI) zu annotieren sind, und welcher "Abkürzungen" sich Annotator:innen bedienen können. Zudem stellen wir Post-Processing-Skripte bereit, mit welchen die "abgekürzten" Annotationen dann in das vollständige Schema umgewandelt werden können. -Für Projekte, welche keinen Wert auf eine vollständige Annotation legen, -stellen wir zudem BeNASch-lite vor, eine reduzierte Version dieses -Schemas, welches aber kompatibel ist. +Für Projekte, welche keinen Wert auf eine vollständig BeNASch-konforme Annotation legen, stellen wir zudem Methoden vor, wie das Schema so reduziert werden kann, dass die eigenen Daten soweit kompatibel bleiben, wie möglich. _coming soon_ ## 1.5. Vorverarbeitung des Textes @@ -96,7 +92,7 @@ sein. Aus diesem Grund versuchen wir, möglichst wenig am Text zu ändern, der einzige Schritt, der zwingend durchzuführen ist, ist die [[Tokenisierung]](https://de.wikipedia.org/wiki/Tokenisierung). Hierbei geht es in erster Linie darum, Satzzeichen von Wörtern zu -trennen, um eine saubere Annotation zu ermöglichen.\ +trennen, um eine saubere Annotation zu ermöglichen. Verwenden Sie das empfohlene Verfahren in der Anleitung, können Sie sich der dort vorgeschlagenen Tokenisierung bedienen. @@ -121,9 +117,9 @@ Empfehlungen). Die gewählten Typen müssen konsequent annotiert werden um Konsistenz in den Daten zu gewährleisten!\ Die Annotationsdokumentation des Projekts muss klar und verständlich festhalten, welche optionalen Typen annotiert wurden. Falls eines der -Module in den Empfehlungen (Kapitel 6) genutzt wurde, kann einfach das +Module in den Empfehlungen (_coming soon_) genutzt wurde, kann einfach das Modul festgehalten werden. In jedem Fall ist die Version des aktuellen -BeNASch in der Dokumentation zu verzeichnen. +BeNASch in der Dokumentation zu verzeichnen. (Versionierung beginnt bald) ## 1.8. Annotationsbeispiel @@ -137,14 +133,12 @@ gewidmet ihr Haus & Hofstatt in der Aeschenvorstadt" In diesem Text erkennen wir die folgenden Entitäten-Erwähnungen: REF.NAM.PER: **Diebolt Rüly** der Küfer -* * * - REF ist der allgemeine Marker für Entitätenerwähnungen, die keine Attribute sind. - NAM steht für *named*, also eine Entität, die anhand ihres Eigennamens erwähnt wird. - PER steht für *person*, da es sich hierbei um eine Person handelt. - *Diebolt Rüly* ist der *Head*, der Kern, der Erwähnung. Alle Entitätenerwähnungen müssen genau eine *Head*-Spanne aufweisen. ATT.NOM.PER.OCC: der **Küfer** -* * * - ATT ist der Marker für Erwähnungen, die aber "nur" die ihr übergeordnete Erwähnung, in dem Fall die des Diebolt Rüly, beschreiben. - NOM steht für *nominative*, also eine Entität, die anhand eines Nomens beschrieben wird. - Es handelt sich erneut um eine Person, erhält also die PER-Klassifikation. @@ -155,27 +149,22 @@ ATT.NOM.PER.OCC: der **Küfer** REF.NAM.PER: seine Frau **Agnes** ATT.NOM.PER.FAM: seine **Frau** -* * * - Hier handelt es sich um ein Attribut, wie schon der Beruf bei Diebolt. In diesem Fall aber is die Erwähnungspräzisierung vom Typen FAM (family) statt OCC. REF.PRO.PER: **seine** -* * * - Diese Pronominalnennung (PRO) bezieht sich auf Diebolt und wird in der Beziehungsannotation wichtig. REF.PRO.PER: **einander** REF.NOM.LOC: ihr **Haus & Hofstatt** in der Aeschenvorstadt -* * * - Beachte, dass wir die gesamte Spanne samt der Beschreibung, wo das Haus liegt, mit einschliessen. Alles, was syntaktisch Teil der Nominalphrase rund um *Haus & Hofstatt* ist, ist Teil der Erwähnung! - LOC steht für *location*. - Wir annotieren die gesamte Phrase *Haus & Hofstatt* als eine einzelne Erwähnung, da es sich bei dieser Formulierung um ein und dieselbe Entität handelt, nicht um mehrere verschiedene Entitäten. REF.PRO.PER.GRP: **ihr** -* * * - Auch Possessiva werden als PRO annotiert und sind erneut sehr wichtig bei der Annotation der Beziehungen. REF.NAM.LOC: der **Aeschenvorstadt** -* * * - Bemerke, dass auch der Artikel Teil der Erwähnung ist. ![Annotation Example with Entities](./static/images/example_entities.png) @@ -186,35 +175,58 @@ Mit Deskriptoren können wir weitere Beschreibungen von Entitäten erfassen, auc In der Erwähnung "ihr Haus und Hofstatt in der Aeschenvorstadt" sind folgende Deskriptorne zu annotieren: DESC.OWNER: ihr (in "ihr Haus & Hofstatt ...") -* * * - DESC ist der Marker für Deskriptoren. - OWNER steht für eine Beschreibung der Besitzverhältnisse der Entität. - Dieser Deskriptor impliziert gleichzeit eine OWNERSHIP-Beziehung (siehe nächstes Kapitel) DESC.LOC: **in** der Aeschenvorstadt -* * * - LOC steht für eine Beschreibung der Lage, bei einer Personenerwähnung kann es auch die Herkunft oder den Wohnort beschreiben. Wir können das LOC präzisieren, falls wir die Lage genauer beschreiben möchten (z.B. LOC_IN). ![Annotation Example with Descriptors](./static/images/example_desc.png) ### 1.8.4. Einfache Beziehungen -Beziehungen beschreiben Verhältnisse zwischen Entitäten. In diesem Beispiel finden wir mehrere Beziehungen, die wir _einfach_ annotieren können. Dies bedeutet, dass sie nur aus zwei verbundenen Erwähnungen und einer Klassifikation ihrer Beziehung bestehen. Würden wir komplexere Verhältnisse annotieren wollen, müssten wir auf _volle_ Annotation zurückgreifen. Die Textstrings hier beziehen sich auf die in 1.8.2. definierten Erwähnungen: - -REL.FAM: "seine Frau" → "seine" -* * * -- REL ist der Marker für Beziehungen. -- FAM steht wie bei der Erwähnungspräzision in 1.8.2. für *family*. -- Wir machen uns diese Überschneidung zu Nutze und müssen im empfohlenen Workflow nur das Attribut annotieren, die Beziehung wird dadurch impliziert und im Postprocessing erzeugt. +Beziehungen sind in weiterem Sinne Zustände (Kapitel 4), die ein Verhältnis zwischen mehreren Entitäten beschreiben. +Wie wir genau Beziehungen annotieren, wird in der Projektdokumentation spezifiziert. Nehmen wir an, dass wir uns für +die in diesem Teil folgenden Beziehungen, FAM, OWNERSHIP und LOC, auf eine einfache Annotation festgelegt haben, in der wir +nur die jeweiligen teilnehmenden Entitäten (Rollen) annotieren. +Die Textstrings hier beziehen sich auf die in 1.8.2. definierten Erwähnungen: + +REL.FAM: "seine Frau" und "seine" +- FAM steht wie bei der Erwähnungspräzision in 1.8.2. für *family* und ist die Klassifikation der Beziehung. +- Rolle 1 (Ehepartner:in) ist "seine Frau", Rolle 2 (Ehepartner:in) ist "seine". +- Wenn unsere Projektdokumentation auch die Annotation der Textspanne vorschreiben würde, wäre das "seine Frau", also die gleich Spanne wie das Attribut. +- Wenn unsere Projektdokumentation auch die Annotation des Triggers vorschreiben würde, wäre das der Head "Frau". +- Wir machen uns diese überschneidenden Informationen mit dem Attribut zu Nutze und müssen im empfohlenen Workflow nur das Attribut annotieren, die Beziehung samt Rollen, optionaler Textspanne und Trigger wird dadurch impliziert und im Postprocessing erzeugt. - Da wir textnah annotieren, findet die Beziehung nur zwischen dem Attribut und dem unmittelbaren Pronomen statt, die Verbindung auf "Diebolt Rüly" findet erst in einem nächsten Schritt statt. -REL.OWNERSHIP: ihr → "ihr Haus & Hofstatt ..." -* * * +REL.OWNERSHIP: "ihr Haus & Hofstatt ..." und "ihr" - Auch hier können wir uns die Überschneidung mit dem Deskriptor zu Nutze machen. +- Ansonsten funktioniert alles analog zum vorigen Beispiel. + +REL.LOC: "ihr Haus & Hofstatt in der Aeschenvorstatt" und "der Aeschenvorstatt" +- Funktioniert analog zum vorigen Beispiel. + +### 1.8.5. Erweiterte Ereignis-Annotation +Ereignisse werden wie Zustände (u.a. Beziehungen) annotiert. In diesem Beispiel nehmen wir an, dass unser Projekt sich darauf festgelegt hat, das Ereignis "BEQUEST" (eine Widmung zweier Eheleute einander) mit obligatorischer Annotation der Textspanne, des Triggers und der Rollen der Widmenden und Empfänger der Widmung wie auch des Objekts der Widmung zu annotieren. + +EV.BEQUEST: +- Textspanne: Der ganze Satz +- Trigger: "gewidmet" + - Der Trigger sollte möglichst kurz sein und sogleich das Ereignis möglichst gut beschreiben. +- Rolle BEQUEATHER: "Diebolt Rüly der Küfer" +- Rolle BEQUEATHER: "seine Frau Agnes" +- Rolle BENEFICIARY: "einander" +- Rolle PROPERTY: "ihr Haus & Hofstatt..." + +Wir müssen in diesem Beispiel die Rollen explizit annotieren, während die Rollen bei den einfachen Beziehungen im vorherigen Kapitel automatisch ableitbar waren, weshalb wir sie nicht explizit annotieren mussten. Das ist einer der Vorteile der Verschachtelung. Würden wir die Beziehungen im letzten Kapitel ausserhalb eines Deskriptors oder eines Attributs finden, oder wären sie komplexer als nur 2 Rollen, müssten wir die Rollen explizit annotieren, um Ambiguitäten zu vermeiden. -REL.LOC: "ihr Haus & Hofstatt ..." → "der Aeschenvorstatt" +![Annotation Example with Event](./static/images/example_event.png) -#### 1.8.4.1. Koreferenzen -Koreferenzen stellen eine spezielle Form der Beziehungen dar. Sie halten die Information fest, bei welchen Erwähnungen es sich um dieselben Entitäten handelt. In unserem Fall haben wir zwei Pronominalerwähnungen, die wir durch Koreferenzen mit ausführlicheren Erwähnungen verbinden. Koreferenzen werden immer von im Text später erscheinenden Erwähnungen zu den früheren gezogen. + +#### 1.8.6. Koreferenzen +Koreferenzen halten die Information fest, bei welchen Erwähnungen es sich um dieselben Entitäten handelt. +In unserem Beispiel finden wir zwei Pronominalerwähnungen, die wir durch Koreferenzen mit ausführlicheren Erwähnungen verbinden. +Koreferenzen werden immer von im Text später erscheinenden Erwähnungen zu den früheren gezogen. COREF: "seine" → "Diebolt Rüly der Küfer" @@ -223,29 +235,11 @@ COREF: "einander" → "seine Frau Agnes" COREF: "ihr" → "Diebolt Rüly der Küfer" COREF: "ihr" → "seine Frau Agnes" -* * * + - Da es sich bei "ihr" und "einander" um Erwähnungen mehrerer Entitäten handelt, können wir auch mehrere COREFs setzen. -- Falls Listen-Elemente verwendet werden, kann die COREF einfach auf die Liste gesetzt werden, die dann sowohl Diebolt wie auch Agnes umfassen würde. In diesem Beispiel wurde auf Listen der einfachheit halber verzichtet. +- Falls Listen-Elemente verwendet werden, kann die COREF einfach auf die Liste gesetzt werden, die dann sowohl Diebolt wie auch Agnes umfassen würde. In diesem Beispiel wurde auf Listen der Einfachheit halber verzichtet. - Sind diese Koreferenzen markiert, ist nun auch klar, wie z.B. die Familienbeziehung zwischen Agnes und Diebolt repräsentiert wird. - "seine Frau Agnes" *ist* "seine Frau" (Attribut) - "seine Frau" *hat Familienbeziehung mit* "seine" (Beziehung) - "seine" *ist* "Diebolt Rüly" (Koreferenz) -- Wir annotieren Beziehungen zwar textnah an den Erwähnungen, aber schlussendlich besteht damit zwischen den beiden Entitäten "Diebolt Rüly" und "Agnes" eine Beziehung vom Typ "FAM". - -![Annotation Example with Coreferences](./static/images/example_coref.png) -Bemerke, dass wir die Beziehungen REL.FAM, REL.OWNERSHIP und REL.LOC nicht nochmal annotieren müssen, sie werden durch die Attribute und Deskriptoren bereits verzeichnet. Beziehungen, die ausserhalb von Erwähnungen stattfinden (z.b. "Diebolt ist verheiratet mit Agnes") müssten wir hingegen explizit verzeichnen. - -### 1.8.5. Voll annotierte Ereignisse -Wie bei Beziehungen unterscheiden wir Annotation von Ereignissen in _einfacher_ und _voller_ Annotation. Je nach Definition unserer Ereignisse könnten wir hier ein Widmungs-Ereignis in _voller_ Annotation auszeichnen: - -EV.BEQUEST: -* * * -- Spanne: Der ganze Satz -- Trigger: "gewidmet" - - Der Trigger sollte möglichst kurz sein und sogleich das Ereignis möglichst gut beschreiben. Für die Wahl der Trigger siehe das Kapitel zur Ereignisannotation. -- Rolle BEQUEATHER: "Diebolt Rüly der Küfer" -- Rolle BEQUEATHER: "seine Frau Agnes" -- Rolle BENEFICIARY: "einander" -- Rolle PROPERTY: "ihr Haus & Hofstatt..." - -![Annotation Example with Event](./static/images/example_event.png) \ No newline at end of file +- Wir annotieren Beziehungen zwar textnah an den Erwähnungen, aber schlussendlich ist damit zwischen den beiden Entitäten "Diebolt Rüly" und "Agnes" eine Beziehung vom Typ "FAM" ableitbar. \ No newline at end of file diff --git a/2_entities.md b/2_entities.md deleted file mode 100644 index 7d507bc..0000000 --- a/2_entities.md +++ /dev/null @@ -1,580 +0,0 @@ ---- -title: 2. Entitäten -layout: default -nav_order: 3 ---- - -# 2. Entitäten - -Bei einer Entitäten-Annotation handelt es sich genau genommen um die -Annotation von *Erwähnungen* (Mentions). Von einer *Entität* kann man -erst sprechen, wenn bestimmt wurde, welche Erwähnungen -sich alle auf eine bestimmte Entität beziehen. - -Zur Annotation von Entitäten gehört einerseits die Information der Grenzen -der Erwähnung (Welche Token sind Teil der Erwähnung?), -wie auch die Kategorisierung der Erwähnung -in verschiedenen Kategorien, beschreiben in den folgenden Kapiteln und die -Identifikation des *Heads*, indem auch dessen Grenzen im Text festgehalten werden. - -## 2.1. Identifikation von Entitäten -Eine Entitäten-Erwähnung wird dann annotiert, wenn die Entität unter eine der festgelegten Entitäten-Klassen (Kapitel 2.9.) fällt. -In der Bestimmung der Abgrenzung der Erwähnung, d.h. welche Wörter mit zur Erwähnung gehören, folgen wir soweit möglich der syntaktischen Struktur des Satzes. -Eine Erwähnung besteht dementsprechend sowohl aus dem Kern (*Head*) sowie die diesen umgebende [[Nominalphrase]](https://de.wikipedia.org/wiki/Nominalphrase). Ein paar Beispiele um zu beschreiben, was Teil der Erwähnung ist: - -Beispiel: "\[Der alte Schmied\]"[^1]\ -Beispiel: "\[Die Witwe des Schmied\]"\ -Beispiel: "\[Des Schmieds Witwe\]"\ -Beispiel: "\[Das Haus in der Vorstadt\]"\ -Beispiel: "\[Das Haus, das in der Vorstadt liegt\]" - -Diese Erwähnungen können teils grosse Längen annehmen, gewisse Dokumententypen neigen dazu ihre Informationen stark zu verschachteln. Hier ein fiktives Beispiel, das aber z.B. im *Historischen Grundbuch der Stadt Basel* nicht unüblich wäre (die eckigen Klammern markieren die relevante Erwähnung): - -"Der Schaffner zu den Barfüssen hat \[Johannes Schmidlin des Gerbers Behausung samt der Schüren, genannt zum Roten Stern, gelegen in der Steinenvorstadt zwischen der Gerbern Zunfthaus und des Ulrich Zofingers des Schmieds Erben, zinst dem Kloster der Barfüsser 2 sh. alle Fronfasten, sonst frei\] um versessenen Zins wegen gefrönt." - - -## 2.2. Identifikation des *Heads* -Der *Head* markiert das syntaktisch zentrale Element der Erwähnung. Welcher Teil der Erwähnung der *Head* ist, -ist von der Erwähnungs-Klassifikation (Kapitel 2.3.) abhängig und wird in den dortigen Unterkapiteln erläutert. -Die Klassifikation einer Erwähnung wiederum bezieht sich exakt auf den *Head*. Informationen ausserhalb des *Head* können wiederum selbst als Erwähnungen, Werte oder Deskriptoren erfasst werden. *Head*-Elemente können keine weiteren Annotationen enthalten. - -Jede Erwähnung muss genau einen *Head* aufweisen, der aber mehrere Wörtern umfassen kann. - -## 2.3. Erwähnungs-Klassifikation (Mention Type) - -Die Erwähnungsklassifikation hält fest, auf welche Weise eine Entität -im Text genannt wird. - -Wir unterscheiden nach ACE-Vorbild unter den Erwähnungsarten: - -### 2.3.1. Eigennamen-Erwähnung (NAM) - -Hierbei handelt es sich um eine Erwähnung der Entität anhand ihres -Eigennamens. - -Beispiel: "\[Hans Schneider, der Karrer in Neuenburg -gesessen\]" - -Achtung, in einem solchen Fall handelt es sich nicht um eine -Eigennamennennung: - -Beispiel: "\[Der Hügel, Büttenberg genannt, liegt 3 Meilen -nördlich\]" - -Hier ist "Hügel" das syntaktisch zentrale Wort (*head*), während die -Eigennamenerwähnung in diesem Fall als Attributivnennung zu verzeichnen -wäre (Kapitel 2.7.). Die Erwähnung wäre in diesem Fall eine nominative -Erwähnung (Nächstes Kapitel). - -### 2.3.2. Nominative Erwähnung (NOM) - -Hierbei handelt es sich um eine Erwähnung anhand eines Nomens, welches kein Eigenname ist. - -Beispiel: "\[Der Schaffner des Spitals\]" - -Nominative Erwähnungen zeichnen sich oft dadurch aus, dass sie -Informationen zur Entität enthalten, wie den Beruf oder eine Beziehung -zu einer anderen Entität. Sie sollten in dem Fall mit einem passenden -Subtypen gekennzeichnet werden (Kapitel 2.9.). - -### 2.3.3. Pronominale Erwähnung (PRO) - -Hierbei handelt es sich um eine Erwähnung anhand eines Pronomens, häufig -ergänzt mit einer Beschreibung. - -Beispiel: "\[Der, dem der Heinzi zinst\]" - -Pronominalerwähnungen finden sich aber auch oft innerhalb anderer Erwähnungen -als Possessivpronomen. - -Beispiel: "\[\[seine\] Frau\]" - -#### 2.3.3.1. Spezialfall: Selbstreferenzierung (SELF) - -Wenn ein Pronomen die verfassende Instanz selbst referenziert, wird -statt PRO SELF verwendet. - -Beispiel: "\[Wir, \[Burgermeister und Rat -\[der Stadt Basel /NAM.GPE_ORG\] /NOM.ORG_GOV\] -/SELF.ORG_GOV\]" - -Die Entitätsklassifikation wird wie üblich ermittelt, was bedeutet, dass -im Text kein Hinweis auf die Klassifikation des Verfassers gegeben ist, -dieser als SELF.UNK annotiert werden sollte. - -Beispiel "\... \[die Helblings /NAM.PER..GRP\] -\[uns /SELF.UNK..GRP\] gegeben haben" - -### 2.3.4. Unbekannte Erwähnung (UNK) - -Aufgrund unleserlicher Schrift kann es vorkommen, dass die Erwähnung -nicht mehr zu entziffern ist, obwohl klar ist, dass es sich dabei um -eine Erwähnung handelt. Die Stelle kann dann als UNK gekennzeichnet -werden. - -### 2.3.5. Präzisierung der Erwähnung - -Im Falle von Nominalerwähnungen können wir zusätzliche Informationen -festhalten, indem wir die Erwähnungsart weiter präzisieren. Wir -versuchen dabei möglichst dieselben Klassen zu verwenden wie für -Beziehungen (Kapitel 4) und Deskriptoren (Kapitel 2.7.3), wobei wir noch -weitere Präzisierungen speziell zu diesem Zweck definieren. - -Wenn z.B. eine Person anhand einer Verwandschaftsbeziehung erwähnt wird -("seine Frau"), dann beinhaltet diese Nennung zugleich -eine Beziehung. Indem wir dieselben Klassennamen verwenden, vereinfachen -wir den Annotationsprozess (siehe Annotationsanleitung). - -Die passenden Präzisierungen sind abhängig von der -Entitätsklassifikation und werden aus diesem Grund in den entsprechenden -Kapiteln aufgelistet (Kapitel 2.5.). - -## 2.4. Ordinalität - -### 2.4.1. Einzelne Entität (SGL) - -Die Erwähnung betrifft eine einzelne Entität. - -Beispiel: "\[Heinzi Schneider\]" - -### 2.4.2. Mehrere Entitäten (GRP) - -Die Erwähnung betrifft eine Gruppe von Entitäten. - -Beispiel: "\[Die Nachbarn an der Gerbergassen wohnend\]" - -Wichtig ist bei GRP, sich der Abgrenzung zu den ORG-Entitäten bewusst zu -sein. Bei GRP handelt es sich normalerweise um Erwähnungen im Plural. -Bei ORG handelt es sich um "feste" Gruppierungen mit klaren Grenzen, die -auch meist langfristig definiert sind. Bei Familien zum Beispiel handelt -es sich nicht um GRP vom Typus PER, sondern um ORGs. - -### 2.4.3. Negierende Erwähnung (NEG) - -Die Erwähnung nennt die Entitäten auf negierende Weise. Oft unspezifisch -erwähnt. - -Beispiel: "\[Kein Kohlestürzer\] soll hier wohnen" - -## 2.5. Entitäts-Klassifikation - -Die Aufzählung aller Klassen des Basis-Schemas findet sich unter 2.9., -weitere Typen, die nur für bestimmte Projekte interessant sein könnten -unter 2.10. - -Ein Typus kann durch weitere Subtypen genauer definiert werden, im Falle -von Geopolitischen Entitäten ist ein solcher sogar Pflicht. - -## 2.6. Spezifität - -### 2.6.1. Spezifische Entität (SPC) - -Die Erwähnung bezieht sich auf eine spezifische "existierende" Entität. - -Beispiel: "\[Das Haus zum Wind\]" - -### 2.6.1. Unspezifische Entitäten (USPC) - -Die Erwähnung bezieht sich auf keine spezifische Entität. Beispiele -wären eine undefinierte Masse von Entitäten: - -Beispiel: "\[Viele Leute\] sagen..." - -Oder die Verwendung von "man" auf unspezifische Weise: - -Beispiel "Wenn \[man\] die Strasse Richtung Gerbergassen -geht" - -## 2.7. Referenzen / Attribute / Listen - -In BeNASch verwenden wir zur vollständigen Informationserfassung -verschachtelte Annotationen. Zudem halten wir neben den eigentlichen -Entitätserwähnungen auch weitere Informationen zu den Entitäten fest. -Wir unterscheiden hierbei zwischen Listen, Referenzen, Attributen und -Deskriptoren (Kapitel 2.9.). Attribute und Deskriptoren können nur innerhalb von -Listen, Referenzen und Attributen vorkommen. - -### 2.7.1. Referenzen (REF) - -Eine Referenz ist eine Erwähnung, die sich nicht auf dieselbe Entität -wie die darüberliegende Erwähnung bezieht. - -Beispiel: "\[der Schreiner /REF\]"[^2] - -Beispiel: "\[der Schaffner \[des Spitals -/REF\] /REF\]" - -### 2.7.2. Attribute (ATT) - -Bei einem Attribut handelt es sich um eine Erwähnung, die sich auf -dieselbe Entität bezieht wie die darüberliegende Erwähnung. - -Beispiel: "\[Heinzi Müller, \[der Schreiner -/ATT\] /REF\]" - -### 2.7.3. Listen (LST) - -Listen-Elemente dienen dem Zweck, Aufzählungen von Entitäten miteinander -zu verbinden und sie einfacher in Beziehung zu setzen, z.B. mit -Attributen, die sämtliche aufgezählte Entitäten betreffen. Ein Beispiel -verdeutlicht die Nutzung: - -Beispiel: "\[\[Heintzi Schneider\] und \[Johann -Ammann\], \[Nachbarn an \[der -Eisengasse\]\] /LST\]" - -Eine Liste enthält Verweise auf alle Erwähnungen, die Teil von ihr sind -(im obigen Beispiel also "Heintzi Schneider" und "Johann Ammann"). Ein -Attribut oder ein Deskriptor kann zudem eine Liste beschreiben, so wie sie sonst zu einer -anderen Erwähnung gehören können. - -Listen ähneln in ihrer Funktionsweise GRP-Erwähnungen, haben aber keinen -*Head*, dieser wird durch die Aufzählung der Entitäten ersetzt. List -können Erwähnungen von verschiedenen Klassifikationen enthalten. - -Beispiel: "\... zinst \[\[dem Predigerkloster /ORG\] und \[Johann von -Arx /PER\] /LST\] ..." - -Als Aufzählungen anzusehen sind Entitätenerwähnungen, welche durch -Konjunktionen (auch Kommas falls zutreffend) verbunden werden und damit -eine gemeinsame Rolle im Dokument einnehmen, z.B. als Verkäufer, -Zinsempfänger oder Ziel einer Beziehung. - -#### 2.7.3.1. Optionale Spezialtypen - -Für manche Projekte ist es praktisch, wenn neben -Konjunktivkonstruktionen weitere Listen-artige Konstruktionen als -LST-Spezialtypen klassifiziert werden können. Ein solcher Untertyp wäre -zum Beispiel LST.CONTRA, welcher bei manchen Gerichtsdokumenten zum -Einsatz kommt. - -Beispiel: "\[\[Heintzi Schneider\] contra \[Johann -Ammann\], \[Nachbarn an \[der -Eisengasse\]\] /LST\], betreffend ..." - -**LST.CONTRA** - -Verbindung von Entitäten über "contra", "gegen" oder ähnliches. - -## 2.8. Deskriptoren (DESC) -Text innerhalb von Entitätenerwähnungen, welche die Entität näher beschreiben, selbst aber keine Erwähnungen darstellt, wird als Deskriptor annotiert. Deskriptoren dienen in der Praxis auch dazu, Beziehungen und Ereignisse im Text zu verankern (Siehe die Anleitung in Kapitel 7 für Details). - -### 2.8.1. Deskriptor identifizieren -Deskriptoren können alle Klassifizierungen nutzen, welche für Erwähnungs-Präzisierungen, Beziehungen und Ereignisse zulässig sind.Auch weitere beschreibende Spannen können als UNK-Typ verzeichnet werden, falls notwendig. -Deskriptoren halten sich wie Entitätenerwähnungen an die Syntax. Deskriptoren entsprechen üblicherweise [[Adjektivphrasen]](https://de.wikipedia.org/wiki/Adjektivphrase). Zum Beispiel (die DESC-Spanne hier in geschweiften Klammern): - -Beispiel: "...hat \[das Haus, \{\[am Rhein\] gelegen\}\], gekauft." - -Aufgrund der speziellen Eigenschaften von vormodernem Deutsch können wir mit Deskriptoren aber auch andere beschreibende Textstellen markieren. Zum Beispiel wenn bei einem Relativsatz das einleitende Pronomen fehlt: - -Beispiel: "...hat \[Das Haus, \{\[am Rhein\] gelegen\}, \{zinst 5 sh. auf Martini\}\], gekauft." - -Beispiel: "\[Hans Peter \{selig\}\]" - - -## 2.9. Basis-Typologie zur Entitätsklassifikation - -Als Klassen definieren wir solche Kategorien, welche für alle oder -zumindest die meisten Projekte von Interesse sein sollten, und daher -immer annotiert werden sollten, wenn das volle Schema verwendet wird. - -Durch Unterklassen können die Klassen präziser definiert werden, wobei dies optional ist (Siehe Kapitel 2.7), -abgesehen von den Subklassen von GPE. - -### 2.9.1. Übersicht (alphabetisch) - -- GPE (Geopolitische Entitäten) - - GPE (im Kontext nicht unterscheidbar) - - LOC (im Kontext eines Ortes genannt) - - ORG (im Kontext einer handelnden Entität genannt) - - PER (Erwähnung der Bevölkerung des Gebiets) -- LOC (Orte) -- ORG (Organisationen) -- PER (Personen) - -### 2.9.2. Personen (PER) - -Wir annotieren Erwähnungen von einer oder mehrerer Personen mit der -PER-Abkürzung. Bei mehreren Personen ist die Unterscheidung zu beachten, -ab wann es sich nicht mehr um eine Gruppe von Personen handelt, die -erwähnt wird, sondern um eine Organisation im Sinne einer ORG. Oft -kann dies über die Ordinalität unterschieden werden. - -Beispiel PER+GRP: "\[Die Zimmerleute des Spitals\]" - -Beispiel ORG: "\[Die Gesellschaft der Schaffner des -Spitals\]" - -Ein wichtiger Spezialfall ist jedoch zu beachten, wenn eine Personengruppe semantisch für die Organisation selbst steht. Ein häufiger Fall aus dem *Historischen Grundbuch der Stadt Basel* wäre z.B. die Erwähnung von Klöstern (also Organisationen) als "Die Frauen von Klingenthal" oder "den Herren zu St. Peter". Decken sich diese Erwähnungen sinngemäss mit der Erwähnung der Klöster, werden sie als Organisationen, nicht als Personengruppen, erfasst.[^3] - -Dazu kommt noch die Unterscheidung von GPE.PER-Erwähnungen, welche dann -Vorrang haben, wenn Personen als Angehörige einer GPE genannt werden. - -Beispiel GPE.PER: "\[Die Berner\] gingen..." - -### 2.9.2.1. Erwähnungs-Präzisierungen für Personen -Hier folgen die etablierten Präzisierungen für PER-Erwähnungen. Sie sollten verwendet werden, wenn eine Entität als NOM, manchmal auch als PRO, erwähnt wird. Mehr zu Erwähnungs-Präzisierungen in Kapitel 2.3.5. - -#### 2.9.2.1.1. func (Funktion) - -Die Person wird durch eine langfristige Funktion beschrieben. *func* -dient dabei als Auffang-Subtyp, präzisere Tags wie *occ* dienen für -nähere Beschreibungen der Funktion. - -Beispiele ??? - -#### 2.9.2.1.2. occ (Beruf) - -Die Person wird durch ihren Beruf beschrieben. Es handelt sich hierbei -um eine Präzisierung von *func*. Ist nicht klar, ob es sich um einen -Beruf im eigentlichen Sinne handelt, sollte *func* verwendet werden. - -Beispiel Erwähnungspräzisierung: "\[der Schneider\] -sagte..." - -Beispiel Erwähnungspräzisierung: "\[Ulrich, \[der -Zimmermann\], zu \[Neuenburg\] gesessen\]" - -#### 2.9.2.1.3. org-aff (Organisationszugehörigkeit) - -Die Person wird durch eine passive Zugehörigkeit zu einer Organisation -beschrieben. - -Beispiel Erwähnungspräzision: "\[ein Bürger zu -\[Bern /REF.NAM.GPE_ORG\] /REF.NOM_ORG_AFF.PER\]" - -#### 2.9.2.1.4. org-job (Tätigkeit in Organisation) - -Die Person wird durch eine Tätigkeit für eine Organisation beschrieben. -Es handelt sich hierbei um eine Präzisierung von *org-aff*. - -Beispiel Erwähnungspräzision: "\[der Schaffner des -\[Spitals\]\]" - -#### 2.9.2.1.5. origin (Herkunft) - -Die Person wird durch einen Ort beschrieben. Dabei ist nicht klar, ob es -sich um den derzeitigen Wohnort oder Herkunftsort oder sogar einen -Beinamen handelt. - -Beispiel Erwähnungspräzision: "\[Der Dornacher\]" - -#### 2.9.2.1.6. owner (Besitztum) - -Die Person wird durch den Besitz von etwas beschrieben. - -#### 2.9.2.1.7. rel (Beziehung) - -Die Person wird durch eine langfristige Beziehung zu einer anderen -Person oder Personengruppe (nicht ORG!) beschrieben. Kapitel 2.10. -schlägt Präzisierungen vor für Projekte, welche insbesondere -interpersonelle Beziehungen untersuchen wollen. - -Beispiel Erwähnungspräzisierung: "\[Greta von Arx -\[\[Elisabeth von Arx \[selige\]\] -Tochter /ATT.NOM.REL\]\]" - -#### 2.9.2.1.8. title (Titulierung) - -Die Person wird durch einen Titel, den sie trägt, beschrieben. Dies -stellt eine Präzisierung von *func* dar. Wenn ein Titel gleichzeitig -auch eine berufliche Tätigkeit beschreibt, sollte *occ* verwendet -werden. - -Beispiel Erwähnungspräzisierung (Gleich zweimal): -"\[\[Herr\] Hans von Sehen, -\[Ritter\]\]" - -Manche Titel sind nur durch Kontext als solche erkennbar. Im obigen -Beispiel wird "Herr" als Titel annotiert, da Hans von Sehen im -unmittelbaren Kontext als Adliger erkennbar ist und "Herr" ihn als -solchen auszeichnet. Gerade in späteren Dokumenten wird "Herr" hingegen -als generelle Anrede verwendet, in welchem Fall es nicht als Titel zu -annotieren ist. - -### 2.9.3. Orte (LOC) - -Ein Ort wird als eine Entität definiert, zu, durch oder an welche man -gehen kann. Dazu zählen natürliche, fassbare, Orte wie Flüsse oder -Berge, aber auch menschengemachte Strukturen wie Häuser, Strassen und -Brücken, sowie nicht fassbare Konzepte wie geographische Regionen, solange sie -nicht gleichzeitig politische Entitäten sind. - -In Kapitel 2.10. finden sich Richtlinien für präzisere Klassifizierungen -von Orten, wie z.B. ein separater FAC-Tag für menschengemachte -Strukturen, sollte ein Projekt diese Unterscheidung wünschen. - -### 2.9.3.1. Erwähnungs-Präzisierungen für Orte - -Bisher gab es keinen Bedarf dafür. - -### 2.9.4. Organisationen (ORG) - -Organisationen unterscheiden sich von Gruppen, indem sie meist einen -Eigennamen besitzen und langfristige, etablierte Entitäten darstellen. -Im Gegensatz zu modernen Annotationsschemata können wir hierbei keine -Definition erklären, welche sich auf den "offiziellen" Status einer -Gruppierung bezieht. Insofern würden wir sagen, dass es sich dabei um -eine zu ihrer Zeit anerkannte Organisation handeln sollte. - -In Kapitel 2.10. werden Richtlinien für genauere Kategorisierungen von -Organisationen genannt, welche für gewisse Projekte wünschenswert sein -könnten, z.B. REL für Religiöse Organisationen wie Klöster oder Stifte. - -Organisationen können leicht mit PER.GRP verwechselt werden. ORG ist -dann angebracht, wenn sich die Erwähnung deutlich auf eine Organisation -als ganzes bezieht. So sollte "einige Augustiner" nicht als ORG -annotiert werden, sondern als PER.GRP, aber "zinst den Augustinern" -hingegen schon. - -Wichtig ist auch zu bemerken, dass gewisse Orte eng mit Organisationen -verbunden sein können. So existiert ein Kloster meist sowohl als -Organisation (der Orden) wie auch als Ort (das Gebäude). Diese -Erwähnungen sind jeweils entsprechend ihres Kontexts zu annotieren. - -### 2.9.4.1. Erwähnungs-Präzisierungen und Deskriptoren für Organisationen - -Bisher gab es keinen Bedarf dafür. - -### 2.9.5. Geopolitische Entitäten (GPE) - -Geopolitische Entitäten unterscheiden sich von anderen Entitäten in der -Hinsicht, dass dieselbe Entität sowohl in ihrer Rolle als Ort, als -Organisation oder auch als Personengruppe referenziert werden kann. Wir -verwenden in jedem Kontext die Annotation *GPE*, aber versehen diese mit -einem entsprechenden Subtyp. Dieses Problem wird in den ACE-Guidelines -genauer besprochen, wir fassen es hier aber nochmal zusammen. - -#### 2.9.5.1. GPE - -In manchen Fällen wird die GPE direkt referenziert. In diesem Fall -verwenden wir GPE.GPE als Annotation. - -Beispiel: "Es unterschreiben \[die Orte -\[Basel\], \[Bern\], -\[Zürich\]\]" - -#### 2.9.5.2. LOC - -Wird die GPE im Sinne einer LOC genannt, verwenden wir GPE.LOC. - -Beispiel: "\[Ulrich \[der Schneider\] -gesessen zu \[Neuenburg\]\]" - -Wir verwenden in diesem Fall die Subtypen, welche auch für LOC-Entitäten -gelten. - -#### 2.9.5.3. ORG - -Wird die GPE im Sinne einer ORG genannt, verwenden wir GPE.ORG. - -Beispiel: "\[Bürger zu \[Basel\]\] - -Wir verwenden in diesem Fall die Subtypen, welche auch für ORG-Entitäten -gelten. - -#### 2.9.5.4. PER - -Wird die Bevölkerung einer Stadt referenziert, verwenden wir GPE.PER. - -Beispiel: "\[Die Berner\]" - -## 2.10. Optionale Entitäts-Klassen - -### 2.10.1. LOC-Subtypen - -#### 2.10.1.1. Menschengemachte Strukturen (FAC) - -Mit FAC werden Orte annotiert, die von Menschen geschaffen wurden. Das -schliesst sowohl Gebäude als auch Strassen und Plätze ein. - -Beispiel: "\[Die Behausung in \[der S. Alban -Vorstatt\]\]" - -#### 2.10.1.2. Wasserkörper (WAT) - -#### 2.10.1.3. Natürliche Region (GEO) - -Natürliche Regionen sind definiert durch geologische oder ökologische -Eigenheiten. Dazu zählen z.B. Berge, Gebirge, aber auch Wälder. - -#### 2.10.1.4. Künstliche Region (REG) - -Künstliche Regionen definieren sich nicht primär durch geologische oder -ökologische Eigenheiten, stellen aber auch keine geopolitischen -Entitäten dar. Denkbar wären hier z.B. "das Zürichgau". - -#### 2.10.1.5. Himmelskörper (ASTR) - -Mit ASTR werden Erwähnungen von Himmelskörpern gekennzeichnet. "Die -Sonne", "Der Mond". - -#### 2.10.1.6. Grenze (BOR) - -Mit BOR werden Orte gekennzeichnet, die Grenzen zwischen anderen Orten -darstellen, insbesondere zwischen GPEs. - -### 2.10.2. ORG-Subtypen - -#### 2.10.2.1. Regierungsorganisationen (GOV) - -Mit GOV werden Erwähnungen annotiert, die nicht Regierungen als ganzes -betreffen (dazu ist GPE_ORG da), sondern nur Teile der Regierung, selbst -wenn diese eine führende Position innehaben. - -Beispiel: "\[Mr . Lienhart Bientz \[der -Rebman\], \[des Rats /NOM.ORG_GOV\]\]" - -#### 2.10.2.2. Religiöse Organisationen (REL) - -Unter REL fallen Organisationen wie Stifte und Klöster. - -Beispiel: "\... zinst von eigenschaft zu \[S. Claren\]" - -#### 2.10.2.3. Zünfte, Berufsverbände (OCC) - -Mit OCC werden Erwähnungen, die auf Zünfte und Berufsverbände verweisen, -annotiert. - -#### 2.10.2.4. Familien (FAM) - -### 2.10.3. PER: *rel*-Präzisierungen - -#### 2.10.3.1. Verwandtschaft (family) - -Unter diese Präzisierung fallen Bezeichnung, die der heutigen Definition -einer familiären Beziehung entsprechen, also Geschwister, Eltern, -Kinder, etc. Für die Bezeichnung einer Person durch die Ehe oder festen -Partnerschaft zu einer anderen Person gibt es zudem den Tag *married* - -#### 2.10.3.2. Verheiratet (married) - -Unter married fallen Beschreibungen von Personen durch feste -Partnerschaften oder Ehe. - -Beispiel: "\[Jerg Holzman\], und \[\[seine\] -Frau /NOM.PER.married\]" - -## 2.11. Komplizierte Fälle - -### 2.11.1 Mehrere Personen mit nur einem genannten Nachnamen - -Beispiel: "Hedwig und Bertschi Eberli" - -Werden zwei Personen genannt, aber nur bei einer der Familienname -beschrieben, folgen wir den Prinzipien der textnahen Annotation. - -Beispiel: "\[\[Hedwig /PER] und \[Bertschi Eberli /PER] /LST]" - -Für weitere Informationen siehe [Diskussion](https://github.com/raykyn/BeNASch/issues/11) - ---- - -[^1]: In Beispielen zeigen die eckigen Klammern eine Annotation an, eine - Unterstreichung markiert den *head*. Etwaige weitere Annotationen im - Beispiel werden weggelassen, wenn sie für das Beispiel nicht - relevant sind. - -[^2]: Hinter dem / steht eine allfällige Klassifizierung. - -[^3]: [[Diskussion: Personengruppen, die ORGs repräsentieren]](https://github.com/raykyn/BeNASch/issues/2) \ No newline at end of file diff --git a/2_entities/2_1_entity_annotation.md b/2_entities/2_1_entity_annotation.md new file mode 100644 index 0000000..82bbba0 --- /dev/null +++ b/2_entities/2_1_entity_annotation.md @@ -0,0 +1,283 @@ +--- +title: 2.1. Entitäten +layout: default +nav_order: 1 +--- + +# 2.1. Entitäten + +## 2.1.1. Identifikation von Entitäten +Eine Entitäten-Erwähnung wird dann annotiert, wenn die Entität unter eine der festgelegten Entitäten-Klassen (Kapitel 2.9.) fällt. +In der Bestimmung der Abgrenzung der Erwähnung, d.h. welche Wörter mit zur Erwähnung gehören, folgen wir soweit möglich der syntaktischen Struktur des Satzes. +Eine Erwähnung besteht dementsprechend sowohl aus dem Kern (*Head*) sowie die diesen umgebende [[Nominalphrase]](https://de.wikipedia.org/wiki/Nominalphrase). Ein paar Beispiele um zu beschreiben, was Teil der Erwähnung ist: + +Beispiel: "\[Der alte Schmied\]"[^1]\ +Beispiel: "\[Die Witwe des Schmied\]"\ +Beispiel: "\[Des Schmieds Witwe\]"\ +Beispiel: "\[Das Haus in der Vorstadt\]"\ +Beispiel: "\[Das Haus, das in der Vorstadt liegt\]" + +Diese Erwähnungen können teils grosse Längen annehmen, gewisse Dokumententypen neigen dazu ihre Informationen stark zu verschachteln. Hier ein fiktives Beispiel, das aber z.B. im *Historischen Grundbuch der Stadt Basel* nicht unüblich wäre (die eckigen Klammern markieren die relevante Erwähnung): + +"Der Schaffner zu den Barfüssen hat \[Johannes Schmidlin des Gerbers Behausung samt der Schüren, genannt zum Roten Stern, gelegen in der Steinenvorstadt zwischen der Gerbern Zunfthaus und des Ulrich Zofingers des Schmieds Erben, zinst dem Kloster der Barfüsser 2 sh. alle Fronfasten, sonst frei\] um versessenen Zins wegen gefrönt." + + +## 2.1.2. Identifikation des *Heads* +Der *Head* markiert das syntaktisch zentrale Element der Erwähnung. Welcher Teil der Erwähnung der *Head* ist, +ist von der Erwähnungs-Klassifikation (Kapitel 2.3.) abhängig und wird in den dortigen Unterkapiteln erläutert. +Die Klassifikation einer Erwähnung wiederum bezieht sich exakt auf den *Head*. Informationen ausserhalb des *Head* können wiederum selbst als Erwähnungen, Werte oder Deskriptoren erfasst werden. *Head*-Elemente können keine weiteren Annotationen enthalten. + +Jede Erwähnung muss genau einen *Head* aufweisen, der aber mehrere Wörtern umfassen kann. + +## 2.1.3. Erwähnungs-Klassifikation (Mention Type) + +Die Erwähnungsklassifikation hält fest, auf welche Weise eine Entität +im Text genannt wird. + +Wir unterscheiden nach ACE-Vorbild unter den Erwähnungsarten: + +### 2.1.3.1. Eigennamen-Erwähnung (NAM) + +Hierbei handelt es sich um eine Erwähnung der Entität anhand ihres +Eigennamens. + +Beispiel: "\[Hans Schneider, der Karrer in Neuenburg +gesessen\]" + +Achtung, in einem solchen Fall handelt es sich nicht um eine +Eigennamennennung: + +Beispiel: "\[Der Hügel, Büttenberg genannt, liegt 3 Meilen +nördlich\]" + +Hier ist "Hügel" das syntaktisch zentrale Wort (*head*), während die +Eigennamenerwähnung in diesem Fall als Attributivnennung zu verzeichnen +wäre (Kapitel 2.7.). Die Erwähnung wäre in diesem Fall eine nominative +Erwähnung (Nächstes Kapitel). + +### 2.1.3.2. Nominative Erwähnung (NOM) + +Hierbei handelt es sich um eine Erwähnung anhand eines Nomens, welches kein Eigenname ist. + +Beispiel: "\[Der Schaffner des Spitals\]" + +Nominative Erwähnungen zeichnen sich oft dadurch aus, dass sie +Informationen zur Entität enthalten, wie den Beruf oder eine Beziehung +zu einer anderen Entität. Sie sollten in dem Fall mit einem passenden +Subtypen gekennzeichnet werden (Kapitel 2.9.). + +### 2.1.3.3. Pronominale Erwähnung (PRO) + +Hierbei handelt es sich um eine Erwähnung anhand eines Pronomens, häufig +ergänzt mit einer Beschreibung. + +Beispiel: "\[Der, dem der Heinzi zinst\]" + +Pronominalerwähnungen finden sich aber auch oft innerhalb anderer Erwähnungen +als Possessivpronomen. + +Beispiel: "\[\[seine\] Frau\]" + +#### 2.1.3.3.1. Spezialfall: Selbstreferenzierung (SELF) + +Wenn ein Pronomen die verfassende Instanz selbst referenziert, wird +statt PRO SELF verwendet. + +Beispiel: "\[Wir, \[Burgermeister und Rat +\[der Stadt Basel /NAM.GPE_ORG\] /NOM.ORG_GOV\] +/SELF.ORG_GOV\]" + +Die Entitätsklassifikation wird wie üblich ermittelt, was bedeutet, dass +im Text kein Hinweis auf die Klassifikation des Verfassers gegeben ist, +dieser als SELF.UNK annotiert werden sollte. + +Beispiel "\... \[die Helblings /NAM.PER..GRP\] +\[uns /SELF.UNK..GRP\] gegeben haben" + +### 2.1.3.4. Unbekannte Erwähnung (UNK) + +Aufgrund unleserlicher Schrift kann es vorkommen, dass die Erwähnung +nicht mehr zu entziffern ist, obwohl klar ist, dass es sich dabei um +eine Erwähnung handelt. Die Stelle kann dann als UNK gekennzeichnet +werden. + +### 2.1.3.5. Präzisierung der Erwähnung + +Im Falle von Nominalerwähnungen können wir zusätzliche Informationen +festhalten, indem wir die Erwähnungsart weiter präzisieren. Wir +versuchen dabei möglichst dieselben Klassen zu verwenden wie für +Zustände (Kapitel 4) und Deskriptoren (Kapitel 2.7.3), wobei wir noch +weitere Präzisierungen speziell zu diesem Zweck definieren. + +Wenn z.B. eine Person anhand einer Verwandschaftsbeziehung erwähnt wird +("seine Frau"), dann beinhaltet diese Nennung zugleich +einen Zustand. Indem wir dieselben Klassennamen verwenden, vereinfachen +wir den Annotationsprozess (siehe Annotationsanleitung). + +Die passenden Präzisierungen sind abhängig von der +Entitätsklassifikation und werden aus diesem Grund in den entsprechenden +Kapiteln aufgelistet (Kapitel 2.5.). + +## 2.1.4. Ordinalität + +### 2.1.4.1. Einzelne Entität (SGL) + +Die Erwähnung betrifft eine einzelne Entität. + +Beispiel: "\[Heinzi Schneider\]" + +### 2.1.4.2. Mehrere Entitäten (GRP) + +Die Erwähnung betrifft eine Gruppe von Entitäten. + +Beispiel: "\[Die Nachbarn an der Gerbergassen wohnend\]" + +Wichtig ist bei GRP, sich der Abgrenzung zu den ORG-Entitäten bewusst zu +sein. Bei GRP handelt es sich normalerweise um Erwähnungen im Plural. +Bei ORG handelt es sich um "feste" Gruppierungen mit klaren Grenzen, die +auch meist langfristig definiert sind. Bei Familien zum Beispiel handelt +es sich nicht um GRP vom Typus PER, sondern um ORGs. + +### 2.1.4.3. Negierende Erwähnung (NEG) + +Die Erwähnung nennt die Entitäten auf negierende Weise. Oft unspezifisch +erwähnt. + +Beispiel: "\[Kein Kohlestürzer\] soll hier wohnen" + +## 2.1.5. Entitäts-Klassifikation + +Die Aufzählung aller Klassen, Basis und Optional, findet sich in Kapitel 2.2. + +Eine Klasse kann durch weitere Unterklassen genauer definiert werden, im Falle +von Geopolitischen Entitäten ist eine solche sogar Pflicht. + +## 2.1.6. Spezifität + +### 2.1.6.1. Spezifische Entität (SPC) + +Die Erwähnung bezieht sich auf eine spezifische "existierende" Entität. + +Beispiel: "\[Das Haus zum Wind\]" + +### 2.1.6.1. Unspezifische Entitäten (USPC) + +Die Erwähnung bezieht sich auf keine spezifische Entität. Beispiele +wären eine undefinierte Masse von Entitäten: + +Beispiel: "\[Viele Leute\] sagen..." + +Oder die Verwendung von "man" auf unspezifische Weise: + +Beispiel "Wenn \[man\] die Strasse Richtung Gerbergassen +geht" + +## 2.1.7. Referenzen / Attribute / Listen + +In BeNASch verwenden wir zur vollständigen Informationserfassung +verschachtelte Annotationen. Zudem halten wir neben den eigentlichen +Entitätserwähnungen auch weitere Informationen zu den Entitäten fest. +Wir unterscheiden hierbei zwischen Listen, Referenzen, Attributen und +Deskriptoren (Kapitel 2.9.). Attribute und Deskriptoren können nur innerhalb von +Listen, Referenzen und Attributen vorkommen. + +### 2.1.7.1. Referenzen (REF) + +Eine Referenz ist eine Erwähnung, die sich nicht auf dieselbe Entität +wie die darüberliegende Erwähnung bezieht. + +Beispiel: "\[der Schreiner /REF\]"[^2] + +Beispiel: "\[der Schaffner \[des Spitals +/REF\] /REF\]" + +### 2.1.7.2. Attribute (ATT) + +Bei einem Attribut handelt es sich um eine Erwähnung, die sich auf +dieselbe Entität bezieht wie die darüberliegende Erwähnung. + +Beispiel: "\[Heinzi Müller, \[der Schreiner +/ATT\] /REF\]" + +### 2.1.7.3. Listen (LST) + +Listen-Elemente dienen dem Zweck, Aufzählungen von Entitäten miteinander +zu verbinden und sie einfacher in Beziehung zu setzen, z.B. mit +Attributen, die sämtliche aufgezählte Entitäten betreffen. Ein Beispiel +verdeutlicht die Nutzung: + +Beispiel: "\[\[Heintzi Schneider\] und \[Johann +Ammann\], \[Nachbarn an \[der +Eisengasse\]\] /LST\]" + +Eine Liste enthält Verweise auf alle Erwähnungen, die Teil von ihr sind +(im obigen Beispiel also "Heintzi Schneider" und "Johann Ammann"). Ein +Attribut oder ein Deskriptor kann zudem eine Liste beschreiben, so wie sie sonst zu einer +anderen Erwähnung gehören können. + +Listen ähneln in ihrer Funktionsweise GRP-Erwähnungen, haben aber keinen +*Head*, dieser wird durch die Aufzählung der Entitäten ersetzt. List +können Erwähnungen von verschiedenen Klassifikationen enthalten. + +Beispiel: "\... zinst \[\[dem Predigerkloster /ORG\] und \[Johann von +Arx /PER\] /LST\] ..." + +Als Aufzählungen anzusehen sind Entitätenerwähnungen, welche durch +Konjunktionen (auch Kommas falls zutreffend) verbunden werden und damit +eine gemeinsame Rolle im Dokument einnehmen, z.B. als Verkäufer, +Zinsempfänger oder Ziel einer Beziehung. + +#### 2.1.7.3.1. Optionale Spezialtypen + +Für manche Projekte ist es praktisch, wenn neben +Konjunktivkonstruktionen weitere Listen-artige Konstruktionen als +LST-Spezialtypen klassifiziert werden können. Ein solcher Untertyp wäre +zum Beispiel LST.CONTRA, welcher bei manchen Gerichtsdokumenten zum +Einsatz kommt. + +Beispiel: "\[\[Heintzi Schneider\] contra \[Johann +Ammann\], \[Nachbarn an \[der +Eisengasse\]\] /LST\], betreffend ..." + +**LST.CONTRA** + +Verbindung von Entitäten über "contra", "gegen" oder ähnliches. + +## 2.1.8. Deskriptoren (DESC) +Text innerhalb von Entitätenerwähnungen, welche die Entität näher beschreiben, selbst aber keine Erwähnungen darstellt, wird als Deskriptor annotiert. Deskriptoren dienen in der Praxis auch dazu, Zustände und Ereignisse im Text zu verankern (Siehe die Anleitung in Kapitel 7 für Details). + +### 2.1.8.1. Deskriptor identifizieren +Deskriptoren können alle Klassifizierungen nutzen, welche für Erwähnungs-Präzisierungen, Zustände und Ereignisse zulässig sind. Auch weitere beschreibende Spannen können als UNK-Typ verzeichnet werden, falls notwendig. +Deskriptoren halten sich wie Entitätenerwähnungen an die Syntax. Deskriptoren entsprechen üblicherweise [[Adjektivphrasen]](https://de.wikipedia.org/wiki/Adjektivphrase). Zum Beispiel (die DESC-Spanne hier in geschweiften Klammern): + +Beispiel: "...hat \[das Haus, \{\[am Rhein\] gelegen\}\], gekauft." + +Aufgrund der speziellen Eigenschaften von vormodernem Deutsch können wir mit Deskriptoren aber auch andere beschreibende Textstellen markieren. Zum Beispiel wenn bei einem Relativsatz das einleitende Pronomen fehlt: + +Beispiel: "...hat \[Das Haus, \{\[am Rhein\] gelegen\}, \{zinst 5 sh. auf Martini\}\], gekauft." + +Beispiel: "\[Hans Peter \{selig\}\]" + + +## 2.1.9. Komplizierte Fälle + +### 2.1.9.1 Mehrere Personen mit nur einem genannten Nachnamen + +Beispiel: "Hedwig und Bertschi Eberli" + +Werden zwei Personen genannt, aber nur bei einer der Familienname +beschrieben, folgen wir den Prinzipien der textnahen Annotation. + +Beispiel: "\[\[Hedwig /PER] und \[Bertschi Eberli /PER] /LST]" + +Für weitere Informationen siehe [Diskussion](https://github.com/raykyn/BeNASch/issues/11) + +--- + +[^1]: In Beispielen zeigen die eckigen Klammern eine Annotation an, eine + Unterstreichung markiert den *head*. Etwaige weitere Annotationen im + Beispiel werden weggelassen, wenn sie für das Beispiel nicht + relevant sind. + +[^2]: Hinter dem / steht eine allfällige Klassifizierung. + diff --git a/2_entities/2_2_entity_typology.md b/2_entities/2_2_entity_typology.md new file mode 100644 index 0000000..071e7d1 --- /dev/null +++ b/2_entities/2_2_entity_typology.md @@ -0,0 +1,293 @@ +--- +title: 2.2. Entitäten-Typologie +layout: default +nav_order: 2 +--- + +# 2.2. Entitäten-Typologie + +## 2.2.1. Basis-Typologie zur Entitätsklassifikation + +Als Basis-Klassen definieren wir solche Kategorien, welche für alle oder +zumindest die meisten Projekte von Interesse sein sollten, und daher +immer annotiert werden sollten, wenn das volle Schema verwendet wird. + +Durch Unterklassen können die Klassen präziser definiert werden. + +### 2.2.1.1. Übersicht (alphabetisch) + +- GPE (Geopolitische Entitäten) + - GPE (im Kontext nicht unterscheidbar) + - LOC (im Kontext eines Ortes genannt) + - ORG (im Kontext einer handelnden Entität genannt) + - PER (Erwähnung der Bevölkerung des Gebiets) +- LOC (Orte) +- ORG (Organisationen) +- PER (Personen) + +### 2.2.1.2. Personen (PER) + +Wir annotieren Erwähnungen von einer oder mehrerer Personen mit der +PER-Abkürzung. Bei mehreren Personen ist die Unterscheidung zu beachten, +ab wann es sich nicht mehr um eine Gruppe von Personen handelt, die +erwähnt wird, sondern um eine Organisation im Sinne einer ORG. Oft +kann dies über die Ordinalität unterschieden werden. + +Beispiel PER+GRP: "\[Die Zimmerleute des Spitals\]" + +Beispiel ORG: "\[Die Gesellschaft der Schaffner des +Spitals\]" + +Ein wichtiger Spezialfall ist jedoch zu beachten, wenn eine Personengruppe semantisch für die Organisation selbst steht. Ein häufiger Fall aus dem *Historischen Grundbuch der Stadt Basel* wäre z.B. die Erwähnung von Klöstern (also Organisationen) als "Die Frauen von Klingenthal" oder "den Herren zu St. Peter". Decken sich diese Erwähnungen sinngemäss mit der Erwähnung der Klöster, werden sie als Organisationen, nicht als Personengruppen, erfasst.[^1] + +Dazu kommt noch die Unterscheidung von GPE.PER-Erwähnungen, welche dann +Vorrang haben, wenn Personen als Angehörige einer GPE genannt werden. + +Beispiel GPE.PER: "\[Die Berner\] gingen..." + +### 2.2.1.2.1. Erwähnungs-Präzisierungen für Personen +Hier folgen die etablierten Präzisierungen für PER-Erwähnungen. Sie sollten verwendet werden, wenn eine Entität als NOM, manchmal auch als PRO, erwähnt wird. Mehr zu Erwähnungs-Präzisierungen in Kapitel 2.3.5. + +#### 2.2.1.2.1.1. func (Funktion) + +Die Person wird durch eine langfristige Funktion beschrieben. *func* +dient dabei als Auffang-Subtyp, präzisere Tags wie *occ* dienen für +nähere Beschreibungen der Funktion. + +Beispiele ??? + +#### 2.2.1.2.1.2. occ (Beruf) + +Die Person wird durch ihren Beruf beschrieben. Es handelt sich hierbei +um eine Präzisierung von *func*. Ist nicht klar, ob es sich um einen +Beruf im eigentlichen Sinne handelt, sollte *func* verwendet werden. + +Beispiel Erwähnungspräzisierung: "\[der Schneider\] +sagte..." + +Beispiel Erwähnungspräzisierung: "\[Ulrich, \[der +Zimmermann\], zu \[Neuenburg\] gesessen\]" + +#### 2.2.1.2.1.3. org-aff (Organisationszugehörigkeit) + +Die Person wird durch eine passive Zugehörigkeit zu einer Organisation +beschrieben. + +Beispiel Erwähnungspräzision: "\[ein Bürger zu +\[Bern /REF.NAM.GPE_ORG\] /REF.NOM_ORG_AFF.PER\]" + +#### 2.2.1.2.1.4. org-job (Tätigkeit in Organisation) + +Die Person wird durch eine Tätigkeit für eine Organisation beschrieben. +Es handelt sich hierbei um eine Präzisierung von *org-aff*. + +Beispiel Erwähnungspräzision: "\[der Schaffner des +\[Spitals\]\]" + +#### 2.2.1.2.1.5. origin (Herkunft) + +Die Person wird durch einen Ort beschrieben. Dabei ist nicht klar, ob es +sich um den derzeitigen Wohnort oder Herkunftsort oder sogar einen +Beinamen handelt. + +Beispiel Erwähnungspräzision: "\[Der Dornacher\]" + +#### 2.2.1.2.1.6. owner (Besitztum) + +Die Person wird durch den Besitz von etwas beschrieben. + +#### 2.2.1.2.1.7. rel (Beziehung) + +Die Person wird durch eine langfristige Beziehung zu einer anderen +Person oder Personengruppe (nicht ORG!) beschrieben. Kapitel 2.10. +schlägt Präzisierungen vor für Projekte, welche insbesondere +interpersonelle Beziehungen untersuchen wollen. + +Beispiel Erwähnungspräzisierung: "\[Greta von Arx +\[\[Elisabeth von Arx \[selige\]\] +Tochter /ATT.NOM.REL\]\]" + +#### 2.2.1.2.1.8. title (Titulierung) + +Die Person wird durch einen Titel, den sie trägt, beschrieben. Dies +stellt eine Präzisierung von *func* dar. Wenn ein Titel gleichzeitig +auch eine berufliche Tätigkeit beschreibt, sollte *occ* verwendet +werden. + +Beispiel Erwähnungspräzisierung (Gleich zweimal): +"\[\[Herr\] Hans von Sehen, +\[Ritter\]\]" + +Manche Titel sind nur durch Kontext als solche erkennbar. Im obigen +Beispiel wird "Herr" als Titel annotiert, da Hans von Sehen im +unmittelbaren Kontext als Adliger erkennbar ist und "Herr" ihn als +solchen auszeichnet. Gerade in späteren Dokumenten wird "Herr" hingegen +als generelle Anrede verwendet, in welchem Fall es nicht als Titel zu +annotieren ist. + +### 2.2.1.3. Orte (LOC) + +Ein Ort wird als eine Entität definiert, zu, durch oder an welche man +gehen kann. Dazu zählen natürliche, fassbare, Orte wie Flüsse oder +Berge, aber auch menschengemachte Strukturen wie Häuser, Strassen und +Brücken, sowie nicht fassbare Konzepte wie geographische Regionen, solange sie +nicht gleichzeitig politische Entitäten sind. + +In Kapitel 2.10. finden sich Richtlinien für präzisere Klassifizierungen +von Orten, wie z.B. ein separater FAC-Tag für menschengemachte +Strukturen, sollte ein Projekt diese Unterscheidung wünschen. + +### 2.2.1.3.1. Erwähnungs-Präzisierungen für Orte + +Bisher gab es keinen Bedarf dafür. + +### 2.2.1.4. Organisationen (ORG) + +Organisationen unterscheiden sich von Gruppen, indem sie meist einen +Eigennamen besitzen und langfristige, etablierte Entitäten darstellen. +Im Gegensatz zu modernen Annotationsschemata können wir hierbei keine +Definition erklären, welche sich auf den "offiziellen" Status einer +Gruppierung bezieht. Insofern würden wir sagen, dass es sich dabei um +eine zu ihrer Zeit anerkannte Organisation handeln sollte. + +In Kapitel 2.10. werden Richtlinien für genauere Kategorisierungen von +Organisationen genannt, welche für gewisse Projekte wünschenswert sein +könnten, z.B. REL für Religiöse Organisationen wie Klöster oder Stifte. + +Organisationen können leicht mit PER.GRP verwechselt werden. ORG ist +dann angebracht, wenn sich die Erwähnung deutlich auf eine Organisation +als ganzes bezieht. So sollte "einige Augustiner" nicht als ORG +annotiert werden, sondern als PER.GRP, aber "zinst den Augustinern" +hingegen schon. + +Wichtig ist auch zu bemerken, dass gewisse Orte eng mit Organisationen +verbunden sein können. So existiert ein Kloster meist sowohl als +Organisation (der Orden) wie auch als Ort (das Gebäude). Diese +Erwähnungen sind jeweils entsprechend ihres Kontexts zu annotieren. + +### 2.2.1.4.1. Erwähnungs-Präzisierungen und Deskriptoren für Organisationen + +Bisher gab es keinen Bedarf dafür. + +### 2.2.1.5. Geopolitische Entitäten (GPE) + +Geopolitische Entitäten unterscheiden sich von anderen Entitäten in der +Hinsicht, dass dieselbe Entität sowohl in ihrer Rolle als Ort, als +Organisation oder auch als Personengruppe referenziert werden kann. Wir +verwenden in jedem Kontext die Annotation *GPE*, aber versehen diese mit +einem entsprechenden Subtyp. Dieses Problem wird in den ACE-Guidelines +genauer besprochen, wir fassen es hier aber nochmal zusammen. + +#### 2.2.1.5.1. GPE + +In manchen Fällen wird die GPE direkt referenziert. In diesem Fall +verwenden wir GPE.GPE als Annotation. + +Beispiel: "Es unterschreiben \[die Orte +\[Basel\], \[Bern\], +\[Zürich\]\]" + +#### 2.2.1.5.2. LOC + +Wird die GPE im Sinne einer LOC genannt, verwenden wir GPE.LOC. + +Beispiel: "\[Ulrich \[der Schneider\] +gesessen zu \[Neuenburg\]\]" + +Wir verwenden in diesem Fall die Subtypen, welche auch für LOC-Entitäten +gelten. + +#### 2.2.1.5.3. ORG + +Wird die GPE im Sinne einer ORG genannt, verwenden wir GPE.ORG. + +Beispiel: "\[Bürger zu \[Basel\]\] + +Wir verwenden in diesem Fall die Subtypen, welche auch für ORG-Entitäten +gelten. + +#### 2.2.1.5.4. PER + +Wird die Bevölkerung einer Stadt referenziert, verwenden wir GPE.PER. + +Beispiel: "\[Die Berner\]" + +## 2.2.2. Optionale Entitäts-Klassen + +### 2.2.2.1. LOC-Subtypen + +#### 2.2.2.1.1. Menschengemachte Strukturen (FAC) + +Mit FAC werden Orte annotiert, die von Menschen geschaffen wurden. Das +schliesst sowohl Gebäude als auch Strassen und Plätze ein. + +Beispiel: "\[Die Behausung in \[der S. Alban +Vorstatt\]\]" + +#### 2.2.2.1.2. Wasserkörper (WAT) + +#### 2.2.2.1.3. Natürliche Region (GEO) + +Natürliche Regionen sind definiert durch geologische oder ökologische +Eigenheiten. Dazu zählen z.B. Berge, Gebirge, aber auch Wälder. + +#### 2.2.2.1.4. Künstliche Region (REG) + +Künstliche Regionen definieren sich nicht primär durch geologische oder +ökologische Eigenheiten, stellen aber auch keine geopolitischen +Entitäten dar. Denkbar wären hier z.B. "das Zürichgau". + +#### 2.2.2.1.5. Himmelskörper (ASTR) + +Mit ASTR werden Erwähnungen von Himmelskörpern gekennzeichnet. "Die +Sonne", "Der Mond". + +#### 2.2.2.1.6. Grenze (BOR) + +Mit BOR werden Orte gekennzeichnet, die Grenzen zwischen anderen Orten +darstellen, insbesondere zwischen GPEs. + +### 2.2.2.2. ORG-Subtypen + +#### 2.2.2.2.1. Regierungsorganisationen (GOV) + +Mit GOV werden Erwähnungen annotiert, die nicht Regierungen als ganzes +betreffen (dazu ist GPE_ORG da), sondern nur Teile der Regierung, selbst +wenn diese eine führende Position innehaben. + +Beispiel: "\[Mr . Lienhart Bientz \[der +Rebman\], \[des Rats /NOM.ORG_GOV\]\]" + +#### 2.2.2.2.2. Religiöse Organisationen (REL) + +Unter REL fallen Organisationen wie Stifte und Klöster. + +Beispiel: "\... zinst von eigenschaft zu \[S. Claren\]" + +#### 2.2.2.2.3. Zünfte, Berufsverbände (OCC) + +Mit OCC werden Erwähnungen, die auf Zünfte und Berufsverbände verweisen, +annotiert. + +#### 2.2.2.2.4. Familien (FAM) + +### 2.2.2.3. PER: *rel*-Präzisierungen + +#### 2.2.2.3.1. Verwandtschaft (family) + +Unter diese Präzisierung fallen Bezeichnung, die der heutigen Definition +einer familiären Beziehung entsprechen, also Geschwister, Eltern, +Kinder, etc. Für die Bezeichnung einer Person durch die Ehe oder festen +Partnerschaft zu einer anderen Person gibt es zudem den Tag *married* + +#### 2.2.2.3.2. Verheiratet (married) + +Unter married fallen Beschreibungen von Personen durch feste +Partnerschaften oder Ehe. + +Beispiel: "\[Jerg Holzman\], und \[\[seine\] +Frau /NOM.PER.married\]" + +--- + +[^1]: [[Diskussion: Personengruppen, die ORGs repräsentieren]](https://github.com/raykyn/BeNASch/issues/2) \ No newline at end of file diff --git a/2_entities/2_3_coreferences.md b/2_entities/2_3_coreferences.md new file mode 100644 index 0000000..6b9b152 --- /dev/null +++ b/2_entities/2_3_coreferences.md @@ -0,0 +1,28 @@ +--- +title: 2.3. Koreferenzen +layout: default +nav_order: 3 +--- + +# 2.3. Koreferenzen +Koreferenzen helfen uns, aus Erwähnungen Entitäten herzuleiten. Eine Koreferenz ist immer eine gerichtete Verbindung von einer Erwähnung zu einer anderen. Wir unterscheiden zwischen direkten Koreferenzen, die zwingend annotiert werden müssen, und indirekten Koreferenzen, deren Annotation optional ist. Wir empfehlen, die Unterscheidung dieser beiden Arten von Koreferenzen einzuhalten. + +## 2.3.1. Direkte Koreferenzen +Eine direkte Koreferenz bedeutet, dass eine Erwähnung nur dann Sinn ergibt, wenn eine Koreferenz existiert. Das gilt zum Beispiel für (fast) alle Pronomina und Nominativnennungen mit expliziten Begriffen wie "vorgenannten". + +Beispiele für direkte Koreferenzen: + +"Hans Jakob kauft das Haus und er bezahlt 30 Gulden." +Hans Jakob <= er + +"Der Schaffner des Steinenklosters fröhnt das Haus wegen der vergessenen Zinsen, so dem vorgenannten Kloster jedes Jahr 3 sh. gezinst wird." +des Steinenklosters <= dem vorgenannten Kloster + +## 2.3.2. Indirekte Koreferenzen +Eine indirekte Koreferenz hält fest, dass es sich bei zwei Erwähnungen um Referenzen auf dieselbe Entität handelt, diese Information erfordert aber Kontextwissen oder ist zu gewissem Grad Spekulation. + +"Der Schaffner des Steinenklosters fröhnt das Haus wegen der vergessenen Zinsen, so dem Kloster jedes Jahr 3 sh. gezinst wird." +des Steinenklosters <= dem Kloster + +"Der Herr Friedrich zog nach Italien. Der Herzog focht dort viele Kämpfe." +Der Herr Friedrich <= Der Herzog \ No newline at end of file diff --git a/2_entities/2_entities.md b/2_entities/2_entities.md new file mode 100644 index 0000000..ee9a53f --- /dev/null +++ b/2_entities/2_entities.md @@ -0,0 +1,15 @@ +--- +title: 2. Entitäten +layout: default +nav_order: 3 +has_children: true +--- + +# 2. Entitäten +Zur Annotation von Entitäten gehört einerseits die Information der Grenzen der Erwähnung (Welche Token sind Teil der Erwähnung?), die Identifikation des *Heads* und die Kategorisierung der Erwähnung in eine Entitäten-Kategorie. + +Bei einer Entitäten-Annotation handelt es sich genau genommen um die +Annotation von *Erwähnungen* (Mentions). Von einer *Entität* kann man +erst sprechen, wenn bestimmt wurde, welche Erwähnungen +sich alle auf eine bestimmte Entität beziehen. +Die Verbindung von Erwähnungen zu Entitäten geschieht durch die Annotation von Koreferenzen. \ No newline at end of file diff --git a/3_values.md b/3_values.md index a0082a7..80f2b01 100644 --- a/3_values.md +++ b/3_values.md @@ -9,7 +9,7 @@ nav_order: 4 Werte folgen nicht denselben Regeln wie Entitätserwähnungen. Sie können Textspannen auszeichnen, die in irgendeiner Hinsicht für die Forschung relevant sein könnten und oft sind sie auch relevant als -Anknüpfungspunkt für Beziehungen und Ereignissen, wobei sie dadurch auch +Anknüpfungspunkt für Zustände und Ereignissen, wobei sie dadurch auch mit Entitätserwähnungen verknüpft werden können. Werte haben keine *head*-Elemente. diff --git a/4_relations.md b/4_relations.md index 131d341..d33c8c4 100644 --- a/4_relations.md +++ b/4_relations.md @@ -1,81 +1,117 @@ --- -title: 4. Beziehungen und Ereignisse +title: 4. Zustände und Ereignisse layout: default -nav_order: 4 +nav_order: 5 --- -# 4. Beziehungen und Ereignisse -Aus praktischen Gründen lohnt es sich zwar meistens zwischen Beziehungen und Ereignissen zu unterscheiden, die Grenzen sind jedoch manchmal nicht klar auszumachen. Sowohl Beziehungen wie auch Ereignisse repräsentieren Zusammenhänge zwischen Entitäten (und/oder Werten). Ereignisse stellen ein konkretes Geschehnis dar und keinen Zustand. Die Beziehung "married" würde z.B. den Zustand des Verheiratet-Seins beschreiben, während das Ereignis "marriage" spezifisch den Beginn der Heirat markiert. -In BeNASch annotieren wir Beziehungen und Ereignisse mit derselben Methode. +# 4. Zustände und Ereignisse +Über Zustände können wir weitere Informationen zu Entitäten im Text vermerken. Sie werden oft durch Attribute und Deskriptoren im Text annotiert, können aber auch im Freitext gegeben sein. +Als Zustand sind Eigenschaften einer Entität zu bezeichnen, z.B. welche Verwandten sie hat oder dass die Entität verstorben ist. +Ein Zustand, der ein Verhältnis zwischen mehreren Entitäten festhalt, wird auch als "Beziehung" bezeichnet. -Wir unterscheiden zwischen zwei Komplexitätsstufen der Annotation. Ein Projekt sollte für jede Beziehungs- und Ereignis-Klasse, die verwendet wird, bestimmen, ob die einfache Annotation ausreicht, oder von der vollen Annotation Gebrauch gemacht werden sollte. +Ereignisse hingegen vermerken Aktivitäten im Text. Diese finden sich öfter im Freitext, manchmal aber auch in Referenzen, Attributen oder Deskriptoren. +Beispiele für Ereignisse wäre zum Beispiel eine Transaktion oder ein Todesfall. -{: .note } -Die einfache Annotation ist Teil des offiziellen BeNASch-Schemas und ihre Verwendung bedeutet keinen Bruch mit dem Schema. +Ereignisse und Zustände hängen eng miteinander zusammen. +So kann z.B. ein "marriage"-Ereignis einen "married"-Zustand ab diesem Punkt implizieren, und ein "divorce"-Ereignis das Ende desselben Zustands. +Wir annotieren aber auch in diesem Fall textnah, d.h. nur das im Text genannte Ereignis, nicht aber der implizierte Zustand wird vermerkt. ## 4.1 Annotationsebene -Eine Beziehung oder ein Ereignis finden jeweils auf einer bestimmten syntaktischen Ebene statt, welche wir als Annotationsebene bezeichnen. Annotationen für die Beziehung oder das Ereignis dürfen nur auf dieser Ebene erfolgen bzw. Entitäten/Werte auf dieser Ebene verbinden. Eine Annotationsebene kann z.B. die Dokument- oder Satzebene sein, oder die Ebene innerhalb einer Erwähnung. Falls die Beziehung oder das Ereignis in einer Erwähnung stattfinden, kann die Erwähnung selbst auch ein Element der Beziehung oder des Ereignisses sein. +Eine Beziehung oder ein Ereignis finden jeweils auf einer bestimmten syntaktischen Ebene statt, welche wir als Annotationsebene bezeichnen. Annotationen für den Zustand oder das Ereignis dürfen nur auf dieser Ebene erfolgen bzw. Entitäten/Werte auf dieser Ebene verbinden. Eine Annotationsebene kann z.B. die Dokument- oder Satzebene sein, oder die Ebene innerhalb einer Erwähnung. Falls der Zustand oder das Ereignis in einer Erwähnung stattfinden, kann die Erwähnung selbst auch ein Element der Beziehung oder des Ereignisses sein. Beispiel: "\[\[ihr\] Ehemann\]" -| Beziehungstyp | Entität A | Entität B | +| Zustand | Entität A | Entität B | |---|---|---| | Verheiratet | Ehemann | ihr | Beispiel: "Es verhandelt \[\[der Kinder\] Vogt\] mit \[dem Käufer\]" -| Ereignistyp | Entität A | Entität B | +| Ereignis | Entität A | Entität B | |---|---|---| | Verhandlung | der Kinder Vogt | Käufer | -Die Erwähnung der "Kinder" liegt nicht auf derselben Annotationsbene wie das Ereignis, daher können die Kinder kein Element des Ereignisses sein. Die Verbindung zum Ereignis kann aber trotzdem festgehalten werden, indem gleichzeitig die Beziehung zwischen den Kindern und dem Vogt festgehalten wird. +Die Erwähnung der "Kinder" liegt nicht auf derselben Annotationsbene wie das Ereignis, daher können die Kinder kein Element des Ereignisses sein. Die Verbindung zum Ereignis kann aber trotzdem festgehalten werden, indem gleichzeitig der Zustand (die Beziehung) zwischen den Kindern und dem Vogt festgehalten wird. -| Beziehungstyp | Entität A | Entität B | +| Zustand | Entität A | Entität B | |---|---|---| | Stellvertretung | Vogt | Kinder | +## 4.2. Definition eines Zustands / eines Ereignisses +Da es unmöglich ist, alle Typen von Zuständen und Ereignissen zu vermerken, sollte ein Projekt sich auf eine Reihe von Zuständen und Ereignissen festlegen, und diese konsequent annotieren. +Wir empfehlen dazu die Basis-Typologie (notwendig um als BeNASch-konform zu gelten) plus Zustände/Ereignisse nach Forschungsschwerpunkt. +Noch in Planung ist, beispielhafte Module für bestimmte Arten von Korpora (z.B. Grundbuchdokumente) zur Verfügung zu stellen. +Wir möchten Projekte, die BeNASch verwenden, bitten ihre Auswahl an Zuständen/Ereignissen mit der Community im Github-Forum zu teilen. -## 4.2. Einfache Annotation -Die einfache Annotation umfasst lediglich drei Elemente: +Wurde festgelegt, welche Zustände und Ereignisse annotiert werden sollen, muss festgelegt werden _wie_ sie annotiert werden. +Folgende Elemente können annotiert werden: -- Entität/Wert A -- Entität/Wert B -- Klassifikation +- Textspannen +- Trigger +- Rollen +- Zusatzinformationen -Manche Beziehungen sind gerichtet, zum Beispiel eine -Besitzverhältnis-Beziehung. Andere sind symmetrisch, z.B. eine -Eheleute-Beziehung. Bei gerichteten Beziehungen ist die Erwähnung A die -sogenannte *from*-Partei und die Erwähnung B die *to*-Partei. Die -Beziehung sollte so gelesen werden können "\ is -\ by/to/of \". +Zwingend notwendig ist die Annotation im Text von wenigstens einem Trigger, einer Rolle oder der Textspanne. -Diese einfache Annotation kann bereits viele Fälle abdecken, z.B. Beziehungen wie "Bertha, Hansis Frau" oder "Bertha heiratet Hansi". +Für einfache Beziehungen zum Beispiel ist oft die Definition von zwei Rollen ausreichend: -## 4.3. Volle Annotation -Die volle Annotation ermöglicht die Annotation von komplexeren Konstruktionen und umfasst die folgenden Elemente: +Zustand: Verheiratet +Rolle 1: Ehepartner:in 1 (PER) +Rolle 2: Ehepartner:in 2 (PER) -- Textspanne -- Trigger -- Entitäten/Werte gemäss definierten Rollen -- Zusatzinformationen -- Klassifikation +Beispiel: "des Schmieds eheliche Frau" + +Für komplexe Zustände oder Ereignisse ist meist die Definition eines Trigger-Elements, weiterer Rollen und etwaiger Zusatzinformationen hilfreich: + +Zustand: Rentenverhältnis +Trigger: muss annotiert werden +Rolle 1: Rentenzahler (PER / ORG) +Rolle 2: Rentenempfänger (PER / ORG) +Rolle 3: Belastete Liegenschaft (LOC) +Rolle 4: Zahlungsintervall (TIME.REC) +Rolle 5: Zahlungsbetrag (MONEY) +Zusatz: Zahlungsgrund (z.B. "von eigenschaft") +Zusatz: Information zu Ablösbarkeit (z.B. "ist ablösbar") + +Beispiel: "er zinst von dem Haus zum Bären von eig. jährlich dem Kloster zu den Barfüssen 3 sh." + +Die Annotation von Triggern ist für das Verständnis von Zuständen und Ereignissen nicht notwendig, kann aber aus linguistischem Interesse sinnvoll sein, und ist in der Annotationspraxis hilfreich. +Zudem können Trigger von maschinellen System zur besseren Annotation von Zuständen und Ereignissen genutzt werden. + +Manche Zustände oder Ereignisse könnten auch völlig von Entitäten unabhängig sein, oder eine nähere Annotation der Rollen ist nicht im Forschungsinteresse des Projekts. +In diesem Fall bietet sich entweder die Annotation des Triggers oder der Textspanne am ehesten an: + +Ereignis: Wetterereignis +Textspanne: muss annotiert werden. + +Beispiel: "heute stürmte es stark." + +## 4.3. Beschreibung der Elemente -Die Textspanne sollte das syntaktische Element umfassen, in welchem das Ereignis stattfindet, und in welchem daher auch alle anderen Elemente liegen. Diese Textspannen-Annotation ist nicht den Regeln der Entitätenannotation unterworfen und darf sich z.B. mit anderen Textspannen-Annotationen schneiden. +### 4.3.1. Textspanne +Die Textspanne sollte das syntaktische Element umfassen, in welchem das Ereignis/der Zustand stattfindet, und in welchem daher auch alle anderen Elemente liegen. Diese Textspannen-Annotation ist nicht den Regeln der Entitätenannotation unterworfen und darf sich z.B. mit anderen Textspannen-Annotationen schneiden. Beispiel: "\[Elsa hat auf das Haus 5 Gld. geboten\] und \[am Dienstag hat sie es gekauft.\]" Beispiel: "\[\[Elsa hat auf das Haus 5 Gld. geboten\] und es gekauft.\]" -Der Trigger sollte den zentralen Begriff der Beziehung oder des Ereignisses markieren, wobei wir der Konsistenz wegen dazu raten den Trigger auf den linguistischen Kopf der syntaktischen Einheit, welche die Beziehung oder das Ereignis ausmacht, zu setzen. Dies ist auf Satz- oder Dokumentebene meist das Prädikat, in Erwähnungsebenen üblicherweise der Head. In seltenen Fällen oder bestimmten Texttypen kann es sein, dass kein Trigger auszumachen ist. In diesem Fall kann der Trigger auch weggelassen werden. +### 4.3.2. Trigger +Der Trigger sollte den zentralen Begriff des Zustands oder des Ereignisses markieren, wobei wir der Konsistenz wegen dazu raten den Trigger auf den linguistischen Kopf der syntaktischen Einheit, welche den Zustand oder das Ereignis ausmacht, zu setzen. Dies ist auf Satz- oder Dokumentebene meist das Prädikat, in Erwähnungsebenen üblicherweise der Head. In seltenen Fällen oder bestimmten Texttypen kann es sein, dass kein Trigger auszumachen ist. In diesem Fall kann der Trigger auch weggelassen werden. Beispiel Satzebene: "\[das Kloster hat wegen versessener Zinsen Uelis Haus gefrönt.\]" Beispiel Erwähnungsebene: "\[seine Frau\] -{: .note } +[!TIP] Erwähnungspräzisierungen implizieren oft eine Beziehung oder ein Ereignis, ein Fakt, den wir uns während der Annotation zu Nutze machen können. -Jede Beziehung und jedes Ereignis definiert in seiner vollen Annotation Rollen, welche Entitäten oder Werten zugewiesen werden. Es definiert auch, wie oft eine Rolle jeweils vorkommen kann, und ob gewisse Rollen optional sind. Zudem existiert eine Zahl generischer Rollen, welche alle Beziehungen oder Ereignisse (optional) aufweisen. +### 4.3.3. Rollen +Rollen werden Entitäten, Werten oder anderen Ereignissen zugewiesen. +Grundsätzlich wird angenommen, dass das Vorkommen einer Rolle nicht notwendig ist, damit ein Zustand oder Ereignis vermerkt wird. +Kommt sie aber vor und ist in der Projektdefinition vermerkt, muss sie annotiert werden. +Es wird auch immer angenommen, dass eine Rolle mehrmals vorkommen kann und dann mehrmals annotiert wird. +In der Projektdefinition können diese Spezifikationen aber weiter präzisiert werden, z.B. kann für einen "Verheiratet"-Zustand festgelegt werden, dass nur genau zwei PER-Entitäten an der Beziehung teilnehmen. +Solche Präzisierung können nützlich sein um Fehler – insbesondere in maschinell generierten – Datensätzen festzustellen. Beispiel: "\[Hans von Oltingen mit Zustimmung Franzen Oltingers seines Vaters verkauft an Peter Schützen den Rebmann das Haus und den Garten für 163 fl.\]" @@ -88,18 +124,19 @@ Beispiel: "\[Hans von Oltingen mit Zustimmung Franzen Oltingers seines Vaters Zusatzinformationen werden direkt als Textspanne annotiert und können (mehrere) Entitäten oder Werte umfassen. Diese Entitäten oder Werte sollten aber nicht gleichzeitig Rollen einnehmen. Zusatzinformationen sollten auch klassifiziert werden. +### 4.3.4. Zusatzinformationen +Zusatzinformationen werden direkt als Textspannen annotiert und können (mehrere) Entitäten oder Werte umfassen. Diese Entitäten oder Werte sollten aber nicht gleichzeitig Rollen einnehmen. Zusatzinformationen sollten auch klassifiziert werden. Beispiel: "das Haus, \[zinst jährlich \{zur Weisung\} ein Brot.\]" / "zur Weisung" --> Zinsgrund Beispiel: "\[er schuldet 300 fl. Kapital \{für jeden fl. 6 sh.\]\}" / "für jeden fl. 6 sh." --> Geldumrechnung -## 4.4. Unter-Beziehungen / Unter-Ereignisse -Es kann vorkommen, dass innerhalb einer Ereignisspanne (oder Beziehungsspanne) mehrere Sachverhalte beschrieben werden. Ein Beispiel für einen solchen Fall: +## 4.4. Unter-Zustand / Unter-Ereignisse +Es kann vorkommen, dass mehrere Ereignisse oder Zustände an demselben Trigger hängen. Ein Beispiel für einen solchen Fall: "\[...\] das Haus, \[zinst jährl. dem Spital 2 sh. zu eigen 1 brot zur wysung, dann dem Kloster zu Barfüssen 1 sh. 2 pfennig ablösbar mit 30 fl.\]" -Wir definieren in diesem Fall alle Informationen innerhalb der Spanne demselben Ereignis oder derselben Beziehung zugehörig. Aber wir unterscheiden sie trotzdem in verschiedene Unter-Ereignisse oder Unter-Beziehungen. In diesem Fall würden sich drei Unter-Ereignisse auszeichnen lassen: +Wir definieren in diesem Fall alle Informationen innerhalb der Spanne demselben Ereignis oder derselben Beziehung zugehörig. Aber wir unterscheiden sie trotzdem in verschiedene Unter-Ereignisse oder Unter-Zustände. In diesem Fall würden sich drei Unter-Ereignisse auszeichnen lassen: Für alle Unter-Ereignisse: @@ -134,7 +171,7 @@ Unter-Ereignis 2: | Betrag zur Ablösung | 30 fl. | ## 4.5. Klassifikation -Die wichtigste Klassifikation jedes Ereignisses und jeder Beziehung ist die Ereignis- bzw. Beziehungsklasse. Diese beschreibt die inhaltliche Bedeutung der Annotation. Eine Liste von vorgeschlagenen Klassen und deren Beschreibung findet sich in der Typologie (TODO: Verlinken). +Die wichtigste Klassifikation jedes Ereignisses und jeder Beziehung ist die Ereignis- bzw. Zustandsklasse. Diese beschreibt die inhaltliche Bedeutung der Annotation. Eine Liste von vorgeschlagenen Klassen und deren Beschreibung findet sich in der Typologie (TODO: Verlinken). Weiter sollten folgende Klassifikationen ausgezeichnet werden (in fett jeweilige default-Werte): @@ -143,32 +180,32 @@ Weiter sollten folgende Klassifikationen ausgezeichnet werden (in fett jeweilige | Klasse | Beschreibung | |---|---| | pos | | -| neg | Verneinung des Ereignisses / der Beziehung. | +| neg | Verneinung des Ereignisses / des Zustands. | Zeitform: | Klasse | Beschreibung | |---|---| -| pres | Gegenwart, entspricht der "textual anchor time", d.h. auch Verben die eine Vergangenheitsform aufweisen, können ein Ereignis oder eine Beziehung im "pres" beschreiben. | -| past | Ereignis / Beziehung explizit in der Vergangenheit, auch in Bezug auf die "textual anchor time". | -| fut | Ereignis / Beziehung explizit der Zukunft. Die Unsicherheit von künftigen Ereignissen ist damit schon abgedeckt, es braucht also keine weitere Angaben zur Modalität (siehe unten). | +| pres | Gegenwart, entspricht der "textual anchor time", d.h. auch Verben die eine Vergangenheitsform aufweisen, können ein Ereignis oder einen Zustand im "pres" beschreiben. | +| past | Ereignis / Zustand explizit in der Vergangenheit, auch in Bezug auf die "textual anchor time". | +| fut | Ereignis / Zustand explizit der Zukunft. Die Unsicherheit von künftigen Ereignissen oder Zuständen ist damit schon abgedeckt, es braucht also keine weitere Angaben zur Modalität (siehe unten). | | unspec | Nicht klar | Modalität: | Klasse | Beschreibung | |---|---| -| ass | Ereignis / Beziehung wird als Fakt beschrieben. | -| claim | Ereignis / Beziehung wird als Behauptung beschrieben. | -| rumor | Ereignis / Beziehung wird als Gerücht beschrieben. | -| hypo | Ereignis / Beziehung wird als Möglichkeit beschrieben. | -| requ | Ereignis / Beziehung wird als Befehl beschrieben. | -| prop | Ereignis / Beziehung wird als Vorschlag beschrieben. | -| desi | Ereignis / Beziehung wird als Wunsch beschrieben. | -| prom | Ereignis / Beziehung wird als Versprechen beschrieben. | -| other | Ereignis / Beziehung wird nicht als Fakt beschrieben, passt aber in keine andere Kategorie | +| ass | Ereignis / Zustand wird als Fakt beschrieben. | +| claim | Ereignis / Zustand wird als Behauptung beschrieben. | +| rumor | Ereignis / Zustand wird als Gerücht beschrieben. | +| hypo | Ereignis / Zustand wird als Möglichkeit beschrieben. | +| requ | Ereignis / Zustand wird als Befehl beschrieben. | +| prop | Ereignis / Zustand wird als Vorschlag beschrieben. | +| desi | Ereignis / Zustand wird als Wunsch beschrieben. | +| prom | Ereignis / Zustand wird als Versprechen beschrieben. | +| other | Ereignis / Zustand wird nicht als Fakt beschrieben, passt aber in keine andere Kategorie | ## 4.6. Vollständige Beispiele -TODO +_coming soon_ [^1]: Die Beziehung ist hier in einem Deskriptor beschrieben. In diesem Fall kann auch die darüberliegende Annotation, auf die sich der Deskriptor bezieht, mit einer Rolle versehen werden. diff --git a/anno_guide/5_1_project_setup.md b/5_anno_guide/5_1_project_setup.md similarity index 100% rename from anno_guide/5_1_project_setup.md rename to 5_anno_guide/5_1_project_setup.md diff --git a/anno_guide/5_2_doc_anno.md b/5_anno_guide/5_2_doc_anno.md similarity index 100% rename from anno_guide/5_2_doc_anno.md rename to 5_anno_guide/5_2_doc_anno.md diff --git a/anno_guide/5_3_postprocessing.md b/5_anno_guide/5_3_postprocessing.md similarity index 100% rename from anno_guide/5_3_postprocessing.md rename to 5_anno_guide/5_3_postprocessing.md diff --git a/anno_guide/5_anno_guide.md b/5_anno_guide/5_anno_guide.md similarity index 93% rename from anno_guide/5_anno_guide.md rename to 5_anno_guide/5_anno_guide.md index f834a05..727df31 100644 --- a/anno_guide/5_anno_guide.md +++ b/5_anno_guide/5_anno_guide.md @@ -1,11 +1,11 @@ --- title: 5. Annotations-Anleitung layout: default -nav_order: 5 +nav_order: 6 has_children: true --- -# 7. Annotations-Anleitung +# 5. Annotations-Anleitung Auf dieser Seite findet sich eine Schritt-für-Schritt-Anleitung, wie 1. ein Projekt in INCEpTION aufgesetzt wird. (In Arbeit) diff --git a/index.md b/index.md index aa7af5b..cc89d62 100644 --- a/index.md +++ b/index.md @@ -23,3 +23,19 @@ die Mitsprache und Perspektiven von ausserhalb dieses Kreises sind aber äussers Oben rechts findet sich ein Link zum [Github-Repository des Projekts](https://github.com/DHBern/BeNASch/), darin können über das [Issues](https://github.com/DHBern/BeNASch/issues/) oder das [Discussions](https://github.com/DHBern/BeNASch/discussions/)-Tab Änderungsvorschläge vorgebracht oder Diskussionen angestossen werden. Wer sich mit Git auskennt, darf z.B. Tippfehler, Umformulierungen oder Ergänzungen an Beispielen auch gerne per Pull-Request einreichen. + +## Neuigkeiten + +### BeNASch-Workshop im Januar 2025 +Wir laden herzlich interessierte Forscher:innen zum ersten Workshop rund um das BeNASch-Schema ein, welcher am 23. und 24. Januar 2025 stattfinden wird. Der Workshop findet in Bern statt und ist kostenlos, alle weiteren Infos gibt es [hier](https://www.dh.unibe.ch/forschung/benasch/index_ger.html). + +### Regelmässige Meetings +Meetings zur Diskussion von Punkten aus dem Github-Forum finden alle zwei Wochen statt (siehe Forum). Bei Interesse bitte bei den Admins melden, wir freuen uns über jede zusätzliche Teilnehmer:in! + +## Änderungsprotokoll + +### November 2024 +(für genaues Changelog siehe Github Repo) +- Umbenennung von Beziehungen in Zustände, Beziehungen bezeichnen Zustände mit mehr als einer beteiligten Entität. +- Entgliederung der Entitäten-Typologie aus der Entitäten-Annotation für bessere Übersichtlichkeit. +- Einführung der Unterscheidung zwischen direkten und indirekten Koreferenzen. \ No newline at end of file From a16e2187cdd240f61565ac18d9ddae5e79d26206 Mon Sep 17 00:00:00 2001 From: Ismail Prada Date: Mon, 11 Nov 2024 15:55:01 +0100 Subject: [PATCH 2/2] Adapted annotation guide to changes. --- 5_anno_guide/5_2_doc_anno.md | 72 +++++++++++++----------------------- 1 file changed, 26 insertions(+), 46 deletions(-) diff --git a/5_anno_guide/5_2_doc_anno.md b/5_anno_guide/5_2_doc_anno.md index 7aad302..9e2894d 100644 --- a/5_anno_guide/5_2_doc_anno.md +++ b/5_anno_guide/5_2_doc_anno.md @@ -5,25 +5,24 @@ nav_order: 2 parent: 5. Annotations-Anleitung --- -# 6.2. Annotation in INCEpTION +# 5.2. Annotation in INCEpTION In diesem Guide wird im Detail erklärt, wie ein Dokument in Inception annotiert werden sollte, damit es durch das BeNASch-assoziierte Postprocessing korrekt verarbeitet werden kann. Die hier empfohlene Methode der Annotation zielt darauf ab, möglichst weniger "überflüssige" Tags setzen zu müssen. -Es wird angenommen, dass ein Projekt nach den Empfehlungen in Kapitel 7.1. aufgesetzt wurde und die entsprechenden Layer "Span" und "Relation" vorhanden sind. +Es wird angenommen, dass ein Projekt nach den Empfehlungen in Kapitel 5.1. aufgesetzt wurde und die entsprechenden Layer "Span" und "Relation" vorhanden sind. ## Entitäten annotieren - ### Textspanne markieren -{: .note } Wir empfehlen, das "Span"-Layer auf Token-basierte Annotation zu setzen. Dies ermöglicht etwas schnelleres Markieren der Textspannen, weil nicht exakt die Endungen der Wörter markiert werden müssen. Durch Doppelklick kann ein Token schnell angewählt und annotiert werden. - -Im Schema wurde es zwar schon erwähnt, aber wir annotieren in diesem Schema immer "lange" Spannen. Das entspricht üblicherweise den Grenzen der jeweiligen [[Nominalphrase]](https://de.wikipedia.org/wiki/Nominalphrase). Es sollte ausserdem nicht vergessen, den Kopf (HEAD) zu markieren und zu annotieren (jede Entitätenerwähnung, egal ob Referenz oder Attribut, muss genau einen HEAD aufweisen!). +[!TIP] +Wir empfehlen, das "Span"-Layer auf Token-basierte Annotation zu setzen. Dies ermöglicht etwas schnelleres Markieren der Textspannen, weil nicht exakt die Endungen der Wörter markiert werden müssen. Durch Doppelklick kann ein Token schnell angewählt und annotiert werden. +Im Schema wurde es zwar schon erwähnt, aber wir annotieren in diesem Schema immer "lange" Spannen. Das entspricht üblicherweise den Grenzen der jeweiligen [[Nominalphrase]](https://de.wikipedia.org/wiki/Nominalphrase). Es sollte ausserdem nicht vergessen werden, den Kopf (HEAD) zu markieren und zu annotieren (jede Entitätenerwähnung, egal ob Referenz oder Attribut, muss genau einen HEAD aufweisen!). ### Label setzen -Um den Annotationsprozess zu beschleunigen, verzichtet das Projekt darauf, für jede Klassifikation von Entitäten mehrere Felder zu verwenden. Stattdessen werden alle Informationen unter dem Feature "Label" verzeichnet. Die verwendeten Abkürzungen entsprechen übrigens denen, die im Schema jeweils in Klammern stehen. +Um den Annotationsprozess zu beschleunigen, verzichtet das Projekt darauf, für jede Klassifikation von Entitäten mehrere Felder zu verwenden. Stattdessen werden alle Informationen unter dem Feature "Label" verzeichnet. Die verwendeten Abkürzungen entsprechen denen, die im Schema jeweils in Klammern stehen. Für Referenzen folgt diese Annotation dem folgenden Schema: - Erwähnungs-Klassifikation @@ -51,7 +50,8 @@ Die optionalen Klassifikationen müssen nur annotiert werden, wenn sie vom Stand | Ordinalität | Singular (SGL) | | Spezifität | Spezifisch (SPC) | -{: .note } Im Postprocessing können die Standard-Werte in "schema_info.json" angepasst werden. +[!TIP] +Im Postprocessing können die Standard-Werte in "schema_info.json" angepasst werden. Pronomina können sogar noch weiter verkürzt werden, solange sie eine Koreferenz zu einem Label aufweisen, welches die vollen Informationen aufweist. Ein PRO reicht in dem Fall aus. @@ -65,67 +65,49 @@ Ein Dokument könnte nach diesem Schritt folgendermassen aussehen: ## Deskriptoren annotieren - ### Textspanne markieren - Auch Deskriptoren sollten der Syntax des Satzes folgen. Es sollte nicht vergessen werden, dass auch Pronomina Entitätenerwähnungen darstellen, und daher nicht als Deskriptoren, sondern als Attribute zu annotieren sind. -Das Setzen eines "Key" ist in der derzeitigen BeNASch-Version nicht obligatorisch. +Falls der Deskriptor ein Ereignis oder einen Zustand markiert, ist es in diesem Schritt bereits ratsam einen Trigger und etwaige Rollen zu markieren. ### Label setzen - Die Auswahl an möglichen Deskriptoren ist gross, da sie auch alle Typen von Relationen und Ereignissen abdeckt. Deskriptoren werden mit "desc" eingeleitet, danach folgt der Typus des Deskriptors. ### Beispiel - Ein Dokument könnte nach diesem Schritt folgendermassen aussehen: ![Annotation Example with Descriptors](../static/images/example_desc.png) +## Koreferenzen setzen +Wir können Koreferenzen, durch eine Linie zwischen zwei Erwähnungen darstellen. Dazu ziehen wir einfach mit gedrückter linker Maustaste den Pfeil von der einen Erwähnung zu der anderen Erwähnung und schreiben "coref" in das Feld "Label". Eine Lösung per ID (da die Pfeile den Bildschirm teils sehr unübersichtlich machen) ist in Arbeit, aber noch nicht im Postprocessing implementiert. -## Relationen annotieren - - -### Zur Erinnerung - -Eine Relation besteht immer aus zwei Entitätenerwähnungen und einem Typus. - +## Annotation von einfachen Beziehungen und Ereignissen +Als "einfach" sind Zustände und Ereignisse zu verstehen, die nur aus zwei Rollen bestehen, und ev. einem Trigger. -### Relationen und Koreferenzen per Linie setzen +Falls sie in einer Verschachtelung vorkommen, müssen sie oft gar nicht explizit annotiert werden. +Im Beispiel unten z.B. sehen wir die Beziehung vom Typus FAM im Attribut "seine Frau" enthalten. Das Postprocessing produziert daraus die Beziehung *"seine **Frau**" hat Beziehung FAM mit "**seine**"*. Also: das Postprocessing erzeugt eine beliebige Anzahl Beziehungen mit dem gleichen Typus wie dem des Attributs, welche das Attribut selbst mit allen Entitätenerwähnungen, die im Attribut stehen, verbinden.\ +Die Wiedergabe durch Deskriptoren funktioniert ähnlich. Nur wird in diesem Fall die Entität, welche durch den Deskriptor beschrieben wird, mit der (oder den Entitäten), die innerhalb des Deskriptors stehen, verbunden. Im Beispiel unten wird also das "Haus & Hof" mit der "Aeschenvorstadt" durch eine Beziehung des Typus "loc" im Postprocessing generiert.\ +Die Zuweisung der Rollen wird (coming soon) aus der Projektspezifikation abgeleitet. Bei einer gerichteten Beziehung wie OWNERSHIP z.B. können wir definieren, dass immer die beteiligte PER- oder ORG-Erwähnung die besitzende Rolle inne hat, während die LOC besitzt wird. Besteht Ambiguität, wie z.B. zwei ORGs in einer OWNERSHIP-Beziehung, müssen die Rollen explizit annotiert werden, ansonsten meldet das Postprocessing dies als eine Unklarheit, die händisch nachbearbeitet werden muss. Zur expliziten Annotation von Rollen siehe weiter unten. -Wir können Relationen, insbesondere wenn sie nicht in einer verschachtelten Erwähnung stattfindet, durch eine Linie zwischen zwei Erwähnungen darstellen. Dazu ziehen wir einfach mit gedrückter linker Maustaste den Pfeil von der einen Erwähnung zu der anderen Erwähnung und schreiben den Typus in das Feld "Label" (Kein rel. oder so notwendig). - - -### Relationen in Attributen und Deskriptoren - -Findet die Beziehung innerhalb einer verschachtelten Erwähnung statt, wird sie entweder durch ein Attribut oder einen Deskriptor repräsentiert. - -Im Beispiel unten z.B. sehen wir die Beziehung vom Typus FAM im Attribut "seine Frau" enthalten. Das Postprocessing produziert daraus die Beziehung *"seine **Frau**" hat Beziehung FAM mit "**seine**"*. Also: das Postprocessing erzeugt eine beliebige Anzahl Beziehungen mit dem gleichen Typus wie dem des Attributs, welche das Attribut selbst mit allen Entitätenerwähnungen, die im Attribut stehen, verbinden. - -Die Wiedergabe durch Deskriptoren funktioniert ähnlich. Nur wird in diesem Fall die Entität, welche durch den Deskriptor beschrieben wird, mit der (oder den Entitäten), die innerhalb des Deskriptors stehen, verbunden. Im Beispiel unten wird also das "Haus & Hof" mit der "Aeschenvorstadt" durch eine Beziehung des Typus "loc" im Postprocessing generiert. - - -### Gerichtete Beziehungen - -Viele Beziehungen sind gerichtet (siehe Beziehungstypologie in Kapitel 4). Wird die Beziehung per Pfeil gesetzt, sollte die Beziehung in Richtung Pfeil gelesen werden. z.B. "Hans arbeitet beim Spital". Ist die Beziehung verschachtelt gilt die Richtung von der äusseren Spanne zur inneren Spanne (z.B. "[**Hans**, [**Schaffner** des [**Spitals**]]]" => Hans arbeitet beim Spital). Noch besser ist es, bei gerichteten Beziehungen die Rollen direkt zu benutzen, z.B. bei einem Schuldverhältnis "Creditor" und "Debitor". +Ausserhalb von Verschachtelungen können einfache Beziehungen / Ereignisse wie Koreferenzen per Pfeil markiert werden, das Label sollte dann den Typ der Beziehung wiedergeben. ### Beispiel - Ein Dokument könnte nach diesem Schritt folgendermassen aussehen: ![Annotation Example with Coreferences](../static/images/example_coref.png) -## Ereignisse annotieren +## Explizite Annotation von Zuständen und Ereignissen ### Zur Erinnerung -Ein Ereignis besteht aus einer Ereignis-Spanne, welche einer bestimmten syntaktischen Einheit entspricht, einem Ereignis-*Trigger* und einer vom Ereignis abhängigen Anzahl von assoziierten Rollen. +Ein Ereignis oder ein Zustand werden gemäss Projektspezifikation annotiert. In diesem Fall nehmen wir an, dass im Beispiel alle Elemente, Textspanne, Trigger und Rollen annotiert werden müssen. Alles im Folgenden gilt auch für die Annotation von Zuständen. ### Grundlegendes -Die Ereignis-Spanne wird im "Label"-Feature mit dem Präfix "evspan" gekennzeichnet. Darauf folgt der Ereignis-Typus. Die Ereignis-Spanne kann weggelassen werden (wie im Beispiel unten), dann setzt das Postprocessing die Spanne automatisch von der ersten Rolle/Trigger bis zur letzten Rolle/Trigger im Text. +Die Ereignis-Spanne wird im "Label"-Feature mit dem Präfix "evspan" gekennzeichnet. Darauf folgt der Ereignis-Typus. +Die Ereignis-Spanne kann weggelassen werden (wie im Beispiel unten) wenn vom Projekt erlaubt, dann setzt das Postprocessing die Spanne automatisch von der ersten Rolle/Trigger bis zur letzten Rolle/Trigger im Text. Ist unser Ereignis in einer Referenz, einem Attribut oder einem Deskriptor verankert, gilt dieselbe Textspanne wie das Anker-Element. -Der Trigger wird wie eine Entität oder Deskriptor gesetzt und im "Label"-Feature mit dem Präfix "ev" markiert. Ein Ereignis kann in seltenen Fällen ohne Trigger auftreten. Dann ist es wichtig den Ereignis-Typus zumindest in der Ereignis-Spanne festzuhalten. +Der Trigger wird wie eine Entität oder Deskriptor gesetzt und im "Label"-Feature mit dem Präfix "ev" markiert. Ein Ereignis kann in seltenen Fällen ohne Trigger auftreten. Wird oder kann kein Trigger annotiert werden, empfiehlt es sich die Ereignis-Spanne zu setzen, um trotzdem den Ereignis-Typ angeben zu können. Existiert ein Anker-Element, kann der Ereignis-Typ vermutlich (je nach Projektspezifikation) vom Anker-Element abgeleitet werden. Für Rollen verwenden wir das "Role"-Feature. Dort wird die Role einfach eingeschrieben. Auch Ereignis-Spannen und/oder Trigger können eine Rolle in einem anderen Ereignis erhalten. @@ -147,11 +129,9 @@ Hier entstehen die folgenden (Unter-)Ereignisse:\ 120: Zins an St. Martin von 2 Gulden.\ 130: Zins an Christiana Herbsterin von 5 Pfund. -### Ereignisse in Deskriptoren und Attributen -Wie Relationen können auch Ereignisse durch Deskriptoren und Attribute repräsentiert werden, wodurch wir uns etwas Annotation sparen können. Hierbei gilt: Ist kein Trigger annotiert, wird der Key des Deskriptors bzw. der Head des Attributs vom Postprocessing als Trigger angenommen. In einer Setting-Datei (noch nicht implementiert) wird zudem weiteres automatisiertes Verhalten definiert, z.B. deutet ein Deskriptor vom Typus "due" nicht nur die Beschreibung des Zinsverhältnis innerhalb einer Hausbeschreibung an, sondern auch, dass das Haus die Rolle "property" im Ereignis erhält. - -Ereignisse, die durch Deskriptoren oder Attribute verzeichnet werden, müssen in einer Setting-Datei verzeichnet werden, schon nur um sie von Relationen unterscheiden zu können. - +### Anker-Elemente +Anker-Elemente ersparen uns doppelten Annotationsaufwand. +Einiges wurde schon erwähnt, explizit gilt: Ist kein Trigger annotiert, wird der Head des Attributs oder der Referenz vom Postprocessing als Trigger angenommen. In einer Setting-Datei (noch nicht implementiert) wird zudem weiteres automatisiertes Verhalten definiert, z.B. deutet ein Deskriptor vom Typus "due" nicht nur die Beschreibung des Zinsverhältnis innerhalb einer Hausbeschreibung an, sondern auch, dass das Haus die Rolle "property" im Ereignis erhält. ### Beispiel