Seit 16.09. ist das neue Webstandards-Magazin im Handel erhältlich und gerade jetzt vergess’ ich darüber zu posten… immerhin enthält es Folge 10 von Pfefferles OpenWeb

…und zur Feier des Tages gibt es ein wenig Schema.org-Bashing:

Knapp 2 Milliarden Webseiten sind mit einer hCard ausgezeichnet und RDFa verzeichnete zwischenzeitlich ein Wachstum von 510% , trotzdem haben sich Google, Yahoo! und Microsoft dazu entschlossen ein neues Format zu entwickeln.

Viel Spaß beim lesen und ich freue mich wie immer über ein bisschen Feedback.

Auf schema.org findet man eine Übersicht alle Schemas die die Suchgiganten in Zukunft unterstützen werden:

This site provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results, making it easier for people to find the right web pages.

Was mich besonders freut: Die Schemas basieren alle auf Microdata und wer meinen Blog regelmäßig verfolgt wird wissen, dass ich das Format sehr schätze! Hier ein Beispiel wie eine Person mit dem neuen Schema aussieht:

<div itemscope itemtype="http://schema.org/Person">
  <span itemprop="name">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="image" />
</div>

Soweit so gut, aber… es werden WIEDER einmal weder bestehende Microformats, noch RDFa Schemas auf Microdata portiert, was dazu führt dass mir spontan 5 unterschiedliche Formate einfallen um Personen zu beschreiben: hCard (Microformats), Data-Vocabulary (RDFa- und Microdata-Beschreibung genutzt von den rich-snippets), FoaF (RDFa), vCard (RDFa), schema.org (Microdata).

Die Microformats-Community hat von Anfang an eines richtig gemacht: Es gibt nur eine Stelle an der Microformats definiert werden und man muss einen relativ langwierigen Prozess befolgen um ein neues Format zu definieren. Das führt zwar dazu dass es bisher nur eine handvoll Schemas veröffentlicht wurden, diese aber wohl definiert sind und in der Regel auf bisherigen Formaten aufbauen. Die hCard ist beispielsweise ein 1:1 Abbild der vCard.

Schema.org ist zwar eine ganz nette Idee aber man hat leider versäumt sich mit der Microformats-, RDFa-, RDF- Community zusammenzusetzen und einen gemeinsamen Konsens zu finden!

Wäre folgendes Beispiel so viel komplizierter?

<div itemscope itemtype="http://microformats.org/profile/hcard">
  <span itemprop="fn">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="photo" />
</div>

…oder das?

<div itemscope itemtype="http://www.w3.org/2006/vcard/ns">
  <span itemprop="fn">Jane Doe</span>
  <img src="janedoe.jpg" itemprop="photo" />
</div>

Das Format ist letztendlich Geschmackssache… der eine mag lieber die einfachen Microformats, der andere steht mehr auf RDFa und ich bevorzuge Microdata, man sollte sich aber endlich auf ein einheitliches Schema einigen!

Yahoo! zählt knapp zwei Milliarden hCards in ihrem Index und trotzdem diktiert man Webseitenbetreibern etwas komplett anderes auf…

Auch wenn ich mich wiederhole: Hoffentlich schafft es Yahoo! den SearchMonkey demnächst etwas besser in die Standard-Suche zu integrieren. Man kann doch keinem normalen Menschen erzählen er müsse nach searchmonkey:com.yahoo.page.uf.hcard suchen um Profile zu finden

Die aktualisierte Liste aller unterstützten Formate:

• hCard (searchmonkey:com.yahoo.page.uf.hcard)
• hCalendar (searchmonkey:com.yahoo.page.uf.hcalendar)
• hReview (searchmonkey:com.yahoo.page.uf.hreview)
• hAtom (searchmonkey:com.yahoo.page.uf.hatom)
• hResume (searchmonkey:com.yahoo.page.uf.hresume)
• adr (searchmonkey:com.yahoo.page.uf.adr)
• geo (searchmonkey:com.yahoo.page.uf.geo)
• tag (searchmonkey:com.yahoo.page.uf.tag)
• xfn (searchmonkey:com.yahoo.page.uf.xfn)
• RDFa (searchmonkey:com.yahoo.page.rdf.rdfa)
• eRDF (searchmonkey:com.yahoo.page.rdf.erdf)

…aber der SearchMonkey scheint gerettet:

Yahoo! and Microsoft are sharing ideas for how to advance the SearchMonkey vision of building an ecosystem for developers, publishers, and the semantic web. The landscape is complex, so we’re working hard to determine which path provides the best value for site owners and end users.

Großartig! …immerhin hat SearchMonkey eine neue Suchmaschinen Ära eingeleitet. Vielleicht ist Yahoo! ja mit Hilfe von Microsoft in der Lage den Affen etwas besser in die normale Suche zu integrieren, damit auch Otto Normalsucher von der semantischen Suche profitieren können.

Wer seiner BOSS-Applikation semantischen Charakter spendieren will, muss seiner Query-URL einfach folgende Key-Value Paare anhängen:

