DadA goes DadAWeb 3.0 - Projektrelaunch, der Dritte!

Jetzt aber ... der große Durchbruch!?

Vorbemerkung

Vielleicht ist es utopisch, was wir uns mit unserer Idee des DadAWeb 3.0 vorstellen. Aber Fortschritt ist die Verwirklichung von Utopien. Das meint jedenfalls Oscar Wilde, und wir sehen das genau so.

Die Realität ist: Vier Jahre nach dem im September 2013 eingeleiteten zweiten Projektrelaunch konnte das Projekt DadA 3.0 immer noch nicht realisiert werden. Es ist Zeit für eine kritische Bestandsaufnahme der bisherigen Projektentwicklung und für die Suche nach alternativen Realisierungsmöglichkeiten. Dies geschieht in dem hiermit beginnenden dritten Projektrelaunch.

Jochen Schmück, im Oktober 2017

Bilanz der bisherigen Entwicklung (Fazit des 2. Projekt-Relaunches)

hier die bisherigen Versuche zur Realisierung des Systems und die Gründe ihres Scheiterns kurz dokumentieren.

Vier Modelle zur Realisierung von DadA Online / DadAWeb 3.0

1. Quick and Dirty

Import der bislang offline gepflegten DadA-Dokumentationen (DadA-P und DadA-L) in ein pflegeleichtes Online-CMS (wie Joomla! oder WordpPresss) bzw. Wiki (wie Mediawiki). Das wäre quasi eine Fortsetzung der bislang bestehenden statischen HTML-Version des Ur-DadAWeb, nur eben im Rahmen eines CMS/Wikis und mit dem Unterschied, das dann (z.B. beim Wiki auf der Diskussions-Seite) User direkt ihr Feedback (Korrektur- und Ergänzungsvorschläge) zu den Dokumenten geben könnten. Recherchen sind bei diesem Modell nur über die integrierte Volltext-Suche des jeweiligen CMS möglich.

Der Vorteil:

Diese Lösung lässt sich innerhalb kürzester Zeit mit geringem Kostenaufwand realisieren. Erforderlich dafür ist nur ein dem jeweiligen CMS entsprechendes Datenimport-Tools wie es z.B. für Mediawiki mit der Extension Data Transfer (für die Formate CVS und XML) vorliegt. Für Joomla und WordPress gib es vergleichbare Tools/Erweiterungen. Da mit dem DadAWeb-Wiki bereits eine solche Online-Plattform existiert, die zugleich auch hochwertige Contents (wie das Lexikon der Anarchie“) beinhaltet, wäre es naheliegend, die DadA-Dokumentationen in das bestehende DadA-Wiki zu importieren.

Der Nachteil:

Als Online-Datenbank lässt sich die DadA dann aber nicht nutzen, weil keine echten Datenbankstrukturen existieren, die z.B. bei feldbezogenen Suchen (z.B. Beispiel: Suche alle Titel mit Erscheinungsort: Berlin) ermöglicht. Auch die Pflege derDadA- Dokumente ist nicht optimal, weil immer die Gefahr besteht, dass bei Korrekturen oder Ergänzungen versehentlich die DadA-Feldkennungen zerstört werden, was den Re-Import in eine echte Datenbankumgebung dann später erschwert.

2. Quick und Selfish

Import der bestehenden DadA-Dokumentationen in eine reine Online-Datenbank (wie z.B. Datenbank24.de oder BasePortal). Dort können dann die DadA-Dokumentationen in einer echten Datenbankumgebung gepflegt und auch für spezielle Datenbank-Recherchen genutzt werden. Eine integrierte Plattform, auf der redaktionelle, bibliothekarische und Datenbank-Inhalte angeboten werden, ist mit dieser Lösung jedoch nicht möglich. Allenfalls ließe sich die damit realisierte DadA-Onlinedatenbank per Frame in ein redaktionelles System (wie es z.B. Joomla oder Wordpress bietet) einbetten.

Der Vorteil:

Auch diese Lösung lässt sich zeitnah umsetzen. Die Daten befinden sich bei diesem Modell in einer echten Datenbankumgebung, was den Aufwand für Import und Export sehr gering hält. In einer solchen Datenbank können auch datenbankspezifische Recherchen durchgeführt werden.

Der Nachteil:

Hohe Kosten, denn solche Onlinedatenbank-Lösungen kosten zwischen 5,00-50,00 EUR/Monat. Da redaktionelle und bibliothekarische Inhalte auf der einen Seite und die Datenbankinhalte auf der anderen Seite über zwei verschiedene Systeme gepflegt werden, erhöht dies natürlich auch den Aufwand der Systemadministration.

3. Pragmatic and Useful

Import der bestehenden DadA-Dokumentationen in ein anwenderfreundliches CMS wie Joomla! oder WordPress bzw. in ein Wiki auf Basis von Semantic Mediawiki. Um in einem solchen eher auf redaktionelle Inhalte ausgerichteten System die DadA-Dokumentationen als Onlinedatenbank nutzen zu können, müssten allerdings in dem CMS/Wiki zusätzliche Datenbankstrukturen und –funktionen eingebaut werden. Am einfachsten dürfte die Realisierung dieses Modells mit Hilfe des CMS Joomla! sein, bei dem inzwischen mit dem seit Mai 2017 existierenden Programm-Feature der Custom Fields die Möglichkeit besteht, Inhalte in echten Datenbankstrukturen zu erfassen und zu pflegen.

Der Vorteil:

Die Dokumentationen der DadA würden sich bei diesem Modell zusammen mit den redaktionellen und bibliothekarischen Inhalten des DadAWeb in einem integrierten System befinden. Das erleichtert den systemadministrativen Pflegeaufwand des DadAWeb 3.0 inkl. der DadA-Onlinedatenbank. Eine solche Lösung hat für die User einen deutlich höheren Nutzwert als die ersten beiden Lösungen. Die User können in einem solchen System die DadA-Dokumentationen nicht nur für reine Recherchen nutzen, sondern sie können sich aktiv an ihrem Aufbau und ihrer Pflege beteiligen. Gleichzeitig können sie auf dieser Plattform auch die redaktionellen Inhalte mit gestalten und sich auch in Arbeitsgruppen organisieren und untereinander austauschen.

Der Nachteil:

Im Vergleich zu den ersten beiden Lösungen ist bei diesem Modell der Arbeitsaufwand deutlich höher. Nach unseren bisherigen Erfahrungen macht es kaum Sinn, eine solche Lösung über externe Erweiterungen zu den eigentlichen Content-Management-System (wie z.B. durch die für Joomla! entwickelte Erweiterung Fabrik) zu realisieren. Bei externen Erweiterungen besteht immer die Gefahr besteht, dass sie von der Entwicklung des eigentlichen CMS „abgehängt“ und dann nicht mehr weiterentwickelt werden (wie das im Fall der Fabrik-Extension seit Einführung der Custom Fields im Joomla-Kernprogramm vermutlich der Fall sein wird). Da jedoch der Aufwand für die Entwicklung eines solchen integrierten Systems selbst bei den anwenderfreundlichen CMS nicht trivial ist, müssen, um eine baldige Realisierung zu erzielen, einige der Arbeiten nach außen an Experten vergeben werden. Das erhöht die Entwicklungskosten eines solchen Systems

4. Smart and Perfect

Import der bestehenden DadA-Dokumentationen in ein CMS, das in seinen Contentstrukturen, Features und Funktionen frei konfigurierbar ist. Lange Zeit galten Typo3 und Drupal als Systeme, die diesen Anforderungen entsprachen. Allerdings haben sich Systeme als nicht sehr anwenderfreundlich erwiesen. Inzwischen gibt es aber mit dem CMS ProcessWire ein System, das nicht nur diesen Anforderungen nach einem in seinen Contentstrukturen, Features und Funktionen frei konfigurierbaren System entspricht, sondern das auch offensichtlich sehr anwenderfreundlich ist.

Der Vorteil:

