Oskar Welzl: Weblog zur Homepage

Man kommt mit dem Abendessen in der Hand vom Büro nach Hause und erfreut sich nicht nur am Anblick, sondern auch am Duft, der sich mittlerweile (offenbar hatte er den ganzen Nachmittag über Zeit dazu) auch schon in der Wohnung ausgebreitet hat.

Meine Tür liegt verkehrsgünstig zwischen Lift und Treppe, als Verursacher kommen (wenn ich jetzt mal davon ausgehe, daß es sich um Hundekot handelt) also alle hundehaltenden Mitmieter im dritten und vierten Stock in Frage. Das sind doch einige und ich werde jetzt darauf verzichten, mittels CSI-ähnlicher Methoden den Täter aufzuspüren. Einen Verdacht hab ich aber: die Töle von gegenüber. Die legt vorm Gassi-Gehen mit Vorliebe einen Zwischenstop auf meiner Fußmatte ein, während Frauchen auf den Lift wartet. Außerdem kläfft sie auch immer so ungut. Stun-den-lang. Beweisen kann mans halt nicht.

(Ach ja: Ich hab ja in meinem Mietvertrag noch das ausdrückliche Verbot der Haustierhaltung drin. Das geht mittlerweile nicht mehr, glaub ich, oder?)

Das Beruhigende an diesem Lokal: Solange es mein Filetsteak mit Chili-Schoko-Sauce gibt, will ich nicht so recht an die Wirtschaftskrise glauben. ;)

Ein Account auf soup.io sammelt stur alles zusammen, was ich ihm sage. Das Ergebnis - soup.welzl.info - ist ein Planet-ähnlicher Mischmasch aus meinen eigenen Inhalten (aus diesem Blog, aber auch von meinem Mobile Web Server oder von delicious), vor allem aber aus Inhalten anderer Websites, die ich mehr oder weniger regelmäßig lese. Ein öffentlicher RSS-Reader? Ja, irgendwie. Nur theoretisch auch noch ein bißchen mehr.

Ehrlich gesagt hab ich noch keine Ahnung, ob mir das Ding in irgendeiner Weise nützlich sein wird oder ob es für andere einen Mehrwert bringt, aber what shall’s: Es ist gratis, es macht Spaß und ich kann es auf meiner eigenen Domain unterbringen. (Und natürlich ist es ach so „Web 2.0“! *LOL*)

Nettigkeit am Rande: Gekocht wird soup.io in Österreich, genauer in der Otto-Bauer-Gasse in Wien (siehe Impressum). Wer kann da schon nein sagen?

Was an diesem Fall so unglaublich ist: Es geht nicht etwa um die mittlerweile fast schon langweilige Frage von Urheberrechten und DRM. Apple möchte einfach nur erzwingen, daß jeder iPod-Besitzer ausschließlich die iTunes-Software zum Befüllen seines Geräts verwendet. Daran hängt Apples Geschäftsmodell: iTunes ist das Bindeglied zwischen der vom Konsumenten dankbar selbstfinanzierten Abspielstation iPod und der Geldmaschine iTunes Store. Jeder iPod-Besitzer, der andere Software verwendet, steht nicht mehr automatisch regelmäßig vor dem großen Schaufenster des iTunes Store und wird dementsprechend seltener bis gar nicht dort einkaufen.

Zwar klingt das aus Apples Sicht kommerziell nachvollziehbar, für den Konsumenten ist es aber eine Ungeheuerlicheit: Das Gerät geht mit dem Kauf in sein Eigentum über, er darf aber nicht darüber entscheiden, wie er es verwendet. Dieser Zwang zu einer bestimmten Software geht so weit, daß er auch den Zwang zu einem bestimmten Betriebssystemen mit einschließt: Windows 2000? Nein. Windows ME? Nein. GNU/Linux? Daran denkt Apple nicht mal. FreeBSD? Auch nicht, obwohl Apple den gesamten Unterbau für sein OS X von dort geholt hat. Ausschließlich Windows XP, Windows Vista und OS X werden geduldet, für Benutzer anderer Systeme ist der iPod schlichtweg nicht funktionsfähig.

