Web
neuere Einträge ...L'amour à la AOL
Im Oktober hat AOL weltweit 2.000 Mitarbeiter wieder in den freien Arbeitsmarkt eingegliedert. Auch die französische Niederlassung war betroffen, 90 Menschen haben ihre Jobs verloren. Am Tag nach der Kündigung fanden sie sich zum Videodreh in ihren früheren Büroräumen ein. Zur Musik von „L'amour à la Française“ und mit der Widmung to any lost love
beginnt das Video am Kopierer. Ohne Zwischenschnitt laufen die unbeugsamen Franzosen durch Gang und Stiegenhaus, tanzen in der Halle und treffen sich schließlich auf der Straße unter dem Schild mit der Aufschrift „Zu vermieten - 2.000m² Bürofläche“. Eine großartige Idee und hervorragend umgesetzt.
Die Originalfassung ist mit dem Kennwort „aollover“ geschützt: Das Video war als interner Gag und nicht für die Öffentlichkeit gedacht. Mittlerweile existiert eine Kopie auch auf YouTube, allerdings in etwas schlechterer Qualität.
„L'amour à la Française“ von Les Fatals Picards war der französische Song-Contest-Beitrag 2007 und landete auf einem bescheidenen 22. Platz. Die Ergebnisse meiner Song-Contest-Party sahen da anders aus, wir hatten die Franzosen mit diesem charmanten Song an fünfter Stelle. (Auch die Interpretation von Les Fatals Picards gibts natürlich „zum Nachschauen“ im Netz: den Promo-Videoclip und live in Helsinki.)
Die Story wird mittlerweile im französischen Fernsehen, in Wirtschaftszeitungen und natürlich überall im Internet verbreitet. Besser kann man sich einem zukünftigen neuen Arbeitgeber eigentlich nicht mehr präsentieren.
Ort anzeigen auf: Google Maps,
Mapquest
Suche nach Websites und
Fotos in der Nähe
3 Kommentare - Kommentar verfassen
Semantic Web à la twoday
In letzter Zeit spricht man auch bei mir in der Firma (z.B. in einem unserer „Corporate Blogs“ - ja, ich weiß, die sind out, Urlaubsblogs sind in) ganz offen über meine geheimste erotische Phantasie, meinen bizarrsten Fetisch: das semantische Web. Grund genug, den twoday-Server wieder einmal ans Andreaskreuz zu fesseln und diesmal so lange zu mißhandeln, bis er RDF/XML ausspuckt. (Die Vergangenen Folter-Sessions hat er ganz gut überlebt: Planet à la twoday, Geotagging à la twoday und Tagging à la twoday, wobei mit letzterem sogar ganz nebenbei sauberes RSS entstanden ist.)
Ums vorweg zu nehmen: Wirklich implementieren kann man eine RDF-Version des eigenen Blogs hier nicht, dazu müßte serverseitig zu viel geschraubt werden. Aber mit nur wenig manuellem Aufwand alle 4-8 Wochen kommt man recht nah ran.
Die erste Frage ist die nach einem brauchbaren Vokabular. SIOC ist dafür wie geschaffen - unter anderem wahrscheinlich deswegen, weils extra dafür erfunden wurde. Es ist nichts leichter, als den von twoday bereitgestellten RSS 1.0-Feed um ein paar SIOC-Informationen zu bereichern. Daß der entsprechende Beitrag vom rdf:type sioc:Post ist, welches sioc:topic er hat und welcher sioc:User ihn geschrieben hat zum Beispiel. An dieser Stelle wirds Zeit für einen dankbaren Kniefall vor den knallgrauen Göttern: Würden die nämlich Atom oder RSS 2.0 statt des RDF-basierenden RSS 1.0 verwenden, wär's Essig mit der semantischen Erweiterbarkeit des Feeds. Diese ist aber besonders wichtig, weil sie die einzige Möglichkeit zur Echtzeit-Einbindung aktueller Posts und Kommentare in das semantische Web direkt auf dem Server darstellt. Alles andere ist, wie vorhin erwähnt, Handarbeit.
Sobald nämlich Beiträge aus den RSS-Feeds rausrutschen und von neueren verdrängt werden, bleibt nur noch eins: die RDF-Version selber schnitzen. Das geht relativ leicht: Im Export-Modul von twoday läßt sich frei bestimmen, welche Information exportiert werden soll. Dabei bleibt die Hierarchie „Beitrag > Kommentar > Kommentar zum Kommentar“ erhalten. Alles, was man machen muß, ist die Export-Skins so umzuschreiben, daß sie XML-Fragmente exportieren. Diese lassen sich dann abspeichern, zu einer XML-Datei vereinen und per Stylesheet zu RDF/XML verarbeiten. Auf diese RDF/XML-Datei verlinkt man dann aus dem <head> einer HTML-Seite heraus. (Achtung: Die Export-Funktion verliert damit übrigens ihren ursprünglichen Zweck, die so exportierten Daten lassen sich nicht mehr importieren.)
Natürlich ist die scriptgesteuerte Umwandlung besonders spannend, denn hier besteht die Gelegenheit, zusätzliche Infos einzufügen: Auf welche externen Seiten verweist ein Artikel? Welche Quellen werden zitiert? Welche Personen sind auf den Fotos zu sehen? In welcher Beziehung stehen diese Personen zueinander? Ein Gemisch aus SIOC, FOAF und Dublin Core kann alle relevanten Informationen ausdrücken, mehr ist nicht notwendig. Ach ja, doch: WGS84 kommt auch noch vor - immerhin haben wir ja gerade erst gelernt, wie man Geotags in Blogposts einfügt. ;)
Wem das alles was nützt? Bösen Datensammlern in Schurkenstaaten vielleicht. Dem 08/15-User im Web derzeit kaum, obwohl man mit gut gemeinten Tools wie der Firefox Tabulator Extension zumindest halbherzigen Zugriff auf die Daten hat. Egal - Hauptsache mir geht jedesmal einer ab, wenn mein Shell-Script die RDF/XML-Files generiert und hochlädt. Wie gesagt: meine geheimste erotische Phantasie … ;-)
9 Kommentare - Kommentar verfassen
My URI: I Deserve It!
Sir Tim Berners Lee sagt:
… everything of importance deserves a URI. Go ahead and give yourself a URI. You deserve it!
Na dann: Wer mich in FOAF-Files oder anderen RDF-Dokumenten erwähnt, möge bitte dafür hinkünftig die URI
http://www.welzl.info/id/oskar.welzl
verwenden.
Mein eigenes FOAF-File habe ich schon entsprechend geändert: Ich bin darin kein nackter bNode mehr, sondern als <foaf:Person rdf:about="http://www.welzl.info/id/oskar.welzl" /> jetzt eindeutig. Schön, nicht?
Tagging à la twoday
Anders als bei blogr oder Weblife hat knallgrau hier bei twoday ja (noch?) keinen Tagging-Mechanismus eingebaut. (Klingt komisch, ist aber so. *g*) Einen seither immer wieder verwendeten Workaround hat Daniel schon im Jänner 2006 präsentiert: Ein Script fordert zur Tag-Eingabe auf und produziert HTML-Code, aus dem Technorati dann Tags extrahieren kann. Der HTML-Code landet direkt im Textbereich des Beitrags. Nachteil dabei: Die Tags sind nicht „wiederverwertbar“ (z.B. für del.icio.us oder im RSS-Feed). Außerdem wirken sich zu große Änderungen bei den Tags auf den Zeitstempel „modifytime“ aus, was unerwünschte Nebeneffekte hat.
Wie also tun?
Ähnlich wie beim Geotagging können zusätzliche Eingabefelder im Formular für das Erstellen/Ändern von Einträgen (Story.editForm) weiterhelfen, das man über „Layout verwalten > Skins“ erreicht:
<p>
<% message key="Story.create.title"%>:<br />
<% story.content part="title" as="editor" size="24" class="formTitle" %>
</p>
<p>
<% message key="Story.create.text"%>:<br />
<% story.content part="text" as="editor" cols="60" rows="15" class="formText" %>
<br />
Tag 1: <% story.content part="tag.1" as="editor" size="30" %> <br/>
Tag 2: <% story.content part="tag.2" as="editor" size="30" %> <br/>
</p>
Die fett hervorgehobenen Stellen sind die neuen Eingabefelder für Tags. Auch diese Lösung hat einen Nachteil: Man muß sich bei der Änderung von „Story.editForm“ auf eine maximale Anzahl von Tags festlegen und für jedes Tag ein eigenes Eingabefeld bauen. Hier im Beispiel sind es zwei („tag.1“ und „tag.2“), ich habe mich in meinem Blog für neun entschieden. Zu viele sind in der Darstellung/Weiterverarbeitung extrem umständlich zu handhaben, zu wenige machen einfach keinen Spaß.
Eingesetzt wird das Tag in Skins wie z.B. story.Display. Dabei kann es auf zwei verschiedene Arten aufgerufen werden. <% story.content part="tag.1" as="plaintext" encoding="xml" %> stellt das Tag so dar, wie es eingegeben wurde - mit Umlauten, Leerzeichen, Schrägstrichen und allem, was drin ist. Das ist der Text, wie man ihn lesen soll. Die zweite Variante, <% story.content part="tag.1" as="plaintext" encoding="url" %>, codiert „gefährliche“ Sonderzeichen, die in URIs nicht vorkommen sollen, annähernd nach RFC 3986 um (z.B. „%C3%96sterreich“ statt „Österreich“). Leerzeichen in Wortgruppen werden aber durch ein „+“ ersetzt, was zwar nicht RFC 3986 entspricht, praktischerweise aber genau das ist, was fast alle relevanten Webservices in URLs erwarten.
Die folgende Konstruktion nutzt beide Varianten:
<% story.content part="tag.1" prefix='Tag: <a href="http://technorati.com/tag/' suffix='" rel="tag">' as="plaintext" encoding="url" %><% story.content part="tag.1" suffix='</a>' as="plaintext" encoding="xml" %>
Wenn tag.1 z.B. mit „Österreich“ befüllt wurde, erzeugt sie den HTML-Code Tag: <a href="http://technorati.com/tag/%C3%96sterreich" rel="tag">Österreich</a>. Das ist schon mal sehr praktisch und flexibel: einfach statt der Technorati-URL irgend ein anderes Fragment nehmen, und auch dorthin wird verlinkt.
Die Tags sollten dann auch im RSS-Feed landen, und zwar sinnvollerweise als „dc:subject“. Dort werden sie von Webservices wie Technorati erwartet, außerdem entspricht das der Definition für dieses Feld, die lautet:
The topic of the resource. (Comment: Typically, the topic will be represented using keywords, key phrases, or classification codes.)
Es zahlt sich jedenfalls aus, die Änderung im RSS-Feed vorzunehmen (die relevanten Skins sind Story.rssItem und Story.rssItemSummary). In der Standardeinstellung schreibt twoday dort nämlich einen vollen HTML-Link (also mit <a href="…">) auf die Übersichtsseite des Beitrags-Themas in das Feld dc:subject, was ein bißchen über die oben zitierte Definition des Feldes hinaus schießt und Technorati beim Versuch, Tags automatisch zu extrahieren, völlig durcheinander bringt.
Wenn man schon mal bei den RSS-Feeds ist und einen ausgeprägten Fetisch für Standards eintwickelt hat, die niemanden interessieren, sollte man noch eine Änderung vornehmen. Der Codeabschnitt
<% story.content part="text" prefix="<description>" suffix="</description>" encode="xml" %>
ist durch den nachfolgenden zu ersetzen:
<% story.content part="text" prefix="<description>" suffix="</description>" encode="xml" as="plaintext" %>
Mit dieser Ergänzung („as="plaintext"“) schneidet twoday das HTML-Markup aus dem Beitragstext und schreibt ihn ohne Links, Bilder und Formatierungen in den Feed. Ja, tatsächlich, das müßte so sein, auch wenns keiner macht. HTML-Markup gehört in das Feld „<content:encoded>“ aus dem Modul Content, das man auch noch einfügen kann, wenn man mag. (Namespace nicht vergessen!)
Tja, so funktioniert dann auch Tagging mit twoday, solange man sich eine vernünftige Anzahl von Eingabefeldern überlegt. Eines stört mich noch an dieser Lösung: Die Beschreibung der Ausgabe für mehrere Tag-Felder in den einzelnen Skins ist extrem schwerfällig. Ich habe keine Möglichkeit gefunden, alle Tags als Gesamtheit (z.B. als Liste) anzusprechen. Bei neun Tags, die immer alle gleich behandelt werden sollen, wird das trotz Copy&Paste schnell unflexibel, unübersichtlich und lästig. Hoffentlich muß ich keine großen Änderungen mehr an der Darstellung vornehmen, für die tägliche Eingabe beim Bloggen paßts ja.
3 Kommentare - Kommentar verfassen
Geotagging à la twoday
Alles, was es dazu braucht, sind zwei zusätzliche Eingabefelder im Formular für das Erstellen/Ändern von Einträgen (Story.editForm), das man über „Layout verwalten > Skins“ erreicht:
<p>
<% message key="Story.create.title"%>:<br />
<% story.content part="title" as="editor" size="24" class="formTitle" %>
</p>
<p>
<% message key="Story.create.text"%>:<br />
<% story.content part="text" as="editor" cols="60" rows="15" class="formText" %>
<br />
Längengrad: <% story.content part="geo.lon" as="editor" size="12" %> (z.B. für Mieming/Tirol: Longitude 10.9833) <br />
Breitengrad: <% story.content part="geo.lat" as="editor" size="12" %> (z.B. für Mieming/Tirol: Latitude 47.3)<br/>
</p>
Die fett hervorgehobenen Stellen habe ich eingefügt. Sie bewirken, daß jeder Eintrag nun neben den Standardfeldern (Titel, Text, …) auch über ein Feld „geo.lon“ für den Längengrad und „geo.lat“ für den Breitengrad verfügt. Diese beiden Felder lassen sich anschließend in jeder Skin als <% story.content part="geo.lat" %> bzw. <% story.content part="geo.lon" %> ansprechen. Bizarr verschachtelte prefix-/suffix-Konstruktionen sorgen dabei dafür, daß twoday die Werte nur dann anzuzeigen versucht, wenn sie auch wirklich da sind (nicht jeder Eintrag ist mit Geotags versehen):
<% story.content part="geo.lon" prefix=<% story.content part="geo.lat" prefix='<a href= "http://maps.google.com/maps?f=q&hl=de&q=' suffix=',' %> suffix='&t=h">Google-Maps</a>' %>
Dieses Makro am Ende der Skin Story.display z.B. stellt einen Link zu Google-Maps dar, falls sich ein Wert in „geo.lon“ befindet. Alles andere ist dann nur mehr Spielerei mit vorhandenen Daten.
4 Kommentare - Kommentar verfassen
Thai Blogging
Peter hats vorgemacht, jetzt zeigen auch Wolfi und Raini Bilder von ihrem Urlaub im Hotel Marina am Karon Beach in Phuket. Stammleser erinnern sich: Schon vor ziemlich genau einem Jahr haben mir die beiden, allerdings damals noch via MMS, Bilder von sonnigen Stränden in die Wiener Trostlosigkeit geschickt. Ganz ehrlich macht das ja doch ziemlich Lust auf ein bißchen Entspannung … ;-)
Ach ja: Daß die beiden heuer bloggen statt MMSen hat einen simplen Grund. Aus der Zimmerbeschreibung auf der Website des Hotels:
Each room includes state-of-the-art multi-media. A 32-inch LCD TV, together with a top-of-the-line Mini-computer, means that guests can enjoy everything from music, movie, games, digital photos, and international cable TV.
Urlaub von der Technik wird also nicht gemacht - das gilt umso mehr, als auch der kleine Liebling mit dabei ist. *g*
Flashblock, mon amour
Firefox sei Dank gibt es einen Mittelweg: Flashblock ersetzt jedes Flash-Objekt durch eine leere Fläche mit Play-Button in der Mitte. Man surft also weiterhin unbehelligt, kann aber einzelne Inhalte gezielt zulassen oder aber auch ganze Websites (wie eben XTubeYouTube) zur flashverseuchten Zone machen, in der dann Flash-Inhalte automatisch geladen und wiedergegeben werden.
Mit diesem Add-On läßt es sich leben, bis Flash strafrechtlich verboten wird.
Planet à la twoday
Ich hab einige Zeit nach einem Service gesucht, bei dem ich mich einfach anmelde und einen öffentlichen, frei gestaltbaren Planet aus RSS-Feeds zusammenbaue. Nix gefunden. Dann bin ich draufgekommen, daß ich so etwas direkt hier vor der Haustür liegen habe: Das twoday-Modul Story.modRssFetcherItem hat viel von dem, was es braucht. Es ist nicht perfekt, aber es geht.
Nach kurzem Basteln war dann schließlich „TABs - TA Blogs“ online: Eine aktuelle Zusammenstellung der 15 neuesten Einträge aus den Weblogs meiner Kollegen hier in der Firma. Die Optik ist schauderbar, aber das Konzept funktioniert. Und das gefällt mir.
Fragt sich, warum das sonst niemand als Produkt anbietet. Story.modRssFetcherItem als Hauptinhalt einer Seite ist eine Krücke. Ich würde gerne mehr konfigurieren können (Markup übernehmen ja/nur strukturelles/nein, Bilder anzeigen ja/nein, …), den Anmeldevorgang teilautomatisieren, eine Verbindung zu den URLs der Blogs im Menü des Planet herstellen und vieles mehr. Kennt jemand eine bessere Lösung? Möchte jemand sowas basteln? ;-)
Mein Ex-Chef bloggt
(Ich fänds ja spannend, wenn er das Blog dann auch nachher noch weiterführt; die Reihe der bloggenden Kollegen wird immer dichter hier bei uns.)
Drahtdesign
Ich empfehle im Shop also einen Blick in die Rubrik „Drahtdesign“. Wer sich darüber hinaus davor schützen möchte, daß böse Einbrecher ihm das frisch erstandene Schmuckstück wieder entwenden, wird wahrscheinlich unter „Sicherheitstechnik“ fündig. Außerdem gibts noch Knickschutzwendeln aus Bandstahl, Garagentor-Zugfedern und ähnliche Dinge, mit denen ich so gar nix anfangen kann.
Ich bestell jetzt testweise mal noch einen Schlüsselanhänger. Mal sehen, ob die Lieferung auch so prompt erfolgt wie bei einem gewissen Catering-Service, das ich neulich ausprobiert habe …