DadA goes DadAWeb 3.0 - Projektrelaunch, die Zweite!

Vorbemerkung zum Projektrelaunch

Nachdem das Projekt DadAWeb goes Web 3.0 vor allen aufgrund der technischen Realisierungsschwierigkeiten in den letzten drei Jahren kaum von der Stelle gekommen ist, haben sich die Projektinitiatoren im September für einen Relaunch des Projektes entschieden.

Das ursprünglich für die Realisierung des DadAWeb-3.0-Portals ins Auge gefasste Wiki-System Mediawiki mit der Extensions Semantic Mediawiki wurde von uns über einen längeren Zeitraum hinweg getestet und hat sich für unser Projekt als nicht geeignet erwiesen. Weiter unten werden wir unsere Erfahrungen und Testresultate dokumentieren.

Mediawiki ist als ein reines Wiki-System, wie es auch hier für das Lexikon der Anarchie genutzt wird, durchaus geeignet. Allerdings lässt doch die Anwenderfreundlichkeit zu wün schen übrig, was sich daran zeigt, dass viele Autor_innen sich immer noch schwer mit der Nutzung des Systems tun und uns ihre Aktualisierungen zum Einstellen schicken.

Obwohl ich petrsönlich ein grßer Fan von Wikiu-Systemen bin, muss ich doch mir eingestehen, dass das System für ein Projekt, wie das DadAWeb 3.0, bei dem unterschiedliche Dokumentationen (Biografien, Literatur, Presse usw.) mit ihren feldstrukturierten Datensätzen vernetzt werden sollen, bislang ungeeignet ist. Von der Perspektive her (insbesondere was die Entwicklung des Semantic Mediawiki angeht) sieht es nicht schlecht aus, aber gegenwärtig ist das System für den Endanwender (und auch für den Entwickler) nicht zumutbar.

Deshalb haben wir uns für einen Relaunch (Neustart) des Projektes entschieden, den ich im folge3nden skizzieren will.

KONZEPTION

Anforderungen an den Relaunch des Projektes DadAWeb 3.0 - DadA goes DadAWeb 3.0

Kriterienkatalog für eine Lösung

Die angestrebte Lösung soll

1. analog zu den alten Offline-DadA-Dokumentationen den Aufbau und die Verwaltung einer in den bestimmten Datenfeldern differenzierten Datenbankstruktur ermöglichen. Für DadA-L entsprechen diese z.B. den RAK (Regelnder der Alphabetischen Katalogisierung). Angestrebt wird 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. auf existierenden und möglichst in der Praxis bewährten Komponenten und Erweiterungen basieren (so wenig Eigenentwicklung wie nur möglich!). K2 z.B. ist eine seit Jahren und mehreren Joomla-Generationen bewährte CCK-Komponente, hinter der inzwischen eine große Anwender-Community steht. FlexiContent dagegen ist neu und hat bislang nur wenige Anwender, was dann auch die Möglichkeit des Supports durch die Community einschränkt.

1. 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) Leistung/Performance Contentplanung: Die vernetzten Contents der DadA 3.0 Das DadAWeb-Portal beinhaltet im Datenbankbereich der DadA folgende Content-Bereiche: 1. DadA-B: Biografien (Autoren/Personen) = NEU, Biografische Infos (siehe als Muster die aLibro-Autorenseiten) 2. DadA-L: a) Literatur in Büchern (Monografien) [DadA-L / DadA-Sekundärliteratur(?)] = DadA-Literaturdokumentation, DadA-Sekundärliteratur & aLibro-Titelsystematik; evtl. Links zu aLibro und zu einem DadAWeb-Büchermarkt für Privatanbieter) 3. DadA-L: b) Literatur in Fachaufsätzen [DadA-L] = = DadA-Literaturdokumentation, DadA-Sekundärliteratur 4. 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 5. DadA-P: Periodika (Zeitschriften, Schriftenreihen) = DadA-Pressedokumentation 6. DadA-S: Standorte (Archive/Bibliotheken) = Diese können dann über die DadA-L und DadA-P ihre Bestände dokumentieren und zur Ausleihe anbieten. 7. DadA-V: Verlage = s. als Beispiel aLibro-Verlagsübersicht oder auch die Verlagsseiten im alten DadA-Portal. Hier bündeln sich wiederum die von diesen Verlagen veröffentlichten Publikationen. Anforderungen an das Frontend: 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) 4. 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 Alle hier diskutierten Systeme haben ein System, bei dem die Rechte der User differenziert gestaltet werden können. 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 Roadmap 1. Recherche nach geeigneten Systemen 2. Test der in die engere Wahl genommenen Systeme: a. Datenimport und –export b. Systemperformance bei hohem Datenbestand (am besten einen Test mit 100.000-250.000 Datensätzen durchführen und dann prüfen: Suchzeiten, Erfassung neuer Titel, Speicherplatzverbrauch) c. Anwenderfreundlichkeit des Systems 3. Nach Auswahl des geeigneten Systems Installation und Betrieb einer internen Beta-Version 4. Launch des Livesystems

