…oder How to use hCards to fill in forms.

hCardMapper ist eine JavaScript-Klasse (basierend auf Prototype) um Kontakt- oder Profil-Formulare mit Hilfe einer hCard automatisch zu füllen, ähnlich wie bei bragster.com oder getsatisfaction.com.

Das schöne an hCardMapper ist seine flexible Struktur. Die JavaScript Klasse ist so aufgebaut, dass sie eigentlich Microformats-Parser unabhängig funktionieren sollte, da sie die Daten über einen „Proxy“ abfrägt. Die einzige Vorgabe ist, dass dieser Proxy eine JSON formatierte hCard (jCard) zurückgibt. Das Problematische an dieser Variante ist, dass jeder Parser unterschiedliche Ergebnisse liefert… ich werde es heute abend mal mit dem hKit-Parser testen.

Ein weiter Vorteil ist die Formular-Unabhängige Programmierung die es ermöglicht, das Script auch problemlos auf vorhandene Formulare anzuwenden. Über mappnings werden die hCard-Attribute den entsprechenden Formular-Felder zugeordnet.

Event.observe(window, 'load', function() {
  hcr = new com.omniacomputing.HCardMapper({
    register: true,
    proxy: '/hcardmapper/hcard?uri=',
    insertBelowEl: 'hcr-hook',
    mappings: {
      given_name: 'first',
      family_name: 'last',
      tel: {tel: 'phone', work: 'phone', cell:'phone'},
      email: 'email',
      org: {org: 'company', organization_name: 'company'},
      url: 'website',
      street_address: 'street',
      postal_code: 'zip',
      locality: 'town' 
    }
  })
});

Quelle: http://lib.omnia-computing.de/hcardmapper

Tolle Idee, mal schau’n wie gut das Script mit den (oben schon erwähnten) unterschiedlichen Verarbeitungsweisen der Parser umgeht…

Anfang Februar habe ich einen interessanten Bericht über „How portable is your Skype data?“ von Phil Wolff gelesen. Der Artikel befasst sich mit der Daten-Portabilität von Nicht-Web-Applikationen am Beispiel von Skype. Leider wird diese Art des Datenaustauschs (z.B. zwischen Desktop-Anwendungen und Web-Anwendungen) auch von DataPortability.org noch nicht ausreichend behandelt und es fehlen Formate die diese Art von Austausch ermöglichen (APML mal ausgenommen).

Genau diesen Bericht müssen auch Microsoft und Google gelesen haben bevor beide diesen Monat ihre Contacts-APIs veröffentlichten 🙂

Nach den Beschreibungen von Google:

  • Import a user’s Google contacts into their web or desktop application
  • Export their application’s contact list to Google
  • Write sync applications for mobile devices or popular, desktop-based contact management applications

…und Microsoft:

To tackle the issue of contact data portability it is important to reconcile the larger issue of data ownership. Who owns the data, like email addresses in a Windows Live Hotmail address book? We firmly believe that we are simply stewards of customers’ data and that customers should be able to choose how they control and share their data. We think customers should be able to share their data in the most safe and secure way possible, but historically this openness has been achieved largely through a mechanism called “screen-scraping,” which unduly puts customers at risk for phishing attacks, identity fraud, and spam. Now with the Windows Live Contacts API, we have provided an alternative to “screen-scraping” that is equally open but unequivocally safer and more secure for customers.

…könnte man fast meinen, dass die Hürde des Datenaustauschs zwischen Desktop-Anwendungen und Web-Anwendungen überwunden wäre.

Nicht ganz… Leider basieren beide Systeme „noch“ auf proprietären Webservices und müssen unterschiedlich angesprochen werden, was eine Menge zusätzlichen Entwicklungsaufwand bedeutet. Die wesentlich bessere Lösung wäre natürlich eine einheitliche Contacts-API oder wie Carsten Pötter meint:

Of course, it was great if a more open protocol like OAuth was used, but the announcement might encourage more social networks and other corporations to pursue similar steps.

Immerhin gehören die Social-Network-Anti-Patterns durch diese Entwicklungen hoffentlich bald der Vergangenheit an…

Der englische Verlag Mohawk Media will noch im Frühling diesen Jahres eine neue Comic-Reihe mit Mr. T herausbringen. Wer es (wie ich) nicht bis zum offiziellen Start aushält, kann sich die „Mr. T graphic novel – Limited Advance Edition“ jetzt schon bestellen.

mr-t-comic.jpeg

Die Limited Advance Edition liegt jetzt schon seit Ostern bei mir rum, aber ich habe mich noch nicht dran gewagt 🙂

Mal schau’n ob es mit der Kult-Reihe „Mr. T and the T-Force“ aus den 90ern mithalten kann.

Ach ja… Mr. T war sogar schon im Muppet-Magazin 🙂

Wer schonmal versucht hat hCard Profile zu importieren wird sicherlich auf ein Problem stoßen: Welche hCard ist die richtige?

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:

Semantic Web CubeAmit Kumar (Director, Product Management, Yahoo! Search) hat heute weitere Details der geplanten Yahoo! Search open platform veröffentlicht.

Der erste Punkt ist der Support einer großen Spanne an Web-Semantiken wie z.B. RDF, Microformats und OpenSearch:

Initially, we plan to support a number of microformats, including hCard, hCalendar, hReview, hAtom, and XFN. Yahoo! Search will work with the web community to evolve the vocabulary framework for embedding structured data. For starters, we plan to support vocabulary components from Dublin Core, Creative Commons, FOAF, GeoRSS, MediaRSS, and others based on feedback. And, we will support RDFa and eRDF markup to embed these into existing HTML pages.

Ein Beispiel für eine semantische Suche hat Yahoo! ja schon mit seiner Microsearch gezeigt.

Der zweite wesentliche Punkt ist, dass die Yahoo! Search open platform offen für third-party Developers sein wird. Es wird also möglich sein, über eine API auf die strukturierten Inhalte aus dem Yahoo! Index zuzugreifen.

Hört sich sehr spannend an, bin gespannt auf die Umsetzung und die Möglichkeiten der API.

Wer sich für die open search platform anmelden möchte, kann das hier tun.

via microformatique.com

Weitere Infromationen:

Homo Animatus ist eine Arbeit von Hyungkoo Lee und zeigt, wie das Innenleben von Cartoon Figuren aussieht.

Homo Animatus was an extension of a series of earlier pieces where the artist physically sought to alter – to reduce to cartoon simplicity – his own anatomy.

Ich will den Canis Latrans Animatus für meine Wohnung 🙂

Mal schaun ob jemand alle Figuren erkennt…

020L.jpg
Canis Latrans Animatus und Geococcyx Animatus (Quelle: hyungkoolee.net)

Continue reading

Stephen Paul Weber hat für das DiSo Projekt das MovableType ActionStream Plugin für WordPress portiert.
Das Plugin basiert auf der gleichen YAML Basis (Beispiel: config.yaml) wie auch das MovableType Plugin, hat aber noch nicht den kompletten Umfang wie sein Vorbild.

Ich hab das Plugin mal testweise installiert: Mein ActionStream.

Mal schaun was sich in den nächsten Versionen noch alles tut, spannend finde ich vor allem den Punkt profile_services der auch im YAML-File zu finden ist.

[Update]

Die aktuelle Version unterstützt jetzt auch das Nachladen von weiteren Services/Feeds via SocialGraph-API. Mehr dazu auf Stephens Weblog.

Bild von Chris MessinaIch habe heute morgen bei Keasone schon den ersten (deutschsprachigen) Bericht über den Internet Explorer 8 (beta) gelesen. In den Genuss, ihn selber zu testen, bin ich leider noch nicht gekommen, habe aber gerade ein paar interessanten Artikel über ein neues IE8 Feature gelesen.

Mit dem neuen Internet Explorer ist es möglich Teile einer Webseite direkt zu abonnieren, um über Änderungen dieser Bereiche Informiert zu werden, ohne den Umweg über einen RSS-Feed gehen zu müssen. Das Besondere an den so genannten „WebSlices“ ist, dass sie dem hAtom Microformat bis auf ein paar kleine Unterschiede gleichen.

WebSlices are enabled by adding HTML annotations directly to the Web page. WebSlices use a combination of the hAtom Microformat and the WebSlice format to describe a subscribable portion of a Web page. This section covers the primary, expiration, and bandwidth properties of a WebSlice.

Das heißt, Microsoft hat weitestgehend die Attribute des hAtom Formats verwendet und einen eigenen „Container“ darum gesetzt. Statt class="hfeed hentry" heißt es in der WebSlices-Definition class="hslice"

Der Aufbau eines WebSlices sieht folgendermassen aus:

<div class="hslice" id="1"> 
 <p class="entry-title">Item - $66.00</p> 
  <div class="entry-content">high bidder: buyer1 
  ...
 </div> 
</div>

Das hAtom Format im Vergleich:

<div class="hfeed hentry" id="1"> 
 <p class="entry-title">Item - $66.00</p> 
  <div class="entry-content">high bidder: buyer1 
  ...
 </div> 
</div>

Prinzipiell ist die Idee hinter WebSlices, Teile einer Webseite abonnieren zu können, super… schade ist nur, dass sie nicht auf bestehende/etablierte Formate wie hAtom zurückgreifen, sondern wieder ein eigenes proprietäres Format schaffen müssen.
Ich verstehe auch nicht ganz den Sinn hinter diesem Schritt… hAtom ist mittlerweile ein relativ weit verbreiteter Standard (einige Beispiele) und würde dem WebSlices-System sofort einen Anwendungsfall bieten. Durch das Schaffen eines eigenen Formates dauert es seine Zeit, bis Webseiten-Betreiber dieses auch umsetzen (wenn sie es überhaupt umsetzen).

Ich hoffe dass Microsoft seinen Kurs ändern wird oder zumindest das hAtom Format als alternative zu ihrem hSlice ermöglicht.

Weiterführende Links: