Archiv des Autors: Stephan Lücke

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

(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 !

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).¹. 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.²

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 day³, 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 here⁴:

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.⁵

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.⁶

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.⁷

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:⁸

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 map⁹

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:

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

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/).¹⁰. 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.

Grassi documents the local variation of a single small town in the Italian province of Trento ↩
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. ↩
Such is the case in the AIS ↩
AIS 1218_1, 129 ↩
This would be the case, for example, if the Böhmer Ascoli system, used for example in the AIS, were transcribed directly into IPA instead of the present one, since IPA does not allow such a fine differentiation with regard to the individual sounds as Böhmer Ascoli does ↩
The procedure is sketched in <a href="http://www.kit.gwi.uni-muenchen.de/pdf/band/001/korpus-im-text_band_001_v001.pdf">S. Lücke / C. Riepl / C. Trautmann, Softwaretools und Methoden für die korpuslinguistische Praxis (Korpus im Text 1, München 2017</a>, S. 126f. ↩
A master thesis has just been completed at the Institute of Computer Science of the LMU, 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. ↩
The corresponding sql-statment reads as follows: SELECT concat(a.Aeusserung, ‚ (‚, group_concat(f.IPA order BY f.Id_Token SEPARATOR ‚ ‚),‘)‘ ) AS aeusserung, b.erhebung, b.karte, b.nummer, b.stimulus, c.Nummer, c.Alter_Informant, c.Geschlecht, e.Beschreibung_F, ‚[name of transcriptor]‘ as erfasst_von, a.erfasst_am FROM aeusserungen a JOIN stimuli b USING(id_stimulus) JOIN informanten c USING(id_informant) JOIN vtbl_stimulus_konzept d USING(id_stimulus) JOIN konzepte e USING(id_konzept) JOIN tokens f ON a.Id_Aeusserung=f.Id_Aeusserung WHERE a.Aeusserung LIKE ‚%lac/a-/%‘ and b.Erhebung LIKE ‚AIS‘ AND b.Karte LIKE ‚1218‘ AND b.Nummer LIKE ‚1‘ AND c.Nummer LIKE ‚128‘ AND e.Beschreibung_F LIKE ‚PETIT-LAIT, APRÈS LA PREMIÈRE SÉPARATION DES COMPOSANTS SOLIDES, EST DONNÉ À MANGER‘ GROUP BY a.Id_Aeusserung; ↩
AIS: Map 1152: un’ape; le api“ ALF: Map 1: abeille“ ALJA: Map 792: (l‘) abeille *(le) mâle des abeilles“ ASLEF: Map 1148: ape“ TSA: Map III_28: Biene“ (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>) ↩
S. Chiarcos, Christian; McCrae, John; Cimiano, Philipp; Fellbaum, Christiane (2013 ↩

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

(4835 Wörter)

Abstract

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ßerung¹

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.²

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/).³, und die VerbaAlpina-Daten werden bald auch in die LLOD-Cloud eingebunden sein.⁴

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

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

AIS 1218_1, 129 ↩
Fragezeichen und Ampersands (&) müssen dabei durch den jeweiligen Hexadezimalwert des Zeichens in der Unicode-Tabelle (? = 3f, & = 26) mit vorangestelltem % ersetzt werden. Die DOI 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/?page_id=133&db=191&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=/%3fpage_id=133%26db=191%26single=L1435</a> ↩
S. 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. ↩
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> ↩

Unter der Haube – Ein Blick in den Maschinenraum von VerbaAlpina (im Rahmen der Ringvorlesung „Einblicke in digitale sprachwissenschaftliche Forschungsprojekte“) (Zitieren)

(2328 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.
Zur Erinnerung:
Kernfrage von VerbaAlpina: 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)
Zur Frage des „wo“: 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 und 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ÄSE ⇒ Molke, 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 FROM orte a WHERE a.Name IN ('Mello (Sondrio)','Albosaggia') AND a.Beschreibung LIKE 'Commune']])

Transkriptionsverfahren

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)

aktuell Thema einer Masterarbeit in der Informatik (Methoden: „nearest neighbour“ oder „deep learning“)
daher manuelle Erfassung der Daten mit dem VA-Transkriptionstool:

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

Typisierung

Manche Quellen (Sprachatlanten) dokumentieren die individuelle Sprecheräußerung („Einzelbeleg“) in phonetischer Transkription (so z. B. der AIS)
VerbaAlpina ist im Wesentlichen an lexikalischer Variation interessiert
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„
Arbeit, die nur von Sprachwissenschaftlern geleistet werden kann
Nutzung des Typisierungstools:

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 FAIRness

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

Personen: Gemeinsame Normdatei (GND) der Deutschen Nationalbibliothek (DNB), hervorgegangen aus Personennamendatei (PND), Schlagwortnormdatei (SWD) und Gemeinsamer Körperschaftsdatei (GKD) [sehr gutes Suchportal für die GND: http://swb.bsz-bw.de/DB=2.104/]
Beispiel: Alexander der Große: http://d-nb.info/gnd/118501828
Normdaten sind meist (alpha)numerische eindeutige Identifikatoren
Weitere Beispiele für Normdaten: Geonames für Geographica
Beispiel: London (welches? Hauptstadt von UK oder London in Kanada?) ⇒ Geonames-Normdatum macht es klar
Normdaten für antike Geographica: https://pleiades.stoa.org/places/422960 (Lavinium)

Normdaten für Konzepte

Q-IDs von Wikidata
Beispiel: KÄSE
auffindbar über Wikipedia-Artikel: https://de.wikipedia.org/wiki/K%C3%A4se, am linken Rand Link auf Wikidata-Datenobjekt: https://www.wikidata.org/wiki/Q10943
Am unteren Ende jeder Wikidata-Konzept-Seite finden sich Identifikatoren („Identifiers„) von anderen Normdaten-Produzenten (z. B. für London/Ontario = https://www.wikidata.org/wiki/Q92561 = https://www.geonames.org/6058560)
VA registriert diese Wikidata Q-IDs in der Tabelle der Konzepte:
Das Ergebnis zeigt auch die VA-eigene ID des Konzepts KÄSE. Die Tabelle enthält demnach bereits ein entsprechendes Mapping.

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

Methodologie: Dokumentation aller Aspekte, die VerbaAlpina betreffen
Lexikon-Alpinum
Publikationsplattform

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

API: „application programming interface, dt.: Programmierschnittstelle – für automatischen Zugriff durch Maschinen
Dokumentation: https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=8844&db=xxx
Abruf der Coredaten von VerbaAlpina
Drei verschiedene Gruppierungen: Konzepte, morpholexikalische Typen, Gemeinden; außerdem: Einzelbelege
Beispiel: Export des Morpholexikalischen Typs „malga; roa; sub; f; 0″ (Orthographie; Sprachfamilie; Wortart; Affigierung): https://www.verba-alpina.gwi.uni-muenchen.de/?api=1&action=getRecord&id=L90&version=182&format=csv&empty=0

IT-Team von VerbaAlpina

David Englmeier (Frontend, v.a. Kartierung)
Florian Zacherl (Datenbank und Schnittstellen)
Filip Hristov (Hilfskraft)

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

(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.

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

(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)

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

(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

Thomas Krefeld (2018): Linguistische Theorien im Rahmen der digital humanities. Korpus im Text. Version 1 (27.08.2018, 21:33). url: https://www.kit.gwi.uni-muenchen.de/?p=28010&v=1
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
Lücke, Stephan (2018): VerbaAlpina – Aspekte der informatischen Konzeption und technischen Realisierung (https://www.verba-alpina.gwi.uni-muenchen.de/?p=6495&db=181)
Krefeld, Thomas (2018): VerbaAlpina – oder: der Transfer der Geolinguistik in die digital humanities (https://www.verba-alpina.gwi.uni-muenchen.de/?p=5969&db=181)
Krefeld, Thomas / Lücke, Stephan (2014): VerbaAlpina – Der alpine Kulturraum im Spiegel seiner Mehrsprachigkeit, in Ladinia XXXVIII, 189-211 (http://www.verba-alpina.gwi.uni-muenchen.de/wp-content/uploads/krefeld_luecke_l38_2014.pdf?db=181)
Lücke, S. / Zacherl, F.: s.v. “Forschungsdatenmanagement”, noch unpubliziert; erscheint demnächst in: VA-de 18/2, Methodologie, vorläufig erreichbar unter https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=493&db=xxx&letter=F#112

VerbaAlpina@GeRDI (Zitieren)

(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)

(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-Schema (Download Powerpoint-Datei)

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

VA-Projektbeschreibung für die Teilnehmer des statistischen Praktikums des Statistischen Beratungslabors des Instituts für Statistik der LMU (Zitieren)

(903 Wörter)

Abstract

Im Alpenraum gibt es für die Bezeichnung einer Sache (= Konzept) normalerweise, verteilt auf eine große Anzahl von Sprachen und Dialekten, eine Vielzahl von verschiedenen Wörtern. Umgekehrt kann ein Wort unter Umständen mehrere unterschiedliche Konzepte bezeichnen. Dieser wechselseitige Zusammenhang variiert regional (Georeferenzierung) und über die Zeit (Chronoreferenzierung). Als weitere Variable kommen das Genus und die Herkunft eines Wortes ins Spiel. Außerdem können die Sachen zu Domänen zusammengefasst werden (z.B. Gebäude, Produkte, Werkzeuge -> vgl. oben INTERAKTIVE KARTE > KONZEPTE). Die skizzierten Zusammenhänge können statistischen Analysen unterzogen werden. Beispiel: Welcher Zusammenhang besteht zwischen der Anzahl von Bezeichnungen für ein bestimmtes Konzept? Ist z.B. die Anzahl von Bezeichnungen pro Konzept in der Domäne „Produkte“ durchschnittlich größer als in der Domäne „Gebäude“?

Im Detail

VerbaAlpina (= VA; https://www.verba-alpina.gwi.uni-muenchen.de/) ist ein seit 2014 von der DFG gefördertes Langzeitprojekt. Ziel des Projekts ist die systematische Sprach- und politische Grenzen überschreitende Sammlung von Bezeichnungen, die im Alpenraum für ausgewählte Konzepte gebräuchlich sind oder waren.

VerbaAlpina unterscheidet zwischen Bezeichnung und Konzept. Mit Konzept ist eine außersprachliche Kategorie gemeint, die auch als Begriff oder „platonische“ Idee bezeichnet werden kann; zwischen Konzepten und Bezeichnungen besteht keine 1:1-Relation: für manche Konzepte gibt es in manchen Sprachen keine Bezeichnung; für andere Konzepte kann es dagegen in manchen Sprachen sehr viele, synonyme Bezeichnungen geben. Zur klaren Unterscheidung zwischen „Bezeichnung“ und Konzept verwendet VerbaAlpina folgende Konvention: Ist ein Konzept gemeint, wird es in Versalien geschrieben, meint man eine Bezeichnung, wird das Wort kursiv gesetzt. Ein Beispiel: KÄSE meint das Konzept, also eine FESTE MASSE, DIE AUS MILCH DURCH DEN ZUSATZ EINES GERINNUNGSMITTELS ERZEUGT WIRD. Demgegenüber ist mit Käse das Wort gemeint, mit dem das Konzept KÄSE bezeichnet wird. Andere Bezeichnungen für KÄSE wären z.B. das italienische formaggio oder das französische fromage. VA ist jedoch weniger an den hochsprachlichen Bezeichnungen interessiert. Vielmehr geht es um die teils zahlreichen dialektalen Bezeichnungen für die von VA ausgewählten Konzepte. Für KÄSE wären dies z.B. die Bezeichnung caciolo, ciucc oder fontina, wobei es im Einzelfall immer sein kann, dass diese Bezeichnungen einen ganz bestimmten Typ von KÄSE bezeichnen.

VA ist lexikalisch ausgerichtet, d.h. phonetische Variationen ein und desselben Wortes werden jeweils zu einem sog. morpholexikalischen Typ zusammengefasst (z.B. Kaas, Chaas -> Käse). Im Rahmen der Typisierung werden den morpholexikalischen Typen nach Möglichkeit auch sog. Basistypen zugewiesen. Das sind, vereinfacht gesprochen, Vorstufen eines morpholexikalischen Typs, die häufig in älteren im Alpenraum gesprochenen Sprachen wie etwa dem Lateinischen zu suchen sind. So gehen beispielsweise die beiden morpholexikalischen Typen Formaggella und Formaggiera auf den gemeinsamen Basistyp formaticu(m) zurück. Hinsichtlich der morpholexikalischen Typen wird von VA außerdem zwischen der Sprachfamilie (romanisch, germanisch, slavisch), dem Genus (m., f., n.) und der sog. Affigierung unterschieden. Letztere meint Wortelemente wie z.B. Diminutiv-Suffixe wie im Deutschen „-chen“.

Gesammelt werden ausschließlich georeferenzierte Sprachdaten. Das von VA gesammelte Material stammt bislang überwiegend aus sog. Sprachatlanten. Das sind Kartenwerke, auf denen die geographische Verbreitung von Bezeichnungen für bestimmte Konzepte markiert ist. Die Daten aus den Atlanten wurden von VA überwiegend manuell transkribiert und zusammen mit der Georeferenzierung in strukturierter Form in einer MySQL-Datenbank (VA_DB) abgelegt. Das Gesamtmaterial ist über definierte Schnittstellen abrufbar (VAP). Die Datenbank fungiert auch als Backbone der o.a. multifunktionalen Webschnittstelle (VA_WEB). Neben online-Kartographie und Dokumentation besteht dort auch ein Bereich für Projektveröffentlichungen, in dem auch die im Rahmen des statistischen Praktikums erarbeitete Studie publiziert werden soll.

Das Material aus den Sprachatlanten wird mehr oder weniger systematisch um weitere Daten ergänzt. Dazu gehören u.a. ergänzende Daten zu außersprachlichen Gegebenheiten, wie etwa die Fundorte lateinischer Inschriften im Alpenraum. Von Interesse wären auch demographische Daten, die derzeit aber noch nicht flächendeckend vorliegen. Ganz wesentlich ist der Ausgleich von Inkonsistenzen im Atlasmaterial, die sich vor allem aus Unterschieden bezüglich der von den einzelnen Atlanten abgefragten Konzepte ergibt. Zu diesem Zweck betreibt VA ein Online-Portal zum sog. Crowdsourcing: Informanten im Internet sollen dialektale Bezeichnungen der für VA relevanten Konzepte beisteuern. Nicht zuletzt auf diese Weise erhält der VA-Datenbestand eine diachrone Dimension (die jedoch in eingeschränktem Maß auch schon durch die unterschiedliche Entstehungszeit der Sprachatlanten gegeben war).

Die Daten für das statistische Praktikum können über eine MySQL-Schnittstelle zur Verfügung gestellt werden (relationales Datenformat). Aus Sicht von VA können die statistischen Analysen über folgende Variablen erfolgen:

Georeferenzierung (lat/lng)
Konzept
Bezeichnung
Basistyp
Sprachfamilie
Genus
Chronoreferenzierung (einfache Unterscheidung zwischen Atlasmaterial und Crowd)

Aus Sicht von VA könnte man aus statistischer Sicht vielleicht folgende Fragen stellen:

Verteilung von Basistypen auf Sprachgebiete, bezogen auf Konzepte
Verteilung von Morphtypen bezogen auf regionale Verteilung bezogen auf Konzepte
Variabilität von Bezeichnungen in Bezug auf Konzepte (Anzahl verschiedener Bezeichnungen pro Konzept bezogen auf Konzeptdomäne -> charkteristische Zusammenhänge, z.B. höherer Wert bei Produkten als bei Geräten oder Gebäuden)
Verteilung von Basistypen in Bezug auf Konzepte (breite, gleichmäßige Streuung über verschiedene Konzeptdomänen oder gebunden an spezifische?)
Häufung romanischer Basistypen in der Nähe von Zentren lateinischer Inschriftenfunde?
Häufung lateinischer Inschriften in der Umgebung von Ortschaften, die auf der Tabula Peutingeriana erscheinen

CSV-Daten (31.10.2019)

Crowdsourcing Publicity-Aktionen
Eintragungen ins Crowdsourcing-Tool (unbearbeitet) mit Konzepten
Lateinische Inschriften
Orte der Tabula Peutingerina
Belege mit nicht-romanischen Typen und lateinischen oder vorrömischen Basistypen
Alle typisierten Sprachdaten mit Konzepten (Das Feld Crowd gibt an, ob es sich um einen Crowdsourcing-Beleg handelt)
Polygondaten der Sprachgebiete
Vollständiger VA-Sprachdatensatz (Entspricht den Daten, die über die API abgerufen werden können; Dokumentation hier)

Kontakt

Thomas Krefeld (thomas.krefeld@lmu.de)

Stephan Lücke (luecke@lmu.de)

Introduction

Scientific Approach

Technical Aspects

VerbaAlpina tools

Betacode and Transcription Tool

Betacode

Transcription Tool

Crowdsourcing tool

Mapping tool

Cross-linkage and sustainability

Access to VA-data

Linkage with external resources

Some organizational stuff

Einführung

Scientific Approach

Technical Aspects

VA-Tools

Der VA-Betacode und das VA-Tanskriptionstool

Betacode

VA-Transkriptionstool

Crowdsourcingtool

Kartentool

Vernetzung und Nachhaltigkeit

Zugriffsmöglichkeiten von außerhalb

Verknüpfung mit externen Ressourcen

Some organizational stuff

Gliederung

Einführung

Datenerfassung

Beispiel Sprachatlanten

Transkriptionsverfahren

Typisierung

Ergebnis der systematischen Datenerfassung

Crowdsourcing (CS)

VerbaAlpina und FA*I*Rness

Normdaten für Personen und Geographica

Normdaten für Konzepte

Normdaten für morpholexikalische Typen

Die reine Technik

Technologie der interaktiven online-Karte

API

IT-Team von VerbaAlpina

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

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

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

Das Modellprojekt „eHumanities – interdisziplinär“

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

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

Vorbemerkung

Das Projekt VerbaAlpina (VA)

Besonderheiten von VA

Institutionelle Einbindung (Organisationsstruktur): VA – ITG – UB

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

Teil 2: Open Data (Martin Spenger)

Vorbemerkung

Stephan Lücke

Das Projekt VerbaAlpina – Kurzvorstellung

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

Literaturverzeichnis

Gerdi-Fragebogen zu VerbAlpina (Februar 2018)

VA@GeRDI (27. Juni 2018)

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

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

Allgemeines

Sessions

VA_DB

VA_WEB

Funktionen des Backends

Transkriptionstool

Typisierungstool

Konzeptbaum

Forschungslabor (in Planung)

Funktionen des Frontends

Methodologie

Interaktive Online-Karte

Qualitative Kartierung

Quantifizierende Darstellung

Lexicon Alpinum

Crowdsourcing: Dateninkonsistenzen und deren Ausgleich

Jenseits von VA_DB und VA_WEB: Der weitere Horizont

VerbaAlpina und FAIRness