Methodologie

Bislang existiert für die in der Methodologie publizierten Beiträge noch keine Volltextsuche. Eine solche befindet sich in Planung und Entwicklung und wird in einer der nächsten VerbaAlpina-Versionen zur Verfügung stehen. Bis dahin kann behelfsmäßig, nach Aufruf von "Alle Einträge anzeigen", die Volltextsuche der Browser (meist Strg+F) verwendet werden.
Sortierung

Alle Einträge anzeigen

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


Aktualisierung der Daten für die Visualisierung

Um den durchgehenden Betrieb der interaktiven Karte möglichst zu gewährleisten, werden die Tabellen der Datenzugriffsschicht und die zugehörigen Hilfstabellen nur einmal täglich aktualisiert. Somit werden Änderungen in den sprachlichen Kerndaten bzw. den Daten der sprachbezogenen Peripherie im Normalfall erst am nächsten Tag auf der Karte sichtbar. Für eine sofortige Aktualisierung können die entsprechenden Prozeduren direkt in der Datenbank über SQL-Statements aufgerufen werden:

Sprachliche Kerndaten:
CALL zling();

Daten der sprachbezogenen Peripherie:
CALL zgeo();

(auct. Florian Zacherl)

Tags: Informationstechnologie



API

API steht für "application programming interface", zu Deutsch ‚Anwendungsprogrammierschnittstelle'. Eine solche stellt VerbaAlpina unter der Adresse https://www.verba-alpina.gwi.uni-muenchen.de/?api=1 zur Verfügung. Eine ausführliche Dokumentation der dort zu verwendenden Syntax findet sich in folgendem Beitrag: API Dokumentation. Die API erlaubt es, gezielt bestimmte Inhalte aus der VA-Datenbank (VA_DB) in definierten Formaten über einen Browser abzurufen. Die Auswahl der Daten und das Ausgabeformat werden dabei durch URL-Parameter gesteuert.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Betacode

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 der Punkt unterhalb des e im Wort tega durch ein Fragezeichen wiedergegeben: te? . 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

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



Datenbank-Dokumentation

Bei der zentralen Projekt-Datenbank von VA (= VA-Modul VA_DB) handelt es sich um eine relationale Datenbank, die mit dem Datenbankmanagementsystem (DBMS) MySQL verwaltet wird. Rein physisch ist diese Datenbank, die den regelmäßigen Versionierungen unterliegt, eine von einer Vielzahl weiterer Projektdatenbanken, die auf dem MySQL-Cluster der IT-Gruppe Geisteswissenschaften (ITG) der LMU liegen. Dieses System ist hochverfügbar und redundant ausgelegt; es werden regelmäßige Backups der Datenbanken auf diesem Cluster angelegt und auf die Fileserver des Leibniz-Rechenzentrums (LRZ) übertragen.

Die VA-MySQL-Datenbank ist sehr komplex. Sie besteht derzeit (Mai 2020) aus 156 Tabellen mit insgesamt 1,6 GB Daten. Eine detaillierte Beschreibung des Inhalts und der Funktion jeder einzelner dieser Tabellen ist im VA-Modul VA_WEB abgelegt (Link). Für weitere Details sei auf den Eintrag Technologie verwiesen.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Datenformat

s. Datenmodellierung.

Tags: Informationstechnologie



Datenmodellierung

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



Datenstrukturierung

s. Datenmodellierung.

Tags: Informationstechnologie



Datenzugriffsschicht

Der Zugriff auf das Modul VA_DB erlaubt, unmittelbar in den primären Projektdaten zu recherchieren. Dieser Zugriff kann entweder durch den Menschen (über das Modul VA_WEB) oder durch Maschinen bzw. Programme erfolgen. Letzteres Szenario besteht z. B. auch projektintern bei der Kommunikation zwischen den Modulen VA_WEB und VA_DB, betrifft aber auch automatische Zugriffe z. B. von Rechnern bzw. Programmen der VA-Projektpartner. Im Laufe der Entwicklungsarbeiten im Bereich der Module VA_WEB und VA_DB ist es aus informatischer bzw. programmiertechnischer Sicht nicht selten erforderlich, bestehende Datenstrukturen zu verändern und an neue Erfordernisse anzupassen. Dies kann im Fall des Zugriffs durch einen Menschen zu Verwirrung führen, im Fall des Zugriffs durch eine Maschine bzw. ein Programm führt es schlicht zu einer Fehlfunktion. Um diesem Problem zu begegnen, wird innerhalb von VA_DB eine – zumindest weitgehend – stabile Datenstruktur zwischengeschaltet; in diese sog. Datenzugriffsschicht werden die veränderlichen primären Datenstrukturen hineinprojiziert . In der zentralen MySQL-Projektdatenbank (VA_DB) sind die jeweiligen Schnittstellen in Form mehrerer Tabellen realisiert. Für den Zugriff durch Maschinen sind die Tabellen z_ling (für die Sprachdaten) und z_geo (für geographische Daten) optimiert. Die für den Zugriff durch Menschen konzipierten Schnittstellen vap_ling und vap_geo liegen als Datenbanktabellen in mehreren Sprachversionen vor und sind durch entsprechende Namenssuffixe kenntlich gemacht. Derzeit (Oktober 2020) existieren die folgenden vap-Tabellen: vap_ling_de, vap_ling_it, vap_ling_fr, vap_ling_si; vap_geo_de, vap_geo_fr. Eine detaillierte Dokumentation der in diesen Schnittstellen gespeicherten Daten ist unter Datenbank-Dokumentation zu finden.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Digital Humanities

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

Die Verwendung der sog. Digital Object Identifier (DOI) suggeriert die Existenz von "Digitalen Objekten". Bei der Entwicklung des Konzepts des DOI scheint jedoch im Wesentlichen eine von der technischen Dimension dominierte Vorstellung gewirkt zu haben. Bei dem DOI geht es hauptsächlich darum, eine im Internet existierende und mit einer URL versehene Ressource auch dann noch finden und ansprechen zu können, wenn sich die Domain der URL geändert hat. Eine präzise oder gar verbindliche Definition dessen, was ein Digital Object sei, ist damit jedoch nicht verbunden. Entsprechend sind die über URLs und DOIs erreichbaren Ressourcen hinsichtlich ihres Inhalts äußerst heterogen. Gemeinsam ist allen entsprechenden Instanzen lediglich, dass es sich jeweils um statische oder ad hoc erzeugte, aus technischer Sicht in sich konsistente und daher zweifelsfrei interpretierbare Daten oder Dateien handelt, die über Browser aufgerufen, dargestellt und/oder heruntergeladen werden können.