Apples Sperre zum umgehen ist dabei technisch gar nicht so kompliziert und wurde 2007 bereits erfolgreich vorexerziert (daher gibt bzw. gab es bisher Programme, die Musik auf iPods schreiben konnten): Alles hängt an einer einzigen Datei (iTunesDB), die unverschlüsselt am iPod liegt. In ihr sind die Songdaten abgespeichert. Lesen kann diese Datei jeder. Zum Schreiben ist es jedoch notwendig, eine nach einem geheimen Verfahren errechnete Prüfsumme anzuschließen. Stimmt diese Prüfsumme nicht, ist die Übertragung der Datei an den iPod nicht erfolgreich. Wer Software für den iPod entwickeln möchte, muß also nur diesen Algorithmus herausfinden. 2007 dauerte das knappe 36 Stunden.

Apple hat darauf reagiert und in der letzten Firmware die Prüfsummenberechnung verändert. Zeit also, sich darüber Gedanken zu machen, wie man sie diesmal knacken könnte. Der ersten Gedankenaustausch dazu im oben erwähnten Wiki wurde nun von Apples Anwälten grob unterbunden. Überraschenderweise berufen sie sich dabei auf den DMCA, mit dem man eigentlich gegen Copyrightverletzungen vorgehen würde. Die EFF und die Betreiber des Projekts selbst sind aber (so wie ich) der Ansicht, daß jemand, der Daten auf sein eigenes Gerät schreiben will, keine Copyrightverletzung begeht und daß Apple in diesem Fall kein rechtlich schützenswertes Interesse daran hat, daß der Algorithmus geheim bleibt.

Wer sich für die juristischen Details und die Argumentationslinien beider Seiten interessiert, findet hier die Mail von Apple an Bluwiki und hier die Reaktion der EFF. Ich bin gespannt, wie die Sache weiter geht … nicht, weil ich meinen nicht vorhandenen iPod von GNU/Linux aus mit Musik befüllen möchte, sondern weil es schön wäre zu sehen, daß auch ein großer Konzern nicht einfach mit allem durchkommt. Schlimm genug, daß Leute auf die Hardware reinfallen - sie sollten wenigstens nachher noch die Chance bekommen, sich per Software aus der eisernen Umklammerung zu lösen.

Ich würd gern mal Nokias neues Service Friend View ausprobieren und habs bei mir auch schon installiert - es scheitert nur daran, daß ich keine Freunde hab. Zumindest keine, von denen ich aus dem Stand wüßte, daß sie meinen oben angeführten Mindestanforderungen entsprechen. ;)

Friend View ist eine Mischung aus „Ich sehe, wo Du gerade bist“ und Micro-Blogging. Die Beta Labs beschreiben es als an experimental research project, was weniger eine revolutionäre Idee, sondern ungetestete, halbfertige Software bedeutet. Sei’s drum. Ich find das Konzept nett und eigentlich auch ganz brauchbar umgesetzt (eine kleine Idee davon vermittelt das Promo-Video).

Also: Rührt Euch per Mail bei mir, wenn Ihr das Programm erfolgreich installiert habt. Oder fügt mich gleich zur Liste hinzu, ich verwende auf Friend View den gleichen Namen wie hier.

Bei den Browsern hat der Internet Explorer nochmal deutlich verloren und liegt erstmals unter 50%. Der Abstand zum Firefox beträgt nun nur mehr drei Prozentpunkte. Ebenfalls interessant: Abgesehen von der Aufholjagd des Firefox gibt es keine Veränderung seit 2006.

Der Anteil der regelmäßigen Leser ist von 11% auf 10% leicht gesunken, wobei allerdings die Besucherzahl insgesamt nochmal deutlich gestiegen ist: Statt 59 kommen nun im Schnitt 84 Besucher pro Tag hierher.

Was Microsoft in der Browserstatistik verliert, gewinnt es bei den Betriebssystemen wieder dazu: Rund 85% aller Zugriffe erfolgen mit einem Windows-System. Vor allen Windows Vista trägt hier zum Wachstum von MS bei, fast ausschließlich auf Kosten von GNU/Linux. Das freie Betriebssystem stürzt von 14% auf 7% ab und liegt damit nur mehr knapp über OS X, das seinen Anteil von 6% unverändert halten konnte.

Die Gruppe „Andere“ wird zunehmend bunter. Neben diversen Windows-Varianten und Unix-Derivaten finden sich hier auch immer mehr mobile Betriebssysteme (z.B. Symbian), aber auch Spielkonsolen wie Nintendo Wii.

Alle Zahlen beruhen wie immer auf der Auswertung der letzten 3000 Besucher. Prozentangaben sind gerundet.

So landen wir also im Ibis und plaudern über alte Zeiten. (Sehr alte Zeiten mittlerweile …) Er wirkt sehr entspannt und ausgeglichen. Ich glaub fast, es geht ihm gut. ;)

Ganz zum Schluß wird mir noch eine besondere Ehre zuteil: Ich darf seine Neue kennenlernen. Sie spricht sogar mit mir und führt mich schließlich heim, wofür ich ihr ausgesprochen dankbar bin.

Nett wars. Immerhin haben wir uns seit Juli 2007 nicht mehr gesehen. Wir sollten sowas öfter mal machen.

Anlaß ist die Eröffnung einer neuen Website, die ich gestern ganz zufällig mitbekommen hab: Ich hab ja hier im Februar 2007 über Drahtdesign aus dem Hause Salomon berichtet. Offenbar hat sich diese Werbung derart positiv auf die Nachfrage dort ausgewirkt, daß man sich nun entschlossen hat, der Kollektion „Swinging Candles“ einen eigenen Webauftritt außerhalb der etablierten Firmenhomepage zu spendieren.

Nicht übel, nicht übel, was da so geboten wird. Ich hab mein Teil ja schon, sonst tät ich doch glatt nochmal einkaufen (die Farbvariation Gelb-Rainbow hats mir angetan *gg*).

(Ach ja: Wer verwirrt auf einer halb leeren Seite steht und keine Navigation findet: Flash aktivieren bzw. besser gleich direkt zum Shop. Dort gibts zwar auch kein Bild, aber eine Übersicht über alle Varianten in HTML. Die Dingers sehen nach wie vor so aus wie hier auf dem Foto zu diesem Blogeintrag - nur halt in den sechs verschiedenen Farben.)

Seit dem 14.10.2008 ist RDFa eine W3C-Empfehlung. RDFa steht für „RDF in attributes“ und definiert eine Erweiterung zu XHTML, mit der RDF-Statements direkt in Webseiten eingebettet werden können. Das Internet wird dadurch ein Stück maschinenlesbarer: Suchmaschinen können diese Information verwerten und so zum Beispiel in Suchergebnissen eine Unterscheidung treffen zwischen Essen, der Stadt in Deutschland, und dem guten Essen bei der Mama. (Tatsächlich experimentiert Yahoo! in seinem Projekt Searchmonkey mit RDFa. Irgendjemand hier sollte mal über Searchmonkey bloggen …)

Natürlich habe ich mich (trotz meiner Verärgerung und Frustration über den sorglosen Umgang mit URIs) seit 14.10. mit RDFa gespielt und versucht, ob man es in einem Blog auf twoday.net einsetzen kann. Immerhin: SIOC/RDF, Planets, Geotagging und Tagging … Mein Blog hat ja schon jetzt nicht mehr allzuviel mit dem zu tun, was Knallgrau sich ursprünglich so vorgestellt hat unter diesem Service.

Um es vorweg zu nehmen: Dieses Blog enthält noch keine RDFa-Informationen. Ich habe es bei einem Testblog belassen. Zum ersten Mal leisten die knallgrauen Server spürbaren Widerstand.

Das grundlegende Problem: RDFa ist als Erweiterung zu XHTML (genauer: zu XHTML 1.1) konzipiert. XHTML ist durch derartige Module leicht erweiterbar, HTML nicht. Ich bemühe mich zwar, dieses Blog so weit wie möglich XHTML-konform zu halten. Knallgrau verhindert aber, daß es wirklich verläßlich sauberes XHTML ist:

• Es gibt bei der Texteingabe keine Prüfung auf valides XHTML, wie z.B. Drupal sie anbietet. Mit ein bißchen Disziplin schaffe ich es zwar meist (nicht immer), meine eigenen Beiträge fehlerfrei zu halten. Auf die Kommentare anderer User habe ich jedoch keinen Einfluß. Was immer da an Markup drin ist, XHTML ist es wahrscheinlich in den seltensten Fällen.
• Wesentlich schlimmer: Eine rudimentäre Prüfung auf gültiges Markup führt twoday.net beim Speichern eines Beitrags dann doch durch. Die ist aber problematisch und zerstört in Einzelfällen korrektes XHTML. Folge: Es gibt Situationen, in denen ich selbst wissentlich fehlerhaften Code veröffentlichen muß, weil twoday die von mir richtig eingegebenen Tags stur entfernt.
• Knallgrau gibt mir keine Möglichkeit, den MIME-Type der Dokumente zu verändern. XHTML 1.0 kann man ruhigen Gewissens als text/html ausliefern (das passiert hier). RDFa baut aber auf XHTML 1.1 auf, und dieses sollte als application/xhtml+xml ausgeliefert werden. Zwar geht text/html in Ausnahmefällen durch, trotzdem: An solche Vorgaben hält man sich einfach, und zwar aus dem gleichen Grund, aus dem man sich regelmäßig duscht.
• Es ist naheliegend, XHTML-formatierte Inhalte der Seite mit dem datatype rdf:XMLLiteral in eine RDF-Aussage zu übernehmen. Diese Konstruktion bricht zusammen wie ein Kartenhaus, wenn dann einmal fehlerhaftes XHTML (das dann in der Regel auch kein XML mehr ist) in einem solchen Bereich auftaucht.

Mir war das alles dann doch zu heiß. Es gibt keine ausreichenden Erfahrungen, wie RDFa-Parser arbeiten, ob sie über derartige Unkorrektheiten stolpern. (Der von mir zum Testen von rdfa.twoday.net verwendete Parser zum Beispiel spuckt bei ungültigem XHTML nur mehr Fehlermeldungen aus.)

Bleibt zusammenfassend: Ich weiß wie's geht, ich kann es jederzeit einbauen, sobald eine halbwegs fehlertolerante Applikation es auch sinnvoll verarbeiten kann. Bis ich aber weiß, wie fehlertolerant solche Applikationen sein werden, spiele ich nur im Testblog weiter - und schau mir Drupal näher an, das nicht nur korrektes XHTML bietet, sondern auch schon RDFa-Unterstützung eingebaut hat.

Genau das, was Fennec ausmachen und von anderen Browsern abheben soll, ist völlig mißglückt: das User Interface. Es beginnt schon damit, daß Fennec als einziger mir bekannter Browser eine Bedienungsanleitung benötigt. Beim Start wird man mit dem Konzept bekannt gemacht, daß sämtliche Bedienelemente erst dann erscheinen, wenn man links oder rechts über den Seitenrand hinaus scrollt (ein Video der extrem langsamen Testversion verdeutlicht das). Wer diesen Hinweis eilig überblättert, hat schon verloren.

Andererseits ist es auch nicht weiter schlimm, wenn man die Bedienelemente nicht findet: Es gibt nämlich fast keine. Zwei Buttons für „Vor“ und „Zurück“, dann welche für die Lesezeichen, einer für ein Optionen-Menü. Das wars. Mehr ist nicht. Einen Link in einem neuen Tab öffnen? Geht nicht. Seite speichern? Nein. Link zur Seite per Mail verschicken? Nicht mit Fennec. Bild speichern? Braucht keiner. Text markieren und kopieren? Computer sagt nein.

Die Aufgabe „Entwickle ein einfaches User Interface“ hat das Fennec-Team gelöst, indem es einfach gar kein User Interface entwickelt und damit alle üblichen Browser-Funktionen unzugänglich gemacht hat. (Dieser Ansatz ist in der Branche nicht neu.)

