DadA goes DadAWeb 3.0 - Projektrelaunch, der Dritte!

Vorbemerkung

Nachdem vier Jahre nach dem zweiten Projektrelaunch das Projekt DadA 3.0 immer noch nicht realisiert werden konnte, ist es Zeit für das Projekt Bilanz zu ziehen und nach alternativen Realisierungsmöglichkeiten zu suchen. Dies geschieht in einem neuen dritten Projektrelaunch.

Bilanz der bisherigen Entwicklung (2. Projekt-Relaunch)

hier die bisherigen Versuche zur Realisierung des Systems kurz dokumentieren.

Vorschlag für einen modifizierten Kriterien-Katalog

Kriterienkatalog für eine Lösung

Die angestrebte Lösung soll

1. analog zu den (offline gepflegten) alten DadA-Dokumentationen den Aufbau und die Verwaltung einer in frei definierbaren Datenfeldern differenzierten Onlinedatenbank ermöglichen. Für DadA-L entsprechen diese Datenfelder z.B. den RAK (Regeln der der Alphabetischen Katalogisierung). Angestrebt ist ein System von differenziert strukturierten und untereinander vernetzten Contents (s. Contentplanung für DadA 3.0). Durch einen Mausklick auf den Autorennamen „Bakunin, Michail“ soll beispielsweise zum einen die Biografie-Seite zu Bakunin als Suchergebnis angezeigt werden, aber es sollen auch gleichzeitig alle Schriften von oder über Bakunin im Suchergebnis aufgelistet werden.
2. zeitnah erfolgen und dies zu einem vertretbaren Arbeits- und finanziellen Aufwand. An dem Mediawiki-System haben Markus und ich monatelang herumexperimentiert, ohne dass wir dadurch irgendwie der Realisierung des DadAWeb 3.0 wesentlich näher gekommen wären. Die nun angestrebte Jetzt-Lösung sollte innerhalb von 6 Monaten eine funktionsfähige Demo-Site und innerhalb von 12 Monaten den Launch der Live-Site ermöglichen.
3. zukunftssicher sein. Also keine selbst programmierten oder exotischen Spezial-Systeme (wie z.B. das nur in Deutschland im Unibereich genutzte Literaturverwaltungsystem litw3), die in zehn Jahren evtl. nicht mehr existieren, sondern stabile und internationale bewährte CM-Systeme wie Mediawiki, Joomla! oder Wordpress (Drupal und TYPO3 klammere ich erst einmal mal aus, weil beide Systeme als nicht besonders anwenderfreundlich gelten, s. die Beiträge und Vergleichstest in Hintergrundwissen).
4. MODIFIZIERT: möglichst nur mit den eigenen Kernkomponenten der für die Lösung verwendeten Software betrieben werden können. Externe Erweiterungen bedeuten immer erhöhte Sicherheitsrisiken und sie werden auch nicht selten von einem auf den anderen Tag eingestellt. Bei den Kernkomponenten kann man davon ausgehen, dass sie auch künftig existieren und auch weiter entwickelt werden.
5. sowohl für den aktiven als auch den passiven User so anwenderfreundlich wie nur möglich sein. Mediawiki z.B. ist für die meisten Nutzer eindeutig zu „sperrig“. Wordpress und Joomla dagegen punkten in Sachen Benutzerfreundlichkeit.

Die fünf Hauptkriterien bei der Auswahl des geeigneten Systems sind:

1. frei definierbare und vernetzbare Contentstrukturen (CCK)
2. Usability/Anwenderfreundlichkeit
3. Zukunftsperspektiven
4. Datensicherheit
5. System-Leistung/-Performance

Contentplanung: Die vernetzten Contents der DadA 3.0

Das DadAWeb-Portal beinhaltet im Datenbankbereich der DadA folgende Dokumentationen (die grün markierten sind die bereits existierenden Dokumentationen):