Für die Erzeugung echter Interoperabilität ist es jedoch unerlässlich, die technische Dimension des Konzepts DIGITAL OBJECT um eine inhaltliche zu ergänzen. Diese inhaltliche Dimension muss überdies einem verbindlichen strukturierenden System unterliegen, das in etwa vergleichbar wäre mit den kontrollierten Vokabularen, wie sie z.B. von den Bibliotheken zur inhaltlichen Erschließung von analogen und digitalen Beständen eingesetzt werden. Konkret wäre klar zu umreißen, welche Entitäten den Status eines Digital Object erhalten können, wie die logische innere Struktur dieser Objekte auszusehen hat und welches Benennungsschema angewendet werden soll. Wesentliche Voraussetzung für den nutzbringenden Einsatz eines entsprechenden Konzepts wäre sicherlich eine möglichst feine Granulierung von Datenbeständen. Erst dann ist eine effektive Vernetzung im Sinne echter Interoperabilität gewährleistet, wodurch sich die entsprechenden Maßnahmen als eine tragende Säule bei der Umsetzung der FAIR-Kriterien erweisen.

Die Entwicklung und Durchsetzung eines entsprechenden Systems bzw. darauf aufbauender Verfahren kann nicht von Einzelprojekten geleistet werden. Vielmehr sind hier wissenschaftspolitische Weichenstellungen unerlässlich, die z.B. der Rat für Informationsinfrastrukturen (RfII) vornehmen könnte. Auch die derzeit (2020) entstehenden NFDI-Konsortien könnten auf die Entwicklung und Etablierung entsprechender Konventionen hinwirken.

VerbaAlpina definiert versuchsweise die im Projekt gesammelten morpholexikalischen Typen und Konzepte zusammen mit den jeweils verbundenen Metadaten als digitale Objekte. Zu diesem Zweck werden die entsprechenden Daten typ- bzw. konzeptweise in einzelnen, über URLs und in der Folge auch DOIs erreichbaren, Text-Dateien abgelegt. Diese Dateien werden außerdem von der UB der LMU übernommen. Dabei werden die Daten zusätzlich in schematisierten Metadatenformaten (DataCite für die generischen Metadaten, CIDOC-CRM für die inhaltliche Tiefenerschließung) erfasst, was schließlich zur Auffindbarkeit der digitalen Objekte auch über die Bibliothekskataloge führt.


Literatur: Hui 2012; Hui 2016; 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.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Digital Object Identifier (DOI)

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

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

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




Vorbemerkung:

