Kategorien
Dienste des ZIM Lehren und Lernen Moodle

eduGAIN‑Anbindung für Moodle – Jetzt auch für Österreich und die Schweiz

Was hat sich geändert?

Schon etwas länger, genau genommen seit Anfang des Jahres, steht eduGAIN (EDUcation Global Authentication INfrastructure) als ergänzender Authentifizierungs‑Provider im SAML‑Stack (Security Assertion Markup Language) des Moodle‑Systems der Bergischen Universität Wuppertal (BUW) zur Verfügung. Dadurch können Studierende, Lehrende und Mitarbeitende von teilnehmenden Hochschulen aus Österreich und der Schweiz zusätzlich zu unserem nationalen DFN‑AAI‑Verbund (Deutsches ForschungsNetz – Authentifizierungs- und Autorisierungs-Infrastruktur) auf das Lernmanagementsystem zugreifen.

Warum eduGAIN?

  • Inter‑institutionelle Zusammenarbeit – Viele aktuelle Forschungs‑ und Lehrprojekte erstrecken sich über Grenzen hinweg. Der Zugriff über eduGAIN erleichtert den Austausch von Lernmaterialien und Kursen mit Partner*innen aus Nachbarländern.
  • Einheitliche Benutzer‑Erfahrung – Nutzer*innen können sich mit den bereits bekannten Hochschul‑Credentials (z. B. Uni‑Login) einloggen, ohne ein separates Konto anlegen zu müssen.

Technische Umsetzung

  1. SP-Föderationserweiterung – Der Service Provider (SP) wurde in der eduGAIN Föderation registriert und ist nun für IDP´s aus Österreich und der Schweiz erreichbar.
  2. Attribute‑Mapping – Zusätzlich zu den bereits genutzten Attributen (z. B. eduPersonPrincipalName) wird das Attribut schacHomeOrganization berücksichtigt, um die Herkunftsinstitution eindeutig zu bestimmen.
  3. Der Service Provider (SP) unterstützt die R&S‑Entity‑Category. Das bedeutet, dass er automatisch von allen Identity Providern (IdPs) erreicht werden kann, die ebenfalls diese Entity‑Category unterstützen.

R&S Entity Category

Eine spezifische Entity Category, die von der Research and Scholarship (R&S) Initiative definiert wurde und unter anderem die Nutzung von SAML‑Attribute‑Release‑Policies regelt.

Wenn ein SP die R&S‑Entity‑Category implementiert, erkennt er automatisch IdPs, die dieselbe Kategorie unterstützen, und kann ohne zusätzliche Konfiguration mit ihnen kommunizieren. Umgekehrt können IdPs, die die R&S‑Kategorie anbieten, den SP problemlos ansprechen.

Was bedeutet das für Sie?

  • Für österreichische und schweizerische Nutzer*innen: Beim Login können Sie ebenfalls über den Button Verwenden Sie Ihr Nutzerkonto bei anderer Hochschule in der folgenden Maske nach Ihrer Universität oder Hochschule suchen. Nach Auswahl der jeweiligen Hochschule werden Sie wie gewohnt auf die Anmeldeseite Ihrer Uni weitergeleitet und gelangen nach erfolgreicher Authentifizierung zum Moodle‑Dashboard.
  • Für alle anderen BUW‑Nutzer*innen: Die bisherige Anmeldung bleibt unverändert.

Für Dozierende gilt weiterhin der Hinweis: Externe Nutzer*innen können sich nicht selbst in Kurse einschreiben. Auch dann nicht, wenn dies ohne Passwort möglich wäre. Sie müssen von den Lehrenden durch die manuelle Einschreibung als Teilnehmer*in zum Kurs hinzugefügt werden.

Fragen oder technische Unterstützung?

Kontaktieren Sie uns gern unter e-learning@uni-wuppertal.de. Wir freuen uns auf Ihr Feedback und wünschen viel Erfolg beim grenzüberschreitenden Lernen!

Kategorien
Lehren und Lernen Moodle

Gerechte Verteilung – Moodle-Aktivität ermöglicht (Gruppen-/Themen-) Wahl basierend auf Präferenzen

Wie können Studierende in einem Moodle-Kurs ein Thema auswählen oder sich einer Gruppe zuordnen?

