Diese Version ist aktuell für einen internen Test (nur für assoziierte Forscher*innen) vorgesehen. Das Barometer umfasst folgende Funktionen:

  • Frontend (Benutzeroberflächen)
    Es sind mehrere Arten von Benutzeroberflächen (kurz GUI) vorgesehen.

    • Windows-Client:
      Der Windows-Client ist die mächtigste GUI. Mit diesem Frontend kann auf eine Vielzahl von Daten zugegriffen werden. Die Daten können lokal gespeichert und auch exportiert werden. Nur assoziierte Forscher*innen haben Zugriff auf dieses Frontend.
    • WebAssembly:
      WebAssembly ist ein neuer offener Standard für dynamische Webinhalte. Früher wurde für derartige Inhalte Flash oder Java verwendet – diese Techniken stehen nicht mehr zur Verfügung. WebAssembly ist zertifiziert und wird von allen modernen Webbrowsern unterstützt. WebAssembly ist wesentlich schneller bei der Analyse von großen Daten als JavaScript.
    • Public RSS-Data-Feed:
      Wird wie „Public HTML/JS“ vom Service „StaticData“ (verfügbar über „Apache2 / barometer“) erzeugt und verweist auf die statisch generierten Daten.
    • Public HTML5/JS:
      Visualisierungen die vom Service „StaticData“ (verfügbar über „Apache2 / barometer“ – s. u.) täglich neu erzeugt werden.
  • Web-Server (Linux)
    Dies ist der Server auf dem auch diskurslinguistik.net läuft. Dieser Server stellt drei Dienste bereit, die Zugriff auf die Daten ermöglichen.

    • „Apache2 / ReverseProxy“:
      Dies ist lediglich eine Weiterleitung von Anfragen, die an die API weitergeleitet werden. Alle Anfragen unterliegen der „RESTful-API“-Spezifikation.
    • „Apache2 /barometer“:
      Der Apache-Server stellt ein Verzeichnis bereit, in dem statische HTML5- und JavaScript-Dateien abgelegt werden.
    • StaticData:
      Wird vom Server mittels CRON (zeitgesteuerte Aufgabe) gestartet. Prüft nach dem Start, ob sich Daten geändert haben. Falls neue Daten vorliegen, werden die davon abhängigen Analysen neu berechnet. Die Ausgabe erfolgt dann in „Apach2 /barometer“ (siehe oben).
  • RESTful-API
    Hierbei handelt es sich um eine Definition der Schnittstelle.
  • Anwendungs-Server (Windows)
    Dieser Server ist das Herzstück und führt Sammlung, Aufbereitung und Analysen durch.

    • Infrastructure
      Alle Services sind für den Betrieb essentiell.

      • Mailer
        Versendet Mails (Registrierung / Passwort ändern / ggf. auch Berichte/Analyseergebnisse).
      • UserData
        Dies ist der zentrale Nutzerdienst. Nutzer können sich hier registrieren, anmelden und ihre personenbezogenen Daten einsehen und ändern (inkl. Passwort).
        Der Service teilt bei der Anmeldung eines registrierten Benutzers automatisch einen verfügbaren DataProxy zu (s. u.).
      • DataProxy
        Der DataProxy listet alle verfügbaren Daten (/catalog), gibt Auskunft über die Tages-Quota des Nutzers (/quota) und überwacht diese. Außerdem leitet er Anfragen an Webservices weiter, die mit der Analyse betraut sind (/query).
    • LiveData (SIM-Stack)
      Die Services für die LIVE-Korpora führen die Analysen durch.

      • SIM (steht für SingleIndexMetric)
        Ein SIM basiert auf der CorpusExplorer Console (cec) – mit ihr werden die Korpora ausgewertet.
        Ein SIM ist mit einer einfachen Datei frei konfigurierbar. Für die Konfiguration der aktuell mehreren Dutzend SIMs existiert zudem ein eigenes Konfigurationsprogramm.
        Die Konfiguration umfasst (A) welcher Befehl auf der CEC ausgeführt werden soll und (B) wie dieser Befehl von der Datenbank (basierend auf RocksDB – ein Key/Value-Store mit vorgeschaltetem Bloom-Filter) verarbeitet wird – diese Verarbeitungsart wird intern als DatabaseBehavior bezeichnet. Folgende DatabaseBehavior stehen zur Verfügung:

        • date-value
          Die gesamte Ausgabe der CEC wird als Tageswert in die Datenbank eingelesen. Abfragen zu einem Tag geben dann alle Daten zurück. Bsp.: Die Abfrage nach 2020-01-18 ergibt bei einem frequency1-Service alle Frequenzen des Korpus „2020-01-18“.
        • dictionary
          Sollte (bzw. wird nur) im Zusammenhang mit dem CEC-Befehl ‚corresponding‘ verwendet – erlaubt das Auflösen von Relationen zwischen Layer-Werten. Bsp.: Die reduzierende Abfrage nach „Häuser“ liefert „Haus“, die expandierende Abfrage nach „Haus“ liefert „Häuser“, „HAUS“, „Häusern“ etc. – die bidirektionale (bidirektional -> Reduktion + Expansion) Abfrage zu „Häuser“ liefert „Häuser“, „HAUS“, „Häusern“ etc.
        • value-date
          Führt zunächst wie „date-value“ eine Abfrage zu allen Tageswerten aus. Ordnet dann die Werte zu. So kann z. B. nach „Haus“ gefragt werden und alle datierten Frequenzen werden zurückgegeben.
        • value-date-fs
          Es zeigt sich, das „value-date“ ab einer gewissen Größe (viele Werte/Token * viele Tage) sehr lange für die Erstellung eines Index benötigt. Daher wurde eine Filesystem (FS) basierte Lösung entwickelt, die wesentlich effizienter arbeitet (schnellere Inserts / minimal langsamere Reads / bessere Parallelisierung).
      • KWIC
        Der KWIC-Service steht aktuell nur für die LIVE-Korpora zur Verfügung. Es wird immer nur Zugriff auf die letzten 30 Tage gewährt. Die KWIC-Suche erlaubt nur einfache Abfragen und keine komplexen Suchen. Dafür ist sie extrem schnell (Rückgabezeiten unter 250ms) und sehr ressourcenschonend (ca. 800 MB RAM).
      • CorpusCollector
        Der CorpusCollector schließt die Lücke, die die KWIC-Suche nicht abdecken kann. Der CorpusCollector ist nur für assoziierte Forscher*innen vorgesehen. Er bietet Zugriff auf alle LIVE-Korpora (nicht nur 30 Tage) und erlaubt auch komplexere Suchabfragen. Die Ergebnisse werden als CEC6-Korpora geliefert. Deren Berechnung und Zusammenstellung erfolgt in Zeiten, in denen der Server nicht oder nur wenig ausgelastet ist.
    • RefData
      Die Korpora unter RefData nutzen den SIM-Stack (s. o.), jedoch ohne KWIC und CorpusCollector (da diese Korpoa für Assoziierte verfügbar sind). Folgende Korpora stehen zur Verfügung:

      • DTA (Zeitungen)
        Historisches Zeitungskorpus aus dem Deutschen Text-Archiv
        [Quelle]
      • BT-Plenar
        Bundestags Plenarprotokolle
        [Quelle]
      • BT-Druck
        Bundestags Drucksachen
        [Quelle]
      • CAL²
        Hintergrund ist die CEC6 (CorpusExplorer) Version des CAL²-Korpus
        [Quelle]
      • kleineAnfragen
        Kleine und große Anfragen der Landesparlamente und Antworten dazu.
        [Quelle]
      • Bundesanzeiger
        [Quelle]
      • OMP-Artikel
        Artikel aus dem OneMillionPosts-Korpus (nur Zeitungsartikel – keine Leserkommentare)
        [Quelle]
      • SPIEGEL
        Alle frei verfügbaren Artikel des Spiegel-Magazins.
        [nicht frei verfügbar]
      • Neues Deutschland
        Alle Artikel der Zeitung „Neuen Deutschland“.
        [nicht frei verfügbar]
    • CorpusProcessing
      Alle Rohdaten werden mittels CorpusExplorer aufbereitet.
    • SCIEBO
      Dient aktuell als Backup-Speicher.
    • Sources
      Die aktuelle Quellen:

      • RSS/WEB & WEB
        Initial eine Liste mit Webseiten/RSS-Feeds die Artikel über die DPA, google news posten. Ergänzt durch ausgewählte Webseiten.
      • Twitter
        Aktuell nicht im Einsatz. Könnten aktuelle Tweets erheben.

      • Weitere Quellen möglich
    • StaticData
      StaticData umfasst keine Korpora im klassischen Sinn. Vielmehr beinhalten diese Services Zusatzinformationen.

      • OpenThesaurus
      • GermaNet
      • Google NGram – aktuell nicht aktiv
      • DeReWo – aktuell nicht aktiv
      • Wiktionary
      • FastText – aktuell nicht aktiv
        word2vec für CAL² und für alle Texte aus LIVE in 2019.
      • CAL²
        Portal – Promotionsprojekt von Isabell Gauer. Nicht identisch mit „RefData / CAL²“. Start Q2/Q3 2020.

      • Weitere StaticData möglich.