Bei diesem Modell ließe sich ein System entwickeln, das passgenau den spezifischen Anforderungen des DadA-Projektes und seiner Dokumentationen als auch denen der redaktionellen und bibliothekarischen Inhalte entspricht. Da in einem solchen selbst konfigurierten Idealsystem kein unnötiger Ballast an nicht benötigten Programm-Features und -Funktionen existiert, dürfte die Systemperformance deutlich besser sein als bei einer Lösung wie sie im vorigen 3. Modell beschrieben wurde.

Der Nachteil:

Im Vergleich zu allen anderen bisher beschriebenen Lösungen erfordert dieses Modell in der Entwicklungsphase den höchsten Arbeitsaufwand. Um dieses Modell in einem vertretbaren Zeitrahmen zu realisieren, müssen einige Arbeiten an externe Spezialisten vergeben werden, was die Entwicklungskosten für dieses System erhöht.

Kriterienkatalog für eine Lösung (Vorschlag zur Diskussion)

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 Jochen monatelang herumexperimentiert, ohne dass wir dadurch irgendwie der Realisierung des DadAWeb 3.0 wesentlich näher gekommen wären. Auch die im 2. Projekt-Relaunch unternommenen Anstrengungen zur Realisierung des Projektes auf Basis unterschiedlicher Systeme, die sich zuletzt auf die Lösung "Joonmla+Fabrik-Extension" focussiert haben, hat bislang zu keinem echten Durchbruch in der Realisierung von DadA 3.0 geführt. Die nun im 3. Relauunch angestrebte 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 Content-Management-Systeme wie Mediawiki, Joomla! oder Wordpress (Drupal und TYPO3 wurden ausgeklammert, 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 Datenbank-/Content-Strukturen
2. Gute Usability/Anwenderfreundlichkeit
3. Sichere Zukunftsperspektiven
4. Datensicherheit und Datenschutz
5. System-Leistung/-Performance

Contentplanung: Die vernetzten Contents der DadA 3.0

Das DadAWeb-Portal beinhaltet redaktionelle, bibliothekarische und Datenbankinhalte. Im Datenbankbereich finden sich folgende DadA-Dokumentationen (die grün markierten sind die bereits existierenden Dokumentationen):

1. DadA-A, Archivalien (NEU): Erfassung von Nachlässen und musealen Exponaten wie z.B. Briefwechsel, Tagebücher, digitale Dokumente, Fotos, Filme, Audioaufnahmen, Plakate, Aufkleber usw. usf. Siehe 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 (NEU):, Veranstaltungen (erst einmal) mit dem Schwerpunkt auf Bildungs- und Kulturveranstaltungen.
4. DadA-F, Forschungs- und Publikationsvorhaben (NEU): 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, Organisationen (NEU): 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: Standorte, Archive und Bibliotheken (NEU): Diese können dann über die DadA-L und DadA-P ihre Bestände dokumentieren und zur Ausleihe anbieten.
10. DadA-V: Verlage (NEU): Siehe 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 standardisierte Daten-Import- und Exportfunktionen (am besten im CVS-Format) verfügen, damit zum einen die alten Offline-Datenbanken der DadA problemlos ins neue Online-System importiert und andererseits künftig auch die Datenbank/en des neuen Systems per Export auch wieder in andere gängige Datenbanksysteme überführt werden können.

Finanzierung

Um im 3. Relaunch nun endlich den Durchbruch zur Realisierung des Projektes DadAWeb 3.0 zu erzielen, sollten wir versuchen, schwierige Programmieraufgaben, die die Projektentwicklung ausbremsen, nach außen zu vergeben und durch Spezialisten erledigen zu lassen. Das kostet natürlich Geld, das dem Projekt nicht zur Verügung steht. Folgende Finanzierungsmodelle könnten für die Finanzierung des Projektes genutzt werden:

1. Projektförderung: z.B. durch die Rosa-Luxemburg-Stiftung
2. Social Crowd-Funding: z.B. durch Crowd-Funding-Portale wie StartSomeGood

Diskussionsvorschlag für 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