Seit ihrem Aufkommen vor wenigen Jahren werden die FAIR-Kriterien im wissenschaftlichen Umfeld intensiv diskutiert, denn die in diesem Akronym zusammengefassten Begriffe sind zwar intuitiv eingängig, allerdings nicht trennscharf, weil in funktionaler Hinsicht untereinander verschränkt. Auch innerhalb von VerbaAlpina hat die eingehende Auseinandersetzung mit FAIR bisweilen dazu geführt, dass nicht alle von den einzelnen VerbaAlpina-Mitgliedern zu diesem Thema verfassten Texte inhaltlich vollkommen kongruent ausgefallen sind. Unabhängig von diesen individuell divergenten Interpretationen definiert VerbaAlpina jedoch die Kriterien, die von FORCE11 formuliert worden sind (https://www.force11.org/group/fairgroup/fairprinciples), als Maßstab der FAIR-Compliance. Deren Einhaltung ist aus methodischer Sicht durchdacht. Im Hinblick auf die praktische Umsetzung besteht aktuell noch insofern eine Einschränkung, als die Anreicherung mit generischen Metadaten (gemäß dem Metadatenschema von DataCite) derzeit noch nicht geleistet ist. Diese erfolgt jedoch im Zuge der Übertragung der VA-Daten in das Open-Data-Repositorium der LMU, an deren Operationalisierung momentan gearbeitet wird.
--
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 DataciteSchema 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 zu 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. Die Technologie von VerbaAlpina wurde u.a. nachgenutzt vom Projekt APPI der Universität Lille. Eine entsprechende Dokumentation ist unter dem folgenden Link zu finden: https://github.com/anr-appi/verba-picardia-doc/wiki/Documentation-du-syst%C3%A8me-Verba.

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 u.a. 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 Gesamtheit der Metadaten ermöglicht schließlich das gezielte Auffinden einzelner Dateien über den Bibliothekskatalog.


Im Rahmen des vom Bayerischen Wissenschaftsministerium geförderten Projekts "eHumanities – interdisziplinär" werden die von VerbaAlpina gesammelten Kerndaten (Einzelbelege, morpholexikalische Typen, Konzepte, Georeferenz) exemplarisch auf das sog. CIDOC CRM Schema abgebildet. Bei CIDOC CRM handelt es sich um eine (informatische) Ontologie, die spätestens seit Anfang der 1990er Jahre entwickelt wurde und deren Wurzeln im Umfeld der Museumswelt liegen. Die Entwicklung des Conceptual Reference Model (CRM) geht zurück auf eine Arbeitsgruppe des Comité International pour la Documentation (CIDOC), das seinerseits eine Gliederung des International Council of Museums (ICOM) darstellt. Die dahinter stehende Absicht ist gewesen, Daten unabhängig von variablen Kategoriebezeichnungen auffindbar zu machen. So kann anstelle von "Autor" auch "author", "Verfasser", "auteur" zur Bezeichnung der Kategorie des Verfassers eines Textes verwendet werden. CIDOC CRM sieht für die Bezeichnung des Autors eines Textes das Kürzel E39 vor, so dass die entsprechende Information vollkommen unabhängig von individuellen Bezeichnungen aufgefunden werden kann. Die ICOM/CRM Special Interest Group entwickelt das CRM kontinuierlich weiter. Die jeweils aktuelle Version des Standards (es handelt sich sogar um eine ISO Norm: ISO 21127:2014, was zusätzlich für die Verwendung spricht) kann auf der Seite http://cidoc-crm.org/versions-of-the-cidoc-crm heruntergeladen werden. Derzeit (Juni 2020) umfasst der Standard insgesamt 99 Entitäten, die um insgesamt 197 "Eigenschaften" ("Properties") ergänzt werden. Letztere dienen hauptsächlich der Beschreibung der Beziehungen zwischen verschiedenen Entitäten des Models (Beispiele: P1: "is identified by", P15: "was influenced by" etc.). Das nachfolgende, von Julian Schulz generierte und vorläufige, Diagramm zeigt den Versuch der Zuordnung der VerbaAlpina-Entitäten zu den CRM-Kategorien (E- und P-Nummern) (PDF-Version: https://www.verba-alpina.gwi.uni-muenchen.de/wp-content/uploads/cidoc-verbaalpina.pdf):





Mittelfristiges Ziel ist, den Kerndatenbestand von VerbaAlpina feingranuliert mit den standardisierten Metadaten des CIDOC CRM versehen in das Forschungsdatenrepositorium der UB der LMU zu übertragen. Dort soll dann ein mit der Ruby-on-Rails-Engine Blacklight realisiertes und auf einem Apache Solr-Index aufsetzendes Suchportal den Zugriff auf die Daten ermöglichen.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Forschungsdatenmanagement

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



Forschungslabor

Es war von vornherein vorgesehen, ein virtuelles Forschungslabor einzurichten, das alle interessierten Nutzer einlädt, die von VerbaAlpina entwickelten geolinguistischen Tools (verschiedene kartographische Darstellungen,Typisierungsstufen u.a.) individuell zu nutzen und neue, womöglich auch alternative Analysen und Ergebnisse zu präsentieren oder aber die Tools selbst weiterzu entwickeln. Am Ende der zweiten Förderphase kann man feststellen, dass diese Option bislang nicht nachgefragt wurde. Der Grund dafür liegt allerdings keineswegs im fehlenden Interesse; vielmehr ist das Gegenteil der Fall: Die von VerbaAlpina entwickelte Methodologie und Technologie haben sich als so attraktiv für Partnerprojekte erweisen, dass die Kooperation direkt in deren Konzeption einfloss oder VerbaAlpina als Modellprojekt für die Entwicklung von Metadatenmodellen und einschlägigen Prozeduren/Workflows gewählt wurde, wie bei:

(auct. Thomas Krefeld)

Tags: Linguistik Informationstechnologie Webseite



Gemeinsame Normdatei (GND)

Allgemeines zur GND

Die bibliothekarische Inhaltserschließung basiert im Grunde auf 2 Säulen:
  • Mittels Klassifikationen lässt sich eine (grobe) inhaltliche Einordnung vornehmen (DDC) und z.B. auch die Aufstellung von Literatur in Freihandbeständen organisieren (RVK).
  • Durch die Vergabe von Schlagwörtern bzw. Schlagwortketten (nicht mehr en vogue) lässt sich der Inhalt eines Werkes detaillierter beschreiben (GND).
In der GND wurden 2012 die bisherigen Normdateien PND (Personennamendatei), GKD (Gemeinsame Körperschaftsdatei), SWD (Schlagwortnormdatei) und EST (Einheitssachtitel des Deutschen Musikarchivs) zusammengeführt. Die frühere Differenzierung in Normdaten für die Formalerschließung und Normdaten für die Sacherschließung wurde damit aufgegeben. Heute gibt es pro Entität einen Datensatz, der in beiden Kontexten genutzt werden kann.

Zur Erschließungs- bzw. Vergabepraxis

  • Formalerschließer, d.h. Bibliothekare, die die formalen Metadaten einer Ressource erfassen, wie z.B. Autor, Titel, Erscheinungsjahr, usw., sind dazu angehalten, zumindest die mit der Ressource in Verbindung stehenden Personen (z.B. Autor, Herausgeber, gefeierte Person usw.) mit einem Eintrag in der GND zu verknüpfen. Auf diese Weise wird die Person eindeutig identifiziert. Ist eine Person noch nicht in der GND hinterlegt, wird eine neue Personen-Entität angelegt. Hierzu wird ein vorgegebenes Set an identifizierenden Informationen (z.B. Lebensdaten, Beruf, zugeordnete Einrichtung usw.) erfasst, das, wenn möglich, der vorliegenden Ressource entnommen wird. Eine einschlägige Informationsquellen ist aber z.B. auch der auf einer Institutsseite veröffentlichte Lebenslauf der Person.
  • Sacherschließer sind Bibliothekare, die den Inhalt einer Ressource erschließen. Hierbei stützen sie sich auf den Titel der Ressource, aber nicht ausschließlich. Nicht selten haben Ressourcen recht kunstvoll gestaltete Überschriften, die keinerlei Rückschluss auf den eigentlichen Inhalt zulassen. Sacherschließer gehen daher normalerweise so vor, dass sie sich anhand der Überschrift, des Klappentexts, des Inhaltsverzeichnisses, des Vorworts, der Einleitung, des Schlusses usw. einen Überblick über den Inhalt verschaffen. Anschließend fassen sie diesen in einer Handvoll Schlagwörtern zusammen. Für die Recherche nach geeigneten Schlagwörtern eignet sich z.B. die OGND.
Die DNB erprobt parallel Verfahren, mit denen Schlagwörter automatisiert vergeben werden können.

Zur GND im Kontext von Normalisierung und Datenaustausch

Bibliotheken haben schon recht früh damit begonnen, ihre Erschließungsdaten untereinander auszutauschen. Hierzu braucht es ein einheitliches (Austausch-)Format (MARC) und ein Vokabular (GND), das Bezeichnungen vereinheitlicht und gleichzeitig das Problem von Synonymen, Homonymen usw. behebt.
Seit einigen Jahren werden Daten nicht mehr nur zwischen Bibliotheken ausgetauscht, sondern auch zwischen verschiedenen Kultur- und Wissenseinrichtungen. Im Zuge dessen wird die GND, als eine Quelle von Normdaten, auch verstärkt von Archiven, Museen usw. eingesetzt; sie ist so für die digital humanities grundsätzlich relevant geworden. (Vgl. hierzu das GND4C-Projekt: https://www.dnb.de/DE/Professionell/ProjekteKooperationen/Projekte/GND4C/gnd4c.html)
Die Verwendung von Normdaten, speziell der GND, ermöglicht es Datenaggregatoren wie der Deutschen Digitalen Bibliothek, oder bavarikon, Objekte aus verschiedenen Sparten miteinander zu verknüpfen und damit ihre Auffindbarkeit zu verbessern.
Welchen Vorteil die GND in diesem Kontext bietet, lässt sich an einem (fingierten) Beispiel veranschaulichen:
In bavarikon gibt es z.B. ein Porträt von Martin Luther und gleichzeitig eine Münze mit dem Konterfei Martin Luthers. Beide Objekte haben Martin Luther als „Thema“; Sie können jedoch nur dann (auf einfachem Wege) vom System miteinander in Beziehung gesetzt werden, wenn in beiden Fällen im Feld dc:subject nicht nur ein String eingetragen ist, sondern ein eindeutiger Identifikator, wie z.B. die GND-ID (118575449). Werden statt eines Identifikators Strings verwendet, ist es gut möglich, dass diese voneinander abweichen, d.h. in diesen Fällen wäre zwar die gleiche Person gemeint, ihre Bezeichner würden sich jedoch unterscheiden. Dass dies gar nicht so unwahrscheinlich ist, verdeutlicht ein Blick auf die Spalte „Andere Namen“ des GND-Datensatzes:
http://d-nb.info/gnd/118575449. Einem Menschen fällt es nicht schwer, die (leicht) voneinander abweichenden Strings zusammenzuführen, für eine Maschine ist dies dagegen ein größeres Hindernis.

Zur GND im Kontext von Linked Data

Obwohl die GND mittlerweile auch vermehrt außerhalb von Bibliotheken eingesetzt wird, ist das Format der GND-Datensätze, MARC, stark domänenspezifisch und wird außerhalb der Bibliothekswelt nicht verwendet. Die GND Ontologie stellt einen Versuch dar, diese Lücke zu schließen, um die GND auch für die Verwendung im Semantic Web einsatzfähig zu machen, denn:

„The need for name disambiguation and entries having an authoritative character is an issue that concerns a lot more communities than the library world. In a growing information society the unique identification and linking of persons, places and other authorities becomes more and more important. The GND Ontology aims to transfer the made experience from libraries to the web community by providing a vocabulary for the description of conferences or events, corporate bodies, places or geographic names, differentiated persons, undifferentiated persons (name of undifferentiated persons), subject headings, and works.“
Eine Ontologie besteht aus den folgenden Komponenten:
  • Konzepte/Klassen fassen real existierende Instanzen mit gemeinsamen Eigenschaften zusammen; z.B. „Schlagwort“;
  • Instanzen/Begriffe, welche die eigentlichen Objekte darstellen, z.B. Butter, identifiziert durch die globale URI http://d-nb.info/gnd/4009236-7;
  • Relationen verbinden Konzepte und Instanzen miteinander; z.B. wird Butter über folgendes Konstrukt als ein Objekt der Klasse SubjectHeadingSensoStricto“ (einer Unterklasse der Klasse Schlagwort) ausgewiesen:<rdf:Description rdf:about="http://d-nb.info/gnd/4009236-7"><rdf:type rdf:resource="http://d-nb.info/standards/elementset/gnd#SubjectHeadingSensoStricto"/ß> (vgl. http://d-nb.info/gnd/4009236-7/about/rdf).

Ein Vorteil von Linked Data ist, dass die codierte Information sprachunabhängig ist. Im obigen Beispiel wird das durch den Begriff Butter repräsentierte Objekt, oder anders ausgedrückt, das real world object BUTTER, durch Properties (Eigenschaften) näher beschrieben. Der String Butter taucht zwar in der RDF-Datei auch auf, aber nur als ein Property der Ressource Butter:
<gndo:preferredNameForTheSubjectHeading rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Butter</gndo:preferredNameForTheSubjectHeading> In einem Anwendungsfall, in dem man zusätzlich zum deutschen Begriff Butter die italienische Entsprechung bräuchte, könnte man hierfür einfach ein weiteres Triple (RDF basiert auf Triplen) bilden, z.B. bestehend aus der Ressource http://d-nb.info/gnd/4009236-7 als Subjekt, rdfs:label xml:lang=“it“ als Prädikat und dem Literal (String) burro.

Angenommen die Biblioteca nazionale Firenze würde mit ihrem Nuovo Soggetario Thesaurus ähnlich verfahren wie die DNB mit der GND, könnte man die Ressource Butter in der GND mit der Ressource burro im Nuovo Soggetario Thesaurus z.B. über die Property owl:sameAs in Verbindung setzen, um auszudrücken, dass in beiden Fällen das gleiche real world object BUTTER beschrieben wird.
Mit dem Property <skos:broadMatch rdf:resource="http://zbw.eu/stw/descriptor/14957-0"/> wird z.B. die GND-Ressource Butter mit der ZBW-Ressource Streichfett in Beziehung gesetzt.

(auct. Sonja Kümmet [UB der LMU])

Tags: Informationstechnologie Außersprachlicher Kontext



Georeferenzierung

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 Geoinformationen 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 Geokoordinaten seit einiger Zeitaus rechtlichen Gründen nicht mehr möglich.


(auct. Thomas Krefeld | Stephan Lücke)

Tags: Linguistik Informationstechnologie Außersprachlicher Kontext



Interoperabilität

Im gegebenen Kontext der vom Projekt betriebenen online-Lexikographie versteht VerbaAlpina unter dem "Begriff" Interoperabilität die technische Möglichkeit, über das Internet in standardisierter Weise auf Datenbestände zugreifen bzw. diese verknüpfen zu können. Die Gewährleistung von Interoperabilität ist eines der vier Postulate, die im Akronym FAIR zusammengefasst sind. Voraussetzung für eine effiziente Datenverknüpfung und somit für Interoperabilität ist im Wesentlichen eine feine Granulierung des Datenbestandes, der jedes einzelne digitale Objekt basierend auf einem einheitlichen URL-Schema individuell adressierbar macht. Das Datenmodell von VerbaAlpina unterscheidet im Kern die folgenden drei Entitäten: morpholexikalische Typen (sprachliche Instanz), Konzepte/Begriffe (außersprachliche Instanz) sowie politische Gemeinden (räumliche Instanz). Jedes einzelne Datenobjekt innerhalb einer dieser drei Instanzen ist mit einer individuellen Nummer versehen, die in die folgenden URL-Schemata eingesetzt und somit abgerufen werden können. Die Nummerierung der genannten Entitäten folgt diesem Schema: Morpholexikalische Typen haben das Präfix L, Konzepte C und Ortschaften A. Wesentlicher Bestandteil der URLs ist stets die Angabe der Datenbankversion von VA_DB, wodurch Stabilität und Zitierbarkeit gewährleistet sind. Die Versionsnummern bestehen jeweils aus drei Ziffern, von denen die beiden ersten für das Kalenderjahr und die dritte für das Halbjahr stehen. Die Versionsnummer 172 verweist demnach auf die Ende des Jahres 2017 erzeugte Version.

Eine Liste sämtlicher in einer VA-DB-Version vorhandenen Nummern ist jederzeit über die API von VerbaAlpina abrufbar. Die auf diese Weise gefundenen Nummern können u.a. in die folgenden URL-Schemata eingesetzt werden, die jeweils auf unterschiedliche Funktionsbereiche von VerbaAlpina führen:

Interaktive Online-Karte (nur morpholexikalische Typen und Konzepte):
https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=133&db=[VERSIONSNUMMER]&single=[VA-ID]

Lexicon Alpinum (nur morpholexikalische Typen und Konzepte):
https://www.verba-alpina.gwi.uni-muenchen.de/?page_id=2374&db=[VERSIONSNUMMER]#[VA-ID]

API (morpholexikalische Typen, Konzepte und Gemeinden):
https://www.verba-alpina.gwi.uni-muenchen.de/?api=1&action=getName&id=[VA-ID]&version=[VERSIONSNUMMER]

Die gelisteten Ressourcen können auch unter Verwendung der DOI des VerbaAlpina-Portals angesprochen werden. Dazu muss der Domainname "www.verba-alpina.gwi.uni-muenchen.de" jeweils durch "doi.org/10.5282/verba-alpina" ersetzt und die URL-Parameter (hinter .../? ...) mit dem Parameter "urlappend=" eingeleitet sowie Gleichheitszeichen (=), Ampersand (&) und Hash (#) durch die jeweiligen Hexadezimalwerte der Unicode-Tabelle in der Schreibweise %3D, %26 und %23 ersetzt werden:
https://doi.org/10.5282/verba-alpina?urlappend=%3Fpage_id%3D2374%26db%3D[VERSIONSNUMMER]%23[VA-ID] (für Einträge im Lexikon Alpinum)

Beispiele:

ALMHÜTTE (Eintrag zum Konzept ALMHÜTTE (WIRTSCHAFTSGEBÄUDE AUF DER ALM) im Lexicon Alpinum)
babeurre (m.) (roa.) (Darstellung der Verbreitung des morpholexikalischen Typs L1435, “babeurre (m.) (roa.)“, auf der interaktiven Online-Karte von VA)
ALMHÜTTE (Darstellung der Verbreitung von Bezeichnungen für das Konzept C612, ALMHÜTTE, auf der interaktiven Online-Karte von VA)
https://www.verba-alpina.gwi.uni-muenchen.de/?api=1&action=getRecord&id=L1435&version=182&format=xml&empty=0 (Abruf der Metadaten des morpholexikalischen Typs L1435, “babeurre (m.) (roa.)“, über die API im XML-Format)
https://doi.org/10.5282/verba-alpina?urlappend=%3Fpage_id%3D133%26db%3D191%26single%3DL1435 (DOI-Link auf die Darstellung der Verbreitung des morpholexikalischen Typs “babeurre (m.) (roa.)“ auf der interaktiven Online-Karte von VA [s.o.])

Nicht nur der Kerndatenbestand von VerbaAlpina ist feingranular über individuelle, stabile URLs adressierbar. Auch für von registrierten Nutzern angelegte Datensynopsen auf der interaktiven Online-Karte können stabile, dauerhaft verfügbare Zitierlinks abgerufen werden, die anschließend in externe Online-Dokumente eingesetzt werden können und bei Aufruf exakt die vom Nutzer erzeugte Kartenansicht anzeigen (Beispiel: https://www.verba-alpina.gwi.uni-muenchen.de?page_id=133&db=172&tk=2352 [synoptische Karte mit Visualisierung der Verbreitung der Basistypen butyru(m) und Schmalz).

(auct. Stephan Lücke)

Tags: Informationstechnologie



Konzeptbeschreibung

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

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

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



Metadaten

Beim Umgang mit Daten wird gerne zwischen Primärdaten und Metadaten unterschieden. Als Metadaten gelten alle Daten, die die Primärdaten beschreiben. Anstelle von "Metadaten" können auch die bedeutungsidentischen Bezeichnungen "Attribute" oder "Merkmale" verwendet werden. Im Zuge der Datenmodellierung wird festgelegt, welche Primärdaten durch welche Metadaten beschrieben werden müssen oder können. Die Kategorie "Metadatum" zerfällt wiederum in einzelne Metadatenkategorien. Für jede Metadatenkategorie werden außerdem die jeweils zulässigen Werte definiert.

Am besten ist dieses System an einem Beispiel zu demonstrieren. Die gegebenen Primärdaten seien Personen. Jede Person sei durch ihren Namen, Vornamen, Geburtsort, Geburtsdatum sowie ihre Augenfarbe beschrieben. Die zulässigen Werte könnten wie folgt beschrieben werden:

Name: Zeichenkette, bestehend aus Buchstaben
Vorname: Zeichenkette, bestehend aus Buchstaben
Geburtsort: Zeichenkette, bestehend aus Buchstaben
Geburtsdatum: Datum in der Form JJJJ-MM-TT
Augenfarbe: Ein Wert aus der Liste "braun, grün, blau"

Jedes Individuum sollte durch die Summe aller Werte in den verschiedenen Metadatenkategorien eindeutig beschrieben werden. Sobald der Fall auftritt, dass eine Duplizität im Datenbestand auftritt, also zwei Individuen mit vollkommen identischen Werten in allen Metadatenkategorien auftreten, muss das Metadatenschema als unzulänglich betrachtet und modifiziert werden.

(auct. Stephan Lücke)

Tags: Informationstechnologie



Metadatenschema

Ganz allgemein gesprochen dienen Metadatenschemata der systematischen Beschreibung von Gegenständen oder Sachverhalten sowie deren Beziehungen untereinander. Ganz wesentlich ist dabei die Definition von Entitäten und deren spezifischen Eigenschaften, wobei strenggenommen die Grenze zwischen Beschreibung und Definition verschwimmt.

Grundsätzlich können Metadatenschemata für beliebige Bereiche definiert werden, maximalen Nutzen entfalten sie jedoch erst, wenn sie als weithin akzeptierter Standard etabliert sind. Der Mehrwert besteht dabei hauptsächlich darin, dass sich inhaltlich kompatible Datenbestände eindeutig aufeinander beziehen bzw. mit einander verknüpfen lassen (Interoperabilität). Insofern spielen Metadatenschemata auch eine wichtige Rolle im Hinblick auf die Erfüllung der FAIR-Prinzipien. Die Abbildung eines Metadatenschemas kann in unterschiedlicher Gestalt erfolgen. So ist dies z.B. in Listen, Tabellen- oder XML-Form möglich. Eine graphische Darstellung kann in Form eines sog. Entity-Relationship-Diagramms (ERD) erfolgen. Das damit verbundene Konzept des Entity-Relationship-Modells (ERM) scheint mit "Metadatenschema" bedeutungsidentisch zu sein.

Aus der Perspektive von VerbaAlpina spielen Metadatenschemata zunächst im Hinblick auf die Verwaltung des eigenen Datenbestands eine Rolle, wobei hier ein projektspezifisches, nicht standardisiertes, gleichwohl jedoch dokumentiertes Metadatenschema Anwendung findet. Hauptsächlich für den Export der VA-Daten in externe Datenrepositorien kommen auch etablierte Standard-Metadatenschemata zum Einsatz. So wird z.B. der Kerndatenbestand von VerbaAlpina, d.h. das georeferenzierte und konzeptbezogene morpholexikalische Material aus VA_DB, im Zuge der Übertragung in das Open-Data-Repositorium der Universitätsbibliothek der LMU mit dem vom gleichnamigen Konsortium kuratierten Metadatenschema Datacite beschrieben. Zusätzlich wird der Kerndatenbestand von VerbaAlpina im Metadatenschema CIDOC-CRM abgebildet, das eine inhaltliche Tiefenerschließung des Materials zum Ziel hat. CIDOC-CRM wird üblicherweise als eine "Ontologie" bezeichnet. Die Abbildung der VA-Daten auf die dort definierten Klassen und Eigenschaften und die anschließende formale Repräsentation des Ergebnisses, das sodann die primären VA-Daten und die sekundären CIDOC-CRM-Metadaten synoptisch kombiniert, rechtfertigt dennoch, CIDOC-CRM als "Metadatenschema" zu bezeichnen. Das Beispiel zeigt, wie fließend die Übergänge sein können und wie unscharf der Begriff "Metadatenschema" bisweilen erscheinen kann. Unabhängig von allen terminologischen Fragen sollte es bei der Erschließung von Forschungsdaten im Wesentlichen darum gehen, Metadaten in strukturierter, einer Ontologie folgenden Form in einem verbreiteten Austauschformat (z.B. RDF) zur Verfügung zu stellen.

Die Erschließung der VA-Kerndaten sowohl mit DataCite als auch mit CIDOC-CRM erfolgt im Rahmen des Forschungsprojekts eHumanities – interdisziplinär, das drei Jahre lang (bis 2021) vom Bayerischen Ministerium für Wissenschaft und Kunst gefördert wird und sich mit der Herausforderung des Forschungsdatenmanagements (FDM) befasst. VerbaAlpina besitzt innerhalb von eHumanities – interdisziplinär den Status eines Pilotprojekts.

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

Tags: Informationstechnologie



Module

s. Versionierung.

Tags: Informationstechnologie



Normdaten

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 (unter Einbeziehung der Einheitssachtitel-Datei des Deutschen Musikarchivs) 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 Q-ID 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

[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

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



Transkription

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.
Eine vollständige Liste der Regeln für die Originaltranskription findet sich unter Transkriptionsregeln.

(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



Transkriptionsregeln

Wir unterscheiden zwischen Basiszeichen und Diakritika.

Basiszeichen befinden sich auf der Grundlinie. Alle Zeichen, die sich nicht auf der Grundlinie befinden, werden als Diakritika betrachtet. Als Diakritika im weiteren Sinne werden auch rein typographische Variationen eines Basiszeichens behandelt, z.B. wenn das Basiszeichen kleiner dargestellt wird als die anderen.

Basiszeichen


Basiszeichen, die in der ASCII-Tabelle vorhanden sind, werden beibehalten (= alle lateinischen Buchstaben; nicht deutsche Umlaute!). Alle anderen Basiszeichen werden durch eine Kombination von einem Buchstaben und einer Ziffer transkribiert (siehe Tabelle).

Diakritika


Diakritika werden grundsätzlich hinter das Basiszeichen gesetzt, dem sie zugeordnet sind. Bei mehreren Diakritika auf einem Basiszeichen muss die folgende Reihenfolge eingehalten werden.

  • Zunächst werden Diakritika notiert, die eine typographische Variation eines Basiszeichens markieren, z.B. wenn das Basiszeichen höher oder tiefer gesetzt wird. Diese Diakritika werden in der Tabelle gelb dargestellt.
  • Danach folgen Diakritika unter und über dem Basiszeichen in der Reihenfolge von unten nach oben. Insbesondere müssen die Diakritika unter einem Basiszeichen (grün markiert) immer vor denen über einem Basiszeichen (blau markiert) kommen.
  • Als letztes werden Diakritika notiert, die nach dem Basiszeichen kommen, z.B. ein Längenzeichen oder ein Apostroph nach einem Basiszeichen. Diese sind in der Tabelle orange markiert.

Jedes Zeichen, das für die Transkription eines Diakritikums verwendet wird, darf pro Basiszeichen nur einmal vorkommen. Für die Wiederholung des selben Diakritikums gibt es eigene Regeln, z.B. : für zwei Punkte über einem Basiszeichen oder \2 für einen doppelten Gravis.

Wenn sich ein Diakritikum auf zwei oder mehr Zeichen bezieht z.B. a͠e werden die Basiszeichen in eckige Klammern gesetzt, in diesem Fall [ae]~.

Klammern und Kommentare

Kommentare (ob eingeklammert oder nicht) werden nach dem Beleg, auf den sich sich beziehen, in spitze Klammern gesetzt, z.B: (m.) → <m.>. Wenn der gesamte Beleg eingeklammert ist, wird der Beleg ohne Klammern transkribiert und in spitzen Klammern die Bemerkung "eingeklammert" hinzugefügt.

Trennzeichen


Eventuelle morphosyntaktische Varianten eines Belegs wie z.B. Singular- und Pluralformen werden durch Kommata, verschiedene Wortformen durch Semikola getrennt. Dies entspricht der Darstellung der Belege im Atlas AIS. Wenn in der Quelle die Belege durch andere Trennzeichen (z.B. / oder -) getrennt sind, müssen diese in der Transkription entsprechend durch Kommata und Semikola ersetzt werden. Eventuelle Nummerierungen von verschiedenen Varianten werden weggelassen.

Typisierte Belege


Wenn die Quelle für einen Informanten sowohl einen Einzelbeleg als auch eine bereits typisierte Variante enthält, wird nur der Einzelbeleg transkribiert. Nur falls dies nicht möglich ist, wird die typisierte Variante transkribiert und über das entsprechende Auswahlmenü als "phon. Typ" bzw. "morph. Typ" markiert. Im Gegensatz zu Einzelbelegen sind bei Typen auch Großbuchstaben erlaubt, sonst gelten die selben Regeln für die Transkription.

Wenn für einen Informanten Einzelbelege und typisierte Belege gemischt vorkommen, müssen für die Transkription zwei verschiedene Zeilen angelegt werden, in denen die Transkripte entsprechend als Typ bzw. Beleg markiert werden.

Sonderzeichen in der Quelle


Alle Zeichen, die in der Transkription als Diakritika verwendet werden (inklusive Ziffern) müssen, wenn sie als Originalzeichen vorkommen, durch die Voranstellung von zwei Backslashes maskiert werden, z.B. * → \\*. Dies bezieht sich aber nur auf Zeichen, die in der Quelle Teil der phonetischen Transkription des Einzelbelegs sind. Bei Zeichen, die eine bestimmte Bedeutung haben, muss diese Bedeutung stattdessen als Bemerkung in spitzen Klammern hinter den Beleg geschrieben werden. Zum Beispiel steht das Zeichen † im AIS für eine veraltete Form und muss in der Transkription mit <veraltet> notiert werden. Klammern werden immer ersetzt (siehe Klammern und Kommentare und Platzhalter).

Folgende Zeichen aus dem AIS können einfach weggelassen werden: ℗, ○, P, S, +

Platzhalter


Alle Formen von Platzhaltern oder verkürzten Schreibweisen müssen durch die Zeichenfolge ersetzt werden, für die sie stehen. Wenn ein Beleg mit Kommentaren in mehrere Belege aufgeteilt wird, müssen diese wiederholt werden. Die folgende Tabelle enthält einige Beispiele:

Beleg QuelleTranskription
u kā́ni; i ~u ka-/ni; i ka-/ni
(Alm)hütteAlmhu:tte; Hu:tte
(um bé̜l) pašọ́ɳ (selten)um be(/l pas^o?/n1 ; pas^o?/n1

Eine Ausnahme gibt es bei kleinen phonetischen Variationen bei bereits typisierten Belegen, so kann z.B. der morpho-lexikalische Typ "Sänn(e)hütte" als "Sa:nn\(e\)hu:tte" transkribiert werden.

Transkription nicht möglich


Bei Informanten, für die in einer Karte keine Daten eingetragen sind, wird der "vacat"-Button verwendet. Falls die Transkription eines Beleges problematisch ist (z.B. weil sie anhand dieser Regeln nicht möglich oder unklar ist), wird der "Problem"-Button verwendet. Die Buttons "Konzept nicht vorhanden" und "Bezeichnung nicht bekannt" werden jeweils verwendet, wenn die Sache an sich nicht bekannt ist bzw. die Sache bekannt ist, aber der Informant sie nicht benennen kann. Sollte die Quelle nur angeben, dass zwar das Wort, jedoch nicht die Bedeutung bekannt ist, dann muss dieser Beleg nicht transkribiert werden.

Konzeptzuweisung


Über das rechte Auswahlmenü wird der Äußerung ein Konzept zugeordnet. Der vorausgewählte Wert entspricht dabei immer dem Konzept, welches für diesen Stimulus bisher am häufigsten zugeordnet wurde, also im Normalfall dem "Hauptkonzept" der jeweiligen Karte. Wenn dieses nicht zutreffend ist, weil bespielsweise für einen Beleg ein spezifischeres Konzept angegeben wird, muss dieses (falls noch nicht vorhanden) neu angelegt und zugeordnet werden. Für alle Äußerungen (Ausnahme vacat, Problem etc.) muss ein entsprechendes Konzept ausgewählt sein. Das Konzept bezieht sich immer auf die vollständige Äußerung, auch dann, wenn beispielsweise mehrere Varianten durch Semikola getrennt vorkommen. Falls einzelne Varianten verschiedene Bedeutungen haben, muss für jede Variante eine eigene Zeile angelegt werden. Der Beleg "prẹẓṓr V, káłọ M" von AIS-Karte 1212 muss zum Beispiel, da die Abkürzungen "V" und "M" für verschiedene Konzepte stehen, folgendermaßen transkribiert werden:

ÄußerungKonzept
pre?z?o-/rLAB, VOM KALB
ka/l1o?LAB, KÜNSTLICH

Falls für eine Äußerung in der Quelle mehrere Bedeutungen angegeben werden, können im Auswahlmenü auch mehrere Konzepte ausgewählt werden.

Vorschau bei der Transkription


Beim Eingeben der Transkription wird zu Vergleichszwecken hinter dem jeweiligen Textfeld eine Vorschau angezeigt, wie der Beleg nach der Rückkonvertierung aussieht. Falls der Text "Nicht gültig" erscheint, ist der Beleg falsch transkribiert und kann so nicht eingetragen werden. Falls einzelne Zeichen rot markiert im Beta-Code erscheinen, bedeutet das, dass der Beleg zwar gültig ist, aber das Zeichen (momentan) noch nicht konvertiert werden kann. Das tritt hauptsächlich bei Zeichen auf, die in dieser Form noch nicht vorgekommen sind. Der Beleg kann in diesem Fall ganz normal eingetragen werden.

Basiszeichen


Zeichen Beschreibung Beta-Code Kommentar
α
Griechisches Alphaa1
ɒ
Spiegelverkehrtes aa2
æ
Ligatur aea3
β
Griechisches Betab1
ƀ
Durchgestrichenes bb2
χ
Griechisches Chic1
ҁ
Zeichen für Glottisverschlussc2
c
Durchgestrichenes cc3
ɕ
lateinische Minuskel c mit Schleifec4eng. ship
δ
Griechisches Deltad1
đ
Durchgestrichenes dd2
ð
Ethd3
ə
Schwae1
Haken links vom ee2
ε
Griechisches Epsilone3
φ
Griechisches Phif1
ƒ
Labiodentale Fortisf2
ɣ
Griechisches Gammag1
Rechts offenes gg2
g mit unterem Strichg3
ʔ
Glottisschlag g4
ɥ
lateinische Minuskel h gespiegelt und auf dem Kopf stehendh1fra. huit
i mit schrägem Strichi1
ı
i ohne Punkti2
ɨ
i mit waagrechtem Strichi3
ɪ
lateinisches Kapitälchen ii4
ɟ
lateinische Minuskel j mit Querstrichj1
ł
Durchgestrichenes ll1
l mit stark geschwungenem Strichl2
l mit zwei geschwungenen Strichenl3
λ
Lambdal4
ʎ
diagonal gespiegelte lateinische Minuskel yl5ita. figli
ɱ
lateinische Minuskel m mit Haken rechts untenm1
ɳ
Zeichen für velares „n“ (dt. kling)n1
ŋ
velare Nasalen2
ɲ
lateinische Minuskel n mit Haken links untenn3wie ita. gnocchi
œ
Ligatur oeo1
ɔ
links offenes oo2
ơ
o mit Haken am oberen rechten Rando3
ǫ
o mit Ogoneko4
ø
o mit diagonalem Stricho5
ω
Griechisches Omegao6
π
Kreiszahl Pip1
þ
Thornp2
q mit waagrechtem Strichq1
ʀ
Großbuchstabe R auf Höhe eines Kleinbuchstabenr1
ɹ
diagonal gespiegelte lateinische Minuskel rr2
ɾ
lateinische Minuskel r ohne linke obere Serifer3
ʃ
Eshs1
s mit Schrägstrich linkss2
ʂ
lateinische Minuskel s mit retroflexivem Haken links untens3
ϑ
Griechisches Thetat1
Stärker geschwungenes uu1
ʊ
Latin small letter Upsilonu2
ʒ
Ezhz1
ʑ
lateinische Minuskel z mit Schleifez2eng. vision

Diakritika


Zeichen Beschreibung Beta-Code Kommentar Beispiel
Punkt unter Basiszeichen?s?
ė
Punkt über Basiszeichen?1e?1
ä
Zwei Punkte über Basiszeichen:a:
Zwei Punkte unter Basiszeichen:1u:1
Nach rechts geöffnetes Häkchen unter Basiszeichen(o(
Zwei nach rechts geöffnete Häkchen unter Basiszeichen(1e(1
Nach links geöffneter Halbkreis (spiritus lenis) über Basiszeichen)r)
Nach links geöffneter Halbkreis unter Basiszeichen)1o)1
ç
Cedille)2c(2
ó
Akut auf Basiszeichen/o/
Doppelter Akut auf Basiszeichen/2o/2
à
Gravis auf Basiszeichen</td>a</td>
Doppelter Gravis auf Basiszeichen\2a\2
Gravis mit Punkt am oberen Ende auf Basiszeichen\3u\3
ā
Waagrechter Strich über Basiszeichen-Minuszeichen -a-
ā̄
Zwei waagrechte Striche über Basiszeichen-2Minuszeichen -a-2
Waagrechter Strich unter Basiszeichen_Underscore _n_
Doppelter waagrechter Strich unter Basiszeichen_1n_1
Tilde ÜBER Basiszeichen~e~
Stärker geschwungene Tilde ÜBER Basiszeichen~1
Tilde UNTER Basiszeichen+e+
Nach OBEN geöffneter Halbkreis ÜBER Basiszeichen!a!
Nach UNTEN geöffneter Halbkreis ÜBER Basiszeichen%a%
Nach UNTEN geöffneter Halbkreis UNTER Basiszeichen@a@
Nach OBEN geöffneter Halbkreis UNTER Basiszeichen@1k@1
Kreis ÜBER Basiszeichen|u|
Kreis UNTER Basiszeichen&s&
Senkrechter Strich unter Basiszeichen$e$
Hacek^g^
ĝ
Zirkumflex^1g^1
"Zirkumflex" unter Basiszeichen^2o^2
"Hacek" unter Basiszeichen^3d^3
u
Unendlichkeitszeichen über Basiszeichen"u"
"Größer-als-Zeichen" über Basiszeichen>n>
Kreuz unter Basiszeichen*a*
Kreuz über Basiszeichen*1a*1
g’
Apostroph nach Basiszeichen'auf der #-Tasteg'
Umgedrehter Apostroph nach Basiszeichen'1auf der #-Tastea'1
Erhöhte vertikale Linie nach Basiszeichen'2auf der #-Tasteg'2
Häkchen nach Basiszeichen=k=
Ziffer hochgestellt nach Basiszeichen\<n>0Ziffer mit \ maskieren und nachgestellte 0c\20
IPA Längenzeichen:2a:2
IPA Längenzeichen halb:3a:3
ᵃb
Basiszeichen oberhalb der Grundlinie0a0b
Basiszeichen auf der Grundlinie, kleiner als alle anderen Zeichen8n8d
ᵢn
Basiszeichen unterhalb der Grundlinie9i9n
Obere bzw. untere Diakritika eingeklammert[<d>]Eingeklammertes Diakritikum zwischen eckigen Klammernu[:] bzw. e[?]
Basiszeichen über Basiszeichen{<z>}Erhöhtes Basiszeichen zwischen geschweiften Klammerna{o}
Basiszeichen unter Basiszeichen{1<z>}a{1o}

Spezielle Zeichen

Diese Zeichen haben prinzipiell den Rang eines Basiszeichens, können aber nicht mit Diakritika ergänzt werden.

Zeichen Beschreibung Beta-Code Beispiel
·e̜kọ́ɳ
Ein Punkt, vor oder nach dem Basiszeichen. Höher als die Grundlinie..1.1e(ko?/n1

Spezielle Leerzeichen
(Reguläre Leerzeichen werden in dieser Tabelle durch das Symbol ␣ dargestellt.)

Zeichen Beschreibung Beta-Code Beispiel
w‿d
Leerzeichen mit Bogen{␣}w{␣}d


(auct. Stephan Lücke | Florian Zacherl)

Tags: Informationstechnologie



Uniform Resource Name (URN)

s. Digital Object Identifier

Tags: Informationstechnologie



Versionierung

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:

Stadel bei Fex Platta, im Fextal bei Sils Maria, Oberengadin (Bild: Thomas Krefeld)

Sennhütte auf der Roßsteinalm, oberhalb Lenggries (Bild: Thomas Krefeld)

15/1

Herbst in Südtirol, in der Nähe des Passeiertals (Bild: Susanne Oberholzer)

15/2

Pflege des Mascherpa Käses, Lombardei (Bild: Formaggio Bitto )

16/1

Alpsee, Immenstadt im Allgäu (Bild: Christina Mutter)

16/2

Heuernte im Chiemgau (Bild: Sammlung Groth-Schmachtenberger, Freilichtmuseum Glentleiten)

17/1

Heuernte (Bild: Sammlung Groth-Schmachtenberger, Freilichtmuseum Glentleiten)

17/2

Heuernte (Bild: Sammlung Groth-Schmachtenberger, Freilichtmuseum Glentleiten)

18/1

Winterlandschaft auf der Plose oberhalb Brixen (I) (Bild: Stephan Lücke)

18/2

Blick über die Seiser Alm auf die Geislerspitzen (Bild: Stephan Lücke)

19/1

Zillertaler Alpen (Bild: Thomas Krefeld)

19/2



(auct. Stephan Lücke)

Tags: Informationstechnologie



Wikidata

Wikidata ist eine freie Wissensdatenbank, die Daten ihrer Wikimedia-Schwesterprojekte (Wikipedia, Wikivoyage, Wikisource) als eine Art zentraler Speicher in strukturierter Form bereitstellt. Die Daten auf Wikidata werden unter einer freien Lizenz zur Verfügung gestellt (Creative Commons Public Domain Dedication 1.0) und können in bis zu 111 verschiedenen Einzelsprachen und Dialekten erstellt, verwendet und durchsucht werden. Im Unterschied zu Wikipedia sind auf Wikidata keine vollständigen Artikel, sondern lediglich einzelne Konzepte gelistet, die alle über eine eigene Q-ID verfügen. So hat das Konzept MOLKE z.B. die Q-ID 185009 (vgl. Wikidata). Wenngleich die Nachhaltigkeit dieses Katalogs nicht im strengen Sinn garantiert wird, ist damit aus sprachwissenschaftlicher Sicht de facto die Grundlage eines sehr nützlichen onomasiologischen Referenzsystems entstanden.

Den Konzepten von VerbaAlpina werden die entsprechenden Q-IDs von Wikidata zugewiesen. Dies ist für VerbaAlpina vor allem hinsichtlich der Kooperation mit dem Projekt GeRDI von Relevanz. So wird Wikidata von GeRDI als Wissensdatenbank (knowledge base) verwendet, um eine disziplinübergreifende Suche in unterschiedlichen Sprachen gewährleisten zu können. Auf diese Weise wird ermöglicht, dass z.B. bei Eingabe eines Suchbegriffs auf Italienisch zugleich auch Ergebnisse in anderen Sprachen gefunden werden.

Konzepte, die auf Wikidata noch nicht erfasst sind, werden von VerbaAlpina dort neu angelegt. Zu diesem Zweck wurde auf Wikidata ein Projektaccount für VerbaAlpina eingerichtet. Als Default-Sprache gilt Englisch. Es können jedoch Übersetzungen des jeweiligen Konzepts in allen auf Wikidata verfügbaren Sprachen eingegeben werden.

(auct. Christina Mutter)

Tags: Informationstechnologie