Zu allem Überfluß haben sie auch noch dort gepatzt, wo sie dann doch Funktionen eingebaut haben: Der Button „Zurück“ gehört zu den am häufigsten genutzten beim Browsen. Die Firefox-Entwickler haben das erkannt und ihn bei Firefox 3 extra groß gemacht. Bei Fennec ist das anders: Da ist er gut versteckt in einer Zauberleiste, die nur beim Scrollen nach rechts sichtbar wird. Mehrere Seiten zurück? Kein Problem: Nach rechts scrollen, Button klicken, nach rechts scrollen (Nein! Die Zauberleiste bleibt nicht etwa offen!), Button klicken, nach rechts scrollen, Button klicken, …

Das Fennec-Team rechtfertigt diese Fingergymnastik damit, daß möglichst viel Platz für den eigentlichen Seiteninhalt zur Verfügung stehen soll und daher alle Bedienelemente aus dem Anzeigebereich verschwinden mußten. Das Gegenteil von gut ist gut gemeint. Auf dem N800 muß Fennec sich den direkten Vergleich mit dem ebenfalls auf Firefox basierenden MicroB-Browser gefallen lassen. Auch dort läßt sich die Leiste mit URL-Eingabefenster, Vor-/Zurück-Buttons etc. ausblenden, auf Wunsch (und damit: in der Regel) bleibt sie aber stehen. Sie nimmt dabei exakt 56 Pixel eines 480 Pixel hohen Bildschirms ein. Diesen Platz opfert man gerne, wenn man dafür alle Funktionen nur einen Klick entfernt hat. Überhaupt kenne ich keinen mobilen Browser, der nicht die gesamte verfügbare Bildschirmfläche für die Anzeige des Seiteninhalts nutzen kann. Alle diese Browser kommen ohne das von Fennec erfundene Zauberland jenseits des Seitenrandes aus und bringen noch wesentlich mehr Funktionalität in gut durchdachten User Interfaces unter.

Bleibt die Frage, warum Fennec dennoch so viel mediale Aufmerksamkeit erzielt hat und so viele Lorbeeren erntet. Ein Fennec-Entwickler hat diese Frage vorab in seinem Blog beantwortet: Visual Momentum and Physics are compelling. Nothing shouts “sexy!” like pretty animations and a physics engine. - Ja! Es ist einfach lustig, die Seite mal nach links, mal nach rechts zu schieben und dann auf coole Knöpfchen zu drücken. Das macht viel mehr Spaß als so ein dröges Menü, das wir schon aus 100.000 Desktop-Anwendungen kennen. Das Problem ist nur: Nach ein paar Tagen Scrollen nach links und noch drei Tagen Scrollen nach rechts ist der Spielfaktor weg. Dann bleibt der Alltag. Spätestens dann will man wieder schnell zurückblättern können beim Surfen - oder eine Seite offline speichern, weil man im Zug zwischen Berlin und  Züssow keinen UMTS-Empfang hat. Dann wirds ärgerlich mit Fennec.

Zu befürchten steht, daß es tatsächlich ärgerlich wird: Die Bande zwischen Nokia und Mozilla sind eng. Es wird kein Zufall sein, daß die Nokia-Tablets derzeit die einzigen Geräte mit Fennec sind. Ich gehe davon aus, daß die nächste Version von Maemo von MicroB auf Fennec schwenkt. Hoffentlich lernt man bis dahin aus den gröbsten Fehlern.

Beim Durchprobieren verschiedener Chat- und Instant-Messaging-Programme für mein Nokia N800 bin ich über Pidgin gestolpert (befindet sich im Maemo Extras Repository). Dabei ist mir im Application Manager ein wunderliches Zusatzpaket mit dem Namen „Pidgin Bonjour Support“ aufgefallen, das ich sicherheitshalber mit installiert habe. Wer weiß, wofürs gut ist?

