"Primärdaten als Grundlagen für Veröffentlichungen sollen auf haltbaren und gesicherten Trägern in der Institution, wo sie entstanden sind, für zehn Jahre aufbewahrt werden."
Empfehlungen zur gesicherten Aufbewahrung und Bereitstellung digitaler Forschungsprimärdaten, DFG: Ausschuss für Wissenschaftliche Bibliotheken und Informationssysteme, Unterausschuss für Informationsmanagement, S. 2, Januar 2009.

Portierung von Webseiten: Was uns die Versionsumstellung eines CMS zur Nachhaltigkeit von Ressourcen sagt

Details
Erstellt am Mittwoch, 09. November 2011 11:28
Geschrieben von Thorsten Trippel

In den letzten Wochen haben wir es endlich geschafft: die NaLiDa-Webseiten wurden auf die neue Version eines Content-Management-Systems umgestellt, das eine veränderte Struktur hat und das Mehrsprachigkeit und Lokalisierung erlaubt. Gleichzeitig haben wir auch eine erste englische Version erstellt. Da ein zentrales Anliegen in unserem Projekt darin besteht, Nachhaltigkeit zu gewährleisten, gab es eine Hand voll Fragen, die zu klären waren. Einige werden hier kurz angerissen:

Erhalt der Inhalte der alten Präsenz

Ein wesentlicher Bestandteil von Nachhaltigkeitsbestrebungen ist es immer, den Inhalt einer Ressource langfristig zu sichern. Dies bedeutet insbesondere, dass neue Versionen und neue Infrastrukturen zu keinem Informationsverlust führen dürfen. Normalerweise würde man ja davon ausgehen, dass man bei neuen Versionen von Infrastruktur-Software, z.B. einer neuen Version eines Content-Management-Systems, keine Probleme hat, die alten Daten zu importieren. Diese Annahme ist aber nicht richtig.

Bei der Umstellung vom CMS (Joomla 1.5 auf 1.7) hat sich die zugrundeliegende Struktur massiv geändert, was für unsere Zwecke große Vorteile hat. Artikel waren zuvor über zwei verschiedene Hierarchieebenen geordnet worden, in der neuen Version wurde dies verändert, im Prinzip kann man nun beliebige Hierarchien verwenden. Also musste eine Abbildung der alten Hierarchien auf die neuen durchgeführt werden.

Eine zusätzliche Herausforderung stellte auch die Abbildung auf ein mehrsprachiges System dar, was sowohl Fragen der Lokalisierung als auch zur Verlinkung und zur Struktur der URLs beinhaltete.

Bei besonders großen Präsenzen hätte man hier sicher die Artikel gezielt über SQL-Operationen von einem System in das andere erreichen können. Wir entschieden uns aber für die "Quick and Dirty"-Methode: da wir nur eine kleine dreistellige Anzahl von Seiten hatten, erschien es uns einfacher, die alten Artikel in das parallel laufende neue System zu kopieren. So konnten wir uns einen Testzyklus sparen, ob wirklich die Artikel syntaktisch richtig in das neues System aufgenommen wurden. Außerdem war durch die neue Strukturierung der Hierarchien ohnehin eine manuelle Nachbearbeitung notwendig, die im Wesentlichen darin bestand, jeden Artikel zu öffnen und der neuen Struktur zuzuweisen. Es erschien als vertretbarer Aufwand, dies manuell zu machen, für tausende Seiten wäre dies kein gangbarer Weg. Allerdings muss man dafür sorgen, dass man überprüft, ob man wirklich alle Artikel erreicht hat. Dazu kann man aber auch Verfahren verwenden, um zu prüfen, ob alte URLs richtig auf die neuen Artikel zeigen.

Wenn wir das auf andere Ressourcen übertragen, bedeutet dies, dass man manchmal heuristisch an die Portierung herangehen muss. Wenn man wirklich eine kleine, abgeschlossene Dokumentmenge hat, dann kann es vorteilhaft sein, die Portierung manuell durchzuführen. Kleine Tests und klare Abläufe müssen dann aber dafür sorgen, dass keine zusätzlichen Fehler eingebaut werden.

Content-Management-Systeme verfügen meist über die Fähigkeit, interne Parameterdarstellungen von URLs durch "schöne" Links zu ersetzen: Da ein CMS meist ein Programm ist, sind individuelle Seitenaufrufe normalerweise Aufrufe des Programms mit bestimmten Parametern, in URLs durch Attribut-Wert-Paare angegeben (also so etwas wie index.php?option=com_content&view=article&id=60&lang=de). Als Ergebnis erhält man dann eher eine Adresse wie "willkommen.html". Unterschiedliche Versionen von Software haben dabei allerdings verschiedene Verfahren, d.h. wenn man einmal solche Adressen verwendet, müssen die bei den nächsten Versionen nicht genau so aussehen.

