“Open” can mean a lot of different things. A federated social web is specific: it means that there are distinct entities that control parts of the system, but those parts are connected with agreed-upon rules to make a pleasing and usable whole.

Oder wie Chris Saad es ausdrückt Open is not enough. Time to raise the bar: Interoperable

» What is the federated social web?
» Features of a federated social web

Facebook und der Social Graph
Facebook packt neben hCards und XFN jetzt auch rel-me links auf die Profilseiten.

Facebook joins the distributed social web #DiSo by supporting rel-me + representative hCard microformats!

…das gibt ‘nen schönen Backlink

» Facebook joins the distributed social

Microsofts Identity “Mash-up”
Microsoft bastelt an einem Identity “Mash-up” und kombiniert die unterschiedlichsten Systeme miteinander.

[...] we chose to create an intermediary Security Token Service that understands the OpenID protocol (used by PayPal), WS-Federation protocol and SAML 1.1 tokens (used by Medtronic apps). This intermediary STS enables SSO between the web applications, avoiding re-authentication with the original identity provider (PayPal).

Und warum das ganze? Weil ‘s geht

» Consumer Identities for Business transactions
» Identity “Mash-up” Federation Demo using Multiple Protocols (OpenID and WS-Federation)

Beispiel:

• <a rel="me" href="http://twitter.com/pfefferle" /> (notizBlog.org -> twitter.com)
• <a rel="me" href="http://notizblog.org" /> (twitter.com -> notizblog.org)

Um auch Community-Profile ohne Backlink-Möglichkeiten (z.B. facebook) verifizieren zu können, kam Brad Fitzpatrick (der Mann hinter Googles Social Graph API) auf die geniale Idee, den fehlenden Link mit einer qr-codierten URL in seinem Profilbild zu ersetzen.

…jetzt müssen die QR-Codes nur noch in die SG-API aufgenommen werden.

Vor ein paar Tagen habe ich ein Gespräch zwischen Dirk Olbertz und Tantek Çelik via Twitter verfolgt, bei dem es genau um dieses Problem ging…

Das Problem der representative hCard kann auf zwei verschiedene Weisen gelöst werden:

…in short 1. url==uid==source. 2. url has rel-me

url==uid==source

Die einfachste Möglichkeit ist, zu überprüfen ob eine der (unter der angegebenen Source-URL) gefundenen hCards als URL die die Source-URL enthält. Wenn man sicher gehen will, sollte man die URL zusätzlich noch als UID (RFC2426) auszeichnen.

Ein Beispiel für eine representative hCard für http://notsorelevant.com wäre:

<span class="vcard">
	<span class="fn">Carsten Pötter</span>
	<span class="url uid">http://notsorelevant.com</span>
</span>

rel-me

Die zweite Möglichkeit ist, nach hCards mit rel="me" URLs zu suchen.

Diese Variante lässt sich natürlich auch mit der Ersten verbinden:

<span class="vcard">
	<span class="fn">Carsten Pötter</span>
	<span class="url uid" rel="me">http://notsorelevant.com</span>
</span>

Wer also ganz sicher gehen möchte sollte das letzte Beispiel nutzen

Für Web-Seiten die gar keine Profile oder zumindest keine Profile auf der Startseite haben, könnte rel="me" auch als Delegation zu einer (anderen) Seite mit einer representative hCard genutzt werden.

Beispiel: <link rel="me" href="http://www.notsorelevant.com/ueber/" />

Da es für PHP (meines Wissens) noch keinen XFN-Parser gibt, habe ich mich beim hCard-Commenting WordPress Plugin für die erste Variante (url==uid==source) entschieden… Ich hoffe es funktioniert

Weitere Informationen zu representative hCards im Microformats-Wiki:

• representative hCard
• representative hCard parsing
• rel-me

So, endlich komm ich neben den ganzen DataPortability und OpenID News auch mal wieder zu meinen sehr geschätzten Microformats

Yahoo! Research Barcelona bastelt mit “Yahoo! Micro Search” an einer Social/Semantic Search Engine. Yahoo! Micro Search ist aber keine reine Microformats Suche wie z.B. die Technorati “Microformats Search” sondern unterstützt (wie die Social Graph API) auch RDFa, über <link rel="me" /> verlinkte RDF Dateien wie z.B. FoaF und demnächst soll auch noch GRDDL dazu kommen (bin mal gespannt wie das aussehen soll).

Der Aufbau der Suchergebnisse ist (zumindest im Hauptteil) eher klassisch wie bei Google oder Yahoo! aufgebaut.

Im oberen Teil der Sidebar werden gefundene GEO-Daten direkt auf einer Yahoo Map dargestellt. Die unten abgebildeten Orte wurden z.B. in meinem Plazes Account gefunden.

Darunter sollen wohl gefundene hCalendar-Events mit Hilfe der Smile Timeline angezeigt werden, das habe ich aber leider nicht ausprobieren können… meine war immer leer, ich hoffe das liegt nicht an mir

Wo bei Google “nur” die Anzahl der Suchtreffer zu einem Suchbegriff angezeigt werden, listet die Micro Search genau auf wie viele davon Profile (z.B. vCards/hCards) oder Events (z.B. hCalendar) sind.

Fazit: “Yahoo! Micro Search” dient wohl in erster Linie dazu Google einen Schritt voraus zu sein und ein Pendant zu der “Social Graph API” zu schaffen… und wenn schon, ich mag die Idee. Man sollte sich in Zukunft nur im klaren sein, dass arglos veröffentlichte Microformats demnächst auch alle gefunden (und meist auch dessen Autor zugeordnet) werden können…

Weiterführende Links:

• Yahoo! Research Barcelona DokuWiki
• Structured data – set to take on Google