Methodologie

Sortierung

Alle Einträge anzeigen

(no Tag)   Außersprachlicher Kontext   Funktionsbereiche   Informationstechnologie   Linguistik   Webseite  


Betacode (Zitieren)

In Anlehnung an die Terminologie des Thesaurus Linguae Graecae (TLG), der das entsprechende Konzept Anfang der 1970er Jahre für die elektronische Erfassung altgriechischer Texte mit den damaligen computertechnischen Mitteln entwickelt hatte, wird im Rahmen von VerbaAlpina die Transkription komplexer Schriftsysteme unter ausschließlicher Verwendung von ASCII-Zeichen als "Betacode" bezeichnet.
Die folgende Graphik illustriert das Verfahren anhand eines Beispiels aus dem Sprach- und Sachatlas Italiens und der Südschweiz (AIS):





Bei der Übertragung der im Sprachatlas verwendeten phonetischen Transkription nach Böhmer-Ascoli in aus ASCII-Zeichen bestehende Sequenzen wird zunächst ganz einfach zwischen Basiszeichen und Diakritika unterschieden. Sofern ein Basiszeichen im ASCII-Code vorhanden ist, wird es bei der Übertragung durch sich selbst repräsentiert (was im gegebenen Beispiel durchweg der Fall ist). Unmittelbar hinter das Basiszeichen werden sodann nacheinander alle mit ihm verbundenen Diakritika geschrieben, wobei jedes Diakritikum durch ein spezielles ASCII-Zeichen ersetzt wird. Die Zuordnung der Diakritika zu ASCII-Zeichen ist innerhalb von VerbaAlpina eindeutig und in speziellen Tabellen der VerbaAlpina-Datenbank dokumentiert. Die Wahl der Zuordnung ist, soweit möglich, geleitet vom Prinzip der optischen Ähnlichkeit. So wird im genannten Beispiel das Häkchen unterhalb des u im Wort tu durch eine öffnende runde Klammer wiedergegeben: tu(. Die Diakritika werden ausgehend von ihrer Anordnung am Basiszeichen in der Reihenfolge unten nach oben und links nach rechts hinter das Basiszeichen geschrieben. Aufgrund des Prinzips der optischen Ähnlichkeit erfolgt die Zuordnung von Diakritika zu ASCII-Zeichen unabhängig von ihrer quellenspezifischen Semantik, in anderen Worten: Auch wenn ein Häkchen unterhalb eines Basiszeichens in der einen Quelle eine vollkommen andere phonetische Bedeutung besitzt als in einer anderen Quelle, so wird dennoch in beiden Fällen das Häkchen durch eine nachgestellte Klammer wiedergegeben. Die semantischen Unterschiede werden in den quellenspezifischen Transkriptionstabellen dokumentiert: Sie regeln die Konversion des Betacodes in die Outputtranskription gemäß IPA (ein und dieselbe Beta-Kodierung kann also je nach Quelle zu ganz unterschiedlichen IPA-Kodierungen führen).
Das beschriebene Verfahren besitzt eine Reihe von Vorteilen:
- Die Datenerfassung kann in vergleichsweise hohem Tempo auf herkömmlichen Standardtastaturen erfolgen und ist vollständig betriebsystemunabhängig,
- die Transkriptoren benötigen keine Kenntnisse der phonetischen Transkriptionssysteme,
- es lassen sich beliebige Zeichen bzw. Diakritika erfassen, unabhängig davon, ob diese in Unicode kodiert sind oder nicht, und
- die elektronische Datenerfassung erfolgt ohne Informationsverlust.
Durch Ersetzungsroutinen kann der Betacode in nahezu beliebige andere Transkriptionssysteme überführt werden. Im Zuge solcher Konvertierungen kommt es unter Umständen zu Informationsverlusten, die jedoch im Wesen der Transkriptionssysteme begründet sind. So unterscheidet die phonetische Transkription nach Böhmer-Ascoli verschiedene Öffnungsgrade in einer Granularität, die im IPA-System nicht vorgesehen ist.

(auct. Thomas Krefeld | Stephan Lücke)

Tags: Linguistik Informationstechnologie



Codepage (Zitieren)

VerbaAlpina vereinigt Daten aus verschiedenen Arten von Quellen: Daten aus gedruckten Sprachatlanten und Wörterbüchern, die zunächst noch digitalisiert werden müssen, sowie bereits elektronisch vorliegende Daten aus einer Reihe von Partnerprojekten. Jede dieser unterschiedlichen Quellen verwendet mehr oder weniger individuelle Systeme zur Transkription. Um die erforderliche Vereinheitlichung zu realisieren, sind Listen nötig, in denen festgelegt ist, welches Schriftzeichen im Transkriptionssystem der einen Quelle welche Entsprechung im Transkriptionssystem der anderen Quelle besitzt. Hauptsächlich geht es darum, die unterschiedlichen Transkriptionssysteme auf das Internationale Phonetische Alphabet (IPA) abzubilden, das innerhalb von VerbaAlpina als Referenztranskription fungiert. Zur Überführung eines quellenspezifischen Transkriptionssystems in das IPA-System ist die Anlage einer vollständigen Liste in Tabellengestalt mit Schriftzeichenentsprechungen erforderlich. Eine solche Tabelle wird als "Codepage" bezeichnet.
Nachfolgend ein Auszug aus der für die Konvertierung des AIS-Transkriptionssystems in IPA grundlegenden Codepage. Insgesamt umfasst diese Codepage rund 4500 Zeilen/Zuordnungen:


Die Kolumne `BETA` enthält die im AIS verwendeten Zeichen in nach dem Prinzip des Betacodes transkribierter Form, die Kolumne `IPA` das jeweils entsprechende IPA-Zeichen und die Kolumne `HEX` den oder die Zahlenwerte der Unicodetabelle, die dem jeweiligen IPA-Zeichen entsprechen.

Eine vollständige Übersicht über die Codepages für alle Quellen von VerbaAlpina findet sich hier.

(auct. Stephan Lücke)

Tags: Linguistik Informationstechnologie



Datenformat (Zitieren)

s. Datenmodellierung

Tags: Informationstechnologie



Datenmodellierung (Zitieren)

Unter Datenmodellierung versteht VerbaAlpina die theoretische Entwicklung einer Gliederung von zunächst unstrukturiertem Datenmaterial. Im Wesentlichen geht es dabei um die Definition von sog. Entitäten, also einer Klasse von digitalen Einzelobjekten, denen eine bestimmte Art und Anzahl von Attributen (= Eigenschaften) gemeinsam ist. Ausschließlich diese Attribute sind für die inhaltliche und funktionale Bestimmung der Objekte relevant. Im Zuge der Datenmodellierung erfolgt auch die Festlegung der Beziehungen zwischen den unterschiedlichen Entitäten.
Von der Datenmodellierung sind zu unterscheiden die Datenstrukturierung und das Datenformat. Mit Datenstrukturierung ist die konkrete Anwendung des theoretischen Datenmodells auf einen Datenbestand gemeint, als deren Ergebnis eine strukturierte Repräsentation der Daten etwa in Gestalt einer oder mehrerer Tabellen vorliegt. Ein strukturierter Datenbestand kann wiederum in unterschiedlichen Datenformaten abgebildet werden (z.B. in Tabellenform = relationales Datenformat, XML-Format usw.), wobei häufig eine Transformation von einem in ein anderes Format möglich ist.

s. auch Relationales Datenmodell

(auct. Stephan Lücke)

Tags: Informationstechnologie



Digital Humanities (Zitieren)

Das Projekt VerbaAlpina wurde von vornherein mit Blick auf Webtauglichkeit konzipiert, denn es will ganz entschieden zur Überführung der etablierten geisteswissenschaftlichen Traditionen, genauer: der Geolinguistik, in die Digital Humanities beitragen . Dieser Ausdruck ist zwar mittlerweile fest etabliert; seine beiden Konstituenten sind jedoch keineswegs selbsterklärend und verdienen jeweils eine methodologische Bemerkung.

(1) Digital hat eine Reihe komplexer Implikate:
  • Die empirische Grundlage der Forschung besteht in Daten (vgl. Schöch 2013), d.h. in digital kodierten und strukturierten oder mindestens strukturierbaren Einheiten; dabei handelt es sich teils um bereits publizierte und sekundär digitalisierte Daten (wie z.B. die älteren Atlasmaterialien), teils aber auch um neu zu erhebende Daten. Im Blick auf die relevanten Konzepte werden möglichst umfangreiche Datenbestände angestrebt. Die Methode ist also quantitativ und weitgehend induktiv.
  • Die Forschungskommunikation erfolgt unter den medialen Bedingungen des Internets. Das eröffnet zunächst die Möglichkeit unterschiedliche Medien (Schrift, Bild, Video und Ton) hypertextuell zu verflechten; weiterhin können die als Forscher (vor allem als Projektpartner) und/oder als Informanten beteiligten Personen kontinuierlich miteinander kommunizieren und kooperieren.
  • Damit wird interessierten Wissenschaftlern das Angebot gemacht, an der Entwicklung dieser projektbasierten und kollaborativen Forschungsplattform mitzuwirken. Diese Perspektive ist mindestens in doppelter Hinsicht nützlich und weiterführend: Sie erlaubt es, unterschiedliche Standorte einzubinden und – vor allem – die konstruktive Verschränkung von Informationstechnologie und Sprachgeographie mit öffentlichen Ressourcen voranzutreiben, ohne auf den (juristisch und ökonomisch problematischen) Support privater IT-Firmen zurückgreifen zu müssen.
  • Das projektrelevante Wissen kann auch auf längere Zeit kontinuierlich akkumuliert und modifiziert werden, obwohl die Garantie einer dauerhaften Verfügbarkeit technisch noch schwer umzusetzen ist (vgl. hierzu die wichtige CLARIN-D-Forschungsinfrastruktur http://de.clarin.eu/de/home.html). Jedenfalls ist eine Publikation der Ergebnisse auf dinglichen Trägermedien (Bücher, CDs oder DVDs) vor diesem Hintergrund kein zentrales Anliegen mehr; gleichwohl wird eine sekundäre Druckoption eingerichtet, so wie es auch die Online-Lexikographie gelegentlich anbietet, so z. B. der exemplarische Tesoro della Lingua Italiana delle Origini.
(2) Hinter Humanities steht eine spezifische Konzeption des Forschungsfachs, die sich mit dem überkommenen Begriff der Philologie nur ganz unzulänglich erfassen lässt. Diese genuin textorientierte Tradition wurde de facto bereits durch die mit gesprochener Sprache arbeitenden Bereiche der Linguistik überholt. In Bezug auf VerbaAlpina wäre indes auch die Rede von digital linguistics zu eng, denn obwohl sprachliche Daten im Zentrum stehen, werden ganz bewusst auch außersprachliche Daten einbezogen, die für das historische Verständnis geolinguistischer Verhältnisse unabdingbar sind.

(auct. Thomas Krefeld)

Tags: Informationstechnologie



Digital Object Identifier (DOI) (Zitieren)

Ein Digital Object Identifier (DOI) ist eine weltweit eindeutige und unveränderliche Adresse, über die elektronische Ressourcen wie z. B. Websites erreichbar sind. Die Erreichbarkeit ist auch dann gewährleistet, wenn sich z. B. der sogenannte "Uniform Resource Locator" (URL) einer Ressource ändert. Der wesentliche Nutzen des DOI-Systems besteht demnach in der nachhaltigen Zitierbarkeit elektronischer Ressourcen. Dies wird durch einfaches Mapping erreicht: Die DOI-Stiftung führt ein Register, in dem jedem DOI die jeweils aktuelle URL einer Ressource zugeordnet ist. Bei Änderung einer URL muss entsprechend die Änderung im Register der DOI-Stiftung erfolgen. URL-Änderungen müssen der DOI-Stiftung durch die DOI-Registrierungsagentur mitgeteilt werden, die den betreffenden DOI hatte registrieren lassen. Die Eintragung der Webressource von VerbaAlpina im DOI-Register erfolgt über das "Referat Elektronisches Publizieren" der Universitätsbibliothek der LMU, das seinerseits die Registrierung nicht direkt bei der DOI-Stiftung, sondern beim DataCite-Konsortium vornimmt, das Mitglied der DOI-Stiftung ist.

Voraussetzung für das zuverlässige Funktionieren des Konzepts der DOI ist neben dem verantwortungsbewussten Handeln des Domainbetreibers auch die Verlässlichkeit der mit der Pflege der entsprechenden Zuordnungstabellen beauftragten Institution, also der zuständigen DOI-Registrierungsagentur. Diese sollte eine möglichst unbegrenzte Existenzperspektive besitzen, so wie dies etwa bei den Universitäts-, Staats- und Nationalbibliotheken gegeben ist. In jedem Fall sollte der Domainbetreiber allfällige Änderungen der Adresse eines digitalen Objekts an die Registrierungsagentur melden, damit diese die entsprechenden Einträge im DOI-Register anpassen kann. Umgekehrt sind auch regelmäßige Überprüfungen von Seiten der DOI-Registrierungsagentur(en) vorstellbar, in etwa vergleichbar mit den traditionellen "Revisionen" in Bibliotheken.

Der DOI von VerbaAlpina lautet doi:10.5282/verba-alpina. Die Zahl vor dem Schrägstrich (10.5282) wird als Präfix, die sich anschließende Zeichenfolge als Suffix bezeichnet. Das Präfix ist der zuständigen DOI-Registrierungsagentur – in diesem Fall der Universitätsbibliothek der LMU – zugeordnet. Damit ein Zitat beispielsweise in einem wissenschaftlichen Aufsatz direkt auf das Portal von VerbaAlpina führt, muss dem DOI die URL der DOI-Stiftung vorangestellt werden: http://dx.doi.org/10.5282/verba-alpina.
Nahezu demselben Zweck wie der DOI dient der sogenannte Uniform Resource Name (URN), und auch die Funktionsweise ist in etwa die gleiche. Anders als beim DOI ist beim URN jedoch die Registrierung mehrerer URLs für eine Ressource möglich. Dies kann etwa dann von Interesse sein, wenn Ressourcen im Sinne der Ausfallsicherheit oder Nachhaltigkeit auf verschiedenen Servern mit entsprechend unterschiedlichen URLs abgelegt werden. Anders als beim DOI wird das URN-Register nicht von einer einzigen Institution, sondern dezentral von verschiedenen nationalen Organisationen betrieben. Das Auffinden einer Webressource kann nur über den Registrierungsserver ("Resolver") der Institution erfolgen, bei der der URN registriert worden war. Für Deutschland übernimmt diese Aufgabe die Deutsche Nationalbibliothek (DNB). Die URN von VerbaAlpina lautet urn:nbn:de:bvb:19-verba-alpina-8. Das Portal von VerbaAlpina ist unter Einbindung des DNB-Resolvers unter der URL http://nbn-resolving.de/urn:nbn:de:bvb:19-verba-alpina-8 erreichbar.

Grundsätzlich ist es möglich, DOIs und URNs auch für Teilressourcen einer Domain (z.B. einzelne Webseiten oder Mediendateien) registrieren zu lassen. Alternativ können Teilressourcen einer Domain auch über die Einbindung der URL-Parameter in den DOI angesprochen werden. Dafür muss eine spezielle Syntax verwendet werden, die durch das folgende Beispiel illustriert wird: Der auf die URL des Eintrags Forschungsdatenmanagement (https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=493&db=xxx&letter=F#112 ) verweisende DOI sieht folgendermaßen aus:

http://dx.doi.org/10.5282/verba-alpina?urlappend=/%3fpage_id=493%26db=xxx%26letter=F#112

Das Beispiel zeigt, dass das Fragezeichen sowie die sog. "Ampersands" (&) durch den jeweiligen Hexadezimalwert des Zeichens in der Unicode-Tabelle (? = 3f, & = 26) ersetzt werden müssen.

Literatur: Dreyer 2012

(auct. Stephan Lücke | Julian Schulz [ITG])

Tags: Informationstechnologie



Digitalisierung (Zitieren)

Mit Digitalisierung wird im Kontext von VerbaAlpina nicht der schlichte Einsatz von Computern zur elektronischen Datenverarbeitung, sondern vielmehr und wesentlich die digitale Tiefenerschließung des Materials durch systematische und transparente *Strukturierung* und Kategorisierung verstanden.





Dabei kommt quasi ausschließlich das relationale Datenmodell zum Einsatz, bei dem das Datenmaterial grundsätzlich in Tabellengestalt organisiert wird. Die Tabellen bestehen aus Zeilen (= Datensätze, Tupel) und Spalten (= Attribute, Felder, Eigenschaften), wobei jede Tabelle in jede Richtung um zusätzliche Zeilen und Spalten erweitert werden kann. Zwischen den Tabellen bestehen logische Zusammenhänge, die sinnvolle Verknüpfungen und entsprechende synoptische Darstellungen (sog. "Joins") von zwei und mehr Tabellen erlauben. Für die Verwaltung der Tabellen setzt VerbaAlpina derzeit das Datenbankmanagementsystem MySQL ein, die Tabellen sind jedoch nicht an dieses System gebunden, sondern können jederzeit z.B. in Textgestalt mit eindeutig zu definierenden Trennzeichen für Feld- und Datensatzgrenzen (sog. Separatoren) zusammen mit den Spaltennamen und der Dokumentation der logischen Zusammenhänge (Entity-Relationship-Modell) exportiert werden. Die derzeit vielfach verwendete XML-Struktur wird im operativen Bereich von VerbaAlpina nicht eingesetzt. Im Rahmen des Schnittstellenkonzepts ist XML jedoch als Exportformat verankert.

Neben der logischen Strukturierung der Daten spielt im Zusammenhang mit dem Stichwort "Digitalisierung" die Kodierung der Schriftzeichen die zweite zentrale Rolle. Gerade im Hinblick auf die Langzeitarchivierung des Datenmaterials ist der richtige Umgang mit dieser Thematik von großer Bedeutung. Soweit möglich, orientiert VerbaAlpina sich dabei an der Kodierungstabelle und den Vorgaben des Unicode-Konsortiums. Im Fall der Digitalisierung von Schriftzeichen, die bislang noch nicht in die Unicodetabelle aufgenommen sind, erfolgt die digitale Datenerfassung eines Einzelzeichens vorzugsweise durch Serialisierung in Gestalt einer Abfolge von Zeichen aus dem Unicode-Bereich x21 bis x7E (innerhalb des ASCII-Bereichs). Die entsprechenden Zuordnungen werden in speziellen Tabellen dokumentiert, wodurch eine spätere Konvertierung in dann möglicherweise vorhandene Unicodewerte stets möglich ist.

(auct. Stephan Lücke)

Tags: Linguistik Informationstechnologie



Entity Relationship (Zitieren)

Daten können grundsätzlich zu sogenannten "Entitäten" zusammengefasst werden. Dabei handelt es sich um Klassen von Daten, die jeweils eine bestimmte Art und Anzahl spezifischer Merkmale aufweisen. So können beispielsweise die Städte Trento, Innsbruck und Luzern eine Klasse "Orte" bilden, der die Merkmale "Ortsname", "Längengrad", "Breitengrad", "Staat" und "Einwohnerzahl" zu eigen ist. Die einzelnen Mitglieder einer solchen Klasse unterscheiden sich durch die unterschiedlichen Werte der die Klasse ausmachenden Merkmale.
In einer relationalen Datenbank werden Entitäten idealerweise in jeweils eigenen Tabellen gespeichert, wobei jede Tabellenspalte die Werte jeweils eines spezifischen Merkmals aufnimmt. Die Tabellenzeilen enthalten die individuellen, durch ihre Merkmalswerte von einander unterschiedenen Mitglieder der Datenklasse (Entität). In den allermeisten Fällen – und so auch bei VerbaAlpina – stellt eine relationale Datenbank eine Sammlung verschiedener Entitäten (und somit Tabellen) dar, zwischen denen logische Beziehungen bestehen. So wäre etwa die Entität "Informant", die durch die Merkmale "Alter", "Geschlecht", "Geburtsort" und "Wohnort" definiert ist, mit der Entität "Orte" in der Weise logisch verbunden, dass die Werte der Merkmale "Geburtsort" und "Wohnort" Entsprechungen in der Entität "Orte" besitzen. Beziehungen zwischen Mitgliedern dieser beiden Entitäten ergeben sich aus Übereinstimmungen der Werte eines oder mehrerer, ihrem Wesen nach kongruenter, Merkmale der jeweiligen Entitäten. Im gegebenen Fall könnte sich theoretisch eine Zuordnung aus identischen Werten der Merkmale "Geburtsort" und "Ortsname" ergeben, wodurch mittelbar einem Informanten die Geokoordinaten seines Geburtsortes zugeordnet werden könnten. Es ist leicht zu erkennen, dass in diesem Beispiel Probleme aufgrund von Homonymen auftreten könnten. Um dergleichen zu vermeiden, ist es üblich, Ganzzahlen als Identifikatoren (kurz: "ID") zu verwenden, die die Mitglieder einer Entität eindeutig bezeichnen.
Das skizzierte System der Entitäten und ihrer logischen Zusammenhänge wird als Entity Relationship bezeichnet. Der in einer relationalen Datenbank gesammelte Datenbestand ist ohne eine Erläuterung dieser dort bestehenden Abhängigkeiten nur schwer versteh- und nutzbar. Üblicherweise erfolgt die Abbildung der Entity Relationship in Gestalt eines graphischen Schemas.
Die Entity Relationship unterliegt während der zyklischen Entwicklungsphasen von VerbaAlpina (s. Versionierung) ständigen Anpassungen und somit Veränderungen. Jeder archivierten Version von VerbaAlpina wird das Entity Relationship Modell der jeweils zugrundeliegenden Datenbankversion in Form eines ER-Diagramms beigegeben, das mit dem Programm yEd erzeugt und als GraphML abgespeichert wird. Die mit automatischen Tools erzeugten Diagramme werden wegen des damit verbundenen erheblichen Arbeitsaufwands nicht nachträglich graphisch aufbereitet. Aus diesem Grund und wegen der hohen Komplexität der abgebildeten Strukturen sind sie daher in aller Regel für Außenstehende nicht auf Anhieb zu verstehen. Sie enthalten jedoch alle für das Verständnis der Struktur von VA_DB nötigen Informationen und stellen somit eine wichtige Voraussetzung für die Nutzung der Datenbank auch nach dem Ende der Projektförderung dar. Folgende Graphik basiert auf den Entitäten und Verknüpfungen der Datenbank VA_XXX in ihrem aktuellen Zustand (30.11.2017), bildet diese jedoch nicht vollständig ab und ist nur als illustrierendes Beispiel zu verstehen:





(auct. Stephan Lücke)

Tags: Informationstechnologie



FAIR-Prinzipien (Zitieren)

Im Jahr 2016 veröffentlichte eine große Anzahl von Wissenschaftlern aus einer ganzen Reihe von Ländern im Wissenschaftsmagazin Nature einen Artikel, in dem es darum ging, Richtlinien für den Umgang mit Forschungsdaten zu formulieren (Wilkinson, M. D. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci. Data 3:160018 doi: 10.1038/sdata.2016.18 (2016). ?). Letztlich gehen die in dieser Publikation vorgetragenen Ideen auf einen Workshop zurück, der im Januar 2014 am Lorentz Center an der Universität Leiden in den Niederlanden stattgefunden hatte. Der Titel des Workshops hatte gelautet: Jointly designing a data FAIRPORT

Zwischenzeitlich haben sich diese Ideen, die im Akronym FAIR fokussiert sind, als ein Orientierungspunkt in der aktuellen Debatte über den richtigen Umgang mit Forschungsdaten etabliert (dies wurde u.a. auf dem Netzwerktreffen des GeRDI-Projekts im Oktober 2018 deutlich; vgl. auch die FAIRGROUP der FORCE11-Community).

Das Akronoym FAIR steht für die folgenden zentralen, sich z.T. wechselseitig bedingenden, Postulate, an denen sich der Umgang mit Forschungsdaten orientieren sollte (?):

  • F — Findable
  • A — Accessible
  • I — Interoperable
  • R — Reusable

Diese Schlagwörter bedingen implizit eine ganze Reihe von Konsequenzen für den Umgang mit digitalen Forschungsdaten.

Damit Daten auffindbar sind, sollte es mindestens ein zentrales Portal geben, über das Suchanfragen gestartet werden können. Es bietet sich an, den Nachweis der Forschungsdaten – gemeint sind im Wesentlichen ihr Inhalt sowie ihr Bewahrungsort – in die seit langem etablierten Bibliothekskataloge zu inkorporieren. Zu vermeiden wären alle Konzepte, die einen Suchvorgang an unterschiedlichen Stellen verlangen würden.

Um gefunden werden können, müssen Daten selbstverständlich auch physisch existent sein. Hierbei geht es weniger um die Frage der technischen Realisierung, die z.B. durch die flächendeckend bestehenden Rechenzentren geleistet werden kann, sondern vielmehr um die Frage nach der institutionellen Zuständigkeit. Auch unter diesem Aspekt bieten sich wiederum die Bibliotheken an, die aufgrund ihrer Geschichte, ihrer genuinen Aufgabe als Wissensbewahrer sowie ihrer langfristigen Bestandsperspektive eigentlich als konkurrenzlose Kandidaten für diese Aufgabe angesehen werden können. Sie sollten die Verantwortung für die nachhaltige Bewahrung der digitalen Daten übernehmen. In welcher Form dies schließlich geschieht, ob die Bibliotheken eigene Repositorien aufbauen und verwalten oder auf Rechenzentren als Dienstleister zurückgreifen, ist von nachrangiger Bedeutung und kann von Fall zu Fall unterschiedlich gehandhabt werden.

Große Bedeutung besitzt die Konzeption und Vergabe von Metadaten, über die die eigentlichen Forschungsdaten auffindbar gemacht werden müssen. Unverzichtbar erscheint die Verwendung mindestens eines verbindlichen, hierarchisch aufgebauten Metadatenschemas, das unter Einbindung ebenfalls verbindlicher kontrollierter Vokabulare eine inhaltliche Kategorisierung der abgelegten Forschungsdaten erlaubt. VerbaAlpina hat sich vorläufig für das weit verbreitete und auch von der UB der LMU gewählte Datacite-Schema entschieden. Der Einsatz mehrerer konkurrierender Metadatenschemata wäre möglich, jedoch nur sinnvoll, wenn sie jeweils konsequent für alle erfassten Forschungsdaten angelegt werden. Untergeordnete fachspezifische Metadatenschemata können eine sinnvolle Ergänzung der übergeordneten Metadatenschemata darstellen.

Mit "accessible" ist vor allem die nicht durch rechtliche Schranken wie etwa das Urheberrecht eingeschränkte Zugänglichkeit von Daten gemeint. Dieser Punkt ist am wenigsten von den Denjenigen zu beeinflussen, die Daten sammeln oder produzieren. Neben dem Urheberrecht ist bei Datensammlungen häufig der Schutz von Persönlichkeitsrechten zu beachten. Die Forderung nach Zugänglichkeit zielt demnach vor allem darauf ab, dass sämtliche Daten, die keiner rechtlichen Beschränkung unterliegen, von den Produzenten dieser Daten nicht eigens mit rechtlichen Zugangsbeschränkungen belegt werden. Konkret bedeutet das in erster Linie den Verzicht auf das Copyright und die Anwendung eines Lizenzmodells, das konform ist mit den Bedingungen des Open Access. Weit verbreitet im wissenschaftlichen Umfeld ist die Verwendung der Creativecommons-Lizenzen (CC), von denen allerdings nicht alle die Kriterien für Open Access erfüllen. Insbesondere verstößt das Verbot kommerzieller Nutzung, das Teil einer CC-Lizenz sein kann, gegen das Konzept von Open Access. Der Grund besteht darin, dass nahezu jede Verwendung von Daten unter Umständen als "kommerzielle Nutzung" angesehen werden kann und eine klare Grenzziehung diesbezüglich aus juristischer Sicht so gut wie unmöglich ist (s. auch dazu den Methodologie-Beitrag "Lizenzierung").

Ebenso wie auch die Auffindbarkeit von Daten besitzt die Interoperabilität zwei, nämlich eine technische und eine theoretisch-organisatorische, Seiten. Um Datenbestände fruchtbringend miteinander verknüpfen und sich aufeinander beziehen zu lassen, bedarf es in vielen Fällen zunächst einer logischen Freingranulierung der Daten, die sich überdies an, zumeist fachspezifischen, Regeln orientiert. Eine ganz zentrale Rolle spielen in diesem Zusammenhang die sog. "Normdaten", bei denen es sich um definierte und, im Idealfall standardisierte, Konzeptkategorien handelt, deren einzelne Instanzen (digitale Objekte) bezogen auf eine klar definierte Art und Anzahl von Eigenschaften "distinct", also singulär sind. Die Belegung der einzelnen Objekte einer Konzeptkategorie mit numerischen oder alphanumerischen Identifikatoren ("ID"s), erlaubt die unzweideutige Referenzierung von Objekten. Die Granulierung von Datenbeständen entlang den Grenzen von Kategorien und deren einzelnen Instanzen/Objekten in Verbindung mit der Verwendung der spezifischen Identifikatoren erlaubt sodann die Verknüpfung von getrennten Datenbeständen mit kongruenten Inhalten. Echter Mehrwert entsteht allerdings erst dann, wenn es auch technisch möglich ist, auf einzelne Objekte direkt zu referenzieren und so mit nur einem Klick von einem Datenbestand zu einem Objekt eines anderen Datenbestands zu gelangen. Dies erscheint nur dann möglich, wenn tatsächlich jedem einzelnen Datenobjekt ("Granum") eine eigene URL zugewiesen wird. Im Sinne der Nachhaltigkeit muss schließlich jeder einzelnen URL auch noch eine DOI zugewiesen werden.

Die Wiederverwendbarkeit von Datenbeständen ergibt sich schließlich aus der sorgfältigen Beachtung und Umsetzung der drei vorangegangenen Postulate.

VerbaAlpina ist bemüht, sämtliche datenbezogenen Verfahren und Regelungen an den FAIR-Prinzipien auszurichten. Thomas Krefeld sieht darin grundsätzlich die Basis einer DH-Forschungsethik (Thomas Krefeld [2018]: Linguistische Theorien im Rahmen der
digital humanities. Korpus im Text. Version 2 (05.11.2018, 11:35).
Absatz 4. url: http://www.kit.gwi.uni-muenchen.de/?p=28010&v=2#p:4.). Der Auffindbarkeit der Daten dient die Kooperation mit der UB der LMU sowie dem DFG-Projekt GeRDI, die derzeit im Rahmen des Projekts e-humanities – interdisziplinär erfolgt. Vor allem der zentrale Datenbestand im Modul VA_DB wird im Zuge dessen versionsweise mit Metadaten versehen und in mehrerlei Gestalt an die UB der LMU übergeben, wo er in jedem Fall im Open-Data-Repositorium abgelegt wird. Wenigstens die Metadaten werden anschließend zusätzlich in den Index inkorporiert, der aktuell im Rahmen des Projekts GeRDI aufgebaut wird. Ziel ist es, die von VerbaAlpina gesammelten und aufbereiteten Daten zentral über den Bibliothekskatalog der UB und darüberhinaus auch über das noch in Entwicklung befindliche Suchportal des GeRDI-Projekts auffindbar zu machen. Sämtliche von VerbaAlpina verwalteten Daten werden, soweit möglich, unter eine Open-Access-konforme Creativecommons-Lizenz gestellt (bis Version 18/1 CC BY SA 3.0 de, ab 18/2 CC BY SA 4.0). Die Interoperabilität wird zum einen durch eine feine Granulierung des Datenbestands erreicht, die sich auch am Konzept der Normdaten orientiert, indem bereits bestehende Normdaten mit dem Datenmaterial von VerbaAlpina verbunden werden. Dies ist z.B. möglich mit geographischen Daten, etwa den politischen Gemeinden, die das zentrale geographische Bezugssystem von VerbaAlpina darstellen. Für die für VerbaAlpina zentralen Datenkategorien "morpholexikalischer Typ" und "Konzept" existieren wenigstens teilweise bislang noch keine Normdaten, auf die die VerbaAlpina-Daten bezogen werden könnten. In diesen Fällen ist VerbaAlpina bemüht, in Kooperation mit prädestinierten Institutionen wie etwa der Deutschen Nationalbibliothek (DNB) entsprechende Normdaten bzw. Normdatenkategorien einzurichten. Zur Bedienung der technischen Erfordernisse für eine effiziente Interoperabilität wird das zentrale lexikalische Datenmaterial datensatzweise in einer Vielzahl kleiner Dateien abgelegt, die schließlich über individuelle DOIs auf Open Data LMU angesprungen werden können. Jeder einzelnen Datei wird außerdem eine Metadaten-Datei im Datacite-Format beigegeben, die schließlich in ihrer Gesamtheit das gezielte Auffinden einzelner Dateien über den Bibliothekskatalog ermöglichen.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Forschungsdatenmanagement (Zitieren)

Im Zuge der Verbreitung digitaler Methoden rückt in jüngster Zeit die Frage ins Blickfeld, wie mit sog. "Forschungsdaten" umzugehen sei. Es scheint so, als gingen die damit verbundenen Vorstellungen auf die Verhältnisse in den Naturwissenschaften zurück. Dort liegt häufig das Szenario vor, dass z. B. große Mengen von Messdaten zunächst erhoben und anschließend in interpretierenden Texten ausgewertet werden. Dabei ergibt sich eine scheinbar klare Zweiteilung, bei der ausschließlich die Messdaten als "Forschungsdaten" bezeichnet werden. Es mag sein, dass es bisweilen Usus war oder auch immer noch ist, die Forschungsdaten als ephemer und nicht dauerhaft bewahrenswert zu erachten. Das Forschungsdatenmanagement hat sich zum Ziel gesetzt, nicht nur die interpretierenden Texte, sondern auch eben jene als "Forschungsdaten" bezeichnete Daten, die die Grundlage für die Interpretation darstellen, langfristig zu bewahren und nachnutzbar zu machen.

Das Thema "Forschungsdatenmanagement" (FDM) wird derzeit (2018) in Deutschland sowohl auf Bundes- wie auch auf Länderebene stark gefördert, und es ist bereits mit einer Reihe einschlägiger Unternehmungen begonnen worden. Die entsprechenden Aktivitäten sind vor dem Hintergrund der Bestrebungen zur Errichtung einer European Open Science Cloud (EOSC) auf EU-Ebene zu sehen. Für Deutschland sind auf überregionaler, bundesweiter Ebene in diesem Zusammenhang etwa die vom "Rat für Informationsinfrastrukturen" (RfII) ausgesprochene Empfehlung zur Einrichtung einer "Nationalen Forschungsdateninfrastruktur" (NFDI), die sich daran orientierende NFDI-Arbeitsgruppe der Akademienunion (mit Schwerpunkt auf den Geisteswissenschaften) oder auch das seit 2016 von der DFG geförderte und interdisziplinär ausgerichtete Projekt "Generic Research Data Infrastructure" (GeRDI) zu nennen. Die Projekte HeFDI ("Hessische Forschungsdateninfrastrukturen") in Hessen und das vom bayerischen Wissenschaftsministerium geförderte Projekt "eHumanities – interdisziplinär" seien an dieser Stelle stellvertretend für FDM-Initiativen auf Landesebene genannt.

Aus der Perspektive der Geisteswissenschaften ist die vermeintlich klare Trennung zwischen Forschungs- und Interpretationsdaten bzw. -texten, so wie sie im Bereich der Naturwissenschaften vereinzelt vielleicht möglich sein mag, ausgesprochen problematisch bzw. fragwürdig. VerbaAlpina jedenfalls unternimmt keine entsprechende Unterscheidung, sondern betrachtet sämtliche vom Projekt gesammelten und erzeugten Daten als ein untrennbar verwobenes Ganzes, dessen Einzelteile in vielfältiger Weise aufeinander bezogen sind. Im Sinne des "Forschungsdatenmanagements" deklariert VerbaAlpina demnach die Gesamtheit seiner auf die Module VA_DB, VA_WEB und VA_MT verteilten digitalen Daten (also Sprachdaten, Kommentare, Glossareinträge, Computercode, Mediendaten etc.) als Forschungsdatum, das getreu den FAIR-Prinzipien und orientiert an den einschlägigen Empfehlungen des RfII (RfII 2016, Anhang A, S. A-13) bewahrt werden muss. VerbaAlpina ist mit dem Status eines Pilotprojekts eingebunden in die bereits erwähnten Projekte GeRDI und "eHumanities – interdisziplinär".

Ein wesentlicher Aspekt des Forschungsdatenmanagements ist die Gewährleistung von Interoperabilität in dem Sinn, dass persistente projekt- bzw. datenbestandsübergreifende Verknüpfungen zwischen Teilmengen der jeweiligen Datenbestände möglich sind. Eine wichtige Rolle spielen dabei die sog. DOIs, "Digital Object Identifier". Diese stellen die technische Voraussetzung für die dauerhafte, URL-unabhängige Adressierbarkeit "digitaler Objekte" dar und sind für alle elektronischen Inhalte erzeugbar, die über eine URL erreichbar sind. Im Umfeld des Bibliothekswesens wurden DOIs zunächst zur persistenten Identifizierung von elektronischen Buchpublikationen (z.B. https://doi.org/10.5282/ubm/epub.25627) oder auch ganzen Websites (z.B. http://dx.doi.org.emedien.ub.uni-muenchen.de/10.5282/asica) verwendet. Abweichend von dieser Praxis verlangt das Erfordernis der Interoperabilität zwischen getrennt erarbeiteten und verwalteten Datenbeständen eine wesentlich feinere Granulierung. VA erzeugt zu diesem Zweck eine Reihe von im Internet über URLs erreichbaren Dateien, die das gesammelte Sprachmaterial gruppiert nach morpholexikalischen Typen, Konzepten, Herkunftsgemeinden und Einzelbelegen enthalten. Die Dateien sind mit den jeweils von VA vergebenen IDs der jeweiligen Datenkategorie benannt. Dateien der Kategorie "Gemeinde" tragen am Anfang des Dateinamens ein "A", "C" markiert Konzepte und "L" morpholexikalische Typen. Die jeweils nachfolgende Nummer ist die von VA vergebene ID. Der Zugriff auf diese Daten ist über die Adresse https://www.verba-alpina.gwi.uni-muenchen.de/export möglich. Die Zuweisung der DOIs erfolgt zunächst im Rahmen des Projekts "eHumanities – interdisziplinär" durch die UB der LMU, die überdies die Daten in ihren eigenen Datenbestand übernimmt und dort durch noch zu entwickelnde Verfahren und unter Anwendung eines geeigneten Metadatenschemas zusätzlich in der Tiefe inhaltlich erschließt. Ziel ist neben der Bereitstellung der Forschungsdaten im Repositorium die Integration und Auffindbarkeit der feingranulierten VA-Daten in den Bibliothekskatalogen. Aus dem Bestand der UB der LMU werden die VA-Daten außerdem in den Index des DFG-Projekts GeRDI übernommen und damit einer Nachnutzung in interdisziplinären Kontexten zugeführt.

s. auch Normdaten

(auct. Sonja Kümmet [UB der LMU] | Stephan Lücke | Julian Schulz [ITG] | Florian Zacherl)

Tags: Informationstechnologie



Georeferenzierung (Zitieren)

Ein wesentliches Ordnungskriterium der in VerbaAlpina verwalteten Daten ist die Georeferenzierung unter Verwendung von Breiten- und Längengraden. Die Genauigkeit dieser Referenzierung variiert je nach Datentyp, wobei grundsätzlich eine möglichst exakte, metergenaue Referenzierung angestrebt wird. Im Fall der Sprachdaten aus Atlanten und Wörterbüchern ist in aller Regel lediglich eine vergleichsweise ungefähre Referenzierung nach Maßgabe eines Ortsnamens möglich, im Fall von z. B. archäologischen Daten hingegen sind tatsächlich metergenaue Georeferenzierungen möglich. Es können Punkte, Linien (etwa Straßen, Flüsse u. Ä.) und Flächen gespeichert werden. Aus technischer Perspektive findet hauptsächlich das sogenannte WKT-Format (https://en.wikipedia.org/wiki/Well-known_text) Verwendung, das in der VA-Datenbank mit der Funktion geomfromtext() (https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html in ein spezifisches MySQL-Format überführt und so gespeichert wird. Die Ausgabe im WKT-Format erfolgt durch die MySQL-Funktion astext().
Referenzraster der Georeferenzierung ist das Netz der politischen Gemeinden im Alpenraum, die, je nach Bedarf, entweder als Fläche oder als Punkte ausgegeben werden können. Basis sind dabei die Grenzverläufe der Gemeinden mit Stand von etwa 2014, die VerbaAlpina von seinem Partner "Alpenkonvention" erhalten hat. Eine ständige Aktualisierung dieser Daten, die sich aufgrund nicht seltener Verwaltungsreformen durchaus häufiger verändern, ist entbehrlich, da es sich aus Sicht von VerbaAlpina lediglich um einen geographischen Referenzrahmen handelt. Die Punktdarstellung des Gemeinderasters wird algorithmisch aus den Gemeindegrenzen abgeleitet und ist somit sekundär. Die errechneten Gemeindepunkte stellen die geometrischen Mittelpunkte der Gemeindeflächen dar und markieren höchstens zufällig den Hauptort oder gar deren Mittelpunkt. Im Bedarfsfall können sämtliche Daten einzeln oder kumulierend auf den errechneten Gemeindepunkt projiziert werden. Dies ist etwa bei den Sprachdaten aus Atlanten und Wörterbüchern der Fall.
Zusätzlich zum exakt georeferenzierten Referenzraster der Gemeindegrenzen wird (ab Version 16/1) ein wabenförmiges quasi-georeferenziertes Raster dargestellt, das zwar die ungefähre Lage der Gemeinden zueinander wiedergibt, gleichzeitig jedoch jedem Gemeindegebiet eine idealisierte Fläche jeweils gleicher Form und Größe zuweist. [Bild:va_polygone-1.jpg]] Damit werden alternative Kartierungsverfahren angeboten, die beide ihre Vor- und Nachteile haben und wegen ihrer Bildlichkeit auch beide ein gewisses suggestives Potential mitbringen: Die topographische Darstellung vermittelt wegen ihrer Präzision einen besseren Einblick in die konkrete Räumlichkeit mit ihren oft sehr speziellen Geländeprofilen, einzelnen Übergängen, Talverläufen, unzugänglichen Talausgängen usw. Die Wabenkarte erlaubt dagegen eine abstrahiertere Visualisierung der Daten, da sie die Größen der Gemeindeflächen sowie siedlungsgeographische Ballungen bzw. Streuungen ausgleicht. Das ist besonders bei quantitativen Karten nützlich, denn die Größe der Fläche erzeugt schon bei der Wahrnehmung unwillkürlich den Eindruck quantitativen Gewichts. Die Ermittlung der Geoinformantionen zu den jeweiligen Erhebungspunkten erfolgte mittels eines Online Tools. Bedingt durch nicht eindeutige Benennung der Ortschaften, sowie nicht Erkenbarkeit der Namen, war eine manuelle Korrektur der Angaben nötig. Leider ist die Ermittlung der Geokoordianten seit einiger Zeitaus rechtlichen Gründen nicht mehr möglich.


(auct. Thomas Krefeld | Stephan Lücke)

Tags: Linguistik Informationstechnologie Außersprachlicher Kontext



Konzeptbeschreibung (Zitieren)

Die Konzepte werden in der Tabelle KONZEPTE der Datenbank am Beispiel des Deutschen wie folgt erfasst: Existiert eine lexikalisierte Bezeichnung für ein Konzept, so wird diese im Datenbankfeld 'Name_D' eingetragen. Bei fehlender Lexikalisierung bleibt dieses Feld leer. Unabhängig davon wird im Feld 'Beschreibung_D' das Konzept genauer spezifiziert bzw. definiert. Dies erfolgt nach einer festgelegten Vorgehensweise, die am Beispiel des Konzepts 'MILCHKANNE' (ID_Konzept 610) demonstriert wird: Das eben genannte Konzept wird mit einem spezifischen Lexem bezeichnet, daher wird MILCHKANNE in 'Name_D' eingetragen. Die Beschreibung sieht folgende hierarchische Reihenfolge vor: Gerät, Zweck, Material, Form (evtl.). Angewendet auf das Konzept ergibt sich also die Beschreibung: GEFÄSS, ZUM AUFBEWAHREN VON MILCH, AUS METALL. Falls möglich bzw. nötig sollen weiterhin diese zusätzlichen Regeln befolgt werden: Zahlen von 1-10 werden ausgeschrieben, zum Wiedergeben eines Prozesses, einer Handlung usw. kann entweder 'zu+Artikel+Infinitiv (substantiviertes Verb)' oder 'für+Substantiv' verwendet werden. Das Einhalten dieser Muster ermöglicht analoge Übersetzungen, die Bildung sprachunabhängiger Kategorien auf unterschiedlichen Abstraktionsebenen (-> GEFÄSSE -> GEFÄSSE ZUR AUFBEWAHRUNG -> GEFÄSSE AUS METALL usw.), automatisierte Korrekturen bzw. Änderungen und eine transparente Suche. Alle Konzepte werden auf diese Weise auf Deutsch, Italienisch, Französisch, Slowenisch und Rätoromanisch erfasst.

(auct. Giorgia Grimaldi | Thomas Krefeld)

Tags: Informationstechnologie



Langzeitarchivierung (Zitieren)

Sämtliche VerbaAlpina-Projektdaten werden so verwaltet, dass diese über einen möglichst langen Zeitraum les- und verwendbar bleiben. Die ins Auge gefasste Perspektive umfasst dabei wenigstens mehrere Jahrzehnte, das zugrundeliegende Konzept ist letztlich jedoch auf eine Konservierung ohne zeitliche Befristung ausgerichtet.

Im einzelnen werden die folgenden Aspekte berücksichtigt:
1. Welche Institution(en) wird(/werden) mit der Bewahrung der Daten bzw. der betreffenden Datenträger betraut?
2. Dokumentation der Datenstrukturierung sowie der logischen Zusammenhänge zwischen Daten und Datenkategorien (Entity Relationship)
3. Dokumentation der verwendeten Zeichenkodierung(en)

Mehrere Kopien der Projektdaten sollen bei mehreren verschiedenen Institutionen archiviert werden. Derzeit sind dafür die IT-Gruppe Geisteswissenschaften der Ludwig-Maximilians-Universität München (ITG) mit deren Anbindung an die Archivierungsserver des Leibniz-Rechenzentrums sowie das BAS Clarin Repository vorgesehen. Es ist geplant, zusätzliche Sicherungskopien bei weiteren geeigneten Institutionen zu deponieren. Die Archivierung findet im Rhythmus der Versionierungen statt. Archiviert werden jeweils die Datenbank mit sämtlichen Projektdaten (Modul VA_DB zusammen mit dem Entity-Relationship-Modell) sowie das Web-Framework (VA_WEB), das für die Präsentation der Daten im Internet (inklusive der jeweiligen Funktionalität) zuständig ist, so dass, zumindest theoretisch, ein "Wiedererwecken" jeder einzelnen Version in entsprechenden emulierten Betriebssystem- bzw. Softwareumgebungen möglich ist. Archiviert wird ferner die Medienbibliothek, die hauptsächlich Photos, Filme, Text- und Tondokumente enthält (Modul VA_MT).

In unregelmäßigen Abständen wird die VerbaAlpina-Webseite (VA_WEB) auch im Internetarchiv https://archive.org abgelegt. Unter der Adresse https://web.archive.org/web/*/http://verba-alpina.gwi.uni-muenchen.de/ lassen sich ältere Versionen von VA_WEB abrufen. Die älteste dort erfasste Version stammt vom 10. November 2014. Die Archivierungen erfolgen teils automatisch durch den "Wayback"-Crawler von archive.org, teils aktiv durch VerbaAlpina, seit 2018 regelmäßig im Zuge der halbjährlichen Versionswechsel.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Lizenzierung (Zitieren)

Die Anwendung des Copyright führt gerade im wissenschaftlichen Kontext häufig dazu, dass Inhalte, deren Präsentation für die Nachvollziehbarkeit darauf aufbauender Erkenntnisse eigentlich unverzichtbar ist, in wissenschaftlichen Publikationen nicht oder nur sehr eingeschränkt genutzt werden dürfen. Fast immer steht die Frage im Raum, welche Verwendung noch vom Zitatrecht gedeckt ist. Bisweilen ist auch unklar, ob ein Autor, dessen Werk verwendet werden soll, bereits mehr als 70 Jahre tot ist oder ob seine Rechte nach seinem Tod auf Dritte übergegangen sind. Jeder Autor (nicht nur) wissenschaftlicher Publikationen muss diese Regelung als massive Einschränkung empfinden, die letztlich und gerade in der Summe den Fortschritt der Wissenschaft erheblich behindert. Das Copyright muss daher als für den Wissenschaftsbetrieb ungeeignetes Lizenzmodell betrachtet werden.

VerbaAlpina fühlt sich daher verpflichtet, sämtliche von VerbaAlpina selbst erarbeiteten Inhalte in Übereinstimmung mit den sog. FAIR-Prinzipien und dem damit verbundenen Open Access Gedanken zur Nutzung durch Dritte frei zur Verfügung zu stellen, und steht damit in einer Reihe von Initiativen und Institutionen, die sich derzeit für die Verbreitung und Durchsetzung dieses Ideals einsetzen (vgl. z.B. das Open Science Center der LMU). Hinsichtlich der Inhalte von VerbaAlpina besteht eine Einschränkung nur insofern, als Daten, die VerbaAlpina von Seiten Dritter übernommen hat und die restriktiveren Nutzungsbedingungen wie etwa dem Copyright unterliegen, auch von VerbaAlpina nur unter den entsprechenden Bedingungen weitergegeben werden. So können speziell einzelne Mediendateien im VA-Modul VA_MT, die VA aus externen Datenquellen bekommen oder erworben hat, dem Copyright unterliegen. Betroffene Objekte werden im Modul VA_MT individuell mit entsprechenden Merkmalen versehen. VerbaAlpina ist stets bemüht, die für einzelne Inhalte bestehenden Nutzungsbedingungen jeweils anzugeben, sofern diese nicht im Rahmen einer Open-Access-Lizenz genutzt werden dürfen. Sollten VerbaAlpina in diesem Zusammenhang Irrtümer unterlaufen – und dies gilt besonders für Urheberrechtsverletzungen – wird darum gebeten, VerbaAlpina unverzüglich darauf hinzuweisen. Entsprechende Inhalte werden von VerbaAlpina umgehend entfernt.

Sämtliche aus rechtlicher Perspektive im Sinne von Open Access uneingeschränkt nutzbaren Daten und Inhalte werden von VerbaAlpina unter eine Creative-Commons-Lizenz (CC) gestellt, die lediglich die Nennung des Urhebers sowie die Weitergabe unter den selben Bedingungen verlangt. Dies wird in der Nomenklatur von CC durch die Kürzel "BY" und "SA" ("share alike") zum Ausdruck gebracht. VerbaAlpina verzichtet bewusst auf das Verbot der kommerziellen Nutzung (CC-Kürzel "NC" – "non-commercial"), da dies sogar eine Weiterverwendung zu wissenschaftlichen Zwecken unmöglich machen kann (s. dazu den Vortrag "Offene Lizenzen – ein Werkstattbericht zu den rechtlichen Herausforderungen im Jahr 2015 " [etwa ab Minute 13] von Thomas Hartmann). Insofern ist die NC-Klausel nicht kompatibel mit dem Open-Access-Gedanken (s. https://open-access.net/informationen-zu-open-access/rechtsfragen/lizenzen/, Abschnitt "Das Creative Commons-Modell", konsultiert am 09.10.2018).

Während die CC-Lizenzen der Version 3.0 auch an das deutsche Rechtssystem angepasst worden waren, wird seit der derzeit (2018) jüngsten Version 4.0 darauf verzichtet. Die daraus folgenden Konsequenzen sind für VerbaAlpina schwer einzuschätzen. Das von der Niedersächsischen Staats- und Universitätsbibliothek Göttingen betriebene Portal https://open-access.net/ meint dazu: "Derzeit noch unklar ist, wie es sich auswirkt, wenn die Standardlizenz in einer ausländischen Sprache zur Verfügung gestellt wird, die der Lizenznehmer nicht oder nicht sicher beherrscht" (https://open-access.net/informationen-zu-open-access/rechtsfragen/lizenzen/, konsultiert am 09.10.2018). VerbaAlpina folgt daher der Praxis der Universitätsbibliothek der LMU und stellt ab der VA-Version 18_2 (Dezember 2018) sämtliche Inhalte, die nicht unter die oben genannten Ausnahmen fallen, unter die CC-Lizenz BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/). Alle älteren Versionen stehen in analogem Sinn unter der CC-Lizenz BY-SA 3.0 de (http://creativecommons.org/licenses/by-sa/3.0/de/).
Für den von VerbaAlpina entwickelten Softwarecode findet die im Umfeld der Softwareentwicklung übliche MIT-Lizenz Anwendung, die die freie Nachnutzung des Softwarecodes erlaubt.

Das Lizenzierungssystem sowie die Zugriffsrechte der verschiedenen VA-Benutzergruppen werden durch die folgende Graphik dokumentiert:





(auct. Stephan Lücke)

Tags: Informationstechnologie Webseite



Module (Zitieren)

s. Versionierung

Tags: Informationstechnologie



Normdaten (Zitieren)

Der Begriff NORMDATEN hat seinen Ursprung im Bibliothekswesen. Bei der Katalogisierung von Publikationen ist es z.B. unverzichtbar, Autoren eindeutig identifizieren zu können, um Werke unabhängig von differierenden Schreibweisen oder Namensänderungen jeweils eindeutig dem jeweiligen Autor zuordnen zu können. Die gleiche Notwendigkeit ergibt sich auch bei der Verschlagwortung der erfassten Literatur, etwa um geographische Begriffe, die Gegenstand von verschiedenen Abhandlungen sind, ebenfalls eindeutig identifizieren und diese dann auch aufeinander beziehen zu können. Diese Notwendigkeiten führten zur Anlage entsprechender onomasiologischer Listen, die zunächst individuell von den einzelnen Bibliotheken geführt wurden.

Die Möglichkeiten der technischen Vernetzung von Datenbeständen, deren Anfänge in die 1970er Jahre zurückreichen, erforderten alsbald eine Angleichung der bis dato von den einzelnen Bibliotheken individuell geführten Verzeichnisse. Aus diesem Grund haben die Bibliotheken spätestens in den 1980er Jahren – erste Planungen erfolgten bereits Ende der 1970er Jahre – damit begonnen, die individuellen Verzeichnisse einander anzugleichen und gemeinsame Personen- und Schlagwortverzeichnisse anzulegen, um bibliotheksübergreifende Konsistenz zu erreichen. Im Lauf der Zeit entstanden zunächst thematisch getrennte Verzeichnisse: Ein Personenverzeichnis (Personennamendatei, PND), ein Verzeichnis von Körperschaften (Körperschaftsdatei, GKD) sowie ein Schlagwortverzeichnis (Schlagwortnormdatei, SWD). Schließlich setzte sich die Erkenntnis durch, dass die entstandene thematische Trennung nicht zweckmäßig ist, zumal Personen und Körperschaften nicht nur als Autoren bzw. Herausgeber figurieren können, sondern ihrerseits auch Gegenstand von Publikationen sein können, weswegen sie auch bei Verschlagwortungen auf Basis der Schlagwortnormdatei entsprechend berücksichtigt werden müssen. Aus diesem Grund wurden die drei getrennten Normdateien von 2009 bis 2012 in einer gemeinsamen Unternehmung der Deutschen Nationalbibliothek und der deutschsprachigen Bibliotheksverbünde zur sog. Gemeinsamen Normdatei (GND) vereinigt. Diese steht nunmehr seit 2012, zwischenzeitlich in einer ganzen Reihe von Formaten (MARC 21 Authority, MARC21-xml und RDFxml), der Öffentlichkeit zur Verfügung und wird zunehmend auch für Verschlagwortungen außerhalb des Bibliothekswesens genutzt. So werden Normdaten u.a. in den an der ITG beheimateten DH-Projekten BMLO (Bayerisches Musiker-Lexikon online) und Kaiserhof registriert und zur zweifelsfreien Identifizierung von Personen verwendet.

Unter der Adresse http://ognd.bsz-bw.de/ (ein Dienst des Bibliotheksservice-Zentrums Baden-Württemberg) steht ein komfortables Suchinstrument zur Recherche in der GND zur Verfügung. Mit der GND vergleichbare Normdateien werden von Institutionen, vorrangig Bibliotheken, weltweit geführt. Seit 2003 existiert das von der DNB und Library of Congress gemeinsam ins Leben gerufene Projekt VIAF (Virtual International Authority File), das sich zum Ziel gesetzt hat, diese Datenbestände in einem System zu vereinen und dort abrufbar zu machen.

Auch wenn das System der Normdaten rein theoretisch die eindeutige Identifizierung von Personen und Konzepten erlaubt, hängt die konkrete Nutzbarkeit von der technischen Implementierung in den elektronischen Bibliothekskatalogen ab. In den Katalogen der DNB und der Bayerischen Staatsbibliothek (BSB) liefert die Suche nach "Homère" auch Treffer, deren bibliographische Erfassung nur die deutsche Schreibweise "Homer" enthält. Andererseits listet im Online-Katalog der BSB ein Klick auf einen mit einem Link unterlegten Autorennamen derzeit (Nov. 2018) noch Titel, die nicht nur von dem entsprechenden Individuum, sondern auch von gleichnamigen Autoren stammen.

Auch wenn der Ursprung des Konzepts der Normdaten offenbar im Umfeld des Bibliothekswesens liegt, hat sich die Verwendung von Normdaten mittlerweile auch in anderen Bereichen etabliert. Als Beispiel können die Projekte Geonames (Entität Geographica), Pleiades (Entität antike Geographica) oder auch Glottolog (Entität Weltsprachen) genannt werden.

Normdaten besitzen große Bedeutung für die u.a. von der FAIR-Initiative geforderte Interoperabilität. Durch die Definition eines Normdatums und die Vergabe eines (alpha)numerischen Identifikators besteht, neben der Einbindung in die inhaltliche Erschließung der Bibliothekskataloge, auch die Möglichkeit der logischen und technischen Verknüpfung von kongruenten Daten in von einander getrennten Datenbeständen.

Aus der Perspektive von VerbaAlpina wäre die Etablierung der Normdatenkategorien "morpholexikalischer Typ" (⇒ Typisierung) und "Konzept" methodologisch konsequent und deshalb sehr wünschenswert. Dies würde erlauben, morpholexikalische Typen und Konzepte mit Identifikatoren zu versehen. Auf diese Weise könnten lexikalische Daten weltweit und, im Falle der Konzepte, unabhängig von der Einzelsprache eindeutig aufeinander bezogen werden. Vereinzelt lassen sich Ansätze in diese Richtung beobachten. So werden beispielsweise in den strukturierten Datenbeständen des Wikidata-Projekts sog. Q-IDs vergeben, die außersprachliche Konzepte eindeutig identifizieren und auf diese Weise eine gemeinsame und identische Referenz für die verschiedenen Artikel in den unterschiedlichen Sprachversionen der Wikipedia zu ein und demselben Thema liefern. Das Konzept ALMHÜTTE ist in Wikidata z.B. mit der Q-ID Q2649726 eindeutig identifiziert. Der entsprechende Eintrag in Wikidata verweist auf zugeordnete Wikipedia-Artikel in derzeit (Oktober 2018) insgesamt sieben verschiedenen Sprachen. Von den aktuell (Oktober 2018) insgesamt 2629 von VerbaAlpina erfassten Konzepten konnten bislang genau 400 eine QID zugeordnet werden. Die Q-IDs werden, soweit vorhanden, im Datenbestand von VerbaAlpina registriert. Eine analoge, systematische Identifizierung morpholexikalischer Typen besteht im Rahmen des Wikipedia- bzw. Wikidata-Projekts bislang anscheinend noch nicht. Erst ansatzweise wurden dort bislang L-IDs für sprachliche Bezeichnungen vergeben; ob damit jedoch präzis definierte Typen gemeint sind, wird nicht klar.

Orientiert am Modell der Normdaten-IDs vergibt VerbaAlpina für die Datenkategorien (Entitäten) "Konzept", "morpholexikalischer Typ" (s. Typisierung) und "Gemeinde" eigene Identifikatoren, die per einfachem Mapping auf andere bereits etablierte Normdatensysteme wie etwa die Q-IDs des Wikidata-Projekts bezogen werden können. VerbaAlpina ist überdies bestrebt, speziell die Datenkategorie "morpholexikalischer Typ" in die Systematik der Gemeinsamen Normdatei (GND) einzubringen. Die entsprechende Perspektive besteht, zumal die GND inhaltlich und strukturell erweitert und an die Bedürfnisse der Wissenschaft sowie allgemein kulturtragenden Einrichtungen und Personen angepasst werden soll. Einem entsprechenden Austausch soll die für Dezember 2018 angesetzte Konferenz GNDCon 2018 dienen. Die Interessen von VerbaAlpina werden dort von Mitgliedern der UB München sowie der ITG vertreten werden.

Die GND unterscheidet derzeit die folgenden Entitäten: Körperschaft (Sigle: b), Konferenz (f), Geographikum (g), Person (nicht individualisiert) (n), Person (individualisiert) (p), Sachbegriff (s) sowie Werk (u) (http://www.dnb.de/SharedDocs/Downloads/DE/DNB/standardisierung/inhaltserschliessung/entitaetenSatztypen.pdf?__blob=publicationFile). Einem DNB-Dokument aus der Kategorie "Arbeitshilfen zur gemeinsamen Normdatei (GND)" ist ferner zu entnehmen, dass für die Kategorie "Buchstaben, Morpheme, Wörter als Gegenstand linguistischer Untersuchungen" der spezifische Entitätencode "slz" als Unterkategorie der Entität "Sachbegriff" vorgesehen ist. Es liegt nahe, die Normdaten von VerbaAlpina mit dieser Kategorie zu verknüpfen.

Literatur:
Capellaro 2003

(auct. Stephan Lücke)

Tags: Informationstechnologie



Quantifizierende Darstellungen (Zitieren)

[Vorbemerkung: Der nachfolgende Artikel nimmt in Teilen Bezug auf derzeit noch in Entwicklung befindliche Funktionalitäten von VA_WEB, die für die Öffentlichkeit derzeit noch nicht zugänglich sind.]

Die interaktive Online-Karte von VerbaAlpina erlaubt neben der qualitativen Kartierung auch die Visualisierung aggregierter Daten im Sinne einer quantifizierenden Abbildung der Daten im Raum. Die Aggregierung orientiert sich dabei stets an geographischen Regionen. Der Nutzer hat dabei die Auswahl zwischen Aggregierung auf Basis der Gemeindeflächen (Kleinraum), der sog. NUTS-3-Regionen (Mittelraum) und schließlich der Verbreitungsregionen der drei großen Sprachfamilien Germanisch-Romanisch-Slavisch (Großraum). Darüber hinaus besteht die Möglichkeit, beliebige Gemeindeflächen als individuelle Regionen zu definieren, die dann wiederum als Bezugsgröße der Aggregierung fungieren. Letztere Option kann verzerrenden Effekten entgegenwirken, die sich in der Perspektive der Aggregierung über die administrativ – und somit aus Sicht der Sprachwissenschaft sachfremd – motivierten Flächen der Gemeindegebiete oder der NUTS-3-Regionen ergeben. Im Einzelfall kann die entsprechende Vorgehensweise natürlich nur heuristisch sein, der Nutzer hat aber die Möglichkeit, einmal entdeckte sinnvolle regionale Kohärenzen abzuspeichern, zu kommentieren, wiederzuverwenden und der Allgemeinheit zur Verfügung zu stellen.

Bezogen auf die gewählten Regionen bzw. Flächen werden sodann sämtliche bis zur Aktivierung der quantifizierenden Darstellung ausgewählten qualitativen Daten aggregiert. Größe und Farbgebung der einzelnen Kartensymbole korrelieren dabei mit der Anzahl der jeweils in einem Symbol gebündelten qualitativen Einzeldaten. Der arithmetisch zugrunde gelegte Maximalwert, bei dessen Erreichen ein Symbol stets die jeweils maximale Größe und Farbgebung erhält, entspricht dabei standardmäßig der höchsten Anzahl an aggregierten Daten, der in einer der ausgewählten Flächen bzw. Regionen auftritt. Wahlweise kann dieser maximale Referenzwert auf die Gesamtanzahl der aggregierten Einzeldaten umgesetzt werden, was zu einer Änderung der Kartendarstellung führt.

Bei aktivierter Quantifizierung können durch Deaktivierung einzelner Listeneinträge in der Kartenlegende die entsprechenden qualitativen Daten aus der Berechnung der Quantitäten herausgenommen oder andere durch zusätzliche Auswahl hinzugenommen werden.

Neben der Quantifizierung vor dem Hintergrund einer georeferenzierten, die realen Grenzverläufe abbildenden Karte erlaubt VerbaAlpina auch die Darstellung quantifizierter Daten auf einer sog. Wabenkarte. Gestalterisches Vorbild ist eine Wikipedia-Grafik, die die Wahlergebnisse der britischen Unterhauswahl von 2015 visualisiert. Im folgenden ist zunächst die punkt-, längen- und winkeltreue Karte (im folgenden als "geographische Karte" bezeichnet) mit den Wahlergebnissen in den einzelnen Wahlkreisen wiedergegeben. Daran anschließend ist die Wabenkarte abgebildet, auf der jeder Wahlkreis durch ein Sechseck jeweils identischer Größe dargestellt ist.




Quelle: https://upload.wikimedia.org/wikipedia/commons/3/3e/2015UKElectionMap.svg (abgerufen am 03.11.2016)




Quelle: https://upload.wikimedia.org/wikipedia/commons/c/cd/2015_UK_general_election_constituency_map.svg (abgerufen am 03.11.2016)

Die Gegenüberstellung der beiden Kartentypen zeigt die jeweiligen Vor- und Nachteile. Die Wabenkarte weist geographische Ungenauigkeiten bzw. diesbezüglich sogar Fehlinformationen auf. So erkennt man z.B. im Distrikt Greater London eine isolierte rote Wabe, die von lauter blauen Waben umgeben ist – ein scheinbares Faktum, das jedoch keinen Rückhalt in der geographischen Karte findet. Auf der anderen Seite besitzt die Wabenkarte den Vorteil, die realen Zahlenverhältnisse zwischen den einzelnen Farben besser zu visualisieren, da eine Vielzahl von flächenmäßig sehr kleinen Wahlbezirken auf der geographischen Karte vom Betrachter als nachrangig wahrgenommen werden, obwohl die politische Bedeutung mit der der flächenmäßig großen Wahlbezirke gleichgestellt ist. Somit ergänzen sich die beiden Kartentypen und der eigentliche Mehrwert besteht in der Möglichkeit, beide Karten konsultieren und deren Visualisierung gegenüberstellen zu können.

Die Wabenkarte von VerbaAlpina zeichnet sich dadurch aus, dass sämtliche politischen Gemeinden im Alpenraum durch jeweils gleich große Hexagone abgebildet werden. Dabei wird versucht, die geographische Logik wenigstens ungefähr zu bewahren. Die Berechnung der Farbgebung der einzelnen Hexagone erfolgt dort in der gleichen Weise wie oben bei der Punktsymbolkarte beschrieben. Der Vorteil einer solchen Wabenkarte besteht gegenüber einer simplen Einfärbung der Gemeindeflächen auf einer georeferenzierten Karte darin, dass suggestive Effekte durch stark unterschiedliche Größe der Gemeindeflächen unterdrückt werden.

(auct. Stephan Lücke)

Tags: Informationstechnologie Webseite



Technologie (Zitieren)

VerbaAlpina verwendet soweit möglich online-Technologie. Herzstück ist eine Wordpress-Installation (Modul VA_WEB), an die mehrere MySQL-Datenbanken (Modul VA_DB) angebunden sind. Bei Wordpress handelt es sich um ein kostenfrei verfügbares, quelloffenes (open source) und individuell erweiterbares PHP-Framework, dessen Funktionalitäten durch den Einsatz von Javascript-Bibliotheken ergänzt werden. Letzteres trifft vor allem auf die interaktive online-Karte zu, die sich in den ersten Versionen von VerbaAlpina der einschlägigen Javascript-Bibliothek von Google Maps bediente. Voraussichtlich mit der VA-Version 19_1 erfolgt die Umstellung auf das quelloffene Javascript-Framework "Leaflet", die mit der Implementierung eines hochperformanten WebGL-Layers zur Visualisierung großer Datenmengen einhergeht.

Soweit möglich und sinnvoll, werden sämtliche von VerbaAlpina entwickelten Wordpress-Funktionalitäten als sog. Plugins realisiert, die anschließend auf der weithin bekannten und innerhalb der Entwickler-Community fest etablierten Plattform "Github" abgelegt werden (https://github.com/VerbaAlpina/). Sie können von dort uneingeschränkt heruntergeladen und nachgenutzt werden. Die Verwendung der Plugins wird im Rahmen der im Bereich der Softwareentwicklung weit verbreiteten MIT- Lizenz gestattet. Die auf Github angezeigte Unterscheidung zwischen PHP- und Javascript-Plugins ist artifiziell und wurde vom Github-System automatisch eingetragen. Die meisten der von VerbaAlpina entwickelten Plugins enthalten grundsätzlich neben PHP-Code immer auch gewisse Anteile an Javascript-Code. Derzeit (November 2018) stehen auf der Github-Seite von VerbaAlpina die Plugins "TranscriptionTool-Plugin", "Interactive-Map_Plugin", "Verba-Alpina-Plugin" zur Verfügung. Zusätzlich kann von dort auch das "Verba-Alpina-Theme" heruntergeladen werden, das hauptsächlich für das Design des Frontends verantwortlich ist. Es ist vorgesehen, noch weitere von VerbaAlpina entwickelte Funktionserweiterungen in Form von Plugins auf Github zum Download anzubieten.

Liste der wichtigsten bislang von VerbaAlpina entwickelten Funktionserweiterungen:

  • Interaktive Online-Karte (vielschichtige Visualisierung von Datenanalysen)
  • Transkriptionstool (für die Transkription hauptsächlich von Sprachatlanten)
  • Typisierungstool (Kategorisierung von erfasstem Sprachmaterial und Zuweisung zu Typen)
  • Konzeptbaum (Verwaltung der hierarchischen Struktur der außersprachlichen Konzeptwelt)
  • CS-Tool ("Crowdsourcing"-Tool; Erhebung von Sprachmaterial über das Internet zur Abrundung und Ergänzung des Datenmaterials)
  • SQLtoHTML (direkte Einbindung der Ergebnisse von SQL-Abfragen in Wordpressbeiträge)

Neben diesen komplexen Tools, die sehr wahrscheinlich auch für Anwender jenseits von VerbaAlpina von Nutzen sein können, erfolgte die Entwicklung von zahlreichen Funktionalitäten im Detail, deren Umformung in modular verwendbare Plugins nicht sinnvoll erscheint, da sie entweder zu geringfügig oder zu spezifisch zugeschnitten auf die Erfordernisse von VerbaAlpina erscheinen. Zugänglich ist jedoch auch diese Kategorie von Entwicklungen, zumal neben den erwähnten Plugins auch der komplette Softwarecode von VerbaAlpina auf Github abgelegt wird.

Das an die Wordpress-Umgebung angebundene Backend besteht, wie gesagt, aus mehreren MySQL-Datenbanken. Die Datenbank va_wp basiert auf dem Standard-Modell einer MySQL-Datenbank, wie sie üblicherweise als Backend von Wordpress-Installationen Verwendung finden. Über diese Datenbank werden hauptsächlich die "generischen" Funktionalitäten einer Wordpress-Installation wie z.B. die Benutzerverwaltung abgewickelt. Der zentrale fachwissenschaftliche Datenbestand von VerbaAlpina wie etwa Transkriptionen (Tabelle `tokens`), Typisierungen im weitesten Sinn (`morph_typen`, `basistypen`, `etyma`, `lemmata`), Konzepte (`konzepte`), Methodologie-Einträge (`glossar`), Beiträge des Lexikon alpinum (`im_comments`) oder auch die Bibliographie (`bibliographie`) befindet sich in der Datenbank va_xxx. Das Suffix "xxx" bezeichnet dabei die jeweilige Arbeitsversion von VerbaAlpina, deren Datenbestand durch den laufenden Betrieb ständigen Änderungen unterliegt. Bei der Erzeugung einer VerbaAlpina-Version wird jeweils eine dann stabile Kopie dieser Datenbank erzeugt, deren Name die entsprechende Versions-Nummer als Suffix erhält (z.B. va_181). Außerdem existiert für eine Reihe von Kooperationspartnern von VerbaAlpina jeweils eine MySQL-Datenbank. Die Namen dieser Datenbanken weisen jeweils das Praefix "pva_" (= "Partner von VerbaAlpina") auf, es folgt das Kürzel des Partnerprojekts (z.B. pva_ald-i).

Die von VerbaAlpina in der Mediathek (Modul VA_MT) der Wordpressinstallation gesammelten Mediendateien (Bilder, Videos, Tonaufnahmen) werden, wie bei Wordpress-Installationen üblich, im Filesystem des Webservers gespeichert.

Alle technologischen Instanzen von VerbaAlpina, also die Wordpress-Installation wie auch die Datenbanken, nutzen die IT-Infrastruktur der IT-Gruppe Geisteswissenschaften der LMU. Diese Institution betreibt ein professionelles IT-Management mit hochverfügbaren Web- und Datenbankservern und greift dabei auch auf Dienste des Leibniz-Rechenzentrums der Bayerischen Akademie der Wissenschaften zurück. Der Bestand der ITG ist mit derzeit insgesamt sieben unbefristeten Personalstellen langfristig gesichert. Ein Teil des Personals widmet sich ausschließlich dem Betrieb sowie der Wartung und Pflege von Server-Hard- und -Software.

Sämtliche Softwareentwicklungen wurden von den Informatikern David Englmeier (wiss. Mitarbeiter; seit Oktober 2016), Filip Hristov (Hilfskraft; seit September 2016) und Florian Zacherl (wiss. Mitarbeiter; seit Oktober 2014) geleistet.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Terminologie (Zitieren)

Vielfach wird eine Unterscheidung zwischen Rohdaten, Primär- und Metadaten vorgenommen. Eine verbindliche Definition dieser Kategorien existiert bislang nicht.

Rohdaten: Daten nach Übernahme aus "Quelle" (z.B. von Partnern, über OCR aus Lexika, via Transkription ...)

VA orientiert sich am Modell von Stuart Card (infovis-reference-model; reference-model for vizualization).

Dementsprechend wird unterschieden zwischen Roh- und Primärdaten. Rohdaten sind alle Daten in der Gestalt, die vorliegt, bevor die Daten elektronisch in die VA-Struktur übertragen wurden. Dies gilt auch für den Fall, dass zu übernehmende Daten bereits in der VA-Struktur vorliegen, da auch in diesem Fall menschliche Interaktion zur Datenübernahme erforderlich ist (etwa um festzustellen, *dass* die Struktur identisch ist).

Als Primärdaten werden definiert: Sämtliche Daten, die über die API mit dem Parameter "getRecord" (Beispiel: https://www.verba-alpina.gwi.uni-muenchen.de/?api=1&action=getRecord&id=C1&version=182&format=xml&empty=0) abgerufen werden (noch nicht vollständig implementiert) können. Dabei wird unterschieden zwischen Kern-Primärdaten (=sprachliche Daten) und peripheren Primärdaten (sprachliche Peripherie wie z.B. archäologische Daten).

Unter Metadaten werden all die Daten verstanden, die die Primärdaten beschreiben (z.B. administrative Daten zur Beschreibung des Gesamtprojekts, alle erläuternden Texte, z.B. in der Methodologie [die unterschiedliche Aspekte des Gesamtprojekts beleuchtet] oder dem Lexikon Alpinum).

Sekundärdaten sind all die Daten, die der Verarbeitung all der anderen Daten dienen (Code, Queries etc. ...)

(auct. David Englmeier | Filip Hristov | Thomas Krefeld | Stephan Lücke | Christina Mutter | Florian Zacherl)

Tags: Informationstechnologie



Transkription (Zitieren)

Die sprachlichen Materialien werden graphisch in doppelter Weise wiedergegeben, um den beiden gegenläufigen Prinzipien der Quellentreue und der leichten Vergleichbarkeit gerecht zu werden:
(1) Inputversion in der Originaltranskription
Im VA-Portal werden Quellen zusammengeführt, die aus unterschiedlichen Fachtraditionen stammen (Romanistik, Germanistik, Slavistik) und die historisch unterschiedliche Phasen der dialektologischen Forschung repräsentieren; manche Wörterbuchdaten wurden zu Beginn des letzten Jahrhunderts (GPSR) und andere erst vor wenigen Jahren (ALD) erhoben. Deshalb ist es wissenschaftsgeschichtlich notwendig, die Originaltranskription weitestgehend zu respektieren. Aus technischen Gründen ist es allerdings unmöglich, bestimmte Konventionen unverändert zu erhalten; das gilt insbesondere für die vertikale Kombination von Basiszeichen (‘Buchstaben’) und diakritischen Zeichen, also etwa dann, wenn ein Betonungsakzent über einem Längenzeichen über einem Vokal über einem Schließungszeichen positioniert ist (Betacode). Diese Konventionen werden in jeweils definierten technischen Transkriptionen in lineare Folgen von Zeichen überführt, wobei ausschließlich ASCII-Zeichen benutzt werden (so genannter Betacode). Bis zu einem gewissen Grad können bei der Beta-Kodierung intuitiv verständliche graphische Ähnlichkeiten zwischen den Originaldiakritika und den ASCII-Entsprechungen ausgenützt werden; sie sind mnemotechnisch günstig.

(2) Outputversion in IPA
Im Sinne der Vergleichbarkeit und auch der Nutzerfreundlichkeit ist zudem die Ausgabe in einer einheitlichen Transkription wünschenswert. Alle Beta-Codes werden daher mit spezifischen Ersetzungsroutinen in IPA-Zeichen überführt. Einige wenige, aber unvermeidbare Unverträglichkeiten ergeben sich vor allem dann, wenn einem, durch Diakritika spezifizierten Basiszeichen in der Inputtranskription in IPA zwei unterschiedliche Basiszeichen entsprechen. Das gilt vor allem im Hinblick auf die Öffnungsgrade der Vokale, wo z. B. in der palatalen Reihe die beiden Basiszeichen <i> und <e> in Verbindung mit Schließungspunkt und einem oder zwei Öffnungshäkchen es erlauben, sechs Öffnungsgrade abzubilden; in Beta-Kodierung sind das: i – i( – i((– e?-- e – e(– e((. Dafür stehen in IPA nur vier Basiszeichen i – ɪ – e – ɛ zur Verfügung.


(auct. Thomas Krefeld)

Tags: Linguistik Informationstechnologie



Uniform Resource Name (URN) (Zitieren)

s. Digital Object Identifier

Tags: Informationstechnologie



Versionierung (Zitieren)

VerbaAlpina besteht aus folgenden Modulen:





- VA_DB: Datenbestand in der (MySQL-)Projekt-Datenbank (va_xxx)
- VA_WEB: Programmcode der Webschnittstelle des Projektportals www.verba-alpina.gwi.uni-muenchen.de samt zugehöriger Wordpress-Datenbank (va_wp)
- VA_MT: Mediendateien (Photos, Filme, Text- und Tondokumente), die sich in der Medienbibliothek der Webschnittstelle befinden

Alle drei Module bilden ein konsistentes Ganzes mit wechselseitigen Verknüpfungen und Abhängigkeiten und können daher nicht voneinander getrennt werden. Während der Projektlaufzeit wird halbjährlich, jeweils zum 15. Juni und zum 15. Dezember eines Jahres, simultan der jeweils aktuelle Status der Module VA_DB und VA_WEB in Gestalt einer elektronischen Kopie gleichsam "eingefroren". Diese eingefrorenen Kopien erhalten Versionsnummern nach dem Schema [Kalenderjahr]/[laufende Nummer] (z .B. 15/1). Die jeweils produktive VA-Version erhält die Bezeichnung XXX (vgl. Zitierweise).

Die Erzeugung von Kopien der VA-Mediathek (VA_MT) verbietet sich aufgrund der üblicherweise enormen Größe von Mediendateien. Aus diesem Grund wird von diesem Modul im Zuge eines Versionierungsvorgangs keine Kopie erzeugt. Einmal dort abgelegte Elemente können daher, sofern auch nur eine einzige VA-Version mit ihnen verknüpft ist, nicht aus der VA-Mediathek entfernt werden.

Im Projektportal besteht die Möglichkeit, zwischen der jeweils "produktiven" und daher ständigen Änderungen unterworfenen VA-Version sowie den archivierten, "eingefrorenen" Versionen zu wechseln. Im Projektportal wird durch geeignete Farbgebung des Hintergrunds bzw. bestimmter Bedienelemente angezeigt, ob man sich in der produktiven oder einer archivierten Version von VA befindet. Zitierfähig sind *ausschließlich* die archivierten Versionen von VA.

Titelbilder älterer VerbaAlpina-Versionen:

15/1

15/2

16/1

16/2

17/1

17/2

18/1



(auct. Stephan Lücke)

Tags: Informationstechnologie