RECHERCHE / HINTERGRUNDWISSEN

Anwenderberichte/Anwendungsbeispiele:

• Ellen Bahr: Creating Library Websites with Joomla: Not Too Big, Not Too Small, Just Right (2010)

• WordPress Fun with Advanced Custom Fields (Realisierung eines Bücherblogs mit Wordpress)

• Wordpress nach Drupal und wieder zurück (systemkritischer Erfahrungsbericht der Arbeit mit Drupal)

• How to Use Custom Fields for Entering Book Information (Realisierung eines Bücherblogs mit Wordpress)

• Yuriy Babenko: When is Drupal not the right choice? (Kenntnisreiche Beschreibung der Vor- und Nachteile des Drupal-CMS)

CMS-Vergleiche

• Usage of content management systems for websites (aktuelle Statistik der weltweiten Verbreitung von Open Source CMS-Systemen)

• CMS Comparison: Drupal, Joomla and Wordpress (April 2013)

• WordPress vs Joomla – Review (revised, 2013)

• CMS-Check: Ein Blick in die Zukunft von WordPress, TYPO3, Joomla und Drupal (2013)

• Drupal vs Joomla vs WordPress: CMS Showdown (Juli 2013)

• Bundesamt BSI überprüft Sicherheit von WordPress, TYPO3, Drupal und Joomla (2013)

TEST DER SYSTEME

MEDIAWIKI / SEMANTIC MEDIAWIKI

Mediawiki mit der Extensions Semantic Mediawiki wurde über einen längeren Zeitraum hinweg getestet und hat sich dabei für das Projekt DadAWeb 3.0 als nicht geeignet erwiesen. Später hier die Erfahrungen und Testresultate erfassen.

Kurzfazit: Mediawiki ist super als ein reines Wiki-System. Aber für ein Projekt, wie das DadAWeb 3.0, bei dem unterschiedliche Dokumentationen (Biografien, Literatur, Presse usw.) mit ihren feldstrukturierten Datensätzen vernetzt werden sollen, ist das Mediawiki bislang noch ungeeignet. Von der Perspektive her (insbesondere was die Entwicklung des Semantic Mediawiki angeht) sieht es nicht schlecht aus, aber gegenwärtig ist das System für den Endanwender (und auch für den Entwickler) nicht zumutbar.

WORDPRESS

Das weltweit populäre Blogsystem, das durch Plugins für verschiedene Anwendungszwecke angepasst werden kann.

Bibliografische Module (Plugins) für Wordpress:

- Bibliografisches Modul: OpenBook Book Data URL: http://wordpress.org/plugins/openbook-book-data/ Downloads: 16,616, Autor hat 2 Plugins entwickelt

- Book Review Modul: book-review-library URL: http://wordpress.org/plugins/book-review-library/ Downloads: 371, Autor hat 14 Plugins entwickelt

- Book Review Modul: book-review URL: http://wordpress.org/plugins/book-review/ Downloads: 252, Autor hat bislang nur 1 Plugins (nämlich book-review) entwickelt

- CCK-Modul für Wordpress: URL: http://wordpress.org/plugins/advanced-custom-fields/screenshots/ Downloads: 1.271.414. Autor hat bislang nur 1 Plugins (nämlich book-review) entwickelt Kommentar: Advanced Custom Fields. Zitat: Advanced Custom Fields is the perfect solution for any wordpress website which needs more flexible data like other Content Management Systems. Wird häufig mit den CCK-Features von Drupal verglichen.

Datenimport nach Wordpress Zum Procedere siehe am Beispiel des Imports von Joomla-Content: How to Import Joomla Content Using the WP Importer Plugin Wordpress-Referenzseiten - nozegraze.com: http://www.nosegraze.com/reviews/ das ist die, die den Artikel „How to Use Custom Fields for …“ geschrieben hat und für 35$ auch ein Review-Plgin anbietet. - KinderbuchLotse: www.kibulo.de (wurde inzwischen eingestellt)