1. DadA-A, Archivalien (zur Erfassung von Nachlässen und musealen Exponaten wie z.B. Briefwechsel, Fotos, Plakate, Aufkleber usw. usf.): NEU, s. als Beispiel die Datenbank der Archialien des IISG, Amsterdam
2. DadA-B, Biografien (Autoren/Personen): NEU, Biografische Infos (siehe als Grobmuster die aLibro-Autorenseiten, aber in der DadA natürlich strukturierter als bei aLibro)
3. DadA-E, Events, Veranstaltungen (erst einmal) mit dem Schwerpunkt auf Bildungs- und Kulturveranstaltungen.
4. DadA-F, Forschungs- und Publikationsvorhaben. Siehe die Rubrik "Forschungsprojekte" im gegenwärtigen DadAWeb.
5. DadA-L - a) Literatur in Büchern (Monografien): siehe DadA-Literaturdokumentation, DadA-Sekundärliteratur & aLibro-Titelsystematik (zu den geplanten Features der neuen DadA-L siehe die Demo des neuen DadA-L unter dem DadAWeb 3.0)
6. DadA-L - b) Literatur in Fachaufsätzen: siehe DadA-Literaturdokumentation, DadA-Sekundärliteratur
7. DadA-O: NEU, Organisationen (Infos zu großen Organisationen wie z.B. die FAU, aber auch zu kleinere informellen Vereinigungen, in denen sich Personen (1) vereinigt haben oder die als Institution bei der Herausgabe von Publikationen in Erscheinungen treten
8. DadA-P: Periodika (Zeitschriften, Schriftenreihen), siehe DadA-Pressedokumentation
9. DadA-S: NEU, Standorte (Archive/Bibliotheken): Diese können dann über die DadA-L und DadA-P ihre Bestände dokumentieren und zur Ausleihe anbieten.
10. DadA-V: NEU, Verlage = s. als Beispiel die Verlagsseiten im DadA-Portal oder auch die aLibro-Verlagsübersicht. Hier bündeln sich wiederum die von diesen Verlagen veröffentlichten Publikationen.

Anforderungen an das Frontend (die Anwenderoberfläche des Programms):

Nicht registrierte User

1. Kommentarfunktion zu den bestehenden Titeln (Einträgen): Der nicht registrierte User soll eine einfache und bequem gestaltete Möglichkeit haben, Kommentare zu den bestehenden Dokumenten einzustellen, z.B. für Titel-Korrekturen.
2. Bewertungsfunktion: Dies NUR für DadA-L, um dem User die Möglichkeit zu geben, Titel zu bewerten, was Nutzern die Suche nach Literatur erleichtert, die von anderen Usern als gut bewerte wurde.
3. Dokumenten-Erfassungsmöglichkeit: Gerade bei der DadA-L sollte auch der nicht registrierte User die Möglichkeit haben, durch ein einfach gestaltetes Formular neue Titel für die DadA zu erfassen.
   WICHTIG: Gut wäre hier ein zusätzliches Tools wie Zotero, mit dem dann die bibliografischen Daten durch Eingabe der ISBN-Nr. online abgefragt und per Mausklick in die DadA-L importiert werden könnten. [Hier können wir vielleicht auf den Erfahrungen mit der von Markus programmierten Mediawiki-Extension SMWBibHelper aufbauen]. Es gibt bereits eine fertige OPAC-Extension - oBiblioOPAC for Joomla! -, die sich vielleicht dafür nutzen ließe.

Registrierte User (Autoren; Redakteure)

1. Korrekturmöglichkeit: Registrierte und als zuverlässig eingeschätzte Autoren sollten die Möglichkeit haben, Korrekturen in bestehenden DadA-Dokumenten vorzunehmen (allerdings werden diese Korrekturen vermutlich nicht wie in einem Wiki dokumentiert, aber vermutlich lässt sich eine Benachrichigtungsfunktion per E-Mail integrieren, die über eine durchgeführte Veränderung des Dokumentes informiert).

Nutzungsrechte

Bei allen hier diskutierten Systemen können die Rechte der User differenziert gestaltet werden. In Anlehnung an die unter Joomla und Wordpress genutzte Rechteverwaltung sollten für DadAWeb 3.0 in etwa die folgende vier großen Rechtegruppen bestehen:

1. Nicht registrierte User: Können die Kommentar- und Bewertungsfunktion. Zudem können sie neue Einträge (in allen DadA-Dokumentationen?) über eine anwenderfreundliche Erfassungsmaske einreichen, die allerdings von einem Redakteur freigeschaltet werden müssen.
2. Registrierte User (Autor): Haben alle Rechte der passiven User, Zusätzlich können sie aber ihre eigenen eingestellten Titel verändern und auch in den dafür freigegebenen anderen redaktionellen Seiten des DadAWeb aktiv werden.
3. Registrierte User (Redakteur): Betreuen bestimmte Themenbereiche und schalten Neutitel frei. Setzen die Korrekturhinweise zu bestehenden Titeln um, die über Üser-Kommentare kommen.
4. Admin/Sysop: Entwicklung, Projektmanagement, Technik & User-Support

Anforderungen an die Datenbanktechnik

Das neue System sollte über gute und standardiiserte Import- und Exportfunktionen (am besten CVS) verfügen, damit zum einen die alten Offline-Datenbanken der DadA problemlos ins neue Online-System importiert und zugleich und andererseits künftig auch die Datenbank/en des neuen Systems per Export auch wieder in andere gägige Datenbanksysteme überführt werden können.

Die Projekt-Roadmap: Was ist wann geplant

Die Projektplanung unterteilt sich in die folgenden Arbeitsschritte

1. Diskussion und Bestandsaufnahme der bisherigen Projektentwicklung
2. Diskussion und Festlegung des Kriterienkataloges für die neue Lösung
3. Recherche nach geeigneten Systemen, die bisher noch nicht im 2. Projekt-Relaunch berücksichtigt wurden.
4. Test der in die engere Wahl genommenen Systeme .
5. a) Datenimport und –export
6. b) Systemperformance bei hohem Datenbestand (am besten einen Test mit 10.000-25.000 Datensätzen durchführen und dann prüfen auf:
   • Reaktionszeiten bei systeminternen Suchen
   • Speicherzeiten bei der Erfassung neuer Titel
   • Speicherplatzverbrauch
7. c) Anwenderfreundlichkeit des Systems
8. Nach Auswahl des geeigneten Systems Installation und Betrieb einer internen Beta-Version
9. Launch (Start) des Livesystems

TEST DER SYSTEME

Um möglichst schnell einen Überblick über die als Lösung für das Projekt DadAWeb 3.0 sich anbietenden Systeme zu bekommen, wird der Test methodisch wie folgt durchgeführt: