Archiv des Autors: Stephan Lücke

VerbaAlpina erklärt sich selbst – Teil 2: Informationstechnik (Zitieren)

Stephan Lücke
(1983 Wörter)

Grundsätzliches

  • VerbaAlpina (VA) beschäftigt sich mit der Frage, welche Bezeichnungen es für ausgewählte, für den Alpenraum typische Konzept/Begriffe es gab und gibt
  • VA ist mit diesem Ziel ein von der DFG gefördertes Langfristvorhaben mit Perspektive bis 2025 (derzeit dritte Teilphase [2019-2022] in Beantragung)
  • Die Untersuchung ist auf den Alpenraum beschränkt
  • Die Grenze des Untersuchungsgebiets ist das Perimeter der sog. Alpenkonvention (Link)
  • Das Sprachmaterial stammt hauptsächlich aus sog. Sprachatlanten und Wörterbüchern (letztere nur, wenn sie Auskunft über die regionale Verbreitung der verzeichneten Wörter geben; Beispiel: Idiotikon)
  • Neben Sprachatlanten und Wörterbüchern verwendet VA Methoden des Crowdsourcing („citizen science“) zur Sammlung von Sprachmaterial (dazu später mehr)
  • VA fragt nach der Verbreitung von Wörtern innerhalb des Alpenraums (welche Wörter werden wo verwendet und welche Bedeutung haben sie dort?)
  • Im Hinblick auf die Wörter ist VA im Wesentlichen an sog. Morpholexikalischen Typen (Morphtypen) interessiert. Diese sind letztlich vergleichbar mit den Lemmata von Wörterbucheinträgen
  • Ein Morphtyp im Sinn von VA wird definiert durch
    • die Orthographie,
    • die Zugehörigkeit zu einer Sprachfamilie (germanisch, romanisch, slawisch),
    • die Wortart,
    • das Genus und
    • die Affigierung (letztere z. B. –chen in Häuschen ⇒ eigener Morphtyp neben Haus)
    • Beispiel: la malga (romanisch, feminin, ohne Affigierung); zwei Morphtypen: die Butter und der Butter
  • VA befasst sich in der Hauptsache mit Dialektausdrücken (also nicht mit den Hochsprachen)
  • VA ist nur nachrangig an phonetischer Variation interessiert
  • Das geographische Bezugssystem innerhalb der Alpenkonvention wird durch die politischen Gemeinden gebildet (5771; statisches Referenzystem; Änderungen werden nicht berücksichtigt)
  • VA besitzt neben der diatopischen auch eine diachronische Dimension (Veränderungen über die Zeit; Sprachatlanten z. T. aus der 1. Hälfte des 20. Jh. ⇔ Daten aus dem Crowdsourcing von heute)
  • Die Kernentitäten von VA sind demnach:
    • Morphtyp
    • Konzepte (zur Unterscheidung von Wörtern stets in Versalien geschrieben; BUTTER meine das Konzept, also die Sache als solche; Butter hingegen meint das Wort „Butter“)
    • Gemeinden
    • [Zeit]

⇒ Das Wort xy wurde/wird in den Jahren jjjj in der/den Gemeinde(n) yz zur Bezeichnung des Konzepts KO verwendet

  • Die Wechselbeziehung von Morphtypen und deren Bedeutung erzeugt vor dem Hintergrund von Raum und Zeit eine enorme Komplexität:

Zu den Kernentitäten gehört auch der sog. Basistyp. Damit sind Wörter gemeint, die in irgendeiner Weise ganz offenkundig mit einem Morphtypen verbunden sind, ohne dass der Zusammenhang im Detail geklärt werden kann. In aller Regel handelt es sich dabei um ältere Vorstufen. Hierzu ein Beispiel:

Das deutsche Wort Salamander hängt unverkennbar mit dem italienischen salamandra zusammen. Das Wort salamandra gab es schon im Lateinischen (Georges). Für das deutsche Salamander stellt sich nun die Frage, ob es sich direkt aus dem Lateinischen entwickelt hat (Etymologie-Szenario) oder ob es später aus dem Italienischen übernommen worden ist (Entlehnungs-Szenario). Fragen dieser Art sind häufig nur mit sehr großem Aufwand – wenn überhaupt – zu entscheiden. Dennoch besteht unverkennbar eine Verbindung. Um diese dokumentieren zu können, hat VA den Basistyp eingeführt. (anders als im Fall von lat. salamandra können manche Basistypen keiner spezifischen Sprache zugeordnet werden. Gleichwohl muss es sie gegeben haben. In solchen Fällen wird ein Basistyp rekonstruiert [Kennzeichnung durch * vor dem Basistypen]; Beispiel: *cala als Basistyp z. B. von frz. chalet)

  • In Sprachatlanten und Wörterbüchern werden vielfach keine Morphtypen, sondern Einzelbelege oder phonetische Typen dokumentiert (z. B. Kaas, Chaas, Käs – alles Varianten des Morphtyps der Käse) ⇒ Quelldaten müssen klassifiziert werden (sog. „Typisierung“)
  • Im Zuge der Typisierung verknüpft VA nach Möglichkeit einen Morphtyp mit einem korrespondierenden Eintrag in einem sog. Referenzwörterbuch. Liste der Referenzwörterbücher (Beispiel: der Morphtyp „malga|rom|f|nicht affigiert“ entspricht dem Eintrag malga im Vocabolario der Treccani; http://www.treccani.it/vocabolario/malga/)
  • VA sammelt bis zu einem gewissen Grad auch Daten zur sog. außersprachlichen Peripherie. Als Beispiel können die Fundorte lateinischer Inschriften im Alpenraum genannt werden. Diese geben können einen Hinweis auf die Intensität der Romanisierung geben. Dies wiederum kann etwa die heutige Verbreitung romanischer Basistypen in bestimmten Regionen mehr oder weniger plausibel erscheinen lassen.

Technik

  • VA ist ein rein digitales Projekt – praktisch vollkommener Verzicht auf traditionelle papiergebundene Methoden
  • verwendet Standardsoftware, quasi ausschließlich open source
  • knapp 50% der Projektbeteiligten sind im Informatik-Sektor des Projekts tätig (2 wiss. Mitarbeiter, 1 Hilfskraft)

Backend und Frontend

Backend

  • Backend wird gebildet von einer MySQL-Datenbank
  • Vorteile der MySQL-DB:
    • Web-fähig
    • an der ITG herrscht seit langem Expertise
    • große Anzahl weiterer Projektdaten in der selben Server-Umgebung (MySQL-Cluster), so dass technische/inhaltliche Verknüpfung theoretisch möglich (Demo)
  • Die VADB ist im Lauf der Zeit immer komplexer geworden (normaler Vorgang) – aktuell 156 Tabellen (Demo)
  • Tabellen der Kernentitäten:
    • Einzelbeleg: Tabellen „aeusserungen“ und Tabelle „tokens“
    • Morphtyp: Tabelle „morph_typen“
    • Konzept: Tabelle „konzepte“
    • Ortschaft: Tabelle „orte“
    • Die Zusammenhänge zwischen den einzelnen Entitäten sind in der Datenbank aufgrund der sog. Normalisierung nur durch komplexe Operationen darstellbar. Nur eine kurze Skizze: Beispiel id_aeusserung = 89349
    • Daher Bündelung der verteilten Informationen in sog. Datenzugriffsschicht: vap_ling_de („Human-readable interface“; in mehreren Sprachen verfügbar) und z_ling (für Maschinen)
  • jeweils aktuelle Arbeitsversion trägt den Namen va_xxx
  • VADB wird alle halbe Jahre versioniert
    • Erzeugung einer DB-Kopie, an der nichts mehr geändert wird.
    • Suffix: _jjh (j=Jahr; h=Halbjahr), z. B. va_191: Datenbankversion der ersten Jahreshälfte 2019 (erzeugt Ende Juni/Anfang Juli; die Versionen der 2. Jahreshälfte werden gegen Ende Dezember erzeugt).
    • Wichtig für Gewährleistung der Zitierfähigkeit! Ein Wechsel zwischen den Versionen ist im Frontend von VerbaAlpina möglich (Demo)
  • neben der VADB existiert eine Reihe von Datenbanken der offiziellen VA-Partner (Kooperationsvereinbarungen; bislang insgesamt 53). Präfix: pva_ (= Partner von VerbaAlpina; Demo)

Frontend

  • Standard-WordPress-Installation (Demo: https://www.verba-alpina.gwi.uni-muenchen.de/)
  • auch hier wieder: Front- und Backend (Demo)
  • ergänzt um Eigenentwicklungen, zumeist in Form von sog. Plugins (werden auf Github unter offenen Lizenzen (CC BY-SA,  zur Nachnutzung zur Verfügung gestellt: https://github.com/VerbaAlpina/)
  • Mehrsprachig: die wichtigsten Sprachen des Alpenraums + Englisch (verursacht großen Aufwand)
  • Multifunktional:
    • Arbeitsinstrument für Mitarbeiter
    • Dokumentation
    • Publikation
    • Datensammlung
  • Punkt Dokumentation: Methodologie (Reflexion vielfältiger Aspekte, sprachwissenschaftlicher ebenso wie informatischer) (Demo)
  • Weitere Kern-Module des Frontend neben der Methodologie:
    • Interaktive Karte (Demo: malga, HERDE;
      • Integration von semasiologischer und onomasiologischer Perspektive;
      • qualitative und quantitative Kartierung: quantitative Kartierung bildet die Häufigkeit der in einer Region auf der aktuellen Karte dargestellten Symbole durch Intensität der Flächenfärbung ab (Beispiel: malga|rom|f|- in der Bedeutung ALM)
      • Kombination mit Daten der außersprachlichen Peripherie;
      • Einbindung von Normdaten: Wikidata-Q-IDs und Geonames-IDs: Belegfenster malga ⇒ HERDE im Ort Stenico)
      • Auf der Karte können auch individuelle Suchanfragen in SQL formuliert werden, die dann kartiert werden (Beispiel: liefer alle Einzelbelege des Morphtyps Butter, die mit einem „P“ beginnen: where Type_Kind = ‚L‘ AND Type = ‚Butter‘ AND Instance like ‚p%‘)
      • Technisch hochperformant (Nutzung des Standards WebGL, der den direkten Zugriff auf die Grafikkarte erlaubt; s. den Methodologie-Eintrag)
    • Lexicon Alpinum (Demo alt; Neuentwicklung! ⇒ Demo)
    • Transkriptionstool: Operationalisierung der strukturierten Erfassung analoger Datenquellen, v. a. von Sprachatlanten (Demo; Verwendung des Betacodes ⇒ normale Tastatur, geringe Fehleranfälligkeit, schnell zu erlernen, keine Kenntnisse in phonetischer Transkription erforderlich; Automatisierung vor allem wegen Zuordnungsproblematik nicht möglich)
    • Typisierungstool: Klassifizierung/Typisierung der digitalisierten Daten (Demo)
    • Crowdsourcing-Tool(s) …

Einsatz von Crowdsourcing

  • Motivation:
    1. Konsolidierung von Inkonsistenzen, die sich aus der inhomogenen Dokumentationslage auf Basis von Sprachatlanten und Wörterbüchern ergeben (Übersicht über unterschiedliche thematische Abdeckung verschiedener Atlanten) ⇒ regionale Begrenzung der Quellen und unterschiedlicher Inhalt: z. B. wird nicht jedes Konzept von jedem Sprachatlas berücksichtigt. ⇒ Beseitigung von Dokumentationslücken (Demo)
    2. Mithilfe bei Transkription (⇒ Zooniverse-Tool; ursprüngliche Absicht: Verwendung eines „Baukastens“ ( Zooniverse Project Builder), der den Entwicklungsaufwand reduziert. Hoffnungen haben sich leider nicht bestätigt, Entwicklungsaufwand kaum geringer als bei Eigenentwicklung. Weiterer Nachteil: Nicht direkt ins VA-System integriert, sondern auf Server von Zooniverse. Bislang noch nicht beworben, daher noch nicht produktiv. Transkriptionsergebnisse müssen in csv-Datei exportiert werden, die dann in va-DB importiert wird. Entsprechende Prozedur wird derzeit entwickelt – (Demo) – Zooniverse ist ein „citizen science web portal „, das eine große Anzahl von Crowdsourcing-Projekten unterstützt und auf seinen Seiten hostet. Eines der sehr frühen Projekte: Klassifizierung von Glaxien, ähnliche Aufgabe wie bei VerbaAlpina: Transkription von Logbüchern von Arktisfahrern aus dem 19. und frühen 20. Jh. – Zooniverse ist an der Universität Oxford beheimatet und verfügt über eine sehr große Anzahl von *registrierten* freiwilligen „Crowdern“ (über 1,5 Mio.); VerbaAlpina „not yet an official Zooniverse project“ (aufwendiges Review-Verfahren)
  • Die Vitalität des Crowd-Sourcing-Tools 1) wird überwacht: CSGRAPH

Nachhaltigkeit

  • Sämtlicher „Output“ von VA muss dauerhaft zugänglich und nutzbar sein
  • Paradigma ist – in dieser Beziehung – das traditionelle Buch auf Papier
  • Im Detail sind damit u. a. die folgenden Postulate verbunden:
    • Die Daten müssen dauerhaft auffindbar sein (Buch: Bibliothekskataloge; wichtig: Es muss klar sein, an welche Institution ich mich wende. Bei einem Buch geht man selbstverständlich zur Bibliothek)
    • Die Daten müssen dauerhaft zugänglich sein (Buch: Bibliotheken)
    • Inhalte müssen präzise und stabil zitierbar sein (Buch: Seitenzahlen)
  • Durch die Möglichkeiten der elektronischen Vernetzung kommen, gegenüber dem Paradigma des Buches, die folgenden Postulate hinzu:
    • Projektdaten sollten mit Daten außerhalb des Projekts verknüpft werden können.
    • Zu diesem Zweck müssen die Daten des Projekts zu Entitäten zusammengefasst werden. Jede Instanz einer Entität muss eindeutig identifizierbar sein und über eine elektronische Adresse ansprechbar sein.
    • Die Kernentitäten von VA sind wiederum die oben bereits genannten:
      • Morphtypen
      • Konzepte
      • Orte
      • Basistypen
    • Jede Instanz dieser Entitäten erhält einen innerhalb des Projekts eindeutigen Identifikator: Morphtypen Präfix L, Konzepte Präfix C, Orte Präfix A, Basistypen Präfix B) – Beispiele im Lexikon Alpinum
    • Die Identifikatoren können auch als „Normdaten“ bezeichnet werden – Unter Normdaten versteht man eindeutige, numerische oder alphanumerische Zeichenketten, die eine Instanz einer bestimmten Entität eindeutig identifizieren. Frühe Normdatensysteme sind z. B. im Kontext des Bibliothekswesens entstanden; ein Motiv dabei ist gewesen, Autoren mit gleichlautenden Namen eindeutig identifizieren zu können (⇒ häufige Personennamen wie im Deutschen „Schmid“ oder „Meier“). Bekannte Normdatensysteme sind z. B. die Gemeinsame Normdatei (GND) der deutschen Nationalbibliothek (Suchportal; Demo: Krefeld [123778689], Alexander der Große [118501828]). Ein für VA relevantes Normdatensystem ist z. B. die Wikidata (Beispiel folgt gleich)
    • Die projektspezifischen Normdaten können im Mapping-Verfahren mit bestehenden projektexternen Normdatensystem verknüpft werden (z. B. Wikidata-QIDs: VA-Konzept-ID C612 [ALMHÜTTE] ⇒ Wikidata Q-ID Q2649726])
  • Sofern diese inhaltliche Verknüpfung nicht von Menschen, sondern von Maschinen geleistet werden soll, spricht man von Interoperabilität.
  • Die interaktive Karte stellt im Hinblick auf die Zitierfähigkeit eine besondere Herausforderunge dar: Jeder User kann individuelle Kartenbilder erzeugen, die möglicherweise wesentlich für eine spezifische Argumentation sind. VA hat daher ein System entwickelt, das die Erzeugung individueller URLs erlaubt, deren Aufruf exakt das Kartenbild generiert, das bei Erzeugung der URL auf dem Bildschirm zu sehen war (Demo).
  • Wesentliche Voraussetzung für die uneingeschränkte Nachnutzbarkeit von Projektdaten ist eine möglichst offene Lizenzpolitik. Seit einigen Jahren bietet hier die Initiative Creative Commons (CC; gemeinnützige Organisation, gegründet 2001) generische Lizenzmodelle. VA stellt all seine Inhalte, soweit möglich, unter der CC-Lizenz BY-SA zur Verfügung. Einzige Bedingung ist dabei nur die Nennung des ursprünglichen Urhebers (BY) und die Weitergabe der Daten unter eben dieser Bedingung (SA = share alike)
  • Diese Postulate im Hinblick auf Nachhaltigkeit sind seit einigen Jahren im Akronym FAIR verankert (bereits von Thomas Krefeld angesprochen): Daten müssen Findable – Accessible – Interoperable und Reusable sein.
  • Übertragung der VA-Daten an die UB der LMU, dabei Anreicherung um Metadaten (Prozeduren derzeit noch in der Entwicklung)
  • Zu diesem Zweck: API (Application Programming Interface; dt: Programmierschnittstelle) – Ermöglicht Zugriff auf die Kerndaten von VA, gegliedert nach Morphtypen – Konzepten – Ortschaften – Einzelbelegen (Demo)
  • Wozu Metadaten? – Ein simples Beispiel: VA spricht in seinem Datenbestand von „morpholexikalischem Typ„. In einem anderen Projekt wird dasselbe Konzept etwa als „Lemma“ bezeichnet. Die Inhalte beider Kategorien sind jedoch aufeinander zu beziehen. Damit Menschen – und mehr noch Maschinen – erkennen können, dass es sich um kongruente, mit einander zu verknüpfende Daten handelt, können die jeweiligen Datenbestände auf ein gemeinsames, nach Möglichkeit weithin bekanntes und anerkanntes Bezugssystem abgebildet werden. Meist verwendet das Metadatenschema ein alphanumerisches System, das bestimmte Entitäten eindeutig identifiziert.
  • VA bzw. die UB der LMU verwenden zwei verschiedene, weit verbreitete Metadatenschemata, wobei das eine, vom Konsortium Datacite, im Wesentlichen für die Erfassung von üblicherweise in Bibliothekskatalogen erfassten Daten wie Autoren, Schlagwörter und Entstehungszeit und -ort bezieht (s. dazu den Best Practice Guide)
  • Für die inhaltliche Tiefenerschließung findet das Metadatenschema CIDOC CRM (das Conceptual Reference Model [CRM] geht zurück auf eine Arbeitsgruppe des Comité International pour la Documentation [CIDOC], das seinerseits eine Gliederung des International Council of Museums (ICOM) darstellt; seit Anfang der 1990er Jahre) Anwendung (Dokumentation):

 

VerbaAlpina – Digital Geolinguistics Dedicated to the Lexical Analysis of the Alpine Region (Zitieren)

Stephan Lücke
(5722 Wörter)

Abstract

Since 2014 the DFG-funded long term project VerbaAlpina (VA) is run at the Ludwig-Maximilians-University of Munich (LMU). VA is a cooperation of the Institute of Romance Studies and the LMU Center for Digital Humanities (DH; IT-Gruppe Geisteswissenschaften).

The project focuses on lexical variation throughout the Alpine area as defined by the so-called Alpine Convention (https://www.alpconv.org/). Whereas geolinguistic research within the Alpine region is traditionally orientated towards the spread of national languages and towards political borders, VA takes the homogeneous natural environment of the mountaneous region and the resulting uniform habitat conditions and ways of living as the guiding parameters defining its area of research.

VA is conceptualized as a strictly digital project that uses web technology for various purposes such as documentation, publication and visualisation. VA takes its data from traditional geolinguistic publications, mainly linguistic atlases and suitable dictionaries (i.e. dictionaries providing geographic information). The strictly digital approach is associated with several challenges starting from the difficulties regarding the transcription of the sometimes complex phonetic characters that are used especially in some of the linguistic atlases. VA has developed a series of specific reusable and freely available online tools that are used within the workflow of digitizing data from the printed sources. Another tool, the so-called Crowdsourcing tool, was built for gathering speech data from online users with the aim of filling documentation gaps that result from inconsistencies of the available printed sources.

An interactive online map that is using performant up-to-date graphical technology (WebGL) offers suggestive qualitative and quantitative visualisation of geographic distribution patterns from onomasiological and/or semasiological perspectives. These can also be combined with non linguistic data such as the sites of latin inscriptions.

In addition to the geolinguistic core themes of the project, VA is providing methodological reflexion on many of the issues deriving from the strictly digital orientation that should be of interest also beyond the borders of the project and even beyond the field of geolinguistics. In general, VA is looking for perspectives and solutions that allow the linkage of lexical data across so far isolated domains of geolinguistic research projects with the option of real interoperability (the “I” in the acronym FAIR).

The talk will provide more detailed information on the mentioned aspects of the project VerbaAlpina.


Talk*

One word in advance: It is still common to work with PowerPoint presentations on occasions like this. VerbaAlpina tries to avoid PowerPoint as it does not totally comply with the „FAIR“-criteria: At least a powerpoint presentation is not interoperable (FAIR) at all and usually hardly findable, accessible and reusable (FAIR). On the other hand, all these demands are met with a web-based contribution like the one you can see right here. This preamble is not meant as a criticism of using Powerpoint but rather as an apology for the use of this different kind of presentation.

You can scan the QR-Code below with your smartphone and follow the talk on your mobile device.

! Scan with Smartphon !

! Scan with Smartphon !

Introduction

Some of you might already know our project VerbaAlpina. Nevertheless, I will start my talk by sketching the overall frameset of VerbaAlpina.

Scientific Approach

VerbaAlpina is a linguistic project with mainly lexical orientation. The focus is on a simple question: We would like to know which terms are used for specific concepts in the Alpine region. The documentation is limited to concepts that are typical for the Alpine region, such as mountain pasture and dairy farming or the specific alpine flora and fauna. From the point of view of traditional geolinguistics, a fundamental innovation is certainly the definition of the research area. The scope of many of the existing speech atlases for example complies with political-administrative concepts such as national territories or the selection criterion is restricted to the distribution of national languages. In contrast, VerbaAlpina has chosen the homogeneity of the Alpine region in terms of landscape, culture, and economy as the decisive aspect for the definition of the research area.

As already mentioned, the focus of VerbaAlpina’s interest is the lexical material. VerbaAlpina’s database is primarily based on material published in traditional language atlases. To a certain extent dictionaries were also used, but only those whose entries contain information on the geographical distribution of the documented terms. Examples include the Swiss-German Idiotikon or the Dizionario di Montagne di Trento by Corrado Grassi (DizMT).1. Among the language atlases prominent examples are the Sprach- und Sachatlas Italiens und der Südschweiz (AIS) and the Vorarlberger Sprachatlas (VALTS).

VerbaAlpina sees itself as an entirely „digital“ online project that completely refrains from publications in conventional book or atlas form. The term „digital“ also refers to work with *structured* data, that means data enriched with metadata. All these data are managed in a relational database (MySQL).

VerbaAlpina’s data model is dominated by the correlation between the world of language and the extralinguistic reality, that is the world of concepts. The following scheme illustrates this correlation and makes it clear that in principle a certain word can designate more than just one concept and vice versa several words can exist for one and the same concept. In the context of VerbaAlpina, concepts are always written in capitals to clearly distinguish between words and concepts:

Correlation between designations and concepts

This basic model, which initially appears very simple, quickly acquires a high degree of complexity by adding the dimensions of space and time. This is because certain terms for certain concepts are only used in certain regions. The location and size of these regions can change over time or even disappear altogether.

So the question is:

  • Which words are or have been used
  • at which places
  • at what time to designate
  • which concepts?

Since the dimension of space is one of the central factors, VerbaAlpina only collects language material with georeferencing, as is the case in language atlases or in some dictionaries.

VerbaAlpina’s spatial dimension is defined by the perimeter of the so-called Alpine Convention. The Alpine Convention is a treaty under international law signed by the countries sharing the Alps. The perimeter is a boundary drawn by this organisation which defines the extent of the Alps administratively. For purely pragmatic reasons VerbaAlpina follows this border since a clear delimitation of the study area is organisationally indispensable and otherwise hardly possible.2

Within the study area all collected and georeferenced language material is related to the grid of political communities. In the case of large-scale distribution data such as „Ticino“ or „Vorarlberg“, the corresponding language data is attributed to all municipalities in these regions. Starting from the fine granulation of the political communes, the language material can be grouped in later analyses according to superordinate political units such as cantons, departments, government districts or regions and visualised on a map.

From VerbaAlpina’s point of view, the dimension of time is a little problematic, since the data grid is still very patchy in terms of chronological distribution and unbalanced in relation to the entire Alpine region. Some of the sources evaluated by VerbaAlpina indicate the time of the collection of a single document very precisely, sometimes even to the day3, while for other sources the year of publication only provides a terminus ante quem for the language data recorded therein.

VerbaAlpina’s data material acquires historical depth through the interlocking of the words drawn from the sources and the identification of similarities in the lexical basis. French salamandre, Italian salamandra and German salamander have the same lexical basis. It is obvious to assume a historical connection here. However, it is not easy to decide whether, for example, the German word is derived from one of the two Romance words (loanword scenario), or whether all three variants can be traced back to a common forerunner independently of each other. In such cases, VerbaAlpina identifies a lexical precursor from an earlier language spoken in the Alpine region and assigns it to the modern words in order to be able to grasp *that* there is a connection between the three words mentioned. VerbaAlpina refers to such precursors as „base types“. In the case of the example this would be the Latin salamandra.

The reason for this simplification is twofold: on the one hand, it is often not possible to decide which of the possible scenarios mentioned is present in the individual case and on the other hand, corresponding searches may be very time-consuming, so that they cannot be carried out within the framework of the project due to time constraints. The VA base types have the great advantage that they can be used to represent obviously existing connections *without* forcing the specification of the connections in detail.

The central reference value of VerbaAlpina are the so-called „morpholexical types“, hereinafter referred to as „morph types“. These are lexical units that are distinct, that means unmistakable, with regard to the linguistic family they belong to, spelling, genus and the question of whether they have an affixation or not. In this respect, the morph types correspond roughly to the lemmas of traditional dictionaries. These are predominantly nomina, verbs only play a subordinate role in VerbaAlpina so far.

VerbaAlpina initially bases its typification on so-called reference dictionaries. If there is a suitable entry in these dictionaries, it is assigned to the selected tokens. If the type exists in several reference dictionaries, multiple assignments are made. If a morph type does not exist in any reference dictionary, VerbaAlpina creates its own new morph type which is then assigned.

For the data collected from language atlases and dictionaries the morph type they represent must be decided on a case-by-case basis. An automatic assignment seems impossible. VerbaAlpina has developed a special tool facilitating manual typification, in which the transcribed and then tokenised utterances can be assigned to morph types (screenshot; link [registered users only]).

VerbaAlpina deliberately refrains from assigning morph types to individual languages or even dialects. The reason is that linguistic landscapes and thus also the Alpine region basically represent continua within which clear demarcations are practically impossible. Strictly speaking, each locality can have its own dialect. When defining the morph types, therefore, only the assignment to one of the three language families existing in the Alpine region is made. The assignment to a language family is inherited from the sources from which the documents belonging to the respective morph type originate.

The phonetic dimension is largely ignored by VerbaAlpina but can be mapped in the VerbaAlpina data model and is already present selectively in the database.

Many project specific aspects, be it related to linguistics or computer sciences, are reflected and thus documented in the methodology section of the project website.

Technical Aspects

VerbaAlpina tools

VerbaAlpina uses standard software wherever possible which must also be open source. Essentially, this involves the MySQL database management system (DBMS) for managing the central database and the WordPress PHP framework for the project website. For the specific requirements of the project, however, tools based on the aforementioned basic technologies have been developed. All of them are available on Github for free re-use under the CC-BY-SA license (VerbaAlpina-Github-Repository). And there is already one case in which some of our tools is reused: The VerbaPicardia (APPI).

Betacode and Transcription Tool

Betacode

For the transcription of „exotic“ writing systems, that primarily are found in language atlases, VerbaAlpina uses a concept that was developed and successfully used for the Thesaurus Linguae Graecae (TLG) in the 1970s (TLG-Betacode). In essence, the aim is to replace arbitrary characters and diacritics with defined and documented sequences of ASCII characters. The rules follow as simple and mnemotechnically favorable patterns as possible. For example, an acute on a base character is transcribed by a slash behind the base character.

The utterance you see here4:

taken from the AIS, is transcribed according to the transcription rules as follows:

la lac/a/

The sound value denoted by a sign is not important at all. This also means that identical signs such as the acute are always transcribed in the same way, that means with a slash after them, completely independent of the transcribed original and the possibly specific phonetic meaning. Only a source specific conversion procedure, in which all transcriptions are transferred into the IPA system, takes the sound values of the original source into account.

This method has several advantages:

  • It is possible to transcribe characters that are not yet Unicode-encoded.
  • The transcription can be done comfortably with standard keyboards and without complicated key combinations.
  • The transcriptors do not require knowledge of the meaning of the characters.
  • The transcriptions are – unlike multi-byte characters from UTF-8 – technically robust against unwanted changes.
  • Transcription takes place without loss of information.5

Transcription Tool

Especially, the automatic structured recording of lexical material from language atlases represents a considerable technical problem. It is not about the transformation of the partly exotic writing systems, which are sometimes used there. OCR programs such as Abbyy Finereader can be trained in such a way that they also correctly capture such writing systems and even produce the VerbaAlpina-specific beta code.6

In case of the linguistic atlases of the Romance tradition the real difficulty lies often in assigning the correct place, represented by a number, to the statements entered directly on the map. Machines are always overwhelmed by this task – and sometimes even humans are – when the entries on the map are too close together, as is the case, for example, in the AIS in southern Switzerland and neighbouring Italy.7

AIS-map 1218: Problem of assigning strings to numbers

From the point of view of automatic data acquisition the language atlases with point symbol maps, which are widely used in the field of German studies, appear to be even more complicated. In contrast to the Romance atlases data is usually displayed here in typified form. Concrete individual utterances of the informants are only presented occasionally.

Punktsymbolkarte germanistischer Tradition (VALTS IV 73: Die SENNHÜTTE)

The structured collection of data from these language atlases can therefore only be carried out manually. The problem is that consistent, error-free data collection requires a high degree of concentration and discipline. VerbaAlpina has developed a special transcription tool to make this work easier, to reduce the risk of errors and to ensure that the procedure is as systematic as possible.

Transcription tool

The tool synoptically combines a scan of the map to be transcribed and the form in which the transcriptions are entered. Maps and points on the map that have already been transcribed are marked accordingly. The system also prevents the duplicate capture of individual entries on the map. The transcriptor is given the numbers or signatures of the points on the map one after the other by the system. The transcription then takes place in the appropriate field of the form. The other parameters such as map number, location point number and concept assignment are specified by the system and are stored together with the transcription in the database. The registered data in the database then look like this:8

The input mask presents the general transcription rules for data entry in beta code in a windowframe at the top right, so the transcriptor can consult them with as little effort as possible. The automatic conversion corresponding to the original script on the map is displayed to the right of the input field as the transcriptor is writing. Thus, the transcriptor can immediatly detect eventual typos. In addition, the system prevents entering invalid character combinations.

Crowdsourcing tool

The database compiled by VerbaAlpina from language atlases and dictionaries shows inconsistencies in several respects. These inconsistencies result mainly from the fact that the language atlases each cover only parts of the Alpine region and do not all comprise the same concepts. As a result, for a certain region there are terms for concepts that were not even queried elsewhere – which does not mean that they do not exist there. For example the concept BEE is only attested in the areas documented by the following atlases: AIS, ALF, ALJA, ASLEF, TSA as is visualized on the following map9

Missing attestations for the concept BEE

It is not possible to carry out any surveys to fill the gaps. VerbaAlpina is therefore using the idea of crowdsourcing to round off the database. The idea is that users on the Internet contribute previously undocumented terms for selected concepts. VerbaAlpina has developed a special crowdsourcing tool (CS tool) for this purpose (Link). The functionality is deliberately kept simple so as not to deter potential crowders.

The VerbaAlpina Crowdsourcing (CS) Tool

Each „crowder“ has to select a location on a map and enters designations for selected concepts that are, in his opinion, common at this location. VerbaAlpina typifies the entire material as well as the data from atlases and lexica. A validation of the crowd material is theoretically possible through the principle of third-party confirmation but is currently not carried out by VerbaAlpina, mainly because the amount of data is still too small.

VerbaAlpina is monitoring the crowd activity (Link). Experience has shown that the vitality of the croudsourcing tool, that is: the number of entries, depends crucially on corresponding advertising activities. Immediately after media reports about VerbaAlpina and its crowdsourcing tool or corresponding propaganda in social media, the number of entries rises sharply but always falls again soon.

Mapping tool

The interactive online map appears as the, so to say, „showcase“ of the project. It is designed as the central data access point for the public, enabling the representation of language data in the dimension of space and thus revealing connections that often remain hidden when data is viewed in table or list form.

The digital map offers both the possibility of accessing the database from the perspective of words, that means of mapping the various concepts that can be designated by a particular word, and the option of asking the opposite question: Which concepts are designated where with which words. In traditional publishing, these two perspectives could only be served by two different genera: The (onomasiological) language atlas and the (semasiological) dictionary. The digital online map even offers the possibility of synoptically mapping both perspectives.

The map essentially offers two different forms of visualization. he standard method is qualitative mapping where the individual data which are bundled according to political communities are first displayed on the map by symbols. The following example shows the mapping of the distribution of the Romanic morph type malga, grouped according to its regionally different meanings:

A click on the map symbols opens an info window in which the underlying language data is presented. In addition to the source, the concept designated with the word, the base type and the individual attestation of the respective source in IPA are also displayed. The framed letters behind morph and base types refer to the corresponding entries in the reference dictionaries and are partly interactive, depending on accessibility on the net. A click on the symbol then leads directly to the corresponding entry in the reference dictionary. The info window also includes norm data and links to them. A click on the globe symbol next to or below the municipality name leads to the corresponding Geonames page, the concept names are linked to the Wikidata entries.

In addition to qualitative mapping, VerbaAlpina also offers a quantifying presentation. A click on the Q in the circle next to the menu item „Areas and regions“ acccumulates the currently mapped elements according to regions and colours them differently according to the number of elements mapped there. As default the large language areas form the reference pattern. By selecting the corresponding menu item „Areas and regions“, the data can also be accumulated and mapped according to smaller administrative units down to the level of municipalities.

The following map shows the distribution of morph types connected to the (Latin) base type butyuru(m) (Link):

Distribution of morph types connected to the base type butyru(m) (qualitative mapping)

The same data accumulated on the quantifying map (Link):

quantifying representation of the distribution of morph types connected to the base type butyru(m)

In addition to the realistic representation of the geographical boundaries, the quantifying representation can also be visualized on a hexagon map. In this kind of map, the geographical units are represented by hexagons of identical size. Thus, visual distortion effects are avoided which result from the area sizes which differ strongly from each other in reality. Of course, this kind of mapping has the disadvantage that the geographical arrangement of the areas and especially the number of adjacent areas no longer corresponds to reality in most cases. The added value certainly results from the possibility of switching between the different mapping variants and thus gaining an almost objective impression.

Hexagon map

The sharing symbol at the top right-hand corner of the map allows you to call up a persistent link that refers stably to the current map view and can, for example, be sent by e-mail or used in texts.

The realization of the online map is based on the latest graphics technology (WebGL) and is extremely powerful. This performance becomes visible above all during zoom processes with a large number of map symbols and borders, which demand a high computing power from the computer. The use of WebGL allows the necessary calculations on the processor of the graphics card (GPU) which is responsable for the decisive performance gain.

Cross-linkage and sustainability

Access to VA-data

Access to VerbaAlpina data is possible in various ways:

  • Via the project portal, which is freely accessible on the Internet and above all via the interactive online map and the – not yet mentioned – Lexicon alpinum,
  • via the API, which is also freely accessible,
  • or by using the PMA interface of the MySQL database.

The API allows the download of finely granulated material in a number of different formats and aggregations. Access via the PMA interface is reserved for VerbaAlpina’s official cooperation partners. The PMA interface allows data analysis using the SQL language. SQL-statements can also be executed using a form in the mapping tool. This function will be accessible to the public very soon. At present its use is restricted to registered users.

VerbaAlpina’s core data is very finely granulated and the individual elements are uniquely identified with persistent identifiers and can therefore be addressed precisely. Ultimately, these alphanumeric identifiers fulfill the function of VerbaAlpina-specific norm data. In concrete terms, all morph types, concepts and political communities are given a unique number which can be used to access the specific data in different ways or be referenced externally. Identifiers of the morph types have the prefix L, concepts C and communities A. The ID L1435, for example, stands for the morph type „babeurre (m.) (roa.)“. The first of the following addresses calls up a mapping of the distribution of this morph type, the second leads to the download of the data stored on this morph type in XML format and the last, finally, leads to the commentary in the Lexicon Alpinum – if available:

With a few exceptions, all URLs that refer to VerbaAlpina content contain a parameter that refers to a specific version of VerbaAlpina, marked in red in the examples above. The first two digits represent the year, the last one the version number of the year (191: first version in 2019). While the database of the working version, which is recognizable by the character string xxx, is subject to permanent changes, the contents of the other versions are stable. This ensures that references to these URLs always call up the same content and citation security is guaranteed. VerbaAlpina data is versioned twice a year, at mid-year and at year-end. You can choose between the available versions on the homepage.

The data of VerbaAlpina will soon also be transferred to the RDF schema of the Semantic Web. However, the establishment of a SPARQL endpoint is not planned for the time being; the corresponding implementation involves some effort and seems dispensable since there are a number of other ways of accessing the VerbaAlpina data. After all, VerbaAlpina meets the criteria of the „Linguistic linked open data“ movement (http://linguistic-lod.org/).10. Towards open data for linguistics: Lexical Linked Data (PDF). Heidelberg, in: Alessandro Oltramari, Piek Vossen, Lu Qin, and Eduard Hovy (Hrsgg.), New Trends of Research in Ontologies and Lexical Resources. Springer.)), and the data of VerbaAlpina will soon be included in this.

In the course of transferring the data of VerbaAlpina to the research data repository of the LMU-Library every item is enriched with DataCite metadata and is given a persistent DOI. The corresponding procedure is currently in development. It will soon be functional.

Linkage with external resources

VerbaAlpina links the three core categories of its database with external databases via the integration of suitable norm data.

In the case of morph types, corresponding links are established to the reference dictionaries. An interesting side effect is that the different suitability of the corresponding resources becomes clear. In terms of maximum interoperability, only some of the reference dictionaries provide suitable possibilities to technically address data in a desireable way. Positive examples include the portal of the Centre National de Ressources Textuelles et Lexicales ([Bibl:CNRTL]) or the Italian Treccani which offer transparent URLs for each lexical entry (e.g:  https://www.cnrtl.fr/definition/beurre, http://www.treccani.it/vocabolario/burro/). In some other cases references are only possible with great inaccuracy or not at all. It is not uncommon to encounter the phenomenon that the addressability of the contents still refers to the conventional page logic of book printing and to PDF documents or image files. This is, for example, the case with the French etymological dictionary (FEW).

For the concepts VerbaAlpina refers so far exclusively to the so-called Wikidata data objects. Each concept is assigned the respective Wikidata Q-ID in the database of VerbaAlpina. The corresponding link leads to the Wikidata data object page. There you will find links to the articles in the different Wikipedia of this concept. The link to the norm data of geonames has already been mentioned.

As we have already seen, links to all norm data are presented to the user in the info windows on the online map.

Some organizational stuff

VerbaAlpina started in 2014 and is funded by the German Research Foundation (DFG) with a perspective until 2025. The individual project terms comprise 3 years each. At the moment we are heading towards the last year of the second term and are about to prepare the application for the funding of the third term.

VerbaAlpina is directed by Thomas Krefeld and myself. The staff is divided into two parts: There are three linguists and two computer scientists who are each supported by assistants. Among the linguists there are two Romance scholars and one Germanist. One of the computer scientists is mainly responsible for all aspects of the core data (data modelling, interfaces, API), the other mainly for all questions of visualisation, mainly the interactive online map.

VerbaAlpina is thus an interdisciplinary DH project with parts of the classical humanities and computer science. The LMU Center for Digital Humanities (IT-Gruppe Geisteswissenschaften; ITG) is responsible for the informatics part. This institution was created in 2000, is largely financed by the six humanities faculties of the LMU and has an unlimited perspective of existence. The ITG is responsible for planning and operating the IT infrastructure in the Humanities area. One of the ITG’s steadily growing areas of responsibility is support in the planning and implementation of DH projects. From the ITG’s point of view, VerbaAlpina is only one of numerous projects whose project data is managed in the context of a heterogeneous, but uniformly – namely relationally – structured overall data pool. Over the years, this data pool has grown to considerable size and diversity, offering at least theoretically the perspective of data analysis across project boundaries. Against this background, the ITG is currently developing a cooperation with the LMU-Master’s programme in Data Science, which was launched at the beginning of 2017.

The ITG also plays an important role with regard to the sustainability of the results produced by VerbaAlpina. After the end of project funding, the ITG will continue to operate the project portal as far as possible and perform the minimum maintenance work required for operation.


* Given at the colloqium „NEW WAYS OF ANALYZING DIALECTAL VARIATION“, held at Sorbonne University, Paris, 21-23 November 2019. The English version of the talk was initially produced with the help of DeepL (https://www.deepl.com/translator) and subsequently corrected or adapted where necessary.


  1. Grassi documents the local variation of a single small town in the Italian province of Trento 

  2. However, the chosen definition of the study area causes certain asymmetries, such as the fact that the Swiss Emmental, famous for its cheese, lies outside the Alpine Convention and is therefore not covered by VerbaAlpina, although this region could very well be considered part of the Alpine region from both an economic and an environmental point of view. 

  3. Such is the case in the <span class="bibl" data-bibl="ais">AIS</span> 

  4. AIS 1218_1, 129 

  5. This would be the case, for example, if the Böhmer Ascoli system, used for example in the <span class="bibl" data-bibl="ais">AIS</span>, were transcribed directly into <span class="vaabr" data-vaabr="IPA">IPA</span> instead of the present one, since <span class="vaabr" data-vaabr="IPA">IPA</span> does not allow such a fine differentiation with regard to the individual sounds as Böhmer Ascoli does 

  6. The procedure is sketched in <a href="http://www.kit.gwi.uni-muenchen.de/pdf/band/001/korpus-im-text_band_001_v001.pdf"><span class="vaabr" data-vaabr="SDOT">S.</span> Lücke / C. Riepl / C. Trautmann, Softwaretools und Methoden für die korpuslinguistische Praxis (Korpus im Text 1, München 2017</a>, <span class="vaabr" data-vaabr="SDOT">S.</span> 126f. 

  7. A master thesis has just been completed at the Institute of Computer Science of the <span class="vaabr" data-vaabr="LMU">LMU</span>, which was intended to design an algorithmic solution to this problem. Among other things, deep learning methods were used. As far as VerbaAlpina can judge, however, no success is in sight in this way either – not to talk about the technical availability of an appropriate tool. 

  8. The corresponding sql-statment reads as follows:</p> <p>SELECT</p> <p>concat(a.Aeusserung, ‚ (‚,<br /> group_concat(f.<span class="vaabr" data-vaabr="IPA">IPA</span> order BY f.Id_Token SEPARATOR ‚ ‚),‘)‘<br /> ) AS aeusserung,<br /> b.erhebung,<br /> b.karte,<br /> b.nummer,<br /> b.stimulus,<br /> c.Nummer,<br /> c.Alter_Informant,<br /> c.Geschlecht,<br /> e.Beschreibung_F,<br /> ‚[name of transcriptor]‘ as erfasst_von,<br /> a.erfasst_am</p> <p>FROM aeusserungen a<br /> JOIN stimuli b<br /> USING(id_stimulus)<br /> JOIN informanten c<br /> USING(id_informant)<br /> JOIN vtbl_stimulus_konzept d<br /> USING(id_stimulus)<br /> JOIN konzepte e<br /> USING(id_konzept)<br /> JOIN tokens f<br /> ON a.Id_Aeusserung=f.Id_Aeusserung<br /> WHERE<br /> a.Aeusserung LIKE ‚%lac/a-/%‘<br /> and b.Erhebung LIKE ‚AIS‘<br /> AND b.Karte LIKE ‚1218‘<br /> AND b.Nummer LIKE ‚1‘<br /> AND c.Nummer LIKE ‚128‘<br /> AND e.Beschreibung_F LIKE ‚PETIT-LAIT, APRÈS LA PREMIÈ<span class="vaabr" data-vaabr="RE">RE</span> SÉPARATION DES COMPOSANTS SOLIDES, EST DONNÉ À MANGER‘<br /> GROUP BY a.Id_Aeusserung; 

  9. <strong>AIS</strong>: Map 1152: un’ape; le api“<br /> <strong>ALF</strong>: Map 1: abeille“<br /> <strong>ALJA</strong>: Map 792: (l‘) abeille *(le) mâle des abeilles“<br /> <strong>ASLEF</strong>: Map 1148: ape“<br /> <strong>TSA</strong>: Map III_28: Biene“</p> <p>(cf. map <a href="https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=xxx&tk=2428" target="_BLANK">https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=xxx&tk=2428</a>)<br />  

  10. <span class="vaabr" data-vaabr="SDOT">S.</span> Chiarcos, Christian; McCrae, John; Cimiano, Philipp; Fellbaum, Christiane (2013 

VerbaAlpina – Digital Geolinguistics Dedicated to the Lexical Analysis of the Alpine Region (Zitieren)

Stephan Lücke
(4835 Wörter)

Abstract

Since 2014 the DFG-funded long term project VerbaAlpina (VA) is run at the Ludwig-Maximilians-University of Munich (LMU). VA is a cooperation of the Institute of Romance Studies and the LMU Center for Digital Humanities (DH; IT-Gruppe Geisteswissenschaften).

The project focuses on lexical variation throughout the Alpine area as defined by the so-called Alpine Convention (https://www.alpconv.org/). Whereas geolinguistic research within the Alpine region is traditionally orientated towards the spread of national languages and towards political borders, VA takes the homogeneous natural environment of the mountaneous region and the resulting uniform habitat conditions and ways of living as the guiding parameters defining its area of research.

VA is conceptualized as a strictly digital project that uses web technology for various purposes such as documentation, publication and visualisation. VA takes its data from traditional geolinguistic publications, mainly linguistic atlases and suitable dictionaries (i.e. dictionaries providing geographic information). The strictly digital approach is associated with several challenges starting from the difficulties regarding the transcription of the sometimes complex phonetic characters that are used especially in some of the linguistic atlases. VA has developed a series of specific reusable and freely available online tools that are used within the workflow of digitizing data from the printed sources. Another tool, the so-called Crowdsourcing tool, was built for gathering speech data from online users with the aim of filling documentation gaps that result from inconsistencies of the available printed sources.

An interactive online map that is using performant up-to-date graphical technology (WebGL) offers suggestive qualitative and quantitative visualisation of geographic distribution patterns from onomasiological and/or semasiological perspectives. These can also be combined with non linguistic data such as the sites of latin inscriptions.

In addition to the geolinguistic core themes of the project, VA is providing methodological reflexion on many of the issues deriving from the strictly digital orientation that should be of interest also beyond the borders of the project and even beyond the field of geolinguistics. In general, VA is looking for perspectives and solutions that allow the linkage of lexical data across so far isolated domains of geolinguistic research projects with the option of real interoperability (the “I” in the acronym FAIR).

The talk will provide more detailed information on the mentioned aspects of the project VerbaAlpina.


Talk*

Englische Version

Einführung

Ein Wort vorab: Nach wie vor ist es üblich, bei Vorträgen mit PowerPoint-Präsentationen zu arbeiten. Es gehört zum Konzept von VerbaAlpina, darauf zu verzichten, und die Vorträge stattdessen als WordPress-Beiträge zu konzipieren, die im Internet frei verfügbar sind. Der Grund ist, dass PowerPoint-Präsentationen nicht „FAIR“, also findable, accessible, interoperable und reusable sind, VerbaAlpina jedoch größten Wert auf die Einhaltung dieser Prinzipien legt. Mit WordPress-Beiträgen ist dies deutlich besser gewährleistet.

Some of you might already know our project VerbaAlpina, regardless I want to start my talk by sketching the overall frameset of VerbaAlpina in short terms.

Scientific Approach

VerbaAlpina ist ein im wesentlichen lexikalisch ausgerichtetes sprachwissenschaftliches Projekt. Im Zentrum des Interesses steht die vor der Hand einfache Frage, welche sprachlichen Bezeichnungen für ganz bestimmte Konzepte im Alpenraum verbreitet sind. Die Dokumentation ist dabei beschränkt auf Konzepte, die typisch für den Alpenraum sind, wie etwa die Alm- und Milchwirtschaft oder auch die spezifisch alpine Tier- und Pflanzenwelt. Eine aus Sicht der traditionellen Geolinguistik grundlegende Neuerung ist sicherlich der Zuschnitt des Untersuchungsgebiets, oder vielmehr die zugrundeliegende Motivation, die nicht, wie verbreitet der Fall, politisch-administrative Konzepte wie etwa Staatsgebiete, sondern vielmehr die naturräumliche und in der Folge kulturelle Homogenität einer Region zum Auswahlkriterium macht.

Wie bereits gesagt, steht das lexikalische Material im Mittelpunkt des Interesses von VerbaAlpina. Der Datenbestand von VerbaAlpina basiert zum einen auf dem Material, das in traditionellen Sprachatlanten publiziert vorliegt. Zum anderen wurden auch Wörterbücher herangezogen, allerdings nur solche, deren Einträge auch Informationen zur geographischen Verbreitung der Bezeichnungen enthalten. Als Beispiel können das Schweizerdeutsche Idiotikon oder auch der Dizionario di Montagne di Trento von Corrado Grassi genannt werden. Letzterer dokumentiert die lokale Variation eines einzelnen kleinen Ortes in der italienischen Provinz Trento. Von den Sprachatlanten können als prominente Beispiele der Sprach- und Sachatlas Italiens und der Südschweiz (AIS) oder auch der Sprachatlas von Vorarlberg (VALTS) genannt werden.

VerbaAlpina versteht sich als durch und durch „digitales“ Online-Projekt, das vollständig auf Publikationen in herkömmlicher Buch- oder Atlasform verzichtet. Mit „digital“ ist hier überdies die Arbeit mit *strukturierten*, also um Metadaten angereicherten, Daten gemeint. Diese werden in einer relationalen Datenbank verwaltet.

Das Datenmodell von VerbaAlpina wird dominiert von der Wechselbeziehung zwischen der Welt der Sprache und der außersprachlichen Realität, also der Welt der Konzepte. Das nachfolgende Schema illustriert diese Wechselbeziehung und macht deutlich, dass grundsätzlich ein bestimmtes Wort mehr als nur ein Konzept bezeichnen kann und umgekehrt auch mehrere Wörter für ein und dasselbe Konzept existieren können. Zur klaren Unterscheidung zwischen Wörtern und Konzepten werden im Kontext von VerbaAlpina Konzepte stets in Versalien geschrieben:

Zusammenhang zwischen Bezeichnungen und Konzepten

Dieses zunächst sehr simpel anmutende Basismodell erlangt sehr schnell hohe Komplexität durch die Hinzufügung der Dimensionen von Raum und Zeit. Denn bestimmte Bezeichnungen für bestimmte Konzepte sind nur in bestimmten Regionen gebräuchlich. Dabei können Lage und Größe dieser Regionen sich über die Zeit verändern oder auch ganz und gar verschwinden.

Die Fragestellung lautet also:

  • Welche Wörter werden oder wurden
  • an welchen Orten
  • zu welcher Zeit zur Bezeichnung
  • welcher Konzepte verwendet?

Da die Dimension des Raumes einen der zentralen Faktoren darstellt, sammelt VerbaAlpina ausschließlich Sprachmaterial mit Georeferenzierung, wie dies etwa in Sprachatlanten oder in manchen Wörterbüchern vorliegt.

Der Rahmen der räumlichen Dimension ist von VerbaAlpina durch das Perimeter der sog. Alpenkonvention abgesteckt. Die Alpenkonvention ist ein völkerrechtlicher Vertrag der Alpenanrainerstaaten. Das Perimeter ist eine von dieser Organisation gezogene Grenze, die die Ausdehnung der Alpen administrativ definiert. VerbaAlpina orientiert sich aus rein pragmatischen Gründen an dieser Grenze, da eine klare Abgrenzung des Untersuchungsgebiets  organisatorisch unerlässlich und anders kaum möglich ist. Allerdings bedingt die gewählte Definition des Untersuchungsgebiets gewisse Asymmetrien, wie etwa die Tatsache, dass das Schweizerische Emmental, berühmt für seinen Käse, außerhalb der Alpenkonvention liegt und daher nicht von VerbaAlpina erfasst wird, obwohl diese Region in wirtschaftlicher wie auch naturräumlicher Hinsicht sehr wohl zum Alpenraum gerechnet werden könnte.

Innerhalb des Untersuchungsgebiets stellen für VerbaAlpina die politischen Gemeinden das zentrale Referenzsystem dar: Sämtliches gesammeltes und georeferenziertes Sprachmaterial wird auf das Raster der politischen Gemeinden bezogen. Bei großflächigen Verbreitungsangaben wie etwa „Tessin“ oder „Vorarlberg“ werden die entsprechenden Sprachbelege auf sämtliche Gemeinden dieser Regionen übertragen. Ausgehend von der feinen Granulierung der politischen Gemeinden kann das Sprachmaterial bei späteren Analysen nach übergeordneten politischen Einheiten wie etwa Kantonen, Départments, Regierungsbezirken oder Regionen gruppiert und auf einer Karte visualisiert werden.

Ein wenig problematisch ist aus Sicht von VerbaAlpina die Dimension der Zeit, da das Datennetz im Hinblick auf die chronologische Streuung bislang noch sehr dünn und bezogen auf den gesamten Alpenraum unausgewogen ist. Manche der von VerbaAlpina ausgewerteten Quellen geben den Zeitpunkt der Erhebung eines Einzelbelegs sehr exakt, manchmal sogar tagesgenau, an, bei anderen Quellen liefert das Jahr der Publikation lediglich einen Terminus ante quem für die darin erfassten Sprachdaten.

Das Datenmaterial von VerbaAlpina erhält historische Tiefe durch die Verklammerung der aus den Quellen geschöpften Wörter durch die Feststellung von Gemeinsamkeiten bezüglich der lexikalischen Basis. So besitzen französisch salamandre, italienisch salamandra und deutsch Salamander dieselbe lexikalische Basis. Hier einen historischen Zusammenhang zu vermuten, liegt nahe. Es lässt sich jedoch nicht ohne weiteres entscheiden, ob z.B. das deutsche Wort aus einem der beiden romanischen Wörter hervorgegangen ist (Entlehnungsszenario), oder ob alle drei Varianten unabhängig von einander auf einen gemeinsamen Vorläufer zurückzuführen sind. Um dennoch erfassen zu können, *dass* zwischen den drei genannten Wörtern ein Zusammenhang besteht, identifiziert VerbaAlpina in solchen Fällen einen lexikalischen Vorläufer aus einer früheren im Alpenraum verbreiteten Sprache und weist diesen den modernen Wörtern zu. VerbaAlpina bezeichnet solche Vorläufer als „Basistypen“. Im Fall des Beispiels wäre dies das lateinische salamandra.

Der Grund für diese Vereinfachung ist ein doppelter: Zum einen ist vielfach nicht zu entscheiden, welche der genannten Varianten im Einzelfall vorliegt, zum anderen sind entsprechende Recherchen unter Umständen sehr aufwendig, so dass sie im Rahmen des Projekts aus Zeitgründen nicht betrieben werden können. Die VA-Basistypen haben den großen Vorteil, dass sie offenkundig bestehende Zusammenhänge datentechnisch abbilden lassen, *ohne* zur Spezifizierung der Zusammenhänge im einzelnen zu zwingen.

Die zentrale Bezugsgröße von VerbaAlpina sind die sog.morpholexikalischen Typen„, im folgenden kurz „Morphtypen“ genannt. Dabei handelt es sich um lexikalische Einheiten, die bezüglich ihrer Sprachfamilienzugehörigkeit, ihrer Schreibung, des Genus und der Frage, ob sie eine Affigierung aufweisen oder nicht, distinkt, also unverwechselbar sind. Insofern entsprechen die Morphtypen in etwa den Lemmata der traditionellen Wörterbücher. Dabei handelt es sich ganz überwiegend um Nomina, Verben spielen bei VerbaAlpina bislang eine untergeordnete Rolle.

Bei der Typisierung orientiert sich VerbaAlpina zunächst an sog. Referenzwörterbüchern. Sofern in diesen Wörterbüchern ein passender Eintrag vorhanden ist, wird dieser den ausgewählten Tokens zugewiesen. Existiert der Typ in mehreren Referenzlexika, erfolgen Mehrfachzuordnungen. Sollte ein Morphtyp in keinem Referenzlexikon vorhanden sein, erzeugt VerbaAlpina einen eigenen, neuen Morphtypen, der dann zugewiesen wird.

Für die aus Sprachatlanten und Wörterbüchern erfassten Daten muss jeweils im Einzelfall entschieden werden, welchen Morphtypen sie repräsentieren. Eine automatische Zuweisung erscheint unmöglich. Für die manuelle Typisierung hat VerbaAlpina ein eigenes Tool entwickelt, in dem die transkribierten und anschließend tokenisierten Äußerungen Morphtypen zugeordnet werden können.

VerbaAlpina verzichtet bewusst auf die Zuweisung der Morphtypen zu Einzelsprachen oder gar Dialekten. Der Grund ist, dass sich Sprachlandschaften und so auch der Alpenraum grundsätzlich als Kontinua darstellen, innerhalb derer klare Abgrenzungen praktisch unmöglich sind. Streng genommen kann jede Ortschaft ihren eigenen Dialekt besitzen. Bei der Definition der Morphtypen erfolgt daher lediglich die Zuweisung zu einer der drei im Alpenraum vorhandenen Sprachfamilien. Die Zuordnung zu einer Sprachfamilie wird dabei von den Quellen vererbt, aus denen die Belege stammen, die dem jeweiligen Morphtypen angehören.

Die phonetische Dimension wird von VerbaAlpina weitgehend ausgeblendet, ist im Datenmodell von VerbaAlpina jedoch abbildbar und punktuell im Datenbestand auch schon präsent.

Die Entwicklung der Sprache im Raum ist stets mehr oder minder stark beeinflusst von einer ganzen Reihe dynamischer Prozesse. Dazu gehören etwa Wanderungsbewegungen, Verdrängungen, Landnahmen, der Wandel von Wirtschaftsformen oder auch der klimatischen Rahmenbedingungen. Aus diesem Grund sammelt VerbaAlpina – allerdings unsystematisch und selektiv – auch nicht-sprachliche Daten, die die genannten Phänomene dokumentieren. Als Beispiel können Daten zu archäologischen Fundstätten der Völkerwanderungszeit oder auch die Informationen zu Verkehrswegen und Ortschaften genannt werden, die der Tabula Peutingeriana entnommen werden können. Auch die Daten dieser außersprachlichen Peripherie müssen georeferenzierbar sein. VerbaAlpina bietet den Nutzern die Möglichkeit, diese Daten in Beziehung zur Verbreitung sprachlicher Phänomene zu setzen und auf diese Weise historische Zusammenhänge sichtbar werden zu lassen.

Technical Aspects

VA-Tools

VerbaAlpina setzt nach Möglichkeit weit verbreitete Standardsoftware ein, die außerdem open source sein muss. Im Wesentlichen handelt es sich um das Datenbankmanagementsystem (DBMS) MySQL zur Verwaltung des zentralen Datenbestands sowie um das PHP-Framework WordPress. Für die spezifischen Anforderungen des Projekts wurden jedoch überwiegend auf den genannten Basistechnologien aufbauende Tools entwickelt, die allesamt auf Github zur freien Nachnutzung unter der CC-BY-SA-Lizenz verfügbar sind (https://github.com/VerbaAlpina?tab=repositories).

Der VA-Betacode und das VA-Tanskriptionstool

Betacode

Für die Transkription von „exotischen“ Schriftsystemen, wie sie häufig gerade in Sprachatlanten anzutreffen ist, setzt VerbaAlpina ein Verfahren ein, das bereits in den 1970er Jahren für den Thesaurus Linguae Graecae (TLG) entwickelt und erfolgreich eingesetzt worden war. Im Kern geht es darum, beliebige Schriftzeichen durch definierte und dokumentierte Sequenzen von ASCII-Zeichen zu ersetzen. Die Regeln folgen möglichst einfachen und mnemotechnisch günstigen Mustern. So wird z.B. ein Akut auf einem Basiszeichen durch einen Slash hinter dem Basiszeichen transkribiert.

Die Äußerung1

wird gemäß den Transkriptionsregeln folgendermaßen transkribiert:

la lac/a/

Dabei spielt der mit einem Zeichen bezeichnete Lautwert keine Rolle. Das bedeutet auch, dass identische Zeichen wie z.B. der Akut vollkommen unabhängig von der transkribierten Vorlage und der möglicherweise spezifischen phonetischen Bedeutung stets gleich, nämlich mit einem nachgestellten Slash transkribiert wird. Erst ein vorlagenspezifisches Konvertierungsverfahren, bei dem sämtliche Transkriptionen in das IPA-System übertragen werden, berücksichtigt die Lautwerte der ursprünglichen Quelle.

Diese Methode besitzt gleich mehrere Vorteile:

  • Es ist die Transkription von Zeichen möglich, die bislang noch nicht unicode-kodiert sind
  • Die Transkription kann bequem mit Standardtastaturen und ohne komplizierte Tastenkombinationen erfolgen
  • Die Transkriptoren benötigen keine Kenntnisse über die Bedeutung der Zeichen
  • Die Transkriptionen sind – anders als Multi-Byte-Characters von UTF-8 – technisch robust gegen ungewollte Veränderung
  • Die Transkription erfolgt ohne Informationsverlust (was z.B. der Fall wäre, wenn anstelle des vorliegenden Böhmer-Ascoli-Systems direkt in IPA transkribiert werden würde, da IPA keine so feine Unterscheidung hinsichtlich der Einzellaute erlaubt wie Böhmer-Ascoli)

VA-Transkriptionstool

Speziell die automatische strukturierte Erfassung von lexikalischem Material aus Sprachatlanten stellt ein erhebliches technisches Problem dar. Dabei geht es nicht um die Verwandlung der, wie wir am Beispiel des AIS gesehen haben, teils exotischen Schriftsysteme, die dort bisweilen Verwendung finden. OCR-Programme wie z.B. Abbyy Finereader lassen sich so trainieren, dass sie auch solche Schriftsysteme korrekt erfassen und sogar den VerbaAlpina-spezifischen Betacode produzieren.

Im Fall der Sprachatlanten der romanistischen Tradition besteht die eigentliche Schwierigkeit darin, die direkt auf der Karte eingetragenen Äußerungen jeweils der richtigen Nummer zuzuordnen. Maschinen sind mit dieser Aufgabe immer dann überfordert, wenn die Eintragungen auf der Karte zu dicht beieinander liegen, wie dies z.B. im AIS im Bereich der Südschweiz und dem angrenzenden Italien der Fall ist. Am Institut für Informatik der LMU ist soeben eine Masterarbeit abgeschlossen worden, die eine algorithmische Lösung für dieses Problem entwerfen sollte. Dabei wurde u.a. mit Deep-Learning-Verfahren gearbeitet. Soweit VerbaAlpina es einschätzen kann, ist aber auch auf diesem Wege kein Erfolg in Sicht. Von einer technischen Verfügbarkeit eines entsprechenden Tools kann auf keinen Fall die Rede sein.

Aus Sicht der automatischen Datenerfassung noch komplizierter erscheinen die im Bereich der Germanistik verbreiteten Sprachatlanten mit Punktsymbolkarten, bei denen bestimmte Merkmalsausprägungen als Symbole auf der Karte dargestellt werden. Anders als bei den romanistischen Atlanten werden hier auch zumeist typisierte Daten abgebildet, konkrete Einzelbelege der Informanten werden nur in Ausnahmefällen präsentiert.

Punktsymbolkarte germanistischer Tradition (VALTS IV 73: Die SENNHÜTTE)

Die strukturierte Erfassung der Daten aus diesen Sprachatlanten kann also nur manuell erfolgen. Das Problem dabei besteht dann wiederum darin, dass die konsistente fehlerfreie Datenerfassung ein hohes Maß an Konzentration und Disziplin erfordert. Zur Erleichterung dieser Arbeit, und um die Fehleranfälligkeit zu verringern und außerdem ein möglichst systematisches Vorgehen zu gewährleisten, hat VerbaAlpina ein spezielles Transkriptionstool entwickelt.

Das VA-Transkriptionstool

Das Tool integriert einen Scan der zu transkribierenden Karte in das Formular, in das die Transkriptionen eingetragen werden. Bereits transkribierte Karten werden entsprechend farblich markiert, und auch die Doppelerfassung einzelner Eintragungen auf der Karte werden vom System verhindert. Dem Transkriptor werden vom System nacheinander die Nummern oder Siglen der Ortspunkte auf der Karte vorgegeben. Die Transkription erfolgt dann in das dafür vorgesehen Feld des Formulars. Die anderen Parameter wie Kartennummer, Ortspunktnummer und Konzeptzuweisung sind vom System jeweils vorgegeben und werden gemeinsam mit der Transkription in der Datenbank abgespeichert. Die Eingabemaske präsentiert in einem Teilfenster rechts oben die allgemeinen Transkriptionsregeln für die Datenerfassung im Betacode, so dass der Transkriptor sie mit möglichst geringem Aufwand konsultieren kann. Zur Kontrolle für den Transkriptor wird rechts vom Eingabefeld simultan mit der Transkription die Originalschreibweise der Vorlage eingeblendet.

Crowdsourcingtool

Der von VerbaAlpina aus Sprachatlanten und Wörterbüchern zusammengetragene Datenbestand weist in mehrfacher Hinsicht Inkonsistenzen auf. Diese ergeben sich z.B. dadurch, dass die Sprachatlanten, die jeweils nur einen Teil des Alpenraums abdecken, nicht alle dieselben Konzepte dokumentieren, wie dies die folgende Abbildung ersichtlich macht:

[Screenshot]

In der Folge liegen also für eine bestimmte Region Bezeichnungen für Konzepte vor, die an anderer Stelle gar nicht abgefragt wurden – was nicht heißt, dass diese dort nicht existieren.

Die Durchführung von Nacherhebungen vor Ort ist nicht durchführbar. Daher setzt VerbaAlpina die Idee des Crowdsourcings ein, um den Datenbestand zu arrondieren. Die Idee ist, dass User im Internet bislang nicht dokumentierte Bezeichnungen für ausgewählte Konzepte beisteuern. Zu diesem Zweck hat VerbaAlpina ein spezielles Crowdsourcing-Tool (CS-Tool) entwickelt. Die Funktionalität ist bewusst simpel gehalten, um potentielle „Crowder“ nicht abzuschrecken.

Jeder „Crowder“ wird zu Beginn gefragt, welchem Dialekt seine Beiträge zuzuordnen sind. Anschließend muss er auf einer Karte einen Ort auswählen und gibt dann nach seiner Meinung an diesem Ort gebräuchliche Bezeichnungen für ausgewählte Konzepte ein. Das auf diese Weise gesammelte Material wird von VerbaAlpina ebenso typisiert wie die Daten aus Atlanten und Lexica. Eine Validierung des Crowd-Materials ist rein theoretisch durch das Prinzip der Fremdbestätigung möglich (Motto: Einmal ist kein Mal, zweimal ist immer), wird aktuell von VerbaAlpina aber nicht durchgeführt, nicht zuletzt, weil die Datenmenge bislang noch zu gering ist.

Die Erfahrung der vergangenen Jahre hat gezeigt, dass die Vitalität des Croudsourcing-Tools, also die Menge der Eintragungen, ganz entscheidend von entsprechenden Werbeaktivitäten abhängt. Nach Medien-Berichten über VerbaAlpina und sein Crowdsourcing-Tool oder entsprechende Propaganda in den sozialen Medien, steigen die Eintragungen jeweils stark an, sinken jedoch bald wieder ab.

Auch das CS-Tool kann unter der CC-BY-SA-Lizenz nachgenutzt werden.

Kartentool

Gleichsam das Schaufenster des Projekts bildet die interaktive Online-Karte. Sie ist als der zentrale Datenzugriffspunkt für die Öffentlichkeit konzipiert, der die Abbildung der Sprachdaten in der Dimension des Raums ermöglicht und somit Zusammenhänge offenbaren kann, die bei Betrachtung der Daten in Tabellen- oder Listenform häufig verborgen bleiben.

Die digitale Karte bietet sowohl die Möglichkeit, auf den Datenbestand aus der Perspektive der Wörter zuzugreifen, also sich die verschiedenen Konzepte kartieren zu lassen, die mit einem bestimmten Wort bezeichnet werden können, wie auch die Option, die umgekehrte Frage zu stellen: Welche Konzepte werden wo mit welchen Wörtern bezeichnet. Im traditionellen Publikationswesen konnten diese beiden Perspektiven nur durch zwei unterschiedliche Genera bedient werden: Den Sprachatlas und das Wörterbuch. Die digitale Online-Karte bietet sogar die Möglichkeit, beide Perspektiven synoptisch zu kartieren.

Die Karte bietet im wesentlichen zwei unterschiedliche Formen der Visualisierung an. Standard ist die qualitative Kartierung, bei der die Einzeldaten gebündelt nach politischen Gemeinden zunächst durch Symbole auf der Karte abgebildet werden. Das nachfolgende Beispiel zeigt die Kartierung der Verbreitung des romanischen Worttyps malga, gruppiert nach dessen regional unterschiedlichen Bedeutungen:

https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=191&tk=2414

Ein Klick auf die Kartensymbole öffnet ein Info-Window, in dem die zugrundeliegenden Sprachdaten präsentiert werden. Neben der Quelle werden auch das mit dem Wort bezeichnete Konzept, der Basistyp sowie der Einzelbeleg der jeweiligen Quelle in IPA-Transkription angezeigt. Die umrahmten Buchstaben hinter Morph- und Basistypen verweisen auf die entsprechenden Einträge in den Referenzwörterbüchern und sind z.T. interaktiv; ein Klick auf das Symbol führt dann direkt zum entsprechenden Eintrag im Referenzwörterbuch. In das Info-Window sind außerdem Normdaten eingebunden und entsprechend verlinkt. So führt ein Klick auf das Erdkugelsymbol neben oder unter dem Gemeindenamen auf die entsprechende Seite von Geonames, die Konzeptnamen sind mit den Einträgen bei Wikidata verknüpft.

Neben der qualitativen Kartierung bietet VerbaAlpina auch eine quantifizierende Darstellung an. Ein Klick auf das Q im Kreis neben dem Menüpunkt „Flächen und Regionen“ kumuliert die im Moment kartierten Elemente nach Regionen und färbt diese entsprechend der Anzahl der dort kartierten Elemente unterschiedlich ein. In der Grundeinstellung bilden die großräumigen Sprachgebiete den Referenzrahmen. Durch entsprechende Auswahl über den Menüpunkt „Flächen und Regionen“ kann die Kumulierung und Kartierung der Daten auch auf Basis kleinerer administrativer Einheiten erfolgen.

Neben der realitätstreuen Abbildung der geographischen Grenzverläufe kann die quantifizierende Darstellung auch auf der Grundlage einer Hexagonkarte erfolgen. Bei dieser Art der Kartendarstellung werden die geographischen Einheiten durch Hexagone mit jeweils identischer Größe dargestellt. Dadurch werden visuelle Verzerrungseffekte vermieden, die sich durch die in der Realität stark von einander unterscheidenden Flächengrößen ergeben. Natürlich ergibt sich bei dieser Art der Kartierung wiederum der Nachteil, dass die geographische Anordnung der Flächen und vor allem die Anzahl angrenzender Flächen in den meisten Fällen nicht mehr der Realität entspricht. Der Mehrwert besteht sicherlich in der Möglichkeit, zwischen den verschiedenen Kartierungsvarianten wechseln zu können und auf diese Weise einen annähernd objektiven Eindruck gewinnen zu können.

Das Teilensymbol am rechten oberen Rand der Karte erlaubt den Abruf eines persistenten Links, der stabil auf die aktuelle Kartenansicht verweist und z.B. über Mails versandt oder in Texte eingesetzt werden kann. Außerdem können ganz bestimmte Kartenansichten mit einer spezifischen Art und Anzahl von ausgewählten Daten als synoptische Karten unter einem frei wählbaren Namen gespeichert und mit einem ausführlichen Kommentar versehen werden. Anschließend erscheinen diese Karten im Menü „synoptische Karte“. Allerdings ist diese Funktion registrierten Benutzern vorbehalten.

Die Realisierung der Online-Karte basiert auf modernster Graphiktechnologie (WebGL) und ist extrem leistungsfähig. Sichtbar wird diese Leistungsfähigkeit vor allem bei Zoom-Vorgängen mit einer großen Anzahl von Kartensymbolen und Grenzverläufen, die dem Computer eine hohe Rechenleistung abverlangen. Der Einsatz von WebGL erlaubt die erforderlichen Berechnungen auf dem Prozessor der Graphikkarte, was den entscheidenden Leistungsgewinn mit sich bringt.

Vernetzung und Nachhaltigkeit

Zugriffsmöglichkeiten von außerhalb

Der Zugriff auf die Daten von VerbaAlpina ist auf verschiedene Weise möglich:

  • Über das im Internet frei zugängliche Projektportal und dort vor allem über die interaktive Online-Karte und das Lexicon alpinum
  • Über die, ebenfalls frei zugängliche, API
  • Über die PMA-Schnittstelle der MySQL-Datenbank

Die API erlaubt den Download des sprachlichen Kernmaterials in einer Reihe unterschiedlicher Formate und in unterschiedlicher Aggregierung. Der Zugriff über die PMA-Schnittstelle ist den offiziellen Kooperationspartnern von VerbaAlpina vorbehalten. Die PMA-Schnittstelle erlaubt Datenanalysen unter Einsatz der Sprache SQL.

Der Kerndatenbestand von VerbaAlpina ist sehr fein granuliert und die Einzelelemente sind mit persistenten Identifikatoren eindeutig identifiziert und somit präzise ansprechbar. Letztlich erfüllen diese alphanumerischen Identifikatoren die Funktion von VerbaAlpina-spezifischen Normdaten. Konkret erhalten unter anderem alle Morphtypen, Konzepte und politischen Gemeinden eine eindeutige Nummer, unter deren Verwendung dann auf unterschiedlichen Wegen auf die spezifischen Daten zugegriffen werden bzw. von externer Seite darauf referenziert werden kann. Identifikatoren der Morphtypen tragen das Präfix L, Konzepte C und Gemeinden A. Die ID L1435 steht beispielsweise für den Morphtypen „babeurre (m.) (roa.)“. Die Adresse db=191&single=L1435″ target=“_BLANK“>https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=133&db=191&single=L1435 ruft sodann eine Kartierung der Verbreitung dieses Morphtyps auf, der Link version=191&format=xml&empty=0″ target=“_BLANK“>https://www.verba-alpina.gwi.uni-muenchen.de/?api=1&action=getRecord&id=L1435&version=191&format=xml&empty=0 führt zum Download der zu diesem Morphtyp gespeicherten Daten im XML-Format und der Link db=191#L1435″ target=“_BLANK“>https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=2374&db=191#L1435 schließlich auf den Kommentar im Lexicon Alpinum (sofern vorhanden).

Mit wenigen Ausnahmen enthalten alle URLs, die sich auf Inhalte von VerbaAlpina beziehen, einen – in den Beispielen von gerade eben rot markierten – Parameter, der sich auf eine ganz bestimmte Version von VerbaAlpina bezieht. Die beiden ersten Ziffern stehen jeweils für das Jahr, die letzte für Versionsnummer im Jahr (191: Erste Version im Jahr 2019). Während der Datenbestand der Arbeitsversion, die an der Zeichenfolge xxx erkennbar ist, permanenten Änderungen unterliegt, sind die Inhalte der anderen Versionen jeweils stabil. Dadurch ist sichergestellt, dass Verweise auf diese URLs stets dieselben Inhalte aufrufen und Zitationssicherheit gewährleistet ist. Die Versionierung der VerbaAlpina-Daten erfolgt zweimal im Jahr, jeweils zu Jahresmitte und zu Jahresende. Auf der Homepage ist die Auswahl zwischen den vorhandenen Versionen möglich. Für alle Inhalte von VerbaAlpina sind auch DOIs verfügbar.2

Demnächst werden die VerbaAlpina-Daten auch in das RDF-Schema des Semantic Web übertragen. Die Einrichtung eines SPARQL-Endpoints ist jedoch zunächst nicht vorgesehen; die entsprechende Umsetzung ist mit einigem Aufwand verbunden und erscheint entbehrlich, da es eine Reihe anderer Zugriffsmöglichkeiten auf die VerbaAlpina-Daten gibt. Immerhin erfüllt VerbaAlpina die Kriterien der „Linguistic linked open data“-Bewegung (LLOD; http://linguistic-lod.org/).3, und die VerbaAlpina-Daten werden bald auch in die LLOD-Cloud eingebunden sein.4

Verknüpfung mit externen Ressourcen

VerbaAlpina verknüpft die drei Kernkategorien seines Datenbestands über die Einbindung geeigneter Normdaten mit externen Datenbeständen.

Im Fall der Morphtypen werden entsprechende Verbindungen zu den Referenzlexika hergestellt. Ein interessanter Nebeneffekt ist, dass dabei die unterschiedliche Eignung der entsprechenden Ressourcen deutlich wird. Im Sinne maximaler Interoperabilität sind bislang die Inhalte nur weniger der von VerbaAlpina erfassten Referenzwörterbücher adressierbar. Positive Beispiele wären etwa das Portal des Centre National de Ressources Textuelles et Lexicales ([Bibl:CNRTL]) oder die italienische Treccani, die jeweils transparente URLs für jeden lexikalischen Eintrag anbieten (z.B.:  https://www.cnrtl.fr/definition/beurre, http://www.treccani.it/vocabolario/burro/). In manch anderen Fällen sind Referenzierungen entweder nur mit großer Ungenauigkeit oder auch gar nicht möglich. Nicht selten begegnet man dem Phänomen, dass sich die Adressierbarkeit der Inhalte noch an der herkömmlichen Seitenlogik des Buchdrucks und auf PDF-Dokumente oder Bilddateien bezieht. Dies ist etwa der Fall beim Französischen etymologischen Wörterbuch, ursprünglich von Walter Warburg (FEW).

Für die Konzepte verweist VerbaAlpina bislang ausschließlich auf die sog. Wikidata-Datenobjekte. Jedem Konzept ist in der VerbaAlpina-Datenbank die jeweilige Q-ID der Wikidata zugeordnet. Der entsprechende Link führt auf die Datenobjektseite bei Wikidata. Dort wiederum befinden sich Links zu den Artikeln in den verschiedensprachigen Wikipedien zu diesem Konzept. Bereits erwähnt wurde die Verknüpfung mit den Normdaten von geonames. Links für alle Normdaten der genannten Kategorien werden dem Nutzer in den Info-Windows auf der Online-Karte präsentiert.

Some organizational stuff

VerbaAlpina started in 2014 and is funded by the German Research Foundation (DFG) with a perspective until 2025. The individual project terms comprise 3 years each. At the moment we are heading towards the last year of the second term and are about to prepare the application for the funding of the third term.

Der Mitarbeiterstab ist zweigeteilt: Es gibt drei Sprachwissenschaftler und zwei Informatiker, die jeweils noch von Hilfskräften unterstützt werden. Unter den Sprachwissenschaftlern befinden sich zwei Romanisten und ein Germanist, von den Informatikern ist einer hauptsächlich für alle Belange der Kerndaten zuständig (Datenmodellierung, Schnittstellen, u.a. API), der andere überwiegend für alle Fragen der Visualisierung, hauptsächlich die interaktive Online-Karte.

VerbaAlpina stellt somit ein interdisziplinäres DH-Unternehmen mit Anteilen in den klassischen Geisteswissenschaften und in der Informatik dar. Der informatische Teil ist an der IT-Gruppe Geisteswissenschaften (ITG) angesiedelt. Diese Einrichtung besteht seit dem Jahr 2000, wird getragen von den sechs geisteswissenschaftlichen Fakultäten der LMU und besitzt eine unbefristete Existenzperspektive. Die ITG ist zuständig für Planung und Betrieb der IT-Infrastruktur im Bereich der Humanities. Einen stetig wachsenden Aufgabenbereich der ITG stellt die Unterstützung bei Planung und Durchführung von DH-Projekten dar. VerbaAlpina stellt aus Sicht der ITG also nur eines von zahlreichen Projekten dar, dessen Projektdaten im Kontext eines heterogenen, jedoch einheitlich – nämlich relational – strukturierten Gesamtdatenbestand verwaltet werden. Dieser im Lauf der Jahre auf beachtliche Größe und Vielfalt angewachsene Datenpool bietet zumindest theoretisch die Perspektive der Datenanalyse über Projektgrenzen hinweg. Vor diesem Hintergrund entwickelt sich zur Zeit eine Kooperation der ITG mit dem Master-Studiengang Data Science, der Anfang 2017 ins Leben gerufen wurde.

Die ITG spielt auch im Hinblick auf die Nachhaltigkeit der von VerbaAlpina erarbeiteten Ergebnisse eine wichtige Rolle. Nach dem Ende der Projektförderung wird die ITG das Projektportal im Rahmen ihrer Möglichkeiten weiter betreiben und das für den Betrieb erforderliche Minimum an Wartungsarbeit leisten.


* Given at the colloqium „NEW WAYS OF ANALYZING DIALECTAL VARIATION“, held at Sorbonne University, Paris, 21-23 November 2019


  1. AIS 1218_1, 129 

  2. Fragezeichen und Ampersands (&) müssen dabei durch den jeweiligen Hexadezimalwert des Zeichens in der Unicode-Tabelle (<strong><span style="color: #ff0000;">? = 3f</span></strong>, <span style="color: #339966;"><strong>& = 26</strong></span>) mit vorangestelltem % ersetzt werden. Die <span class="vaabr" data-vaabr="DOI">DOI</span> der URL <a href="https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=133&db=191&single=L1435">https://www.verba-alpina.gwi.uni-muenchen.de/<strong><span style="color: #ff0000;">?</span></strong>page_id=133<strong><span style="color: #339966;">&</span></strong>db=191<strong><span style="color: #339966;">&</span></strong>single=L1435</a> liest sich wie folgt: <a href="https://dx.doi.org/10.5282/verba-alpina?urlappend=/%3fpage_id=133%26db=191%26single=L1435">https://dx.doi.org/10.5282/verba-alpina?urlappend=/<strong><span style="color: #ff0000;">%3f</span></strong>page_id=133<strong><span style="color: #339966;">%26</span></strong>db=191<strong><span style="color: #339966;">%26</span></strong>single=L1435</a> 

  3. <span class="vaabr" data-vaabr="SDOT">S.</span> Chiarcos, Christian; McCrae, John; Cimiano, Philipp; Fellbaum, Christiane (2013). Towards open data for linguistics: Lexical Linked Data (<a href="https://www.springer.com/cda/content/document/cda_downloaddocument/9783642317811-c1.pdf" target="_BLANK">PDF</a>). Heidelberg, in: Alessandro Oltramari, Piek Vossen, Lu Qin, and Eduard Hovy (Hrsgg.), New Trends of Research in Ontologies and Lexical Resources. Springer. 

  4. Die Erzeugung der RDF-Struktur wird derzeit vorbereitet. Die Registrierung erfolgt anschließend unter der Adresse <a href="https://lod-cloud.net/add-dataset" target="_BLANK">https://lod-cloud.net/add-dataset</a> 

VerbaAlpina II: Technische Aspekte (im Rahmen der Ringvorlesung „Einblicke in digitale sprachwissenschaftliche Forschungsprojekte“) (Zitieren)

Stephan Lücke
(2583 Wörter)


Gliederung

  • Einführung
  • Datenerfassung
  • Ergebnis der systematischen Datenerfassung
  • Crowdsourcing (CS)
  • VerbaAlpina und FA*I*Rness
  • Die reine Technik
  • IT-Team von VerbaAlpina

Einführung

  • Ergänzung des Vortrags von Thomas Krefeld, der VerbaAlpina als geolinguistisches Vorhaben um Umfeld der Digital Humanities vorgestellt und den Fokus auf VerbaAlpina als „virtueller Forschungsumgebung“ gelegt hatte.
  • Kernfrage: Welche Dinge werden wo mit welchen Wörtern bezeichnet?
  • Fundamental: Unterscheidung zwischen Bezeichnung und KONZEPT, im Folgenden (und generell in Texten außerhalb der Datenbank) markiert durch unterschiedliche Typographie (Bezeichnung kursiv, Konzept in Versalien) ⇒

Butter ≠ BUTTER

  • Geographischer Rahmen: Alpenraum (Perimeter der Alpenkonvention [= völkerrechtlicher Vertrag zum Schutz der Alpen aus dem Jahr 1991] – rein pragmatische Entscheidung, aus der Perspektive der Operationalisierbarkeit unverzichtbar)
  • Geographische Referenz sind für VerbaAlpina die politischen Gemeinden im Alpenraum. Festgelegter Bestand, administrative Veränderung (Schaffung neuer Gemeinden, Fusion etc.) werden nicht berücksichtigt. Insgesamt 5771 Gemeinden ([[SQL:SELECT COUNT(*) AS Anzahl FROM orte a JOIN orte_kategorien b USING(id_kategorie) WHERE a.Alpenkonvention = 1 AND b.Id_Kategorie = 62]]; Karte)
  • Datenbasis:
    • Sprachatlanten
    • Wörterbücher
    • ergänzt um Daten der „Crowd“ (sog. Crowdsourcing)
  • Digitalisierung“ erfolgt grundsätzlich über eine Reihe aufeinander folgender Ebenen:

Allgemeines Digitalisierungskonzept für Textquellen


Datenerfassung

  • Datenerfassung: Transkription aus Sprachatlanten und Wörterbüchern
  • Sprachatlanten: onomasiologisch („Welche Bezeichnungen gibt es z. B. für ein bestimmtes Konzept?“):

FLÜSSIGKEIT NACH DER GERINNUNG DER FESTSTOFFE BEI DER HERSTELLUNG VON KÄSEMolke, Abzug, Jutte, Käsemilch, kweta, petit-lait

  • georeferenzierte (!) Wörterbücher: semasiologisch (Welche Konzepte bezeichnet z. B. das Wort malga?)

Gaden (germanisch, Substantiv, männlich, nicht-affigiert) ⇒ DACHKAMMER, RAUM ZUM LAGERN VON MILCHPRODUKTEN, SCHEUNE, SCHLAFRAUM, STALL (Auswahl)

Beispiel Sprachatlanten

  • Sprachatlanten bislang quantitative Hauptquelle für VerbaAlpina
  • Zahlreiche Sprachatlanten im Alpenraum: Karte 

Netz der Sprachatlanten in Zentral- und Westalpen

  • Beispiel: der AIS (Sprach- und Sachatlas Italiens und der Südschweiz, Karl Jaberg, Jakob Jud, 1928-40): Elektronische Version „Navigais“ von Graziano Tisato:

Die Karte 1218 (KÄSEMILCH = MOLKE) des AIS in der online-Präsentation Navigais von Graziano Tisato

  • Die roten Nummern stehen für die Informanten
  • Neben den Nummern stehen Äußerungen, die von den Informanten stammen („Einzelbelege“)
  • Phonetische Transkription im sog. Böhmer-Ascoli-System (ähnlich Teuthonista)
  • Aus dieser Karte muss strukturiert die Information erfasst werden, an welchem Ort das vorgegebene Konzept wie bezeichnet wird. Beispiel:
Konzept Ortspunkt Äußerung
MOLKE 227 laʧ sɛrˈu
MOLKE 225 laj serˈuŋ
  • Die Informanten-Daten werden in einer eigenen Tabelle abgespeichert:
Erhebung Nummer Gemeinde Alter Geschlecht
AIS 225 Mello 25 m
AIS 227 Albosaggia 41 m
  • Alter und Geschlecht werden nicht von allen Sprachatlanten angegeben. In solchen Fällen bleiben die Felder einfach leer.
  • Der AIS liefert jedoch detaillierte Informationen zu den Informanten in den sog.Aufnahmeprotokollen“ (Jaberg/Jud 1928):

Aufnahmeprotokoll des AIS zum Erhebungspunkt 227 (Albosaggia) – Die hier in Frage gestellte Nummer 32 bezieht sich auf die Reihenfolge, in der die Erhebungen durchgeführt worden sind. Qn bezeichnet den „Questionario normale“, also das Standardfragebuch, das hier zum Einsatz gekommen ist (alternativ: Qe [erweitert], Qr [reduziert]). Die erwähnten Fotos sind online verfügbar in der „AIS Datenbank“ der Universität Bern (http://130.92.166.34/fmi/webd/AIS)

  • Auch Daten zu den Gemeinden werden in einer eigenen Tabelle abgespeichert:

(Abfrage: [[SQL:SELECT NAME, round(ST_x(a.Mittelpunkt),2) AS lng, round(ST_y(a.Mittelpunkt),2) AS lat, a.geonames as Geonames_ID FROM orte a WHERE a.Name IN ('Mello (Sondrio)','Albosaggia') AND a.Beschreibung LIKE 'Commune']])

Transkriptionsverfahren

  • Das Problem:

  • Umgang mit Zeichen(kodierung): Böhmer-Ascoli nicht Unicode-kodiert, selbst wenn: Eingabe über Tastatur sehr umständlich, daher Einsatz des:
  • Betacode; Ideengeber: Thesaurus Linguae Graecae (1974)

Prinzip des Betacodes

  • Verfahren ist quellenunabhängig: Identische Zeichen bzw. Zeichenkombinationen (Basiszeichen samt Diacritica) werden stets identisch transkribiert, auch wenn möglicherweise unterschiedliche „Bedeutungen“ vorliegen. Diese werden bei der automatischen Umsetzung in IPA berücksichtigt.
  • Automatische Erfassung der Daten bislang nicht möglich
  • OCR wäre nicht das Problem! ⇒ Lücke/Riepl/Trautmann 2017, S. 126ff.
  • Hauptproblem jedoch: Zuordnung der Belege zu den einzelnen Erhebungspunkten

Ausschnitt aus AIS 1218_1 (KÄSEMILCH)

  • Thema wurde in einer Masterarbeit in der Informatik behandelt (Methoden: „nearest neighbour“ oder „deep learning“). Die Arbeit lieferte kein operationalisierbares Ergebnis; Problem also weiterhin ungelöst.
  • daher manuelle Erfassung der Daten mit dem VA-Transkriptionstool:

VA-Transkriptionstool: Beispiel AIS-Karte 1218_1 „KÄSEMILCH“

  • VA nutzt auch das generische Croudsourcing-Framework Zooniverse: Freiwillige im Netz sollen AIS-Karten transkribieren: https://www.zooniverse.org/projects/filip-hr/verbaalpina
  • Entwickelt mit Hilfe des generischen Entwicklungstools „Zooniverse Project Builders
  • Auslöser war das Zooniverse-Projekt „Old Weather“ – Wetterrekonstruktion aus Logbüchern von Arktis-Fahrern im 19. und 20. Jh.
  • Ursprünglicher Gedanke bei der Nutzung des Zooniverse Project Builders: Zeitersparnis – Arbeit hat sich aber als sehr aufwendig herausgestellt; immer wieder Auflagen und Nachfragen von Seiten Zooniverse. Daher: „…  not yet an official Zooniverse project“
  • Die über VA-Zooniverse ausgeführten Transkriptionen können in csv-Dateien exportiert und von dort in die Datenbank von VerbaAlpina übertragen werden:

  • Bislang erst sehr wenige Transkriptionen, da noch nicht beworben

Typisierung

  • Die Sprachatlanten und Wörterbücher präsentieren unterschiedliche Kategorien von Sprachmaterial. Wir unterscheiden:
    • Einzelbeleg: Konkrete Äußerung eines Sprechers (= Informanten) zu einem ganz bestimmten Zeitpunkt an einem bestimmten Ort. Von der Quelle meist in phonetischer Transkription wiedergegeben.
    • Typisierte Belege: idealisierte Repräsentanten eines an einem Ort oder in einer Region verbreiteten „Typs“ – Typisierung kann unterschiedlichen Kategorien folgen

Schriiner, Schriner, Schreiner (bündelt jeweils individuelle Varianten [Einzelbelege])

      • morpholexikalische Typisierung – Sämtliche Varianten, egal ob Einzelbelege oder Typisierungen, werden zu morhpolexikalischen Typen zusammengefasst:
morphTyp phonTypen
Schreiner Schriiner, Schriner, Schreiner
Schnitzer Schnätzer, Schnätzi
Meister Mäischter
Holzmeister Holzmäischter
Tischmacher ?
Tischler ?

VA ist primär an den morpholexikalischen Typen interessiert, registriert und präsentiert bei Suchergebnissen aber jeweils auch Einzelbelege oder ggf. auch phonetische Typen.

Der [Bibl:AIS] liefert, in bester romanistischer Tradition, jeweils

Beispiel einer Quelle mit Einzelbelegen: AIS

  • Die beiden oben zitierten Belege aus der Karte „KÄSEWASSER“ des AIS unterscheiden sich zwar hinsichtlich der phonetischen Transkription, repräsentieren jedoch beide offenkundig den selben morpholexikalischen Typ (die hier vorgelegte Zuweisung zum Typ „latte serone“ ist exemplarisch und vorerst spekulativ):
Konzept Ortspunkt Äußerung morph_typ
MOLKE 227 laʧ sɛrˈu latte serone
MOLKE 225 laj serˈuŋ latte serone
  • ⇒ sämtliches gesammeltes Material muss typisiert werden
  • Was ist ein morpholexikalischer Typ? ⇒ VerbaAlpina dokumentiert solche und ähnliche Fragen in der Sektion „Methodologie“ (hier: s. v. Typisierung)
  • Arbeit, die nur von Sprachwissenschaftlern geleistet werden kann: Aufgabe der romanistischen und germanistischen Mitarbeiter von VA
  • Nutzung des Typisierungstools (s. auch den Eintrag „Typisierung: Anlegen morpho-lexikalischer Typen“ in der Methodologie):

Die Karte AIS 1218_1 im Typisierungstool von VerbaAlpina

  • Status der in den Quellen versammelten Daten hinsichtlich Typisierung sehr unterschiedlich
  • manche Sprachatlanten liefern bereits typisierte Daten und präsentieren spezifische Einzelbelege der Informanten nur punktuell
  • Beispiel: VALTS (Vorarlberger Sprachatlas)

Karte 73 aus dem Vorarlberger Sprachatlas VALTS IV: SENNHÜTTE bzw. SENNEREIRAUM AUF DER ALPE

  • Diese Karte vereint die Dokumentation mehrerer unterschiedlicher Konzepte (neben SENNHÜTTE und SENNEREIRAUM AUF DER ALPE noch weitere: PRIMITIVE SENNHÜTTE AUF MAIENSÄßEN, SENNKÜCHE, KÄSEKELLER etc.)
  • Präsenz unterschiedlicher morpholexikalischer Typen durch spezifische Symbole markiert (sog.Punktsymbolkarte„; typisch für Sprachatlanten in germanistischer Tradition)
  • rote Symbole markieren morpholexikalische Typen romanischen Ursprungs, schwarze solche deutschen Ursprungs
  • Automatisierung unmöglich; manuelle Datenerfassung durch Spezialisten unerlässlich
  • Beispiel braune Markierung: In der Ortschaft Bichlbach (Erhebungspunkt T6), wird der SENNEREIRAUM INNERHALB DER ALPHÜTTE als Sennküche bezeichnet
  • Abbildung dieser Informationen im relationalen Datenformat:
Konzept Ortspunkt Äußerung morph_typ
SENNEREIRAUM INNERHALB DER ALPHÜTTE T06 ? Sennküche
  • Erfassung von Daten aus Wörterbüchern. Beispiel: [[Bibl:Idiotikon]

Eintrag „Teie“ im Schweizerdeutschen Wörterbuch (Idiotikon)

Gliederung des Eintrags „Teie“ im Schweizerdeutschen Wörterbuch (Idiotikon) nach den Kategorien des VerbaAlpina-Datenmodells

  • relationale Abbildung (exemplarischer Ausschnitt):
Konzept Ortspunkt Äußerung morph_typ
GEBRECHLICHE, BESCHRÄNKTE, SCHWERFÄLLIGE WEIBSPERSON Chur ? Teie

Ergebnis der systematischen Datenerfassung

  • Viele Bezeichnungen für viele Konzepte (m:n-Beziehung), stets georeferenziert (fiktive Tabelle):
Bezeichnung Konzept Gemeinde
malga HERDE Colico
malga ALM Pieve Di Ledro
malga SENNHÜTTE Ossana
muvel HERDE Lantsch/Lenz
pastura HERDE Wolkenstein in Gröden
  • Datenbank ermöglicht doppelte Perspektive: onomasiologisch und semasiologische (traditionell an unterschiedliche Publikationsarten gebunden: Sprachatlanten und Wörterbücher):
  • Relationales Datenmodell erlaubt den Einsatz der relationalen Algebra
  • ⇒ Einsatz der formalen Sprache SQL (structured query language) möglich
  • Beispiel für eine onomasiologische Suche:
select * from tabelle
where Bezeichnung like 'malga';

Ergebnis:

Bezeichnung Konzept Gemeinde
malga HERDE Colico
malga ALM Pieve Di Ledro
malga SENNHÜTTE Ossana
  • Beispiel für eine semasiologische Suche:
select * from tabelle
where Konzept like 'HERDE';

Ergebnis:

Bezeichnung Konzept Gemeinde
malga HERDE Colico
muvel HERDE Lantsch/Lenz
pastura HERDE Wolkenstein in Gröden
  • Die relationale Algebra erlaubt komplexe Berechnungen über dem Datenbestand
  • Beispiel:
/*
 SQL-Statement 
 Finde sämtliche morpholexikalischen Typen, 
 die das Konzept MOLKE bezeichnen, 
 und gib die jeweilige Häufigkeit des morpholexikalischen Typs an
*/

select 
 Name_Konzept as Konzept, 
 typ,
 anzahl

from
(
 select 
  count(*) as Anzahl, 
  a.Name_Konzept, 
  a.Typ 
 from vap_ling_de a
 
 where 
  a.Name_Konzept like 'MOLKE'
  and a.Art_Typ like 'Morph_Typ'
  group by a.Typ
  order by Anzahl desc
) sq
;
  • Weitere Fragestellungen, die mit der relationalen Algebra beantwortet werden können:
    • Welche Konzepte weisen die höchste Varianz lexikalischer Variation auf?
    • Wie hoch ist der Anteil lateinischer Basistypen bezogen auf ausgewählte Regionen innerhalb des Alpenraums?
  • Kartierung: Analytische Ergebnisse können auf der interaktiven online-Karte von VerbaAlpina visualisiert werden

Kartierung des Konzepts MOLKE auf der interaktiven online-Karte von VerbaAlpina

  • Kartierungen können über das „Teilen“-Symbol rechts oben auf der online-Karte dauerhaft gespeichert und durch das Versenden des entsprechenden Links mit anderen geteilt werden
  • Belegfenster, Beispiel:

Beispiel für ein Einzelbelegfenster auf der interaktiven online-Karte von VerbaAlpina

  • Einzelbelegfenster enthält neben Informationen zu Einzelbeleg (links oben), morpholexikalischem Typ und Konzept Verlinkungen auf externe Ressourcen: Geonames (kleiner Globus rechts oben) sowie Referenzlexika (G: Georges; C: CNRTL; T: Treccani; F: FEW)
  • Wichtig für Referenzierung auf externe Ressourcen: Deren feine Datengranulierung – jedes „Datum“ muss präzise über eine URL ansprechbar sein („Interoperabilität„!) ⇒ eine Lehre für VerbaAlpina!
  • Quantifizierungen: spezielle Funktion auf der interaktiven online-Karte:

Quantifizierende Kartierung des morpholexikalischen Typs „Anke“ auf der interaktiven online-Karte von VerbaAlpina

  • Hexagon-Karte:

Abbildung des Vorkommens des morpholexikalischen Typs „Anke“ auf der Hexagonkarte von VerbaAlpina

  • Neben der kartographischen Ergebnispräsentation bietet VerbaAlpina eine textorientierte Version an: das Lexicon Alpinum:

Das Lexicon Alpinum von VerbaAlpina

  • Kommentare zu ausgewählten (!) Konzepten, morpholexikalischen Typen und Basistypen (Basistyp: Gibt den Ursprung eines morpholexikalischen Typs an; nicht notwendig ein „Etymon“ im sprachwissenschaftlichen Sinn)
  • Angabe der VA-spezifischen Normdaten, die die VA-Konzepte und -morpholexikalischen Typen eindeutig bezeichnen.
  • Einträge im Lexicon Alpinum sind über URLs direkt referenzierbar. Beispiel: https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=2374&db=xxx&comment_id=L581#L581 (Morphtyp L581 Anke)
  • Diachrone Streuung des Datenmaterials über mindestens rund 100 Jahre (je nach Alter der Quellen)!

Crowdsourcing (CS)

  • Systematische Erfassung von Daten aus Atlanten und Wörterbüchern ergibt regionale Inkonsistenzen: Nicht für alle Gemeinden im Untersuchungsgebiet liegen Daten für alle Konzepte vor. Schematische Darstellung:
Gemeinde 1

(Atlas I)

Gemeinde 2

(Atlas II)

Gemeinde 3

(Atlas III)

Gemeinde n

(Atlas N)

Konzept A x x x
Konzept B x x
Konzept C x x
Konzept n x x x
  • Sog. „Nacherhebungen“ erforderlich
  • Feldforschung nicht finanzierbar
  • Lösung: Crowdsourcing („Begriff“ erstmals 2006 von Jeff Howe verwendet): „… bezeichnet die Auslagerung traditionell interner Teilaufgaben an eine Gruppe freiwilliger User, z. B. über das Internet“ (Wikipedia)
  • VerbaAlpina hat ein eigenes Crowdsourcing-Tool entwickelt (CS-Tool):

Das Crowdsourcing-Tool von VerbaAlpina

  • Eingabe von Bezeichnungen für auswählbare Konzepte
  • Ergebnis:
Gemeinde 1 Gemeinde 2 Gemeinde 3 Gemeinde n
Konzept A x CS x x + CS
Konzept B x x + CS CS
Konzept C CS x x
Konzept n x CS x + CS x
  • Konzept aus Sicht von VerbaAlpina durchaus erfolgreich:

Monitoring-Webseite für das Crowdsourcing-Tool von VerbaAlpina

  • Bislang über 11000 Eintragungen
  • Erkenntnis: Werbung ist unverzeichtbar
  • Diachrone Asymmetrien bestehen weiterhin bzw. kommen gar hinzu!
  • Andererseits: Dokumentation von Verschwinden bzw. Entstehung von morpholexikalischen Typen
  • Auch das Entstehen neuer Konzepte kann auf diese Weise erfasst bzw. dokumentiert werden (z. B. ELEKTRONISCHE KUHGLOCKE)

VerbaAlpina und FA*I*Rness

  • VerbaAlpina befasst sich derzeit verstärkt mit der Thematik des Forschungsdatenmanagement (FDM): Einbindung in die Projekte eHumanities – interdisziplinär und GeRDI
  • Wesentlicher Aspekt dabei: Gebot der FAIRness (Graphik von Thomas Krefeld):
FAIR principles
Data have to be Findable
Accessible
Interoperable
Reusable
  • Im Fokus: „Interoperabilität„; Beispiele:
  • Als wesentliche Voraussetzung für Interoperabilität erscheinen Normdaten: „normierte“ Datensätze; Normdaten existieren für ganz unterschiedliche Entitäten, z. B. Personen, Geographica oder auch Konzepte

Normdaten für Personen und Geographica

Normdaten für Konzepte

Normdaten für morpholexikalische Typen

  • Für viele Entitäten existieren speziell in der GND bislang noch keine Normdaten, so z. B. für morpholexikalische Typen – schlecht für VerbaAlpina, da morpholexikalische Typen eine der für VA zentralen Kategorien sind.
  • Ansätze allerdings bei Wikidata:  „lexemes“: https://www.wikidata.org/wiki/Wikidata:Lists/lexemes
  • Beispiel: morpholexikalischer Typ „der Käse„: https://www.wikidata.org/wiki/Lexeme:L49797
  • Die entsprechende Nummer wird in der Tabelle der Morphtypen in der DB von VA eingetragen:
  • Einträge können von Usern angelegt werden (evtl. Beispiel formaggio)

Die reine Technik

  • VerbaAlpina ist vollständig „digital“
  • Im wesentlichen zwei Komponenten: Ein multifunktionales (!) Web-Portal (VA_WEB) und eine (relationale) MySQL-Datenbank (VA_DB; in der Realität mehrere, vor allem zwei: eine spezifischen Projektdatenbank und eine WordPress-Datenbank für den Betrieb von VA_WEB)
  • VA_WEB: WordPress-Installation: in PHP programmiert, erweitert um projektspezifische Funktionen, die modular als „Plugins“ realisiert und der Allgemeinheit über Github zur Verfügung gestellt werden.
  • relevante VA-Eigenentwicklungen für VA_WEB:
    • Transkriptionstool
    • Typisierungstool
    • Crowdsourcing-Tool (CS-Tool)
    • SQLtoHTML: Einbindung von Abfrageergebnissen aus MySQL-Datenbank in WordPress-generierte Webseite
  • Responsive Webdesign (Anpassung der Darstellung an verschiedene Endgeräte):

Die VerbaAlpina-Karte auf einem Samsung S7 Display

Technologie der interaktiven online-Karte

  • Openstreetmap:  „Open Data“ gemäß Open Data Commons Open Database Lizenz (ODbL)
  • JS-Bibliothek Leaflet (vergleichbar mit bzw. Ersatz für Google Maps API)
  • WebGL (Web Graphics Library): JS-Programmierschnittstelle, die die Grafikkarte des Clients verwendet, um Visualisierungen hardwarebeschleunigt zu animieren ⇒ Verzögerungsfreie Animation von Markern auf der VA-Karte bei Zoomvorgängen

API


IT-Team von VerbaAlpina

Konzeption und Institutionalisierung des FDM — aus der Erfahrung eines Forschungsprojekts in den digitalen Geisteswissenschaften (Zitieren)

Stephan Lücke
(4356 Wörter)

Vorbemerkung

Der nachfolgende Text stellt die Ausarbeitung des am 28.3.2019 auf den e-Science-Tagen in Heidelberg von Stephan Lücke und Martin Spenger gemeinsam gehaltenen Tandem-Vortrags dar. Der Text ist die Vorlage der in den Kongressakten publizierten Version (PDF-Version), die inhaltlich identisch ist. Abweichungen können höchstens hinsichtlich einzelner Verlinkungen bestehen, weswegen bei Zitaten zwischen den beiden Versionen unterschieden werden muss.


Stephan Lücke (ITG), Martin Spenger (UB der LMU)

Dieser Beitrag zeigt am Beispiel des Forschungsdatenmanagements an der LMU, wie Wissenschafts- und Infrastrukturpartner erfolgreich zusammenarbeiten können. Im Rahmen des Modellprojekts „eHumanities – interdisziplinär“ wird die Zusammenarbeit anhand des Pilotpojekts VerbaAlpina verdeutlicht. Der erste Teil des Aufsatzes beschreibt VerbaAlpina und die Besonderheiten aus der Perspektive der digitalen Geisteswissenschaften. Der zweite Teil bringt als Infrastrukturpartner die Universitätsbibliothek der LMU ins Spiel. Abschließend folgt ein kurzer Überblick über das Projekt „eHumanities – interdisziplinär“.

1. Teil: Das Projekt VerbaAlpina (Stephan Lücke)

Das Projekt VerbaAlpina (VA) ist ein von der DFG gefördertes Langfristvorhaben mit einer Perspektive bis 2025 und befindet sich derzeit in der zweiten Förderphase, die noch bis zum Herbst 2020 andauert.  Es handelt sich um ein interdisziplinäres Projekt im Umfeld der Digital Humanities. Der Schwerpunkt des Interesses liegt auf den Sprachwissenschaften, daneben erfolgt jedoch auch eine intensive und streckenweise exemplarische Auseinandersetzung mit den Herausforderungen der Informationstechnologie. Das von VA zusammengetragene und analysierte Datenmaterial kann darüber hinaus auch für andere Disziplinen wie etwa die Ethnographie, die Archäologie oder auch die Geschichtswissenschaften von Interesse sein. VA betreibt unter anderem eine intensive Methodenreflexion, die hauptsächlich in der Rubrik „Methodologie“ auf der Projektwebseite dokumentiert ist. Zu einigen der im Folgenden thematisierten Punkte finden sie dort ausführlichere Darlegungen, auf die hier generell hingewiesen sei.

Initiatoren und Träger des Projekts sind Thomas Krefeld vom Romanistischen Seminar der LMU sowie Stephan Lücke von der IT-Gruppe Geisteswissenschaften der LMU. In der laufenden zweiten Förderphase verfügt VA über je zwei Doktorandenstellen im Bereich der Sprachwissenschaft (einer zuständig für die Romanistik/Slawistik, der andere für die Germanistik) und in der Informatik (für Datenbank- und Frontendentwicklung). Für die umfangreiche Koordinationsarbeit mit den zahlreichen Projektpartnern steht eine weitere Doktorandenstelle zur Verfügung, deren Inhaberin ihre Doktorarbeit im thematischen sprachwissenschaftlichen Umfeld des Projekts vorbereitet. Unterstützt wird das Team durch eine Reihe von Hilfskräften, die vor allem für die strukturierte Datenerfassung eingesetzt werden.

Vorrangiges Ziel von VA ist die systematische Erfassung und Analyse der im Alpenraum verbreiteten morpholexikalischen Typen, die zur Bezeichnung ausgewählter „Objekte“ (Konzepte, Begriffe) Verwendung finden oder auch fanden. Vereinfacht gesagt, steht dabei die Frage im Zentrum, welche Konzepte an welchen Orten mit welchen Wörtern bezeichnet werden. So wird z.B. das Konzept BUTTER (VA verwendet zur Bezeichnung der Konzepte stets Versalien, um damit den Unterschied zu den Bezeichnungen/Wörtern klar zu machen) in unterschiedlichen Regionen des Alpenraums mit unterschiedlichen morpholexikalischen Typen bezeichnet: In Bayern und Österreich herrscht der Typ Butter vor, im Alemannischen ist Anke weit verbreitet, in Italien nennt man die BUTTER burro. VA ist fokussiert auf die jeweiligen morpholexikalischen Typen, das heißt, phonetische Variationen werden zwar vielfach dokumentiert, jedoch nicht systematisch erfasst oder gar analysiert. Eine vollständige Erfassung des morpholexikalischen Materials ist unmöglich. Daher beschränkt VA seine Dokumentation und Untersuchung auf typisch alpine Konzeptdomänen wie etwa die Almwirtschaft (Schwerpunkt der ersten Projektphase von 2014 bis 2017) oder auch Natur und Umwelt (laufende Projektphase) sowie Tourismus (geplant für die Projektphase ab 2020).

Der geographische Rahmen des Untersuchungsgebiets ist aus pragmatischen Gründen auf die Ausdehnung der sogenannten Alpenkonvention festgelegt worden. Als Datengrundlage dienen in erster Linie traditionell in Buchform publizierte sogenannte Sprachatlanten, die konzeptorientiert („onomasiologisch“) in Kartenform die Verbreitung von morpholexikalischen Typen für die Bezeichnung vorgegebener Konzepte präsentieren. Die systematische Erfassung dieser Daten ist kaum automatisierbar und bedeutet einen erheblichen Aufwand an Handarbeit. Die Schwierigkeit liegt dabei weniger im (nicht eingesetzten) OCR-Verfahren, sondern vielmehr an der kartographischen Zuordnung bestimmter Bezeichnungen zu den einzelnen auf den Karten verzeichneten Punkten. Erschwert wird diese automatische Erfassung überdies durch die Verwendung von Symbolen auf der Karte, die die Orthographie des  entsprechenden Typs also unterdrücken. Die Daten aus den Sprachatlanten werden ergänzt um Daten aus Wörterbüchern, die, anders als die Sprachatlanten, von den morpholexikalischen Typen ausgehen und die jeweiligen durch sie bezeichneten Konzepte dokumentieren. Es werden jedoch nur solche Wörterbücher berücksichtigt, die auch Aufschluss über die geographische Verbreitung der jeweiligen Bedeutungen geben. VA verfügt über eine große Anzahl nationaler und internationaler Partner, die vielfach über eigene Sprachdatensammlungen verfügen, die nach Möglichkeit und Eignung ebenfalls in den Datenbestand von VA übernommen werden. In der Summe ergibt sich ein kartierbares Netz der im Alpenraum verbreiteten Bezeichnungen der ausgewählten Konzepte, die auf einer interaktiven Online-Karte präsentiert werden. Ein wesentlicher Mehrwert des Einsatzes der zeitgemäßen Online-Medien ist dabei der problemfreie und schnelle Wechsel zwischen der onomasiologischen und der semasiologischen Perspektive.

VA stellt sämtliche von ihm erzeugten Inhalte – wozu auch alle Softwareentwicklungen gehören – nach Möglichkeit unter einer offenen Lizenz zur Verfügung (CC BY-SA). Ausnahmen bestehen nur für Daten, die anderweitig unter restriktiven Lizenzen geführt werden.

VA versteht sich als konsequent digitales Online-Projekt und betrachtet die traditionellen Publikations- und Kommunikationsgepflogenheiten im Wissenschaftsbetrieb als überholt. Das Projekt verzichtet vollständig auf den Einsatz herkömmlicher Drucktechnologie und hält auch den Einsatz von PDF-Dokumenten als eine wenig geeignete Publikationsform, die gegenüber der Webtechnologie entscheidende Einschränkungen besitzt.

Die zentralen Projektdaten werden im relationalen Datenformat in einer MySQL-Datenbank verwaltet. Als Frontend dient eine generische WordPress-Installation, für die von den Projekt-Informatikern eine Reihe von spezifischen, auf die Projektbedürfnisse zugeschnittenen, Plugins entwickelt wurden, die über GitHub der Allgemeinheit unter der CC BY-SA-Lizenz zur Verfügung gestellt werden. Das Projektportal ist multifunktional. Es dient gleichermaßen als Arbeitsinstrument für die Projektmitarbeiter wie auch als Publikations- und Dokumentationsplattform und schließlich zur wissenschaftlichen Kommunikation, wobei allerdings letztere Funktionalität noch nicht konsequent ausgebaut ist. Die Idee ist, dass sich Wissenschaftler und Laien auf dem Portal registrieren und das System für den wissenschaftlichen Austausch und auch als Instrument zur Verwaltung eigener Daten verwenden.

VA unterscheidet nicht zwischen „Forschungsdaten“ einerseits und auswertenden Daten andererseits, eine Vorstellung, von der offenkundig auch die aktuelle Diskussion des Forschungsdatenmanagements geprägt ist. Sämtliche Projektdaten sind aufeinander bezogen und somit untrennbar miteinander verbunden. Aus diesem Grund verfolgt VA das Ziel, die Gesamtheit der Daten, also die gesammelten Sprachdaten sowie alle darauf bezogenen analytischen und erläuternden Texte, kartographischen Repräsentationen und sonstige Derivate als Ganzes dauerhaft und in zuverlässig zitierbarer Weise zu erhalten. Angesichts ständig ausgebauter Speicherungskapazitäten und dem im Vergleich mit mancher naturwissenschaftlichen Disziplin geringem Datenvolumen kann die Datenmenge nicht als Hinderungsgrund betrachtet werden, womit kein Grund erkennbar ist, nicht den kompletten Datenbestand dauerhaft zu bewahren.

Der aus den stets nur auf Teilbereiche des Alpenraums beschränkten Sprachatlanten und Wörterbüchern zusammengetragene gleichsam „historische“ Datenbestand weist notwendigerweise eine ganze Reihe von Inkonsistenzen auf. So sind regionale Unterschiede hinsichtlich Belegdichte und Dokumentation der ausgewählten Konzepte festzustellen. Um diese Inkonsistenzen auszugleichen, wurde von VA ein Crowdsourcing-Tool entwickelt, das Nutzern im Internet erlaubt, regionale Bezeichnungen für die projektrelevanten Konzepte beizutragen. Aktuell sind auf diesem Weg exakt 11546 (Stand 30.4.19) morpholexikalische Einzelbelege in den Datenbestand von VA gelangt. Neben dem geographischen und konzeptbezogenen Ausgleich gelangt über das Crowdsourcing auch eine (zusätzliche, da auch die konventionellen Datenquellen unterschiedliche Zeiträume dokumentieren) diachrone Perspektive in den Datenbestand, die einen Einblick in den Sprachwandel und dessen Dynamik erlaubt.

VA steht im engen Verbund mit im Wesentlichen zwei an der LMU beheimateten Institutionen: Der IT-Gruppe Geisteswissenschaften (ITG) sowie der Universitätsbibliothek (UB). Die ITG besteht seit knapp 20 Jahren und ist ursprünglich aus einer Stelle für rechnergestützte Forschung an der Fakultät für Kulturwissenschaften der LMU hervorgegangen. Sie ist zuständig für und ist getragen von sämtlichen geisteswissenschaftlichen Fakultäten, wobei ihre zentralen Aufgaben in der Planung und Betreuung der IT-Infrastruktur, der Unterstützung bei und der Durchführung von digitaler Forschung und Lehre sowie im Management der von den Wissenschaftlern erzeugten Forschungsdaten liegen. Die bei VA beschäftigten Informatiker sind direkt an der ITG angesiedelt und haben dort die Möglichkeit zum fachlichen Austausch mit anderen Beschäftigten, die in einer ganzen Reihe von weiteren DH-Projekten mit vergleichbaren Aufgaben beschäftigt sind. Dieses strukturelle Konzept gewährleistet ein hohes Maß an Synergieeffekten, von denen auch die anderen an der ITG betriebenen Projekte profitieren können. VA ist bestrebt, die für das Projekt entwickelte Software soweit möglich und sinnvoll generisch und modular zu konzipieren, so dass sie mit möglichst geringem Aufwand auch in anderen Kontexten weiter- bzw. wiederverwendet werden kann.

Vor allem im Hinblick auf die dauerhafte Bewahrung der Projektdaten spielt wiederum die UB die entscheidende Rolle für VA. Generell ist VA der Meinung, dass vor allem die Bibliotheken die natürlichen Ansprechpartner für alle Fragen der Datenbewahrung sind. Dies ist begründet zum einen durch die jahrhundertelange Tradition der entsprechenden Zuständigkeit, zum anderen durch die feste institutionelle Verankerung, die eine langfristige Bestandsgarantie verspricht, wie sie kaum eine andere Einrichtung in vergleichbarem Umfang besitzt. Hinzu kommt ein hohes Maß an Kompetenz, das an der UB sowohl im Hinblick auf die bibliothekarischen wie auch die informatischen Erfordernisse vorhanden ist. Drittmittelgeförderte Projekte mit begrenzter Existenzperspektive erscheinen problematisch, werden von VA jedoch zusätzlich genutzt. So wird aktuell ein Datenexport an das CLARIN-D Centre Leipzig vorbereitet, mit dem VA eine Kooperationsvereinbarung abgeschlossen hat.

Über den Kontakt zur UB und ITG ist VA auch in das vom Bayerischen Staatsministerium für Wissenschaft und Kunst geförderte Projekt eHumanities – interdisziplinär eingebunden. VA nimmt dort die Rolle eines Pilotprojekts ein, dessen Daten exemplarisch mit Metadaten angereichert und schließlich in das institutionelle Repositorium der UB (Open Data LMU) gelangen, wo sie schließlich in versionierter Form dauerhaft gesichert und auch zitierbar sind. Die Entwicklung bzw. Anpassung der Metadatenmodelle an die spezifischen Projekterfordernisse erfolgt in enger Zusammenarbeit von VA-, ITG– und UB-Mitarbeitern. Dieser Prozess, der sich als ausgesprochen effizient erweist, ist in dieser Form nur durch die enge lokale Ansiedlung der beteiligten Institutionen möglich. Vor dem Hintergrund dieser Erfahrung steht VA allen Konzepten, die im Hinblick auf das Forschungsdatenmanagement Lösungen mit spezialisierten zentralen Institutionen favorisieren, die dann unter Umständen sehr weit vom Ort der Projekttätigkeit liegen, skeptisch gegenüber. Demgegenüber betrachtet VA die skizzierte enge Verzahnung der beteiligten Akteure als modellhaft. Zumindest theoretisch sollte eine Übertragung dieses Konzepts auf andere Universitätsstandorte angesichts der doch weitgehend flächendeckenden Verbreitung von Universitätsbibliotheken möglich sein.

VA steht seit Längerem auch in Kontakt mit dem vom BMBF geförderten Projekt GeRDI, das als Datenaggregator betrachtet werden kann, dessen Ziel es ist, Forschungsdaten der verschiedensten Disziplinen über einen zentralen Zugang unter Einsatz von Metadaten zugänglich zu machen. Durch die oben beschriebene Kooperation im Rahmen des Projekts eHumanities – interdisziplinär gelangen die VA-Daten über die UB auch in den Datenbestand von GeRDI.

Im Zusammenhang mit dem Forschungsdatenmanagement wird für die Aufbereitung von Forschungsdaten seit einiger Zeit auch die Erfüllung der sog. FAIR-Prinzipien propagiert bzw. bisweilen auch gefordert. Das Projekt VA hält die in diesem Akronym versammelten Postulate für durch und durch berechtigt und ist bestrebt, diesen Kriterien möglichst weitgehend zu entsprechen. Die Auffindbarkeit (findable) und Zugänglichkeit (accessible) der VA-Daten ist durch die in Zusammenarbeit mit der UB erfolgte Anreicherung um Metadaten mit deren anschließender Einbindung in Kataloge (z.B. OPAC) und Aggregatoren-Dienste (GeRDI) sowie durch das angewendete offene Lizenzmodell hinreichend gewährleistet. Die Forderung der Interoperabilität (interoparable) und bis zu einem gewissen Grad auch der Nachnutzbarkeit (reusable) erscheint nur möglich, wenn das vom Projekt gesammelte Datenmaterial in möglichst feiner Granulierung vorliegt und auf die einzelnen Datensätze über eine URL eindeutig referenziert werden kann. Aus diesem Grund wird der Kerndatenbestand von VA nach Einzelbelegen, morpholexikalischen Typen, Konzepten und Gemeinden gruppiert, die jeweiligen Gruppen mit persistenten Identifikatoren versehen und in dieser Form, zusammen mit allen übrigen Projektdaten, versionsweise an die UB übertragen. Nach der Anreicherung um Metadaten und der Ablage im institutionellen Repositorium ist es sodann möglich, jede einzelne Instanz innerhalb der genannten Gruppierungen über eine DOI anzusprechen. Damit sind de facto projektspezifische Normdaten erzeugt, darüberhinaus ist eine der wesentlichen Forderungen erfüllt, die den Datenbestand von VA als „linked open data“ qualifizieren (die Existenz einer persistenten URL). Derzeit fehlen jedoch noch die ebenfalls erforderlichen RDF-Metadaten im XML-Format, deren Erzeugung jedoch geplant ist. Die UB erwägt außerdem, zusätzlich zu den DOIs eigene persistente URLs zu erzeugen, deren Vergabe und Betreuung in der alleinigen Verantwortung der UB liegen. VA begrüßt diese Perspektive, zumal die VA-Ressourcen zusätzlich zu den DOIs über ein weiteres, davon unabhängiges System persistenter Adressen erreichbar sein werden.

Die größte Herausforderung des Forschungsdatenmanagements besteht in der langfristigen Konservierung „lebender Systeme“, wie das Projektportal von VA eines ist. VA betrachtet dieses von ihm entwickelte Projektportal als eine zeitgemäße Publikationsform, die in ihrer primären Funktion – der Veröffentlichung – mit der traditionellen Buchpublikation vergleichbar ist, aber natürlich darüber hinausgehende Möglichkeiten bietet. Der Wunsch wäre, dieses Webportal möglichst ad infinitum online verfügbar zu halten, vergleichbar mit der Bewahrung eines Buches in einer Bibliothek. Leider stehen diesem Ideal technische Schwierigkeiten entgegen, die struktureller Natur und daher bislang nicht lösbar sind. Das Problem besteht hauptsächlich in der ständigen Weiterentwicklung der Software- konkret: Serverumgebung, innerhalb derer ein solches Projektportal läuft. Die projekt- bzw. portalspezifische Software muss in größeren Abständen immer wieder an die veränderte Umgebung angepasst werden, bedarf also mehr oder minder permanenter Pflege. VA ist zwar insofern strategisch gut aufgestellt, als das Projektportal von der ITG betreut wird, die über eine unbefristete Bestandsperspektive verfügt und im Rahmen ihrer personellen Möglichkeiten die Betreuung des VA-Webportals auch über das Projektende von VA hinaus übernehmen wird, jedoch kann nicht ausgeschlossen werden, dass in mittel- bis langfristiger Perspektive derart großer Aufwand für den Fortbetrieb des Portals geleistet werden müsste, der die Kapazitäten der ITG übersteigt. Versuchsweise wurde eine ältere Version des VA-Webportals auf einem sog. Docker-Image auf einem Server der UB abgelegt (https://verba-alpina-archiv.ub.uni-muenchen.de/), jedoch erscheint auch dies nicht als absolut zuverlässige Dauerlösung. Als derzeit einzig vernünftiges Konzept zur dauerhaften Bewahrung auch des Webportals erscheint nur die von VA betriebene möglichst ausführliche Dokumentation der Funktionalität der Webseite zusammen mit der Archivierung des entwickelten Softwarecodes auf GitHub sowie im institutionellen Repositorium der UB (Letzteres wird derzeit noch projektintern diskutiert). Späteren Generationen sollte es dann zumindest theoretisch möglich sein, das Gesamtsystem einschließlich all seiner Funktionen mit der dann verfügbaren Technik „nachzubauen“.

2. Teil: Die Perspektive der Bibliothek (Martin Spenger)

Wie aufgezeigt spielen Bibliotheken eine entscheidende Rolle im Umgang mit Forschungsdaten. Dabei nimmt die bereits an den Einrichtungen vorhandene Expertise in der Erschließung und Zugänglichmachung von Informationen eine zentrale Rolle im Prozess des Forschungsdatenmanagements ein.

Neben der Erschließung der Forschungsdaten und der Verknüpfung mit Normdaten kann die generische und fachspezifische Anreicherung mit Metadaten als ein Kompetenzbereich der Bibliotheken betrachtet werden. Oft besteht zusätzlich eine entsprechende Infrastruktur an den Einrichtungen, die sich mit der Vergabe von persistenten Identifikationen (PID) befasst. Bibliotheken können in der Regel auf eine langjährige Erfahrung mit der Vergabe und dem Einsatz von Digital Object Identifiern (DOI) und Uniform Resource Names (URN) zurückgreifen.

Diese Aufgabenbereiche bilden die Grundlage, um Daten zugänglich und auffindbar zu machen. Neben der Beratung zum Forschungsdatenmanagement finden sich Bibliotheken zudem immer häufiger in der Position des „Data Publishers“, also des Datenveröffentlichers. Mit der Veröffentlichung von Forschungsdaten – beispielsweise auf institutionellen Repositorien – entstehen zusätzliche Aufgabenfelder für die Bibliotheken. In der Regel verfügen die Publikationsplattformen bereits über eine Infrastruktur, die es ermöglicht, die Metadaten über Schnittstellen an weitere Suchmaschinen oder Discovery-Systeme zu liefern. Bibliotheken kennen dabei auch die Recherche- und Nutzungs-Bedürfnisse der Forschenden und sorgen dafür, dass auch die Forschungsdaten über geeignete Plattformen für eine breite Nutzergruppe zugänglich sind.

Während mit der Vergabe von PIDs bereits eine dauerhafte Zitierbarkeit gegeben ist, müssen sich die „Data Publishers“ auch mit der Frage auseinandersetzen, wie Forschungsdaten langfristig verfügbar bleiben können. An vielen Bibliotheken bestehen bereits entsprechende Workflows für digitale Publikationen, die sich teilweise auch auf Forschungsdaten übertragen lassen. Gemäß den Regeln der guten wissenschaftlichen Praxis sollen Daten mindestens zehn Jahre aufbewahrt werden. Dies erscheint jedoch verglichen mit „traditionellen“ Beständen von Bibliotheken sehr kurz. Während beispielsweise im Bereich „Altes Buch“ Medien bewahrt werden, die mehrere hundert Jahre alt sein können, ist es unklar, ob heute erstellte Forschungsdaten in zehn Jahren noch lesbar sind. Es wird daher an verschiedenen Lösungen gearbeitet, von Technologien wie Bitstream Preservation bis hin zur Langzeitarchivierung, damit auch Informationen aus digitalen Daten langfristig verfügbar sind.

Fallbeispiel Universitätsbibliothek der Ludwig-Maximilians-Universität München

Die Themen Open Access und Forschungsdaten sind an der Universitätsbibliothek der Ludwig-Maximilians-Universität München (UB der LMU) Teil des Alltagsgeschäfts. Neben elektronischen Publikationsplattformen für Zeitschriften (Open Journals LMU), Hochschulschriften (Elektronische Hochschulschriften) und weiteren wissenschaftlichen Publikationen (Open Access LMU), werden auch hybride Publikationsformen (z. B. Open Publishing LMU) angeboten (🔗). Die Veröffentlichung von Forschungsdaten ist seit 2010 über das institutionelle Repositorium Open Data LMU möglich.

Primär richtet sich das Repositorium an Wissenschaftler/innen aller Fakultäten der LMU sowie kooperierender Institutionen. Die Ausrichtung ist interdisziplinär, und es wurden bereits Forschungsdaten aus über 15 verschiedenen Fachgebieten veröffentlicht. Nutzer/innen können nach erfolgreicher Registrierung ihre Daten eigenständig auf den Server hochladen. Eine einheitliche Forschungsdaten-Policy wurde bisher nicht eingeführt, es wird aber empfohlen, Daten im Sinne der Budapester Open Access Initiative und der Berliner Erklärung über offenen Zugang zu wissenschaftlichem Wissen der Allgemeinheit zur Verfügung zu stellen.

Das Repositoriums Open Data LMU läuft unter der Open-Source-Software EPrints. An der UB der LMU ist die Version 3.3.15 im Einsatz. EPrints wird in einer Linux-Umgebung aufgesetzt und benötigt Perl sowie eine MySQL-Datenbank. Eine OAI-Schnittstelle erlaubt den Export von Metadaten in vielen Standard-Formaten, darunter DataCite, Dublin Core oder RDF.

Abbildung 1: Das institutionelle Repositorium Open Data LMU

Durch die stetig wachsenden Anforderungen an das Forschungsdatenmanagement wurde an der UB der LMU alternative Repositorien-Software evaluiert. Eine Alternative sollte alle Funktionen, die EPrints bietet, beinhalten sowie einen komfortableren und vielseitigeren Umgang mit Forschungsdaten ermöglichen. Zentrale Anforderungen sind beispielsweise eine hohe Skalierbarkeit sowie die Anbindung an neue Technologien wie Linked Open Data und Semantic Web.

Die Wahl fiel schließlich auf Fedora Repositories. Fedora ist ebenfalls ein Open Source-Produkt und wird von DuraSpace entwickelt. Hinter der Organisation steht eine große und aktive Community, die Lösungen für unterschiedliche Bedarfe anbietet. Das populärste Produkt von DuraSpace ist das Repositorium DSpace, welches mittlerweile zu den am häufigsten eingesetzten Datenrepositorien an deutschen Forschungseinrichtungen zählt. Während sich DSpace verhältnismäßig einfach installieren und einrichten lässt, fungiert Fedora als Middleware und bedarf tiefer greifender Entwicklungs- und Programmierarbeiten.

Wie genau sich Fedora als Middleware einsetzen lässt, zeigt folgende Skizze, die in der Entwicklungsphase an der UB der LMU erstellt wurde. Als Pilotprojekt diente dabei das in Teil 1 des Textes erwähnte Projekt VerbaAlpina (VA). Die Projektwebseite hat seit 2019 eine Schnittstelle, die Forschungsdaten in unterschiedlichen Formaten bereitstellt, wahlweise als csv, xml oder json.

Abbildung 2: vereinfachte Skizze der Infrastruktur

Über die Schnittstelle gesammelte Daten werden anschließend um Metadaten angereichert. Dabei arbeiten Metadaten-Experten der UB der LMU mit Vertretern aus den Fachdisziplinen zusammen. Im Beispiel von VA entstand in Zusammenarbeit mit den Projektmitarbeiter/innen ein detailliertes Datenmodell, das anschließend in ein geeignetes Metadatenschema übertragen wurde.

Das Metadaten-Management ist die Kernaufgabe im frühen Stadium des Forschungsdatenmanagements und entscheidet darüber, wo und von wem die Daten aufgefunden werden können. Die UB der LMU verwendet dabei den Metadaten-Standard von DataCite. Dieser Standard kann auch zur Registrierung von DOIs genutzt werden. Zusammen mit der ITG und dem Leibniz-Rechenzentrum (LRZ) der Bayerischen Akademie der Wissenschaften werden in einer Arbeitsgruppe Best-Practice-Empfehlungen für die
Verwendung des Metadaten-Schemas erarbeitet. Dies ist insofern sinnvoll, da den Forschenden eine Empfehlung gegeben werden kann, wie das Metadaten-Schema in ihrem Fachbereich am besten zu verwenden ist.

Das Thema Granularität spielt hierbei eine ebenso große Rolle. Je nach Disziplin kann die Granularität stark variieren. Da die Möglichkeit besteht, PIDs für Forschungsdaten zu vergeben, stellt sich unweigerlich die Frage, auf welcher Ebene dies geschehen soll. Im DOI-Handbook werden folgende Möglichkeiten genannt:

A DOI name can be assigned to any object, regardless of the extent to which that object might be a component part of some larger entity. DOI names can be assigned at any desired degree of precision and granularity that a registrant deems to be appropriate.

For example, for granularity in textual materials, separate DOI names can be assigned to a novel as an abstract work, a specific edition of that novel, a specific chapter within that edition of the novel, a single paragraph, a specific image, or a quotation, as well as to each specific manifestation in which any of those entities are published or otherwise made available. (🔗)

Im Falle von VA haben die Einzelbelege in der Forschung einen besonderen Status. Deshalb ist im Projektkontext die Überlegung, PIDs auf Einzeldatensatzebene zu vergeben. Bei VA handelt sich um ca. 81.000 Datensätze. Damit die Unterscheidung und Suchbarkeit der Einzelbelege sinnvoll gestaltet werden kann, fließen in die Metadaten auch Sacherschließung und geographische Informationen mit ein. Die in Teil 1 erwähnten Verbindungen der Einzelbelege unter den Typen „Gemeinden“, „morphololexikalische Typen“ und „Konzept“ werden ebenfalls in den Metadaten berücksichtigt.

Abbildung 3: Transformation der Daten: Von den Roh-Daten aus einer CSV-Datei, über das Datenmodell hin zum DataCite-XML

Die Transformation erfolgt dabei über mehrere Schritte. Anhand eines detaillierten Datenmodells werden die Rohdaten der Schnittstelle bearbeitet und um entsprechende Metadaten angereichert. Dies erfolgt in Abstimmung mit den Forschenden. Anschließend wird eine DataCite-XML-Datei erstellt, die alle relevanten Metadaten beinhaltet. Diese XML-Datei wird von der UB der LMU auch für die Erstellung von DOIs verwendet.

Fedora bietet an dieser Stelle verschiedene Möglichkeiten für einen Ingest der Daten. Neben XML besteht auch die Möglichkeit, RDF-Dateien für das Anlegen der Datensätze zu verwenden. Im Testbetrieb wird an der Universitätsbibliothek der Import beider Varianten erprobt.

Der Fluss der Forschungs- und Metadaten ist daher sehr komplex. Ein daraus entwickeltes Aufgabenmodell wirft zudem einige Fragen auf, die im Rahmen des Projekts geklärt werden müssen:

Abbildung 4: Erweitertes Aufgabenmodell zum FDM in den digitalen Geisteswissenschaften an der LMU

Das erweiterte Aufgabenmodell zeigt, wie die Aufgaben der ITG und der UB der LMU zusammenhängen. Die Anreicherung mit Metadaten erfolgt an der UB der LMU in enger Zusammenarbeit mit der ITG und den Forschenden aus den Fachdisziplinen. Sobald die Forschungsdaten um entsprechende Metadaten angereichert sind, werden Forschungs- und Metadatensätze in das Repositorium Open Data LMU übertragen. An diesem Punkt werden die Forschungsdaten zum ersten Mal über das institutionelle Repositorium durchsuch- und auffindbar. Um die Daten einer breiteren Nutzergruppe zur Verfügung zu stellen, werden über entsprechende Schnittstellen (z. B. OAI-PMH) Metadaten an weitere Dienste geliefert. Daten
von Open Data LMU werden momentan von BASE, Google Dataset Search oder GeRDI indexiert.

Zur Verfügbarkeit der Forschungsdaten bietet Open Data LMU eine sogenannte Bitstream Preservation. Die Daten werden gemäß den Regeln der guten wissenschaftlichen Praxis mindestens zehn Jahre aufbewahrt. Mit dem Umstieg auf eine neue Repositorien-Software soll gleichzeitig auch die Strategie der Datenarchivierung überarbeitet werden. Zukünftig soll ein Schwerpunkt nicht nur auf die Archivierung von Forschungs-, sondern auch der zugehörigen Metadaten gelegt werden. Eine den NESTOR-Richtlinien folgende Langzeitarchivierung könnte dabei eingerichtet werden. Im Falle des Pilotprojekts VA bietet auch die Projektwebseite mit ihrer multimedialen Kartenansicht Informationen, die durch eine reine Ablage der Forschungsdaten verloren gehen könnte. Die UB der LMU arbeitet hier erneut im Tandem mit der ITG und dem VA-Projekt, um die Bedarfe der Wissenschaft zu erkennen und umzusetzen. In der Vergangenheit gab es des Öfteren Kooperationen mit dem LRZ, die sich mit der Archivierung von Daten beschäftigt haben. Auch für zukünftige Projekte soll in diesem Bereich kooperiert werden.

Für die langfristige Planung wird ebenfalls erwogen, Forschungsdaten über bestehende Recherche-Systeme an Bibliotheken auffindbar zu machen. Dies könnte über Bibliothekskataloge erfolgen. Dabei ist angedacht, analog zu den oben genannten Discovery-Diensten nur die Metadaten weiterzugeben. Sobald die Infrastruktur um das Fedora-Repositorium zuverlässig im Produktivbetrieb läuft, wird diese Möglichkeit evaluiert.

Die Zusammenarbeit zwischen UB und Wissenschaftler/innen der LMU hat gezeigt, dass es von großem Vorteil sein kann, auf bestehende Strukturen aufzubauen. Sowohl die Universitätsbibliothek, als auch die geisteswissenschaftlichen Institute sind ein fester Bestandteil der Universität und können auch längerfristige Vorhaben besser umsetzen, als beispielsweise Projekte mit begrenzter Laufzeit. Die Zusammenarbeit hat zudem auf beiden Seiten die Kompetenz der Forschungsdaten-Ansprechpartner vergrößert. Dabei spielt auch die Beratung auf verschiedenen Stufen des Forschungsprozesses eine zentrale Rolle, die sowohl von Infrastruktur-, als auch von Wissenschaftspartnern übernommen werden kann. Wenn die Universitätsbibliothek schon frühzeitig in die Planung und Durchführung von Forschungsdatenvorhaben involviert wird, erzeugt dies Synergien, die ein erfolgreiches Vorhaben leichter realisierbar machen. Mit der ITG und der UB der LMU besteht zudem ein institutioneller „Verbund“ für Forschungsdaten in den Digitalen Geisteswissenschaften an der LMU. Die Zusammenarbeit kann perspektivisch neue Kooperationen und Finanzierungsmöglichkeiten entstehen lassen.

Das Modellprojekt „eHumanities – interdisziplinär“

Die in Teil 1 und Teil 2 genannten Infrastruktur- und Wissenschaftspartner arbeiten nicht nur innerhalb der LMU zusammen, sondern sind auch Teil des Projekts: „eHumanities – interdisziplinär“. Dort arbeiten ITG und die UB der LMU unter der Federführung der UB der Friedrich-Alexander-Universität Erlangen-Nürnberg (UB der FAU) an Fragestellungen zu Forschungsdaten in den digitalen Geistes- und Sozialwissenschaften. Das Projekt wird vom
Bayerischen Staatsministerium für Wissenschaft und Kunst gefördert und hat eine Laufzeit von drei Jahren (März 2018 – März 2021).

Im Projekt beschäftigen sich die Mitarbeiter/innen mit der Konzeption und Evaluierung neuer Hilfsmittel und der Erarbeitung von Best-Practice-Empfehlungen. Die Verbindung von digitaler Bibliotheksexpertise mit informatischen und fachmethodischen Schnittstellenkompetenzen steht dabei im Vordergrund.

Projektergebnisse werden über die Projektwebseite veröffentlicht. Der Zwischenbericht über das erste Projektjahr wurde bereits veröffentlicht und zukünftige Berichte und Ergebnisse werden ebenfalls mit der Community geteilt. Ziele sind dabei auch, Erfahrungsberichte zu Fedora zu veröffentlichen und Programmierarbeiten über die Plattform GitHub zur Verfügung zu stellen. Durch die Veröffentlichung von Quellcode in Kombination mit den Berichten soll eine Transferierbarkeit der Projektergebnisse auf weitere Vorhaben und/oder Disziplinen möglich sein.

Bereits nach einem Drittel der Projektlaufzeit hat sich gezeigt, dass die Zusammenarbeit von Infrastruktur- und Wissenschaftspartnern neue Sichtweisen auf altbekannte Probleme ermöglicht, wie z. B. die Fragen nach der Langzeitarchivierung, Granularität und Auffindbarkeit. Durch eine Kooperation wird zudem vermieden, dass Bibliotheken und Wissenschaftler/innen Insellösungen für ihre Projekte aufbauen. Die Zusammenarbeit sorgt dafür, dass sich an der LMU aus Erfahrung mit Pilotprojekten der digitalen Geisteswissenschaften feste Workflows etablieren, von denen alle Teilnehmenden profitieren und durch die wiederkehrende Themen schneller bearbeitet werden können.

Die Bereitstellung von Datenmodellen und das Erarbeiten von Best-Practice-Empfehlungen für Metadatenschemata können zudem in Datenmanagementpläne übernommen werden. Dies ist ein weiteres Arbeitspaket des Modellprojekts, mit dem sich die UB der FAU beschäftigt. Dort wird im Frühjahr 2019 eine RDMO-Instanz eingeführt, die anschließend auch auf Server der UB der LMU übertragen werden soll. Um die Wissenschaftler/innen für das Thema „Forschungsdaten“ zu sensibilisieren, wird an der UB der FAU in einem weiteren Arbeitspaket ein digitales Lern- und Informationsangebot erstellt. Die Schulungs- und Videomaterialien werden anschließend als Open Educational Resources auch anderen Interessenten zur Verfügung gestellt und in den Digitalen Campus Bayern integriert. Dort können sie beispielsweise zum Bestandteil von Curricula im Bereich Digital Humanities werden. Mit leichten Veränderungen sind diese Materialien auch auf andere Institutionen und verwandte Disziplinen transferierbar.


 

IT-Gruppe Geistesschwissenschaften (ITG) der LMU

Konzeption und Institutionalisierung des FDM — aus der Erfahrung eines Forschungsprojekts in den digitalen Geisteswissenschaften (Zitieren)

Stephan Lücke
(495 Wörter)

Beitrag zu den Tandem-Talks auf den e-Science-Tagen in Heidelberg 2019

Stephan Lücke, Martin Spenger

Teil 1: Die Perspektive des Projekts (Stephan Lücke)

Vorbemerkung

Das Projekt VerbaAlpina betreibt intensive Methodenreflexion. Die meisten der im Folgenden nur kurz angeschnittenen Themen werden in der Rubrik „Methodologie“ des Projektportals vertieft abgehandelt. Die nachfolgende Präsentation ist punktuell auf Einträge in dieser Methodologie verlinkt.

Das Projekt VerbaAlpina (VA)

  • Von der DFG-gefördertes Langfristvorhaben mit Perspektive bis 2025
  • Derzeit zweite Förderphase (2017-2020)
  • interdisziplinäres DH-Projekt (Sprachwissenschaften, Informationstechnologie, [Ethnographie, Geschichte …])
  • Leitung: Thomas Krefeld (Sprachwiss.), Stephan Lücke (IT)
  • Personalausstattung:
    • 2 Sprachwissenschaftler (Romanistik, Germanistik),
    • 2 Informatiker,
    • eine Koordinatorin,
    • Hilfskräfte
  • Thema: Sprache und Kultur im Alpenraum
  • Im Zentrum steht die Frage: Welche Sachen werden an welchen Orten wie bezeichnet?
  • Beispiel: Die Sache (das „Konzept“) BUTTER wird in der Schweiz als „Anke“ bezeichnet, in Bayern als „Butter“, in Frankreich als „beurre“, in Italien als „burro“. Phonetische Variationen werden nicht berücksichtigt, es geht vor allem um morpholexikalische Typen. Beschränkung auf ausgewählte „Konzeptdomänen“ (Almwirtschaft, Natur und Umwelt, Tourismus)
  • Sammlung der Daten für den gesamten Alpenraum (= Gebiet der sog. Alpenkonvention). Quelle sind im wesentlichen sog. Sprachatlanten und Wörterbücher, die über die geographische Herkunft der Bezeichnungen Auskunft geben.
  • VA stellt nach Möglichkeit alle Inhalte unter der Lizenz CC BY-SA zur Verfügung – auch diese Präsentation
  • VA hat Kooperationsabkommen mit zahlreichen Partnern

Besonderheiten von VA

  • VA ist konsequent und ausschließlich „digital (WordPress; php, js, sql)
  • Strukturierte elektronische Erfassung des Materials aus Sprachatlanten und Wörterbüchern
  • Eintragung in eine relationale Datenbank (MySQL)
  • VA hält Trennung zwischen „Forschungsdaten“ und deren Interpretation für problematisch ⇒ Gesamtdatenbestand wird als „Forschungsdaten“ betrachtet (inkl. entwickelter Programmcode ⇒ WordPress-Plugins)
  • Multifunktionalität des Projektportals: Werkzeug — Dokumentation — Publikation — Kommunikation
  • Nutzung von Crowdsourcing (zum Ausgleich von Inkonsistenzen im Datenmaterial und für Dokumentation von Veränderungen gegenüber früher [Diachronie])

Institutionelle Einbindung (Organisationsstruktur): VA – ITG – UB

  • VA angebunden an die IT-Gruppe Geisteswissenschaften (ITG) der LMU (Projektinformatiker dort angestellt)
  • ITG: DH-Kompetenzzentrum für alle geisteswissenschaftlichen Fakultäten der LMU; zuständig für IT-Infrastruktur — Forschung & Lehre digital — Forschungsdatenmanagement
  • Institutioneller Verbund *vor Ort*: Projekt (VA) — Kompetenzentrum (ITG) — Datenzentrum (UB) …  enger Kontakt mit regelmäßigen Treffen ⇒ hohes Maß an Effizienz; nach Ansicht von VA mit Modellcharakter!!
  • VA als Pilotprojekt eingebunden in das Projekt eHumanities – interdisziplinär (Förderung durch das Bayerische Kultusministerium seit 2018 bis Ende 2019)
  • VA-Daten gelangen über UB auch an GeRDI (Aggregator)

FDM: Mehrwert der Kooperation mit der UB der LMU für VA

  • Problem bzw. Anspruch: Erfüllung der FAIR-Kriterien – Was tun mit den Projektdaten?
  • Perspektive: Bisher keine Standardverfahren
  • Drittmittelgeförderte Repositoriumslösungen problematisch wegen unsicherer Zukunft
  • Daher zunächst: Strategie der Verteilung der Daten auf verschiedene Repositorien (u.a. Clarin-D)
  • … UND: Open Data LMU der UB
  • Bibliotheken Idealpartner, weil …:
    • Existenz dauerhaft gesichert
    • kompetentes Personal
    • traditionell mit Wissensbewahrung beauftragt ⇒ große Erfahrung
    • flächendeckend vorhanden
  • UB übernimmt VA-Daten und reichert sie um Metadaten an (zweistufig: generisch ⇒ Datacite; fachspezifisch [in Entwicklung])
  • UB sorgt für Beschaffung feingranularer DOIs, Option: UB-eigene persistente Adressen! Feine Granularität u.a. wichtig für Interoperabilität!
  • ungelöstes Problem „lebendes System“: dauerhafter Betrieb des virtuellen Projektportals (versuchsweise: Betrieb auf Docker-Image auf UB-Server)

Teil 2: Open Data (Martin Spenger)

Powerpoint-Präsentatiion (pdf-Version)


IT-Gruppe Geistesschwissenschaften (ITG) der LMU

Das DFG-Langfristvorhaben „VerbaAlpina“ unter besonderer Berücksichtigung des Aspekts des Forschungsdatenmanagements (Zitieren)

Stephan Lücke
(1960 Wörter)

Vorbemerkung

Der folgende Themenvorschlag wurde am 28.9.18 über das „Conftool“ der DHd2019-Konferenz eingereicht. Dabei wurde der Text zusätzlich in einer Conftool-spezifischen Word- und in einer XML-Datei abgelegt (download als ZIP-Datei). Diese Dateien bildeten dann die Grundlage für die Begutachtung durch insgesamt vier Gutachter. Der Themenvorschlag wurde von zwei der Gutachter abgelehnt, einer empfahl, die Annahme als Posterpräsentation zu erwägen, der vierte Gutachter stimmte für die Annahme des Themenvorschlags. Im Endergebnis wurde der Themenvorschlag abgelehnt.

Die Einbindung von Stellungnahmen zu den Gutachten in den Entscheidungsprozess ist von der DHd2019 nicht vorgesehen. Da wir es wichtig finden, uns der geäußerten Kritik zu stellen, veröffentlichen wir an dieser Stelle, unterhalb des im Folgenden präsentierten Themenvorschlags, eine Stellungnahme zu den von den Gutachtern der DHd2019 vorgebrachten Kritikpunkten. Ursprünglich hatten wir oberhalb der Stellungnahme die Wortlaute der Gutachten präsentiert. Dies erschien uns im Sinne der Nachvollziehbarkeit unserer Stellungnahme unverzichtbar und gleichzeitig aufgrund der Anonymität der Gutachter vertretbar. Das Programmkommitee der DHd2019 sah indes darin eine Störung des Vertrauensverhältnisses zwischen ihm, dem Programmkommitee, und den Gutachtern und hat uns daher eindringlich darum gebeten, die Gutachten nicht öffentlich zugänglich zu machen. Wir haben diesem Wunsch im Geist der Kollegialität entsprochen und die Gutachten wieder entfernt — obwohl wir eigentlich der Ansicht sind, dass angesichts der Anonymität der Gutachter keine Persönlichkeitsrechte verletzt würden.

VerbaAlpina ist der Ansicht, dass der wissenschaftliche Diskurs jederzeit in der Öffentlichkeit stattfinden kann und nach Möglichkeit auch sollte. Gerade wenn unsere Arbeit Kritik erfährt, *müssen* wir, so unsere Auffassung, uns dieser in transparenter und nachvollziehbarer Weise stellen. Dies sind wir allein schon unserem Geldgeber schuldig, mehr aber noch der wissenschaftlichen Öffentlichkeit. In prädigitaler Zeit war es schwer, ein wünschenswertes Maß an Transparenz zu erzielen. Mit Einzug der neuen Medien hat sich die Lage jedoch auch in dieser Hinsicht fundamental geändert. Nunmehr ist es technisch vollkommen problemlos, den wissenschaftlichen Diskurs in allen Details offenzulegen. Wir sind davon überzeugt, dass dies nur positive Effekte auf die Produktivität der Akteure und die Qualität ihrer wissenschaftlichen Arbeit haben wird, und hoffen, dass dieser Paradigmenwechsel sich wenigstens mittelfristig flächendeckend durchsetzen wird.


Stephan Lücke

Themenvorschlag für einen Vortrag auf der DHd-Konferenz 2019 in Mainz und Frankfurt/M.: Bericht über die Entwicklung einer digitalen Ressource

Das Projekt VerbaAlpina – Kurzvorstellung

In der prädigitalen Welt hatten sich im Umfeld der Lexikographie zwei grundsätzlich voneinander unterschiedene Publikationsgattungen etabliert. Während das Wörterbuch von den Bezeichnungen ausging und, in alphabetischer Reihung, die unterschiedlichen Bedeutungen der einzelnen Wörter dokumentierte, präsentierte der sog. Sprachatlas, ausgehend von den Bedeutungen, die unterschiedlichen Wörter, die für deren Bezeichnung verwendet wurden. Die Bezeichnung „Sprachatlas“ verweist dabei auf die diatopische Dimension der Lexikographie, die darin begründet ist, dass Wörter in unterschiedlichen Regionen unterschiedliche Bedeutungen haben können. Während die georeferenzierte Abbildung der Verhältnisse das wesentliche Charakteristikum eines Sprachatlasses ist, finden sich Informationen zur geographischen Verbreitung der Wortbedeutungen nur in manchen Wörterbüchern. Als ein prominentes Beispiel für letztere Variante kann das Wörterbuch der schweizer-deutschen Sprache, das sog. Idiotikon (https://www.idiotikon.ch/), genannt werden.

Das Projekt VerbaAlpina (https://www.verba-alpina.gwi.uni-muenchen.de/), das seit dem Jahr 2014 von der DFG als Langfristvorhaben gefördert wird (http://gepris.dfg.de/gepris/projekt/253900505) und sich seit 2017 in seiner zweiten Förderphase befindet, nutzt die Möglichkeiten der Digitalisierung, um die beiden traditionell einander ausschließenden Perspektiven, also den Blick vom Wort zu dessen Bedeutung und den von der Bedeutung zu den Wörtern, in einem System zu vereinigen und schafft auf diese Weise eine innovative lexikographische Publikationsform, die überdies durch den Einsatz von Datenbanktechnologie eine Reihe erweiterter Analysemöglichkeiten wie etwa statistische Auswertungen des Datenmaterials ermöglicht.

Rein inhaltlich konzentriert sich das Projekt auf den Alpenraum und die dort gesprochenen Nationalsprachen und deren Dialekte. Als Datenbasis dienen zunächst die für diesen Raum verfügbaren traditionellen Sprachatlanten und Wörterbücher mit georeferenzierten Belegen, deren Inhalt partiell erfasst und in eine relationale Datenbank eingetragen wurde bzw. wird. Da eine vollständige Erfassung des lexikalischen Materials mit den vorhandenen Mitteln nicht zu leisten ist, erfolgt eine selektive Dokumentation von Vokabular, das mit bestimmten Konzeptdomänen verbunden ist. In der ersten Phase des Projekts stand das lexikalische Material im Umfeld von Almwesen und Milchwirtschaft im Mittelpunkt, in der laufenden Phase geht es hauptsächlich um Flora, Fauna und traditionelle Küche. Die geplante dritte Phase wird sich mit der modernen Lebenswelt und dem Tourismus bzw. vielmehr dem damit verbundenen Vokabular befassen.

Das gleichsam „historische“ Material aus Sprachatlanten und Wörterbüchern wird über ein Crowd-Sourcing-Tool (https://www.verba-alpina.gwi.uni-muenchen.de/en?page_id=1741) um aktuelles Material ergänzt. Unter anderem durch dieses im Netz gesammelte Material erhält das Projekt auch eine diachrone Perspektive, die die Beobachtung von Sprachwandel z.B. vor dem Hintergrund wirtschaftlicher und/oder demographischer Veränderungen erlaubt. Um dies zu ermöglichen, sammelt VerbaAlpina auch die Sprachdaten ergänzende Daten, etwa zur Bevölkerungsentwicklung oder zur Infrastruktur. Sehr wichtig ist für VerbaAlpina auch die Kooperation mit Partnern überwiegend aus dem Bereich der Sprachwissenschaften, die über eigene Sprachkorpora verfügen. Spezielle Kooperationsvereinbarungen regeln den Austausch von Datenmaterial zum wechselseitigen Nutzen. In diesem Zusammenhang, aber auch grundsätzlich, fühlt sich VerbaAlpina dem Ideal des Open Access verpflichtet. Sämtliche Inhalte werden nach Möglichkeit unter der CC-Lizenz BY-SA zur Verfügung gestellt.

Aus sprachwissenschaftlicher Sicht entsteht durch die Wahl des Alpenraums als Untersuchungsgebiet insofern ein besonderer Mehrwert, als die Dokumentation von Wortschatz sich traditionell am Verlauf der Sprach- und/oder der Nationalgrenzen orientierte. Da der Alpenraum von einer ganzen Reihe von Sprach- und politischen Grenzen durchzogen ist, versammelt VerbaAlpina demnach Sprachmaterial, das bislang nur in voneinander getrennten Publikationen dokumentiert und konsultierbar gewesen ist. Auf diese Weise ergibt sich die Möglichkeit, grenzüberschreitende Zusammenhänge wie etwa die Verbreitung ein und derselben lexematischen Basis sowohl im germanischen wie auch im romanischen Sprachraum zu entdecken. Als Beispiel lassen sich etwa das im germanischen Sprachraum u.a. in Kärnten belegte Wort Kasel und der vor allem im oberitalienischen Alpenraum verbreitete morpholexikalische Typ Casel anführen. Beide morpholexikalischen Typen hängen unverkennbar und zwar insofern miteinander zusammen, als ihnen jeweils das lateinische Wort căsa als lexematische Basis innewohnt. Diese Erkenntnis wirft sofort die Frage nach der Ursache dieses Zusammenhangs auf, die in den unterschiedlichen Szenarien des Sprachkontakts zu suchen ist. Spätestens in diesem Moment erhält das Projekt VerbaAlpina auch eine historische Dimension, denn nahezu ausschließlich ist Sprachkontakt mit historischen Prozessen wie etwa Wanderungsbewegungen, Eroberungen oder auch Handelsbeziehungen verknüpft. Neben dieser historischen Dimension beinhaltet VerbaAlpina auch einen Konnex mit der Ethnographie, zumal die Arbeit mit den Wörtern und Bezeichnungen auch zur Auseinandersetzung mit der damit verbundenen Lebenswelt zwingt. Insofern präsentiert sich VerbaAlpina also auch als ein interdisziplinäres Forschungsvorhaben.

Die Herausforderung des „Forschungsdatenmanagements“ – Nachhaltigkeit, Auffindbarkeit, Zitierbarkeit

VerbaAlpina versteht sich als vollständig digitales Online-Projekt, das konsequent speziell die damit gegebenen Möglichkeiten der Vernetzung und Verknüpfung nutzt. Mit diesem Anspruch ist eine ganze Reihe von Herausforderungen verbunden, die teils über die Kernbelange des Projekts hinausreichen und grundsätzliche Probleme berühren, die für die digitalen Geisteswissenschaften ganz allgemein gelöst werden müssen. Als das orientierunggebende Paradigma betrachtet VerbaAlpina dabei zunächst das gedruckte Buch, das bei allen mit diesem Medium verbundenen Nachteilen zwei ganz wesentliche und auch künftig unverzichtbare Eigenschaften besitzt: Es ist text- bzw. allgemein inhaltsstabil und dadurch zitierfähig und es ist in materieller Hinsicht dauerhaft. Die wesentliche Herausforderung, der sich VerbaAlpina und im Grunde alle digital arbeitenden Projekte gegenübersehen, ist demnach die Verbindung der neuen, erweiterten Möglichkeiten der Digitalisierung mit eben jenen unverzichtbaren Eigenschaften des Buches.

Für das Konzept der Dauerhaftigkeit wird aktuell verbreitet die Vokabel „Nachhaltigkeit“ bzw. „Nachnutzbarkeit“ verwendet. Vor dem Hintergrund der Digitalisierung besitzt dieses Postulat wiederum zwei Seiten: eine technische und eine inhaltliche. Die rein technische Bewahrung stellt sich dabei als das geringere Problem dar, denn die Sicherung digitaler Daten kann zuverlässig von Rechenzentren oder vergleichbaren Institutionen übernommen und gewährleistet werden. Wesentlich anspruchsvoller ist die Sicherstellung der künftigen und im Idealfall zeitlich unbegrenzten Nutzbarkeit der erzeugten Inhalte, die sich bei vollständig digitalen Projekten nur zu einem Bruchteil als von Menschen lesbarer Text in natürlicher Sprache darstellen. Soweit uns bekannt, gibt es in dieser Hinsicht noch keine allgemeingültigen und etablierten Verfahren, vielmehr befinden wir uns derzeit in einer Übergangsphase, in der allenthalben nach tragfähigen Konzepten in diesem Zusammenhang gesucht wird. Sämtliche Bemühungen müssen schließlich in der Etablierung allgemein akzeptierter Standardverfahren münden.

Zur Sicherstellung der Zitierbarkeit sämtlicher Inhalte bedient sich VerbaAlpina des Konzepts regelmäßiger Versionierungen. Derzeit wird jeweils zur Jahresmitte und zum Jahresende eine Version erzeugt, deren Zustand ab diesem Moment unverändert bleibt. Auf der Homepage des Projekts kann zwischen den verschiedenen Versionen gewählt werden. Eine Vielzahl der Inhalte von VerbaAlpina kann über URLs direkt adressiert werden, wobei jede dieser URLs die jeweilige Versionsnummer als URL-Parameter in sich trägt.

Im Hinblick auf mögliche künftige Umzüge der Projekthomepage, mithin eine Änderung der Domain, wurde bislang bereits ein sog. Digital Object Identifier (DOI) registriert, der die grundsätzliche Erreichbarkeit des Projektportals auch in solchen Fällen weiterhin garantieren kann. Derzeit sind Bestrebungen im Gange, DOIs nicht nur für das Projektportal als Ganzes, sondern vielmehr auch für definierte Inhalte in sehr feiner Granularität registrieren zu lassen. So ist beabsichtigt, u.a. die im Projekt versammelten morpholexikalischen Typen sowie die von diesen bezeichneten Konzepte (= Begriffe) mit individuellen DOIs zu versehen, so dass eine gezielte Referenzierung auf diese Einzeldaten möglich wird.

Neben der Registrierung dieser DOIs sind Bestrebungen im Gang, aus den im Projekt verwalteten Daten etwa nach dem Vorbild der GND Normdaten zu generieren. Konkret soll u.a. jeder morpholexikalische Typ, definiert durch lexematische Basis, Sprachfamilienzugehörigkeit, Genus und Affigierung, sowie jedes außersprachliche Konzept zu einem Normdatum deklariert werden. Die Vergabe entsprechender Normdaten-IDs in Verbindung mit der Registrierung feingranularer DOIs ist unverzichtbar für die gezielte Verknüpfung von Daten über Projektgrenzen hinweg und ist ein wichtiges Element im Umfeld des aktuell wissenschaftspolitisch stark geförderten Forschungsdatenmanagements. Durch die strukturierte Erfassung der Metadaten im weithin etablierten DataCite-Format finden die Forschungsdaten einschließlich der Normdaten-IDs auch Eingang in die Bibliothekskataloge. Auf diese Weise wird ihre Auffindbarkeit über OPAC-Recherchen ermöglicht.

VerbaAlpina befasst sich derzeit sehr intensiv mit dieser Thematik und ist in zwei aktuell laufende einschlägige Forschungsvorhaben (GeRDI [https://www.gerdi-project.eu/] und „eHumanities – interdisziplinär“ [https://www.fdm-bayern.org/]) zum Thema Forschungsdatenmanagement eingebunden.

Von noch grundsätzlicherer Bedeutung ist die Frage nach der Etablierung institutioneller Zuständigkeiten und Workflows, die die Einhaltung und Weiterentwicklung der einschlägigen Konzepte zur Nachhaltigkeit, Zitierbarkeit und Verknüpfungsmöglichkeit garantieren. Auch zu dieser Thematik hat VerbaAlpina bereits Ideen entwickelt und niedergelegt (Krefeld/Lücke 2017). Unter anderem findet sich darin ein Plädoyer für die Beibehaltung bzw. Stärkung der Rolle der Bibliotheken auch in der Phase nach der digitalen Revolution: Sie waren seit jeher für die Bewahrung und Auffindbarkeit von Informationen zuständig und ihr langfristiger Fortbestand erscheint, anders als dies bei manchen temporär geförderten Repositoriumsprojekten der Fall ist, gesichert.

Der hier unterbreitete Themenvorschlag besteht zusammenfassend darin, das Projekt VerbaAlpina kurz vorzustellen, um anschließend den Fokus auf die skizzierten Aspekte des Forschungsdatenmanagements zu legen. Die Präsentation der damit verbundenen Vorstellungen von VerbaAlpina auf der DHd-Jahreskonferenz wäre umso wichtiger, als gerade in diesem Zusammenhang ein breiter Konsens unerlässlich ist, der nur durch die Diskussion in einer möglichst breiten Öffentlichkeit erzielt werden kann.

Literaturverzeichnis

VerbaAlpina@GeRDI (Zitieren)

Stephan Lücke
(2456 Wörter)

Gerdi-Fragebogen zu VerbAlpina (Februar 2018)

  • Abläufe:

Daten-/Serverinfrastruktur: Die Daten von VerbaAlpina werden modularisiert und versioniert verwaltet. Die sprachlichen Kerndaten liegen auf einem geclusterten MySQL-Server (= Modul VA_DB). Darauf aufsetzend arbeitet eine mit WordPress realisierte GeRDI-VA-DataSources-270618-1638-16Webschnittstelle (VA_WEB), die u.a. eine Seite zur interaktiven kartographischen Visualisierung der in VA_DB gehaltenen Daten erlaubt.

Datenmanagementpläne: ja, aber nicht in standardisierter Form (vgl. https://www.forschungsdaten.info/themen/planen-und-strukturieren/datenmanagementplan/; entsprechende Dokumentationen sind in der Rubrik Methodologie abgelegt.

Freigabe: Der Zugriff auf die Datenbankschnittstellen VAP ist ausschließlich Kooperationspartnern von VerbaAlpina erlaubt und unterliegt einer CC BY-SA- bzw. der ODC-ODbL-Lizenz

  • Daten:

Größe: 1,5 GB (Modul VA_DB; Stand Feb. 2018), 30 GB in 33315 Dateien (Modul VA_WEB; Stand Feb. 2018)

Formate: relationales Datenformat;

Typen: ??

Ursprung: Teils strukturierte Erfassung retrodigitalisierter Sprachatlanten und Wörterbücher, teils Crowd, teils Projektpartner

Software: ??

Schnittstellen: VAP_ling_[language] (Sprachdaten), VAP_geo_[language] (ergänzende georeferenzierte Daten wie z.B. Fundorte von lateinischen Inschriften) (in jeweils 5 Sprachen)

Datenschutz: [Persönlichkeitsrechte? Urheberrechte?]

Speicher: Storage mit Plattenarrays; regelmäßige Backups über TSM ins LRZ

  • Metadaten:

Arten: s. Attribute der VAP-Schnittstellen

Speicherung: gemeinsam mit Primärdaten in VAP-Schnittstellen

Standards: proprietär; Standards werden durch individuell erzeugte Schnittstellen bedient (wie jetzt z.B. GeRDI: Datacite -> OAI-PMH -> Harvester)

Datenschutz: s.oben

Schnittstellen: ??

  • Datenauswertung:

Programme: – (ggf. zukünftig R oder SQL)

Aufbereitung: ??

Visualisierung: Online-Karte (Javascript, Google API)


VA@GeRDI (27. Juni 2018)

Tagesordnung

TOP 1: Roadmap (TW/HN) 

TOP 2: Usecases Datenkorrelation (TW/HN)

TOP 3: Bericht über Kontakte zu UBs (LMU, Erlangen) (SL)

TOP 4: Kooperation GeRDI – UZH (TK)

 

TOP 1: Roadmap (TW/HN)

GeRDI arbeitet in Releases, die ungefähr alle drei Monate
herausgegeben werden sollen. Das wäre eine mögliche Roadmap (bis zum
Ende von GeRDI Phase 1, in Phase 2 können ggf. neue Milestones
vereinbart werden):

Release 0.3 (Herbst 2018):

„Minimal viable product“ -> Verba Alpina Daten sind im GeRDI-Index
(ohne die Knowledge Base und mit Bounding Boxes)
Mögliche Data Provider für die Datenkorrelation wurden
identifiziert (GeRDI-VA-DataSources)

  • Bis zu Release 0.3 soll ein praxistaugliches Metadatenmodell implementiert werden („minimal viable product“). Die Entwicklung soll in enger Abstimmung mit der UB erfolgen.
  • Mit welchen Daten die VA-Daten kombiniert werden sollen, soll bis Herbst 2018 ausdiskutiert sein.
  • Metadatenproviding für GeRDI-Index kann später auch über die UB laufen; bezüglich der sustainability wäre es ein Gewinn, wenn sich die UB als Zwischeninstanz einschalten würde (denkbar wäre: VA liefert an –> UB e-humanities –> UB e-humanities bereitet die Daten auf –> liefert sie dann an GeRDI).

UB e-humanities Projekt

  • Das e-humanities Projekt führt vertiefte Inhaltsanalysen durch und verknüpft  die Daten mit Normdaten. Geplant ist, die Daten dann an GeRDI zu liefern.
  • Frau Kümmet wertet derzeit die Entitäten der ITG-Projekte aus. Diese sollen mit Wikidata verknüpft werden. Es ist jedoch noch nicht klar, ob sich alle Entitäten mit Wikidata abbilden lassen.

Release 0.4 (Winter 2018/19)

Geo-Granularität verbessert (Merging der Polygone für einen besseren
Informationsgehalt).
Anbindung der Data Provider für die Datenkorrelation in den GeRDI-Index.

Release 0.5 (Frühling 2019)

Erste Tests des Daten-Stagings (automatischer Bezug der VA-Daten mit
den Daten anderer Data-Provider) „so automatisch wie möglich“
Automatischer Bezug der Daten

  • Bis Release 0.5 sollen alle Daten von VA und Daten aus anderen Quellen auf die Plattform von GeRDI gebracht werden. Man hat eine erste Idee, wie automatisierbar dieser Prozess ist.

Release 0.6 (Sommer 2019)

Anbindung Knowledge Base an VerbaAlpina-Metadaten
Analyse der gestagten Daten auf LRZ-Rechnern

  • Es soll geprüft werden, welche Aufbereitung der Daten möglich ist.
  • Die Daten sollen mit einer logischen Einheit referieren.
  • Es soll festgelegt werden, wie genau die Datenanalyse ablaufen soll (welche Analyseschritte etc.).

Release 0.7 (Herbst 2019)

Puffer für Unvorhergesehenes

  • Im Herbst 2019 endet GeRDI Phase I.
  • Bis dahin soll ein Anwendungsfall von VA über die GeRDI-Plattform zum Laufen gebracht worden sein.
  • Bei Verlängerung von GeRDi soll mit den Communities aus Phase I auch in Phase II weiter zusammengearbeitet werden. Bei fehlender Anschlussfinanzierung von GeRDI ist vorstellbar, dass das LRZ und die UB als Ansprechpartner dienen und dass das e-humanities Projekt der UB die von GeRDI entwickelten Funktionalitäten übernimmt.

Methodik GeRDI

  • GeRDI nutzt existierende Metadaten-Harvesting-Modelle
  • gearbeitet wird mit DataCite als Standard und OAI-PMH-Protokoll (pleonastisch); damit soll bis Release 0.3 die erste laufbare Version produziert werden
  • wenn DataCite technisch nicht funktioniert, wird darauf entsprechend reagiert
  • laut TW bietet DataCite alles, um die Daten zugreifbar und interseparabel zu machen
  • im Endeffekt soll anhand von Usecases festgestellt werden, welche Anforderungen ein Metadatenstandard erfüllen muss und ob DataCite dafür ausreicht
  • bei Version 0.2/0.3 soll deshalb geschaut werden, ob die Funktionalitäten von DataCite ausreichen; wenn nicht, wird man sich nach entsprechenden Alternativen umschauen (Standard selbst kreieren oder einen bestehenden Standard entsprechend anpassen) und kann, wenn nötig, dann immer noch nachsteuern
  • geplant ist das Mapping von DataCite zu Dublin Core (= Mindeststandard, es gibt aber bessere Metadatenstandards)

Allgemeines

  • ab 18/1 sollen Metadatenannotationen auf SQL-Abfragen losgeschickt werden, Datenbasis: Schnittstelle vap_ling_xx
  • Die Daten sind dann redundant verfügbar und automatisch beziehbar
  • Usecases sind möglich, wie z.B. die Ausgabe bestimmter Diffusionsmuster für bestimmte Gemeinden
  • die entscheidenden Kategorien sind: Gemeinden, Konzepte, Morph-Typen, Zeit; jeder einzelne Morph-Typ ist ansprechbar; wenn eine Wissensdatenbank dazukommt, können andere, z.B. große Online-Wörterbücher, auch daran anknüpfen
  • auch der umgekehrte Fall ist denkbar, d.h. Metadaten aus GeRDI fließen in VA und nicht umgekeht; Daten aus 3 Bereichen stehen zur Verfügung: Statistik-Behörden, Transportdaten und Geophysikdaten

TOP 2: Usecases Datenkorrelation (TW/HN)

  • Nachnamen => Korreliert die Parzellierung der Typen mit der geographischen Distribution von Nachnamen?
  • Demographie-Daten => Welche Zusammenhänge gibt es zu Nivellierungen?
  • geophysikalische Daten => Stichworte: „Baumgrenze“, Flora und Fauna-Daten; hier fehlt eine genaue Fragestellung.
  • Daten, die Verhältnis von Einheimischen zu nicht-Einheimischen beschreiben (Übernachtungszahlen, Verkehrswege, Transportsysteme) => Korelliert dies mit Nivellierungen?

TOP 3: Bericht über Kontakte zu UBs (LMU, Erlangen) (SL), TOP 4: Kooperation GeRDI – UZH (TK)

  • da geisteswissenschaftliche Projekte derzeit allgemein aufgefordert werden, Metadaten anzulegen, ist ein einheitliches Metadatenmodell anzustreben, damit die Daten kompatibel sind
  • TK wäre deshalb dafür, Kontakt zu anderen aufzunehmen (UZH/UBs)
  • TW plädiert dafür, zunächst einen konkreten technischen Vorschlag zu machen und diesen in eine Version zu bringen, die präsentabel ist, bevor man mit anderen in Kontakt tritt

VA@GeRDI (09. Juli 2018) – Treffen zum Thema „Data Provider“

Teilnehmer: Krefeld, Lücke, Nguyen, Weber

Ort: ITG

Zeit: 12:30-13:30

VA ist interessiert an Daten aus folgenden Kategorien:

  • Demographie
  • Infrastruktur (Internet-Erschließung und -Nutzung, Verkehrswege [Straßen, Eisenbahn, Flughäfen], Tourismus)
  • geophysikalische Daten (Klima, Wetter, Bodengüte)
  • Wirtschaft (Verbreitung bestimmter Wirtschaftsformen, z.B. Almwirtschaft, Holzwirtschaft etc.)

Alle Daten sollten mit Chronoreferenzierung versehen sein und möglichst mehrere Zeitschnitte enthalten (Diachronie).

Als Data Provider wird zunächst Eurostat (http://ec.europa.eu/eurostat/data/databaseausgewertet. Erst wenn gewünschte Daten von dort nicht zu beziehen sind, wird auf nationale Datenquellen zurückgegriffen.

Im ersten Anlauf werden zunächst nur Daten zur Demographie erfasst.

Anregung1: MA-Arbeit zur algorithmischen Strukturierung der Daten des Idiotikons (https://digital.idiotikon.ch/idtkn/id12.htm#!page/120031/mode/1up) am LRZ?

Anregung2: Integration der von FZ im Rahmen seiner Diss erzeugten Daten  aus dem REW (http://www.nbn-resolving.de/urn:nbn:de:bvb:355-ubr07799-0) in GeRDI?

Das nächste VA@GeRDI-Treffen findet statt, sobald entweder das Ziel von release 0.3 („Minimal viable product“ -> VA-Daten im GeRDI-Index) erreicht ist oder demographische Daten im Gerdi-Index aufgenommen sind. Herr Nguyen und Herr Weber melden sich bei VA.


Teilnehmer: Kümmet, Lücke, Mutter, Nguyen, Weber, Zacherl

Ort: Medienlabor, Raum 3010, Schellingstraße 33

Zeit: 14:00-16:00 Uhr

Tagesordnung

TOP 1: Aktueller Stand: Metadaten, Harvester

TOP 2: Statusbericht GeRDI 0.2 und 0.3

TOP 3: Nächste Planungen GeRDI 0.4

TOP 4: Vorbereitungen Community Workshop

TOP 5: VA-Datenexport

 

TOP 1: Aktueller Stand: Metadaten, Harvester

GeRDI-Dienste

  • die Dienste „Harvest“, „Search“ und „Bookmark“ sind in GeRDI zentral, der Harvest-Dienst ist für die Nutzer nicht sichtbar
  • GeRDI bezieht sich hinsichtlich des Forschungsdaten-Lebenszyklus auf das Modell UK data life cycle (Quelle: UK Data Service https://www.ukdataservice.ac.uk/manage-data/lifecycle), beinhaltet die folgenden Schritte: creating data –> processing data –> analysing data –> preserving data –> giving access to data –> re-using data
  • VA würde gerne auf das Modell, das GeRDI zugrunde legt, referieren können; zu diesem Zweck soll das Modell irgendwo zentral abgelegt werden

Workflows

  • bislang gibt es in GeRDI zwei Suchmöglichkeiten: einfache Suche + erweiterte Suche
  • weitere Funktionen: Suchbereich einschränken; Daten speichern, bearbeiten, visualisieren; bookmark (speichert Daten als Lesezeichen zur späteren Ansicht)
  • beide Suchmöglichkeiten sollen von Beginn an angeboten werden
  • Auswahl an Filtermöglichkeiten soll sich an den Elementen von DataCite orientieren
  • Datensätze von VA sollen georeferenziert dargestellt werden, Möglichkeit zu georeferenzierter Suche ist aber wichtiger als georeferenzierte Visualisierung, die bereits durch VA selbst geleistet wird
  • an sprachunabhängiger Suche wird gearbeitet (Suche nach „Butter“ findet „Butter“, „burro“, „beurre“ …)
  • Material muss downloadbar und veränderbar sein
  • für VA wäre wichtig: Auffindbarkeit, feine Granulierung und luzide Beschreibung des Materials (ähnlich https://data.ub.uni-muenchen.de/110/)
  • Auswahl des Materials soll sich an Metadaten orientieren, die in DataCite vorliegen; zunächst sollen Daten ausgewählt werden, die sich bezüglich Georeferenz decken; danach soll der Nutzer die Möglichkeit erhalten, die Daten in gesonderter Umgebung (mit Python/R etc.) zu entpacken/explorieren/statistisch auszuwerten. – Ähnliches leistet bereits https://www.max.gwi.uni-muenchen.de/
  • Format der Daten: CSV, evtl. auch XML
  • Partnerprojekte von GeRDI müssen bestimmte Metadaten mitteilen: Georeferenzierung, Chronoreferenzierung, Zuordnung zu groben Bereichen
  • Mögliche Gestaltung der Suchanfragen: Zeiteinschränkung, Ortseinschränkung, Schlagwort

Metadatenschema

  • Bislang nur das Standard-Set des DataCite-Schemas implementiert
  • Metadatenschemata von verschiedenen Disziplinen werden zunächst angeschaut und dann auf entsprechende Töpfe verteilt: DataCite, Extension, Disziplin-spezifisch etc.
  • die gelieferten Metadaten sollen einem gewissen Standard entsprechen
  • Grundlage soll das Formular zur Vergabe von DataCite sein; erst wenn bestimmte Felder ausgefüllt sind, sind Metdaten akzeptabel

 

TOP 2: Statusbericht GeRDI 0.2 und 0.3

GeRDI 0.2:

  • weitere Repositorien wurden eingebunden
  • weitere Filterfunktionen wurden implementiert

GeRDI 0.3:

  • v.a. Verbindung von Oberfläche mit Backend steht im Mittelpunkt

TOP 3: Nächste Planungen GeRDI 0.4

  • kontrolliertes Vokabular für Verwendung in Metadatenschemata wie DataCite
  • Suche und Filterung anhand disziplin-spezifischer Metadaten
  • weitere Repositorien einbinden
  • Download der Suchergebnisse auf lokale Festplatte
  • Aufbau eines Jupyter-Hubs (-> für nachgelagerte Analyse von Projektdaten ähnlich https://www.max.gwi.uni-muenchen.de/)

TOP 4: Vorbereitungen Community Workshop

Für den Community Workshop sind soweit alle Vorbereitungen bereits getroffen.

TOP 5: VA-Datenexport

  • Daten sollen feingranuliert in 4erlei Gestalt an die UB ausgegeben werden: morpholexikalische Typen, Konzepte, Ortschaften, Einzelbelege
  • für jeden einzelnen Datensatz wird eine einzelne Datei erzeugt, die jeweils mit einem Buchstaben (A= Ortschaften, C=Konzepte, L=morpholexikalische Typen) und einer Identifikationsnummer  versehen wird
  • für jeden einzelnen Datensatz wird ein DataCite-Metadatensatz erzeugt; auf diesem Wege landen die Metadaten (nach einem Mapping ins MARC-Format) auch im Bibliothekskatalog (OPAC)
  • VA spricht sich für die Etablierung von Normdaten (GND) für morpholexikalische Typen aus; Teil der GND ist die ID, die auf genau einen Datensatz verweist; analog soll dies auch für Konzepte erfolgen
  • eine DOI erhalten: morpholexikalische Typen, Konzepte, Ortschaften, Einzelbelege und der gesamte Datensatz (VA_DUMP)
  • die genaue Granularität der Daten muss noch diskutiert werden; evtl. gibt es zum Thema „Data granularity“ eine Empfehlung von Interessensgruppen der RDA (Research Data Alliance https://www.rd-alliance.org/); Herr Weber schlägt vor, dort mal nachzufragen
  • spätestens ab November soll GeRDI die OAI-PMH-Schnittstelle von Open Data LMU ansprechen können

Second community workshop GeRDI (16. Mai 2019, Berlin)

Ort: DFN-Verein e.V., Alexanderplatz 1, 10178 Berlin

Zeit: 10:00 – 16:00 Uhr

Allgemeines

  • Start von GeRDI II ist für Ende dieses Jahr/Anfang nächstes Jahr geplant
  • Verlängerungsantrag wurde bereits eingereicht
  • bisher implementierte Funktionen von GeRDI: Search, Bookmark, Store (Jupyter Hub storage) –> aktuell wird an den Funktionen „Process“ und „Analyze“ gearbeitet (entsprechend dem research data life cycle model)
  • Ziel ist es, insgesamt 15 Repositorien einzubinden (derzeit sind es 12)
  • die angestrebte Menge an Metadaten, die integriert werden sollen, wurde bereits überschritten (geplant waren 700.000, derzeit sind es bereits 875.000 metadata records)
  • Ziele für die nächste Projektphase: stakeholders + community building, services based on federation, disciplinary metadata, Europe-wide visibility of research data from Germany (FAIR), consideration of the NFDI (= Nationale Forschungsdateninfrastruktur)

Sessions

(Session A) fand parallel zu Session B) und Session C) parallel zu Session D) statt, CM besuchte Session B) und D) )

A) Data workflows & data pipelines

Using the research data life cycle as a model, we will demonstrate how researchers can use GeRDI services to support their individual data handling strategies.

We would like to understand if this workflows and APIs can be formulated in a generic way covering a wider range of research disciplines or – alternatively – if „data pipelines“ should model discipline-specific data handling strategies. By thinking together with you about specific use cases we will create design sketches for possible new GeRDI functions.

B) Extending GeRDI Metadata Schema with disciplinary metadata elements

This session will address disciplinary metadata elements. Participants will discover the current state of the GeRDI Metadata Schema and how it is used in different GeRDI services. In an exemplary mapping demonstration the participants will be exposed to the process of extending the metadata schema. In a discussion we will try to identify high-priority metadata elements from participating communities. Other discussion topics include the usage of controlled vocabularies and the re-use of metadata elements across communities.

C) How to design: Submit service

During this session we will work together on design the new GeRDI service. We will go through discussing the existing use case, extend and value them. Then will bring our idea to paper discuss them and find the possible solutions for the future implementation. We eager to find out, how such service could be supported through GeRDI, which use cases, are most important and what challenges there are. To get the result we will dive into the different techniques of design thinking method.

D) Improving data quality in research data infrastructures

This session will address the term data quality and its relevance in research. Participants will explore criteria describing and measuring data quality that datasets can be effectively compared and ranked. Learn common criteria and how the scientific domains differ in their quality requirements for data. In a discussion, we will analyze the incentives to motivate data creators as well as the interventions needed to increase the quality of datasets. In the end, the elaborated measures will be assessed and recommendations for research data infrastructures will be made.

Zu Session B): high-priority metadata

  • aufgeteilt auf die verschiedenen Disziplinen (Humanities, Life sciences, Natural Sciences) sollte jede Community bezogen auf ihre einzelnen use cases die jeweiligen high-priority Metadaten nennen (für VA: concepts, morpho-lexical types, single attestations, municipalities)
  • es wurde geschaut, über welche Metadaten die Daten der einzelnen Communities am besten miteinander verknüpft werden können
  • wahrscheinlichster Verknüpfungspunkt der Metadaten der einzelnen Communities ist die Georeferenz der Metadaten, da dieses Metadatum überall vorkommt

Zu Session D): data quality (of metadata)

Frage: Woran kann Datenqualität festgemacht/gemessen werden?

Folgende Punkte wurden erarbeitet:

  • availability of metadata
  • metadata completeness
  • granularity
  • trust in the source of data
  • definition of data quality depends on research question
  • description in natural languages
  • responsibility within community
  • community building

Fazit:

  • fast unmöglich, generisch zu definieren, woran Datenqualität festgemacht werden kann (außer den FAIR-Kriterien)
  • am Community workshop kam man zu dem Schluss, dass man das offen lässt und stattdessen der Community die Möglichkeit gibt, fehlende Metadaten nachzutragen
  • laut Prof. Klaus Tochtermann sollen zudem die Empfehlungen für Datenqualität des RFII (= Rat für Forschungsdateninfrastruktur, NFDI ist daraus entstanden) befolgt werden

 

Sprachkontakt im Spiegel der VerbaAlpina-Datenbank (VA_DB) (Zitieren)

Stephan Lücke
(4056 Wörter)

Die folgenden Ausführungen sind als Ergänzungen zum Vortrag von Thomas Krefeld zu verstehen. Überschneidungen und Wiederholungen sind dabei nicht ganz ausgeschlossen. Der Focus liegt im Folgenden den tendenziell eher quantifizierenden Methoden, die speziell die Datenbank von VerbaAlpina, VA_DB, an die Hand gibt.

Komplementär zur Notwendigkeit, jeden einzelnen Basistypen gewissermaßen qualitativ in der Stratigraphie des alpinen Sprachraums zu lokalisieren, wie im Beitrag von Thomas Krefeld gezeigt werden sollte, lässt sich schon quantitativ grundsätzlich feststellen, dass sämtliche im Alpenraum verbreiteten morpholexikalischen Typen, die unterschiedlichen Sprachfamilien angehören, jedoch auf gemeinsame Basistypen zurückgehen, einen wie auch immer gearteten Sprachkontakt voraussetzen. Dasselbe gilt für alle vorrömischen oder lateinischen Basistypen, die ihren Weg in das Germanische oder Slawische gefunden haben, jedoch natürlich nicht für lateinische Basistypen, die ins Romanische gewandert sind.

Als Basistypen definiert VerbaAlpina den jeweils ältesten fassbaren morpholexikalischen Typen, dem erkennbar eine bestimmte lexematische Wurzel innewohnt. In Betracht kommen dabei im Wesentlichen Wörter aus dem Lateinischen, dem vorrömischen Substrat, dem Griechischen, dem Keltischen, dem Germanischen und dem Slawischen. Sofern möglich, erfolgt eine Identifizierung in einem definierten Referenzwörterbuch, wie z.B. dem lateinischen Wörterbuch von Karl Ernst Georges.

VerbaAlpina verwaltet sämtliche sprachbezogenen Daten in einer Vielzahl von Tabellen, die in ihrer Gesamtheit eine relationale Datenbank bilden. In einer dieser Tabellen sind die Basistypen versammelt. Die Tabelle dokumentiert neben der Orthographie eines Basistypen auch dessen Sprachzugehörigkeit, sowie, demnächst, auch den Verweis auf eventuelle Einträge in einem der Referenzwörterbücher.

Die Zuordnung zu den aktuell im Alpenraum verbreiteten morpholexikalischen Typen erfolgt, wie in relationalen Datenbanken üblich, durch die Zuordnung von Identifikationsnummern, sog. IDs. Im einfachsten Fall sieht eine solche Zuordnung folgendermaßen aus:

Die Tabelle der Basistypen enthält den Eintrag „butyru(m) (lat)“:

ID_Basistyp Basistyp
128 butyru(m) (lat)

Die Tabelle der morpholexikalischen Typen ist ganz ähnlich strukturiert. Auch in ihr ist jeder Eintrag durch eine ID eindeutig identifiziert:

ID_Morphtyp Morphtyp
591 beurre / burro

Im einfachsten Fall erfolgt die Zuordnung eines Basistypen zu einem Morphtypen durch die Eintragung der ID des Basistypen in ein eigenes Feld in der Tabelle der Morphtypen:

ID_Morphtyp Morphtyp ID_Basistyp
591 beurre / burro 128

Speziell im Fall der deutschen Komposita kann es vorkommen, dass ein Morphtyp nicht nur einem, sondern auch zwei Basistypen zugeordnet ist. Dies ist z.B. der Fall beim deutschen Wort Alphütte. Es geht zum einen zurück auf den Basistypen „alpes“ und zum anderen auf den Basistypen „hutta„. In der strukturierten Abbildung im Tabellenformat stellt sich dies wie folgt dar:

ID_Basistyp Basistyp
53 alpes (vor)
48 hutta (ger)
ID_Morphtyp Morphtyp ID_Basistyp
7 Alphütte 53, 48

Die verkettete Eintragung der beiden IDs der Basistypen in der Tabelle der Morphtypen ist ungünstig. Aus diesem Grund erfolgt die Verwendung einer Zwischentabelle, in der die Kombination der Identifikationsnummern eingetragen wird:

ID_Morphtyp ID_Basistyp
7 48
7 53

Die Datenbank erledigt die logische und synoptische Kombination dieser nun insgesamt drei Tabellen, was schließlich zu folgender Darstellung führt:

ID_Morphtyp Morphtyp ID_Basistyp Basistyp
7 Alphütte 53 alpes (vor)
7 Alphütte 48 hutta (ger)

Ebenso wie jedem Basistypen ist auch jedem morpholexikalischen Typen eine Sprache zugeordnet. Die jeweilige Zugehörigkeit ist in den Datenbanktabellen als eigenes Merkmal registriert und kann in die gezeigte synoptische Verknüpfung mit eingebunden werden:

ID_Basistyp Basistyp Sprache_Basistyp ID_Morphtyp Morphtyp Sprache_Morphtyp
724 thûmo goh 639 dûmli(n)ge(n) ger
336 caldaria lat 2400 chaudière / caldaia rom
392 campus lat 525 ciampei rom
478 klětь sla 1714 klet sla
1165 prīmus lat 6519 prime / primo rom

Die Identifikationsnummern dienen nur der korrekten Zuordnung und können in der Darstellung einfach weggelassen werden, so dass sich ein übersichtlicheres Bild ergibt:

Basistyp Sprache_Basistyp Morphtyp Sprache_Morphtyp
*þūmōn ger dûmli(n)ge(n) ger
caldaria lat chaudière / caldaia rom
campus lat ciampei rom
klětь sla klet sla
prīmus lat prime / primo rom

In dem so strukturierten Datenbestand kann nun gezielt nach Sprachkontaktphänomenen gesucht werden. Die Kriterien sind von Thomas Krefeld bereits vorgestellt worden. In etwas formalisierter Schreibweise lassen sie sich vor dem Hintergrund der soeben vorgestellten Datenstruktur wie folgt darstellen:

Einfaches Muster: Ein Basistyp aus einer Sprachfamilie geht in eine andere Sprachfamilie über:

  • lateinisch/romanischer Basistyp -> germanischer Morphtyp
  • lateinisch/romanischer Basistyp -> slawischer Morphtyp
  • germanischer Basistyp -> slawischer Morphtyp
  • slawischer Basistyp -> germanischer Morphtyp

Komplexes Muster: Ein Basistyp aus einer Sprachfamilie geht in mehrere andere Sprachfamilien über:

  • lateinisch/romanischer Basistyp -> germanischer und slawischer Morphtyp
  • lateinisch/romanischer Basistyp -> romanischer und germanischer und slawischer Morphtyp

Für die Identifizierung dieser Muster im relationalen Datenformat formuliert man die Bedingung, dass die Felder Sprache_Basistyp und im Feld Sprache_Morphtyp bestimmte Werte aufweisen müssen. Die Datenbanksprache SQL basiert dabei auf dem Englischen. Für das Auffinden von lateinischen Basistypen, die ins Germanische gewandert sind, schreibt man z.B.:

... where sprache_basistyp = 'lat' and sprache_morphtyp = 'ger'

Das Ergebnis sieht dann wie folgt aus (Ausschnitt):

Basistyp Sprache_Basistyp Morphtyp Sprache_Morphtyp
*brŏcca lat Britschger ger
unguere lat Anke ger
cūpella lat Kübel ger
caseu(m) lat Käsestängel ger
camera lat Milchkammer ger
butyru(m) lat Butter ger
unguere lat Ankentutel ger

Selbstverständlich lassen sich die entsprechenden Ergebnisse zählen und damit auch weitere Berechnungen anstellen. So ist es z.B. möglich zu berechnen, wie häufig lateinische Basistypen in germanischen Morphtypen vertreten sind, die einer bestimmten Konzeptdomäne zugeordnet sind. Solche und ähnliche statistische Analysen sind aktuell als Themenvorschläge für Studentenpraktika am Institut für Statistik der Ludwig-Maximilians-Universität ausgeschrieben.

Für die Identifizierung der etwas komplexeren Fälle, in denen ein Basistyp seinen Weg in mehrere andere Sprachfamilien gefunden hat, muss der Datenbestand nach Basistypen gruppiert und die verknüpften morpholexikalischen Typen sowie deren Sprachzugehörigkeit konkateniert abgebildet werden:

Die präsentierten Beispiele können im Einzelfall durchaus noch Fehler enthalten, die auf inkorrekten Identifizierungen von Basistypen basieren. Diese werden im Laufe der Arbeit am Material beseitigt werden. Es geht hier im Moment nur darum, die Methodik vorzuführen.

Aktuell sind insgesamt 14 Basistypen in allen drei Sprachfamilien vertreten, 32 im romanischen und germanischen Sprachraum, 28 im romanischen und slavischen sowie 7 im germanischen und slavischen. Hinzu kommen derzeit 32 weitere Basistypen, die ausschließlich entweder ins Germanische oder ins Slavische übergegangen sind.

Das bislang von VerbaAlpina verwendete Datenmodell besitzt durchaus noch seine Schwächen. Bislang ist es nur möglich, einen morpholexikalischen Typen an einen bestimmten Basistypen zu binden. Als Beispiel seien der germanische morpholexikalische Typ „Käser“ und der romanische Typ „casera“ genannt. Die folgende Karte zeigt die Verbreitung des germanischen morpholexikalischen Typen Käser (grün) und des romanischen Typen casera (gelb):

Beide Typen sind zweifelfsfrei vom lateinischen casearius herzuleiten, das seinerseits wiederum mit caseus zusammenhängt. Somit stellt sich die Frage, für welchen Basistypen man sich entscheidet: casearius oder caseus. Derzeit sind beide morpholexikalischen Typen mit dem Basistyp caseus verbunden, was sie mit anderen morpholexikalischen Typen wie z.B. dem deutschen Käse verbindet. Daraus ergibt sich eine gewisse Asymmetrie, besteht doch eine engere Verbindung zwischen Kaser und casera als etwa zwischen Kaser und Käse. Würde man nun Kaser und casera den Basistypen casearia zuweisen, ginge wiederum der offenkundig auch vorhandene Zusammenhang mit Käse verloren. Wie damit umzugehen ist, ist noch nicht entschieden. Eine Möglichkeit bestünde darin, die Abbildung der Basistypen im Datenschema weiter zu differenzieren, also etwa zu dokumentieren, dass das lateinische casearius mit caseus verbunden ist.

Die Grenze zwischen den Verbreitungsgebieten der beiden morpholexikalischen Typen verläuft ziemlich exakt entlang der Grenze zwischen dem germanischen (grün) und dem romanischen (rot). Hinzu kommen weitere Gebiete wie natürlich das slawische sowie eine Reihe von Übergangszonen und Enklaven, in denen aktuell Mehrsprachigkeit herrscht. Die Definition der Sprachzugehörigkeit erfolgt im Datenbestand von VerbaAlpina auf Gemeindeebene. Bislang erfolgte die entsprechende Zuweisung mehr oder minder intuitiv. Demnächst orientiert sich die entsprechende Definition an der Sprachzugehörigkeit der Informanten, von denen die Belege aus einer Gemeinde stammen. Sobald für eine Gemeinde Informanten registriert sind, die unterschiedlichen Sprachfamilien zuzuordnen sind, erhält die entsprechende Gemeinde den Status der Mehrsprachigkeit. Auf diese Weise ist eine transparente und belastbare Regelung für die Feststellung von Ein- oder Mehrsprachigkeit gefunden. Durch die Chronoreferenzierung der von VerbaAlpina gesammelten Daten lassen sich, wenigstens theoretisch, auch Veränderungen im Verlauf der Sprachgrenzen dokumentieren und visualisieren. Die Aussagekraft der entsprechenden Analyseergebnisse hängt aber natürlich von der Dichte und der Homogenität des gesammelten Datenmaterials ab.

Ich möchte die Gelegenheit nutzen und auf neuere Entwicklungen im Projekt VerbaAlpina hinzuweisen.

Seit kurzem ist es möglich, auf der interaktiven online-Karte von VerbaAlpina nicht nur die über das Menü abrufbaren Kategorien kartieren zu lassen, sondern auch nahezu beliebige andere analytische Abfrageergebnisse.

Aufruf des Formulars für die Eingabe von SQL-Statements

Als Beispiel kann hier die Kartierung der morpholexikalischen Typen vorgeführt werden, die mit Basistypen verbunden sind, die sowohl im germanischen wie auch im slavischen Sprachraum verbreitet sind.

Qualitative Darstellung der Verteilung von morpholexikalischen Typen, denen Basistypen zugrunde liegen, die sowohl im germanischen wie auch slawische Sprachraum verbreitet sind (Link zur Karte: https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=xxx&tk=1533)

Die synoptische Überlagerung der Sprachfamiliengebiete und der Verbreitung der Basistypen kann aufschlussreiche Muster ergeben, muss dies aber natürlich nicht zwingend. Es bietet sich daher an, auf der Suche nach aussagekräftigen Mustern durch Veränderung der Parameter immer neue Kartierungen zu erzeugen. Allerdings stoßen manche Kartierungsversuche an natürliche Grenzen. So ist das System z.B. mit der Kartierung der Verbreitung von morpholexikalischen Typen, die sowohl im romanischen als auch im germanischen Sprachraum verbreitet sind, noch überfordert. Die entsprechende Kartierung auf Basis der Gemeinden, für die entsprechende Belege vorliegen, würde insgesamt über 1400 Kartensymbole umfassen. Der Nutzen einer Kartierung mit einer derart hohen Anzahl von Kartensymbolen wäre ohnehin sehr begrenzt. Eine quantifizierende Darstellung der Ergebnisse, die auf der online-Karte von VerbaAlpina ebenfalls möglich ist, könnte jedoch einen guten Überblick liefern. Die nachfolgende Karte zeigt die quantifizierende Abbildung der oben dargestellten qualitativen Karte auf Basis von Verwaltungseinheiten mittlerer Größe (sog. NUTS3-Regionen). Die Farbgebung der einzelnen Regionen orientiert sich an der Anzahl von Belegpunkten innerhalb der Regionen.

Quantifizierende Darstellung der Verteilung von morpholexikalischen Typen, denen Basistypen zugrunde liegen, die sowohl im germanischen wie auch slawische Sprachraum verbreitet sind (Link zur Karte: https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=xxx&tk=1531)

Neben der kartographischen Abbildung der Analyseergebnisse bietet die Datenbank auch rein arithmetisch-statistische Analysemöglichkeiten. So ließe sich z.B. die Frage stellen, ob ganz bestimmte Konzeptdomänen besonders häufig mit morpholexikalischen Typen verbunden sind, die über die Grenzen von Sprachfamilien hinweg verbreitet sind.

Bereits jetzt sind statistische Analysen dieser Art mit dem Datenbestand in der VerbaAlpina-Datenbank möglich. Aktuell sind dafür noch Kenntnisse in der Abfragesprache SQL nötig. Künftig sollen jedoch auch spezifisch statistische Tools wie z.B. das weit verbreitete Statistikprogramm R zur Verfügung stehen.

VerbaAlpina steht in Verbindung mit den Entwicklern der Platform MAX, die derzeit in Kooperation zwischen der Kunstgeschichte und der Statistik an der LMU entwickelt wird.

Screenshot aus dem statistischen Analysetool MAX (https://dhvlab.gwi.uni-muenchen.de/max/)

MAX soll primär der statistischen Analyse von Museumsbeständen dienen. Das System ist jedoch so ausgelegt, dass damit im Grunde beliebige relational strukturierte Datensätze mit statistischen Methoden untersucht werden können. Innerhalb von VerbaAlpina soll demnächst ein abgeschlossener Bereich entstehen, der den Partnern von VerbaAlpina zur Verfügung gestellt wird. Innerhalb dieses Bereichs können dann neben den VerbaAlpina-Daten auch persönliche Daten und auch beide in Kombination statistisch analysiert und kartographisch visualisiert werden. VerbaAlpina bezeichnet diesen abgeschlossenen Bereich als „Forschungslabor“. Eine wesentliche Funktionalität dieses Forschungslabors wird die Möglichkeit zum Teilen von Daten, Visualisierungen und Analysen sein, in etwa in der Art, wie man es schon von zahlreichen Diensten im Internet wie z.B. Google und Facebook kennt. Die im Rahmen des MAX-Projekts entwickelten Funktionalitäten zur statistischen Datenanalyse sollen in das VerbaAlpina-Forschungslabor integriert werden.

Ich danke Ihnen für Ihre Aufmerksamkeit.



-- Verknüpfung zwischen Basis- und Morphtypen
select * from basistypen a
join vtbl_morph_basistyp b using(id_basistyp)
join morph_typen c using (id_morph_typ)
;
-- Morphtypen, die mehr als einem Basistypen zugeordnet sind.
select 
 group_concat(distinct c.Orth) as Morphtyp,
 group_concat(a.Orth) as Basistypen
from basistypen a
join vtbl_morph_basistyp b using(id_basistyp)
join morph_typen c using (id_morph_typ)
group by id_morph_typ
having count(*) > 1
;
-- Basistyp butyru(m) und Morphtyp beurre / burro
select 
 a.ID_Basistyp,
 concat(a.Orth, ' (', a.Sprache, ')') as Basistyp,
 c.ID_morph_Typ as ID_Morphtyp,
 c.Orth
from basistypen a
join vtbl_morph_basistyp b using(id_basistyp)
join morph_typen c using (id_morph_typ)
where c.Orth like '%burro%'
limit 1
;
-- Beispiel für die kombinierte Darstellung von Basistypen und
-- morpholexikalischen Typen samt jeweiliger Sprachzuordnung

select
-- a.ID_Basistyp,
a.Orth as Basistyp,
a.Sprache as Sprache_Basistyp,
-- c.ID_morph_Typ as ID_Morphtyp,
c.Orth as Morphtyp,
c.Sprache as Sprache_Morphtyp
from basistypen a
join vtbl_morph_basistyp b using(id_basistyp)
join morph_typen c using (id_morph_typ)
where a.Orth in ('caldaria','klětь','prīmus','*þūmōn','campus')
group by a.Orth
-- order by rand()
limit 5
;
-- Anzahl von Basistypen, die in mehreren Sprachfamilien vertreten sind

select morphtyp_sprachen, count(*) as Anzahl from
(
select
 a.Orth as Basistyp,
 a.Sprache as Basistyp_Sprache,
 group_concat(distinct c.Orth, ' (', c.Sprache, ')' order by c.Sprache, c.Orth separator ' | ') as Morphtypen,
 group_concat(distinct c.Sprache order by c.Sprache) as Morphtyp_Sprachen
from basistypen a
join vtbl_morph_basistyp b using(id_basistyp)
join morph_typen c using (id_morph_typ)
group by a.Orth, a.Sprache
having group_concat(distinct c.Sprache) like '%,%'
-- order by char_length(group_concat(distinct c.Sprache)) desc, group_concat(distinct c.Sprache)
) sq
group by morphtyp_sprachen
;
-- Vorrömische und lateinische Basistypen, die entweder ins Germanische 
-- oder ins Slavische gewandert sind

select 
 a.Orth as Basistyp, 
 a.Sprache as Sprache_Basistyp, 
 group_concat(distinct c.Sprache) as Sprache_Morphtyp, 
 c.Orth as Morphtyp
from basistypen a
join vtbl_morph_basistyp b using(Id_Basistyp)
join morph_typen c using(ID_morph_Typ)
where 
 a.Sprache like 'lat' 
 or a.Sprache like 'vor'
group by a.Orth
having 
 group_concat(distinct c.Sprache) not like '%rom%'
 and group_concat(distinct c.Sprache) not like '%,%'
;

 

Der öffentlich zugängliche Teil von VerbaAlpina, gleichsam das Schaufenster des Projekts, präsentiert sich auf einem Internet-Portal unter der Adresse www.verba-alpina.gwi.uni-muenchen.de. Dort findet sich mit der interaktiven Online-Karte auch der zentrale Zugang zu dem von VerbaAlpina gesammelten Material. Die Karte erlaubt im Wesentlichen die Visualisierung der Verbreitung bestimmter morpholexikalischer Typen, wobei die Wahlmöglichkeiten auf die technisch implementierten Filterfunktionen beschränkt sind. Die Auswahl kann entweder aus semasiologischer oder aus onomasiologischer Perspektive erfolgen, die Kartierung der Sprachdaten kann außerdem noch kontrastiv ergänzt werden um Daten der „sprachbezogenen Peripherie“ wie etwa die Fundstellen antiker lateinischer Inschriften im Alpenraum. Neben der qualitativen Abbildung der Daten ist nach Auswahl einer arealen Gliederung auch die arealbezogene quantifizierende Abbildung der Daten möglich.

Sämtliche auf der Karte darstellbaren Daten werden im Hintergrund in einer relationalen MySQL-Datenbank verwaltet. Diese Datenbank bietet eine Vielzahl an Möglichkeiten der Datenanalyse, die deutlich über die Optionen hinausgehen, die auf der Karte zugänglich sind. Der unmittelbare Zugang zur VerbaAlpina-Datenbank (VA_DB) erfolgt u.a. über ein generisches Web-Interface (PhpMyAdmin). Daneben sind auch andere, teils komfortablere und schnellere Zugangsarten möglich, etwa unter Verwendung sog. Client-Programme wie z.B. MySQL-Workbench oder HeidiSQL. Die direkte Nutzung von VA_DB ist den Kooperationspartnern von VerbaAlpina vorbehalten. Von Vorteil ist die Kenntnis einer speziell für relationale Datenstrukturen entwickelten Programmiersprache namens SQL. Erst der souveräne Umgang mit dieser Sprache gestattet es, das Potential des VerbaAlpina-Datenbestands voll auszuschöpfen. Im Folgenden soll anhand exemplarischer Analysen, die speziell auf die Dimension des Sprachkontakts fokussieren, eine Vorstellung von den Möglichkeiten gegeben werden.

VA_DB enthält unter anderem zwei Tabellen, in denen die ansonsten hauptsächlich aus informatischen und technischen Gründen auf eine Vielzahl von Detailtabellen verteilten Daten gleichsam wie in einem Brennglas gebündelt sind. Eine der beiden Tabellen enthält die Sprachdaten, die andere die der sprachbezogenen Peripherie. Beide Tabellen repräsentieren Instanzen der Schnittstelle VAP (= VA ⇒ Partner) und tragen den Namen vap_ling_de bzw. vap_geo_de. Jede der beiden Tabellen liegt in mehreren Sprachversionen vor (vap_ling_it, vap_ling_fr, vap_ling_slo …).

Ausschnitt aus der Schnittstelle vap_ling_de

Die Schnittstelle vap_ling ist eine Tabelle mit einer Vielzahl an Spalten, die sich bezüglich ihres Inhalts in sechs Gruppen unterteilen lassen:

-- 1) Referenzsystem: Angaben zur Herkunft eines Sprachbelegs
Id_Beleg
Beleg
Quelle_Beleg
Sprache_Informant
Publikationsjahr
Erhebungsjahr

-- 2) Bedeutung des Belegs: Konzeptzuweisung
Name_Konzept
Beschreibung_Konzept

-- 3) Typisierung: Klassifizierung der Sprachbelege (Morpholexikalischer Typ, phonetischer Typ)
Art_Typ
Typ
Sprache_Typ
Wortart
Affix
Genus
Referenz_Typ
Quelle_Typisierung

-- 4) Ursprung des Typs
Basistyp
Basistyp_Unsicher
Etymon
Sprache_Etymon

-- 5) Georeferenzierung
Breitengrad
Laengengrad
Gemeinde

-- 6) Sonstiges
Bemerkungen

Die Gruppe 1) enthält das sog. Referenzsystem, das in erster Linie Angaben zur Herkunft des in der Spalte `Beleg` gespeicherten Einzelbelegs beinhaltet. Generell stammen alle bislang in VA_DB gesammelten Einzelbelege aus Sprachatlanten, georeferenzierten Wörterbüchern oder von der sog. Crowd, also von Informanten, die Sprachdaten über das im Internet zugängliche Crowd-Sourcing-Tool beigesteuert haben. Die Einzelbelege werden nach Möglichkeit in IPA-Gestalt, der phonetischen Referenztranskription von VA, abgebildet. Die Daten in dieser Gruppe 1) enthalten auch Informationen zur Chronoreferenzierung, die schließlich für Analysen im Hinblick auf den Sprachwandel von großem Interesse sein können. In den meisten Fällen ist diese Chronoreferenzierung von den Publikationsjahren der Sprachatlanten und Wörterbücher bzw. von den Zeitpunkten der dahinterstehenden Erhebungen abgeleitet, die von sehr unterschiedlicher Genauigkeit sein können. Im Fall des AIS z.B. sind die Erhebungsdaten häufig auf den Tag genau dokumentiert, in anderen Fällen lassen sich lediglich Zeiträume von mehreren Jahren feststellen.

Die Gruppe 2) dient der Dokumentation des Konzeptes, das mit dem Einzelbeleg im konkreten Fall bezeichnet wird. Die Gruppen 3) bis 5) enthalten dem Einzelbeleg von den Mitarbeitern von VerbaAlpina zugewiesene sprachliche Klassifizierungen. Im Mittelpunkt steht dabei die Identifizierung der morpholexikalischen Typen, die über die Attribute „Orthographie“ (= Typ), „Sprachzugehörigkeit“, „Wortart“, „Affigierung“ und „Genus“ definiert sind. Im Feld `Referenz_Typ` sind Verweise auf Lemmata in bestehenden Wörterbüchern wie etwa dem Duden, dem schweizerdeutschen Idiotikon oder auch der italienischen Treccani eingetragen.

Die Gruppe 4) enthält Informationen zur Herkunft eines morpholexikalischen Typs. Die Kategorie „Basistyp“ wurde eingeführt, weil es vielfach nicht möglich ist zu entscheiden, auf welchem Weg ein offenkundiger lexikalischer Vorläufer eines morpholexikalischen Typs schließlich in diesen eingeflossen ist. Grundsätzlich kann dabei das klassische Szenario im Sinne eines Etymons vorliegen, ein Typ sich also über die Zeit in einer homogenen Sprachgemeinschaft aus einer älteren Vorstufe entwickelt haben. Daneben besteht jedoch auch die Möglichkeit der Entlehnung im Rahmen einer Sprachkontaktsituation. Auch die unabhängige Entwicklung zweier offenkundig miteinander verwandter morphlexikalischer Typen in unterschiedlichen Sprachfamilien aus einem gemeinsamen Vorläufer gehört hierher. Die Kategorie Basistyp lässt eine Entscheidung in dieser Hinsicht bewusst offen.

Die Gruppe 5) schließlich leistet die geographische Verankerung der sprachlichen Einzelbelege.

Die hier aufgespannte und kurz skizzierte Matrix bietet nun eine Vielzahl von Ansätzen für analytische Berechnungen, die u.a. mit der Datenbanksprache SQL durchgeführt werden können. Vor dem Hintergrund der Frage nach Sprachkontaktphänomenen und ihren Reflexen in den VerbaAlpina-Daten bietet sich zunächst eine Analyse der sprachgrenzüberschreitenden Verbreitung der bislang registrierten Basistypen an.

Die Dimension des Sprachkontakts spiegelt sich in den VerbaAlpina-Daten zunächst in der Zuweisung von Sprachfamilien auf den folgenden Ebenen. So ist

  • jeder Gemeinde,
  • jedem Informanten
  • und jedem morpholexikalischen Typ

eine bestimmte Sprachfamilie zugeordnet. VerbaAlpina unterscheidet nicht zwischen Einzel- bzw. Nationalsprachen. Es existieren insgesamt 7 unterschiedliche Kategorien von Sprachgebieten. Zu den drei „homogenen“ Gebieten des Romanischen, Germanischen und Slawischen gesellen sich insgesamt vier Kategorien von Mischgebieten, die sich entweder entlang der Sprachgrenzen verteilen oder auch als Exklaven isoliert innerhalb eines fremden Sprachgebiets liegen. Die Zuweisung der einzelnen Gemeinden zu diesen Kategorien ist kaum objektiv durchführbar und ist im Einzelfall sicher diskussionswürdig. Dies gilt hauptsächlich für die erwähnten Mischkategorien, in denen Mehrsprachigkeit vorliegt, bzw. überhaupt für Regionen in der Nähe der Sprachgrenzen. So ist durchaus zu hinterfragen, weshalb die zimbrische Enklave von Lusern als rein germanisches Sprachgebiet klassifiziert ist, während die benachbarten Sette Comuni als romanisch-germanisches Mischgebiet gelten. Auch die Kategorisierung von Sappada als rein germanisches Sprachgebiet dürfte Widerspruch hervorrufen.

Die Zuweisung eines Informanten zu einer bestimmten Sprachfamilie basiert im Fall der retrodigitalisierten Sprachatlas- und Wörterbuchdaten entweder auf der Ausrichtung der Publikation oder auf spezifizierten Angaben innerhalb der Publikation. In den allermeisten Fällen gehören sämtliche Informanten eines Atlas‘ oder eines Wörterbuchs genau einer Sprachfamilie an. Einzige Ausnahme ist der ASLEF, dessen Informanten unterschiedlichen Sprachfamilien angehören, die jeweils angegeben sind (ger: 2 | rom: 140 | sla: 7). VerbaAlpina nutzt für den Ausgleich von Dateninkonsistenzen das sog. Crowdsourcing-Verfahren. In diesem Fall legen die sog. „Crowder“ ihre Sprachzugehörigkeit selbst fest.

Die Zuordnung eines morpholexikalischen Typs zu einer bestimmten Sprachfamilie ergibt sich unmittelbar aus der Sprachfamilienzugehörigkeit des Informanten, von dem der morpholexikalische Typ stammt. Eine abweichende Sprachfamilienzugehörigkeit zwischen Informant und seinen Äußerungen ist demnach nicht möglich.

Sosehr also die Zuweisung von Sprachfamilien auf einer der vorgestellten Ebenen im Einzelfall und speziell in der Nähe von Sprachgrenzen prekär sein mag, so nützlich ist diese Kategorisierung aufs Ganze gesehen und vor allem abseits der Übergangsregionen, also gleichsam im „Kernland“ der jeweiligen Sprachfamilien als Variable, deren Ausprägung als Parameter bei Datenanalysen Berücksichtigung finden kann.

Unabhängig von der vorgeführten Kategorisierung spiegelt sich die Dimension des Sprachkontakts vor allem auf der Ebene der sogenannten Basistypen wieder, die im Rahmen der Identifizierung der morphosyntaktischen Typen durch VerbaAlpina vorgenommen wird. Das Konzept des Basistyps erlaubt die Identifizierung einer lexematischen Basis, wie sie auch bei der Feststellung eines Etymons erfolgt, lässt dabei aber die Details des Zusammenhangs zwischen dem morpholexikalischen Typ und der lexematischen Basis zunächst offen. Als Beispiel seien die folgenden morpholexikalischen Typen genannt, die alle die lexematische Basis baita enthalten:

Die hier gelisteten insgesamt zwölf morpholexikalischen Basistypen enthalten offenkundig die selbe lexematische Basis. Die Aufstellung lässt jedoch nicht erkennen, ob sich einzelne der Vertreter direkt aus den anderen entwickelt haben, oder ob alle der gelisteten morpholexikalischen Typen auf einen gemeinsamen Vorläufer zurückgehen.

Fragen dieser Art lassen sich also zumindest mit der aktuell vorliegenden Datenstruktur in der VerbaAlpina-Datenbank nicht beantworten. Auf der anderen Seite ist es mit Hilfe der Datenbank jedoch möglich, sämtliche Basistypen aufzufinden, die mit morpholexikalischen Typen aus mehr als einer Sprachfamilie verknüpft sind. Die entsprechende Abfrage lautet:

-- SQL-Statement: Zeige alle Basistypen, die morphlexikalischen Typen in 
-- unterschiedlichen Sprachfamilien zugeordnet sind

select 
 a.Basistyp, 
 group_concat(distinct a.Sprache_Typ) as Sprachfamilien, 
 group_concat(distinct concat_ws(',',a.Typ, a.Sprache_Typ, a.Wortart, a.Affix, a.Genus) separator ' | ') as Morphtypen
from vap_ling_de a 
where 
 a.Art_Typ like 'morph_typ'
 and a.Basistyp is not null
group by a.Basistyp
having sprachfamilien like '%,%'
;

 

Das Ergebnis umfasst derzeit (Juni 2018) insgesamt 78 verschiedene Basistypen. Eine Gruppierung nach vorhandenen Sprachfamilienkonstellationen zeigt, dass zehn Basistypen in allen drei Sprachfamilien, 7 im germanischen und slavischen, 30 im romanischen und germanischen sowie 31 im romanischen und slavischen Sprachraum  verbreitet sind.

Bei der Interpretation dieser und aller anderen errechneten Zahlen ist natürlich stets die Zufälligkeit des bislang von VerbaAlpina erfassten Materials und die bestehende Beschränkung auf bestimmte Konzeptdomänen zu bedenken.

Die strukturierte Erfassung des Datenmaterials erlaubt weitergehende Gruppierungen. So kann z.B. festgestellt werden, welche Konzepte mit den sprachraumübergreifenden Basistypen verbunden sind.

Manche der Elemente der obigen Auflistung mögen auf den ersten Blick irritieren. So erscheint z.B. der aus dem Lateinischen stammende Basistyp mulgere neben der Kategorie der TÄTIGKEITEN, der man dieses Verb primär zuordnen würde, auch in den Kategorien GEBÄUDE und GEFÄßE. Dies erklärt sich bisweilen durch die Einbindung der Einzelelemente in Mehrwortlexien wie hier z.B. in bidone a mungere (EIMER). mulgere steckt jedoch auch in einer germanischen Bezeichnung für den VIEHSTALL AUF DER ALM, melchster, was das Auftreten von mulgere in der Kategorie GEBÄUDE erklärt.

 

 

 

select 
a.Beleg,
a.Art_Typ,
a.Typ,
a.Wortart,
a.Affix,
a.Genus,
a.Referenz_Typ

from vap_ling_de a

group by a.Beleg, a.Art_Typ, a.Typ, a.Wortart, a.Affix, a.Genus, a.Referenz_Typ
;

select * from z_ling where id_instance in

(
select id_beleg from vap_ling_de
where basistyp in
(
select
a.Basistyp
— group_concat(a.Beschreibung_Konzept separator ‚ | ‚),
— group_concat(distinct a.Sprache_Typ) as Sprachfamilien,
— group_concat(distinct concat_ws(‚,‘,a.Typ, a.Sprache_Typ, a.Wortart, a.Affix, a.Genus) separator ‚ | ‚) as Morphtypen
from vap_ling_de a
where
a.Art_Typ like ‚morph_typ‘ collate utf8mb4_general_ci
and a.Basistyp is not null
group by a.Basistyp
— , a.Beschreibung_Konzept
having group_concat(distinct a.Sprache_Typ) like ‚rom,ger‘ or group_concat(distinct a.Sprache_Typ) like ‚ger,rom‘
)
and art_typ like ‚morph_typ‘ collate utf8mb4_general_ci
group by gemeinde
)
group by id_community

VerbaAlpina – Aspekte der informatischen Konzeption und technischen Realisierung (Zitieren)

Stephan Lücke
(7420 Wörter)

Die folgenden Ausführungen ergänzen und exemplifizieren die Darlegungen von Thomas Krefeld zum sprachwissenschaftlichen Gesamtkonzept von VerbaAlpina (VA). Wiederholungen können dabei nicht vollständig ausgeschlossen werden. Im Zentrum stehen hier die Aspekte der informatischen Konzeption und der konkreten technischen Umsetzung.

VerbaAlpina gliedert sich aufs Ganze gesehen in zwei große Teilbereiche: Ein Datenbanksystem (VA_DB) und eine Webschnittstelle (VA_WEB) mit einer Reihe von Detailfunktionen, die im Folgenden vorgestellt werden. VerbaAlpina besitzt außerdem eine Reihe von Kooperationspartnern, von denen jeder eine eigene Datenbank (PVA) nutzen kann. Die dort gespeicherten Daten können in den Datenbestand von VA_DB einfließen und umgekehrt.

VA_DB

VerbaAlpina basiert im Kern auf einer MySQL-Datenbank, um die herum sich verschiedene Module und Funktionalitäten gruppieren.

Eine MySQL-Datenbank ist eine sog. relationale Datenbank, was, stark vereinfacht gesprochen, bedeutet, dass die dort abgelegten Daten in Tabellengestalt organisiert sind. Die Datenstrukturierung erfolgt nach ganz bestimmten Regeln, die vom sog. relationalen Datenmodell vorgegeben sind. Dieses besagt im wesentlichen, dass alle Daten, die in einer Tabelle versammelt werden, Vertreter ein und derselben „Objektklasse“ – ein und derselben „Entität“ – sein müssen. Dies hat zur Folge bzw. gleichermaßen zur Voraussetzung, dass alle in einer Tabelle gespeicherten Daten identische Eigenschaftskategorien aufweisen müssen. So wären beispielsweise in einer Tabelle, in der Informationen über Autos gespeichert werden sollen, Eigenschaftskategorien wie „Farbe“ oder „Höchstgeschwindigkeit“ sinnvoll. Eine Liste mit Personen in dieser Tabelle unterbringen zu wollen, wäre nicht möglich bzw. sinnlos. Sie müsste in einer eigenen Tabelle abgelegt werden, die Eigenschaftskategorien wie „Geburtsort“, „Geschlecht“ oder „Wohnort“ aufweisen würde. Es gibt noch eine Reihe weiterer Regeln, die bei der Anlage einer relationalen Datenbanktabelle beachtet werden müssen bzw. beachtet werden sollten. Dazu gehört z.B. das Gebot, dass eine Tabelle keine Redundanzen enthalten darf oder dass in einem Feld einer Tabelle jeweils nur „atomare“ Werte und keine Wertelisten abgelegt werden dürfen. Die schrittweise Anpassung einer Datenstruktur an das Idealbild des relationalen Datenmodells nennt man „Normalisierung“.

Die von VerbaAlpina gesammelten Daten werden also getreu den eben skizzierten Regeln in den Tabellen einer MySQL-Datenbank abgelegt. Die Strukturierung der Daten folgt dabei dem vom Projekt verfolgten Hauptinteresse: Welche Konzepte werden oder wurden zu welcher Zeit an welchem Ort mit welchen Wörtern bezeichnet? Dieser Satz gibt die Kategorien der zentralen Datenstruktur vor. In Gestalt einer relationalen Tabelle stellt sich der Untersuchungsgegenstand demnach folgendermaßen dar:

Konzept Bezeichnung wann wo
RAHM Rom 1962-2003 Sennwald
SENNHÜTTE Sennhaus 1985-2004 Hohenems
DREHBUTTERFASS Ankenkübel 1962-2003 Mollis
ZIEGENHIRT chevrier / capraio 2005 Romeno
ALMHÜTTE Käser 1965, 1969, 1971 Laces###D:Latsch
BIESTMILCH Biestmilch 2017 Ebenau
SCHEUNE feniera 1975, 1979, 1986 Reillanne
BUTTER rance / rancido 1928-1940 Ramosch
BAUERNHOF kmetija 2011ff. Železniki
EIMER lambar 2011ff. Dobrova-Polhov Gradec

Die Tabelle wirft sofort Fragen auf, deren Antworten wiederum an einer geeigneten Stelle innerhalb des vorgegebenen relationalen Datenmodells untergebracht werden müssen. So wäre z.B. zu fragen, aus welcher Quelle die entsprechende Information stammt. Im Fall von VerbaAlpina sind dies, zumindest bislang, überwiegend Sprachatlanten, z.T. auch Wörterbücher mit georeferenziertem Inhalt, daneben aber auch Daten, die über das Internet gesammelt wurden. Eine weitere Frage wäre, wo die genannten Ortschaften genau liegen, vielleicht auch wieviele Einwohner sie haben usw. All diese Daten würden also entweder in neue Spalten der  vorliegenden Tabelle oder auch, nötigenfalls, in neue Tabellen eingetragen werden. Im Fall der genannten Ortschaften bietet es sich schon deswegen an, sie in einer neuen Tabelle zu speichern, weil die meisten der Ortschaften in der Tabelle mit den Sprachbelegen mehrfach auftreten. Informationen zur geographischen Lage oder Einwohnerzahl müssten andernfalls in der Sprachdatentabelle mehrfach gespeichert werden, was dem Gebot der Redundanzvermeidung widersprechen würde.

Ein relationales Datenbankmanagementsystem wie MySQL erlaubt die problemlose Verknüpfung der auf verschiedene Tabellen verteilten, aber dennoch zusammengehörigen Daten.

Die Erfassung und Strukturierung der von VerbaAlpina bearbeiteten Daten wird auf diese Weise sehr schnell sehr komplex. Aktuell (Mai 2018) besteht die Datenbank von VerbaAlpina (VA_DB) aus

  • 128 Tabellen, die um
  • 12 sog. Views (virtuelle Tabellen)
  • 21 Funktionen und
  • 35 Prozesse

ergänzt werden. Eine Reihe dieser Datenbankobjekte haben jedoch eine rein technische Funktion oder sind temporär.

Die Organisation der Sprachdaten im relationalen Datenformat hat gegenüber der herkömmlichen Repräsentation in Sprachatlanten und Wörterbüchern entscheidende Vorteile. Während Sprachatlanten jeweils nur die onomasiologische Perspektive bedienen, also die Frage beantworten können, mit welchen Wörtern ein ausgewähltes Konzept bezeichnet wird, und Wörter umgekehrt ausschließlich darüber Auskunft geben, welche Konzepte von einer ausgewählten Vokabel bezeichnet werden können (semasiologische Perspektive), vereint das relationale Datenmodell beide Möglichkeiten in einem System.

Neben dem relationalen Datenformat existiert noch eine Reihe weiterer Datenformate wie z.B. XML, JSON oder Graphen (= Strukturen mit Knoten und Kanten). Für welches dieser Formate man sich entscheidet, liegt zum einen an den Eigenheiten des abzubildenden Gegenstands daneben aber durchaus auch an persönlichen Vorlieben. Grundsätzlich gilt, dass einmal strukturierte Daten, die in einem bestimmten Datenformat vorliegen, in andere Datenformate transformiert werden können. So ist es z.B. möglich, die Tabellen einer MySQL-Datenbank im XML-Format auszugeben. Die speziell für MySQL-Datenbanken entwickelte generische Webschnittstelle PhpMyAdmin (PMA) bietet für dieses und andere Datenformate vorgefertigte Exportroutinen. Im folgenden Beispiel werden gefilterte Daten aus der Tabelle vap_ling_de in eine XML-Datei exportiert. Das entsprechende Dialogfeld von PMA sieht folgendermaßen aus:

Die Auswahlliste zeigt die verschiedenen Formate, in die die Daten exportiert werden können. Nach Auswahl von XML wird vom Browser eine Datei heruntergeladen, die die Daten im gewünschten Format enthalten. Hier ein Ausschnitt der XML-Datei:

Das vorliegende Format ist generisch und mag im Einzelfall nicht den spezifischen Erfordernissen entsprechen. Mit etwas erweiterten technischen Kenntnissen lassen sich jedoch im Grunde beliebige Datenformate erzeugen und exportieren.

Ein wichtiger Grund, warum sich VerbaAlpina für das relationale Datenformat entschieden hat, ist die Tatsache, dass dergestalt strukturiertes Datenmaterial nach den Regeln der relationalen Algebra analysiert werden kann. Für entsprechende Operationen sowie generell für die Verwaltung relationaler Datenbestände steht eine spezielle formale Sprache, die sog. Structured Query Language, kurz SQL, zur Verfügung. Ihre Syntax basiert auf der englischen Umgangssprache und ist relativ leicht zu erlernen. Grundlegend sind die Konzepte der Selektion und der Projektion. Mit Selektion ist die Auswahl von Zeilen, die bestimmte Kriterien erfüllen, gemeint, Projektion bezeichnet demgegenüber die Auswahl von Spalten. Sämtliche mit der Sprache SQL ausführbaren Operationen basieren letztlich auf den Regeln der relationalen Algebra.

Um nun mit Hilfe von SQL sämtliche Vokabeln aus dem Datenbestand herauszufiltern, die ein ganz bestimmtes Konzept bezeichnen, muss ein entsprechender Filter formuliert werden. Da  bei diesem Vorgang Zeilen, und keine Spalten, ausgewählt werden, handelt es sich um eine Selektion. Das Beispiel geht davon aus, dass die Daten in einer Tabelle mit Namen „Belege“ abgelegt wurden. Eine entsprechende Tabelle ist in der Datenbank von VerbaAlpina nicht vorhanden. Die konkrete Syntax lautet dann wie folgt:

select * 
from Belege 
where konzept = "SENNHÜTTE"
;

Ergebnis:

Konzept Typ wann wo
SENNHÜTTE Sennhaus 1985-2004 Lustenau
SENNHÜTTE cascina 1928-1940 Bivio
SENNHÜTTE cabotte 1928-1940 Borgomaro
SENNHÜTTE casero 1974-1986 Forni Avoltri
SENNHÜTTE baita 1928-1940 Colico
SENNHÜTTE Käser 2017 Schmirn
SENNHÜTTE cascharia 1928-1940 Soglio (Graubünden)
SENNHÜTTE Schwaige 2017 Villandro###D:Villanders
SENNHÜTTE casa 1928-1940 Lanzada
SENNHÜTTE Alp(e) 1962-2003 Davos
SENNHÜTTE Sennhütte 1985-2004 Alberschwende
SENNHÜTTE casone 1928-1940 Antrona Schieranco

Um umgekehrt die verschiedenen Bedeutungen des italienischen Wortes malga zu ermitteln, formuliert man:

select * 
from Belege 
where Bezeichnung = "malga"
;

Ergebnis:

Konzept Typ wann wo
ALM malga 2012 Moena
ALMHÜTTE Malga 1965, 1969, 1971 Salorno###D:Salurn
HERDE malga 1928-1940 Ardez
HIRTENHÜTTE malga 1974-1986 Ravascletto
KUHHERDE malga 1928-1940 Albosaggia
SENNHÜTTE malga 1928-1940 Rabbi

Die Möglichkeiten von SQL sind schier grenzenlos, und es kann hier nur darum gehen, durch wenige Beispiele eine ungefähre Vorstellung zu vermitteln.

Das folgende Beispiel illustriert, wie sich aus einer bestimmten Tabelle der VerbaAlpina-Datenbank sämtliche morpholexikalischen Typen, die das Konzept BUTTER bezeichnen, extrahieren lassen. Das Ergebnis zeigt außerdem die Anzahl der bislang in VA_DB erfassten Einzelbelege, die dem jeweiligen morpholexikalischen Typ zugeordnet sind:

-- SQL-Statement
-- Finde sämtliche morpholexikalischen Typen, die das Konzept BUTTER bezeichnen, 
-- und gib die jeweilige Häufigkeit des morpholexikalischen Typs an

select 
 Name_Konzept as Konzept, 
 group_concat(typ, ' (', anzahl, ')' separator ', ') as Morphtypen 
from
(
 select 
  count(*) as Anzahl, 
  a.Name_Konzept, 
  a.Typ 
 from vap_ling_de a
 where 
  a.Name_Konzept like 'BUTTER'
  and a.Art_Typ like 'Morph_Typ'
 group by a.Typ
 order by Anzahl desc
 ) sq
;

-- Ergebnis
BUTTER: beurre / burro (1264), Anke (866), Butter (348), Schmalz (271), paintg (96),
éponge / spongia (64), smalz (42), Buttern (24), unto (21), süßes Schmalz (20), puter (19),
pischada (19), Schmalzbutter (8), smalz crü (6), maslo (4), rance / rancido (3), bütér (3), 
menata (3), fiore (2), balle / palla (2), süess Schmalz (2), süesses Schmaalz (2), 
Brütschi (1), süess Schmaalz (1), brusco (1)

Im Vorgriff auf die weiter unten vorgestellten Funktionen der Webschnittstelle von VerbaAlpina (VA_WEB) sei hier erwähnt, dass das von VerbaAlpina verwendete WordPress-System die direkte Einbindung der Ergebnisse von Datenbankabfragen in WordPress-Beiträge wie den vorliegenden erlaubt. Diese Funktion wurde als sog. WordPress-Plugin („SQLtoHTML“) von VerbaAlpina entwickelt und steht als Modul auch für im Grunde beliebige andere WordPress-Installationen zur Verfügung. Das soeben vorgestellte SQL-Beispiel kann, eingebettet in eine spezifische Syntax, in den Text eines WordPress-Beitrags eingebettet werden. Im Frontend erscheint dann anstelle des Codes das Ergebnis der Abfrage.

Code (darf keinen Zeilenumbruch enthalten):

[[SQL:select Name_Konzept as Konzept, group_concat(typ, ' (', anzahl, ')' separator ', ') as Morphtypen from ( select count(*) as Anzahl, a.Name_Konzept, a.Typ from vap_ling_de a where a.Name_Konzept like 'BUTTER' and a.Art_Typ like 'Morph_Typ' group by a.Typ order by Anzahl desc ) sq ]]

Ergebnis im Frontend:

Ein weiteres Beispiel für die Möglichkeiten von SQL zeigt, wieviele verschiedene Basistypen den morphologischen Typen zur Bezeichnung des Konzepts SENNHÜTTE zugrundeliegen und wieviele morphologische Typen pro Basistypen bislang registriert sind:

-- SQL-Statement
/* 
Errechne die Anzahl von morphologischen Typen, die das Konzept SENNHÜTTE bezeichnen 
und die jeweils mit demselben Basistypen verbunden sind: 
  • /
select count(*) as Anzahl, sq.basistyp, group_concat(Typen separator ' | ') as Morphtypen from ( select distinct a.Basistyp, concat(a.Typ, ' (', a.Art_Typ, ')') Typen from vap_ling_de a where a.Name_Konzept like 'SENNHÜTTE' and a.Basistyp is not null ) sq group by basistyp order by Anzahl desc ; -- -- -- Ergebnis 14: căsa(m): casino (Morph_Typ) | casini (Morph_Typ) | Casel (Morph_Typ) | casone (Morph_Typ) | casa (Morph_Typ) | casa da/di alp (Morph_Typ) | casella (Morph_Typ) | casello (Morph_Typ) | casa da fuoco (Morph_Typ) | casine (Morph_Typ) | casa da caschar (Morph_Typ) | casina (Morph_Typ) | caseta (Morph_Typ) | casinel (Morph_Typ) 8: hutta: Sennhütte (Morph_Typ) | Sentumhitta (Morph_Typ) | Hütte (Morph_Typ) | Almhütte (Morph_Typ) | Melkhütte (Morph_Typ) | Sennerhütte (Morph_Typ) | Berghütte (Morph_Typ) | Alphütte (Morph_Typ) 5: *sanio: Sennerei (Morph_Typ) | Sennhütte (Morph_Typ) | Sentumhitta (Morph_Typ) | Sennerhütte (Morph_Typ) | Sennhaus (Morph_Typ) 5: alpe: Alp(e) (Morph_Typ) | casa da/di alp (Morph_Typ) | Almhütte (Morph_Typ) | Alphütte (Morph_Typ) | cascina da/di alp (Morph_Typ) 5: alpes: Alpgemach (Morph_Typ) | Alp(e) (Morph_Typ) | Almhütte (Morph_Typ) | Alphütte (Morph_Typ) | Alm (Morph_Typ) 4: căpsa(m): cascina dal fuoco (Morph_Typ) | cascina per caschar (Morph_Typ) | cascina (Morph_Typ) | cascina da/di alp (Morph_Typ) 4: caseāria: Käser (Morph_Typ) | Chäseren (Morph_Typ) | casera (Morph_Typ) | caserìn (Morph_Typ) 3: *tegia: Teie(n) (Morph_Typ) | Tieje (Morph_Typ) | Tegia (Morph_Typ) 3: baita: baita (Morph_Typ) | baito (Morph_Typ) | bait (Morph_Typ) 2: *caseare: cascina per caschar (Morph_Typ) | casa da caschar (Morph_Typ) ... -- gekürzt

Das Beispiel zeigt z.B., dass insgesamt 14 unterschiedliche morpholexikalische Typen, die das Konzept SENNHÜTTE bezeichnen könnten, mit dem Basistypen „casa(m)“ verbunden sind.

Das relationale Datenmodell und die Abfragesprache SQL erlauben auch weitergehende arithmetische und in der Folge statistische Berechnungen über dem Datenbestand. Das nachfolgende Beispiel berechnet den prozentualen Anteil der einzelnen Basistypen an der Gesamtzahl aller morpholexikalischer Typen, die das Konzept SENNHÜTTE bezeichnen:

-- SQL-Statement
-- Errechne den prozentualen Anteil der einzelnen Basistypen 
-- an der Gesamtzahl aller morpholexikalischer Typen, die das Konzept SENNHÜTTE

select 
 sq.basistyp as Basistyp,
 count(*) as Anzahl, 
 round(count(*) / (
  select count(*)
  from
  (
   select 
    a.Basistyp
   from vap_ling_de a
   where 
    a.Name_Konzept like 'SENNHÜTTE'
    and a.Basistyp is not null
   group by basistyp
  ) sq0
 ) * 100,2) as Prozentanteil

from
(
select distinct
 a.Basistyp,
 concat(a.Typ, ' (', a.Art_Typ, ')') Typen
from vap_ling_de a

where 
 a.Name_Konzept like 'SENNHÜTTE'
 and a.Basistyp is not null
) sq

group by basistyp

order by Anzahl desc
;

-- Ergebnis
Basistyp | Anzahl | Prozentanteil
căsa(m) | 14 | 41.18
hutta | 8 | 23.53
alpe | 5 | 14.71
alpes | 5 | 14.71
  • sanio | 5 | 14.71
caseāria | 4 | 11.76 căpsa(m) | 4 | 11.76
  • tegia | 3 | 8.82
baita | 3 | 8.82 ... -- gekürzt

Ende Mai 2018 umfasste die VerbaAlpina-Datenbank insgesamt

  • 1167 unterschiedliche Konzepte sowie
  • 5446 verschiedene morphologische Typen.

VA_WEB

Die zentrale Datenbank von VerbaAlpina, VA_DB, ist angebunden an die multifunktionale Webschnittstelle, die unter der Adresse https://www.verba-alpina.gwi.uni-muenchen.de (VA_WEB) im Internet erreichbar ist.

VA_WEB ist mit dem weit verbreiteten WordPress-Framework in den Programmiersprachen PHP und Javascript programmiert. Die Entwickler von VerbaAlpina haben eine Reihe von VerbaAlpina-spezifischen Funktionserweiterungen geschrieben. All diese Funktionserweiterungen sind modular als sog.Plugins“ – wie das bereits weiter oben erwähnte SQLtoHTML-Plugin – konzipiert, die frei zur Verfügung gestellt und nach Belieben auch in andere WordPress-Installationen übernommen werden können.

VA_WEB gliedert sich in einen öffentlichen Bereich, das sog. Frontend, und einen zugangsbeschränkten Bereich, das sog. Backend. Das Frontend ist gleichsam das Schaufenster des Projekts. Hier findet sich das bislang zentrale Analyseinstrument, die interaktive Onlinekarte, auf der das in der Datenbank gesammelte Material nach vorgegebenen Kriterien visualisiert werden kann. Eine besondere Bedeutung kommt dem Bereich „Methodologie“ zu. Hier werden nach Stichworten gegliedert sämtliche Aspekte des Gesamtprojekts, von den wissenschaftlichen Grundlagen bis hin zur Erläuterung technischer Details und Vorgehensweisen, allgemeinverständlich erläutert und dokumentiert. Die Sektion „Methodologie“ wird ständig erweitert bzw. nötigenfalls auch überarbeitet.

Das Web-Frontend dient auch als zentrale Publikationsplattform des Projekts. Unter der Rubrik „Beiträge“ finden sich neben allgemeinem Informationsmaterial für die Öffentlichkeit auch ausgwählte Vorträge, die von den Projektmitarbeitern auf wissenschaftlichen und populären Veranstaltungen gehalten werden, sowie wissenschaftliche Beiträge in Artikelform.

Funktionen des Backends

Das Backend von VA_WEB bietet über die von WordPress standardmäßig bereitgestellten Basisfunktionen, zu denen auch die von VA verwendete Benutzerverwaltung gehört, eine Reihe von überwiegend individuell entwickelten Zusatzfunktionen, die in der Projektarbeit Verwendung finden:

Transkriptionstool

Die Erfassung von Daten speziell aus Sprachatlanten kann bislang nur manuell erfolgen. Der Einsatz von OCR (= Optical Character Recognition = automatische Verwandlung von Graphikdaten in elektronisch kodierten Text) ist in diesem Kontext nicht möglich. Das Hauptproblem besteht in der Zuordnung der auf den Karten eingetragenen Einzelbelege zu den jeweils richtigen Erhebungspunkten. Im folgenden Beispiel ist es für einen Computer de facto unmöglich zu entscheiden, welchem der durch die roten Zahlen bezeichneten Erhebungspunkte der grün markierte Beleg zuzuordnen ist.

AIS-Karte 1218: Il siero del latte

Seit wenigen Wochen sind am Leibniz-Rechenzentrum (LRZ) bzw. am Lehrstuhl Prof. Kranzlmüller (Lehrstuhl für Kommunikationssysteme und Systemprogrammierung der LMU) ein, eventuell auch zwei Masterarbeiten ausgeschrieben, die Lösungsansätze für dieses Problem entwickeln sollen.

Die Datenerfassung kann dann automatisch unter Verwendung von OCR erfolgen, wenn das Material in der analogen Quelle in Tabellen- bzw. Listenform vorliegt. Gute Erfahrungen liegen mit dem Programm ABBYY Finereader vor. Das folgende Beispiel stammt aus dem Atlante Linguistico ed Etnografico del Piemonte Occidentale (ALEPO)

Daten in Listenform (hier: Alepo III-i-1: PARASSITI) erlauben den Einsatz von OCR

Aus dargelegten Gründen ist eine automatische Datenerfassung speziell von Datenmaterial aus Sprachatlanten bislang nicht möglich und eine manuelle Erfassung unumgänglich. Zur Erleichterung dieser Arbeit wurde ein spezielles Transkritptionstool entwickelt:

Das Transkriptionstool von VerbaAlpina

In einem Fensterausschnitt wird ein Bild einer Atlaskarte präsentiert. Unmittelbar darunter befindet sich ein Formular, das die strukturierte Erfassung der Kartendaten erlaubt bzw. auch erzwingt. Jeder Einzelbeleg auf der Karte wird unter Angabe des kartierten Stimulus und der Identifizierung des jeweiligen Informanten erfasst und direkt in einer Datenbanktabelle abgelegt. Die Transkription erfolgt im sog. Betacode, einem Verfahren, das auf eine Idee des Thesaurus Linguae Graecae (University of California Irvine) aus den Siebzigerjahren zurückgeht. Grundidee ist, beliebige Sonderzeichen samt Diacritica in Sequenzen von Standardzeichen (konkret: sog. ASCII-Zeichen) zu übertragen. Dabei werden Sonderzeichen und Diacritica nach einem simplen Schema in Abfolgen von Buchstaben des englischen Alphabets und geläufige Satz- und Sonderzeichen wie etwa runde Klammern oder Schrägstriche übertragen. Im Transkriptionstool wird dem Transcriptor auf der rechten Fensterseite das entsprechende Regelwerk eingeblendet.

Zur Herstellung von Vergleichbarkeit werden alle von VA erfassten phonetisch transkribierten Einzelbelege auf das Internationale phonetische Alphabet (IPA) abgebildet. IPA hat demnach innerhalb von VA den Status einer Referenztranskription. Bei der Überführung der quellentreuen Betacode-Transkription nach IPA kann es jedoch, unvermeidbar, zu Informationsverlusten kommen. Als Beispiel sei das Transkriptionssystem nach Böhmer und Ascoli genannt. Dieses unterscheidet durch Diacritica bei den Vokalen eine größere Anzahl von Öffnungsgraden des Mundes als IPA. Bei der Übertragung von Böhmer/Ascoli zu IPA müssen demnach Kompromisse eingegangen werden.

Krefeld, T. / Lücke, S.: s.v. “Betacode”, in: VA-de 17/2, Methodologie, https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=493&db=172&letter=B#7

Die bei der Transkription verwendeten Zeichen sind ausnahmslos sogenannte ASCII-Zeichen. Dabei handelt es sich um Zeichen, die bereits im Jahr 1963 kodiert worden sind. Mit Kodierung ist dabei die Zuordnung der Schriftzeichen zu ganz bestimmten Zahlenwerten gemeint. Dies ist nötig, weil Computer nur mit Zahlen arbeiten können. Kodiert wurden insgesamt 128 Schriftzeichen, bei denen es sich hauptsächlich um die Buchstaben des englischen Alphabets, die arabischen Ziffern sowie um einige Satz- und Sonderzeichen handelt. Die damals festgelegte Kodierung ist bis zum heutigen Tage gültig. Anders als z.B. bei der Verwendung des moderneren Unicode ist die Gefahr des Entstehens von Kodierungsfehlern so gut wie ausgeschlossen. Allgemein bekannt dürfte folgendes Phänomen sein: Der deutsche Umlaut ü wird durch zwei sinnlose Zeichen dargestellt: Mühle ⇒ Mühle. Dergleichen ist bei Verwendung von ASCII-Zeichen ausgeschlossen.

Daneben bietet der Einsatz des Betacodes weitere Vorteile:

  • Die Transkriptionen können unter Verwendung von Standardtastaturen durchgeführt werden
  • Es ist unerheblich, ob ein Transkriptor die konkrete Bedeutung der von ihm erfassten Schriftzeichen kennt. Die Übertragung orientiert sich allein an der graphischen Gestalt der zu transkribierenden Zeichen.
  • Die Transkription ist kaum anfällig für Tippfehler und erfolgt in vergleichsweise hoher Geschwindigkeit
  • Die Transkription ist insofern quellentreu, als dabei keinerlei Informationsverlust auftritt – jedes Basiszeichen und jedes Diacriticum wird durch jeweils genau ein anderes Zeichen wiedergegeben.

Die von den gedruckten oder auch digitalen Quellen verwendeten Transkriptionssysteme sind sehr unterschiedlich. So kann ein und dasselbe graphische Zeichen, z.B. ein e mit einem Punkt darunter, durchaus unterschiedliche Laute bezeichnen. Um Vergleichbarkeit zu erzielen, werden sämtliche quellenspezifischen Transkriptionssysteme auf eine Referenztranskritption, nämlich IPA, abgebildet. Der entsprechende Vorgang erfolgt automatisch durch Ersetzungsprozeduren.

Typisierungstool

Die aus den unterschiedlichen Quellen, also im wesentlichen Sprachatlanten und Wörterbüchern, transkribierten Belege sind hinsichtlich ihres Status sehr heterogen. VerbaAlpina unterscheidet diesbezüglich im wesentlichen zwischen den folgenden Kategorien:

Einzelbeleg   —   morpholexikalischer Typ   —   Basistyp

Ein Einzelbeleg ist die mehr oder weniger unmittelbare und individuelle Äußerung eines Informanten. In Sprachatlanten ist sie meist daran erkennbar, dass sie in phonetischer Transkription und gebunden an einen spezifischen Informanten oder Erhebungspunkt gebunden ist.

Ein morpholexikalischer Typ (kurz: Morphtyp) sind am ehesten vergleichbar mit den Lemmata in traditionellen Wörterbüchern. Ein Morphtyp wird definiert durch die Zugehörigkeit zu einem jeweils gemeinsamen Wortstamm, Sprachfamilie, Wortart, Affigierung sowie Genus. Beispiel: Der Butter und die Butter bilden zwei unterschiedliche Morphtypen, da sie sich hinsichtlich des Genus unterscheiden.

Der Basistyp ist schließlich ein in unterschiedlichen Morphtypen erkennbares gemeinsames lexikalisches Element, ohne dass damit eine Aussage über die Entstehungsgeschichte des einzelnen Morphtypen getroffen werden würde. Vorstellbar in diesem Zusammenhang wären z.B. die Entstehung eines Morphtypen direkt aus einer sprachlichen Vorstufe am Ort im Sinne eines Etymons, jedoch kommen auch Entlehnungsszenarien im Umfeld von Sprachkontakt in Betracht. Als Beispiel können die beiden Morphtypen Salamander (ger.) und Salamandra (rom.) genannt werden. Beide enthalten erkennbar ein gemeinsames lexikalisches Element. Ob aber der eine Morphtyp sich aus dem anderen entwickelt hat oder beide auf einen gemeinsamen Vorläufer zurückgehen, lässt sich vor der Hand nicht entscheiden. Um dennoch die offenkundige Verwandtschaft der beiden Morphtypen im Datenbestand abbilden zu können, werden bei dem Basistypen „salamandra“ zugewiesen. VerbaAlpina geht speziell diesen Fragen nicht systematisch nach, entsprechende spätere Erweiterungen und Ergänzungen sind jedoch jederzeit möglich.

Gleichsam die Referenzkategorie für VerbaAlpina stellt der Morphtyp dar. Speziell für die Zuweisung der transkribierten Belege zu Morphtypen wurde in VerbaAlpina das sog. Typisierungstool entwickelt. Neben der Zuweisung zu Morphtypen erfolgt hier auch die Zuweisung zum jeweiligen Konzept, das laut Quelle von diesem Morphtyp bezeichnet wird.

Sofern möglich, können Morphtypen im Typisierungstool auch mit Lemmata in ausgewählten Referenzwörterbüchern verknüpft werden. Als Beispiel sei der Einzelbeleg tɔːiə aus dem Vorarlberger Sprachatlas (VALTS, Karte 73) genannt. Dieser ist über das Typisierungstool zunächst dem Morphtypen „Teie(n) – ger – sub“ und dieser wiederum dem Lemma „Teien“ im Schweizerdeutschen Wörterbuch, dem sog. Idiotikon, zugewiesen.

VerbaAlpina sieht grundsätzlich auch die Definition und Zuordnung von phonetischen Typen (z.B. Kas, Kaas -> Kaas vs. Kees, Käs -> Kees etc.) vor. Da das Projekt jedoch vorrangig morpholexikalisch ausgerichtet ist, liegt eine entsprechende Typisierung bislang erst lückenhaft vor. Derzeit (Juni 2018) stehen den 5446 morphologischen gerade einmal  646 phonetische Typen gegenüber.

Konzeptbaum

Ganz wesentlich für VerbaAlpina ist die außersprachliche Kategorie der Konzepte. Schließlich lautet die zentrale Frage: Welche Konzepte werden wo und wann mit welchen Morphtypen bezeichnet. Zur Verwaltung der Konzepte wurde von VA ein im Backend von VA_WEB zugängliches Tool entwickelt, das als Konzeptbaum bezeichnet wird.

Nach Aufruf des Tools muss zunächst eine der vorgegebenen Hauptkategorien (z.B. Milchverarbeitung) und anschließend eine Unterkategorie (z.B. Produkte) ausgewählt werden. Danach erscheint eine alphabetisch sortierte Liste aller bislang angelegten Konzepte. Die Elemente dieser Liste könnten durch Drag&Drop zu Unterkonzepten bestehender anderer Konzepte umgruppiert werden. Auch die Neuanlage von Konzepten ist hier möglich.

Forschungslabor (in Planung)

VerbaAlpina möchte sich u.a. zu einer Plattform entwickeln, auf der Forscher und Laien individuelle Studien betreiben und sich bzw. auch ihre Daten austauschen können. Das Konzept sieht vor, dass registrierte Benutzer nach dem Einloggen in VerbaAlpina eine persönliche Umgebung vorfinden, innerhalb derer sie zum einen das vorhandene VerbaAlpina-Datenmaterial nach individuellen Interessen analysieren und die Ergebnisse abspeichern können. Zum anderen soll es möglich sein, eigenes Material in das System zu importieren und dieses dann entweder isoliert oder auch in Kombination mit dem VerbaAlpina-Material zu verarbeiten.

So wie nunmehr schon in vielen Internet-Diensten etabliert, soll es die Möglichkeit geben, Daten und Analyseergebnisse für den Zugriff durch Dritte freizugeben. Diese Freigabe soll mehrere Optionen anbieten: Freigabe für spezifische andere registrierte Benutzer von VerbaAlpina, Freigabe für alle registrierten Benutzer von VA und schließlich die unbeschränkte Freigabe von Daten im Internet. Das Konzept orientiert sich grob am von Google eingesetzten Verfahren im Zusammenhang mit von Nutzern erstellten Karten auf Google Maps.

Das Konzept ist bislang erst in Ansätzen realisiert. Ein solcher Ansatz besteht in der Möglichkeit, auf der interaktiven online-Karte von VerbaAlpina durch die Auswahl beliebiger sprachlicher und außersprachlicher Datenkategorien erzeugte Kartenbilder als „synoptische“ Karten abzuspeichern. Diese Funktion steht aktuell nur registrierten Benutzern zur Verfügung. Beim Abspeichern einer Karte besteht die Möglichkeit, einen Kommentar beizufügen, der den Informationsgehalt der Karte erläutern soll. Für eine erstellte synoptische Karte kann eine Freigabe beantragt werden. Diese erfolgt dann erst nach einer qualitätssichernden Überprüfung durch das Team von VerbaAlpina. Bei künftig verstärkter Nutzung dieser Möglichkeiten wird man über alternative Konzepte zur Qualitätssicherung nachdenken müssen. Vorstellbar sind z.B. Bewertungen durch die Nutzergemeinde von VerbaAlpina.

Im Forschungslabor könnte auch ein Modul zur statistischen Analyse der VerbaAlpina-Korpusdaten eingerichtet werden. An den Instituten für Statistik und Kunstgeschichte wird zur Zeit ein System entwickelt, bei dem es um die statistische Analyse von Museumsbeständen geht. Das Konzept von MAX (Museum Analytics; https://www.max.gwi.uni-muenchen.de/; ein von der LMU im Rahmen des „Qualitätspakts Lehre“ gefördertes Projekt) beinhaltet auch das Szenario, dass Anwender im Grunde beliebige Daten z.B. im csv-Format in das System importieren, um es dort mit vorgefertigten Verfahren statistisch zu analysieren. Künftig sollen  die im Rahmen von MAX entwickelten Funktionalitäten in das Forschungslabor von VerbaAlpina integriert werden.

Funktionen des Frontends

Methodologie

In der Rubrik Methodologie erfolgt eine ausführliche Methodenreflexion. Hier sollen alle mit VerbaAlpina verbundenen Aspekte transparent und nachvollziehbar dokumentiert werden. Der Inhalt ist nach Schlagworten gegliedert, die wiederum thematischen Kategorien zugeordnet sind. Hier werden neben grundlegenden Konzepten des Gesamtprojekts auch spezifisch linguistische oder auch informatisch-technische Detailaspekte erläutert. Die Einträge in dieser Rubrik werden ständig erweitert oder nötigenfalls auch überarbeitet und angepasst. Die Methodologie spielt eine wichtige Rolle im Hinblick auf das Erfordernis der Nachhaltigkeit und Nachnutzbarkeit aller von VerbaAlpina gesammelten und erzeugten Daten. Der Anspruch besteht, dass sämtliche Teile des Gesamtprojekts, seien es die Sprachdaten in der VA_DB, die sprachwissenschaftlichen Kommentare und (mit gewissen Einschränkungen) auch der erzeugte Software-Code auch noch nach Jahrzehnten nutzbar sein werden.

Interaktive Online-Karte

Die interaktive Online-Karte von VA ist das zentrale Visualisierungs- und Analyseinstrument. Aktuell basiert die Karte auf Google-Technologie, konkret auf dem Online-GIS Google Maps und der entsprechenden Javascript-Bibliothek. VerbaAlpina ist im Grunde der Überzeugung, dass der Einsatz von Diensten kommerzieller Anbieter im wissenschafftlichen Umfeld generell vermieden werden sollte. Speziell im Fall der online-Kartographie führt derzeit jedoch kaum ein Weg an Google Maps vorbei. Das Opensource-Projekt Openstreetmap (OSM), das grundsätzlich eine Alternative darstellen könnte, kann hinsichtlich Funktionalität und, was fast noch wichtiger ist, hinsichtlich der Dokumentation mit dem Google-Dienst nicht mithalten. Bei Einsatz von Openstreetmap hätte sehr wahrscheinlich der aktuelle Entwicklungsstand der online-Karte von VerbaAlpina nicht in derselben Zeit erreicht werden können. Grundsätzlich wäre eine Umsetzung der online-Karte auf OSM rein technisch wohl möglich. Sollten in Zukunft Verbesserungen bei OSM festzustellen sein, die einen Umzug vertretbar erscheinen lassen, so wäre ein solcher Schritt durchaus vorstellbar. VerbaAlpina behält diese Perspektive jedenfalls im Auge.

Das Karteninterface erlaubt wahlweise oder auch kombiniert semasiologischen und/oder onomasiologischen Zugriff auf den Datenbestand. Nachfolgend stehen unterschiedliche Gruppierungsoptionen zur Verfügung.

Qualitative Kartierung

Über die Legende am linken Rand der Karte können Konzepte, phonetische oder morpholexikalische Typen oder auch  ausgewählt werden. Seit kurzem steht auch eine Suchfunktion zur Verfügung, die sämtliche auswählbare Listeneinträge durchsucht, unabhängig von deren Kategorisierung als „Konzept“, „Morphtyp“ usw. Nach Auswahl eines verfügbaren Elements erscheinen die entsprechenden Symbole auf der Karte.

Neben Sprachdaten können auf der Karte synoptisch auch georeferenzierte Daten der „sprachbezogenen Peripherie“ visualisiert werden. Darunter werden unterschiedlich Kategorien von Daten verstanden, die mit sprachlichen Phänomenen in der einen oder anderen Weise in Wechselwirkung stehen können. Dies können z.B. historische Daten wie etwa Daten zu antiken Besiedlungsstrukturen und Verkehrswegen, entlang derer sich sprachliche Phänomene verbreitet haben könnten, oder auch Daten zur modernen Infrastrukutur wie etwa zur Verbreitung der Internetanschlüsse im Alpenraum sein, die sicherlich Auswirkungen auf sprachliche Veränderungsprozesse haben. Die Daten dieses Sektors sind bislang noch nicht  systematisch gesammelt worden.

Quantifizierende Darstellung

Die online-Karte erlaubt auch eine quantifizierende Abbildung der auf einer Karte dargestellten Inhalte. Im folgenden Beispiel ist zunächst die nach jeweiliger Bedeutung (Konzepten) gruppierte Verbreitung des Morphtyps „Teie(n)“ kartiert:

Qualitative Kartierung des Morphtyps „Teie(n)“

Die hier abgebildete Karte ist mit dem Link https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=xxx&tk=1357 hinterlegt. Die hinter dem Fragezeichen folgenden, rot gesetzten sog. URL-Parameter bewirken, dass die interaktive Onlinekarte mit der gewünschten Vorauswahl „Morpho-lexikalischer Typ Teie(n) (ger.)“ aufgerufen wird. Ein solcher Link kann für Karten mit der Kartierung beliebiger Elemente (Morphtypen, Konzepte, sprachbezogene Peripherie …) abgerufen werden, indem man am oberen rechten Rand der Karte das allgemein bekannte Sharing-Symbol anklickt.

Die quantifizierende Darstellung dieser Daten orientiert sich an Flächen bzw. administrativen Regionen, d.h. es wird die jeweilige Anzahl von Belegen pro Teilfläche des gewählten Bezugssystems durch unterschiedliche Farbgebung markiert.

Im Wesentlichen kann zwischen den folgenden verschiedenen Bezugssystemen gewählt werden:

  • Sprachgebiete
  • Nationalstaaten
  • NUTS3 (= administrative Gliederung auf Niveau der deutschen Landkreise)
  • Gemeindegrenzen

Die quantifizierende Kartierung setzt die Auswahl mindestens einer dieser Kategorien voraus. Sobald ein entsprechender Eintrag in der Kartenlegende auf der linken Seite vorhanden ist, kann man dort auf das von einem Kreis umgebene Q klicken. Anschließend werden die Daten gemäß den Teilflächen der gewählten Kategorie gruppiert und die gruppenbezogene Anzahl durch Farbgebung der Flächen visualisiert.

Quantifizierende Darstellung der Verbreitung des Morphtyps „Teie(n)“ mit georefrenziertem Verlauf der NUTS3-Grenzen

Im Legendeneintrag „Kartographische Darstellung“ lässt sich sodann noch wählen zwischen den Optionen „Physisch“ und „Hexagonal“. Erstere, im vorstehenden Beispiel angewendete, Option verwendet den tatsächlichen, geographisch exakt kartierten Grenzverlauf der entsprechenden Teilflächen. Bei Auswahl der Option „Hexagonal“ wird jede Teilfläche durch Hexagone jeweils identischer Größe repräsentiert. Diese Art der Darstellung soll die Wahrnehmung verzerrende Effekte beseitigen, die sich durch die z.T. stark unterschiedliche Flächengrößen ergeben können.

Quantifizierende Darstellung der Verbreitung des Morphtyps „Teie(n)“ mit hexagonaler Darstellung der Bezugsflächen

Bei dieser Darstellung gehen konzeptbedingt Teile der geographischen Logik verloren. Im Inneren des Wabenmusters hat jede Fläche stets genau sechs Nachbarhexagone. Es liegt auf der Hand, dass es in der Realität nicht wenige Teilflächen geben wird, die entweder mehr oder weniger Nachbarflächen aufweisen.

Am unteren Rand der quantifizierenden Karten kann die Farbgebung der Flächen verändert werden (u.a. die verbreitete Heatmap, die den Verlauf der Regenbogenfarben verwendet). Die bei dem Balken für die Farbauswahl an der rechten oberen Ecke angegebene Zahl gibt die Anzahl der Belege an, die in der Fläche mit der maximalen Anzahl an Belegen versammelt sind, und hilft somit bei der Einschätzung der Anzahlen in den schwächer eingefärbten Flächen.

Die einzelnen Elemente in der Kartenlegende auf der linken Seite können durch Entfernen oder Setzen des kleinen Häkchens in die Berechnung und Visualisierung der Daten auf der Karte einbezogen oder herausgenommen werden. Bei jeder solchen Aktion wird die Kartendarstellung entsprechend aktualisiert.

Lexicon Alpinum

Das Lexicon Alpinum enthält eine alphabetisch sortierte Liste mit Morphtypen, Konzepten und Basistypen, zu denen bislang ein wissenschaftlicher Kommentar verfasst worden ist. Hinter jedem Eintrag ist angegeben, ob es sich um ein Konzept, einen Morph- oder einen Basistyp handelt. Konzepte sind außerdem,  wie auch in der Legende der Onlinekarte, an der Schreibung in Versalien erkennbar. Über den Link „Auf Karte visualisieren“ gelangt man zur Online-Karte, auf der dem Lexikoneintrag zugeordnete Daten dargestellt werden.

Die im Lexicon Alpinum gelisteten Kommentare können auch über die Online-Karte aufgerufen werden. Sofern für einen bestimmten Legendeneintrag auf der Online-Karte ein Kommentar vorhanden ist, erscheint unmittelbar rechts von diesem Eintrag ein kleines i in einem Kreis. Ein Klick auf dieses Symbol öffnet den Kommentartext, der auch im Lexicon Alpinum präsentiert wird.

Kommentar zum Konzept ALMHÜTTE im Lexicon Alpinum und auf der Online-Karte

Crowdsourcing: Dateninkonsistenzen und deren Ausgleich

Dadurch dass die Hauptquellen von VA, nämlich Sprachatlanten und Wörterbücher, bezogen auf den gesamten Alpenraum durchaus unterschiedliche Konzepte und in der Folge auch Bezeichnungen dokumentiert haben, entsteht bei der Sammlung des Gesamtmaterials ein mehrdimensionales Netz mit einer Reihe von Inkonsistenzen. Die Mehrdimensionalität entsteht dabei im Wesentlichen durch die Variablen Georeferenz, Chronoreferenz und Konzept. So ist es z.B. möglich, dass ein bestimmter Sprachatlas zu einem bestimmten Zeitpunkt in einer bestimmten Region das Vokabular für ein bestimmtes Konzept erhoben hat. Für andere Regionen fehlen hingegen entsprechende Erhebungen entweder vollständig oder aber wurden zu einem erheblich früheren oder späteren Zeitpunkt durchgeführt. Um Inkonsistenzen dieser Art wenigstens im Hinblick auf die Konzept- und geographische Dimension auszugleichen, hat VA ein Crowdsourcing-Tool entwickelt, mit dem über das Internet gezielt Sprachmaterial gesammelt wird. Auch dieses Tool ist über das Frontend von VA_WEB erreichbar (Reiter „MITMACHEN!“).

Konkret werden Internetuser dazu aufgefordert, Bezeichnungen für bestimmte Konzepte, die nach ihrer Ansicht an einem bestimmten Ort üblich sind, in ein online-Formular einzutragen. Das Tool hebt dabei bestimmte Konzepte, die aus Sicht von VerbaAlpina von besonderem Interesse sind, hervor. Grundsätzlich sind die Internetuser jedoch frei, auch Bezeichnungen für beliebige Konzepte ihrer Wahl einzutragen.

Die Validierung der Eintragungen erfolgt nach dem Prinzip der unabhängigen Quellen: Wenn zwei oder mehr Internet-Informanten für einen Ort die selbe Bezeichnung für ein bestimmtes Konzept eingegeben haben, gilt der Eintrag als validiert.

Ein großes Problem dieser Form der Online-Erhebung ist die Resonanz. Jeweils nach der Bewerbung des Crowdsourcing-Tools auf Veranstaltungen oder in den Medien steigt die Zahl der Eintragungen ins System an, ebbt jedoch jedesmal schnell wieder ab.

Jenseits von VA_DB und VA_WEB: Der weitere Horizont

Institutionelle Vernetzung

VerbaAlpina versteht sich als Teil eines Daten- und institutionellen Verbundes. Derzeit (Mai 2018) haben insgesamt über 40 Institutionen und Einzelpersonen mit VerbaAlpina eine Kooperationsvereinbarung geschlossen. Die einzelnen Partner sind hinsichtlich ihrer wissenschaftlichen Ausrichtung und ihren spezifischen Interessen überaus heterogen. Viele der Partner verfügen wie VerbaAlpina über Sprachmaterial, das in aller Regel hinsichtlich Strukturierung und Zeichenkodierung sehr individuell gestaltet ist.

Wesentlicher Bestandteil der VA-Kooperationsvereinbarungen ist der wechselseitige Austausch von Daten zum gegenseitigen Nutzen. Grundsätzlich kommen in diesem Zusammenhang zwei Szenarien ins Spiel, die den effektiven Datenaustausch überhaupt erst ermöglichen:

Entweder, man verständigt sich auf Standards (gleichermaßen für Datenstrukturen wie für Zeichenkodierung), die von allen Beteiligten angewandt werden, oder man folgt einem Schnittstellenkonzept, das es den Projektpartnern erlaubt, ihre individuellen Lösungen beizubehalten. Letztere Option ist die von VerbaAlpina favorisierte Lösung. Bei jedem Datentransfer von der oder in die Datenbank von VerbaAlpina (VA_DB) muss eine eigene Prozedur entwickelt werden, die die Daten der Quelle an die Strukturen und Kodierungen der Zielinstanz anpasst bzw. sie in diese überführt.

Nach außen hin verfügt VerbaAlpina neben der Webschnittstelle mit der Kartenfunktion über eine definierte Datenbankschnittstelle. Diese ist nur für die Kooperationspartner von VerbaAlpina zugänglich. Sämtliches georeferenziertes Sprachmaterial sowie die, ebenfalls georeferenzierten Daten der sprachlichen Peripherie können in Datenbanktabellen konsultiert und von dort auch heruntergeladen werden. Der Name der Datenbankschnittstelle für die Sprachdaten lautet vap_ling_de, der für die Daten der sprachlichen Peripheri vap_geo_de.

select Quelle_Beleg,beleg,concat(Typ,' (',art_typ,')') as typ,Name_Konzept,Gemeinde,Breitengrad,Laengengrad from vap_ling_de a where name_konzept is not null and beleg != '' order by rand()

Schnittstelle vap_ling_de (Ausschnitt)

select Kategorie,Name,Beschreibung,st_astext(Geodaten) from vap_geo_de a order by rand() limit 20

Schnittstelle vap_geo_de (Ausschnitt)

Für jede der beiden Tabellen existieren weitere Versionen mit Spaltennamen in den im Alpenraum gesprochenen Nationalsprachen (vap_ling_fr, vap_ling_it, vap_geo_fr etc.). Die Daten der beiden Schnittstellen sind über die Georeferenzierung aufeinander beziehbar.

VerbaAlpina als vollständig „digitales“ Projekt

VerbaAlpina möchte den Paradigmenwechsel, der sich durch Digitalisierung und Vernetzung ergeben hat, so konsequent wie möglich umsetzen. Dazu gehört im Wesentlichen, dass das Projekt in all seinen Teilen ausschließlich elektronisch realisiert wird und im Internet zugänglich ist. Die Vorteile bestehen dabei in den Möglichkeiten der erweiterten algorithmischen und statistischen Analyse des Datenbestands, der Beschleunigung aller Prozesse, der weitgehenden Unabhängigkeit von kommerziellen Institutionen wie z.B. Wissenschaftsverlagen sowie der ständigen Verfügbarkeit aller Daten und Funktionen unabhängig von Ort und Zeit.

Den genannten Vorteilen stehen auf der anderen Seite Probleme oder besser: Herausforderungen gegenüber. Diese bestehen zunächst in der „Flüchtigkeit“ des elektronischen Mediums, eine Eigenschaft, die eine Reihe von Konsequenzen nach sich zieht. Da wäre zunächst das Problem der Zitierbarkeit elektronischer Ressourcen. Einmal generierte Daten, seien es primäre Forschungsdaten wie etwa das von VerbaAlpina in VA_DB gesammelte Datenmaterial, seien es die analytischen Texte etwa im Lexicon Alpinum, sie alle müssen genauso zuverlässig zitier- und in der Folge vor allem auffindbar sein, wie das ehedem beim Zitat einer Passage in einem gedruckten Buch der Fall gewesen war. Um dieses Ziel zu erreichen, bedient sich VerbaAlpina des Konzepts der Versionierung: In regelmäßigen Abständen (seit 2018 jeweils Ende Juni und Ende Dezember) wird der komplette Datenbestand von VerbaAlpina, also alle Elemente in den Modulen VA_DB und VA_WEB gleichsam eingefroren. Sämtliche Elemente einer eingefrorenen Version können dann über die bekannten URLs direkt angesprochen werden, wobei die jeweilige Nummer der entsprechenden VA-Version als Parameter „db=[Versionsnummer]“ in die URL eingebunden ist. Zwei Beispiele:

Zitat eines Kommentars im Lexicon Alpinum:

Krefeld, T.: s.v. “ALM”, in: VA-de 17/2, Lexicon alpinum, https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=2374&db=172#C216

Zitat einer online-Kartierung:

https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=172&tk=1373

Die unterschiedlichen Zitierversionen können in VA_WEB durch die Navigationselemente am rechten oberen Fensterrand ausgewählt werden:

Auswahl einer VA-Version in VA_WEB. Die jeweils jüngste Zitierversion ist grün unterlegt.

Zitierfähig ist im Grunde auch die jeweilige Arbeitsversion von VerbaAlpina (db=xxx). Allerdings kann in diesem Fall nicht garantiert werden, dass die Inhalte, auf die referiert wird, stabil sind. Die ständige Erweiterung des Datenbestands sowie die Arbeit an Texten kann dazu führen, dass bei Aufruf einer entsprechenden URL nicht die Inhalte angezeigt werden, auf die es bei Anlage des Zitats angekommen war.

Zwar ist Dergleichen nicht geplant, jedoch kann es nicht ausgeschlossen werden, dass in Zukunft die sog.Domain“ der VerbaAlpina-URLs geändert werden muss. Mit Domain ist der Teil einer URL gemeint, der sich vor den URL-Parametern befindet:

https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=2374&db=xxx

Damit die Ressourcen von VerbaAlpina auch denn noch auffindbar sein werden, wurden für die VerbaAlpina-Domain sowohl ein sogenannter Digital Object Identifier (DOI) sowie ein sogenannter Uniform Resource Name (URN) registriert. Bei diesen beiden Systemen handelt es sich im Grunde um nichts anderes als Listen, die auf der einen Seite einen persistenten Identifikator definieren und auf der anderen Seite die diesem Identifikator zugeordnete Domain. Der Identifikator bleibt grundsätzlich unter allen Umständen unverändert, die Domain hingegen ist variabel und kann ausgetauscht werden, wenn eine Ressource unter einer anderen Domain erreichbar sein sollte. DOI und URN von VA_WEB lauten:

persistenter Identifikator Domain
http://dx.doi.org/10.5282/verba-alpina www.verba-alpina.gwi.uni-muenchen.de
http://nbn-resolving.de/urn:nbn:de:bvb:19-verba-alpina-8 www.verba-alpina.gwi.uni-muenchen.de

Eine andere wichtige Frage ist, welche Institutionen für die rein physische Bewahrung der Daten und deren Auffindbarkeit zuständig sein sollen. Thomas Krefeld und Stephan Lücke haben zu diesen Fragen Vorstellungen entwickelt, die durch die folgende Grafik illustriert werden:

Zuständigkeiten und Regelungen im Kontext der Bewahrung digitaler Ressourcen (aus: Thomas Krefeld & Stephan Lücke (2017): Nachhaltigkeit – aus der Sicht virtueller Forschungsumgebungen. Korpus im Text. Version 7 (10.03.2017, 12:27). url: http://www.kit.gwi.uni-muenchen.de/?p=5773&v=7).

Die Frage nach der Sicherung und Verfügbarkeit von digitalen Ressourcen im Umfeld der Wissenschaft ist hochaktuell und beschäftigt derzeit auch die wissenschaftspolitische Ebene wie z.B. den „Rat für InformationsInfrastrukturen“ (rfii), der das Ziel der Schaffung einer Nationalen Forschungsdateninfrastruktur (NFDI) verfolgt, oder das Bayerische Kultusministerium. Momentan ist VerbaAlpina eingebunden in zwei Projekte, die Lösungsansätze in diesem Umfeld evaluieren und entwickeln sollen. Bei dem einen handelt es sich um das von der DFG geförderte Projekt GeRDI (Generic Research Data Infrastructure). Ein Teil dieses Projekts ist am Leibniz-Rechenzentrum (LRZ) angesiedelt. Ziel von GeRDI ist, einen zentralen fach- und disziplinübergreifenden Metadatenkatalog aufzubauen, der in Zukunft das zuverlässige Auffinden digitaler Ressourcen und Informationen ermöglichen soll. Aktuell laufen Bemühungen, wenigstens Teile des VA-Datenbestands aus VA_DB exemplarisch in ein Metadatenschema zu überführen, das dann in den zentralen GeRDI-Index integriert werden soll.

Im selben Umfeld operiert seit Ende letzten Jahres das von der Bayerischen Staatsregierung geförderte Projekt „Forschungsdatenmanagement“ (FDM; https://www.fdm-bayern.org/), dessen Ziel es ist, zuverlässige Lösungen im Hinblick auf die Sicherung und langfristige Verfügbarkeit von Forschungsdaten zu entwickeln.

Allgemein besteht im Hinblick auf den nachhaltigen Umgang mit digitalen Ressourcen noch keine Klarheit. So herrscht noch nicht einmal Einigkeit darüber, ob grundsätzlich *alle* Daten eines digitalen online-Projekts dauerhaft bewahrt werden sollen. Dies zeigt der gerade erwähnt Begriff „Forschungsdaten“. Traditionell werden darunter z.B. Messdatenreihen von Klimaforschern verstanden, die sich anscheinend klar von den darauf aufbauenden Analysen und Erkenntnissen trennen lassen. VerbaAlpina vertritt den Standpunkt, dass eine solche klare Trennung weder möglich, noch sinnvoll noch angesichts der technischen Möglichkeiten nötig ist und strebt an, *sämtliche* im Projekt gesammelten und erzeugten Daten en bloc zu bewahren — z.B. auch die Protokolle der regelmäßigen Projektbesprechungen, die Einblick in den Fortgang der Projektarbeit geben und getroffene Entscheidungen transparent machen können. Neben dieser Frage, was man unter Forschungsdaten zu verstehen habe, ist auch noch nicht verbindlich geklärt, ob und wie Daten verbindlich strukturiert, dokumentiert und Metadaten versehen werden sollen und welche Institutionen mit welchen Aufgaben betraut werden sollen.

VerbaAlpina begegnet diesen Unsicherheiten durch die Suche nach Best-Practice-Lösungen und mit einem Konzept maximaler Flexibilität. Die Entwicklungen auf diesem Sektor werden aufmerksam verfolgt und die Strukturen und Prozeduren von VerbaAlpina darauf ausgerichtet. Unter den gegebenen Umständen erscheint es die beste Lösung, sich an möglichst vielen der z.T. parallel verlaufenden Anstrengungen zu beteiligen und gleichzeitig die VerbaAlpina-Ressourcen möglichst redundant in mehrere Systeme zu übertragen, die sich der Nachhaltigkeit und Nachnutzbarkeit von digitalen Inhalten verschrieben haben. Neben GeRDI wären in diesem Zusammenhang noch die UB der LMU zu nennen, bei der bereits eine ältere Version von VerbaAlpina in einem sog. Docker-System läuft. Dabei handelt es sich um eine gekapselte Serverinstallation, die garantieren soll, dass vor allem die in VA_WEB realisierten Funktionalitäten auch dann noch laufen, wenn es in Zukunft Serversoftware geben wird, mit der der von VA entwickelte Programmcode nicht mehr lauffähig ist. Zu erwähnen wäre schließlich noch das CLARIN-D-Repositorium. VerbaAlpina hat bereits vor längerer Zeit Kontakt mit den dortigen Verantwortlichen aufgenommen, die Realisierung der Übertragung von VA-Daten dorthin steht bislang aber noch aus. Sämtlicher von VA erzeugter Programmcode ist auf Github (https://github.com/VerbaAlpina/Verba-Alpina-Plugin) frei zugänglich und nachnutzbar.

Abschließend sei noch der Aspekt der Lizensierung erwähnt. VerbaAlpina ist der Meinung, dass Forschungsdaten im weitesten Sinne grundsätzlich frei zugänglich gemacht werden müssen. Entsprechend werden die Projektdaten von VA, soweit möglich, unter der CC-BY-SA 3.0 DE Lizenz zur Verfügung gestellt. VerbaAlpina fühlt sich den FAIR-Prinzipien (https://www.force11.org/group/fairgroup/fairprinciples) verpflichtet: Findable – Accessible – Interoperable und Re-usable sein!

Anhang

Eckdaten der technischen Realisierung

Modularer Aufbau: Datenbank (VA_DB) – Publikationsportal (VA_WEB) – Mediathek (VA_MT)

  • VA_DB: MySQL-Cluster
  • VA_WEB: WordPress-Installation mit Anbindung an MySQL-Datenbank
  • WordPress: PHP-Framework, weit verbreitet, standardisiert;
  • Visualisierung der Projektdaten auf einer Google-Map
  • Anpassung der WordPress-Basisinstallation durch projektspezifische Erweiterungen, möglichst in Form von sog. Plugins.
  • Plugin-Konzept ⇒ Synergieeffekte durch Weiterverwendung in anderen Projekten

Beispiel: Strukturierte Erfassung von Daten aus einem Sprachatlas

VALTS-Karte IV 73. Orange Markierung: Verwendung der Bezeichnung Sennküche für den SENNEREIRAUM INNERHALB DER ALPHÜTTE in der Ortschaft Bichlbach (T06). Grüne Markierung: Verwendung der Bezeichnung Taje für die ALPHÜTTE in der Ortschaft Sankt Leonhard (T34).

Die Abbildung präsentiert einen Ausschnitt aus dem VALTS|Vorarlberger Sprachatlas-Karte IV 73 („Die Sennhütte bzw. der Sennereiraum auf der Alpe, Lautung und Bedeutung von Tieje, Taje f.“).

Die Karte ist ein Repräsentant einer sog. Punktsymbolkarte, die die Verbreitung der sprachlichen Merkmale hauptsächlich durch unterschiedliche Symbole visualisiert, die jeweils bestimmten definierten Typen zugeordnet sind. Wesentlich ist demnach die vorangegangene Typisierung des gesammelten Sprachmaterials. Diese Art von Sprachkarte steht einer anderen Art gegenüber, auf der jeweils die konkreten Einzelbelege in häufig phonetischer Transkription direkt neben die korrespondierenden Erhebungspunkte geschrieben werden, ohne dass die Einzelbelege in irgendeiner Weise als Vertreter bestimmter Typen markiert werden würden.

Die Eintragungen auf dieser Karte sind sehr heterogen. So sind zunächst mehrere Konzepte auf einer Karte versammelt:

  • SENNHÜTTE
  • SENNEREIRAUM

Aus der Legende geht hervor, dass auf der Karte darüberhinaus noch weitere Konzepte dokumentiert sind:

  • SENNEREIRAUM INNERHALB DER ALPHÜTTE,
  • PRIMITIVE SENNHÜTTE AUF MAIENSÄßEN,
  • SENNKÜCHE,
  • KÄSEKELLER,
  • ALPHÜTTE

Die meisten dieser Konzepte sind nicht flächendeckend in allen kartierten Erhebungsorten abgefragt und dokumentiert worden. Insofern besteht also eine Inkonsistenz in der Fläche.

VerbaAlpina unterscheidet im Hinblick auf die Sprachdaten mehrere Abstrahierungsstufen. An der Basis befindet sich jeweils der individuelle Einzelbeleg, der von einem Gewährsmann/Informanten gleichsam zu Protokoll gegeben wurde. Diese Einzelbelege können sodann in verschiedener Weise typisiert werden. So können zum einen mehrere Einzelbelege, die bestimmte phonetische Gemeinsamkeiten aufweisen, zu phonetischen Typen zusammengefasst werden. Zum anderen können unterschiedliche Einzelbelege Repräsentanten ein und desselben morpholexikalischen Typs sein, unabhängig von phonetischen Eigenheiten.

Die (fiktiven) Einzelbelege Kaas und Kees würden z.B. aufgrund der differierenden Vokalrealisierung zwei unterschiedlichen phonetischen Typen zuzuordnen sein, wären jedoch beide auf denselben morpholexikalischen Typ Käse zu beziehen.

Auf der VALTS-Karte finden sich Vertreter sowohl von Einzelbelegen wie auch von phonetischen und morpholexikalischen Typen. Ein Vertreter eines Einzelbelegs wäre z. B. der Eintrag toːə in der Kartenlegende zum Erhebungspunkt T34, der als Vertreter des phonetischen Typs Taje aufgefasst wird. Diesem phonetischen Typ Taje wird auf der Karte der phonetische Typ Tieie gegenübergestellt, wobei das unterscheidende Merkmal offenkundig der hinter dem anlautenden T eingeschobene i-Laut ist. Grundsätzlich wäre die Definition weiterer phonetischer Typen denkbar, die sich an anderen lautlichen Merkmalen orientieren würden. So könnte man z.B. auch Belegvarianten, die dem Muster Toje folgen, oder solche, die anstelle des o ein e aufweisen, als weitere phonetische Typen auffassen.

Neben phonetischen Typen begegnen auf der VALTS-Karte auch morpholexikalische Typen. Als solche wären z.B. die unter der Rubrik „Deutsche Bezeichnungen“ aufgelisteten Bezeichnungen (Senn-, Alp– oder Berg-)Hütte oder Sennhaus aufzufassen. Die Karte gibt keinen Aufschluss über die dahinterstehenden Einzelbelege und deren individuelle lautliche Varianten. Unsicherheit besteht auch im Hinblick auf die Frage, ob ein Informant nun Sennhütte, Alphütte, Berghütte oder einfach nur Hütte verwendet hat. Die strukturierte Erfassung der Daten zwingt jedoch jeweils zu klaren Entscheidungen, die daher oftmals nicht leichtfallen. Strenggenommen ist es im vorliegenden Fall gar nicht möglich, eine Entscheidung zu treffen. Lediglich die Verwendung des Wortes Hütte, möglicherweise als Bestandteil eines Kompositums, ist gesichert.

Bei der strukturierten Erfassung der Daten muss der Status jeder Eintragung identifiziert und entsprechend notiert werden. Eine automatisierte Erfassung der Daten ist unmöglich, manuelle Erfassung durch Personen mit sprachwissenschaftlichem Fachwissen zwingend erforderlich.

Das oben präsentierte Beispiel aus dem Vorarlberger Sprachatlas würde sich skizzenhaft in folgender Weise im relationalen Datenformat abbilden lassen:

Metadatenkategorien (Variable):

  • Konzept
  • Bezeichnung_morpholexikalischer Typ
  • phonetischer Typ
  • Einzelbeleg
  • Gemeindename
  • Gemeindenummer
Konzept Bezeichnung_
morpholexikalischer Typ
Bez_phontischer Typ Einzelbeleg Gemeindename Gemeindenummer
SENNEREIRAUM INNERHALB DER ALPHÜTTE Sennküche Bichlbach T6
ALPHÜTTE Teie(n) Taje toːə St. Leonhard T34

Grundlage für die Transkription ist eine von VA erstellte sog. Codepage, in der die Regeln für die Abbildung von Sonderzeichen durch ASCII-Zeichen festgelegt sind.

Ausschnitt aus den Transkriptionsregeln von VerbaAlpina für die Erfassung von Daten aus Sprachatlanten