Es war zwar ein Freitag der 13. aber wir haben es trotzdem gewagt und das 1.5er Release von Stud.IP veröffentlicht. Herunterladen kann man es – wie immer – von den SourceForge-Servern. Eine Liste der Neuerungen findet sich in der History. Es hat sich diesmal zwar nicht soooviel sichtbares geändert aber dafür wurde unter der Motorhaube mal kräftig aufgeräumt und viele Dinge neu sortiert. Das bringt mehr Übersichtlichkeit auf dem Server und erleichtert die Arbeit der Programmierer. Außerdem kann man Stud.IP jetzt auch auf einem Server mit PHP5 (passend zu der 5 in der Releasenummer ) betreiben.

Bei anderen gilt: Schnittstellen gut abdecken, sonst trocknet das Produkt aus. Nicht so bei Stud.IP.

Ein großes Thema beim Entwicklertreffen 2007 in Halle waren Schnittstellen im allgemeinen und die Frage nach dem Datenfluss zwischen HIS-Systemen und Stud.IP in besonderen. Gleich zwei Workshops waren dafür reserviert und das Interesse groß.

Bereits erfolgreiche Lösungen

Im ersten Teil hat Marco Bohnsack von data-quest Lösungen vorgestellt, die sich bereits jetzt im Praxiseinsatz bewähren. Die Unis Hannover und Halle sowie die TU Clausthal importieren Veranstaltungsdaten aus HIS-LSF, beschreiten dabei allerdings wenig standardisierte Wege, die im Einzelfall prima funktionieren, aber nicht ohne weiteres verallgemeinerbar sind. Die FH Osnabrück, die Uni Bremen und die Uni Oldenburg importieren ihre Veranstaltungsdaten aus selbst entwickelten Planungssystemen. Die Unis Halle, Passau und Osnabrück nutzen Stud.IP direkt als Primärsystem für alle Veranstaltungsdaten. Michael Schaarschmidt von der Uni Halle stellte in einer vielbeachteten Präsentation eine sehr ausgereift wirkende Stud.IP-Erweiterung für den Umgang mit Studienmodulen vor, die zwar Basisdaten aus einem anderen System importiert, aber Stud.IP zu einem weiterhin autark nutzbaren System zur Verwaltung und Organisation von Veranstaltungen und jetzt auch Modulen ausbaut. An vielen Hochschulen, die Stud.IP erfolgreich einsetzen, stehen Entscheidungen darüber an, wie und mit welchen Systemen zukünftig Veranstaltungsdaten verwaltet werden sollen. Ein einheitlicher Trend ist nicht erkennbar, so dass sich für das Stud.IP-Projekt die Frage stellt: Wie halten wir es mit den Schnittstellen, so dass Stud.IP sowohl als Primär- als auch als Sekundärsystem für Veranstaltungs- und andere Daten sinnvoll eingesetzt werden kann?

Der weitere Weg: Eine allgemeine Schnittstellendefinition

Diese Frage wurde im zweiten Teil des Workshops diskutiert und das Ergebnis: In den nächsten Wochen werden die Anforderungen zusammengetragen und ein allgemeiner Rahmen für Import-, Export- und Synchronisationsschnittstellen für verschiedenste Daten definiert. Ziel ist ein einheitliches Datenformat, das über verschiedene Kanälen wie Webservices oder Batchschnittstellen genutzt werden kann, um Daten mittels geeigneter Abbildungen mit anderen Systemen zu synchronisieren. Eine solche Abbildung wird z.B. zur IMS Enterprice Specification definiert, aber auch zu HIS-Datenstrukturen und -Schnittstellen, soweit sie spezifiziert sind. Auch andere Szenarien sind wichtig: Mehrere Stud.IP-Installationen miteinander kommunizieren zu lassen oder erweiterte Backupmöglichkeiten für einzelne Stud.IP-Objekte wie z.B. Veranstaltungen zu schaffen. Bereits exisitierende Lösungen werden soweit möglich integriert und die Ideen konfligieren nicht mit anderen Bestrebungen, das Campusmanagement zu vereinfachen. Die konkrete Umsetzung kann bald beginnen: Ressourcen für die Entwicklung stehen zum Teil bereits zur Verfügung, zum Teil könnten sie über ein Konsortialmodell aufgebracht werden, das bei der Entwicklung der ILIAS-Lernmodul-Schnittstelle von data-quest bereits erfolgreich war.

Beteiligung erwünscht

Die Planungsphase ist angelaufen. Erste Anforderungen sind formuliert, gleichzeitig arbeiten wir an einem XML-Datenmodell, dass die Stud.IP-Datenbankinhalte umfassend, flexibel und sicher nach außen darstellen kann. Wie immer bei Stud.IP passiert das öffentlich, und zwar auf dem Developer-Server, aus historischen Gründen in der Veranstaltung »(Studien)Modularisierung im Rahmen von Stud.IP und HIS« . Alle Interessierten sind aufgerufen, sich so früh wie möglich einzubringen: Mit Anforderungen, Vorschlägen, Verbesserungsideen und Kritik. Denn Stud.IP ist ein Open-Source-Projekt und das bedeutet bei uns: Wer sich engagiert und dabei bereit ist, über den eigenen Tellerrand hinauszuschauen, der bestimmt mit, wie es weitergeht.

Wenn die Schnittstelle fertig konzipiert oder gar programmiert ist, ist die Welt allerdings noch nicht gerettet. Denn die Anbindung kann nur an Systeme gelingen, die Daten in verwertbarer Form exportieren oder importieren mögen. Und daran, finden wir, hapert es bei einigen.

Quelle: www.aboutpixel.de / Idefix

Das Recht auf freie Meinungsäußerung hat den Nachteil, dass mitunter auch Widersprüchliches, Falsches, Dummes oder gar Beleidigendes oder Bösartiges gesagt wird. Wenn wir aber alles in allem nehmen, sind wir doch eher bereit, uns damit abzufinden, als dieses Recht abzuschaffen. Mehr noch: Wir verteidigen es als wichtigtige Errungenschaft und erziehen unsere Kinder dazu, sich in einer Welt vielfältiger Meinungen zurechtzufinden.

Die freie Meinungsäußerung in Stud.IP findet ihren Platz an vielen Stellen: In Foren und Wikis, im Chat und auf den persönlichen Homepages. Unter dem Schlagwort »Studierende ernst nehmen« hat sich bereits der zweite Satz der Stud.IP-Philosophie mit dieser Art von Freiheit befasst. Weitergesponnen verlangt der rote Faden durch Stud.IP – nämlich jedem Nutzer selbst Freiheit zu lassen und jeden Nutzer selbst in die Verantwortung zu nehmen – nach Freiheit und Selbstverantwortung auch für andere Informationen, die nicht individuelle Meinung sind, sondern eher offiziellen Charakter haben.

Die Wikipedia macht es vor: Seriöse und verlässliche Informationen können auch dann entstehen, wenn jeder, der glaubt zu wissen, auf reden darf und Kontrolle eher von unten statt von oben ausgeübt wird. Eric Raymonds The Cathedral and the Bazaar argumentiert für die Softwareentwicklung, dass viele kleine Standbetreiber etwas Verlässlicheres zustande bringen können, als ein über allem thronender Baumeister. Für Informationen in Stud.IP heißt das: Lasst diejenigen Veranstaltungsdaten, Sprechstundentermine und akademische Titel eintragen, die es am besten wissen, also Dozenten und Sekretariate anstelle zentral bestellter Administratoren. Auch auf die Gefahr hin, dass mitunter Uneinheitliches, Halboffizielles oder Anmaßendes erscheint. Die Administratoren kann es trotzdem geben, und sie können eingreifen wenn nötig – aber sie sind nicht das Nadelöhr, durch die jede Information vor ihrer Veröffentlichung (und das hießt dann oft: kurz nach dem Verfallsdatum) gehen muss. Und so heißt es im fünften Punkt der Stud.IP-Philosophie:

5. Dezentrale Erfassung und Pflege von Daten.

Nur wenn Informationen auch dort verändert werden, wo sie anfallen, kann ein aktuelles und zuverlässiges Informationssystem entstehen. Die Erfassung und Pflege von Daten erfolgt daher so dezentral wie möglich und so zentral wie nötig: jede NutzerIn pflegt ihre persönlichen Daten, Lehrende betreuen ihre Veranstaltungen, FachbereichsadministratorInnen verwalten die Mitarbeiterlisten ihrer Einrichtungen, eine RaumadministratorIn vergibt von allen genutzte Räume. Zentrale Eingriffe und Beschränkungen durch AdministratorInnen geschehen transparent, d.h. Nutzer werden über Veränderungen ihrer Daten informiert und können jederzeit einsehen, was über sie gespeichert ist.

Wenn ein solches Modell eingeführt wird, sind Ängste da: Dass jemand für Fehler verantwortlich gemacht wird, die nicht in seinem Einflussbereich liegen. Dass renitente Professoren versuchen, Absprachen und Regelungen zu umgehen. Dass Studierende sich Titel anmaßen und Verwirrung stiften. An der Universität Osnabrück beginnt gerade das achte Semester nach der Umstellung vom Kathedralen- auf das Basar-Modell. Das Ergebnis: Ja, es gibt Fehler, es gibt Ungereimtheiten, es gibt Einzelne, die sich freuen, Extrawürste nicht nur braten, sondern auch an den Mann bringen zu dürfen. Aber es gibt auch: Frühere Ungereimtheiten, die plötzlich auffallen, weil Informationen für jeden sichtbar sind. Oder das Gefühl von eigener Verantwortung, weil die Studierenden jetzt beim Dozenten selbst nachfragen, warum die Informationen nicht da sind, wo sie sein sollten. Und: Fehler und Unstimmiges gab es früher auch, denn die verlässliche, immeraktuelle und konsensfindende zentrale Verwaltung von Daten kostet viel mehr, als sich eine Universität leisten kann oder sollte.

Dieser Beitrag ist eine Fortsetzung zu: #4 Orientierung an den Strukturen deutscher Hochschulen

Es sind ja immer die gleichen Fragen, die an den Support-Hotlines auflaufen. Eine der beliebtesten: »Wann fängt eigentlich das Semester wieder an?« Oder, in der selbstverständlich viel wichtigeren Form: »Wann sind endlich Ferien?«

Freilich ließe sich diese Information den Terminlisten und Ablaufplänen jeder Lehrveranstaltung entnehmen, aber dort wird sie offensichtlich nicht gesucht. An der Uni Osnabrück haben wir einen kleinen Schritt unternommen, die Semestertermine sichtbarer zu machen. Alle Studierenden sind – solange sie sich nicht austragen – im Feedbackforum eingetragen. Also haben wir dort für den Beginn und das Ende der Vorlesungszeit ganztägige Termine angelegt. Und schon hat jeder für den 10. April 2007 groß in seinem persönlichen Terminkalender stehen: »Beginn der Lehrveranstaltungen«. Und, für alle Uni-Osnabrücker schonmal zum Vorfreuen, am 14. Juli 2007: »Ende der Lehrveranstaltungen«