Wie man mit alten URLs umgeht, wird an anderer Stelle beschrieben, aber es soll darauf hingewiesen werden, dass dieses Problem existiert. Dabei sind diese "schönen" Adressen aus zwei Gründen interessant: erstens könnten Nutzer sie sich besser merken und zweitens werden sie von Suchmaschinen sinnvoller interpretiert und damit leichter gefunden.

Für Ressourcen bedeutet das, dass auch sie eine Möglichkeit bieten sollten, über Suchmaschinen gefunden zu werden und dazu "schöne" Bezeichnungen zu haben. Dies geschieht bei uns z.B. dadurch, dass wir CMDI-Metadaten auf HTML-Views abbilden, die dann über Suchmaschinen abgefragt werden können. Auch wenn dies nicht der primäre Zugang zu den Ressourcen darstellen muss (und natürlich nicht dafür sorgt, dass Ressourcen, die nicht öffentlich sind, öffentlich werden), ist es ein Mehrwert für die Suchbarkeit.

Umgang mit alten URLs

Bei der Umstellung auf das neue CMS veränderten sich die Muster der Suchmaschinen-Freundlichen(SEF)-URLs, zum einen, weil der Sprachcode in der URL auftauchte, zum anderen, weil die internen Identifikatoren sich geändert haben. Wie können also die alten Adressen noch verwendet werden, die die Suchmaschinen schon kennen oder auf die von anderen Seiten verwiesen wurde?

Unser Verfahren dazu war einfach: Wir erstellten eine Liste aller alten Adressen und verglichen Sie mit den neuen Adressen und generierten daraus Umleitungsanweisungen für den Webserver, sogenannte "permanent Redirect" Anweisungen (oder beim Apache ein Status 301). Suchmaschinen und andere Webseiten erhalten beim Aufruf der alten URL dazu die Information, dass die Seite umgezogen ist, daraufhin können die Links angepasst werden.

Für Ressourcen setzt man normalerweise keine URLs ein, da sie zu oft verändert werden. Stattdessen verwendet man persistente Identifikatoren (PID): jede Ressource bekommt einen (oder sogar mehre, aber das ist ein anderes Thema) eindeutigen und dauerhaften Identifikator, der verlässlich registriert wird. Der Registrar erhält dann zu jeder PID die URI (meist sogar eine URL) für die Ressource. Wenn sich die URI ändert, braucht also nur bei dem Registrar die Adresse angepasst werden und schon liefert der die neue Adresse aus, der Benutzer verweist also auf die PID, nicht auf die "echte" Adresse.

Alles Übersetzen oder parallele Präsenzen?

Wenn man eine multilinguale Umgebung einsetzten möchte, dann ist eine der schwierigen Fragen: Soll man alle Artikel in mehreren Sprachen bereitstellen? Wenn man dies täte, ist ein Mehrfaches der Arbeit zur Erstellung von Artikeln notwendig, abgesehen davon, dass man von Autoren die entsprechenden Kompetenzen oder qualifizierte Übersetzer bereitstellen muss. Wenn man das aber nicht macht, dann fehlen Informationen, die man für eine Sprache bereitstellt, für die andere Sprache.

Für die Webpräsenz des NaLiDa-Projekt haben wir uns für einen hybriden Ansatz entschieden: Die großen Strukturen der Seite werden zumindest in Deutsch und Englisch erstellt, bei individuellen Artikel, wie etwa diesem Blog, gibt es nicht diese Anforderung. Natürlich gibt es die Möglichkeit Übersetzungen bereit zu stellen.

Für den Bereich der Sprachressourcen ist die Frage der Mehrsprachigkeit in Hinblick auf die Beschreibung - die Metadaten - besonders relevant. Die Frage ist ja, ob bestimmte Informationen in mehreren Sprachen vorliegen können oder sollten. Aber auch hier wird normalerweise hybrid verfahren: Ein Projekt beschreibt seine Ressourcen einheitlich in einer Sprache, meist in der Lokalsprache oder Englisch, und zusätzlich in weiteren Sprachen. Wir empfehlen aus Internationalisierungsgründen, die Metadaten auf Englisch anzubieten und zusätzlich auf Deutsch. Dies bedeutet zwar eine gewisse Redundanz, aber die Erfahrung zeigt, dass die Kompetenz in beiden Sprachen in unseren Projektkontexten meist gegeben ist und sich der Aufwand für die zweite Sprache in Grenzen hält.

Silent Relaunch oder laute Bekanntmachungen?

