Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 1. Motivation, Gesamtziel

Der WLO-Hub bzw. die WLO Suche enthält Metadaten von erschlossenen Inhaltequellen. Die Quellen liefern häufig sehr wenig und oft keine guten Metadaten.

Gute Metadaten sind wichtig für

  1. Such- und Vorschlagsfunktionen, also die Aufindbarkeit von Inhalten
  2. die Auswahl von Inhalten
    (beispielsweise akzeptieren manche Bundesländer nur Inhalte, die keine Werbung enthalten)
  3. die rechtskonforme Nutzung von Inhalten
    (beispielsweise muss i.d.R. die Lizenz und der Urheber bei der Nutzung angegeben werden, dafür müssen diese Daten verfügbar sein)
  4. ...gern weitere Gründe ergänzen...


Unsere WLO-Metrik soll kurz gefasst folgendes leisten:

  1. Quantität: Wieviele Datensätze existieren (z.B. von Quelle A versus Quelle B) - und  -  Wieviel % des Feldes X der Datensätze sind ausgefüllt
  2. Qualität: Wie gut sind die ausgefüllten Metadaten (sind es eher Falschinformationen, zu grobe Informationen oder optimal richtige und detaillierte Informationen)
  3. Benutzung: Wie oft / gut wird ein Metadatum genutzt (z.B. wird häufig nach der Bildungsstufe gefiltert). Daraus leiten wir ab, für welche Metadatenfelder wir Ressourcen für Metadatengeneratoren oder für Redaktionsaktivitäten investieren.


<< Zurück zur Startseite / Gesamtinhaltsverzeichnis


Inhalt dieser Seite

Table of Contents


Mitwirkende an dieser Seite:

Contributors Summary

2. State of the Art und Beispiele Dritter


Es folgen ein paar Positivbeispiele für Metadaten-Metriken. Tatsächlich ist WLO (siehe also auch Abschnitt 3.) in einigen Lösungsbereichen State of the Art.

Benchmarking: QA Catalogue for analysing library data (Unibibliothek Gent)

Ein relativ komplexes Qualitätsmetiktool - zu komplex für uns ist - aber gut zum Inspirieren lassen

http://134.76.163.21/gent/




Elixier Metameter (Deutscher Bildungsserver)

Die Metrik des vom Bildungsserver mit organisierten "ELIXIER"-Netzwerks.

http://www.bildungsserver.de/elixier/elixiermetadatenguete.html 



3. Aktueller Stand der WLO-Lösung


Theos MetaQS: Lehrplanthemen-Übersicht

  • senkrecht alle Lehrplanthemen
  • waagerecht die wichtigsten (leider hard codiert) Inhaltetypen
  • in einer Spalte eines Inhaltetyp werden gegenübergestellt
    • Inhalte in der Suchmaschine
    • Inhalte im Fachportal

Das ermöglicht den Fachredaktionen Inhalte in der Suche zu finden, die sie noch in ihre Sammlung übernehmen könnten.

API: http://c106-168.cloud.gwdg.de/docs
Dokumentation: https://openeduhub.github.io/metaqs-docs/



Steffens MetaQS: Fachportalinhalte-Qualität (Gamification)

Zeigt Qualitäts-Issues von Inhalten eines Fachportals (Inhalte einer Fachredaktion)

  • MetaQS-Score
  • Materialien ohne Fachgebiet(smetadatum)
  • Materialien ohne Bildungsstufe
  • Materialien ohne Lizenz
  • Materialien ohne Schlagworte
  • Materialien ohne Titel

Offene Wünsche:

  • zeigt alle Pflichmetadaten der Redakteur:Innen als "Materialien ohne XYZ"



Sammlungsqualität meines Fachportals

  • Sammlung ohne Inhalt
  • Sammlung ohne Schlagworte
  • Sammlung ohne Beschreibungstext


Offene Wünsche:

  • weitere "ohne" Metadatum A, B, C



Metadatenqualität meines Fachportals

  • Senkrecht Sammlungen
  • Waagerecht ausgewählte Metadaten

Offene Wünsche:

  • weitere Metadaten waagerecht, relativ kurzfristige Anpassungsmöglichkeiten 
  • alle Pflichtmetadaten als Spalte anzeigen
  • ein Schalter ermöglicht den Wechsel zwischen OER und allen Inhalten