• &view=searchmonkey_rdf – für diverse RDF-Formate wie z.B. Dublin Core, FOAF oder SIOC
• &view=searchmonkey_feed – für diverse Microformats wie z.B. hCard oder hCalendar

…und so wird aus einem normalen Ergebnis ein semantisches Feuerwerk

Yahoo verwandelt das Web mit der Yahoo Query Language in eine gigantische Datenbank.

Wer bisher schon etwas Erfahrung mit z.B. MySQL gemacht hat, sollte auch mit YQL keine weiteren Probleme haben. Ein Beispiel:

SELECT * FROM feed WHERE url='http://notizblog.org/feed/'

Übersetzt: Gib mir (SELECT) alle Inhalte (*) des RSS-Feeds (FROM feed) die unter der URL: http://notizblog.org zu finden sind (url='http://notizblog.org/feed/').

Das Spannende (weshalb ich es überhaupt erst erwähne) an YQL ist aber der gerade angekündigte Microformats Support, der die Query Language zu einem vollwertigen Microformats Parser macht.

Über den Befehl:

SELECT * FROM microformats WHERE url='http://notizblog.org/kontakt/'

werden Beispielsweise alle Microformats meiner Kontaktseite geparst und mir in einem standardisierten XML oder JSON Format bereit gestellt.

Großartig! Was Yahoo! im Zuge der Open Strategy mit Systemen wie dem SearchMonkey oder YQL geschaffen hat, ist ein echter Traum für jeden Webentwickler und Open Standards Evangelist! Ich hoffe einer der nächste Schritte wird sein, die YQL (als Alternative zu XSLT) auch in den SearchMonkey zu integrieren.

Ach ja… die YQL-Console bietet übrigens eine schöne Alternative zur YQL-Dokumentation… einfach mal einige bekannte SQL-Befehle eingeben und schauen was passiert (so ähnlich habe ich mir damals auch HTML beigebracht)

Einfach die entsprechende SearchMonkey – Konstante als {query} übergeben (eine Liste von Konstanten findet ihr hier):

http://boss.yahooapis.com/ysearch/web/v1/{query}?appid={youBOSSappid}

http://boss.yahooapis.com/ysearch/web/v1/searchmonkeyid:com.yahoo.page.uf.hcard?appid={youBOSSappid}

oder mit normalen Suchbegriffen kombinieren (alle hCards von Mr. T):

http://boss.yahooapis.com/ysearch/web/v1/searchmonkeyid:com.yahoo.page.uf.hcard+mr.t?appid={youBOSSappid}

Aber ist es wirklich wichtig am Branding “OpenID” zu arbeiten? Yahoo hat in seiner OpenID Usability Studie einen Satz, der das Problem (meiner Meinung nach) ziemlich gut trifft:

“Promote the utility, not the technology”

Als Google seine OpenID Implementierung veröffentlicht hat wurden viele Stimmen laut, Google würde OpenID nur für seine Zwecke “missbrauchen”… Aber ist das nicht genau der Schritt den OpenID gehen muss? Weg von der Technik und dem Branding, hin zur Funktionalität und dem Anbieter. Facebook Connect ist doch nur so erfolgreich (wobei wir das ja noch gar nicht wissen) weil ein normaler Internet-Nutzer den Login wieder erkennt (E-Mail Adresse und Passwort) und versteht… bei Yahoo!s oder Googles Directed Identity Implementierung ist es ähnlich, der Benutzer klickt einen Link wie z.B. “mit Google Account anmelden” kommt zu Google und muss wieder nur das Formular ausfüllen welches er schon kennt. Er bekommt nichts von OpenID mit und hat sich ohne Hürden und (im besten Fall) mit einem Klick angemeldet… und für alle Geeks bleibt immer noch die normale OpenID Anmledung!

Diesen Schritt finde ich sogar noch Sinnvoller als die E-Mail – OpenID, da der Nutzer ohne große Workarounds (und nichts anderes ist EAUT) auf OpenID vorbereitet wird.

Ich würde mich sehr über einige weitere Meinungen und Ideen freuen, also ran an die Tastatur

Dieser Post entstand übrigens als Kommentar bei hackr

Diesmal mit Thomas Huhn, dem Mann hinter dem ersten deutschen OpenID-Provider MeinGuter.name und dem Mitbegründer von SpreadOpenID.org.

Themen des Podcastes sind unter Anderem die neuen OpenID-Provider Google und Microsoft, Vor- und Nachteile des Directed Identity Protokolls und die E-Mail Adresse als bessere OpenID (?).

Thomas hat sich nach dem Podcast übrigens noch ein paar interessante Gedanken über die Zukunft von OpenID gemacht (OpenID Germany ist übrigens auch ein Projekt von ihm).

Viel Spaß beim hören und lesen

Die Links zur Sendung gibt’s wie immer hier!

Den Podcast abonnieren:

• Download MP3
• RSS Feed
• iTunes