Soll man bei der Verfügbarkeit und Erneuerung von Webseiten laut trommeln oder nicht? Daran scheiden sich die Geister, auf der einen Seite will man jegliche Aufmerksamkeit erzielen, auf der anderen Seite kann man bestimmte Tests, z.B. ob die Serverkonfiguration funktioniert, mit verträglichem Aufwand manchmal nur an einem laufenden System testen.

Wir haben bei unserem Relaunch daher die "leise" Lösung verwendet, ohne große Ankündigung haben wir die neuen Versionen mit dem neuen Layout und der Struktur öffentlich getestet und als alles zufriedenstellend lief, haben wir keine Rückumstellung vorgenommen, um dann ein Launch-Event zu organisieren. Außerdem ist die Frage: Was ist uns wichtiger, die Verfügbarkeit über einen langen Zeitraum oder ein kurzfristiger Anstieg von Besucherzahlen? Wir haben uns für die Verfügbarkeit entschieden.

Für Forschungsressourcen gilt ähnliches: gut getestete, fertige Ressourcen, über die es z.B. schon Veröffentlichungen gibt, können öffentlichkeitswirksam angekündigt werden. Aber manchmal will man nicht so ein großes Aufhebens machen, sondern erst einmal beobachten, wie groß der interessierte Personenkreis in Wirklichkeit ist, gerade bei großen Ressourcen hätten massive Zahlen von Nutzern manchmal auch erhebliche technische Auswirkungen. Gerade da ein vorheriger großer Test nicht ohne erheblichen Aufwand möglich ist, ist häufig ein "silent Launch" eine gute Alternative für Tests im öffentlichen Raum.

Zeitbedarf für eine Portierung

Es ist eine Binsenweisheit: Es dauert immer länger, als man meint. Zwar kann man einen Zeitplan erstellen, aber die Portierung von Webseiten unter der Verwendung eines neuen CMS ist ohne Evaluation schlecht abzuschätzen.

Wir haben, nachdem wir das neue Layout erstellt hatten und eine Probeinstallation durchgeführt haben, zunächst mit einer kleinen Anzahl von Seiten getestet, wie aufwendig unsere Portierungsstrategie war. Darauf basierend haben wir abschätzen können, wieviel Zeit und Personal wir brauchten, um die Seiten umzustellen. Dabei konnten wir den Aufwand für den Inhalt recht schnell sinnvoll abschätzen, aber die Installation und Konfiguration der Infrastruktur konnten wir nicht sinnvoll vorherbestimmen. Die einzige Möglichkeit, dies abzuschätzen, hätte darin bestanden, die Portierung durchzuführen. Daher haben wir diese Portierung nicht vorher abgeschätzt, sondern ein Drop-out formuliert: wenn die Portierung zu aufwendig geworden wäre, also über einen bestimmten Zeitaufwand gelegen hätte, hätten wir die Portierung abgebrochen.

Unabhängig davon hat die Portierung auf ein neues CMS für uns viele Vorteile gebracht, so dass wir uns für den erwarteten Aufwand entschieden haben. Das ist einer der Gründe, warum dann die Befüllung eines Blogs dann ein wenig hinten an steht.

Im Ressourcenbereich sehen wir das Problem der Portierung von Infrastrukturen daher ähnlich: die inhaltliche Portierung kann durch einfache Tests gut abgeschätzt werden, die Portierung der zugrundeliegenden Infrastruktur ist dagegen nur schwer zu beurteilen. Unabhängig davon gibt es aber Gründe, z.B. veränderte Technologien, Hardware oder Rahmenbedingungen, die eine Portierung auch bei hohem Aufwand als sinnvoll erscheinen lassen. Und wenn man mehr als eine solche Infrastruktur hat, wird der Aufwand leichter zu beurteilen. Die Portierung von Ressourcen erfordert daher die Bereithaltung eines Teams, dass die dafür erforderlichen Kompetenzen besitzt, ein weiterer Grund, für die Ressourcenverwaltung auf vertrauenswürdige Zentren zu setzen statt auf individuelle Datenhaltung innerhalb von kurzlebigen Projekten.

Zusammenfassung

So wie man hier das Ergebnis unserer Portierung von Webseiten von einem CMS in ein anderes sieht, so ist auch die Portierung von Ressourcen über längere Zeiträume aufwendig, aber manchmal notwendig. Man muss nicht jede neue Entwicklung mitgehen, aber verfolgen, ob es Gründe gibt, die Daten zu migrieren und die Infrastrukturen umzustellen. Und manchmal ist es einfach Zeit, Kompetenzen zu konzentrieren und neue Strukturen zu verwenden.