4. Nötige Arbeiten


4.1 Wünsche, Anforderungen



Info
titlewer macht was

Hier schreiben wir auch gemeinsam in Meetings beschlossene Anforderungen.

  • Quantität bestimmen
  • welche Metadaten werden genutzt (Klickzahlen, Christopher fragen)
    • welche Abfragen werden gemacht
  • nächster Schritt Qualität der Metadaten bestimmen
    • Anhand von Testgraphen soll hier bestimmt werden, welche Metadaten Aufmerksamkeit benötigen
    • Anhand von Planung_Metadatengenerierung bestimmen wir gemeinsam mit den Redakteur:Innen, was gerade den höchsten Wert generiert. Bspw. die Generierung von Beschreibungstexten darf gerne automatisierterledigt werden.


Erstes Zwischenziel: Qualitätsmetrik: Metadatenvollständigkeit von Quellen.

  • siehe Bild rechts, sollen
    • senkrecht alle Metadatenfelder des (im Tabellenkopf gewählten) Metadatenprofils aufgelistet werden
    • waagerecht sind in Spaleten die Quellen
    • in der 1. Fassung soll nur der Füllstand der Metadaten gezeigt werden (% der Datensätze gefüllt)
    • nicht Teil des 1. Sprints ist die Qualität der Füllung, welche künftig die KI durch grüne lächelnde oder rote mürrische Robots zeigt.

  • Mutmaßlich (Rücksprache Torsten) muss das MetaQS-Tool nur die Tabelle liefern. Das Umfeld der Tabelle zeigt die edu-sharing Redaktionsumgebung. Hier kann man
    • oberes Suchfeld: man kann Filtern nach Quellen oder nach Metadatenfeldern. 
      Sucht man nach "Cover" bietet die Suche (ähnlich LinkedIn) Suchergebnisse
      "Cover - in Metadatenfeldern"
      "Cover - in Quellen"


  • Die Prozentzahlen der Tabellenzelle sollen anklickbar sein (ggf. blaue Schrift ?)
    der Klick führt zur betreffenden Inhaltemenge, in der DIESES Metadatum nicht ausgefüllt ist.


  •  Links kann die Redaktionsumgebung die übliche Filterleiste einblenden. Diese erlaubt 
    • Filtern der Quellen
    • Filtern der Datensätze (mit üblichen Inhaltemengen-Filtern)
    • Filtern der Metadatenfelder
    • oder Kombinationen daraus

Weiterführend (spätere Entwicklungsphasen)

sollen Spalteninhalte anpassbar sein

  • wie oben Quellen
  • Fachportal (Fachredaktion)
  • Buffets
  • verwendet / unverwendet
  • weiteres



Weiterhin könnten Zell-Inhalte untergliedert und mit verschiedenen Informationen gefüllt werden:

  • Anzahl Prüf- / Suchbuffet
  • ... todo


Intern existieren via Kibana Auswertungsfunktionen. In Arbeit ist eine öffentlich einsehbare tabellarische Metrik des Füllstands des HUB, die in einer 2. späteren Entwicklungsstufe für Nutzende umschaltbar und filterbar gestaltet werden soll:


Quelle AQuelle B...Quelle ZUmschalter / Filter (2. Stufe)
Beschreibendes



Spalten:

  • Quelle
  • Fachportal (Fachredaktion)
  • Buffets (Prüfbuffet, Suchbuffet, Redaktionsbuffet, KI-Buffet)
  • unverwendet / verwendet

Weitere Filter:

  • nur redaktionell geprüft
  • nur Crawler
  • nur Webformularvorschläge

Zellen-Inhalte

  • Anzahl Prüfbuffet vs. Suchbuffet vs. Redaktionsbuffet
  • Metadaten-Ausfüllstand
  • Metadaten-Richtigkeit (was sagt die KI zu von Quellen gelieferten Metadaten)
Cover



Kurztitel



Voller Titel



Beschreibung



Status



URL



Sprache



Typisierung



Typ des Inhalts



Dateiformat (Mimetype)



Dateiformat (Editorwahl)



Bildungsstufe



...etc.







