VerbaAlpina@GeRDI


Gerdi-Fragebogen zu VerbAlpina (Februar 2018)

  • Abläufe:

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

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

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

  • Daten:

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

Formate: relationales Datenformat;

Typen: ??

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

Software: ??

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

Datenschutz: [Persönlichkeitsrechte? Urheberrechte?]

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

  • Metadaten:

Arten: s. Attribute der VAP-Schnittstellen

Speicherung: gemeinsam mit Primärdaten in VAP-Schnittstellen

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

Datenschutz: s.oben

Schnittstellen: ??

  • Datenauswertung:

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

Aufbereitung: ??

Visualisierung: Online-Karte (Javascript, Google API)


VA@GeRDI (27. Juni 2018)

Tagesordnung

TOP 1: Roadmap (TW/HN) 

TOP 2: Usecases Datenkorrelation (TW/HN)

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

TOP 4: Kooperation GeRDI – UZH (TK)

 

TOP 1: Roadmap (TW/HN)

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

Release 0.3 (Herbst 2018):

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

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

UB e-humanities Projekt

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

Release 0.4 (Winter 2018/19)

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

Release 0.5 (Frühling 2019)

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

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

Release 0.6 (Sommer 2019)

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

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

Release 0.7 (Herbst 2019)

Puffer für Unvorhergesehenes

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

Methodik GeRDI

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

Allgemeines

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

TOP 2: Usecases Datenkorrelation (TW/HN)

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

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

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

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

Teilnehmer: Krefeld, Lücke, Nguyen, Weber

Ort: ITG

Zeit: 12:30-13:30

VA ist interessiert an Daten aus folgenden Kategorien:

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

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

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

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

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

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

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


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

Ort: Medienlabor, Raum 3010, Schellingstraße 33

Zeit: 14:00-16:00 Uhr

Tagesordnung

TOP 1: Aktueller Stand: Metadaten, Harvester

TOP 2: Statusbericht GeRDI 0.2 und 0.3

TOP 3: Nächste Planungen GeRDI 0.4

TOP 4: Vorbereitungen Community Workshop

TOP 5: VA-Datenexport

 

TOP 1: Aktueller Stand: Metadaten, Harvester

GeRDI-Dienste

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

Workflows

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

Metadatenschema

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

 

TOP 2: Statusbericht GeRDI 0.2 und 0.3

GeRDI 0.2:

  • weitere Repositorien wurden eingebunden
  • weitere Filterfunktionen wurden implementiert

GeRDI 0.3:

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

TOP 3: Nächste Planungen GeRDI 0.4

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

TOP 4: Vorbereitungen Community Workshop

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

TOP 5: VA-Datenexport

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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.