DadA goes DadAWeb 3.0 - Projektrelaunch, der Dritte!
Inhaltsverzeichnis
- 1 Vorbemerkung
- 2 Bilanz der bisherigen Entwicklung (Fazit des 2. Projekt-Relaunches)
- 3 Vier Modelle zur Realisierung von DadA Online / DadAWeb 3.0
- 4 Kriterienkatalog für eine Lösung (Vorschlag zur Diskussion)
- 5 Contentplanung: Die vernetzten Contents der DadA 3.0
- 6 Anforderungen an das Frontend (die Anwenderoberfläche des Programms):
- 7 Nutzungsrechte
- 8 Anforderungen an die Datenbanktechnik
- 9 Finanzierung
- 10 Diskussionsvorschlag für die Projekt-Roadmap: Was ist wann geplant
- 11 Recherche / Hintergrundwissen
- 12 TEST DER SYSTEME
Vorbemerkung
Vielleicht ist es wirklich utopisch, was wir uns mit dem Projekt des DadAWeb 3.0 vorgenommen haben. Aber Fortschritt ist die Verwirklichung von Utopien, meint Oscar Wilde.
Doch von echten Fortschritten kann im Projekt "DadAWeb 3.0" leider nicht die Rede sein. Eher bewegt sich das Projekt im Kreis. Die traurige Realität ist, dass sieben Jahre nach der Initialisierung des Projektes und vier Jahre nach dem zweiten Projektrelaunch das Projekt DadA 3.0 immer noch nicht wie geplant realisiert werden konnte. Immer noch gibt es keine webbasierte Onlinedatenbank, mit der sich die Inhalte der DadA-Presse- und Literaturdokumentation nicht nur nutzen, sondern auch von den Usern selber pflegen ließen. Immer noch nicht gibt es keine integrierte Web-Plattform für die redaktionellen, bibliothekarischen und Datenbankinhalte des DadAWeb.
Mangels echter Fortschritte ist es 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, von dem wir hoffen, dass er für das Projekt DadA 3.0 endlich den Durchbruch bringt. Wir sind immer noch hoffnungsfroh, denn wie sagt das Sprichwort? Es sagt: "Aller guten Dinge sind drei"!
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
Eine Einschätzung von Jochen Schmück, die als Beitrag zur Diskussion über die weiteren Entwicklungsöglichkeiten des DadA-Projektes gedacht ist.
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 in den Inhalten der DadA-Dokumentationen 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 Wiki des DadAWeb 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 der DadA-Dokumente würe nicht optimal, weil immer die Gefahr besteht, dass bei Korrekturen oder Ergänzungen versehentlich die Datenbank-Feldkennungen der DadA 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. datenbanken24 oder baseportal). Dort können 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 3,99-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 Arbeitsaufwand und die Kosten der Systemadministration.
3. Easy and Pragmatic
Import der bestehenden DadA-Dokumentationen in ein anwenderfreundliches CMS wie Joomla! oder WordPress bzw. in ein Wiki. 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, wofür spezielle Erweiterungen existieren (so gibt es für Joomla! z.B. die von uns getestete Erweiterung Fabrik und für Mediawiki existiert die Erweiterung Semantic MediaWiki. Am einfachsten dürfte inzwischen die Realisierung dieses Modells mit Hilfe des CMS Joomla! sein, bei dem mit dem seit Mai 2017 existierenden Programm-Feature der Custom Fields die Möglichkeit besteht, Inhalte in echten Datenbankstrukturen zu erfassen und zu pflegen und auch datenbankspezifische Such-, Filter- und Listen-Funktionen zu nutzen.
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 aus einem Guss" 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 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 nutzen und mit gestalten und sich in freien 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 dem für das System genutzten Content-Management-System (wie z.B. die Erweiterung "Fabrik" für das CMS Joomla!) zu realisieren. Bei externen Erweiterungen besteht immer die Gefahr, 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 des Features 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 einem anwenderfreundlichen CMS wie Joomla! auch nicht gerade 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. Clever and Perfect
Import der bestehenden DadA-Dokumentationen in ein CMS, das in seinen Contentstrukturen, Features und Funktionen frei konfigurierbar ist und damit bestens den speziellen Anforderungen des DadAWeb entspricht und damit das "perfekte Wunschsystem" wäre. Lange Zeit galten TYPO3 und Drupal als Systeme, die diesen hohen Anforderungen am besten entsprachen. Allerdings haben sich beide Systeme als nicht sehr anwenderfreundlich erwiesen. Inzwischen gibt es aber mit dem clever gestalteten CMS ProcessWire ein System, das nicht nur den Anforderungen nach einem in seinen Contentstrukturen, Features und Funktionen frei konfigurierbaren System besens entspricht, sondern das dabei auch noch sehr anwenderfreundlich ist.
Der Vorteil:
Mit 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 ein solches selbst konfiguriertes System keinen Ballast an nicht benötigten Programm-Features und -Funktionen besitzt, 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 also einige Arbeiten an externe Spezialisten vergeben werden, was die Entwicklungskosten für dieses System deutlich erhöht.
Kriterienkatalog für eine Lösung (Vorschlag zur Diskussion)
Die angestrebte Lösung soll
- 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.
- 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.
- 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).
- 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.
- 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:
- frei definierbare und vernetzbare Datenbank-/Content-Strukturen
- Gute Usability/Anwenderfreundlichkeit
- Sichere Zukunftsperspektiven
- Datensicherheit und Datenschutz
- 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):
- 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.
- DadA-B, Biografien, Autoren, Personen (NEU): Biografische Infos (siehe als Grobmuster die aLibro-Autorenseiten, aber in der DadA natürlich strukturierter als bei aLibro.
- DadA-E, Events (NEU):, Veranstaltungen (erst einmal) mit dem Schwerpunkt auf Bildungs- und Kulturveranstaltungen.
- DadA-F, Forschungs- und Publikationsvorhaben (NEU): Siehe die Rubrik "Forschungsprojekte" im gegenwärtigen DadAWeb.
- 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)
- DadA-L - b) Literatur in Fachaufsätzen: siehe DadA-Literaturdokumentation, DadA-Sekundärliteratur
- 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
- DadA-P: Periodika (Zeitschriften, Schriftenreihen), siehe DadA-Pressedokumentation
- 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.
- 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
- 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.
- 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.
- 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)
- 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:
- 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.
- 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.
- Registrierte User (Redakteur): Betreuen bestimmte Themenbereiche und schalten Neutitel frei. Setzen die Korrekturhinweise zu bestehenden Titeln um, die über Üser-Kommentare kommen.
- 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:
- Projektförderung: z.B. durch die Rosa-Luxemburg-Stiftung
- 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
- Diskussion und Bestandsaufnahme der bisherigen Projektentwicklung
- Diskussion und Festlegung des Kriterienkataloges für die neue Lösung
- Recherche nach geeigneten Systemen, die bisher noch nicht im 2. Projekt-Relaunch berücksichtigt wurden.
- Test der in die engere Wahl genommenen Systeme .
- a) Datenimport und –export
- 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
- c) Anwenderfreundlichkeit des Systems
- Nach Auswahl des geeigneten Systems Installation und Betrieb einer internen Beta-Version
- Launch (Start) des Livesystems
Recherche / Hintergrundwissen
Anwenderberichte/Anwendungsbeispiele:
Fazit der bisherigen Recherchen