4.2. Konzepte / Entscheidungen




Info
titlewer macht was

Hier schreibt Robert Konzepte / Alternativen, Entscheidungen werden dokumentiert. Anne ergänzt später ggf. UX-Entwürfe.

 Herangehensweise:

  • Aufbrechen der derzeitig mangelhaft dokumentierten und getesteten MetaQS Lösung anhand der Anforderung "Qualitätsmatrix"
  • Aufsetzen einer Entwicklungs-Umgebung zum Testen von MetaQS, bspw. in Bezug auf experimentelle Features, ohne die Produktion dabei einzuschränken
  • Entwicklungsumgebung: erledigt, es existiert eine dev Umgebung, in der die Daten aus der Staging Elasticsearch angezeigt werden
  • MetaQS Lösung aufbrechen: In Arbeit, der Umzug auf Produktion muss noch erfolgen



4.3 Dokumentation neuer Lösungsbausteine




Info
titlewer macht was

...hier schreibt Robert, wenn er neue Bausteine gebaut hat. Wenn es in die Lösung eingeht wird der Abschnitt zu "3. Aktueller Stand der WLO-Lösung" übernommen.

 ...

Entwicklungs API: http://c106-168.cloud.gwdg.de/docs
Entwicklungs Dokumentation: https://confluence.edu-sharing.net/confluence/x/CgASBQ

  • Qualitätsmatrix in MetaQS
  • Pflichtmetadaten als Kacheln/Widgets in MetaQS, bisher standen dort fünf ausgewählte Metadaten, von denen mindestens eines kein Pflichtmetadatum war



5. Mitschriften Abstimmungen


21. April 2022 API-Abstimmung

Robert, Torsten

  1. API Abfrage auch mit Filterfeld, e.g., statt replicationsource auch was anderes
  2. Feldnamen ähnlich zu Elasticsearch
  3. API Rückgabe als Liste von Quellen

Zugriff auf SCM für Frontend, um Widget für Qualitätsmatrix zu entwickeln.


Überlegungen zur Perisistierung der Zeitreihe, e.g., Ort der Datenbank und Granularität der Daten - weitere Abstimmung ist hier nötig.

12. April 2022 Zielabstimmung, Zwischenstand


Robert, Hupf, Torsten, (Anne)

  1. Anne und Robert besprachen, dass auf dieser Confluence-Seite Konzepte geschrieben werden
  2. Robert zeigte den Einarbeitungsstand in Theos Lösung

Beschlüsse

Definieren fester Abfragen, was im Frontend dargestellt werden soll.

  • Robert setzt diese Abfragen in MetaQS um.
  • Dafür erhält Robert einen Abfragestring zu edu-sharing, diese sind derzeit nicht user-abhängig; Abfragen via query-wrapper, weiterer Filter
    • Dummy von Torsten
  • Erhaltene Daten als Zeitreihe persistieren
    • wo? MongoDB? PostrgeSQL "immer da"
    • vorerst Daten im MetaQS halten


Roberts Mitschrift zu ersten Zielen:

Zweites Ziel könnte sein

  • v.a. Frontend-Schwerpunkt
  • weitere Filter auswählbar


Vorteile Kibana

  • schnell, low-code mäßig üben/ausprobieren
    • nachträglich queries in Code abbilden
  • Managed service, MetaQS muss gewartet werden


Nachteile Kibana

  • Datenmodell in Kibana muss abgebildet sein
    • u.a. sind die Buffets nicht abgebildet, schwierig abbildbar
  • Tool derzeit nicht da
  • "gefährlich" auf die Redakteur*Innen loszulassen
    • ganzer Datenbestand
    • potenziell löschen möglich
  • Mehraufwand bei der Pflege, e.g., Elasticsearch Config muss abgebildet werden
    • Doppelungen, u.a., bei queries für Kibana und edu-sharing Frontend

  • Datensnapshots wohl schwierig, Historie zeigen
  • gewisse Rückgaben von MetaQS lassen sich nicht mit Kibana abbilden, e.g. Auflistung der Materialien (question)


Übertragung auf die Länder

  • leicht andere Metadaten
  • wie machen wir es konfigurierbar für das Standardprodukt


Zweigleisig

  • wo Kibana, wo MetaQS?