Goebl2008_ALD-II_5_Arbeitsbericht (2007)

Transcrição

¿: 5. Arbeitsbericht
(2007)
Hans Goebl, Edgar Haimerl,
Fabio Tosques
1. Vorbemerkung
Wir legen hiemit den fünften Arbeitsbericht zum zweiten Teil (¿) des Ladinienatlasses ½ vor, der im Prinzip die im Jahr 2007 geleisteten Arbeiten betrifft.
Doch wird de facto von den etwa zwischen den Pfingsttagen der Jahre 2007 und
2008 durchgeführten Aktivitäten die Rede sein. In förderungspolitischer Hinsicht
befindet sich das Projekt ¿ im vierten Jahr der heuer (2008) auslaufenden
FWF-Förderung 17326 (Gesamtdauer mit Verlängerung: 2004–2008) und im
zweiten Jahr der letztes Jahr (2007) ausgesprochenen FWF-Förderung 20047
(zunächst bewilligt für den Zeitraum 2007–2010).
2. Bericht des Projektleiters (Hans Goebl)
2.1 Personalstand, Mitarbeiter, Arbeitsabläufe
Im Berichtszeitraum waren für den ¿ die folgenden Damen und Herren als
voll- und halbbeschäftigte Mitarbeiter in den unten näher bezeichneten Funktionen tätig:
“Ladinia”, XXXII, 2008, 273–324
ISSN 1124–1004; © Istitut Ladin Micurà de Rü, San Martin de Tor (BZ)
274
Ladinia XXXII (2008) / Hans Goebl, Edgar Haimerl, Fabio Tosques
Für die Datenerhebung im Feld:
• Walter Strauß: Seine Tätigkeit beim ¿ hat am 1.10.2001 begonnen und
ist nach Ablauf der beim FWF üblichen Sechs-Jahres-Frist am 30.9.2007 zu
Ende gegangen.
Für EDV-Arbeiten:
• Fabio Tosques: Seine Mitarbeit beim ¿ begann am 1.4.20071 und betrifft vor allem die Pflege und Weiterentwicklung des Programms DMG. Er
ist demnach – gemeinsam mit den Damen Agnes Haberl und Heidemarie
Beer – im Rahmen der Produktion von Probekarten tätig.
• Xavier Casassas: Er hat seine Tätigkeit beim ¿ am 1.12.2005 begonnen
und ist damit innerhalb des FWF-Projektes 17326 offiziell zum Nachfolger
von Slawomir Sobota geworden. Er wird bis Ende August 2008 aus den
Mitteln des Projektes 17326 und darnach aus jenen des Projektes 20047
bezahlt. Wie bereits im letzten Jahr berichtet, kooperiert X. Casassas mit F.
Tosques und S. Sobota in EDV-technischer Hinsicht.
• S. Sobota: Seine zunächst vom FWF finanzierte Mitarbeit begann am
15.10.1999 und dauerte unter Einhaltung der vom FWF vorgeschriebenen
Sechsjahres-Frist bis zum 14.10.2005. Seither wird sein Verbleib im Projekt
¿ durch den Einsatz FWF-externer Mittel2 und durch die Mithilfe der
Universität Salzburg sichergestellt.
Zwischenzeitlich hat sich eine gewisse Arbeitsteilung herausgebildet, die vorsieht, dass F. Tosques sich dominant um die Weiterentwicklung, Anwendung und
Pflege des Programms DMG kümmert, während X. Casassas für die weiter unten
näher beschriebene Sound-Datenbank (SDB) zuständig ist. S. Sobota obliegen
allgemeine EDV-Arbeiten im Umfeld zum Projekt ½, wozu u. a. die Pflege und
Anwendung der Salzburger Dialektometrie-Software “Visual DialectoMetry”
und visualisatorische Aufgaben im Bereich der Disseminierung von in Salzburg
erarbeiteten geolinguistischen Forschungserträgen gehören.
Für die philologische Betreuung der Erstellung der Probekarten:
Dazu wurden zwei mit einem halben Dienstvertrag versehene Mitarbeiterinnen eingestellt. Es sind dies die Magistrae A. Haberl (ab 1. November
2007) und H. Beer (ab 1.1.2008).
F. Tosques war vom 1.4. bis 30.9.2007 beim FWF-Projekt 17326 und ab 1.10.2007 bei dessen Nachfolge-Projekt 20047 angestellt.
1
Siehe dazu die in Abschnitt 2.5 genannten Institutionen.
2
¿: 5. Arbeitsbericht (2007)
Durch die Beendigung der Feldarbeiten im Oktober des Jahres 2007 und den
wenig später erfolgten Abschluß der EDV-Erfassung3 der im Feld gesammelten
Daten ergab sich für die innere Organisation der gesamten Projektarbeit eine völlig neue Struktur. Seit dem letzten Viertel des Jahres 2007 gilt es, die Arbeiten auf
drei Schienen voranzutreiben:
a) Erstellung von Probekarten (siehe dazu Kapitel 2.2)
b) Erstellung der Sound-Datenbank (siehe dazu Kapitel 2.3)
c) Fortführung der Archivarbeiten (siehe dazu Kapitel 2.4)
2.2 Erstellung der Probekarten
Es ist dies ein insgesamt recht komplexer Vorgang, bei dem nicht nur viele Hände wohlorganisiert zusammenarbeiten, sondern auch die unterstützenden EDVInstrumente (“Dialect Map Generator”, DMG) optimal funktionieren müssen. In
personeller Hinsicht besteht die um diesen Vorgang bemühte Gruppe aus dem
EDV-Koordinator F. Tosques, den zwei eben erwähnten halb angestellten Mitarbeiterinnen Haberl und Beer, die vor allem ihre philologischen Kompetenzen4 in
das Projekt einbringen, und dem Projektleiter.
Im einzelnen erfolgen die Arbeiten dergestalt, dass der Inhalt der ¿-Datenbank, worin sich bekanntlich 217 Dateien mit den Antworten auf jeweils 1.063
Gesamt-Fragen befinden, die wiederum z. T. aus mehreren “Teil-Fragen” bestehen, “Stück um Stück”5 kartiert wird. Die zwischen den 1.063 Gesamt-Fragen
(bzw. -Antworten) und den rund 1.449 Teil-Fragen (bzw. -Antworten) bestehenden Zahlenverhältnisse ersieht man aus der folgenden Tabelle:
An der EDV-Eingabe und nachfolgenden Korrektur der letzten im Feld gesammelten Daten waren
erneut bewährte Mitarbeiterinnen aus früheren Tagen beteiligt. Dazu gehörten: Ilaria Adami (Trient)
und Brigitte Rührlinger (Pisa) sowie Liza Klinger, Gertraud Klingler und Zaneta Sobota (alle aus
Salzburg).
3
Dazu gehören aber auch eine sehr gute Dosis an Präzision, Ausdauer und Liebe zur Sache. Ich erinnere
in diesem Zusammenhang an die italienische Redewendung von den lavori di Certosini.
4
Die Kartierung erfolgt demnach in aufsteigender Abfolge der etwa 1.449 Teil-Antworten.
5
275
276
Eine Gesamt-Frage/-Antwort
entspricht x-Teil-Frage(n)/
Teil-Antwort(en)
1
838
2
252
3
174
4
108
5
45
6
18
7
14
Summe der
Teil-Fragen/Teil-Antworten
Anzahl der jeweiligen
Teil-Fragen/Teil-Antworten
1.449
Tab. 1: Summe der Einzel- und Teilfragen im Fragebuch des ¿
Verständnisbeispiel: Im Fragebuch des ¿ scheint unter der Nummer 81/0
die Gesamt-Frage “Può darsi (= può essere) | che sia | cieco” auf. Diese zerfällt
in die folgenden drei Teil-Fragen: 81/1: Può darsi (= può essere) , 81/2: che sia
und 81/3: cieco. In einem während bzw. nach der Enquête korrekt ausgefüllten
Fragebuch befinden sich also an der betreffenden Stelle drei (transkribierte und
fallweise mit metalinguistischen Kommentaren versehene) Teil-Antworten. Laut
Tabelle 1 gibt es 174 derart strukturierte Gesamt-Fragen.
Bei der nach Teil-Antworten erfolgenden Kartierung werden nicht nur die betreffenden Daten erstmals in ihrer räumlichen Verteilung sichtbar, sondern müssen
zunächst einmal in formaler Hinsicht mehrfach korrigiert werden. Diese Kontrollen zielen u. a. auf die Frage, ob die vorliegende Erst-Kartierung überhaupt publikationswürdig ist und ob sie mit den Daten einer zweiten oder gar dritten TeilAntwort zu einer umfassenderen Kombinationskarte vereinigt werden kann.
Der Ausdruck der erwähnten Probekarten erfolgt auf Vordrucken im Format A2,
worauf sich sieben – in diskreten (grünen, blauen und roten) Pastelltönen gehaltene – Prüfpfade befinden, entlang derer – nach Aufdruck des linguistischen
Inhalts einer Teil-Antwort – der Gesamtinhalt der betreffenden Probekarte detailgenau abgesucht werden kann.
Klarerweise ist es in der Praxis mit einem einzigen Kartenausdruck für eine TeilAntwort nicht getan, so dass eine relativ große Anzahl der eben erwähnten Vor-
drucke6 bereit gehalten werden muss. Neben diesen Prüfpfad-Ausdrucken stehen
seit letztem Jahr auch Ausdrucke mit dem gut bekannten hellblauen Grundnetz des
½ bereit, so dass es schon jetzt möglich ist, nach Durchlauf aller Testphasen einen
Kartenausdruck im definitiven kartographischen Outfit herzustellen (siehe dazu die
beiliegende Karte 4).
In diesem Zusammenhang verdient die kartierungstechnische Leistungsfähigkeit
des Programms DMG ein besonderes Lob. Bei der bisher erfolgten Durchsicht von
rund 120 Probekarten hat sich gezeigt, dass die Transkriptionen hinsichtlich Unterbringung in den für sie vorgesehenen (virtuellen) Boxen, fallweiser Verschiebung
in den Kartensektor “Leggenda” sowie hinsichtlich der Realisierung von Turmnotationen und Hochstellungen vom Programm DMG in hervorragender Weise gemanagt werden. Insofern erübrigen sich alle fallweise damit verbundenen Korrekturarbeiten, wodurch eine enorme Zeitersparnis erreicht werden kann.
Zur logistischen Bändigung der beim Umgang mit vielen hunderten A2-Vordrucken unvermeidbaren Papier-Massen wurden entsprechende Behältnisse eingekauft bzw. vom Projektleiter hergestellt. Es sind dies einerseits Metall-Kartei
schränke, die zur Aufnahme von Hängeregistraturen im Format A3 ausgelegt
sind, und andererseits hölzerne Rollwagen zur Aufbewahrung sowie zum Anund Abtransport der A2 großen Vordrucke.
Bei den Metall-Karteischränken konnte auf die aus dem Projekt ¾ vorhandenen Bestände zurückgriffen werden, die allerdings um zwei neu angekaufte
Exemplare ergänzt werden mussten;7 bei den Rollwagen handelt es sich um zwei
vom Projektleiter passgenau aus Holz hergestellte Modelle.
Die Herstellung von Probekarten besteht allerdings keineswegs nur aus dem Ausdruck und der Durchsicht von A2 großen Kartenblättern. Vielmehr geht diesem
Ausdruck eine ausgetüftelte Prüf- und Kontrollarbeit voraus, die auf der Grundlage ganz spezieller Listenausdrucke beginnt. Diese Listenausdrucke,8 deren Nützlichkeit bei der Ausarbeitung des ¾ voll erkannt worden war, haben zum Ziel,
So wurden im Herbst 2007 2.000 Stück Prüfpfad-Vordrucke bestellt und geliefert, die derzeit fast zur
Gänze verbraucht sind.
6
Damit stehen im ½-Archiv derzeit sieben Metall-Karteischränke zur Aufnahme aller Probekarten des
¿ bereit. Da zur Zeit für fast die Gesamtheit aller Teil-Fragen des ¿-Fragebuchs bereits rund
1.700 Prüfpfad-Karten ausgedruckt worden sind, ist die Kapazität dieser sieben Metall-Karteischränke
schon ziemlich ausgelastet.
7
Diese Listen werden in der Folge (v.a. im Kapitel 3) auch als “Transkriptionslisten” bezeichnet.
8
277
278
den Inhalt einer Teil-Antwort in verschiedenen Anordnungen wiederzugeben.
Diese wären u.a.:
• geordnet nach Messpunktnummern,
• vorwärts alphabetisch geordnet nach “Antwort-Typen”, d.h. nach formal
völlig identischen Transkriptionen,
• rückwärts alphabetisch geordnet nach “Antwort-Typen” (wie oben).
Da die im Feld zu jeder Teil-Frage gesammelten Antworten neben der (ersten)
Hauptantwort auch weitere Antwortreflexe umfassen können, kann es sein, dass
neben einer “ersten Version” der Antworten9 zu einer Teilfrage auch eine ”zweite” und eine “dritte” (etc.) Version existieren. Da fallweise eine gemeinschaftliche Unterbringung aller im Feld gesammelten Versionen auf einem Kartenblatt
aus Platzgründen nicht möglich ist, mussten schon früh Überlegungen angestellt
werden, wie man im Gesamtprojekt ¿ derartige überkragende Informationen
behandelt. Derzeit ist vorgesehen, diese Informationen in “Supplementbänden”
(SB) zusammenzufassen, die – in einer derzeit noch nicht abzusehenden Stückelung – den Kartenbänden des ¿ beigegeben werden sollen. Einsichtigerweise
muss man aber schon jetzt bei den Redaktionsarbeiten an die damit verbundenen
Fragen denken. Überdies stellt die Behandlung der zweiten und dritten Versionen
auch eine spezielle Herausforderung an die Leistungsfähigkeit des Programms
DMG dar (siehe dazu weiter unten Kapitel 3).
Die vorhin erwähnten Listen werden – stets auf Blättern mit verschiedenen Farben10 – von den Mitarbeiterinnen A. Haberl und H. Beer zunächst ausgedruckt,
dann nach bestimmten Kriterien11 durchgesehen und hinsichtlich der dabei entdeckten Fehler adnotiert. Abschließend erfolgen die ersten Korrektureingaben in
die ¿-Datenbank.
Derzeit sieht das Programm DMG vor, dass der Gesamtumfang der zur “ersten Version” zählenden
Transkriptionsdaten auf einem Kartenblatt untergebracht wird.
9
Die Größe beträgt stets A4.
10
11
Eines dieser Kriterien ist beispielsweise die Frage der korrekten Setzung der Tonakzente. Das Fehlen
solcher Akzente kann – aus sehpsychologischen Gründen – mittels der Liste VALI (siehe Tabelle 2)
sehr rasch und sicher festgestellt werden.
Abkürzung
voller Name
Inhalt und Funktion
VALI
vorwärts alphabetische
Liste
Enthält die Antworten auf eine Teil-Antwort –
zusammengefasst nach Typen – in vorwärts alphabetischer Anordnung
RALI
rückwärts alphabetische
Liste
Enthält die Antworten auf eine Teil-Antwort –
zusammengefasst nach Typen – in rückwärts alphabetischer Anordnung
MPLI-Tot
nach Messpunkten sortierte
Liste (eine Gesamt-Frage
bzw. -Antwort betreffend)
Enthält die Antworten auf alle zu einer GesamtFrage gehörenden Teil-Fragen, geordnet nach den
von 1 bis 217 aufsteigend sortierten Messpunkten
MPLI-Teil
Liste (nur eine Teil-Frage
bzw. -Antwort betreffend)
Enthält die Antworten auf eine Teil-Frage, geordnet nach den von 1 bis 217 aufsteigend sortierten
Messpunkten
MPLI-Anm
Liste (nur die mit Anmerkungen versehenen Transkripte betreffend)
Enthält nur jene Transkripte, zu denen in den
Fragebüchern Anmerkungen vermerkt worden
sind. Geordnet nach den von 1 bis 217 aufsteigend sortierten Messpunkten. Enthält nur jene
Messpunkte, an denen Anmerkungen vorhanden
sind.
SBLI
Liste für den Supplementband (SB)
Enthält die Versionen 2ff. der Antworten auf eine
Teil-Frage bzw. -Antwort
Tab. 2: Übersicht über die während der Redaktionsphase verwendeten Transkriptionslisten
Die Aufgabe des Projektleiters besteht nun darin, die nach der Listen-Kontrolle
erstellten Ausdrucke der Probe-Karten durchzusehen und darauf alle auffällig gewordenen Probleme in möglichst lesbarer Schrift zur weiteren Behandlung durch
die Damen A. Haberl und H. Beer festzuhalten. Dabei ist nicht nur eine philologisch-linguistische Kontrolle des gesamten Kartenbildes vorzunehmen, sondern
auch eine Vorentscheidung hinsichtlich des definitiven Kartenlayouts zu treffen.
Zudem muss an die Korrektheit der Transkriptionen und der neben diesen stehenden metalinguistischen Anmerkungen, sowie an die Gestaltung des Kartenkopfes
und des fallweise vorzusehenden Kartenkommentars (“Comm.”) gedacht werden. Siehe dazu auch die detaillierte Vorstellung des Zustandekommens der hier
im Anhang präsentierten vier Probekarten: Kapitel 5.
Die Kontrollarbeit des Projektleiters wird sich de facto auf etwas weniger als
2.000 Probe-Karten erstrecken. Angesichts des damit verbundenen Zeitaufwandes ist dafür ein vom Rektor der Universität Salzburg für das Wintersemester
2008/09 (umfassend den Zeitraum vom Oktober 2008 bis zum Februar 2009)
gewährtes Freisemester überaus nützlich.
279
280
Es versteht sich, dass für den geordneten Ablauf dieser komplexen Arbeit einschlägige Kontroll-Bücher bereitgestellt und die verschiedenen Arbeitsabläufe
und deren Ineinandergreifen entsprechend standardisiert worden sind.
2.3 EDV-Entwicklung und -Anwendung
Für die volle Dauer des Berichtszeitraums bestand unsere EDV-Mannschaft aus
unserem EDV-Supervisor Edgar Haimerl (wohnhaft nunmehr in Seattle, USA)
und seinen drei Kooperanten F. Tosques, X. Cassasas und S. Sobota. Der frühere
Projekt-Mitarbeiter Andreas Wagner, der sich sehr große Verdienste um den Ausbau des Programms DMG erworben hatte und in der Mitte des Jahres 2007 mit
einer informatischen Arbeit über die Belange von DMG diplomiert worden war,
hat nach der Sponsion und der unmittelbar darnach erfolgten Annahme einer
einschlägigen Anstellung unser Projekt im Herbst 2007 verlassen. Damit ging
die Hauptverantwortung für die Pflege und Weiterentwicklung von DMG auf die
Schultern von F. Tosques über.
Zur Erledigung der nötigen Koordinierungsgespräche ist E. Haimerl mit diesem
und auch mit X. Casassas weiterhin in engem Kontakt verblieben, wobei erneut
neben E-Mail und dem Internet-Telefonie-Programm Skype das ½-interne Koordinations- und Kontroll-Programm Codebeamer zur Anwendung kamen.
Daneben wurden – stets unter Anleitung von E. Haimerl – die Arbeiten für die
Sound-Datenbank (SDB) vorangetrieben, für die bereits im Jahr 2007 wesentliche EDV-technische Vorarbeiten geleistet worden waren.12 Allerdings hat sich
das Gros der im Bereich der SDB zu leistenden (und auch geleisteten) Arbeiten
deutlich von der EDV-Programmierung ab- und zur philologisch orientierten
EDV-Präparierung der Sound-Daten hin orientiert.
Zur Klarstellung muss etwas ausgeholt werden. Bekanntlich ist – abgesehen von
der allerletzten Phase der Feldarbeiten – beim ¿ die Tondokumentation der
Feldaufnahmen mittels Mini-Disks (MD) der Firma Sony13 vorgenommen worden. Dabei waren die ExploratorInnen angehalten, sowohl auf den MD selber
als auch auf den diesen entsprechenden Seiten des jeweiligen Fragebuchs elektronische bzw. handschriftliche Markierungen anzubringen, die es ermöglichen
Siehe dazu Abschnitt 4.
12
Siehe dazu den detaillierten Bericht bei Goebl/Haimerl 2006, 209–212.
13
sollten, sich in Salzburg eine bestimmte Abfragesituation rasch und zielsicher
anhören zu können.
Glücklicherweise wurde diese Vorgabe von allen weiblichen Mitarbeiterinnen
des ¿ und der Hälfte der männlichen Mitarbeiter genau erfüllt. Leider haben
aber zwei andere männliche Mitarbeiter diesbezüglich enorm geschlampt, so dass
eine umfassende Abhörung der von ihnen unmarkiert nach Salzburg gebrachten
Mini-Disks nötig geworden ist. Diese Abhörarbeit ist nicht nur umständlich und
zeitaufwändig, sondern verursacht auch dementsprechend hohe Zusatzkosten.
Im Zuge dieser Arbeiten mussten – stets unterstützt von den netzbasierten Korrektur-Modulen unserer SDB – mehrere über Werkvertrag in das Projekt ¿
integrierte MitarbeiterInnen14 umfängliche Kontrollarbeiten an den Fragebüchern und den dazugehörenden MD’s vornehmen. Die genaue und stets effiziente
Koordinierung dieser auch logistisch prekären Arbeit wurde vom 1. Dezember
2007 bis 31. Mai 2008 in sehr effizienter Weise von Frau G. Klingler besorgt.
Dabei wurden unter anderem von den Mitschnitten aller 217 Aufnahmen aus
Gründen der Datensicherung Kopien auf DVD hergestellt und wohl geordnet im
½-Archiv eingelagert.
Die im Verlauf dieser Korrekturarbeiten mittels der erwähnten Nach-Markierungen komplettierten Enquêten wurden bzw. werden nacheinander von X. Casassas in die SDB integriert und zur routinemäßigen Anhörung im Netz bereitgestellt. Allerdings ist der damit verbundene Arbeitsaufwand sehr groß, so dass
das angepeilte Endziel – nämlich die Herstellung der netzbasierten Verfügbarkeit
aller Ton-Materialien des ¿ – allerfrühestens am Ende des Jahres 2008 erreicht werden kann.
Zum Bereich der EDV-Arbeit im weiten Sinn gehörten außerdem mehrmalige
Reparaturen und Ergänzungsarbeiten am Hardware-Bestand des ½, wobei ganz
besonders auf die Funktionalität unserer fünf Server15 geachtet wurde.
An diesen Arbeiten waren (bzw. sind auch weiterhin) beteiligt: Uta Gruber, Christian Hajek, G. Klingler, Adriano Neto, Constanze Rigler und Z. Sobota (alle Salzburg).
14
Siehe dazu Kapitel 3.7.3.
15
281
282
2.4 Archivarbeit
Auch hier sind gegenüber dem vierten ¿-Arbeitsbericht keine wesentlichen
Änderungen zu vermerken. L. Klinger hat sich erneut um die Etikettierung, Einsortierung und Archivierung der im Feld gesammelten Diapositive gekümmert,
während die bibliothekarische Erfassung der Neuzugänge für die ½-Bibliothek
weiterhin in den Händen von Pavel Smečka lag.
Leider ist es auch bei der Versorgung der Diapositive zu einem Engpaß gekommen, weil einer der männlichen Exploratoren diese nicht zeitgerecht und auftragsgemäß abgeliefert hat. Doch besteht die Hoffnung, diese Lücke bald auffüllen zu können.
2.5 Finanzierung
Die Finanzierung der ¿-Arbeiten wurde so wie in den vorhergehenden Berichtszeiträumen aus den folgenden Quellen bestritten:
• aus Mitteln der FWF-Projekte 17326 (bis 30.8.2008) und 20047 (ab 1. September 2007),
• aus Förderungsmitteln des Istitut Ladin Micurà de Rü, San Martin de Tor
(BZ),
• aus Förderungsmitteln des österreichischen Bundesministeriums für Unterricht, Kunst und Kultur (bm:ukk), Wien,
• aus Förderungsmitteln des Istitut cultural ladin “Majon di Fascegn”, Vich
(TN),
• aus Förderungsmitteln des Landes Tirol, Innsbruck,
• durch eine Förderung von Seiten der Universität Salzburg: Diese betraf nicht
nur die fortdauernde Bereitstellung der Infrastruktur des ½-Archivs (Räume, Mobiliar, Beleuchtung, Heizung, EDV-Anschluß etc.) sondern auch die
Durchführung der rechnerischen Verwaltung der vom FWF gewährten Personal- und Sach-Mittel sowie die Gewährung eines größeren Betrages für
die Weiterbeschäftigung von S. Sobota.
2.6 Danksagungen
Diese ergehen erneut nicht nur an die im vorliegenden Abschnitt genannten Institutionen, sondern mit besonderer Herzlichkeit auch an alle inner- und außerhalb
Salzburgs tätig gewordenen MitarbeiterInnen. Darunter hebe ich ganz besonders
jene hervor, die in allen Sektoren der Kartenerstellung (F. Tosques, A. Haberl, H.
Beer) und der Präparierung der Sound-Datenbank (G. Klingler und X. Casassas)
tätig sind. Und ein ganz besonders warmer Dank geht über den Atlantik und den
ganzen nordamerikanischen Kontinent hinweg an unseren EDV-Spiritus rector
E. Haimerl, der dem Gesamtprojekt ½ nunmehr schon seit 18 Jahren “mit Herz
und Seele” verbunden ist.
Den institutionellen Förderern seien abschließend zwei Dinge versichert:
• dass das Projekt ¿ gegenüber den zuletzt publizierten Zeitplänen voll
im Takt liegt und damit der für 2011 vorgesehene Projektabschluss weiterhin aufrecht bleibt,
• dass meinerseits nach wie vor alles daran gesetzt werden wird, diesen Termin einzuhalten.
283
284
3. Bericht zur Erstellung der Probekarten (Fabio Tosques, Edgar Haimerl)
3.1 DMG – Redaktionsphase
Als im Oktober 2007 die Daten des letzten Fragebuchs in die Datenbank eingegeben wurden, ist das Projekt Ladinienatlas/¿ in eine neue Phase eingetreten:
in die Phase der Redaktion der Atlaskarten. Diese zielt primär auf die Umlegung
des Inhalts der 217 Fragebücher des ¿ auf Karten und sekundär auf die Korrektur der Daten in der Datenbank sowie auf Erweiterungen bei der Software
Dialect Map Generator (DMG) ab, die – wie bekannt – für die Erstellung der
Karten und Listen eingesetzt wird. Während dieser Phase werden somit sämtliche
EDV-Komponenten des Projekts ¿ auf ihre Gültigkeit, Funktionsfähigkeit
und Zuverlässigkeit geprüft sowie gegebenenfalls verbessert und erweitert.
Die Hauptarbeit während der Redaktionsphase besteht zurzeit aus dem Ausdrucken der Karten und der dazugehörenden Transkriptionslisten.16 Zu jeder Karte
werden im allgemeinen bis zu fünf Transkriptionslisten ausgedruckt, die die Kartenredaktion in entscheidender Weise unterstützen.
3.2 Organisation und Aufgabenverteilung während der Redaktionsphase
Die während der Redaktionsphase zu bewältigenden Aufgaben verteilen sich aktuell auf drei Gruppen:
1.A. Haberl und H. Beer erstellen und drucken Karten mit den dazu gehörenden Transkriptionslisten und fügen mit Hilfe der Software DMG Korrekturen bezüglich der Transkriptionen ein.
2.Hans Goebl überprüft und redigiert darnach Karten und Listen.
3.E. Haimerl, Piotr Popardowski und F. Tosques übernehmen Korrekturen
und Erweiterungen an der Software Dialect Map Generator (DMG) und realisieren – sofern dies nötig ist – programmgestützte Änderungen der Daten
in der Datenbank.
In einer vierten Gruppe würden sich die Arbeiten rund um die Sound-Datenbank
(SDB) befinden, worüber im Kapitel 4. von E. Haimerl berichtet wird.
Zu einer erklärenden Tabelle siehe Kapitel 2.2 (Tab. 2).
16
Im folgenden werden die einzelnen Schritte der Kartenredaktion kurz aufgezählt:
• Ausdruck der Liste VALI,17 um in einem ersten Schritt typische Akzentfehler entdecken und korrigieren zu können.
• Eingabe der darauf entdeckten Fehler als Korrekturen in DMG.
• Ausdruck und anschließende Korrektur der Liste MPLI-Anm.18 Die Korrektur der Anmerkungen betrifft mehrere Aspekte:
◊Anmerkungen, die im DMG-Feld “Zusatzinfo” definiert sind, müssen
dorthin verschoben werden.
◊Von den Exploratoren auf deutsch erstellte Anmerkungen müssen auf
Italienisch übersetzt werden, was derzeit von H. Beer erledigt wird.
◊Zu lange Anmerkungen müssen, da auf der Atlaskarte nur wenig Platz
zur Verfügung steht, auf ein textliches Minimum gekürzt werden.
• Ausdruck der Liste MPLI-Tot19 sowie nochmalige Kontrolle und Korrektur
der Akzentsetzung.
• Ausdruck einer Pfadkarte:20 wenn möglich, bereits unter Berücksichtigung
von mehr als nur einer Version.21
• Ausdruck von Kombi(nations)karten und den dazu neu zu erstellenden Listen MPLI-Tot. Unser Bemühen geht dahin, wo immer möglich mehrere
Teilfragen einer Gesamtfrage auf einer Kombikarte zusammenzufassen. Ob
dies im Einzelfall aus Platzgründen möglich ist, müssen die Kartenerstellerinnen A. Haberl und H. Beer durch den Vergleich mehrerer Kartenbilder
auf dem Bildschirm abschätzen.
• Überprüfung der Kombikarten (samt Listen) durch den ¿-Hauptkorrektor und -redaktor H. Goebl.
• Eingabe der entdeckten Fehler und der vorgenommenen Korrekturen in DMG.
• Markierung der Unterschiede zwischen den vorhandenen Versionen auf der
Liste MPLI-Tot, damit der Korrektor (H. Goebl) diese schnell erkennen
kann.
VALI: vorwärts alphabetisch sortierte Liste
17
MPLI-Anm: Liste zu allen Messpunkten (von 1-217): umfassend nur jene Messpunkte, wofür Anmerkungen der Exploratoren vorhanden sind.
18
MPLI-Tot: Liste zu allen Messpunkten (von 1-217): betreffen immer eine Gesamtfrage und umfassen
daher immer alle dazugehörenden Teilfragen.
19
Siehe dazu die angeschlossenen Karten 1-3.
20
Eine ¿-Karte kann – in Abhängigkeit von der Anzahl der pro Messpunkt erhobenen Antworten –
auch zwei, drei oder vier “Versionen” enthalten. Der gemeinsame Ausdruck mehrerer Versionen ist natürlich ein Platzproblem. Auf der Karte nicht darstellbare Versionen werden, wie oben bereits angegeben,
beim Druck des ¿ zusammenfassend in gesonderten Supplementbänden präsentiert werden.
21
285
286
• Ausdruck der Liste RALI.22
• Ausdruck der Listen MPLI-Teil und SBLI.23
• Änderungen, Anpassungen und Korrekturen am Programm DMG parallel
oder nach der Erledigung dieser Etappen.
Die Entwicklung des Programms DMG ist inzwischen soweit fortgeschritten,
dass wir in der Lage sind, in diesem Bericht die einzelnen Phasen der Redaktion
einer Atlaskarte exemplarisch vorstellen zu können (siehe dazu auch die beiliegenden Karten 1–4 und das Kapitel 5).
Gleich zu Beginn der Redaktionsphase zeigte sich, dass das Programm DMG
für die Karten- und Listenerstellung einiger Erweiterungen bedurfte, die wir im
folgenden Abschnitt kurz erläutern möchten.
3.3 Anpassungen und Erweiterungen beim DMG-Client/-Server für die Redaktionsphase
Gleich nach dem Anlaufen der Redaktionsphase wurde deutlich, dass zusätzlich
zu den bis Ende 2007 in DMG implementieren Transkriptionslisten VALI, RALI,
MPLI noch weitere Listen benötigt wurden. Dabei wurden die folgenden Listen
definiert und DMG-seitig implementiert: SBLI, MPLI-Anm, MPLI-Tot, MPLITeil.24
Bei der Erstellung der Programm-Module für weitere Listen sowie bei der Korrektur von Ausdrucken der bisher implementierten Listen zeigte sich, dass bei
der primären EDV-Erfassung der ¿-Daten nicht immer sorgfältig gearbeitet
worden war.25 So verfälschten beispielsweise eingegebene Leerzeichen am Ende
von Transkripten die alphabetisch sortierten Listen. Die falschen Leerzeichen
mussten daher zunächst mittels einer SQL-Abfrage26 entfernt werden. Inzwischen
RALI: rückwärts alphabetisch sortierte Liste
22
SBLI: Liste jener Belege, die in den Supplementbänden (SB) Platz finden sollen.
23
Zu den Abkürzungen siehe die Tabelle 2 in Kapitel 2.2.
24
Ob es tatsächlich an der Sorgfalt der Dateneingeber lag oder diese für die komplexen Eingaben vielleicht zu kurz eingeschult worden waren, lässt sich inzwischen nicht mehr feststellen. In jedem Fall
hatten die Programmierer immer wieder mit Problemen und langen Debugging-Sessions zu kämpfen.
Dabei wurde sehr häufig festgestellt, dass es sich nicht um Programmfehler (Bugs) in DMG handelte,
sondern um fehlerhafte Datensätze, die zu unkorrekten oder unvollständigen Ausgaben durch das Programm DMG führten, die hier näher erläutert werden.
25
SQL = Standard Query Language: eine standardisierte Abfragesprache für relationale Datenbanken.
26
sorgt der Response Dialog von DMG (siehe Abbildung 16) dafür, dass Leerzeichen am Ende von Transkripten vor dem Zurückschreiben in die Datenbank automatisch entfernt werden.
Dann zeigte sich beim Ausdruck von Listen und Karten, dass der vom DMG-Eingabemodul vorgesehene Zusatz segmento inalterato (= “unveränderter Teil”) viel
zu selten eingegeben wurde. Dieser Zusatz ist aber wichtig, um identische Teile
einer zusammengesetzten Frage programmgestützt identifizieren zu können. So
kommt es beispielsweise häufig vor, dass sich die verschiedenen Versionen einer Gesamtfrage nur in einzelnen Teilfragen voneinander unterscheiden. Damit
beim Ausdruck der zu einer Gesamtfrage gehörenden Teilfragen nicht permanent
identische Antworten auf den Karten und Listen aufscheinen, wurde in DMG der
Zusatz “segmento inalterato” eingeführt.
Schließlich mussten wir feststellen, dass sehr häufig das DMG-Eingabefeld “Zusatzinfo” nicht mit den im Fragebuch kanonisch vorgegebenen Abkürzungen beschickt wurde, sondern vielmehr die betreffenden Abkürzungen (und ähnliche
Informationen) in das Freitextfeld “Anmerkungen” eingegeben wurden. Deshalb
wurde die neue Transkriptionsliste MPLI-Anm implementiert, damit die Korrektoren einen schnellen Überblick über die vorhandenen Einträge im Feld “Anmerkungen” erhalten und diese, wenn nötig, von dort in das Feld “Zusatzinfo”
verschieben können.
Die Eingabefehler in der Datenbank konnten glücklicherweise zum großen Teil
programmgestützt korrigiert werden. Eine manuell durchzuführende Korrektur
der Daten hätte bei rund 300.000 durchzusehenden Datensätzen zu erheblichen
Verzögerungen geführt und den Zeitrahmen des Projekts empfindlich gestört.
3.4 Zusammenfassung: Arbeitsfortschritte am Programm DMG zwischen Mai 2007 und
April 2008
1.Säubern und Korrigieren der Datensätze in der ¿-Datenbank.
2.Implementierung von neuen Listen. Dies geschah durch Erweiterungen am
DMG-Client und besonders am Assembler, wo der Text für die Listen und
Karten vor dem Druck zusammengesetzt (“assembliert)” wird.
3.Ständige Verbesserungen an den Kartenausdrucken (betrifft die Softwarekomponente MapGenerator). Ziel: Einstellung der Fontgrößen und Redaktion der Legenden und deren Inhalt nach den Vorgaben von ¾, damit die
Kartenbilder von ¿ und ¾ einander genau entsprechen.
287
288
4.Sonstige Verbesserungen an den Softwarekomponenten DMG-Client und
DMG-Server, die es beispielsweise gestatten, die Auswahl aller Antworten
zu einer bestimmten Fragenummer gezielt vorzunehmen und zwischen den
Anmerkungen der Enquêteure, die auf den definitiven Karten erscheinen
sollen, und jenen, die nur für interne Zwecke genutzt werden, zu unterscheiden.
5.Migration der DMG-Hauptkomponenten von Windows nach Linux auf einen neu im ½-Archiv aufgestellten Rechner.
3.5 Vorstellung der aktuellen Softwareversion von DMG
Abbildung 3 zeigt im Wesentlichen jene Hauptfunktionen von DMG, die für die
Redaktionsphase benötigt werden. Die Zahlen 1–4 beziehen sich auf die Kapitel
3.5.2 bis 3.5.5 und bezeichnen jene Arbeits-“Pfade”, die in der aktuellen Redaktionsphase von den Mitarbeitern im Projekt ¿ immer wieder begangen werden
müssen. Die einzelnen Arbeitsvorgänge werden nacheinander im Detail erläutert
und zum besseren Verständnis mittels entsprechender Screenshots veranschaulicht. Dafür wird ein exemplarisches Beispiel von der Erstellung der Karte bis
zur definitiven Karte durchlaufen. Als Beispielkarte dient die Gesamtfrage 109
“Sono stato a Venezia [, ieri]”, die sich aus den zwei Teilfragen 109/1 “Sono stato
…” und 109/2 “… a Venezia” zusammensetzt.
3.5.1 Pfad1: DMG-Client installieren und starten
Siehe dazu die Abbildung 1.
Nach dem Download und der Installation von DMG wird das Programm unter
Windows mit einem Doppelklick auf die Datei <dmg.bat> gestartet.27 Voraussetzung für das Funktionieren von DMG ist das Vorhandensein eines Java Runtime
Environments (JRE).28
Der Startbildschirm von DMG ist in Abbildung 1 zu sehen. Registrierte Nutzer
können sich bei DMG mit ihrem Account anmelden (Abbildung 2). Wie dem all-
Unter Linux wird das Programm mit der Datei <dmg.sh> gestartet.
27
Download unter: <http://java.sun.com/javase/downloads/index.jsp>. Für DMG muss mindestens eine
Version ab 5.0 gewählt werden.
28
Abb. 1: Startbildschirm des Programms DMG
Abb. 2: Anmeldung beim Programm DMG
gemeinen Aktivitätsdiagramm in Abbildung 3 entnommen werden kann, stehen
dem Nutzer dann einige Optionen zur Verfügung.
Nach der erfolgreichen Anmeldung bei DMG erscheinen die Reiter “Orte”, “Karten” und “Ortstatus Karte” (siehe dazu Abbildung 4), wobei sich automatisch
der Reiter “Orte” öffnet. In diesem erhält der Nutzer einen schnellen Überblick
über die Ortsnummer, den Ortsnamen, den Beginn und das Ende der Exploration
sowie über den Upload-Status des Fragebuchs, d.h. er erfährt, ob das Fragebuch
schon in der Datenbank erfasst worden ist.
In Abbildung 5 sind die implementierten Auswahlmöglichkeiten im Menü “Datei” zu sehen. Wir können hier einen Ort, eine Karte oder eine Fragenummer auswählen. Die einzelnen Punkte “Ort auswählen”, “Karte auswählen”, “FragenNr
auswählen” und “Neue Karte erstellen” werden anschließend in den jeweiligen
Abschnitten genau beschrieben.
Wir wollen nun – siehe Abbildung 3 – mit Pfad 1 (betreffend die Kartenerstellung) beginnen und dann sukzessive auf die weiteren Funktionen von DMG eingehen.
289
290
Abb. 3: Aktivitätsdiagramm der Hauptfunktionen des DMG-Clients
3.5.2 Pfad 1: Erstellung einer neuen Atlaskarte
Seit die Daten aller 217 Orte in der ¿-Datenbank erfasst sind, ist es möglich,
vollständige Karten und Listen mit den Transkripten aller Orte zu drucken. Dafür
mussten allerdings in einem ersten Schritt alle potentiellen Karten erstellt werden. Insgesamt wurden bisher ca. 1.700 Karten mit Hilfe von DMG definiert und
bereits ebenso viele Karten ausgedruckt.
Das ¿-Fragebuch umfasst 1.063 (Gesamt-)Fragen, von denen die meisten
nur aus einer einzelnen Frage bestehen. Die längsten Gesamtfragen setzen sich
aus sieben Teilfragen zusammen: siehe dazu z. B. die Frage 736 “Quando | il
cacciatore | ebbe | sparato, | gli cadde | per terra | il fucile”, wobei die vertikalen
Striche die Grenzen der Einzelfragen innerhalb der Gesamtfrage kennzeichnen.
Die in Kapitel 2.2 präsentierte Tabelle 2 informiert über die Verteilung der Einzel- und Teilfragen im Fragebuch. Theoretisch müssen für die Redaktionsphase
mindestens 1.449 Karten29 erstellt werden. Daneben können aber auch durch die
gemeinsame Kartierung von zwei (und mehr) Teilfragen Kombinationskarten erstellt werden, woraus sich die große Anzahl der derzeit bereits definierten 1.700
Probekarten erklärt.30 Siehe dazu im Detail Tabelle 3.
pro Gesamtfrage
Anzahl der Gesamtfra- Anzahl der Einzel- bzw. Anzahl möglicher bzw.
gen (m) im ¿-Fra- Teilfragen im Frage- sinnvoller Einzel- und
gebuch mit genau n buch (m · n)
Kombinationskarten
Einzel- bzw. Teilfragen
2
126
n
Teilfragen
1
3
4
5
6
7
Gesamt
838
838
838
58
174
348
27
9
3
2
1.063
252
108
45
18
14
1.449
378
270
135
63
56
2.088
Tab. 3: Anzahl der Gesamt-, Einzel- und Teilfragen im ¿-Fragebuch
Die Zahl 1.449 entspricht der Summe aller Einzel- und Teilfragen des ¿ Fragebuchs.
29
Theoretisch können insgesamt 2.088 “sinnvolle” Kombinationskarten innerhalb einer Fragenummer
erstellt werden. Die Anzahl der möglichen Karten ergibt sich aus der Summe der Kombinationen:
. Diese erhöht sich natürlich, wenn auch verschiedene Fragenummern miteinander kombiniert werden sollen, wie beispielsweise beim ¾, wo häufig Karten erstellt wurden, die Singularund Pluralformen enthielten.
30
291
292
Wenn der Menüpunkt “Neue Karte erstellen...” ausgewählt wird (siehe dazu Abbildung 5), öffnet sich ein neues Dialogfenster (siehe dazu Abbildung 6). In diesem kann nun eine Karte erzeugt werden. Dabei sind die folgenden Eingabefelder
zwingend auszufüllen: Kartentitel und Auswahlbedingungen. “Kontext 1” wird
nur ausgefüllt, wenn es sich um eine Teilfrage einer zusammengesetzten Frage
handelt. In “Kontext 1” steht dann die ganze Frage. Im hier beschriebenen Beispiel “Sono stato a Venezia” würde bei den jeweiligen Teilfragen “Sono stato …”
und “… a Venezia [, ieri]” in Kontext 1 die zusammengesetzte Frage stehen, die
dann auch auf den Ausdrucken der Karten in der Titellegende erscheint (siehe
dazu auch die Karten 1–4).
“Kontext 2” wird für Referenzen auf andere Sprachatlanten genutzt werden, besonders für Verweise auf den AIS, das von Karl von Ettmayer im Jahr 1902 publizierte
Korpus, den ASLEF und den ¾. Im Eingabefeld “Kommentar” kann der Korrektor kommentierende Texte einfügen, die dann auf der Karte (oben, in der rechten
Hälfte) in der Kommentarlegende (Comm.) ausgedruckt werden. Abbildung 7 zeigt
den ausgefüllten Kartendialog der Kombinationskarte von Frage 109/1 “Sono stato
…” mit Frage 109/2 “… a Venezia”: “Sono stato a Venezia [, ieri]”.
Abb. 4: DMG nach erfolgreich vorgenommener Anmeldung
Im Dialog für die Kartenerzeugung (siehe dazu Abbildung 6) wird eine neue Karte
erstellt, indem einerseits die obligatorischen und optionalen Textfelder ausgefüllt
werden und andererseits über den Button “neue Bedingung” die entsprechenden
Fragen aus dem Fragebuch ausgewählt werden. Wenn eine Kombinationskarte
über zwei Teilfragen erstellt werden soll, dann müssen zwei Bedingungen angegeben werden.
Abb. 5: DMG: Auswahloptionen im Menü “Datei”
Abb. 6: DMG-Dialog “Karte erstellen”
293
294
Abb. 7: DMG-Dialog am Beispiel der Karte “Sono stato a Venezia [, ieri]”
(Siehe dazu auch die beiliegenden Karten 1–4).
Nachdem in DMG eine Karte erstellt worden ist, kann über deren weiteres Schicksal entschieden werden. Im Menü “Drucken” hat der Anwender die Möglichkeit,
entweder die erstellte Karte oder die entsprechenden Listen zu drucken. In Kapitel 3.5.3 findet man dazu weitere Informationen.
3.5.3 Pfad 2: Drucken von Karten und Listen
Während der Redaktionsphase ist der reibungslose Ausdruck von Karten und
Listen sehr wichtig. Neben der Eingabe von Korrekturen von Eingabefehlern
und sonstigen sprachlichen Verbesserungen in die Datenbank können dabei aber
auch – bislang allerdings nur sehr selten – Probleme mit dem Kartenlayout auftreten, die dann eine Anpassung im Programm DMG erforderlich machen. Da
derzeit sehr viele Einzel- und Kombinationskarten ausgedruckt werden, wird
dabei unsere Software tatsächlich zum ersten Mal auf ihre volle Funktionsfähigkeit getestet.
Abb. 8: DMG: Fenster mit der Übersicht über die erstellen Karten
In den letzten Jahren konnten die Software-Techniker während der Entwicklung
von DMG schon aus rein zeitlichen Gründen immer nur einen kleinen Teil der
möglichen ¿-Karten erzeugen und daran das Layout der Karten überprüfen. Inzwischen hat sich gezeigt, dass DMG bezüglich der Erkennung von Kollisionen, des Positionierens von Transkripten auf der Karte, des Zeichnens von
Turmnotationen und hochgestellten Zeichen und des Erzeugens von Legenden
hervorragend funktioniert. Nur bei selten auftretenden, ungünstigen Datenkonstellationen war das Layout der Karten nicht immer zufriedenstellend. Besonders
die überschneidungsfreie Positionierung von Türmen, die von einem hochkomplexen Algorithmus, der zu großen Teilen von Andreas Wagner entwickelt wurde,
erledigt wird, hat bei sehr wenigen Karten zu kleineren Problemen geführt, die
aber in der Zwischenzeit weitgehend gelöst werden konnten.
Die Menge der auszudruckenden Karten und Listen ist über den Reiter “Karten”
ersichtlich (siehe dazu Abbildung 8). Zu sehen sind die Felder “KartenNr” (automatisch vom System vergeben), “KartenTitel”, “Kontext1”, “Kontext2” und
“Kommentar”, deren Funktionen schon in Abschnitt 3.5.2 beschrieben worden
sind. Um nun eine Karte auszuwählen, wird diese markiert und über den Menüpunkt “Datei → Karte auswählen” seligiert. Im Menü “Drucken” kann dann entschieden werden, welcher Typ von Karten oder Listen ausgedruckt werden soll
(siehe dazu Abbildung 9).
295
296
Abb. 9: DMG: Menüpunkt “Karte drucken”
Abbildung 10 zeigt einen Ausschnitt aus dem “Kartendruck Dialog”. Hier kann der Kartentyp, der
gedruckt werden soll, ausgewählt
werden. Daneben ist es noch möglich, zwischen einer Vorschau und
einer Druckversion zu wählen. Für
die Redaktionsphase wird zunächst
versucht, eine Karte nur unter HeAbb. 10: DMG: Menü zur Auswahl jener Kartenranziehung der Version 1, d.h. der typen, die gedruckt werden können
jeweils ersten auf eine Teilfrage
gegebenen Antworten, zu drucken.
Dafür wird vor dem Ausdruck zur Überprüfung zuerst eine PDF-Datei der Karte
erstellt. Wenn (unter Heranziehung der Overflow-Legende auf der linken Kartenhälfte) alle Transkriptionen der 1. Version auf die Karte passen, kann im nächsten
Schritt versucht werden, mehrere Versionen auf die Karte zu drucken bzw. auf
dieser unterzubringen.
Parallel zu einer bestimmten Karte werden immer die entsprechenden Transkriptionslisten ausgedruckt. Nach der Auswahl des Menüpunkts “Transkriptionslisten
der Karte drucken” (siehe Abbildung 11) öffnet sich ein neuer Dialog, worin die
möglichen Listen ausgewählt werden können (siehe Abbildung 12).
Abb. 11: DMG-Menüpunkt “Transkriptionslisten drucken”
Abb. 12: DMG: Menü zur Auswahl der Transkriptionslisten
Abbildung 13 (siehe nächste Seite) zeigt den Ausschnitt der Liste MPLI-Tot zur
hier vorgestellten Kombinationskarte “Sono stato a Venezia”.
297
298
Abb. 13: Ausschnitt zweier Beispiellisten: oben die nach den Messpunktnummern sortierte Transkriptionsliste MPLI-Teil zur Teilfrage “… a Venezia” und darunter die Liste MPLI-Tot zur Gesamtfrage “Sono stato a Venezia [, ieri]”. Hinweis: zu den Messpunkten 4 und 7 existiert eine zweite Version. Der Übersichtlichkeit halber werden auf den Listen MPLI-Tot von zusammengesetzten
Fragen keine Zusatzinformationen gedruckt (cf. Messpunkt 4, wo bei der zweiten Version auf der
Liste MPLI-Teil der Zusatz “(arc.)” erscheint).
3.5.4 Pfad 3: Änderung von messpunktspezifischen Daten bzw. Informationen
Durch die Auswahl eines Ortes (bzw. Messpunkts) besteht die Möglichkeit, die
folgenden Informationen neu in die Datenbank einzutragen oder abzuändern:
• Transkripte
• Daten zu den betreffenden Informanten
• allgemeine Informationen zu diesem Messpunkt.
Ein Ort wird ausgewählt, indem dieser markiert und dann auf das Symbol “Ort”
geklickt wird. Alternativ können mit “Datei → Ort auswählen” die Daten des
Ortes geladen werden (siehe dazu Abbildung 14).
Abb. 14: DMG: Auswahl eines Messpunktes (Ortes)
Nachdem die Daten des Ortes geladen wurden, öffnen sich in DMG neue Reiter:
• “Response Liste”: Liste aller Antworten zu dem ausgewählten Ort
• “Informantenliste”: Daten der in dem ausgewählten Ort befragten Informanten.
Wenn die Antworten eines Ortes korrigiert werden sollen, so genügt dazu ein
Klick auf den Reiter “Response Liste”; es öffnet sich darnach eine Liste aller zu
diesem Ort vorhandenen Transkripte (siehe dazu Abbildung 15).
299
300
Abb. 15: DMG: Liste der Transkripte eines ¿-Messpunktes (am Beispiel von Ort 3, Scuol)
Eine einzelne Response kann bearbeitet werden, indem diese markiert und im
Menü “Bearbeiten → Response” die entsprechende Antwort ausgewählt wird.
Daraufhin öffnet sich ein neues Fenster, der “Response Dialog” (siehe dazu Abbildung 16).
Abb. 16: DMG: Bearbeitungsmodus einer Response
Der Nutzer hat nun die Möglichkeit, neue Versionen anzulegen oder diese zu
verschieben. Ebenso kann, falls bei längeren Sätzen zwischen Frage und Antwort
hinsichtlich der Abfolge der syntaktischen Konstituenten Verschiebungen auftreten, die Reihenfolge der Teilfragen verändert werden. Die Transkripte können
entweder über die Tastatur (durch die Eingabe der kanonischen ½-Codes) oder
mit Hilfe des Alphabetikums (durch Anklicken des jeweiligen Transkriptionszeichens mit der Maus) korrigiert werden (siehe dazu Abbildung 17).
Abb. 17: DMG: “Alphabetikum” (am Bildschirm anklickbare Liste aller beim ¿ verwendeten
Lautzeichen)
Zu einem bestimmten Ort können die zu einem neuen Informanten gehörenden
Informationen dadurch angelegt werden, indem man zuerst den betreffenden Ort
markiert und dann den Menüpunkt “Bearbeiten → Informant erfassen” auswählt.
Wenn aber die Daten zu einem Informanten aktualisiert oder korrigiert werden
sollen, so ist im Reiter “Informantenliste” der entsprechende Eintrag zu markieren und der Menüeintrag “Bearbeiten → Informant” auszuwählen (siehe dazu
Abbildung 18). Es öffnet sich sodann die Eingabemaske für die Informantendaten (siehe dazu Abbildung 19).
Abb. 18: DMG: Liste der an einem bestimmten Messpunkt befragten Informanten (am Beispiel
von Ort 1, Tschlin)
301
302
Abb. 19: DMG: Maske für die Eingabe der Daten der befragten Informanten
3.5.5 Pfad 4: Wahl der Fragenummer
Während durch die Auswahl eines Ortes sämtliche Transkripte desselben bearbeitet werden
können, dient die Auswahl der Fragenummer
der Korrektur der Antworten aller Orte zu einer
bestimmten Fragenummer. Das Modul “Fragenummer wählen” ist ein relativ neues Feature in
DMG. Es zeigte sich bei der Redaktion der Karten, dass es für die Durchführung der Korrekturen oft einfacher ist, wenn zu einer Fragenummer alle Transkripte gewählt werden können.
Abb. 20: DMG: Eingabemaske
“Fragenummer auswählen”
Eine Liste aller Antworten zu einer bestimmten Frage erhält man durch die Auswahl des Dialogs “Datei → Fragenummer”. Es öffnet sich ein Eingabefeld, worin
die Fragenummer eingegeben werden kann (siehe dazu Abbildung 20).
Wenn eine Fragenummer eingegeben wird, öffnet sich in DMG ein neuer Reiter
mit einer Liste der Antworten auf eine bestimmte Fragenummer (siehe Abbildung
21).
Abb. 21: DMG: Liste der Antworten auf eine bestimmte Frage des ¿-Questionnaires (am Beispiel der Gesamtfrage 109/1+2: Sono stato a Venezia [, ieri]) (Siehe dazu auch die beiliegenden
Karten 1–4).
Die vorgefundene Antwort kann dann durch den Redaktor bearbeitet werden,
indem der Eintrag mit der Maus ausgewählt und der Menü-Eintrag “Bearbeiten → Response” angewählt wird. Es öffnet sich der “Response Dialog” (siehe
Abbildung 16). Die Bearbeitung der Responses erfolgt – wie im Abschnitt 3.5.4
beschrieben – über den “Response Dialog”.
3.6 Zukünftige Anforderungen an DMG
3.6.1 Supplementbände
Schon jetzt ist abzusehen, dass nicht immer alle Antworten auf die jeweiligen
Karte bzw. in deren Overflowlegende passen werden. Daher müssen jene Antwor-
303
304
ten, die auf der Karte keinen Platz finden, in Supplementbände (SB) ausgelagert
werden. Damit die in den Supplementbänden aufgelisteten Transkripte schnell
gefunden werden, müssen diese nach den Kartennummern sortiert werden. Unter
einer bestimmten Kartennummer werden die SB-Informationen nach den Ortsnummern gereiht, wobei die verschiedenen Versionen untereinander angeordnet
werden sollen.
3.6.2 Erstellung der Indexbände
Wie beim ¾ sollen auch beim ¿ zwei Indexbände erstellt werden, wobei
in beiden Fällen aus Gründen der Datenkomprimierung die schon beim ¾
eingesetzte, vereinfachte Transkription “½-light”31 verwendet werden soll: 1.
vorwärts alphabetisch sortiert, 2. rückwärts alphabetisch sortiert.
Dafür muss in einem ersten Schritt das sehr detaillierte Transkriptionssystem des
¿ in einen reduzierten Zeichensatz (½-light) übergeführt werden. Wir können dabei auf jene Erfahrungen zurückgreifen, die beim ¾ im Rahmen der
Entwicklung des Programms IRS (“Index Retrieval System”)32 gemacht worden
waren. Für die Übersetzung des Transkriptionssystems wird eine Tabelle verwendet, “die jedem phonetischen Zeichen der detaillierten Transkription ein Zeichen
des reduzierten Zeichensatzes zuordnet. Dabei können mehrere phonetische Zeichen der detaillierten Transkription auf ein Zeichen der reduzierten Transkription
abgebildet werden” (Haimerl 2005, 535).
In Anlehnung an den ¾ soll ein neues Index Retrieval System (IRS)33 erstellt
werden. Dafür sprechen verschiedene Gründe:
1.Im Projekt befindet sich derzeit kein Mitarbeiter, der das auf der Microsoft
Foundation Class Library in C++ geschriebene Index Retrievalsystem des
¾ an die neuen Anforderungen anpassen kann.
2.Das IRS des ¾ funktioniert nur auf Windows-Betriebssystemen.
3.Die Datenstruktur des ¿ ist wesentlich komplexer als jene des ¾.
Daher wäre eine Anpassung des IRS des ¾ wahrscheinlich aufwendiger
als die Implementierung eines neuen IRS. Dies betrifft auch Punkt 1.
4.Das IRS des ¾ ist nicht im Internet verfügbar.
Cf. dazu “Ladinia”, XX, 1996, 218.
31
Zum Programm IRS siehe Haimerl 2005, passim.
32
Siehe im Netz unter: <http://www.sbg.ac.at/rom/people/proj/ald/irs/irs_home.html>.
33
In Anlehnung an den ¾ soll das neue IRS die folgenden Eigenschaften besitzen:
• alle Antworten sollen in reduzierter Transkription “½-light” angezeigt
werden;
• das IRS soll sowohl als Stand-alone-Applikation als auch über das Internet
verfügbar sein.
• Sortierung:
◊vorwärts alphabetisch
◊rückwärts alphabetisch
◊nach Kartentitel / Stimulus.
• Suchmöglichkeiten:
◊nach einer Response
◊nach einer Response rückwärts alphabetisch
◊nach den Antworten auf einer Karte.
• Navigationsmenü:
◊Dialog mit Eingabemöglichkeit von Anfangsbuchstaben
◊gehe zum ersten Eintrag (Anfang)
◊gehe zum letzten Eintrag (Ende)
◊gehe zur nächsten Seite
◊gehe zur vorherigen Seite
◊gehe zum nächsten Buchstaben
◊gehe zum vorherigen Buchstaben.
• Beim Doppelklick auf eine Response öffnet sich eine Infobox, die Informationen zur Response anzeigt:
◊die Response selbst
◊den Kartentitel
◊die Kartennummer
◊die Häufigkeit
◊die Belege – die Nummern jener Orte, wo die Response vorkommt.
3.7 Meine Erfahrungen als neuer Mitarbeiter beim Projekt ¿ im Bereich
Softwareentwicklung/EDV (Fabio Tosques)
Im diesem Abschnitt möchte ich kurz auf die Erfahrungen eingehen, die ich als
Neuling im Projekt Ladinienatlas / ¿ gemacht habe und dabei vor allem beschreiben, dank welcher Tools und Hilfen ich mich relativ schnell einarbeiten
konnte. Zunächst muss ich gestehen, dass ich bisher nur an kleineren EDV-Projekten mitgearbeitet habe. Keines dieser Projekte hatte bezüglich der Softwareentwicklung eine vergleichbare Dimension. Der Einstieg beim ¿ war also
305
306
ein “Sprung ins kalte Wasser”, den ich v.a. dank der geduldigen und tatkräftigen
Unterstützung von E. Haimerl und A. Wagner “überlebt” habe. Daneben hat natürlich auch die gute materielle Ausstattung des Projekts den Einstieg erleichert.
Abgesehen von der persönlichen Unterstützung haben sich sowohl die klare Projektstruktur als auch die vielen Tools und Hilfen, die seit Jahren projektbegleitend
von den externen Mitarbeiten (besonders E. Haimerl und A. Wagner) erstellt
worden sind, als besonders hilfreich erwiesen. Die verwendeten Tools waren in
den vorhergehenden Arbeitsberichten immer wieder von E. Haimerl ausführlich
beschrieben worden, so dass hier nur kurz deren wichtigste Eigenschaften und
Aufgaben zusammengefasst werden sollen.
3.7.1 Projektstruktur
Die für die Kartenproduktion relevanten Projekte unterteilen sich in:
• DMG-Client
Dient zur Datenerfassung, Datenkorrektur und Generierung von Karten und
Listen. Der DMG-Client diente bis Ende 2007 v.a. zum Erfassen der Daten, d.h. zur Eingabe von vollständigen Fragebüchern in die ¿-Datenbank. Seit Oktober 2007 sind alle Fragebücher in der Datenbank erfasst. Die
DMG-Client-Anwendung wird seitdem besonders für die Datenkorrektur
und die Kartenredaktion verwendet.
Literatur: Goebl et al. 2004, 127; Goebl/Haimerl 2005, 119; Goebl/Haimerl
2006, 219.
• DMG-Server
Die DMG-Server-Komponente sorgt für den korrekten Datenaustausch zwischen DMG-Client und der ¿-Datenbank.
Literatur: Goebl/Haimerl 2005, 117 und Goebl/Haimerl 2006, 217.
• MapGenerator
Dient zur Erzeugung von Karten. Die Komponente MapGenerator wurde
von A. Wagner als Framework implementiert. Es handelt sich dabei um
eine eigene Programm-Komponente, die als Verbindung zwischen dem
DMG-Client und den GIS Frameworks Tools34 fungiert.
Literatur: Goebl/Haimerl/Wagner 2007, 165ff.
GIS: Geographic Information System.
34
Neben diesen Komponenten wird noch das von E. Haimerl entwickelte BOX
Framework für die GUI35 Erstellung verwendet. Im BOX Framework sind nützliche Java-Klassen implementiert, die als Templates für die Erstellung von graphischen Benutzerschnittstellen verwendet werden.
Bei allen Softwarekomponenten wird strikt eine klare Projektstruktur eingehalten. Grundlage für die Softwareentwicklung bildet der Rational Unified Process
(RUP).36 Dabei handelt es sich um ein Metamodell für Vorgehensmodelle bei der
Entwicklung von Software. Die Projektstruktur in der Entwicklungsumgebung
Eclipse spiegelt dieses Vorgehensmodell wieder, wobei sich im Verzeichnis doc
der jeweiligen Eclipse-Projekte die RUP-Dokumente37 befinden.
3.7.2 Entwicklungsprozess und Tools
3.7.2.1 Dokumentation (in DMG und Wiki)
Bei DMG wurden sowohl der Software-Entwicklungsprozess als auch die einzelnen Komponenten sowie ausführliche Hilfen zur Konfiguration der eingesetzten
Komponenten sehr gut dokumentiert. Bisher war die Dokumentation an drei verschiedenen Orten (im Eclipse-Projekt, Wiki und Task-Tracking-System) abgelegt
worden. Zum einen litt darunter die Übersichtlichkeit und zum anderen war es
schwierig, die einzelnen Dokumente entsprechend zu pflegen. Daher wurden in
den letzten Monaten die Dokumente in zwei Bereiche aufgeteilt bzw. zusammengeführt, ggfs. aktualisert oder überarbeitet:
1.Die spezielle Dokumentation zur Softwareentwicklung für DMG befindet
sich innerhalb von Eclipse im doc-Verzeichnis.
2.Die HowTos,38 die bisher über das doc-Verzeichnis in Eclipse, im Task-Tracking-System und im Wiki verteilt waren, wurden komplett ins projektinterne Wiki migriert und sind dort jetzt für alle Mitarbeiter einsehbar.
GUI: Graphical User Interface.
35
<http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process>.
36
Bei RUP handelt es sich um ein bewährtes Modell zur Entwicklung objektorientierter Software, bei
dem die folgenden Entwicklungsphasen streng eingehalten werden: Modellierung, Anforderungsanalyse, Designanalyse, Implementierung, Test und Auslieferung.
37
“Ein HowTo – englisch sinngemäß: “Wie mache ich ...” – ist eine zuweilen kurze Anleitung, die sich auf
das Lösen eines eng begrenzten Problems beschränkt. Da ein HowTo an den Laien gerichtet ist, wird
auf Details verzichtet, die meist nur für Experten interessant sind. Die in der Regel kurzen Beiträge sind
weniger umfangreich als eine Bedienungs- oder Gebrauchsanleitung oder ein (Benutzer)Handbuch. In
vielen Fällen ist das HowTo jedoch auch die einzige Informationsquelle: <http://de.wikipedia.org/wiki/
HowTo>. Vereinfacht lässt sich “HowTo” auch mit “So wird’s gemacht” übersetzen.
38
307
308
Während die Dokumentation zur Software-Entwicklung im Grunde nur für die
damit Befassten von Interesse ist, sollten die HowTos für alle Projektmitarbeiter
zugänglich sein. Damit diese Anforderung relativ einfach realisiert werden konnte, wurden die HowTos in das projektinterne Wiki verschoben.
3.7.2.2 Projektinternes Wiki39
Im projektinternen Wiki befindet sich inzwischen eine Vielzahl von verschiedenen
Anleitungen bzw. HowTos, die sich folgendermaßen unterteilen lassen:
• HowTos zur Konfiguration der Server und der installierten Software.
• HowTos zu Besonderheiten, die die Nutzung von DMG unter Windows oder
Linux beschreiben.
• HowTos, die die Redaktionsphase betreffen.
• HowTos, die die Backupstrategien und Sicherungsmaßnahmen der Server
beschreiben.
3.7.2.3 Die Diplomarbeit von Andreas Wagner
Von größter Bedeutung für die Einarbeitung in das Framework MapGenerator
war und ist die von A. Wagner (2007) verfasste Diplomarbeit mit dem Titel “Design and Implementation of MapGenerator …”40 und der vom gleichen Autor
verfasste Arbeitsbericht (cf. Goebl/Haimerl/Wagner 2007, 177ff.)
3.7.2.4 Das im Projekt verwendete Task-Tracking-System
Das Tool für Collaborative software development (CSD) (cf. Goebl et al. 2004,
130) ist von besonders großer Bedeutung, da die an der Entwicklung der DMGSoftware beteiligten Programmierer praktisch über die ganze Welt verteilt sind
(Seattle, Salzburg, Warschau) und dennoch stets genau wissen müssen, wer an
“Ein Wiki (hawaiisch für “schnell”), seltener auch WikiWiki oder WikiWeb genannt, ist eine Software
und Sammlung von Webseiten, die von den Benutzern nicht nur gelesen, sondern meist auch direkt
online geändert werden können. Wikis ermöglichen es verschiedenen Autoren, gemeinschaftlich an
Texten zu arbeiten. Ziel eines Wiki ist es im Allgemeinen, die Erfahrung und den Wissensschatz der
Autoren kollaborativ in Texten auszudrücken.” <http://de.wikipedia.org/wiki/Wiki>.
39
Eine PDF-Version der Arbeit findet man unter der folgenden Internet-Adresse: <http://ald.sbg.ac.at/
ALD-II/docs/andreas_wagner_magisterarbeit.pdf>.
40
welchem Stück Software arbeitet. Sie müssen daher zu jeder Zeit den aktuellen
Stand der Arbeit einsehen können.
• Task-tracking erfasst den Status von Aufgaben. An diese Tasks sind Aufwandsschätzungen, Endtermine, Ist-Aufwände und -Zustände, Kommentare
und Lösungsbeschreibungen angebunden.
• Interne Diskussionsforen und HowTos (inzwischen ins Wiki migriert).
• Das Task-Tracking-System wird von den Mitarbeitern intensiv genutzt. Dadurch ist es beispielsweise für neue Mitarbeiter möglich, die seit Projektbeginn eingebrachten Diskussionen, Lösungen, Lösungsvorschläge sowie
Details bezüglich neuer und schon implementierter Anforderungen nachzulesen. Das Studium der fast 500 für DMG-Client, DMG-Server und MapGenerator verfassten Tasks war bei der Einarbeitung ungemein hilfreich.
3.7.2.6 Cruisecontrol/Continuous Integration41
Cruisecontrol dient der automatischen Qualitätskontrolle der eingecheckten42
Software, d.h. alle Änderungen an der Software werden von diesem Tool auf ihre
Gültigkeit geprüft.
3.7.2.7 Concurrent Version System (CVS)
CVS wird seit Oktober 2007 nicht mehr verwendet. Inzwischen wurde ein Wechsel
zu SVN (Subversion) durchgeführt, welche einige Verbesserungen enthält. Dabei
war wichtig, dass bei der Migration keine History-Einträge aus dem CVS-System
verloren gehen. Diese Vorgabe wurde mit dem Tool cvs2svn und abschließenden
Anpassungen erreicht. Ein ausführlicher Bericht über die Details der Migration
von CVS nach SVN kann im projektinternen Wiki nachgelesen werden.
“An important part of any software development process is getting reliable builds of the software.
Despite its importance, we are often surprised when this isn’t done. We stress a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate
daily thus reducing integration problems” (Quelle: <http://cruisecontrol.sourceforge.net/>).
41
Einchecken bedeutet hier “in das zentrale Softwarerepository einspielen”, welches eine Versionierung
der Änderungen an der Software vornimmt und die vorgenommenen Aktualisierungen für alle im
Projekt tätigen Softwareentwickler verfügbar macht.
42
309
310
3.7.2.8 Skype/VNC
Inzwischen wird fast die gesamte Kommunikation über das Internet-TelefonieProgramm Skype abgewickelt:
• Skype hat den Vorteil, dass Gespräche innerhalb des weltweiten SkypeNetzes kostenlos sind.
• Telefonkonferenzen mit mehreren Teilnehmern sind möglich.
• Neben der mündlichen Kommunikation sind gleichzeitig Chats und das
Versenden von Dateien möglich.
• Zusammen mit Virtual Network Computing (VNC)43 können so Zeit- und
Ortsdistanzen relativ einfach überwunden werden.
3.7.3 Umstellung von Windows auf GNU/Linux44
Mit der Inbetriebnahme eines neuen Rechners45 am ½-Archiv sollte eine grundlegende Neustrukturierung der verwendeten Server- und Betriebssystem-Software sowie der Hardware erreicht werden:
• Wechsel des Betriebssystems von Windows 2000/XP auf GNU/Linux für
alle Serverkomponenten des ¿-Projekts (eingesetzt wird Ubuntu Linux
in der Version 7.04);
• Wechsel der Datenbanksoftware von MS-SQLServer auf PostgreSQL;
• Wechsel der Java Version von 1.4 auf 1.5;
• Migration und Upgrade der Produktionsumgebung von JBoss von 3.x auf
4.x:
• Wechsel der Quellcode-Verwaltung von CVS auf SVN;
• Migration von Cruisecontrol mit Anpassungen an die neue Umgebung.
Mit Hilfe von VNC kann der Bildschirminhalt eines Rechners, auf dem der VNC-Server läuft, an verschiedenen Orten gleichzeitig angezeigt werden. Alle am VNC-Server angemeldeten Nutzer sehen so
auf ihren lokalen PCs die Mausbewegungen, Tastatureingaben und sonstigen Eingaben des entfernten
Rechners und können so virtuell zusammenarbeiten.
43
Der Name GNU/Linux bezeichnet das Gesamtsystem, d.h. den Linux-Kernel und die zum Betriebssystem gehörenden Programme, die v.a. von der Free Software Foundation unter dem Namen GNU
(= GNU‘s Not Unix, ein rekursives Akronym) programmiert und gepflegt werden.
44
Technische Daten: Intel(R) Core(TM)2 CPU [email protected], 2 GB Hauptspeicher, Festplatten 320
GB und 500 GB. Beim Kauf des neuen Computers wurde sehr darauf geachtet, dass alle Hardwarekomponenten vom Linux Kernel unterstützt werden und keine proprietären Treiber benötigt werden;
dies deshalb, da proprietäre Treiber in der Regel nicht zu 100% von den Herstellern der Hardware
unterstützt werden und daher die Zuverlässigkeit, Funktionsfähigkeit und Performance des Systems in
der Folge erheblich beeinträchtigen können.
45
Die Umstellung des Betriebssystems von Windows auf GNU/Linux und der
Hauptkomponenten (JBoss, PostgreSQL, Cruisecontrol, Java von 1.4.x → 1.5.x,
CVS → SVN) auf den neu angeschafften Rechner hatte primär drei Ziele:
1.die Performance von DMG zu erhöhen,
2.einen weiteren Schritt in Richtung Open Source Software zu gehen (cf.
Goebl/Haimerl 2006, 216ff.). Das hat v.a. den Vorteil, dass die Kosten für
Software-Lizenzen weitgehend wegfallen und die verwendete Software
völlig transparent ist, da wir selbst Einblick in den Quellcode derselben
haben,
3.saubere Trennung der Aufgaben der fünf im Projekt ½ verwendeten Server:
◊DROM13: für VDM46 und die dazugehörenden Freigaben der bestehenden VDM-Projekte,
◊DROM15: Webserver und Backups von Projektmitarbeitern,
◊DROM16: Software-Entwicklung, Repository und DMG-Komponenten,
◊DROM80: Domaincontroller für die Domäne “Romanistik”,
◊DRUCKSERVALD2: Druckerserver, über den alle Projektmitarbeiter
ihre Druckjobs auf einen zentralen Drucker leiten können.
Ein willkommener Nebeneffekt war, dass ich mich im Zuge all dieser Arbeiten
gründlich mit der vorhandenen Architektur, d.h. mit der Konfiguration, den Eigenschaften und Funktionen der im Projekt eingesetzten Softwarekomponenten,
vertraut machen konnte.
Abbildung 22 zeigt das Zusammenspiel der einzelnen Komponenten nach der
eben geschilderten Umstellung. Gegenüber Abbildung 3 aus dem ¿-Arbeitsbericht von 2005 (cf. Goebl/Haimerl 2006, 215) werden besonders drei Unterschiede deutlich:
1.Die Datenkorrektur erfolgt nur noch mit dem DMG online client.
2.Datenbank und Application Server befinden sich auf einem einzigen Rechner (DROM16) und sind nicht mehr auf verschiedene Rechner verteilt.
3.Die Umstellung der Datenbank von MS-SQLServer auf PostgreSQL.
Die komplette Migration der einzelnen Softwarekomponenten (JBoss, Cruisecontrol, CVS / SVN, MS-SQL / PostgreSQL usw.) vom Windows 2000 Server auf das
GNU/Linux-System hat in toto gut zwei Monate gedauert. Nach einer Analyse
phase von ca. 2–3 Wochen, die der Planung der Umstellung, der Überprüfung
VDM = Visual Dialectometry <http://www.dialectometry.com/dmdocs/index.html>, eine zur
46
Durchführung dialektometrischer Analysen von E. Haimerl geschaffene Spezial-Software.
311
312
der Kompatibilität und der Evaluierung des Aufwands der Migration gewidmet
waren, wurden die Komponenten zuerst in die dafür vorhandene Testumgebung
migriert. Parallel dazu konnten alle Arbeiten auf dem bisherigen Produktivsystem
weiter durchgeführt werden, so dass durch die Umstellung kein Zeitverlust entstanden ist. Die klare Trennung von Test- und Produktivumgebung, die im Projekt seit Jahren vorhanden ist, hat so auch bei der Umstellung geholfen und dafür
gesorgt, dass während der Migrationsphase alle Arbeiten im Projekt ungehindert
weitergeführt werden konnten.
Inzwischen hat sich die Umstellung sehr bewährt: während DMG beispielsweise vor der Migration mindestens 15 Sekunden brauchte, bis alle Transkriptionsdaten eines Ortes geladen wurden, benötigt das neue System zum Laden derselben Daten nunmehr weniger als drei Sekunden. Es ist dies ein für die gesamte
Redaktionsphase überaus wertvoller
Gewinn an Zeit und Funktionalität,
da die Transkriptionsdaten von einzelnen Orten sehr oft geladen werden
müssen.
Ein vergleichbarer Performancegewinn ist auch bei der Auswahl der
“Fragenummer” zu verzeichnen. Da
bei handelt es sich um eine neue
Funktion im DMG-Client, die während der Redaktionsphase aufgerufen
wird, wenn die Antworten aller Orte
zu einer bestimmten Frage geladen
werden müssen. Außerdem ist es nach
dem Upgrade der Java-Version von
1.4 auf 1.5 (oder 5.0) möglich, die
neuen Features von Java zu nutzen,47
die ebenfalls die Geschwindigkeit
der eingesetzten Software merklich
steigern können.
Abb. 22: Zusammenspiel der einzelnen Komponenten im Server DROM 16 nach der Umstellung auf den neuen ½-Rechner
Eine Liste der seit Java 1.5 erreichten Verbesserungen findet man im Netz unter:
47
<http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html>.
4. Bericht zum Stand der Arbeiten zur Sound-Datenbank (SDB)
(Edgar Haimerl)
Bekanntlich ist es das Ziel der SDB, die im Zuge der 217 Feldenquêten gemachten
Tonmitschnitte in einem komfortabel bedien- bzw. abhörbaren Tool zusammenzuführen. Dies setzt nicht nur eine entsprechende Auf- und Vorbereitung aller im
Feld durchgeführten Tonmitschnitte, sondern vor allem das Vorhandensein einer
entsprechend ausgeklügelten Software voraus. So wurden im 4. ¿-Arbeitsbericht, der die im Jahr 2006 geleisteten Arbeiten betraf, das Konzept, die Anforderungen und die EDV-Architektur der SDB vorgestellt (cf. Goebl/Haimerl/
Wagner 2007, 178–185).
4.1 Implementierung des Player Applets und SDB-Servers
Im Berichtsjahr 2007 konnten die einschlägigen Entwicklungsarbeiten zügig
fortgeführt und mit der Implementierung des Clients (Player-Applet)48 und des
Servers in den wesentlichen Punkten abgeschlossen werden.
Zur Erklärung der dabei implementierten Funktionen muss etwas ausgeholt werden. Wenn man zu einem bestimmten Ort und einer bestimmten Frage die in der
SDB vorhandenen Antwortreflexe abhören will, muss man der SDB den abzuhörenden Abschnitt anhand der Fragenummer näherungsweise “mitteilen”. Das
damit in Gang zu setzende Abspielen der Tondateien kann in Java recht einfach
gelöst werden: Die Java Programmierumgebung (Java API) stellt einen MPEG
audio byte-stream49 bereit, aus dem schrittweise Frames gelesen werden können.
Jeder Frame entspricht dabei einem ca. eine Sekunde langen Ausschnitt aus der
betreffenden Sound-Datei.
Bislang hat sich bei den Beta-Tests die Performance des Servers als gut erwiesen,
sodass das betreffende Applet für den schnellen Zugriff auf die speziell vorzuwählenden Interviewabschnitte routinemäßig eingesetzt werden kann:
• Aus der SDB werden immer nur die jeweils abgefragten Abschnitte anstatt
der kompletten, mehrere Megabyte umfassenden Tondatei der betreffenden
Ein Applet ist eine Komponente, die, in eine Webseite integriert, von dort aus bedient werden kann. Ein
Applet kann jedoch auch leicht als eigenständige Applikation gestartet werden. Daher sind Applets in
beiden “Welten” verwendbar: sowohl im Internet als auch in lokalen Umgebungen.
48
Tondateien werden im Computer als Bytes, also als Abfolge von 0 und 1 gespeichert. Aus einer Abfolge
von mehreren Millionen 0/1en wird ein Ausschnitt als Tonausschnitt interpretiert und abgespielt.
49
313
314
Ortschaft übertragen. Das reduziert das zu transportierende Datenvolumen
erheblich.
• Hibernate50 und Cache vereinfachen und beschleunigen den Zugriff auf die
SDB.
• Der WebService AXIS schickt die betreffenden Ausschnitte aus den wavDateien direkt und ohne lange Konvertierung als Anhang einer Message an
den Client.
Insofern kann also das programmierte Applet als erfolgreicher “proof of concept”
gelten. Für den vollwertigen Routine-Einsatz bei der Redaktion des ¿ sind
allerdings noch eine Reihe von Erweiterungen und Verbesserungen nötig.
4.2 Erweiterungen des Player Applets
Abbildung 23 zeigt den Dialog des Player Applets SDB SegmentPlayer: Zu einer gegebenen Orts- (OrtNr) und Fragenummer (FrageNr) kann ein Ausschnitt
aus einer Sound-Datei gesucht (Button “Suche”) und darnach abgespielt werden
(Button “>”).
Abb. 23: Dialog des Segmentplayers
Wenn man die Länge des zu übertragenden Segments verringert (siehe Eingabefeld und Button “Länge speichern”), wird damit auch dessen Übertragungszeit
Hibernate ist eine open source-Bibliothek für den Zugriff auf relationale Datenbanken (ORM – object relational mapping); siehe dazu im Netz: <http://www.jboss.com/pdf/HibernateBrochure-Jun2005.pdf>.
50
reduziert. Jedoch kann es durch die interpolierende Positionsberechnung dazu
kommen, dass der gesuchte Tonausschnitt nicht im übertragenen Soundsegment
liegt.51
4.2.1 Schnelles Positionieren im Tonausschnitt
Eine Funktion, die sich dem Benutzer als “normal” bzw. “natürlich” darstellt, ist
im Applet nicht so einfach: So ist es keineswegs trivial, beim Abspielen einerseits
den aktuellen Stand durch einen sich bewegenden Schieberegler anzuzeigen und
andererseits dem Benutzer zu erlauben, durch Manipulationen an der Position
dieses Schiebereglers auf eine andere Stelle des betreffenden Soundabschnitts zu
springen.
Für die Programmierung bedeutet das, dass die Schieberegler-Anzeige und das
Abspielen des gewählten Soundabschnitts gleichzeitig ausgeführt werden und
somit in parallelen Threads52 ablaufen müssen. Damit man das Abspielen stoppen oder durch das Verschieben des Schiebereglers an eine andere Position des
Soundabschnitts gelangen kann, müssen die diversen Threads aufeinander abgestimmt werden und miteinander kommunizieren. Erschwerend kommt hinzu,
dass das Abspielen eines Audio-Bitstreams nicht zuverlässig angehalten, sondern
nur abgebrochen werden kann.
Die Lösung besteht darin, über Listener dem Applet die zuletzt aus der Tondatei
abgespielte Position mitzuteilen. Das Applet speichert diese Position. Für die
Stop- und Pause-Funktion kann dann das Applet das Abspielen im anderen Thread
abbrechen und anschließend an der jeweils letzten Abspiel-Position oder an der
zuletzt eingestellten Position des Schiebereglers erneut starten. Das Applet selbst
nimmt eine Zwischenspeicherung der binären Daten eines Soundabschnitts vor,
so dass innerhalb dieses Abschnitts ein wiederholtes Abspielen ohne erneuten
Zugriff auf den Server erfolgen kann.
Zu einer ausführlichen Beschreibung cf. Goebl/Haimerl/Wagner 2007, 181.
51
Ein thread “horcht” und wartet auf Meldungen anderer threads; hier meldet jener thread, der die
Audio-Datei abspielt, dem applet thread die Position in Form einer Prozentangabe.
52
315
316
4.2.2 Speichern genau definierter (“exakter”) Positionen
Im Player Applet können durch Eingabe der “aktuellen FrageNr” und durch Speichern mit dem Button “Positionsangabe speichern” genau definierte Positionen
abgespeichert werden (siehe Abbildung 23). Intern wird beim Speichern exakter
Positionen der genaue Offset in der Tondatei berechnet und zusammen mit der ID
der Datei und der Fragenummer in einer speziellen Tabelle abgelegt. Das in Goebl/
Haimerl/Wagner 2007, 184 präsentierte Datenbank-Diagramm veranschaulicht
und erklärt die Tabellen und die zwischen diesen bestehenden Relationen.
Das Speichern von Fragepositionen ist inzwischen sowohl server- als auch client
seitig implementiert. Wiewohl erste Experimente mit diesem neuen Feature gezeigt haben, dass die Positionierung in recht akkurater Weise erfolgt, sind noch
weitere Tests mit anderen und umfänglicheren Daten nötig, bevor eine abschließende Beurteilung dieses Verfahrens möglich ist.
4.3 Geplante Erweiterungen
4.3.1 Liste verfügbarer Orte
Der Löwenanteil der derzeit bei der Erstellung der SDB zu leistenden Arbeit besteht im Konvertieren und Aufbereiten der Sound-Dateien (siehe dazu Abschnitt
4.4. “Stand der Konvertierung”). Um jedoch die SDB schon vor dem Abschluss
dieser sehr zeitaufwändigen Arbeiten benützen zu können, soll eine Liste, die
die Anzahl der jeweils in der SDB implementierten Tonmitschnitte anzeigt, in
der Form einer HTML-Seite erstellt werden. Diese HTML-Seite listet diejenigen Orte bzw. ½-Messpunkte auf, für die das Applet durch einen Link direkt
gestartet werden kann. So kann man sich bei der Abhörarbeit auf die bereits in
der SDB implementierten Messpunkte konzentrieren. Man braucht daher seine
Abhörarbeit nicht “blind” zu starten und muss dabei auch nicht gehäufte Fehlermeldungen bezüglich noch nicht konvertierter Orte zur Kenntnis zu nehmen.
4.3.2 Meldungen des Applets
Auf Abbildung 23 ist im unteren Bereich des Applets ein Bereich zu erkennen,
der für die Ausgabe von Fehlermeldungen verwendet werden soll. Diese Meldungen erleichtern die Arbeit merklich, denn sie können dem Benutzer Hinweise
über die Fehlerursache geben und damit Lösungswege aufzeigen.
An diesem Fehlermeldungssystem des Player Applets sind noch verschiedene
Verbesserungen nötig. Prinzipiell soll bei den Meldungen nach Benutzer- und
Systemfehlern unterschieden werden.
Benutzerfehler ergeben sich durch nicht ausführbare Eingaben des Benutzers.
So würde ein Benutzerfehler dann vorliegen, wenn z.B. ein Ort bzw. Messpunkt
angewählt wird, zu dem noch keine Daten verfügbar sind, oder wenn eine Fragenummer eingegeben wird, die außerhalb des jeweils erfassbaren Bereichs liegt. In
einem solchen Fall muss dem User angezeigt werden, warum seine Abfrage nicht
ausgeführt werden konnte. Im System erzeugt eine nicht ausführbare Abfrage
jedoch interne Probleme, z.B. eine HibernateException beim Zugriff auf einen
Datenbankwert. Diese internen Probleme müssen vom System entsprechend analysiert und darnach in einen für den Benutzer verständlichen Wortlaut als Fehlermeldung umgesetzt werden.
Dagegen liegen Systemfehler außerhalb der Zuständigkeit eines einzelnen
Benutzers. Beispiele für Systemfehler wären: ein nicht erreichbarer Server, eine
falsche Konfiguration des Clients oder auch ein Bug im Programm. In einem
solchen Fall soll der Benutzer von all diesen internen Problemen nur die schlichte
Tatsache erfahren, dass er die festgestellten Schwierigkeiten nicht selber beheben
kann und somit auf externe technische Hilfe angewiesen ist. Damit jedoch
das aufgetretene Problem von einem Fachmann schnell und exakt lokalisiert
werden kann, müssen sowohl der Client als auch der Server die betreffenden
Fehlermeldungen in log-Dateien schreiben.
Diese Anforderungen an das Handling von System- und Benutzerfehlern lassen
sich am besten durch einen zentralen Error-Handling-Manager umsetzen: dabei
werden die Fehler an jener Stelle, an der sie auftreten, kategorisiert und mit
einer ErrorID versehen. Der Error-Handling-Manager kann die ErrorID in eine
allgemein verständliche Meldung umsetzen und weiß, wie bei dieser Art von
Fehlern zu verfahren ist.
Neben den Meldungen über aufgetretene Fehler sollen dem Benutzer auch Rück
meldungen über von ihm erfolgreich durchgeführte Aktionen geliefert werden,
etwa, dass das Abspeichern einer Position erfolgreich exekutiert worden ist.
4.3.3 Rück- und Vorsprung beim Abspielen von Tonsegmenten
Es ist geplant, dass man beim Abhören der Aufnahmegespräche rasch von einer Position in einem Interview an eine andere springen kann, und zwar sowohl
317
318
nach vorne (“eine Minute weiter”) als auch nach hinten (“fünf Minuten zurück”).
Die Implementierung dieses Features steht noch aus. Es war wichtig, zuerst die
Kommunikation zwischen Soundplayer und Applet-Thread stabil und zuverlässig
zu gestalten, um dann auf dieser Basis die Funktionen des erwähnten Vor- und
Rück-Sprungs zu implementieren. Diese Implementierung wird dann problematisch, wenn der neu angeforderte Tonausschnitt nicht mehr in jener Datei zu finden ist, aus der der aktuelle Tonabschnitt segmentiert wurde. Die annähernde
Positionsbestimmung über Dateigrenzen hinweg, die auf relativen Zeitangaben
(z.B. “gehe fünf Minuten weiter”) ohne Angabe einer bestimmten Fragenummer
beruht, ist noch zu lösen.
4.3.4 Online-Verfügbarkeit der SDB im Netz
Derzeit ist die Sound-Datenbank online nur innerhalb des Projektes verfügbar.
Das hat zwei Gründe:
• Es handelt sich um eine Beta-Version, die zuerst projektintern im täglichen
Gebrauch geprüft und verbessert werden soll, bevor sie der projektexternen
Öffentlichkeit zugänglich gemacht wird.
• Gegen unsere Web-Server werden permanent Hacker-Attacken gefahren, da
das EDV-Netz der Universität Salzburg bedauerlicherweise noch nicht durch
eine entsprechende Firewall gesichert ist. Solange wir auf dem Web-Server
nur statische Seiten haben (wie z.B. die Seite <http://ald.sbg.ac.at/ALD-II/>),
ist das nicht allzu problematisch. Damit wir aber dynamische Seiten und Projektdaten über das Internet anbieten können, müssen wir über eine Infrastruktur verfügen, die wesentliche Sicherheitsvorkehrungen bietet (z.B. DMZ – interne Zone mit Tondateien und Datenbank hinter einer Firewall).
Wenn jedoch die Beta-Testungen beendet sein werden und die erwähnte Sicherheitsstruktur zur Verfügung stehen wird, kann das PlayerApplet im Internet für
den direkten Zugriff auf die originalen Tondaten verwendet werden. Spezielle
Änderungen am Applet oder am Server sind dafür nicht nötig.
4.4 Stand der Konvertierung und Datenerfassung zu den Tondateien
Der Hauptteil der Arbeit an der SDB entfiel bisher auf das Konvertieren der Tondateien aus dem proprietären Mini-Disk-Format der Firma Sony in wav- und darnach in mp3-Sound-Dateien. Bis die Konvertierung in der derzeitig praktizierten
Form funktioniert hat, waren allerdings einige Hürden zu nehmen:
1.Es bestehen erhebliche technische Unterschiede zwischen den “alten”
Mini-Disks (bis 2005) und den “neuen” Mini-Disks HD53 (ab 2005) der
Firma Sony.
2.Beim Export mit SonicStage werden die Dateien der Mini-Disks automatisch
nummeriert. Diese (Neu-)Nummerierung der Dateien entspricht aber nicht
unbedingt der originalen zeitlichen Abfolge der Feldaufnahmen. Deshalb
müssen alle Dateien nach der Konvertierung bzw. (Neu-)Nummerierung kurz
angehört und manuell mit einem neuen “Namen” versehen werden, der aus
der Doppelangabe “AnfangFragenummer_EndFragenummer” besteht.
3.Obwohl in aller Regel von den ExploratorInnen für die 181 Seiten des
¿-Fragebuchs bei oder nach den Feldenquêten je eine elektronische
Marke gesetzt wurde, sind diese Informationen aus dem alten Mini-DiskFormat nicht exportierbar und daher für die genaue Positionierung im
Player Applet nicht verwendbar.
Trotz dieser Schwierigkeiten mit dem Mini-Disk-Format54 der Firma Sony und
trotz der dadurch verursachten nicht geringen Kosten (Verlust von Zeit und Einsatz von extra zu entlohnender Manpower) ist die Konvertierung der Tonmitschnitte weit fortgeschritten. Das ist der umsichtigen Organisation der anfallenden
Arbeiten durch Xavier Casassas Canals (hinsichtlich der EDV-Arbeiten) und vor
allem durch Gertraud Klingler (hinsichtlich der Organisation und Überwachung
der Abhör- und Neu-Nummerierungsarbeiten) zu verdanken.
Die Konvertierung aller 217 Tonmitschnitte präsentiert sich nach dem Stand von
Juni 2008 wie folgt:
• 93 (oder 42%) der 217 Tonmitschnitte sind fertig und damit innerhalb des
Projekts online verfüg- und abhörbar.
• 132 (oder 60%) der 217 Tonmitschnitte befinden sich in der abschließenden
Bearbeitungsphase: d.h. dass die oben erwähnte Neu-Nummerierung nach
“Anfang-Fragenummer” und “End-Fragenummer” (innerhalb der Universität Salzburg) online durchgeführt werden kann.
• 192 (oder 88,5%) der 217 Tonmitschnitte wurden bereits von Mini-Disk auf
PC konvertiert und liegen somit als wav- bzw. mp3-Dateien vor.
Die auf diesem Gebiet noch zu leistende Arbeit ist also beträchtlich. Abbildung
24 fasst den aktuellen Stand übersichtlich in einem Diagramm zusammen.
HD steht für High Density.
53
Cf. Goebl/Haimerl 2006, 208ff.
54
319
online
Bearbeitungsstatus
320
vorbereitet
auf PC
0
25
50
erledigt in %
75
100
Abb. 24: Stand der Konvertierung der 217 Tondateien
5. Vorstellung und Interpretation der vier beiliegenden Karten (Hans Goebl)
Aufgabe der vier beiliegenden Karten ist es, den Lesern eine konkrete Vorstellung vom gestaffelten Ablauf der Kartenredaktion zu vermitteln. Zwei der vier
beiliegenden Karten sind in kartographischer Hinsicht “Prüfpfad-Karten” und
zeigen genau jene Gestalt, in der sie am ½-Archiv aufliegen: sie enthalten also
(reale) händische Korrekturvermerke, die vom Projektleiter bei der Durchsicht
bzw. Korrektur dieser Ausdrucke angebracht worden sind.
Ganz besonders die vierte Karte ähnelt jedoch bereits weitestgehend jener Karte,
die in ein paar Jahren im gedruckten Opus zu sehen sein wird. Daher verfügt
sie über den schon beim ¾ verwendeten hellblauen Kartengrund und ist –
so wie auch die (Prüfpfad-)Karte 3 – frei von allen händischen Eingriffen und
Vermerken.
Die Karten 1 und 2 wurden auf der Grundlage der folgenden zwei Teilfragen des
ALD-II-Fragebuchs erstellt: 109/1: Sono stato … 109/2: …a Venezia [, ieri]
Die Formulierung der Frage zielte auf die Erbringung morphologisch (Realisierung
der 1. Person Singular des Passato prossimo etc.), morphosyntaktisch (Verwendung
von Passato prossimo versus Imperfetto) und lexikalisch (Verwendung der Verben
essere und andare) und phonetisch (lautliche Realisierung des Ortsnamens Venezia) relevanter Antworten. Die im Fragebuch enthaltene Ergänzung [, ieri] sollte die
Homogenität der zeitlichen Einbettung der Antwort (d.h. den Bezug auf eine nur
kurz und nicht lang zurückliegende Reise nach Venedig) sicherstellen.
Die Karten 1 und 2 stellen direkte Ablichtungen von am ½-Archiv von mir
bearbeiteten Probekarten dar, während die Karten 3 und 4 auf dem Inhalt der
darnach richtig gestellten Datenbank beruhen und keine händischen Korrekturen
enthalten. Inhaltlich sind die Karten 3 und 4 völlig identisch.
5.1 Vorstellung und Interpretation der Karte 1
Die weit überwiegende Mehrzahl der Antworten besteht aus nur einem Antwort
reflex und daher aus nur einer einzigen “Version”. Doppelantworten – deren Gesamtheit als die “zweite Version” dieser Karte bezeichnet wird – findet man entlang des Prüfpfads 3 (PP. 58, 69, 75, 78 etc.). Dabei entsprechen die Antworten
der ersten Version den dialektalen Pendants zu sono stato und jene der zweiten
Version den dialektalen Pendants zu sono andato (bzw. sono gito). Einige der Exploratoren haben das durch entsprechende Hinweise (“Kommentare”) kenntlich
gemacht: so z. B. an P. 58, wo die dialektalen Reflexe zu sono stato mit (lettl.)
(= [traduzione] letterale, “wörtliche Übersetzung”) und zu sono andato mit (lib.)
(= [traduzione] libera, “freie Übersetzung”) gekennzeichnet wurden.
Interessant sind ferner explizite Hinweise der Gewährspersonen auf die “Archaizität” bestimmter Formen der ersten oder zweiten Version (arc.), die – wie schon
beim ¾ üblich – von den Exploratoren mit besonderer Akribie aufgezeichnet
worden sind: siehe dazu Prüfpfade 4 (P. 92) und 6 (P. 165). Weitere Kommentare
betreffen den Gegensatz zwischen rascher (all. = allegro) und langsamer (lt. =
lento) Elokution, woraus sich natürlich phonetische Unterschiede ergeben: siehe
dazu den Prüfpfad 6 (PP. 169 und 170).
Interessant sind ferner die Setzung des Personalpronomens in den rätoromanischen Gebieten (siehe dazu einige Antworten entlang der Prüfpfade 1, 4 und 7)
und die sporadische Verwendung des Imperfekts anstelle des Passato prossimo
(Prüfpfad 1: PP. 6 und 12).
Die meist beschränkte Länge der Antwortreflexe und der relativ geringe Umfang
der zweiten (etc.) Antworten (der “zweiten (etc.) Version”) eröffnen die Möglichkeit, diese Karte mit jener zur Teilfrage 109/2 (… a Venezia [, ieri]) zu einer
Kombinationskarte zu verschmelzen.
Zunächst ist anzumerken, dass die syntaktisch einfache Struktur der zu den Teilfragen 109/1 und 109/2 gesammelten Antworten deren Zuordnung zu den beiden
Teilfragen in sehr eindeutiger Weise möglich gemacht hat. Zudem sind die meis-
321
322
ten der auf dieser Karte aufscheinenden Antwortreflexe kurz, was erneut für eine
Zusammenlegung des Inhalts dieser Karte mit jenem der Karte 1 plädiert.
Die weit überwiegende Mehrzahl der Antworten entspricht dem Richtungs-Typ
ad venetiam (= a Venezia); daneben gibt es aber auch eine Antwort, die – ganz
eindeutig unter Rücksichtnahme auf die geographische Lage Venedigs am Meer
bzw. “ganz unten” – auf den Typ iusum per venetiam (= giù per Venezia) zurückgeht: siehe dazu Prüfpfad 6, P. 156.
Von besonderem Interesse sind ferner die verschiedenen dialektalen Gestalten
des Ortsnamens Venedig, wobei jene besonders auffallen, die sehr alten “Exonymen” für diese seit alters her europaweit bekannte Stadt entsprechen. Diesbezüglich sind die entlang des Prüfpfads 4 auffindbaren gadertalischen (Typ |aunéžia })
und grödnerischen (Typ |uniéža }) Formen besonders interessant, die von den
Gewährsleuten allerdings meist parallel zu einer in phonetischer Hinsicht stark
italienisierenden Form genannt wurden.
Bemerkenswert ist ferner ein explizit als archaisch bezeichneter Beleg an P.
4 (Prüfpfad 1, Unterengadin: [vnéža]). Ebenso verweisen die an sechs friaulischen Messpunkten (Prüfpfad 7: PP. 195-200) auftretenden Formen [vinéže] oder
[vinéžia] durch das vortonige [i] auf ihr höheres Alter.
Noch eine Anmerkung zum Vorgang der Kartenredaktion. Am Messpunkt 84 erkennt man neben den beiden dort ausgedruckten Versionen das Symbol für ein
offenes Buch. Dieses Symbol wird beim fertigen ¿ auf einen der Supplement-Bände verweisen, worin die auf den Kartenblättern nicht unterzubringenden Transkipte aufscheinen werden.
Beim Zusammenführen der Teilkarten (hier: 1 und 2) zu einer Kombinationskarte (3
und 4) hat es sich gezeigt, dass die Kartenredaktions-Module des Programms DMG
imstande sind, alle zu diesen beiden Teilfragen in der ¿-Datenbank vorhandenen Informationen55 auf einem Kartenblatt unterzubringen. Dieser in den Details
überaus komplexe Vorgang wird von DMG vollkommen automatisch durchgeführt.
Hätte der Umfang der beiden auf einer Karte unterzubringenden Teilfragen (mit all
ihren Versionen) das Fassungsvermögen der Karte und der “Leggenda” überstiegen,
so wären an den von einem Overflow betroffenen Stellen der Karte die vorhin erwähnten Buch-Symbole aufgetaucht und die jeweils überkragenden Informationen
für eine Auflistung in einem der Supplement-Bände bereitgehalten worden.
Diese Informationen umfassen zum Teil drei Versionen: siehe z.B. den P. 163 (Prüfpfad 6), wozu eine
Version auf der Karte und zwei weitere Versionen in der Legende (“Leggenda”) zu finden sind.
55
Die dritte Karte entspricht inhaltlich vollkommen der Karte 4; doch gestattet es
die Pfadstruktur der Karte, deren Inhalt in aufsteigender Reihenfolge der Messpunktnummern lückenlos abzuprüfen.
Die im Kartentitel (rechts oben) aufscheinende Nummer (186) ist fiktiv und wird
im fertigen Opus in anderer Form auftreten. Doch werden im Kartentitel auch
Hinweise auf ältere Sprachatlanten (wie AIS, ¾ oder ALI etc.) zu lesen sein,
die vergleichbare Informationen enthalten. Ebenso fehlt auf dieser Karte ein fallweise links neben dem Titel-Insert einzusetzender Kommentar (“Comm[ento].”).
Wir haben beim ¾ damit sehr gute Erfahrungen gemacht und wollen dieses
Redaktions-Instrument auch beim ¿ entsprechend ausnützen.
Gegenüber der Karte 2 enthalten die Karten 3 und 4 ein geringfügiges Mehr an
Information: siehe dazu den P. 84 (Prüfpfad 4). Bei einem Blick in die Legende
(“Leggenda”) sieht man, dass dort eine auf Karte 2 nicht sichtbare Information
aufscheint, nämlich ein Transkript mit der sehr alten ladinischen Form [inéžia]. Die
Echtheit dieses Belegs – neben der offenbar mit dem Suffix ad erweiteren Form
[ainéžia] – wurde vom Explorator Paul Videsott im Fragebuch explizit bestätigt.
Die Karte 4 entspricht – abgesehen von der Kartennummer und den später noch
einzutragenden Verweisen auf andere Sprachatlanten – vollkommen dem, was
der Leser im fertigen Opus (¿) für diese zwei Teilfragen wird sehen können.
Zudem wurden bei der drucktechnischen Produktion dieser Karte all jene Etappen durchlaufen, die dereinst bei der Produktion aller Karten des ¿ benützt
werden müssen:
a) Herstellung eines druckfertigen Files (als PDF) in Salzburg,
b) Herstellung eines sehr genauen Scans des hellblauen Grundnetzes des ½,56
c) Übermittlung der beiden Files an Paolo Anvidalfarei nach San Martin de Tor,
d) Superposition der beiden Files durch P. Anvidalfarei,
e) Weiterreichung dieser Daten an die Druckerei,
f) Druck der betreffenden Karte.
Es sei daran erinnert, dass das hellblaue Grundnetz beim im Jahr 1998 erfolgten Druck des ¾
exklusiv in analoger Gestalt (und damit als offsetfähiges Positiv) vorlag. Zwischenzeitlich ist dieses
offsetfähige Positiv von einer Salzburger Druckerei abgescannt worden und steht demnach in EDVverwertbarer Form zur Verfügung.
56
323
324
6. Bibliographie
AIS: Jaberg, Karl/Jud, Jakob (eds.): Sprach- und Sachatlas Italiens und der Südschweiz, Zofingen
1928–1940, 8 voll.
¾ = Goebl, Hans/Bauer, Roland/Haimerl, Edgar (eds.): Sprachatlas des Dolomitenladinischen
und angrenzender Dialekte. Teil I, Wiesbaden 1998, 7 voll.
ASLEF: Pellegrini, Giovan Battista (ed.): Atlante storico-linguistico-etnografico del friulano, Padova 1972–1986, 6 voll.
Ettmayer, Karl von: Lombardisch-Ladinisches aus Südtirol. Ein Beitrag zum oberitalienischen
Vokalismus, in: “Romanische Forschungen”, 13, 1902, 321–673; neu hgg. von Hans Goebl,
San Martin de Tor 1995.
Goebl, Hans et al.: ¿: 1. Arbeitsbericht/1a relazione di lavoro (1999–2003), in: “Ladinia”,
XXVIII, 2004, 115–199.
Goebl, Hans/Haimerl, Edgar: ¿: 2. Arbeitsbericht (2004), in: “Ladinia”, XXIX, 2005, 107–124.
Goebl, Hans/Haimerl, Edgar: ¿: 3. Arbeitsbericht (2005), in: “Ladinia”, XXX, 2006, 203–221.
Goebl, Hans/Haimerl, Edgar/Wagner, Andreas: ¿: 4. Arbeitsbericht (2006), in: “Ladinia”,
XXXI, 2007, 157–186.
Haimerl, Edgar: Taxierungsalgorithmen, in: Köhler, Reinhard/Altmann, Gabriel/Piotrowski, Rajmund G. (eds.), Quantitative Linguistik. Ein internationales Handbuch / Quantitative Linguistics. An International Handbook, Berlin / New York 2005, 532–547.
Wagner, Andreas: The Map Generator Framework. Map generation and interaction using Geo
tools open source GIS library and the Java2D API. Applied in the Dialect Map Generator
(DMG) application, Salzburg 2007, [Magisterarbeit zur Erlangung des akademischen Grades
Diplom-Ingenieur an der Naturwissenschaftlichen Fakultät der Universität Salzburg; cf. auch:
<http://ald.sbg.ac.at/ALD-II/docs/andreas_wagner_magisterarbeit.pdf>].
Ressumé
Te chesta cuinta relazion de laur sun l ¿ végnel informé dantaldut sun problems tecnich-informatics. Chilò descriv l colaboradù dl ¿ Fabio Tosques dret
avisa i mioramenc arjonc sot sia colaborazion intensiva entant i agn 2006–2007 al
program svilupé da Edgar Haimerl “Dialect Map Generator” (DMG), depierpul
che Edgar Haimerl enstes referesc sun i laurs realisés en cont dla banca de dac
acustics (SDB). Con l aiut dla ultima verscion dla DMG vala oramei da realisé
debota, te na forma saurida da manajé y te na maniera dldut automatica chertes
dl atlant enjignedes per la stampa. Sciche desmostrazion di varesc fac ti él gnù
enjonté al contribut cater chertes de proa tla grandeza y tla dotazion originala;
Hans Goebl à scrit comentars menus per chestes. La SDB enjigneda ca da Edgar
Haimerl y Xavier Casassas ti darà tost la poscibelté ai redaturs de consulté saurì
les registrazions acustiches fates ti 217 posć dl ¿.

Goebl2008_ALD-II_5_Arbeitsbericht (2007)

Transcrição

Documentos relacionados

Goebl2006_ALD-II_3_Arbeitsbericht (2005)

Goebl2007_ALD-II_4_Arbeitsbericht (2006)

eds 600 siemens cf 62

Angebot pdf-Download

Beraterprofil Uwe Schudak - Bleisteiner und Schudak

FACHAUSSCHUSS GESCHICHTE DER

Paschater Zwoaschritt

Goebl2011_FS Holtus

SOMEONE BESIDE YOU

Emily Bronte, Wuthering Heights (Sturmhöhe) Der Roman spielt im

Organigramm der Firma

stanleyburburin

4. Register 4.1 Register der Personennamen

Campyloneurus Campyloneurus batavianus, Sammluug