Ich weiß es - allerdings erst jetzt, nachdem ich mit mir selbst gesprochen habe: Das Ding führt nämlich dazu, daß die beiden in meinem Netzwerk aktiven Chat-Programme sich sofort gegenseitig finden und „Oskar Welzl“ am Desktop-PC mit dem „Oskar Welzl“ am N800 einen freundlichen Chat führen kann, auch ohne Verbindung zum Internet.

Hintergrund: Bonjour ist einer der vielen Namen für die von Apple entwickelte mDNS/DNS-SD-Technologie. Unter GNU/Linux heißt das entsprechende Service Avahi, Apple selbst nannte es früher einmal Rendezvouz. Gedacht ist es eigentlich dafür, daß Geräte in einem Netzwerk einander mitteilen, welche Dienste (Fileserver, Drucker, …) sie zur Verfügung stellen. Im Idealfall lassen sich diese Services dann ohne weitere Konfiguration im LAN nutzen.

Findige Köpfe haben auf dieser Basis die Jabber-Erweiterung XEP-0174: Serverless Messaging entwickelt. Die funktioniert genialisch einfach: Man richtet auf seinem eigenen Gerät ein Chat-Konto ein, das man mit nichts anderem als dem eigenen Namen konfigurieren muß. Sobald dann im gleichen LAN ein ebenfalls mDNS/DNS-SD-fähiger zweiter Chat-Client auftaucht, sieht man den Namen des Benutzers automatisch in seiner Kontaktliste und kann zu chatten beginnen.

Bei Pidgin am Desktop hatte ich dieses Leistungsmerkmal bereits mitkonfiguriert, ohne daß es mir bewußt war. Am N800 muß man dafür das erwähnte Paket „Pidgin Bonjour Support“ nachinstallieren. Aber auch der von Nokia auf Telepathy-Basis entwickelte Standard-Chat-Client am N800 kann mit mDNS/DNS-SD umgehen: Man muß dafür nur die noch als holprige Beta qualifizierten Erweiterungen, die unter dem Namen RTCOMM-Update angeboten werden, installieren. (Diese Updates enthalten übrigens auch auch AIM, IRC, Yahoo!, MSN und alle möglichen anderen Chat-Protokolle und sind durchaus empfehlenswert. Leider ist die Homepage veraltet und zeigt nicht mehr auf den aktuellen rtcomm-beta-installer; man muß stattdessen in diesem Verzeichnis nach der jüngsten Version suchen.)

Vielleicht sind Selbstgespräche vom N800 zum Desktop kein wirklich überzeugendes Anwendungsbeispiel für diese Technologie. Es gab aber tatsächlich eine Situation, in der dieser selbstkonfigurierende Chat auf vernünftige Weise zum Einsatz kam: Beim letzten Maemo-Summit in Berlin trafen einander mehrere hundert Menschen zum ersten Mal „im echten Leben“. Man kannte allerdings die Namen der anderen Teilnehmer, da die meisten in Blogs, Foren oder Mailinglisten elektronisch miteinander in Kontakt standen. Von diesem Treffen sind Situationen überliefert, in denen ein Konferenzteilnehmer plötzlich einen ihm bekannten Namen am Display seines N800 entdeckt und ihn angechattet hat: „Hey, heb mal Deine Hand! Ich will endlich mal sehen wer Du bist.“ Das ist eben Apple-Know-How. ;)

Harald Scheucher spricht vom Landeshauptmann der Herzen. Die Peinlichkeiten kennen keine Grenzen. Ich warte auf die Ankündigung des Musicals „Jörg!“, das „Evita“ in den Schatten stellen wird. Ganz sicher wird es bei meinem nächsten Besuch in Kärnten dort „Jörg Tränen“ zu kaufen geben - stilgerecht natürlich mit Wodka.

Eigentlich sollte das alles Angst machen. Tut es aber nicht mehr: Es ist zu viel. Wenn Uwe Scheuch versucht, fett aufgetragene Phrasen der Rührung mit BZÖ-Wahlkampf zu verquicken, dann ist das mehr Selbstpersiflage als sonst irgendetwas. Es erreicht den Fremdschäm-Faktor der „Leider Nein“-Kandidaten aus Casting-Shows. Schade eigentlich, daß nur ORF Kärnten bis zum Ende überträgt. Schade, daß die Familie das alles aus der ersten Reihe ertragen muß.