Das geht zum Beispiel über die Aktivität Abstimmung oder Gruppenwahl. Allerdings ist es mit den beiden Methoden nur möglich, das sogenannte “Windhundverfahren” zu nutzen. Wer zuerst klickt, erhält den Platz in der gewünschten Gruppe oder das bevorzugte Thema. Obwohl die Abstimmung bzw. Gruppenwahl aufgrund ihrer einfachen Handhabung beliebt ist, benachteiligt sie jene, die zum Startzeitpunkt nicht online sein können.

Mit dem Plugin “Gerechte Verteilung”, das wir neu in unserem Moodle Learning Management System integriert haben, lassen sich nun komplexere Aufteilungen realisieren. Das Plugin berücksichtigt die individuellen Präferenzen der Studierenden weitaus besser, indem Lehrende verschiedene Abstimmungsstrategien anbieten können.

Ob Akzeptieren/Ablehnen, Likert-Skala, Punktesystem, Rangfolge oder einfaches Ankreuzen – diese verschiedenen Modi füttern den Verteilungsalgorithmus. Der Prozess lässt sich zeitlich über ein Start- und Enddatum steuern, und auch die gewohnten Einstellungen für Voraussetzungen sowie den Aktivitätsabschluss stehen zur Verfügung.

Ansicht in Moodle, Auswahl der Aktivitäten. Das Plugin "Gerechte Verteilung" in hervorgehoben. Dieser Hinweis soll den Lehrenden die Auffindbarkeit der neuen Aktivität erleichtern.

Sie können in Ihrem Moodle Kurs die “Gerechte Verteilung” nutzen, wenn Sie bearbeiten einschalten und die oben abgebildete Aktivität aufrufen.

In den Moodle Docs ist eine Kurzbeschreibung (eng.) veröffentlicht, detaillierter ist die Anleitung der RWTH Aachen. Eine Ergänzung in unserer Moodle-Hilfe folgt.

Kategorien
Lehren und Lernen Moodle

Bist du da? – Anwesenheitserfassung mit Moodle

Der Wunsch zur Anwesenheitserfassung von Kursteilnehmer*innen direkt in Moodle wurde an uns gerichtet. Insbesondere bei Arbeiten in Laboren soll dieses Plugin genutzt werden, denn neben den (klassischen) Vorlesungen gibt es Veranstaltungen mit Anwesenheitspflicht.

Es gibt zu diesem Moodle-Plugin eine Videoanleitung von Captain Moodle bei YouTube, die praxisorientiert und sehr anschaulich verschiedene Einsatzmöglichkeiten aufzeigt.

Darstellung der Auswahl Anwesenheitserfassung in den Moodleaktivitäten

Die Abbildung zeigt die Auswahl der Moodle Aktivitäten mit dem neuen Anwesenheits-Plugin.

Das Plugin bietet verschiedene Auswahlmöglichkeiten. Es können einzelne Termine oder sich wiederholende Termine eingestellt werden. Es kann so konfiguriert werden, dass die Anwesenheit entweder durch Lehrende oder durch die Studierenden selbst erfasst werden kann. Dazu kann das Plugin einen QR-Code generieren, welcher von den Studierenden gescannt werden kann.

Einen Link zu einer detaillierten Anleitung finden Sie auch in unserer Moodle-Hilfe.

Kategorien
Programmierung Tipps & Tricks

Das Telefonbuch der BUW – neue vCard‑Funktion und verbesserte Suche

Das ZIM macht das Telefonbuch der Bergischen Universität noch nutzerfreundlicher. Seit einiger Zeit können alle Einträge als vCard heruntergeladen werden und die Suchfunktion läuft über die BUW‑API, wodurch eine verbesserte Suche möglich ist.


Was ist eine vCard?

Eine vCard ist ein standardisiertes digitales Visitenkarten‑Format (Dateiendung .vcf). Sie fasst die wichtigsten Kontaktdaten – Namen, Position, E‑Mail, Telefon, Web‑Link usw. – in einer einzigen Datei zusammen. Mit einem Klick lässt sich die vCard in jedes gängige Adressbuch (Outlook, Gmail, das Smartphone‑Kontakte‑App …) importieren – kein mühsames Übertragen von Daten mehr.

Unterstützte Felder im BUW‑Telefonbuch

Beim Export wird die vCard nach dem nachfolgenden Schema aufgebaut:

BEGIN:VCARD
VERSION:3.0
FN: <-- Vollständiger Name
N: <-- Nachname;Vorname;weitere Vornamen;Präfix;Suffix
ORG: <-- Organisation / Abteilung
EMAIL;TYPE=INTERNET,WORK: <-- E‑Mail-Adresse
TEL;TYPE=WORK: <-- Telefon
URL: <-- Persönliche oder institutionelle Webseite
END:VCARD

Beispiel‑vCard – Testdaten

Um zu zeigen, wie das Ergebnis aussieht, haben wir eine fiktive vCard einer klar erkennbaren Persönlichkeit aus der Informatik erstellt (hier: Alan Turing – natürlich nur als Test‑Datensatz). Alle Angaben sind rein illustrativ.

BEGIN:VCARD
VERSION:3.0
FN:Alan Mathison Turing
N:Turing;Alan;Mathison;;
ORG:University of Cambridge;Department of Computer Science;
EMAIL;TYPE=INTERNET,WORK:alan.turing@cam.ac.uk
TEL;TYPE=WORK:+44 1223 337000
URL:http://www.example.com/alan-turing
END:VCARD

Hinweis: Beim wirklichen Einsatz werden natürlich die tatsächlichen Kontaktdaten der jeweiligen Uni‑Mitarbeitenden bzw. Einrichtungen eingebettet – nicht die oben gezeigten Testdaten.

Verbesserte Suche über die BUW‑API

Die interne Suche des Telefonbuchs nutzt jetzt die BUW‑API:

https://zim.uni-wuppertal.de/de/unsere-dienste/buw-api

Durch die Anbindung an die API werden Anfragen direkt weitergeleitet. Das Ergebnis:

  • Kürzere Antwortzeiten – Sie erhalten Treffer fast in Echtzeit.
  • Bessere Trefferqualität – Die API berücksichtigt aktuelle Änderungen sofort.
  • Verbesserte Suche nach Namen mit Umlauten – Die Suche berücksichtigt die verschiedene Schreibweise von Umlauten (oe bzw. ö) in Namen.

Uni-interne vs. weltweit verfügbare Einträge

Wir behalten weiterhin die klare Trennung zwischen:

KategorieWer kann sehen?
Interne EinträgeNur Mitglieder der BUW (Studierende, Mitarbeitende) aus dem Uni-Netz
Weltweit verfügbare EinträgeJeder Internetnutzer

Diese Aufteilung sorgt dafür, dass sensible Daten geschützt bleiben, während gleichzeitig wichtige öffentliche Kontakte schnell gefunden werden können.

Kategorien
Dienste des ZIM KI

Mehr Transparenz in genAI4BUW: Die Modellübersicht als Infozentrale

Für die meisten Nutzer*innen ist die Wahl des richtigen KI‑Modells in vielen Chatoberflächen ein Blindflug: Man klickt auf „Standard“, „schnell“ oder „präzise“ – was dahinter steckt, bleibt oft unklar.

genAI4BUW verfügt über ein Feature um Infos anzuzeigen, die sonst verborgen bleiben: eine detaillierte Modellübersicht. Hier lassen sich Fähigkeiten, Grenzen und Betriebsbedingungen der Modelle auf einen Blick vergleichen.

Die Startseite für alle Modelle

Im Zentrum steht der Titel „Modellübersicht“, darunter drei Reiter:

  • Text
  • Bild
  • Embedding

Im obigen Screenshot ist der Tab „Text“ aktiv – hier finden sich alle textbasierten Chatmodelle. Der Aufbau ist immer gleich: Die Bild- und Embedding‑Modelle werden nach demselben Schema dargestellt.

Rechts oben sitzt ein Button „Glossar“ – ein dezenter, aber wichtiger Hinweis: Wer Begriffe wie „Temperature“, „TopP“ oder „Presence Penalty“ nicht aus dem Effeff kennt, kann sie direkt in der Oberfläche nachschlagen.

Karten statt Dropdown: Wie die Modelle dargestellt werden

Jedes Modell wird als eigene Karte dargestellt, mit einem farbigen Streifen links, der die Modellfamilie markiert. Dies sind derzeit (Stand April 2026):

  • OpenAI GPT (OSS 12B)
  • Mistral (Small 4 119B)
  • GPT 5.1
  • GPT 5‑mini
  • GPT 5‑nano
  • GPT 4.1‑mini

Dieser Aufbau vermeidet kryptische Kürzel in einem Dropdown-Menü. Stattdessen erkennt man sofort:

  • zu welcher Familie ein Modell gehört,
  • ob es sich um ein Open‑Weight‑Modell (z.B. über „Inference NRW“) oder ein kommerzielles Cloud‑Modell (z.B. über Microsoft Azure) handelt,
  • und in welcher Region es betrieben wird – symbolisiert durch Flaggen bzw. Region-Icons.

