Auch wenn viele Nutzer sie noch nie bewusst wahrgenommen haben, haben die Wikimedia Commons ihnen mit großer Wahrscheinlichkeit schon Inhalte geliefert: Der überwiegende Anteil aller Bilder in der Wikipedia stammt aus dem gemeinsamen Medienarchiv.

Dies war auch der Ansporn, aus dem im September 2004 das Wikimedia-Projekt gegründet wurde: Die Schaffung eines zentralen Aufbewahrungsortes von Multimedia-Inhalten auf das jedes Wikimedia-Projekt zurückgreifen kann, ohne dass eine Datei zig mal in verschiedene Projekte hochgeladen werden muss.

Bereits ein Jahr nach der Gründung hielt Wikimedia Commons über 250.000 Mediendaten zur freien Verfügung bereit und wurde somit eine der größten freien Mediendatenbanken der Welt. Zum Zeitpunkt dieses Postings enthalten die Commons fast 3 Millionen frei verwendbare Mediendateien.

Bereits vor einigen Jahren hat Erik Möller, von dem bereits die ursprüngliche Idee und Realisierung ausging, den Vorschlag gemacht, die Wikimedia Commons weiter zu öffnen: InstantCommons sollte es weltweit jedem Wiki auf MediaWiki-Basis ermöglichen, auf die Inhalte der Wikimedia Commons zuzugreifen.

Dies wurde nun – wenn auch nicht unter diesem Namen – implementiert.

Ab sofort kann jedes MediaWiki ab der Version 1.13alpha (r35075) direkt Medien von den Wikimedia Commons einbinden. Dazu ist es nötig in der LocalSetting.php folgenden Block einzutragen:

$wgForeignFileRepos[] = array(
‘class’ => ‘ForeignAPIRepo’,
‘name’ => ’shared’,
‘apibase’ => ‘http://commons.wikimedia.org/w/api.php’,
‘fetchDescription’ => true, // Optional
);

Das genügt bereits, um im entsprechenden Wiki auf die gleiche Weise Commons-Inhalte einbinden zu können, wie es innerhalb der Wikipedia der Fall ist. Vorschaubilder werden automatisch generiert, die Bildbeschreibung und die Versionsgeschichte von den Commons durchgereicht.

Bisher werden die Inhalte noch nicht (wie im ursprünglichen InstantCommons-Vorschlag enthalten) lokal gecached, sondern immer direkt von den Commons abgerufen. Damit dürfte bei grossen Wikis signifikant zusätzlicher Traffic erzeugt werden.

Durch die Einbindung von Wikimedia Commons Inhalten ins eigene Wiki, wird Wiki-Betreibern und -Nutzern die Möglichkeit gegeben, auf einen riesigen Fundus freier Medien zugreifen zu können, ohne dass man sich um die Lizenzierung großartig Gedanken machen müsste.

PS: Durch die Änderung des Parameters apibase ist es möglich, auch auf andere MediaWiki-Installationen zugreifen zu können!

(via Erik)

Die ehemals als “stabile Versionen” bekannte Funktionalität entspricht dem Umfang, den ich am 29. August 2006 im Artikel “Fakten” zu den Stabilen Versionen beschrieben habe. Da kann man sich die Idee noch einmal genauer zu Gemüte führen.

Erst gestern auf dem 14. Kölner Webmontag habe ich mich mit Torsten Kleinz über größere Software-Änderungen innerhalb der Wikipedia unterhalten, die relativ selten sind. Mit zu den größten Schritten zählten sicherlich die Abkehr vom CamelCase, der Wechsel von Phase II auf MediaWiki und der Aufbau der zentralen MediendatenbankWikimedia Commons.

Persönlich erinnere ich mich an wenige Projekte (abgesehen vom Single-User-Login), die so lange bereits in der Arbeit und in der Diskussion sind, wie die “stable versions”. Es freut mich, dass mit Hilfe von Wikimedia Deutschland, Wikimedia Frankreich und dem Einsatz von Philipp Birken, Aaron Schulz, Brion Vibber und vielen weiteren Helfern, die gesichteten und geprüften Versionen nun endlich Realität geworden sind.

Nun wird sich zeigen, wie gut die neue Möglichkeit zur Qualitätssicherung in der Realität skaliert. Momentan enthält die Mehrzahl der Artikel noch die Kennzeichnung “Es wurde noch keine Version gesichtet.”, dies wird sich aber dank vieler fleißiger Hände vermutlich bald ändern.

Anträge zur Vergabe des “Sichter”-Flags (das es erlaubt, Artikel als gesichtet zu markieren) können auf der Seite Wikipedia:Gesichtete Versionen/Rechtevergabe gestellt werden.

Momentan ist dazu die Stimmberechtigung Voraussetzung, in Zukunft sollen die Hürden allerdings deutlich niedriger angelegt werden.

Es gibt keine zufriedenstellende prägnante Übersetzung für diese relativ neue englische Redewendung.

Online-Wörterbücher wie dict.leo.org oder dict.cc schlagen den Begriff “Schnickschnack” vor, greifen damit aber viel zu kurz.

“Bells and whistles” sind Funktionen, die für das korrekte Funktionieren eines Produktes oder einer Anwendung nicht wirklich notwendig sind, aber die “user experience” spürbar verbessern.

Ein gutes Beispiel dafür die Typeahead-Funktionalität, die den meisten Benutzern das erste Mal bei der Autokomplettierung der Adresszeile im Browser über den Weg gelaufen sein dürfte. Nachdem man einige Zeichen eingetippt hat, vervollständigt der Browser die Adresse selbst oder bietet, falls mehrere Alternativen gefunden werden, ein Dropdown-Menü an, um die passende Adresse auszuwählen.

Mittlerweile gibt es – gerade in Web 2.0-Umfeld – eine ganze Reihe von Diensten im Web, die diese durch AJAX realisierte Funktionalität nutzen. Während im Browser-Beispiel auf die Historie zurückgegriffen wird, nutzt man im Allgemeinen während des Eintippens der entsprechenden Zeichenfolge eine (asynchrone) Datenbankabfrage auf Daten eines aktuellen Bestandes, um die Treffer als Auswahl anzubieten.

So fragt beispielsweise die Suchmaske auf dem Portal wikipedia.de bereits seit Juni 2007 die bestehenden Artikel der Wikipedia schon bei der Eingabe des Suchbegriffes ab (siehe auch Wikipedia.de in neuem Gewand).

Seit dem 22.04. ist ohne große Ankündigung in allen Wikimedia-Wikis eine Typeahead-Suche aktiviert. Die Suchbox fragt seitdem bei der Eingabe die existierenden Lemmata ab und blendet eine Dropdown-Box zur Auswahl ein.

Da dieses Feature ungemein praktisch ist, wundert es mich, dass bis auf Brion (der es zusammen mit Robert Stojnic umgesetzt hat) bisher niemand das Thema aufgegriffen hat.

Während dies für die Wikimedia-Projekte ein großer Schritt ist, bieten wir bei Wikia bereits seit geraumer Zeit eine Typeahead-Suche an. Aber da das ja nun ein alter Hut ist, haben wir uns überlegt, was man sonst noch so tun kann, um dem Nutzer sinnvolle Tools an die Hand zu geben.

Eine dieser Entwicklungen hört auf den Namen “Link Suggest” und ermöglicht – passend zum Thema – eine Typeahead-Auswahl existierender Artikel bei der Verlinkung im Bearbeitungsmodus. Nach der Eingabe von “[[” und folgenden Zeichen öffnet sich eine Dropdown-Box, aus der der zu verlinkende Artikel einfach ausgewählt werden kann.

Auf die gleiche Art und Weise können auch einfach Bilder (bzw. Thumbnails) eingebunden werden. Leider gibt es momentan noch einen Bug, der dazu führt, dass Link Suggest augenscheinlich nicht unter unixoiden Systemen funktioniert, aber wir arbeiten dran.

MediaWiki goes social.

Gestern hat Wikia ein Social Networking Toolset als MediaWiki-Extension unter der GPL-Lizenz veröffentlicht.

Dies ermöglicht es auf einfache Weise, Social Networking Funktionen in jede laufende MediaWiki-Installation zu integrieren.

Live und in Farbe kann man sich die Erweiterung bei Wikia in der komplett überarbeiteten Halopedia (einer Community rund um das Computerspiel Halo) und in der Sport-Community ArmchairGM anschauen.

Warum sollte man Social-Network-Funktionalität mit Wikis verheiraten?

Spätestens seit der Wikipedia-Diskussion um das Thema ob sie nun aus der “Weisheit der Massen” oder aus der Gemeinschaft einer engagierten Gruppe von Menschen hervorgegangen ist (vgl. “Wer schreibt die Wikipedia?“), sollte jedem bewusst sein, wie wichtig aktiven Wiki-Autoren die gegenseitige Vernetzung ist. Dies gilt für kleinere Gemeinschaften mit einer geringeren Anonymität oft noch in einem höheren Maße.

Ein anderer wichtiger Punkt für ein erfolgreiches Wiki ist, dass die Mitarbeit den Nutzern Spaß macht. Dabei entstehen oft Auswüchse, die mit dem eigentlichen Ziel des Wikis scheinbar nichts zu tun haben, aber für die Gemeinschaft wichtig sind und gerade auch den Charakter eines Projektes prägen.

Social-Network-Funktionen erlauben es Nutzern, sich besser untereinander zu vernetzen und einfacher miteinander zu interagieren. Die SocialProfile-Extension ermöglicht die Erstellung von Profilen in einem standardisiertem Format, das Hinzufügen von Freunden (und von Feinden…), das Verteilen von “Geschenken”, das Hinterlassen von privaten und öffentlichen Nachrichten, die Anzeige von Statistiken und noch ein wenig mehr.

Ursprünglich ist die Erweiterung aus dem ArmchairGM-Ausbau entstanden, da dort die Funktionalität von Social Networks durch die sehr aktiven Mitglieder als enorm wichtig wahrgenommen wurden. Die weiterentwickelten Funktionen wurden dann für das gesamte Wikia-Universum portiert.

Da Wikia sich Offenheit und Transparenz auf die Fahnen geschrieben hat und selbst vom Einsatz Freier Software profitiert, liegt es nahe, dass wir auch entsprechend eigenen Code wieder in die Open-Source Community zurückgeben. So findet man einige unserer Verbesserungen an MediaWiki im SVN-Repository oder diese werden direkt durch Extension-Betreuer aufgegriffen und in neuen Versionen verwertet.

Es ist immer etwas schwierig neue Entwicklungen in die Öffentlichkeit zu geben, da diese in der Regel sehr auf die speziellen Verhältnisse von Wikia zugeschnitten sind und nicht mit Blick auf den “Endanwender” entwickelt wurden.

Die Veröffentlichung braucht dann einiges an Zeit um sie für Standard-MediaWiki-Installationen nutzbar zu machen, erweiterte Dokumentation zu schreiben und alles schön zusammenzupacken. Dies ist uns bei der SocialProfile-Extension aber ganz gut gelungen :-)

• Artikelversionen können in Zukunft als geprüfte Versionen und als gesichtete Versionen markiert werden.
• Diese Änderung wird “in einigen Monaten” in der deutschsprachigen Wikipedia testweise aktiv geschaltet.

Geprüfte Versionen …

• … sollen sicherstellen, dass ein Artikel keine falschen Aussagen und keine wesentlichen Lücken enthält.
• … können nur durch wenige Experten erstellt werden (in der Testphase 3-5 Personen). Das entsprechende Recht wird wie bei Administratoren von einem Bürokraten vergeben. Wie diese Experten ernannt/gewählt werden ist noch nicht festgelegt. Die entsprechenden Benutzer sollten namentlich bekannte Wissenschaftler aus aktiven Portalen sein.
• … sollen Glaubwürdigkeit und Verlässlichkeit schaffen. Neben den hohen Anforderungen an die Benutzer mit Prüfrechten gilt der Grundsatz “Im Zweifelsfall nicht markieren.”
• … können mehrfach von verschiedenen Benutzern mit Prüfrechten markiert werden.
• … werden (vergleichbar zu Artikel-Sperren) im Logbuch und in der Versionshistorie gespeichert. Der Benutzer mit Prüfrechten hat die Möglichkeit einen Kommentar zu vergeben.
• Prüfer vergeben den Status “geprüfte Version” nur in ihrem – anfangs festgelegten – Bereich/Fachgebiet.
• “Normale” Benutzer können Artikelversionen zur Prüfung vorschlagen.
• Langfristig ist zu überlegen ob Experten von außerhalb des Projekts die Möglichkeit gegeben werden kann, Artikel zu prüfen.

Gesichtete Versionen …

• … sollen sicherstellen, dass ein Artikel keinen offensichtlichen Vandalismus wie Totallöschungen oder Beleidigungen enthält.
• … können (vergleichbar zum Editier-Recht bei Halbsperrungen) von jedem Benutzer erstellt werden, der länger als vier Tage angemeldet ist.
• … werden gekennzeichnet durch:
  • Artikelneuanlage durch berechtigten Benutzer
  • Artikelbearbeitung durch berechtigten Benutzer, wenn vorige Version als gesichtet gekennzeichnet war
  • Artikelbearbeitung durch berechtigten Benutzer, wenn dieser die Markierung “gesichtet” (vergleichbar zur Markierung “Kleine Änderung“) setzt
  • Explizite Markierung als gesichtet ohne Änderung vorzunehmen.
• Bis auf die letzte Möglichkeit werden die Kennzeichnungen nicht ins Logbuch oder in die Versionsgeschichte übernommen.

Für beide Kennzeichnungen gilt:

• Es wird neue MediaWiki-Funktionen geben um bspw. nichtgekennzeichnete Artikel aufzulisten.
• Die standardmäßige Darstellung für unangemeldete Benutzer kann in den MediaWiki-Optionen gewählt werden. In der Wikipedia wird während der Testphase die letzte geprüfte oder gesichtete Version angezeigt.
• Es wird ein Hinweis angezeigt, wenn eine aktuellere nichtgekennzeichnete Version existiert.
• Bei der Darstellung von Artikeln die weder geprüft noch gesichtet sind, wird ein Hinweis angezeigt.
• Eine ältere geprüfte Version hat keinen Vorrang vor einer neueren gesichteten Version.

Kritik
Ich finde beispielsweise die Beschränkung der Prüfer auf ein vorher festgelegte Themengebiet diskussionswürdig.

Wie zu erwarten ist ein umstrittener Punkt auch die Wahl der Standard-Anzeige für nicht-angemeldete Benutzer. Diese führt dazu, dass unterschiedliche Benutzer unter einer URL verschiedene Inhalte angezeigt bekommen.

Diskussionen finden statt …

• … auf der Diskussionsseite zu den geprüften Versionen.
• … auf der Diskussionsseite zu den gesichteten Versionen.
• … in der Mailingliste der deutschsprachigen Wikipedia.
• … und vermutlich noch an anderen Stellen.

Disclaimer
Wie üblich gilt: “It’s a wiki.” Die in diesem Artikel beschriebenen “Fakten” sind nicht in Stein gemeisselt und die Wahrscheinlichkeit, dass es noch zu Veränderungen kommen wird ist groß. Dennoch sollte dieser Artikel in Vergleich zu vielen anderen der Wahrheit [TM] bisher am nächsten kommen :-)

Seit geraumer Zeit besteht der Wunsch, dieses Verfahren zu vereinfachen und vor allem aus dem “Pull”-Verfahren ein “Push”-Verfahren zu machen. Dieses sollte weitestgehend einfach für jede Person benutzbar sein, so dass es sich anbietet, bei Änderung einer zu beobachtenden Seite eine E-Mail zu verschicken.

Bereits seit Ende 2004 existiert eine Lösung für dieses Problem: die MediaWiki-Extension “EnotifWiki” von Thomas Gries. Seit Anfang 2006 wurde diese Extension direkt in MediaWiki (ab Version 1.4) übernommen.

Der Haken an der Sache: Obwohl diese Funktion in der Software enthalten ist, ist die entsprechende Funktion in der Wikipedia aufgrund von Performance-Bedenken bisher deaktiviert.

Seit gestern gibt es aber eine andere einfache Möglichkeit, Änderungen an ausgewählten Artikel zu überwachen: durch das Abonnieren eines entsprechenden RSS-Feeds. Eifrige Blogleser werden wissen, was gemeint ist, alle anderen finden in meinem Artikel “Wikipedistik per Mail abbonnieren” eine kleine Einführung in das Thema.

Wie funktioniert das ganze nun?
Schauen wir uns mal ein Beispiel an:

• Als alter Lokalpatriot bin ich sehr am Artikel über die Stadt Jülich interessiert.
• Wenn ich nun auf den Reiter “Versionen/Autoren” klicke, gelange ich auf die zum Artikel gehörige Versionsseite.
• Am linken Bildschirmrand im Menü “Werkzeuge” findet sich nun eine Zeile mit dem Inhalt “rss atom”.
• Nachdem ich mich für das RSS-Format entschieden habe, füge ich die Adresse des Links zu meinen RSS-Reader hinzu.

Voilà – die letzten 10 Änderungen kann ich nun in der Vergleichsansicht (Diff) betrachten. Mein Reader fragt in regelmäßigen Abständen die Adresse ab und weist mich daraufhin, wenn Änderungen am Artikel vorgenommen wurden.

Die Seite Wikipedia:RSS liefert weitere Informationen.

Jakob betrachtet die Unterschiede der Klassifikationssysteme (“Flache Struktur” bei Folksonomies vs. “Hierarchien” bei Wikipedia-Kategorien und hierarchischen Klassifikationen) und weist auf Probleme wie die in der Wikipedia verwendeten Polyhierarchien (“nicht strikte” Hierarchien) hin.

Im folgenden untersucht Jakob statistisch die Verteilung von Deskriptoren pro Eintrag und Einträgen pro Deskriptor unter anderem für die DDC, die englischsprachige Wikipedia und die Folksonomy des Social-Bookmarking-Dienstes del.icio.us, sowie die Level der Deskriptoren in der Hierarchie bei DDC und Wikipedia.

In seinem Posting bei Wikimetrics nennt Jakob kurz gewonnene Erkenntnisse:

I found some basic properties in structural distributions of classification, thesaurus and flat collaborative tagging:

• The number of tags per record (categories per article) is distributed exponentially with a power law tail. This also applies for the number of supercategories per category
• The level (depth) of des[c]riptors in hierarchical systems is normally distributed
• The number of records per tag (articles per category) follows a power law

(An der Uhrzeit seines Postings erkennt man den wahren Forscher…)

• Der Start meiner Erhebung über Wikis in Unternehmen inklusive Onlineumfrage verschiebt sich auf die nächste Woche.
• Heute startet der Wikipedia Workshop Köln
• Die Version 1.6 von MediaWiki ist erschienen. Ab sofort wird via “continuous integration”-Entwicklungsmodell weiterentwickelt: Vierteljährlich erscheinen Snapshots. Die letzten Entwicklungsversionen, mit denen die Wikipedia läuft, sollen in Zukunft immer “ready to run” gehalten werden. Alle veröffentlichten Versionen werden offiziell ein Jahr lang mit Sicherheitsupdates unterstützt.
• Eine kurze Anleitung, wie man sich MediaWiki unter Windows XP selber installiert, ist bei lifehacker zu finden.
• Ich gelobe, in Zukunft etwas fleissiger zu bloggen.
• Wer ihn noch nicht kennt, mag vielleicht diesen Artikel von Juli Zeh in der Zeit lesen, der letzte Woche veröffentlicht wurde.
  

  Mit einer kleinen Hand voll Wiki-Skandalen, die in den letzten Monaten das öffentliche Interesse weckten, scheinen sich die Medien um eine Bestätigung dieser These zu bemühen. Ein paar spaßig gemeinte Falscheinträge in einem Lexikon, das jedem Interessierten offenen Zugang bietet, keine Online-Polizei kennt und allein im deutschen Raum inzwischen fast 400000 Kapitel umfasst, können jedoch kaum darüber hinwegtäuschen, dass die auf Goodwill, Selbstreinigung und autonome Regulierung setzende Wikipedia vor allem eins tut: Sie funktioniert.