URIs können (grob vereinfacht) alles bezeichnen: Information über die Preise einer Frühstückspension (wie z.B. https://members.aon.at/neumair/zimmer_de.htm) oder mich als Person (ich habe die URI https://www.welzl.info/id/oskar.welzl). Alles kann (und soll) eine URI haben. Das ist die Grundlage des Semantic Web, damit wird die Möglichkeit geschaffen, über alles und jedes Aussagen zu treffen und diese Aussagen miteinander zu verknüpfen. Nur eines darf nicht passieren: daß für zwei verschiedene Dinge die gleiche URI verwendet wird. Das ist logisch: Wenn wir für Spinat und Schokokuchen das gleiche Wort hätten, wüßte der Kellner nicht, was er bringen soll.

In populären RDF-Vokabularen wie FOAF und SIOC kommen aber Bezeichnungen vor, die dazu verführen, URIs doppelt zu vergeben. In der Praxis passiert auch genau das. Die wichtigsten Vertreter dieser Gattung sind sioc:Forum, foaf:weblog und sioc:Site.

Warum verführen diese Bezeichnungen zur doppelten Vergabe von URIs? Der Klassiker ist sioc:Forum, das URIs als Diskussionsbereich auszeichnet, in dem Einträge gemacht werden. Mein Weblog hier ist ein sioc:Forum. Das Userforum auf internettablettalk.com ist ein sioc:Forum. Was passiert also naheliegenderweise in der Praxis? Eine RDF-Aussage „http://oskar.twoday.net/ ist vom Typ sioc:Forum“ wird angereichert mit Informationen wie „http://oskar.twoday.net/ hat 1455 Postings“ und „Der User Zorra hat einen Artikel auf http://oskar.twoday.net/ geschrieben“. Das sind Aussagen, die bezüglich meines Weblogs korrekt sind.

Dummerweise gibt es aber neben meinem Weblog auch noch etwas anderes, das bezeichnet und beschrieben werden will: die Seite, die der twoday-Webserver beim Aufruf von http://oskar.twoday.net/ zurückliefert. Die Übersichts- oder Einstiegsseite also. Auch sie ist, ebenso wie das Weblog als ganzes, eine information resource. Auch über diese Übersichtsseite möchte ich Aussagen treffen können: daß derzeit 16 Artikel auf ihr zu sehen sind zum Beispiel („http://oskar.twoday.net/ hat 16 Postings“) oder daß sie valides XHTML ist („http://oskar.twoday.net/ ist XHTML 1.0“).

Die Aussagen über mein Weblog als Gesamtheit und über die Übersichts-/Einstiegsseite widersprechen einander bzw. sind für die jeweils andere Ressource nicht wahr: Der User Zora hat zwar einen Eintrag auf meinem Weblog verfaßt, der Eintrag erscheint aber nicht auf der Einstiegsseite. Und auch wenn mein Weblog tatsächlich 1455 Postings hat, für die Einstiegsseite ist diese Aussage falsch, genauso wie die Annahme, das Blog sei in seiner Gesamtheit sei valides XHTML. Das Weblog und die Einstiegsseite sind also zwei unterschiedliche Dinge, die unterschiedliche URIs benötigen. Weil die einzelne Übersichtsseite noch eher das ist, was der Webserver beim Aufruf der URI zurück liefert, hätte ich grundsätzlich vorgeschlagen, für die andere Ressource (also das Weblog, das Forum, …) eine neue URI zu erfinden. Das geht: Im Semantic Web ist das Erfinden neuer URIs für irgendwelche Dinge tägliche Praxis.

Tatsächlich aber werden „da draußen in der Wildnis“ die jeweiligen URIs der Einstiegsseiten von Blogs/Foren/… als Bezeichner für das gesamte Blog/Forum/… verwendet. Das ist zunächst nicht falsch - nur extrem unpraktisch, weil es die Verwendung der gleichen URI für die dazugehörige Einstiegsseite verhindert oder aber zu widersprüchlichen und falschen Aussagen führt.

In meinen ersten Experimenten mit SIOC wollte ich alles richtig (und damit anders als alle anderen) machen: Ich habe für mein Blog die URI http://www.welzl.info/rdf/twoday#oskar.twoday.net erfunden, an dieser Adresse ein paar Daten zum Blog und den Link auf http://oskar.twoday.net/ hinterlegt. Bis heute bin ich der Ansicht, daß das ein korrekter Ansatz war. Je länger ich mich dann aber nicht nur mit dem Erstellen, sondern auch mit dem Verarbeiten und der für Menschen lesbaren Darstellung von RDF-Informationen beschäftigt habe, desto klarer ist mir geworden, daß dieser Ansatz nur beschränkt praxistauglich ist. Das Semantic Web muß die Antwort auf die Frage geben können, welche Informationen zum Weblog mit der Adresse http://oskar.twoday.net/ zur Verfügung stehen. Kein Mensch wird je nach dem von mir erfundenen http://www.welzl.info/rdf/twoday#oskar.twoday.net suchen. Außerdem gehen die meisten Tools zur Darstellung von RDF davon aus, daß man auf Links mit der Eigenschaft foaf:weblog oder sioc:Forum einfach klicken kann, um zum jeweilig Blog oder Forum zu kommen. Diese Annahme ist zwar nicht durch die Spezifikationen gedeckt, aber sie ist verständlich.

Dazu kommt ein anderer Aspekt: Die Trennung in eine URI für „das Blog von Oskar Welzl“ und eine zweite URI für „die Einstiegsseite des Blogs von Oskar Welzl“ würde sich als „best practice guideline“ nie durchsetzen lassen. Es ist einfach zu kompliziert. Gerade die populären FOAF- und SIOC-Vokabulare werden von vielen RDF-Einsteigern genutzt (dazu zähle ich mich selbst), die eine solche Trennung nur durchführen, wenn sie verbindlich im Vokabular verankert statt nur empfohlen ist.

Seit gestern heißt mein Blog im semantischen Web nun wieder http://oskar.twoday.net/ - ich habe zum ersten Mal seit Jahren das Pragmatische über das Richtige gestellt. Seither habe ich Depressionen und Bauchweh. Es stimmt einfach nicht. Es ist nicht richtig. Wie käme man aus dem Dilemma raus?

Am einfachsten und saubersten wäre eine klare Neudefinition in den betroffenen Vokabularen. Im Fall von foaf:weblog könnte das ganz einfach die Änderung der Beschreibung sein: Derzeit ist es definiert als a weblog of some thing (whether person, group, company etc.). Dies könnte geändert werden auf „The entry point of (or place to bookmark for) a weblog of …“. FOAF kennt ein ähnliches Konzept bereits für foaf:accountServiceHomepage: Dort wird in der Definition ausdrücklich auf die homepage of the service Bezug genommen. Bei SIOC ist die Sache etwas komplexer, da sich das gesamte Vokabular mit Konzepten wie „… ist Teil von …“ auf das sioc:Forum (und nicht auf seine Einstiegsseite) bezieht. Hier wird nichts anderes übrig bleiben als das Konzept der Website (als Sammlung von einzelnen Seiten) deutlicher von dem der dazugehörigen Einstiegsseite zu trennen.

Überhaupt würde ich mir ein knappes Vokabular zur Beschreibung einer Website wünschen: Ganz unabhängig von Foren und Blogs beziehen sich RDF-Statements immer wieder auch auf ganze Websites. Es wäre praktisch, wenn man die in solchen Fällen gleich bleibenden Grundstrukturen (Website hat Hauptseite, Seite X gehört zur Website Y, …) sauber in RDF darstellen könnte. (Ein solches Vokabular ließe sich außerhalb von SIOC und FOAF entwickeln und dann von beiden Projekten nutzen.) Derzeit werden durch die Verwendung der URI der Einstiegsseite als Bezeichner für die gesamte Site Aussagen über genau diese Einstiegsseite unmöglich gemacht - URI-Squatting eben.