Gerade für Einrichtungen, die Wert darauf legen müssen, wo und wie ihre Daten verarbeitet werden sind diese Informationen hilfreich.

Was pro Modell sichtbar ist

Die Karten sind standardisiert. Pro Modell sind u.a. folgende Details zu sehen:

1. Metadaten des Modells

  • Konkreter Modellname
    Etwa gpt-oss-12b-2 oder gpt-5.1.
  • Wissensstand / Stand des Trainings
    Beispielsweise „01.06.2024“. Damit ist klar: Auf welchen Zeitraum spielt das Modell sein Weltwissen zurück?
  • Betreiber
    Etwa Inference NRW oder Microsoft Azure. Für technische Nutzer ist das entscheidend, um Infrastruktur, Latenz und Datenschutz einzuordnen.
  • Region
    Über Flaggen bzw. Symbole visualisiert. So lässt sich erkennen, ob Anfragen im EU‑Kontext verarbeitet werden oder nicht.
  • Wenn ein API Zugriff verfügbar ist:
    Der API Model Name und der zu verwendende Endpunkt, diesen verwenden Entwickler um das Modell in der Programmierung gezielt anzusprechen. Zum Beispiel inferenz-gpt-oss-120b sowie v1/chat/completions

2. Tokenlimits und I/O‑Kapazität

Prominent platziert ist die Maximalanzahl an Tokens:

  • Input / Output, z.B. 400000 / 128000 Tokens.

In einer Zeit, in der Kontexte mit mehreren hundert Seiten keine Seltenheit mehr sind, ist das kein „Nice to have“, sondern Planungsgrundlage: Wer große Dokumente oder lange Chatverläufe einspeisen will, braucht genau diese Zahlen.

3. Fähigkeiten und Features

Unter „Reasoning“ bzw. in Form von Symbolen werden modellbezogene Fähigkeiten gekennzeichnet, z.B.:

  • erweiterte Reasoning‑Fähigkeiten (z.B. für komplexe Analyseaufgaben),
  • Unterstützung für Tool‑/Function Calling,
  • Streaming‑Unterstützung (Antwort kommt tokenweise).

Ob ein Feature unterstützt wird, ist jeweils klar durch ein Häkchen bzw. ein ausgegrautes Symbol erkennbar. So lässt sich etwa ein „voll ausgestattetes“ GPT‑5.1‑Modell schnell von einer leichteren Mini‑Variante unterscheiden.

4. Steuerparameter für die Ausgabe

Spannend ist, dass klassische Sampling‑Parameter direkt aufgelistet sind:

  • Temperature
  • TopP
  • Presence Penalty
  • Frequency Penalty

5. Zugangswege: Frontend vs. API

Am unteren Rand jeder Karte steht:

  • „Nutzung über: Frontend | API“

Damit ist sofort klar, ob ein Modell nur im Chat-Frontend zur Verfügung steht oder auch über eine Programmierschnittstelle. Für Entwickler bedeutet das: Die UI ist nicht Endpunkt, sondern Schaufenster für die zugrundeliegende Plattform.

Vergleich statt Rätselraten

Der eigentliche Mehrwert der Übersicht liegt in der direkten Vergleichbarkeit:

  • Wer viel Kontext braucht, sieht, dass z.B. GPT‑5.1 und GPT‑5‑mini ähnliche Tokenlimits bieten, während andere Modelle stärker begrenzt sein könnten.
  • Wer besonderen Wert auf On‑Prem‑ oder EU‑nahe Verarbeitung legt, erkennt die Modelle, die über „Inference NRW“ mit Länderflagge laufen – im Gegensatz zu Cloud‑Varianten via Azure.
  • Wer nur einfache, schnelle Antworten benötigt, kann gezielt zu „Mini“‑ oder „Nano“‑Modellen greifen, statt unnötig große und teure Modelle einzusetzen.

Fazit

Die hier gezeigte Modellübersicht holt etwas an die Oberfläche, das in vielen KI‑Chats im Verborgenen bleibt: die innere Vielfalt der Modelle, auf denen der Assistent tatsächlich läuft. Statt „eine KI“ gibt es hier eine klar kuratierte Palette von Modellen, jedes mit eigenem Profil, klaren Grenzen und dokumentierten Fähigkeiten.