Wieviele RSS-Versionen gibt es?

Na, was schätzt Ihr? Ich habe im ersten Anlauf 5 getipt - und lag damit knapp über der Hälfte. Sage und schreibe neun sind es nämlich, und Mark zählt sie alle auf: The myth of RSS compatibility [dive into mark]

<rant>Da soll mir doch mal einer sagen, das wäre eine ausgereifte Technik ;-)</rant> Und jetzt gibts auch noch was neues, nämlich Atom. (Der ‘Streit’ RSS vs. Atom: Kommenatare zur Meldung über einen neuen Validator. Scheint übrigens beigelegt zu sein.)

Atom ist ein spannendes Thema. Der Gedanke dahinter ist simpel: RSS funktioniert, ist aber zu sehr Stückwerk und über die Jahre verwachsen. Das vielzitierte Beispiel vom title bringe ich hier nicht, das könnt Ihr woanders nachlesen. Ursprünglich ist RSS ein Tool um Überschriften zu transportieren. Nicht mehr und nicht weniger. Daraus ist mittlerweile eine bunte Ansammlung von Modulen geworden, die alles mögliche in RDF verpacken können. Aber: der Grundgedanke von RSS ist die Technik, nicht der Inhalt.

Atom ist eine Chance, ein refactoring von RSS zu machen und ein Tool zu entwickeln, das sich darüber im Klaren ist, das es Inhalte transportiert.

Ist es denn so schwer…

… RSS-Feeds Timestamps für die Artikel mitzugeben?

Nachdem Alp neulich Volltexte in den Feeds forderte [via Mark @ O’Reilly, Chris, Paul], fordere ich jetzt Timestamps für alle Artikel! Durch den Plattencrash von eben musste ich eRONA neu aufsetzen (inkl. altem DB-Backup) und habe bei der Gelegenheit gleichmal aufgeräumt: Artikel älter als 2 Wochen gelöscht, Feeds, die keiner liest, gelöscht, …

Danach war ein komlettes Update aller Feeds fällig. Was mir bisher höchtens mal unangenehm aufstiess, wenn ich meinen SharpReader mal zwei Tage nicht anhatte, fiel mir nun geballt auf: da eRONA alle Artikel alle abonnierten Feeds zeitlich geordnet darstellt… genau: 15 Artikel vom Blog X, 10 vom Blog Y und nochmal 10 vom Blog Z, alle mit dem gleichen Timestamp. Juhu. Seltsam nur, das diese 15 in Wirklichkeit in einem Zeitraum von 14 Tagen entstanden, und nicht innerhalb einer Sekunde (das ist der zeitliche Abstand, der bei der Erfassung durch eRONA entstanden ist).

Ein Blick in die Feeds zeigt dann auch schnell, das es weder an eRONA noch an magpie liegt, sondern tatsächlich an den Feeds, die den nicht unwesentlichen Timestamp einfach weglassen. Bei einigen Feeds konnte ich per Suche auf der Website einen anderen Feed finden, der Timestamps mitbringt, aber ich habe keine Lust die 209-x Feeds alle per Hand abzugrasen. Obwohl das demnächst mal passieren muss, allerdings per Skript.

Man könnte argumentieren, das sich solche Sachen spätestens nach dem ersten Komplett-Update einpendeln. eRONA holt im Moment alle 2h die Feeds ab, also ist das Fenster recht klein, in dem man mehrmals schreiben muss, um den oben beschriebenen Effekt hervorzurufen.

Doch die Zeitangaben stimmen einfach nicht. eRONA (oder eben $put_your_favorite_feedreader_here) zeigt normalerweise den Zeitpunkt an, an dem ein Artikel veröffentlicht wurde. Das macht sie nicht, weil sie es will, sondern weil es ein für den Leser sinnvoller und wichtger Hinweis ist. Was soll ein Feedreader machen, wenn der Feed keine Timestamps beinhaltet? Raten? Nein, er nimmt einfach den Zeitpunkt der Erfassung. Und schon haben wir falsche Daten im Feedreader.

Also bitte, schaut in Eure Feeds und wenn Ihr da kein pubDate oder dc:date findet, dann baut es bitte ein. Alle Eure Feedleser werden es Euch danken.

Adieu Festplatte

Das kommt davon, wenn man einen Billig-Server (39€/Monat) benutzt: gestern vormittag ist die Platte übern Jordan, und leider war das die einzige Platte im Rechner ;-)

Ein Glück ist Jens ein guter Admin, und so steht das System, jedenfalls die wichtigsten Teile, wieder. Jetzt noch die Backups einspielen. Doch die liegen auf meinem Rechner, müssen jetzt also über ADSL (1286kbit/s = 16kb/s) auf den Server… Und bei insgesamt 300MB dauert das seine Zeit ;-)

Jedenfalls ist jetzt wieder alles gut… Fast, denn wie es bei Murphy heisst: das Backup, das man am dringensten benötigt, ist immer defekt. Lediglich ein Datenbank-Backup vom 05.02. war noch i. O., der Rest ist broken. Prima.

Macht nix, also werden eben die Backups vom Januar eingespielt. Auf meinen eigenen Webs ist das nicht weiter tragisch, wichtig für mich war nur phpBB.de, und das läuft nun wieder mit den Daten vom 05.02. Das ist doch immerhin ein Trost.

Ärgerlich nur, das die Sicherungen von eRONA hinüber sind. Muss also wieder ran und schaun, was ich alles geändert hatte. Im Laufe des Wochenendes werde ich also die restlichen Webs wiederherstellen, dann wird auch iuw-darmstadt und eRONA wieder laufen. Dürckt mir die Daumen ;-)

blockquote, die Zweite

Jon gesteht cite für die Angabe des Namens mißbraucht zu haben, weil er so per XPath nach dem Namen des Zitierten suchen kann.

I’m willing to switch to the correct usage of cite, and since my content is in an XML database I can fix it backwards as well as forwards. But here’s the thing: I still want to be able to search quotes by person, not by URI. And I’d like there to be a standard way for other people to write quotes that they, or I, can search by person.
[Jon’s Radio]

Good point. (X)HTML has no facility for this. A workaround, not breaching the syntax (but the semantic) of (X)HTML would be to use the title attribute instead of a made up one. Sure, nice is neither.

Dublin Core could help out, too. But I know off no way to incorporate DC into (X)HTML elements other than <head>. I believe, if there was a way, DC would be the best solution: it’s already there, tools can handle it and it is an open standard.

Die Nadel im Heuhaufen rutscht tiefer

Nichts wirklich neues: Wir ertrinken in der Flut der auf uns einstürzenden
Informationsmenge. (via hatch.org: Site Search Still Sucks)

Ein Symptom des Ertrinkens bzw. des Versuchs über Wasser zu bleiben ist die
gestiegene Zahl komplexerer Suchen. OneStat zufolge ist der Prozentsatz der Suchanfragen mit mehr als zwei Suchbegriffen seit 2003 um knapp 2% gestiegen. 2003 bestand ein Viertel alles Suchanfragen aus nur einem Suchbegriff, 2004 ist es nur noch ein Fünftel. Das mag auf den ersten Blick wenig erscheinen (mal abgesehen von dem Wort der Statistiken, denen man trauen kann), scheint mir aber doch eine tatsächliche Tendenz hin zu komplexeren, längeren (und frustrierenderen?) Suchen zu sein.

The search capabilities on most company and content-oriented Web sites are as bad now as they were several years ago. In fact, eWEEK Labs was dismayed to find that we could have easily rerun an article we wrote back in June 1997 on how to improve site searches. Every problem we cited is still in evidence today, and every recommendation we made would still be well-taken. Sites should be using indexes, prebuilt searches and good metatags, for example, but surprisingly few do. [Web Site
Search Leaves Users Wanting]

Sich allein auf die Suchmaschinen zu verlassen, damit die eigene Site überhaupt gefunden wird, reicht nicht. Auch die eigene Site, wenn sie denn aus mehr als nur ein paar HTML-Seiten besteht, braucht eine eigene Suchmaschine. Der Trick’, hier auf Google (oder eine andere Suchmaschine) zu verweisen ist faul und birgt
Gefahren: zum einen macht man sich vom Good-Will eines Anbieters abhängig, zum anderen nimmt Google garnicht alle Seiten auf, zum anderen kennt Google die Site nicht und wichtet nach seinen eigenen Regeln.

Eine Umsetzung der Index-Idee findet sich bswp. auf den Seiten der FH Darmstadt.

Die zweite im Artikel angesprochene Idee, vorgefertigte Suchantworten für vielgefragte Dinge zu benutzen, ist so einfach wie genial. Weiß man, was die Benutzer suchen bzw. welche Inhalte am meisten nachgefragt werden, kann man ‘Besten-Listen’ für einzelne Themen generieren, die bei Suche nach vorher festgelegten Begriffen erscheinen. Das hilft dem Nutzer und erhöht den Befriedigungsfaktor.

Eine andere Idee, die mancherorts bereits umgesetzt wird, ist die Bereitstellung themenspezifischer RSS-Feeds, mit denen Benutzer immer einen aktuellen Überblick haben. Das hat zwar nicht direkt mit der Suche zu tun, erleichert diese aber, weil man weiß, was aktuell läuft.

Xenu und Bugfix für das Quote-Bookmarklet

Jons Quote-Bookmarklet hat einen kleinen Bug: das blockquote-Attribut cite sollte eine URI sein.

Vielen Dank an Tilmann Hausherr, Autor des Link-Checkers Xenu’s Link Sleuth (TM). Nachdem ich in itst.org ein paar Linkfehler ausgemerzt hatte, blieben nur noch die Blogeinträge mit blockquotes übrig. Tilmann wies mich dankenswerterweise per Mail darauf hin, das cite eine URI sein sollte.

Mail an Jon Udell iss raus, der ‘Patch’ beschränkt sich darauf, in seiner quote.js in Zeile 62 title durch uri zu ersetzen.

Die Trolle, die ich rief…

Club Volt: Troll Attack! (via Alp, krit.de, ronsens)

Shit happens, um auf der Toilette zu bleiben.

Nach der Lektüre von Lovinks Aufsatz, A und Lorenz-Meyers Kommentar, B hier in ungeordneter Reihenfolge meine Gedanken.

Ich freue mich diebisch, das es selbst die geballte Erfahrung des ‘Who’s Who der deutschsprachigen Medienkünste’ (A) nicht fertigbekommt, mit ein paar Trollen fertig zu werden. Da mache ich mir direkt weniger Sorgen und die Heise-Foren und /. (siehe auch Quit Slashdot.org Today!). Davon mal abgesehen, kann ich nun auch wieder beruhigter schlafen, wenn jemand in meinen Foren trollt: ‘Will man ihnen jedoch nicht die Macht im gemeinsamen Raum überlassen, bleibt keine andere Wahl, als die Verantwortung für das Geschehen in die eigene Hand zu nehmen und Macht auszuüben.’, (B).

Damit denn auch direkt zum zweiten Punkt: wer glaubt, um eine Mailingliste oder ein Forum zu moderieren genüge es, sich mit den technischen Werkzeugen vertraut zu machen, der irrt. Es geht vielmehr um die menschlichen Tücken sozialer Systeme. Wie mein Professor immer sagt (und damit angeblich seine Großmutter zitiert): ‘Es menschelt’. Technik oder Technologie ist nur das Pferd, auf dem man sitzt. Es kommt aber darauf an, reiten zu können, nicht, das beste Pferd unter sich zu haben.

Nachdem es gerade um ein neues Feature für die neue phpBB-Version ging, gab es auch hier wieder Diskussionen um den Sinn und Unsinn solcher ‘community driven’ Techniken, Trolle auf lange Sicht auszuschließen bzw. ihnen den Spaß zu nehmen.

Da gibt es zum einen den Karma-Ansatz (siehe Links oben). Doch leider kann gerade diese Sache böse enden: zum einen in den Händen eines unfähigen Administrators, zum anderen in den Händen einer Meute Trolle. Eine elitäre Clique von Admins und Moderatoren kann hier genauso schädlich sein wie 20 Troll-Accounts, die sich gegenseitig hochpuschen und die anderen drücken.

Eine andere, wesentlich subtilere Methode stellt TARB dar. Die üblichen Methoden des Verwarnens oder -bannens haben den Nachteil, das der betroffene Benutzer diese Aktionen bemerkt: er bekommet eine Warn-E-Mail oder das System erzählt ihm beim Einloggen, das er ausgesperrt wurde. TARB hingegen tut nichts dergleichen: statt den Benutzer merken zu lassen, das estwas mit ihm (seinem elektronischen alter ego) geschehen ist, gaukelt es ihm völlige Normalität vor. Doch seltsam, seine Beiträge werden überhaupt nicht beachtet, alle Flame-Versuche, Beleidigungen und und und zeigen keinerlei Reaktion… Kein Wunder, denn TARB zeigt nur dem Bösewicht seine Beiträge an, sonst sieht sie (außer den Administratoren) niemand. Das Tolle daran ist eigentlich nichtmal die Umsetzung, sondern die Idee: statt es dem Spammer mit schlauen Worten und edlen Taten heimzuzahlen, machen wir uns einfach seine Boshaftigkeit zu eigen und Schlagen ihn mit seinen eigenen Mitteln. Fies, gut und effektiv.

Die Vorteile liegen klar auf der Hand. Wer das Heise-Forum liest (es genügt dazu, den Bereich der News zu verfolgen), der wird feststellen, das die Einführung der ++, +, -, — Bewertungen nur zu noch skurileren Stilblüten geführt hat (mal abgesehen von den Reminiszenzen an 1984…). Warum? Weil all diese Bewertungen öffentlich sind und die Trolle nun um die schlechtesten Bewertungen wetteifern. Ganze Websites sind zu diesem Thema bereits entstanden (Heise-FAQ bei thewalrus, Das Trollvoting bei funkbase oder DocSnyder’s Forum).

Diese Auswüchse resultieren aus der öffentlichen Bekanntgabe von Votes, Karmas oder wie auch immer man das ganze nennt. Das TARB-Tool verhindert sowas. Keine Diskussion, kein Gerangel um die meisten Einträge im Killfile der anderen. Statt dessen ein stiller und kommentarloser Abgang.

TARB ist sicher nicht das Allheilmittel, vor allem wenn es von inkompetenten, übertrieben vorsichtig oder einfach nur unerfahrenen Administratoren genutzt wird. Dann verkehrt es sich zu seinem Gegenteil und wird zu einer gefährlichen Waffe, die tatsächlich Zensur bedeutet. Vor allem funktioniert es nur in geschlossenen Foren, da in offenen Foren der geTARBte jederzeit sehen kann, das seine Beiträge unsichtbar sind. Alternativ könnten sie nur für angemeldete Benutzer unsichtbar sein. Ein guter Ansatz also, aber kein perfekter.

Grundsätzlich sollte aber jeder, der an einer (virtuellen) Diskussion, sei es in einer Mailingliste, einem Forum, dem Usenet oder einem Chat teilnimmt, sich zunächst zurücknehmen und die erste Zeit nur zuschauen, um ein Gefühl für Umgangston, Etikette und Inhalte in dem betreffenden Medium zu bekommen. Denn was in Mailingliste/Kneipe 1 völlig normal ist, kann in Mailingliste/Kneipe 2 zum sofortigen Ausschluss führen; FAQ sind zum Lesen da, nicht zum Überlesen.

Ich möchte jetzt nicht abdriften, daher Schluss für heute, ist eh wieder viel zu spät geworden.