Oskar Welzl: Weblog zur Homepage

Die ganze Sache mit „HTML“ 5 war mir nie geheuer. Schon seit 2008 verfolge ich mit großer Sorge die Entwicklung, die immer weiter weg führt von dem Erfolgsmodell World Wide Web, wie wir es kannten.

Neuester Streich im Dunstkreis von „HTML“ 5 ist die in Arbeit befindliche Spezifikation Encrypted Media Extensions. Sie wird von Google, Microsoft und Co. getrieben und standardisiert einen Weg zum Einbinden von DRM („Digital Restrictions Management“ oder „digitale Rechteminderung“) direkt im Herzen des World Wide Web, in den vom World Wide Web Consortium (W3C) abgesegneten technischen Empfehlungen.

Die Auswirkungen wären beträchtlich. Natürlich gibt es zum einen die direkten Folgen, die jeder spüren wird. Derzeit ist das Web eine offene Plattform. Notwendige Zugangsbeschränkungen zum Beispiel zum eigenen GMX-Account lassen sich über Mechanismen wie Benutzername/Passwort realisieren. Das wars dann aber auch schon. Was ich einmal in meinem Browser angezeigt bekomme, kann ich

• so oft sehen, wie ich möchte,
• speichern,
• verschicken,
• von anderen Programmen als dem Browser verarbeiten lassen

und so weiter. Wenn ein sogenannter „Rechteinhaber“ das verhindern will, muß er sich auf eine andere Infrastruktur verlassen und zum Beispiel auf kommerzielle Browser-Plugins ausweichen. Das ist mit Aufwand verbunden und daher eher die Ausnahme.

Wenn ein DRM-Mechanismus im Web standardisiert wird, liegt die Latte niedriger. Es wird einfacher sein, Inhalte zu beschränken - und es wird daher häufiger vorkommen. Ein Video darf nur 1x angesehen werden, fürs zweite Mal muß man erneut zahlen. Ein Katzenfoto darf man ansehen, aber nicht an Freunde verschicken. Den wissenschaftlichen Artikel kann man online lesen, aber nicht abspeichern. Musik darf man streamen, aber nicht aufs Handy überspielen. Alles, was bisher nur aus den Walled Gardens von Apple & Co. bekannt war, wird dann Teil des heute noch freien World Wide Web.

Es gibt aber noch ein zweites, tieferliegendes Problem: Wenn DRM-Mechanismen so leicht von einer Webseite angefordert werden können, dann müssen sie auch halbwegs verläßlich in den Browsern implementiert werden. Ein Browser, der die Funktion nicht bereitstellt, würde vom einfachen Benutzer nicht als moralisch überlegen, sondern als nicht funktionstüchtig wahrgenommen. (Ähnlich wie Handy-Browser ohne Flash-Unterstützung.) Bleibt die Frage: Wie lösen quelloffene, freie Browser das Problem? Eine Implementierung im offenen Teil des Codes ist problematisch, sie könnte ausgehebelt und von den Anbietern als nicht ausreichend sicher eingestuft werden. Bleibt eine Implementierung als proprietäres Plugin, ähnlich wie Flash … mit all ihren Nachteilen: Ein proprietäres Plugin wird nicht auf allen Betriebssystemen und nicht für alle Versionen zur Verfügung stehen, darf aus rechtlichen Gründen nicht einfach so weitergegeben werden, kann bei technischen Problemen nicht schnell repariert werden usw. usw.

Bürgerrechtsbewegungen wie die EFF oder Defective By Design kämpfen einen ersten Kampf, in dem es darum geht, öffentliches Bewußtsein für dieses Problem zu schaffen. In einer von mir unterzeichneten Petition forderten sie das W3C auf, die Arbeit an diesem Projekt einzustellen. Natürlich lassen sich Microsoft und Google nicht von ein paar tausend Unterstützungserklärungen abhalten. Aber darum gings aus meiner Sicht auch nicht. Es geht jetzt zunächst darum, das Thema überhaupt bekannt zu machen und es zu ermöglichen, daß Internet-User sich eine Meinung bilden.

Um die online-Petition „Wiener Linien & Open Data” unterschreiben zu können (Artikel dazu gibts hier), hab ich mir die Bürgerkarte in Form der Handy-Signatur besorgt. Sie gilt als qualifiziertes Zertifikat im Sinne des Signaturgesetzes und soll mir auch andere Behördenwege ersparen helfen: Pensionsantrag, Diebstahlsanzeige, Meldebestätigung, Rechtsmittel im Verwaltungsverfahren, Staatsbürgerschaftsnachweis, Wahlkarten, … Das alles und noch mehr soll ich online erledigen können, ohne Zusatz-Software, ohne Chipkarte, nur mit dem Handy und dem PC.

Wie funktionierts nun in der Praxis?

The Good

Ich wollte die Petition online unterschreiben. Ich konnte die Petition online unterschreiben. Die praktische Anwendung ist simpel: Telefonnummer und Passwort eingeben, auf TAN warten (kommt per SMS), TAN eingeben, fertig.

Der Anmeldevorgang zur Handy-Signatur führt zwar über insgesamt drei völlig unterschiedlich gehaltene Websites, was ernsthafte Zweifel an der Seriosität des Angebots aufkommen läßt. (a-trust verweist auf Handy-Signatur.at, von dort gehts weiter zu Sendstation.at.) Ist man dann aber erst mal bei Sendstation angekommen, verläuft der erste Teil der Registrierung schmerzlos. (Wer die Voraussetzungen für diese Anmeldung per Online-Banking nicht erfüllt, findet auf Handy-Signatur.at genügend Alternativen.) Leider ist das aber nur der erste Teil …

Ach ja, auch noch „good“: Die Handy-Signatur ist gratis.

The Bad

Auch bei der von mir gewählten Online-Anmeldung ist die Handy-Signatur nicht sofort startklar. Als letzter Schritt im Prozess wird nämlich eine PIN per Briefpost an die Meldeadresse geschickt. Wahrscheinlich soll damit sichergestellt werden, daß die Adresse wirklich stimmt. Das ist einerseits frustrierend (wer online registriert, will online bedient werden), funktioniert außerdem aber auch nicht. Ich habe am 25.3. den online-Teil der Registrierung abgeschlossen. Der Brief sollte „innerhalb von 2-3 Werktagen“ bei mir ankommen. Heute, am 3.4., hatte ich ihn im Postkasten: das sind sechs Werktage, mehr als eine Woche. Ausgedruckt wurde er am 28.3., Poststempel trägt er sicherheitshalber gleich keinen. Man sollte also, wenn man die Handy-Signatur beantragt, besser nichts Dringendes damit erledigen wollen.

Bei der Gelegenheit konnte ich übrigens auch gleich den Telefonsupport kennenlernen. Ich hab dort nämlich angerufen, weil ich wissen wollte, ob irgendetwas nachvollziehbar „hängt“ im System. Die Hotline „weiß grundsätzlich nichts“ (das war der erste Satz nach der Schilderung meines Problems), verläßt sich auf hilfreiche Anregungen durch den Neukunden („Könnten Sie vielleicht dies oder jenes nachsehen?“ - „Ah ja, das geht schon.“) und gibt im Brustton der Überzeugung zwei völlig widersprüchliche Informationen zum Status meiner Anmeldung. Daß es sich dabei um eine kostenpflichtige 0900er-Nummer handelt, macht die Sache nicht besser, ist aber eine lustige Zusatzinfo, wenns um meinen Lieblingssatz in diesem Gespräch geht: „Könnten Sie bitte langsamer sprechen?“

The Ugly

Nachdem ich die Petition erfolgreich unterzeichnet hatte, wollte ich noch weitere Standardanwendungen ausprobieren: Den kostenlosen „e-Tresor“ (2GB Cloud-Speicher), das Signieren von PDFs sowie das Überprüfen einer Signatur. Das Login in den e-Tresor schlug fehl, die Anwendung zur Signaturüberprüfung erklärte mir, daß das soeben erst am gleichen Server von mir selbst signierte PDF eine ungültige Signatur mit 0 Bytes aufwies. Das schafft kein Vertrauen in die Infrastruktur. Ich bin mir nicht sicher, ob ich diese mobile Bürgerkarte jetzt verwenden will, um mir meine Behördenschreiben (RSa und RSb) elektronisch zustellen zu lassen. Von einer eGovernment-Lösung hätte ich grundsätzlich erwartet, daß sie funktioniert.

Weil wir gerade - siehe hier - in Statistiklaune sind: Mit welchen Systemen und Geräten kommen die Leser auf mein Blog? Wie haben sich die Anteile der Betriebssysteme seit 2005 verändert?

	2005	2008	2010	2012
Windows	87%	85%	78%	60%
Linux ¹)	5%	7%	14%	15%
iOS	0%	0%	1%	10%
Symbian	0%	0%	0%	7%
OSX	6%	6%	6%	6%
andere	2%	2%	1%	2%
¹) GNU/Linux und Android

OSX bleibt absolut konstant bei 6%, seit 7 Jahren. Keine Veränderung. Trotzdem entwickelt sich Apple: Die iOS-Anteile liegen 2012 bei 10%.

Mobile Betriebssysteme spielen überhaupt erst in der 2012er-Statistik eine nennenswerte Rolle. Vorher gingen sie großteils in „andere“ unter bzw. hielten sich bei „Linux“ versteckt. (Es gibt einen großen Anteil an N900/N9-Usern. Aus einer Auswertung ausschließlich der mobilen Betriebssysteme 2010 weiß ich, daß rund 70% aller mobilen Besucher mit einem solchen GNU/Linux-Gerät unterwegs waren.) Das überrascht mich doch sehr. Ist die mobile Revolution wirklich erst während der letzten zwei Jahre bei meinen Lesern angekommen? Immerhin: Geschrieben wird dieses Blog seit 2003 auf dem Mobiltelefon!

Windows verliert als einziges System, das dafür konstant und stark. Von ursprünglich fast 90% auf jetzt 60%, das ist ein herber Einbruch.

Einzige Unschärfe der Statistik: Ich kann in der Zeile „Linux“ nicht zwischen Android und einem Desktop-GNU/Linux unterscheiden. (Daher auch die unglückliche Bezeichnung der Zeile.) Die Zuwächse gehen, wenn ich mir die Browserkennungen in den Datensätzen ansehe, aber nicht so stark wie erwartet aufs Konto von Android.

Absolut keine Rolle spielen Systeme wie Blackberry und Windows Phone. Die rund 2% der Kategorie „andere“ setzen sich zum großen Teil aus nicht identifizierbaren Systemen und uralten Windows-Versionen (Windows 98!) zusammen. Außerdem findet man dort auch einen erstaunlich hohen Anteil an Zugriffen, die über den Proxyserver von Opera Mini gelaufen sind.

Zuletzt noch die Basis für die Zahlenspiele: Mein Counter liefert jeweils die Ausstattung der letzten 3000 Besucher. Es handelt sich also bei keiner der Spalten um einen Jahresdurchschnitt, sondern um die Werte der letzten 3000 Leser vor dem Abzug der Daten.

Wieder mal ein bißchen Statistik: Wie finden die Leute mein Blog? Über welche Suchbegriffe locke ich derzeit die Leser zu mir? Trommelwirbel - die Top 20 der letzten 3000 Besucher:

1. mit stäbchen essen
2. hagelkorn
3. oskar welzl
4. jede zelle meines körpers ist glücklich
5. freester fischerfest
6. nokia n9 pr 1.3
7. heißer feger
8. schlafwagen öbb
9. nokia belle c7
10. titten
11. mann mit brüsten
12. dorf und schlachtefest mölschow
13. lächeln und winken pinguine
14. öbb schlafwagen
15. jens jessen anglizismen zur psychologie des sprach importeurs analyse
16. breiten und längengrad herausfinden
17. tablet vivaldi
18. qt zukunft
19. nokia 6110 navigator update
20. sms mit pc empfangen und beantworten

Schon Platz 1 ist faszinierend: Ich habe nie einen Eintrag zum Thema „mit Stäbchen essen“ veröffentlicht. Warum glaubt Google, daß man bei diesem Suchbegriff trotzdem auf meinem Blog fündig wird? Dieses Kommentars wegen. Ich hab dem Erik erklärt, wie Multitouch auf einem resistiven Touch-Screen mit Stylus funktioniert. „Hagelkorn“ bezieht sich auf meine Augen-OP, „Jede Zelle meines Körpers in glücklich“ ist seit dem erscheinen des Artikels 2008 ein Dauerbrenner auf diesem Blog. Für die „Titten“ kann ich nichts, bitte bei Helena beschweren. Auch den „Mann mit Brüsten“ hab ich nur drin, weil Herr Deep_Blue so lieb drum gebeten hat. Offenbar steht er drauf - und viele andere, wie Platz 11 beweist. :)

Schön finde ich, daß abseits dieser etwas schrägen Suchanfragen (Ist das wirklich mein Publikum? „Mann mit Brüsten“???) auch Themen wie das Vivaldi-Tablet und der Artikel über die SMS-Beantwortung mit HeySMS Beachtung finden bzw. aktiv gesucht werden. Immerhin neun der 20 Spitzeneinträge haben einen seriösen, technischen Hintergrund. Sehr fein.

Seltsames gibt es dann auch unter den Suchanfragen, die weniger oft vorkommen. „Wo wohnt Sido?“ wollen viele wissen. Hier, in Trassenheide. „Ist es schlimm wenn man mit eingeschalteter Klimaanlage einschläft?“ fragt ein anderer. Keine Ahnung. Anregungen zum Thema „Grüßen auf dem Klo“ erhofft sich da ein Besucher. Von den Trackshittaz überfordert sind Leser, die nach „Tepf Bedeutung“ suchen. Bezaubernd finde ich die wahrscheinlich ernst gemeinte Frage „Macht Nutella schlank?“ - sicher doch! Und viel Vitamine und Ballaststoffe sind auch drin!

Daß Suchbegriffe zum Thema Liebe an und für sich eintrudeln (und zwar jede Menge), habe ich diesem und diesem Eintrag zu verdanken. „Männern beim Onanieren kostenlos zuschauen“ will da einer. Nochmal: nicht bei mir, Leute. Geht rüber zu cam4, da gibts alles fein sortiert nach Männern und Frauen und Paaren, live und kostenlos. „Geil Oskar“ find ich lieb, herzlichen Dank dafür. („Unwetter Oskar“ gabs auch.) Daß jemand für „richtig onanieren“ eine Internet-Suchmaschine bemühen muß, ist dann fast schon ein bißchen traurig. Schließlich ist da noch die Suchanfrage „Gummistiefel der Nachbarin“, bei der ich auch den Verdacht habe, sie könnte in diese Kategorie fallen. Wer immer es war - herzlichen Dank für das Bild, das ich jetzt wieder ewig nicht aus dem Kopf bekomme.

Schließlich gibts Suchbegriffe, da weiß man einfach, wer sie eingegeben hat. „Warme Küche Halloren“. Servus Conny! *LOL*

Nach mehreren Anläufen (siehe hier und hier) und einem über Jahre gequälten Testblog ist es nun soweit: Dieses Blog ist mit RDFa-Markup angereichert. Mit RDFa kann ich standardisierte, computerlesbare Zusatzinformationen in die Seite einfügen. Leider verhindert twoday.net, daß ich das volle Potential der Technologie ausschöpfe (dazu mehr später), aber zumindest ein paar Basics zur Seitenstruktur konnte ich umsetzen. Eine Suchmaschine erkennt nun besser, was der eigentliche Artikel ist, wo die Kommentare anfangen, ob ein Datum einfach nur zufällig auf der Seite steht oder die Erstellungszeit eines Kommentars bezeichnet und so weiter. Wie das konkret aussieht, zeigt Google. Dieser Artikel wird von der Maschine so verstanden. (Die grafische Darstellung ist hier zu finden.)

Erfahrungen? Grundsätzlich positiv. Ich habe RDFa 1.1 verwendet und bin so den Fallstricken aus dem Weg gegangen, über die man stolpert, wenn man den Server nicht selbst kontrollieren und deshalb kein echtes XHTML ausliefern kann. In einigen Fällen hätte ich mir die elegante Namensraum-Systematik von XHTML und RDFa 1.0 zurück gewünscht, aber das ist wohl nur Geschmackssache.

Ein bißchen übel war, daß ich ständig auf das Vokabular aus schema.org Rücksicht nehmen mußte. Man kann darauf nicht verzichten, weil die großen Suchmaschinen dieses Vokabular bevorzugt verwenden. Andererseits ist schema.org teilweise extrem mühsam und umständlich. Es dupliziert längst vorhandene Funktionen aus anderen Vokabularen, tut dies dann aber nur halbherzig oder kompliziert … Man merkt einfach, daß hier oberflächlich zusammengeschustert wurde, während etablierte Standards wie Dublin Core oder SIOC durch jahrelangen Input aus der Community ausgereift sind. Beispiel: Das Beschreiben von Kommentaren und Antworten auf Kommentare ist in schema.org de facto unmöglich. In SIOC? Ein Kinderspiel. Oder: Das Hervorheben des Autors, wenn man nicht gleich den ganzen Namen verraten, sondern sich auf ein Pseudonym beschränken will (wie hier üblich). Im RDF-Universum leicht über Dublin Core abzuhandeln, mit schema.org ein Eiertanz.

Mein Kompromiß: Ich verwende mehrere Vokabulare parallel. Mag sein, daß Google und Yahoo! keine Informationen aus SIOC, FOAF oder Dublin Core auswerten wollen, aber vielleicht tuts ja jemand anderer. Wo es ging, hab ich auch schema.org verwendet.

Die große Enttäuschung kommt nicht aus RDFa, sondern von unserem twoday.net-Server. Ich kann hier nämlich appetitliches RDFa in die fixen Abschnitte rund um die Blog-Postings und Kommentare herum einbauen. Ich kann RDFa aber nicht im Blog-Posting selbst verwenden. Das reduziert die Nützlichkeit dann doch. Die fixen twoday-Vorlagen wissen ja nichts über den Inhalt des Artikels. Sie wissen, was Überschrift, was Artikel, was Kommentar ist. Sie wissen, wo das Erstellungsdatum steht, in welche Unterkategorie der Artikel gehört, wer ihn geschrieben hat. Diese Informationen kann ich also in RDFa übersetzen. Genau das habe ich getan, genau das kann Google jetzt verwenden. Was nicht geht ist, den Inhalt selbst aufzufetten. RDFa würde mir erlauben, bei Rezepten genau anzugeben: Was ist eine Zutat, welches Foto stellt das fertige Gericht dar, welcher Teil des Textes bezeichnet die Zubereitungszeit, … Oder bei Ereignissen wie meinem Geburtstag oder einem Konzert: Was genau ist es, wo findet es statt, wann beginnts, wie lange dauert es, … Oder auch nur beim Foto neben dem Blog-Artikel anzugeben, wen es abbildet. Nichts davon kann twoday.net. Ich kann den entsprechenden Code beim Erstellen des Artikels zwar eingeben, beim Löschen aber fliegt er raus, weil der Server ihn nicht für gültiges HTML hält. Schade.

Immerhin: der Anfang ist gemacht. Wir sind Semantic Web! :)

Seit 2007 gibt es im Semantic Web einen eindeutigen Bezeichner für mich: http://www.welzl.info/id/oskar.welzl. Jeder, der etwas über mich sagen möchte, kann diese URI als eindeutiges Subjekt verwenden.

Seit einigen Tagen habe ich auch eine WebID, die mich fürs Login auf neuen Seiten eindeutig identifiziert.

Seit vorgestern sind die beiden Dinge eins. Beides ist ja schließlich drauf aus, mich zu identifizieren. Beides beschreibt mich mittels RDF, noch dazu weitgehend mit dem gleichen Vokabular. Wozu also zwei Öltanks sein? Schwupps hab ich die WebID-spezifischen Teile (also vor allem die Zertifikats-Informationen) in die Daten über http://www.welzl.info/id/oskar.welzl eingebaut … Pfeift schon!

Ganz nebenbei gabs (neben inhaltlichen Updates) noch die Umsetzung eines genialen Vorschlags, den Daniel E. Renfer (aka duck1123) auf meinem µBlog gepostet hat:

http://www.welzl.info/id/oskar.welzl existiert ja nicht als Dokument - klar, weil Die URI mich bezeichnet und nicht eine Datei im Web. Der Server schickt stattdessen http://www.welzl.info/id/o.w mit Informationen über http://www.welzl.info/id/oskar.welzl zurück, und zwar je nach Client-Anforderung entweder als maschinenlesbare RDF/XML-Datei oder als für Menschen verdaubare HMTL-Seite. Daniel hat nun vorgeschlagen, auch die HTML-Version mit RDFa anzureichern und somit maschinenlesbar zu machen. Hab ich gleich eingebaut - funktioniert perfekt!

Ich liebe es, wenn sich am Schluß alles so einfach zusammenfügt. Ich bin einfach immer http://www.welzl.info/id/oskar.welzl. Egal ob jemand Informationen über mich veröffentlicht oder ob ich selbst mich mittels WebID irgendwo einlogge. Die Bezeichnung ist immer http://www.welzl.info/id/oskar.welzl. So einfach muß es sein.

Ich stoße auf ein neues Webservice/Forum/… Was muß ich üblicherweise tun, um teilzunehmen? Benutzername und Passwort festlegen, immer die gleichen Daten einpflegen (Name, Mail-Adresse, Homepage, …), vielleicht ein Foto hochladen … Es ist immer der gleich langweile Vorgang. Am Ende hab ich dann einen Account auf einer Seite, die ich nach zwei Wochen nie mehr wieder benutze.

Es gibt verschiedenste Versuche, diese unnötigen Eingaben überflüssig zu machen. Die dümmste und gefährlichste Variante ist, sich mit existierenden Facebook- oder Google-Accounts auf fremden Seiten einzuloggen. Viel besser, weitgehend etabliert und ausreichend offen dagegen ist OpenID. Dabei handelt es sich um ein dezentral angelegtes Protokoll. Ich kann mir einen beliebigen OpenID-Provider aussuchen, mich dort registrieren und von da an auf jeder OpenID-kompatiblen Seite mit immer den gleichen Daten einloggen, ohne mich dort nochmal extra registrieren zu müssen. Das ist die Technik, die ich selbst derzeit am häufigsten verwende.

Gerade entdecke ich eine weitere Alternative, an der zwar noch gebastelt wird, die aber aus meiner Sicht sehr spannend wirkt: WebID. Das System funktioniert auf Basis etablierter Standards wie TLS, X.509-Zertifikaten und RDF. Im Prinzip liegt die ganze Standard-Information über mich in einem RDF-Dokument, das das FOAF-Vokabular benutzt. Zusätzlich enthält dieses Dokument den öffentlichen Schlüssel eines Zertifikats, das ich in meinem Browser abgelegt habe. Wenn ich mich nun erstmals auf einer mir bisher unbekannten Seite einlogge, verlangt die von mir ein Zertifikat (das ich über ein Drop-Down im Browser auswähle). Im Zertifikat hinterlegt ist die Adresse des WebID-Dokuments, das meinen Namen, mein Foto und andere Informationen enthalten kann. Paßt der öffentliche Schlüssel im WebID-Dokument zu dem Zertifikat, mit dem sich mein Browser gerade identifiziert hat, dann wird mein Login akzeptiert und ich habe ohne jeden Aufwand ein neues Profil angelegt.

Natürlich geht niemand davon aus, daß Leute (so wie ich gestern) ein Zertifikat auf der Kommandozeile erstellen und das dazugehörige RDF-Dokument per Hand editieren und hochladen. Der Normalfall wird sein, daß ein Webservice, das WebID unterstützt, Zertifikatsgenerierung und Anlegen eines WebID-Dokuments für bestehende User automatisiert. Daß ich aber auch meine eigene, handgestrickte WebID verwenden kann, ist eine durchaus feine Sache: Ich mag Technologien, die ich auch ganz auf mich allein gestellt und unabhängig von irgendeinem Drittanbieter nutzen kann. WebID scheint so etwas zu sein. Simpel und effizient. (Einziger Nachteil, wie bei allem, was auf Verschlüsselung beruht: Irgendwie muß man einen Weg finden, das WebID-Zertifikat bei sich zu tragen. Sonst klappts nicht mit dem Login im Internet-Café.)

Tips zum Ausprobieren: Dieses Script hilft beim Erstellen eines Zertifikats mit OpenSSL; MyProfile ist ein experimentelles Service, bei dem man sich mit WebID einloggen kann.

Irgendwann im Jahr 2006 habe ich beschlossen, unterhalb der Beiträge in diesem Blog Werbeanzeigen von Google schalten zu lassen. Reich hats mich nie gemacht, aber eine Pizza pro Jahr war drin.

Heute bekomme ich Post vom amerikanischen Bruder: Dieses Blog verstößt wegen seiner pornographischen Ausrichtung gegen die Benutzungsrichtlinien. Ich habe drei Tage Zeit, die problematischen Textstellen zu löschen. Ansonsten wird mein Google-Account gesperrt. Eine Antwort auf die Mail ist nicht möglich.

Liebe Kinder drüben überm großen Teich, ich schreibt Euch hier jetzt mal was wirklich Pornographisches rein: Ihr könnt Euch mit ████████ ██████████ die ███ █████████, bis ████████████ ████ █████████ mit Nägeln ██████████ ████ hat. ;)

Allen anderen Lesern: Schämt Euch! Schämt Euch dafür, daß Ihr Euch jahrelang an meinen perversen Texten hier aufgegeilt habt!

2008 habe ich zum ersten Mal versucht, maschinenlesbare Zusatzinformationen nach der (damaligen) RDFa-Spezifikation in ein twoday.net-Blog einzubauen - und bin kläglich gescheitert. In den letzten Monaten hat sich aber einiges getan: RDFa 1.1 wird sich, das ist abzusehen, wesentlich von der 2008 gültigen Version 1.0 unterscheiden und dadurch technische Probleme aus dem Weg räumen. Außerdem gibt es neue Antworten auf die Frage nach dem „Warum?“. Wo also stehen wir 2012? Und was könnte ich für mein Blog hier verwenden?

Ich habs im RDFa-Testblog von 2008 ausprobiert. Was eine Maschine daraus lesen kann, wird in diesem Diagramm sichtbar. Ziemlich beeindruckend, finde ich. Aber sehen wir mal im Detail, was für mich neu war:

Vorweg: Alle folgenden Aussagen zum „neuen“ RDFa beziehen sich auf eine Version 1.1, die noch nicht als offizielle W3C-Empfehlung vorliegt. Noch wird daran gefeilt - sehr heftig sogar. Ich gehe aber davon aus, daß der Editor’s Draft vom 15.12.2011 dem Ergebnis sehr nahe kommen wird … sofern es überhaupt ein Ergebnis gibt, doch dazu später.

• RDFa verläßt sich nicht mehr auf den XML-spezifischen Mechanismus der Namensraum-Deklaration, um ein Vokabular einzuführen. Das ist zwar deutlich weniger elegant, ermöglicht aber die Nutzung in Dokumenten, die kein XML sind - wie z.B. in twoday.net-Blogs. Heißt: Ich konnte im Testblog RDFa einbauen ohne mich darum zu kümmern, ob die ganze Tagsoup drumherum irgendeinem (X)HTML-Standard entspricht. Tatsächlich habe ich das Ergebnis von neuen RDFa-Parsern lesen lassen, es funktioniert.
• Die Autoren von RDFa haben unter dem Namen „RDFa Lite“ ein Subset definiert, das in seiner Funktionalität sehr stark an das von der Industrie bevorzugte Microdata-Modell erinnert. Microdata ist simpler, aber zentralistischer, weniger leistungsfähig und vor allem weniger flexibel als RDFa. Wahrscheinlich wird es aber für RDFa wichtig werden, eine Microdata-ähnliche, allgemein anerkannte Mindestvariante anbieten zu können. Im Testblog habe ich einfach versucht, möglichst konform zu RDFa Lite zu bleiben (und somit implizit auch „in Microdata zu denken“). Das ist mühsam und umständlich, wenn man RDF gewöhnt ist. Außerdem schränkt es die Möglichkeiten doch sehr ein: Die Einfachheit kommt nicht ohne Preis, manches läßt sich in „Lite“ einfach nicht mehr ausdrücken.
• Im Juni 2011 mußten die um ein semantisches Web bemühten Personen und Organisationen zunächst einen herben Rückschlag einstecken: Mit schema.org haben Google und andere Suchmaschinenbetreiber das Rad neu erfunden und ein auf Microdata basierendes Vokabular vorgestellt, das alle bestehenden völlig ignoriert. Ein Licht am Horizont gibt es erst wieder seit November: RDFa Lite soll von den Suchmaschinenbetreibern gleichberechtigt mit Microdata als Syntax anerkannt werden - solange das schema.org-Vokabular verwendet wird. In der Praxis könnte das bedeuten: Eine Website verwendet volles RDFa 1.1 (also nicht nur die lite-Version) mit etablierten Vokabularen (SIOC, Dublin Core, FOAF, …) und den Ausdrücken aus schema.org. Die großen Suchmaschinen lesen nur, was als RDFa Lite gültig ist und schema.org-Vokabeln enthält, während alle zusätzlichen Informationen für fortgeschrittene RDF-Anwendungen unverändert erhalten bleiben. Ob Google tatsächlich schon RDFa 1.1 Daten aus meinem Testblog liest, bezweifle ich erst mal. Wahrscheinlich warten die, bis die Spezifikation engültig fest steht.

Apropos bis die Spezifikation engültig fest steht: Spannend wird, wie sich das W3C aus der Sache mit den konkurrierenden Standards RDFa und Microdata herauswindet. Es gibt Bestrebungen, die Veröffentlichung beider Spezifikationen zu unterbinden und darauf zu warten, daß die beiden Gruppen sich einigen. Andererseits wäre es nicht das erste Mal, daß zwei Standards parallel existieren, die mehr oder weniger dem gleichen Zweck dienen.

Wenn sich die Geschichte wiederholt, wird der schlechtere Ansatz (Microdata) sich gegen den überlegenen (RDFa) durchsetzen … so wie sich „HTML“ 5 durch die Macht der Konzerne gegen das wesentlich brilliantere XHTML 2 durchsetzen konnte. Noch ist aber nicht alles verloren. Der Kunstgriff mit „RDFa Lite“ könnte noch einiges ändern. Mal sehen.

Einen guten Überblick über den aktuellen Status von RDFa bietet Ivan Herman im Artikel Where we are with RDFa 1.1?. Eine Gegenüberstellung von RDFa, Microdata und den etwas in Vergessenheit geratenen Microformats hat Manu Sporny unter dem Titel An Uber-comparison of RDFa, Microdata and Microformats veröffentlicht.

Mein Weblog bekommt Besuch von N9-Besitzern. In den Aufzeichnungen des Counters finde ich diesen UA-String:

Mozilla/5.0 (MeeGo; NokiaN9) AppleWebKit/534.13 (KHTML, like Gecko) NokiaBrowser/8.5.0 Mobile Safari/534.13

Wie aufregend! :)