BeNASch Meeting Protocols

[raykyn]

In this thread, I'll post summarizes of our meetings with an emphasis of what has been talked about in regards to the annotation itself. Each post will usually also contain the date for the next Meeting and we invite every interested researcher to partake, please send me an e-mail if you're interested in joining us for a meeting. We're looking to publish the meeting agenda upfront in the future as well, so you can better decide if you'd like to attend.

[raykyn]

Meeting of 16. April 2024

Administrative

Should meetings be open to the public from now on?
While we had on guests from outside our core team before, our meetings are not yet communicated to the public. This agenda item proposes to communicate our meetings from now on publicly.
Decision: As more teams start trying out or using BeNASch, it makes sense to open up the meetings. But for the moment, we will do so by communicating time and date, but still requiring a registration. The meeting time and date, as well as the agenda, will be communicated in the github repo.

Platforms

Feedback about Usability of Schema and Instructions
As the towerbooks team in Berne has experimented with annotating with the schema and the instruction document only, we can see some needs to rework parts and extend others. In detail those are:

• Add a complete overview on how to annotate a small document in full to the introduction chapter
• Fix "der Syntax" to "die Syntax"
• Rewrite / improve chapter 2.8.2.1
• Be more explicit in explaining the "long" tagging method in chapter 2.1. Add some examples.

The instruction document is still an old document more intended as a cheat sheet rather than an actual guide on how to annotate. In this meeting, it was decided to add a proper instruction guide on how to annotate in Inception to the Website. Later, this should be complemented with a guide to set up an Inception Project and preprocess and import your files, as well as a guide on how to postprocess your files, to e.g. TEI.

Annotation

Description-Spans
Description-Spans were introduced early on while developing this system to generally annotate information inside entity mentions which was not covered by Attribute mentions. Later, it also took on the task of representing relationships between entities. The "official state" of description spans was not clear for a long time. Were they just a help for the annotation process or do they hold valuable information and should be kept as part of the Schema?
Decision:
Description-Spans will be officially added to the Schema, probably as the chapter after Entities. A description span may either independently describe something, or be an anchor in the text, indicating a relation or an event.

Keywords in Description-Spans
In a previous meeting with a research team from Vienna* the need to highlight specific words inside description-spans was brought up.
Example: "das Haus neben dem Brunnen"
Desc-Span: "neben dem Brunnen"
Desc-'Head': "neben"

Decision:
As this might also be of help to other research groups, but not needed by many, we decide to include such a keyword as an optional feature. It's not been decided yet how to call this keyword and this matter should be discussed in the next meeting.

Mention Subtypes and Desc-Spans indicating Events
At the moment, mention subtypes (Erwähnungspräzisionen) and descriptors may indicate a relationship between the entity itself / the parent entity and a potential entity inside the mention. In the Bernese towerbooks a case like this came up:
"der Hingerichtete zu Aarburg"
Assuming an execution is defined as an event for this project, this span contains the following information (Heads in bold):

Person Reference (NOM.PER.EXECUTED): "der Hingerichtete zu Aarburg"
Place Reference (NAM.GPE_LOC): "Aarburg"
Event-Span of type EXECUTION.PAST: "der Hingerichtete zu Aarburg"
Trigger: "Hingerichtete"
Role EXECUTED: "der Hingerichtete zu Aarburg"
Role PLACE: "Aarburg"

This is all valid and easy to annotate as stand-off in the Schema. But for the annotation process it is a bit trickier.
We came to the conclusion that such a case can be covered by allowing mention subtypes and descriptor types to not only indicate a relation, but also an event. The span would thus be annotated in the following way:

Person reference (NOM.PER.EXECUTED): "der Hingerichtete zu Aarburg"
Place Reference (NAM.GPE_LOC): "Aarburg"
Role EXECUTED: "der Hingerichtete zu Aarburg"
Role PLACE: "Aarburg"

As we can see, what changes is that the trigger does not need to be annotated specifically. The event is implied already by the submention type "EXECUTED" and the postprocessing can later resolve this annotation into the person mention and the event respectively. Of course this requires to fit the postprocessing to be able to resolve this, which is a TODO.

Relative location indicators
If in a text, a word analogous to the modern "Hier" or "Dort" is used, how should this be annotated?
Decision:
Our discussion about this was cut short by a bit, so we should talk about this again the next meeting. It is clear that it should be annotated, and currently the idea is to tag it as a PRO.LOC/PRO.GPE_LOC, but this is still missing to mark the special nature of these words.

*names omitted for privacy reasons

The next meeting is scheduled for the 2nd of May, 13:30
Please shoot me (ismail.prada@unibe.ch) and e-mail if you'd like to attend.

[raykyn]

Meeting of 2. Mai 2024 (13:30)

Protokoll ab jetzt auf deutsch:

Beziehungen und Ereignisse

Beziehungen und Ereignisse werden im Schema neu geordnet. Neu teilen wir ein zwischen Zuständen und Ereignissen, wobei diese auf dieselbe Weise annotiert werden. Bei der Annotation unterscheiden wir aber zwischen einfach und komplexe Annotationen. Projektspezifisch kann festgelegt werden ob ein jeweiliger Typ von Zustand oder Ereignis gar nicht, einfach oder komplex annotiert wird, wobei wir uns eine Basisliste von ständig zu annotierenden Typen (mind. einfach) schaffen (TODO!).

Die einfache Annotation entspricht dabei üblicherweise dem Schema, nach dem bisher Beziehungen annotiert wurden, während die komplexe Annotation dem Schema der Ereignis-Annotation entspricht.

Deskriptoren

Definition

Die Definition von Deskriptoren wurde erneut diskutiert und die Beschreibung in #16 so bestätigt (kleinere Korrekturen sind noch fällig).

Ein Deskriptor wird dann nicht gesetzt, wenn die Information des Deskriptors bereits durch den Head der darüberliegenden Nominalphrase gegeben ist. Dies ist z.B. bei manchen Possessivphrasen ("seine Frau") und Genitivattributen der Fall ("Bürger Basels").

Heads in Deskriptoren

Syntaktische Heads können, müssen aber nicht in Deskriptoren gesetzt werden. Ist der Typ des Deskriptors als komplex zu annotieren verzeichnet muss der Head auch gesetzt werden. Es ist aber theoretisch möglich, dass ein Deskriptor keinen Head enthält, z.B. bei Possessivphrasen und Genitivattributen.

[raykyn]

Meeting vom 16. Mai 2024 (12:00)

Provisorische Agenda:

• Update und Vorstellung des neuesten Stands der Ereignis-Annotation
• Vorschlag 2-Ebenen-modell (Das 2-Ebenen-Modell #21 (comment))
• Vom früheren Meetings weiter: Relative Ortsindikatoren (siehe Meeting vom 16. April 2024)
• Mehrere Attribute und Deskriptoren, selbes Objekt (Mehrere Beziehungen zur selben Erwähnung in Attribut/Deskriptor #15 (comment))
• Details innerhalb von Head-Spans?
• BeNASch-Versionierung

[raykyn]

Meeting vom 9. September 2024 (14:00)

Nach einer längeren Pause hat sich das Team endlich wieder versammelt. Der Schwerpunkt lag wegen der längeren Pause vorerst auf organisatorischen Themen:

Organisation des Projekts

Das Projekt wird vorerst in klassischer Open-Source-Struktur fortgeführt. Dabei behält das Basel-Berner-Kernteam vorerst die Entscheidungsgewalt, welche Änderungen am Schema umgesetzt werden. Dieses Team stellt gleichzeitig die Administratoren des Github-Repositories dar.

• Liste von Admins zur Homepage des Schemas hinzufügen

Wir möchten aber Mitsprache und Beiträge aus der weiteren Community anstossen.

• Liste von Contributors zur Homepage des Schemas hinzufügen

Engagierte Community-Mitglieder können auf Beschluss des Admin-Teams ins Admin-Team aufgenommen werden.

Workflow für Änderungsbeschlüsse

Soll eine Änderung am Schema erfolgen, sollten folgende Schritte geschehen:

1. Vorschlag im Diskussionsforum
   Der Vorschlag wird ausformuliert und samt Beispielen im Diskussionsforum gepostet. Idealerweise werden auch Lösungsvorschläge präsentiert. Dieser Schritt erhöht nicht nur die Übersichtlichkeit und Nachvollziehbarkeit von Entscheidungen, er ermöglicht auch, den Forenpost in den Meeting-Protokollen zu verlinken.

2. Diskussion im Meeting
   Wird ein Vorschlag nicht schon während der Foren-Diskussion verworfen (weil z.B. unumsetzbar oder auf einem Missverständnis des bestehenden Schemas entstanden), kann der Vorschlag bei einem Meeting diskutiert werden. Das Admin-Team sollte den Vorschlag sobald wie möglich zur Diskussion in einem Meeting bringen. Dabei sollte idealerweise beachtet werden, dass der/die Verfasser:in des Vorschlags beim Meeting anwesend sein kann. Im Meeting wird beschlossen ob der Vorschlag abgelehnt, abgeändert oder unverändert umgesetzt wird. Wird eine Umsetzung beschlossen, wird eine Person gewählt, welche die Umsetzung für das Schema formuliert (idealerweise der/die Verfasser:in des Vorschlags).

3. Umsetzung
   Die gewählte Person formuliert den Vorschlag im Schema aus und nimmt die Änderungen direkt in den .md-Dateien vor. Das veränderte Schema wird dann als Pull-Request zum Review gestellt. Alle interessierten Personen sind eingeladen, sich an solchen Reviews zu beteiligen und Änderungen anzubringen.

4. Änderung
   Sobald das Admin-Team bestimmt, dass ein PR bereit für die Veröffentlichung ist, wird der PR in den Hauptzweig des Schemas gemergt und ist damit offiziell.

Versionierung

Versionierung des Schemas sollte bald beginnen. Dabei verwenden wir ein System von Major und Minor Versionsnummern. Ein Unterschied im Minor-Bereich bedeutet eine Änderung im Schema, die kompatibel mit früheren Versionen ist (z.B. ein optionaler Zusatz). Eine Änderung im Major-Bereich bedeutet eine Änderung die möglicherweise Inkompatibilität mit früheren Versionen bedeutet.

Nicht jede kleine Änderung bedeutet das Release einer neuen Version. Das Admin-Team bestimmt, wann eine neue Version veröffentlicht wird.

Für eine erste Version sollten noch folgende Änderungen am Schema geschehen:

• Separation von Schema-Regeln von Schema-Klassen
• Formulierung der Projekt-Schema-Dokumentation

Meeting-Planung

Um weitere langen Pausen in den Meetings zu vermeiden, werden von nun an Meeting-Zeiten semesterweise geplant. Meetings finden alle zwei Wochen statt solange mindestens eine Person des Admin-Teams teilnehmen kann. Absagen werden den Teilnehmenden so früh wie möglich kommuniziert.

Die in diesem Meeting festgelegte Meeting-Zeit kann leider doch nicht so umgesetzt werden, weil eine Ringvorlesung der Uni Bern zur selben Zeit stattfindet. Eine neue Uhrzeit wird am nächsten Meeting (wieder Montag, 14 Uhr CEST) festgelegt.

Der Meeting-Link wird nicht im Github veröffentlicht. Interessierte Personen melden sich bitte per E-Mail an ein Mitglied des Admin-Teams.

Heads bei Organisationen und Orten

Das Thema wurde erneut aufgenommen und beschlossen, die Head-Annotation bei Orten und Organisationen mit derjenigen von Personen in Einklang zu bringen. Das bedeutet, dass der Head bei Eigennamennennungen nicht mehr den Nicht-Eigennamen-Teil des Orts/der Organisation enthält.

Vorher:
"Das Kloster Klingental" => Head: "Kloster Klingental"

Nachher:
"Das Kloster Klingental" => Head: "Klingental"

Dafür muss Kloster eine Auszeichnung erhalten in Form eines Attributs (?), die genaue Kategorisierung ist hier noch zu besprechen.

• Beispiele im Schema anpassen

[raykyn]

Meeting vom 23. September 2024 (14 Uhr)

Meeting-Planung

Wie schon im letzten Protokoll beschrieben muss ein neuer Meeting-Zeitpunkt gefunden werden. Da leider nur zwei Personen des Admin-Teams anwesend waren, wird die Terminfindung auf interne Chats verschoben und der definitive Termin sobald wie möglich veröffentlicht.

BeNASch-Workshop

Die Organisation des in 2025 stattfindenden BeNASch-Workshops wurde besprochen, Details für breitere Kreise folgen im Oktober!

[raykyn]

Meeting vom 10. Oktober 2024

Meeting-Planung

Nach Absprache im Admin-Team findet das zweiwöchentliche Meeting von nun an jeweils Donnerstags um 14 Uhr statt. Nächster Termin ist demnach der 24. Oktober.

Versionierung

Das Thema Versionierung gestaltet sich mit Github Pages nicht ganz so einfach wie erwartet. @DominicWeber beschäftigt sich weiterhin mit einer möglichen konkreten Umsetzung. Ideen wie Veröffentlichung der HTML-Seiten oder einer Umwandlung der .md-Dateien in PDF werden diskutiert.

Wichtigster Punkt vor einer offiziellen ersten Version des Schemas ist noch die Trennung von Regeln und Typologien, sowie die Etablierung der Typologien selbst (ein Thema das bisher nur in unzureichender Tiefe besprochen wurde).

Schema-Diskussionen

Unterscheidung von direkten und indirekten Koreferenzen #28

Der Vorschlag wurde im Meeting spontan besprochen und so akzeptiert. Eine Umsetzung im Schema wird angestossen.

Basis-Typologie (u.a. #20)

Die Diskussion rund um eine BeNASch-Typologie wurde neu aufgefahren. Dabei war die Frage erst einmal, ob eine bestimmte Typologie überhaupt über Schema-Konformität entscheiden sollte. Konsens war, das zumindest eine empfohlene Mindest-Typologie sinnvoll ist (z.B. PER, ORG, LOC) um Kompatibilität zwischen Projekten sicherzustellen. Zudem sollte ein Prozess existieren, mit dem Projekte weitere Typen, seien es "horizontale" Erweiterungen (z.B. eine ARTIFACT-Kategorie), oder "vertikale" Erweiterungen (z.B. eine Präzisierung wie "LOC_MOUNTAIN") gezeigt und übernommen werden können.
In dieser Diskussion wurde keine Basis-Typologie entschieden, und das Thema sollte weiterhin diskutiert werden. Der Workshop im Januar sollte eine gute Plattform bieten, um solche Grundsatzfragen zu diskutieren.

[raykyn]

Meeting vom 24. Oktober 2024

Besprechung und Beschluss von #33 .

Besprechung und Beschluss von #31 .

[raykyn]

Meeting vom 7. Oktober 2024 ist ausgefallen.

[raykyn]

Meeting vom 21. November 2024

Besprechung und Beschluss von #39 .

Besprechung der Handhabung von Kernen und Appositionen insbesondere bei Nicht-Personen. Noch kein Beschluss.

[raykyn]

Das Meeting vom 5. Dezember fällt aus. Das Meeting vom 19.12. wird auch ausfallen.

Das nächste Meeting findet ausserordentlich am 12.12. statt.

[raykyn]

Meeting vom 12. Dezember 2024

Besprechung und Beschluss von #41 #42 (in einem einzelnen Beschluss).

Grössere Anpassung des Schemas ist notwendig.