Anfang der Woche hat Martin Weigert schon über Twitters Pläne, die eigenen Tweets mit noch mehr Medieninhalten zu erweitern, geschrieben:

Immer mehr Partnerseiten können zusätzliche multimediale Inhalte im Kontext von Tweets darstellen. Ganz eindeutig ist bisher nicht, wohin diese Reise für Twitter geht.

Aber ich habe mir nichts weiter dabei gedacht… Immerhin macht das Twitter ja schon seit einer ganzen Weile und ich meine mich zu erinnern, irgendwo gelesen zu haben, dass sie dazu oEmbed einsetzen… Also alles in bester „OpenWeb“-Ordnung 🙂

Aber, Geek der ich bin, hab ich mir gestern zufällig einen Quelltext angeschaut in dem ich auf folgendes entdeckt habe:

<meta name="twitter:card" content="summary">
<meta name="twitter:url" content="...">
<meta name="twitter:title" content="...">Code-Sprache: HTML, XML (xml)

…und nach kurzem googlen bin ich auf die Twitter Cards gestoßen, Twitters eigenes, kleines Open Graph Protocol. Mit den Twitter Cards bekommen Seitenbetreiber ein Set an Meta-Tags an die Hand, und Twitter kann diese Informationen nutzen um die tweets mit den oben erwähnten Mediendaten anzureichern.

Example Twitter Card

…und ich wollte mich gerade darüber aufregen, warum Twitter dazu eine eigene Meta-Sprache erfindet, da bin ich in der Doku ironischerweise auf folgendes gestoßen:

You’ll notice that Twitter card tags look similar to OpenGraph tags, and that’s because they are based on the same conventions as the Open Graph protocol. If you’re already using OpenGraph to describe data on your page, it’s easy to generate a Twitter card without duplicating your tags and data. When the Twitter card processor looks for tags on your page, it first checks for the Twitter property, and if not present, falls back to the supported Open Graph property. This allows for both to be defined on the page independently, and minimizes the amount of duplicate markup required to describe your content and experience.

„Ok“, dachte ich… vielleicht reichen die Open Graph Properties ja nicht aus um alle Informationen, die Twitter braucht, abzubilden. Also hab ich mir mal die Mühe gemacht sie zu vergleichen:

Twitter CardsOpen Graph Protocol
twitter:cardog:type
twitter:siteog:site_name
twitter:urlog:url
twitter:descriptionog:description
twitter:titleog:title
twitter:imageog:image
twitter:image:widthog:image:width
twitter:image:heightog:image:height
twitter:player oder twitter:player:streamog:video oder og:audio
twitter:player:widthog:video:width
twitter:player:heightog:video:height

Es lässt sich also prinzipiell alles mit dem Open Graph Protocol abbilden, es fehlen lediglich die Felder twitter:site:id und twitter:creator:id. Aber wegen diesen zwei Feldern muss man doch nicht das ganze Format „kopieren“. Es reicht doch ein kleiner Absatz, wie man den Open Graph mit den proprietären Werten erweitert… So wie das auch Facebook praktiziert:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:og="http://ogp.me/ns#"
      xmlns:fb="https://www.facebook.com/2008/fbml">
      xmlns:twitter="https://dev.twitter.com/docs/cards">
  <head>
    <title>The Rock (1996)</title>
    <meta property="og:title" content="The Rock"/>
    <meta property="fb:admins" content="USER_ID"/>
    <meta property="twitter:site:id" content="@USER_ID"/>
    ...
  </head>
  ...
</html>
Code-Sprache: HTML, XML (xml)

Hoffentlich überlegt sich das Twitter noch einmal… Wenn nicht, wird dank dieser (und folgender) Redundanzen der <head /> einer Webseite in ein paar Jahren mehr Informationen beinhalten wie der <body />.

…welch ein Over-<head> 🙂

Nach etwas mehr als zwei Jahren und diversen Hosting-Problemen ist Martin McEvoys microformats transformr jetzt unter microform.at erreichbar.

Martin McEvoys tweet

Aber nicht nur die Domain hat sich geändert. Martin (aka Weborganics) hat noch einmal extrem viel Arbeit in den transformr gesteckt, so dass er mittlerweile nahezu alles transformiert was sich so im HTML-Quellcode versteckt:

…und die Liste der Ausgabe-Formate ist mindestens ebenso eindrucksvoll.

Meine Favoriten sind der (von Martin überarbeitete) hCard2QRCode-transformr und der SPARQL Endpoint über den man vollen Zugriff auf alle zuvor transformierten Seiten hat.

Vergesst Optimus, H2VX, microformatic und ufXtract!