III. Veranstaltungen
Für das Auffinden bereits erfasster Types in der Datenbank sind wir wieder
bei der Schriftproblematik: Ohne Schriftsystem mit Orthographie kann man nicht
direkt nach einer Gebärde suchen. Das Projekt weicht, wie international üblich,
auf eine Reihe von Hilfskonstrukten mit ihren jeweiligen spezifischen Schwächen
aus:
• Glossierungen nutzen eine andere als die Zielsprache (in unserem Fall Deutsch)
und bergen damit das Risiko, vorschnell semantische Abgrenzungen der Glos-
sensprache auf die Zielsprache zu übertragen.
• Eine flächendeckende phonetische Transkription, etwa in HamNoSys (Ham-
burg Notation System for Sign Languages), verbietet sich aus Aufwandsgrün-
den. Möglich ist es jedoch, die Types in HamNoSys zu kodieren. Damit wird
es möglich, nach solchen spezifischen Merkmalen des Tokens in der Types-Da-
tenbank zu suchen, die wahrscheinlich aus der Kerngebärde stammen und nicht
Ergebnis morphologischer oder phonologischer Prozesse sind.
Ganz wichtig ist dabei, dass jede Type-Token-Zuordnung sofort überprüft
werden kann, indem man das Video des Tokens mit Videos anderer Tokens dessel-
ben Types vergleicht.
Findet man in der Datenbank keinen geeigneten Type, so legt man einen neu-
en an, vergibt eine Glosse, beschreibt das aufgefundene Token in HamNoSys und
wartet dann ab, ob sich im Laufe der Zeit mehr Tokens finden oder der Type im
Zuge einer Lemmarevision anderen Types zugeschlagen wird. Hinreichend beleg-
te Types werden dann im weiteren Prozess einer lexikographischen Analyse unter-
zogen und gelangen vielleicht schlussendlich in das Wörterbuch.
Es ist offensichtlich, dass dieses Vorgehen gut ausgebildeter Fachleute bedarf.
Wie aber soll zu Projektende der Endnutzer des Wörterbuchs einen Eintrag fin-
den? Der Zugang über das Deutsche scheitert eventuell gerade dort, wo der Wör-
terbucheintrag besonderen Wert für den Nutzer haben könnte, etwa bei Gebärden,
die kein direktes Pendant im Deutschen haben. Es erscheint auch kaum vorstell-
bar, dass DGS-Nutzer für die gelegentliche Konsultation eines Wörterbuches etwa
HamNoSys lernen. Unsere Vision ist vielmehr, dass der Benutzer die Gebärde,
nach der er sucht, in die Kamera seines Computers, Smartphones o. ä. gebärdet
und das Wörterbuch dann eine Übersicht der in Frage kommenden Einträge an-
zeigt, aus denen der Benutzer dann den gewünschten auswählt. Klappt dies mo-
mentan bei einem Prototypen, der 120 Gebärden kennt, so bleibt doch noch viel
zu tun, dies auf ein ganzes Wörterbuch zu skalieren.
Der Wörterbucheintrag wird übrigens keineswegs komplett in Gebärdenspra-
che verfasst sein, sondern viele Strukturelemente auf Deutsch enthalten: Fast alle
Gebärdensprachnutzer sind bis zu einem gewissen Grade zweisprachig und wün-
schen, so das Ergebnis einer im Rahmen des Projektes durchgeführten Umfrage,
diese Zweisprachigkeit bei der Wörterbuch-Konsultation auszunutzen.
86
Für das Auffinden bereits erfasster Types in der Datenbank sind wir wieder
bei der Schriftproblematik: Ohne Schriftsystem mit Orthographie kann man nicht
direkt nach einer Gebärde suchen. Das Projekt weicht, wie international üblich,
auf eine Reihe von Hilfskonstrukten mit ihren jeweiligen spezifischen Schwächen
aus:
• Glossierungen nutzen eine andere als die Zielsprache (in unserem Fall Deutsch)
und bergen damit das Risiko, vorschnell semantische Abgrenzungen der Glos-
sensprache auf die Zielsprache zu übertragen.
• Eine flächendeckende phonetische Transkription, etwa in HamNoSys (Ham-
burg Notation System for Sign Languages), verbietet sich aus Aufwandsgrün-
den. Möglich ist es jedoch, die Types in HamNoSys zu kodieren. Damit wird
es möglich, nach solchen spezifischen Merkmalen des Tokens in der Types-Da-
tenbank zu suchen, die wahrscheinlich aus der Kerngebärde stammen und nicht
Ergebnis morphologischer oder phonologischer Prozesse sind.
Ganz wichtig ist dabei, dass jede Type-Token-Zuordnung sofort überprüft
werden kann, indem man das Video des Tokens mit Videos anderer Tokens dessel-
ben Types vergleicht.
Findet man in der Datenbank keinen geeigneten Type, so legt man einen neu-
en an, vergibt eine Glosse, beschreibt das aufgefundene Token in HamNoSys und
wartet dann ab, ob sich im Laufe der Zeit mehr Tokens finden oder der Type im
Zuge einer Lemmarevision anderen Types zugeschlagen wird. Hinreichend beleg-
te Types werden dann im weiteren Prozess einer lexikographischen Analyse unter-
zogen und gelangen vielleicht schlussendlich in das Wörterbuch.
Es ist offensichtlich, dass dieses Vorgehen gut ausgebildeter Fachleute bedarf.
Wie aber soll zu Projektende der Endnutzer des Wörterbuchs einen Eintrag fin-
den? Der Zugang über das Deutsche scheitert eventuell gerade dort, wo der Wör-
terbucheintrag besonderen Wert für den Nutzer haben könnte, etwa bei Gebärden,
die kein direktes Pendant im Deutschen haben. Es erscheint auch kaum vorstell-
bar, dass DGS-Nutzer für die gelegentliche Konsultation eines Wörterbuches etwa
HamNoSys lernen. Unsere Vision ist vielmehr, dass der Benutzer die Gebärde,
nach der er sucht, in die Kamera seines Computers, Smartphones o. ä. gebärdet
und das Wörterbuch dann eine Übersicht der in Frage kommenden Einträge an-
zeigt, aus denen der Benutzer dann den gewünschten auswählt. Klappt dies mo-
mentan bei einem Prototypen, der 120 Gebärden kennt, so bleibt doch noch viel
zu tun, dies auf ein ganzes Wörterbuch zu skalieren.
Der Wörterbucheintrag wird übrigens keineswegs komplett in Gebärdenspra-
che verfasst sein, sondern viele Strukturelemente auf Deutsch enthalten: Fast alle
Gebärdensprachnutzer sind bis zu einem gewissen Grade zweisprachig und wün-
schen, so das Ergebnis einer im Rahmen des Projektes durchgeführten Umfrage,
diese Zweisprachigkeit bei der Wörterbuch-Konsultation auszunutzen.
86