JOOMLA! Das weltweit wegen seiner Anwenderfreundlichkeit beliebte CMS kann für jeden nur denkbaren Zweck durch Extensions angepasst werden.

Bibliografische Extensions unter Joomla - StorePapers URL: http://extensions.joomla.org/extensions/living/education-a-culture/bibliography/10001 Dokumentation (PDF-File): Wird aber anscheinend noch von niemanden genutzt. Bibliotheks-/Büchersammlungen Extensions bei Joomla: Meine Präferenz aufgrund theoretischer Recherchen: BoobLibraqry Basic - BookLibrary Basic 1. Demo: kommerzielle eBook-Bibliothek (engl.) 2. Demo: Fachbibliothek Pazifik-Klima-Portal (engl.) 3. Demo: öfftl. Kinderbibliothek (span.)

- Alexandria Book Library 1. Demo: http://joomla15.neodemo.net/library.html

- MediaLibrary Basic (ist ein auf andere Medien – z.GB. CD’s – und um einen Onlineshop erweiterte Fassung von BoobLibrary)

- Book Library Strukturierte Contents / Datenbanken, siehe Themenbereich Content Construction: Vergleichstest dreier Systeme: http://www.jinsiders.de/der-grosse-cck-vergleich-zoo20-k2-und-sobi2/1098 1. K2 Tutorial-Videos: http://getk2.org/documentation/k2class2012 Content-Import via CVS: http://www.individual-it.net/Instructions-for-K2-Import-Component.html Falls K2 zu sperrig ist, sollte versucht werden, beim Hersteller von ZOO die kommerzielle Lösung inkl. Support gesponsert zu bekommen, indem DadA 3.0 als Referenzprojekt für den Bereich Sozialwissenschaften entwickelt wird.

2. ZOO

3. FlexiContent: Offensichtlich mächtiges offenes System Zahlreiche Erweiterungen für Import, Filter usw. Besprechung: http://blog.blueforce.ch/2009/12/joomla-cck-mit-flexi-content-komponente/ Fazit: Scheint beliebter und mächtiger zu sein als Form2Content. Am besten beide Systeme testen Siehe zum Datenimport via FlexImport: http://extensions.netassopro.com/tutorials/item/20-fleximport-user-guide

4. Form2Content: Frei definierbare feldbasierte Artikel Demo Movie Database: http://demo.form2content.com/ (login: demo/demo) Fazit: macht einen sehr guten Eindruck – TESTEN!

Alternativ sollte vielleicht auch (das gute alte) SOBI getestet werden. Zwar eher eine Directory-Komponente, die aber sehr flexibel konfigurierbar ist. Joomla-Referenzseiten - Herrick Memorial Library der Alfred University, New York (USA): http://herrick.alfred.edu/ Joomla 1.5 und K2. Ansprechpartner ist Ellen Bahr, die auch den Fachartikel “Creating Libryry Websites …” geschrieben hat.

DRUPAL Das Drupal-System läuft hier nur aus Vergleichsgründen am Rande mit. Zwar scheint Drupal als System dasjenige zu sein, das für den Bereich Bibliografien durch entsprechende Plugins gute Voraussetzungen mitbringt. Allerdings ist es als System offensichtlich träge in der Performance und sowohl für den Entwickler als auch für Endanwender recht sperrig in der Handhabung. (siehe auch: Babenko: When is Drupal not the right choice? und Wordpress nach Drupal und wieder zurück). Bei der Bibliothek der Frauen (Berlin) nachhaken, die mit Drupal m.W.n. keine guten Erfahrungen gemacht hat. Auffälig ist, dass bei den amerikanischen Bibliotheken, die Drupal für ihre Hoepage nutzen, die bibliografischen Kataloge dann aber anscheinend immer unter einem anderen System laufen. Bibliografische Module: - Bibliography Module: https://drupal.org/project/biblio

- Book Review Module: https://drupal.org/project/bookreview Drupal-Referenzseiten - Portal für Bibliotheks-Projekte unter Drupal: http://drupalib.interoperating.info/ - Bibliotheken, die Drupal nutzen: http://drupalib.interoperating.info/library_sites

29.09.2013 - aLibro-Blog – Betaversion: www.alibro.de/blog/ (Arbeit an dem aLibro-Bücherblog erst einmal zugunsten einer Lösung für das DadAWeb 3.0 Projekt eingestellt)