Google, Yahoo! und Bing haben heute angekündigt, dass sie beim Thema Websemantics zukünftig zusammen arbeiten werden und sich auf einen gemeinsamen Standard einigen wollen (wie vorher auch bei den Sitemaps, robots.txt, um.).

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>Code-Sprache: HTML, XML (xml)

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>Code-Sprache: HTML, XML (xml)

…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>Code-Sprache: HTML, XML (xml)

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…

12 Kommentare zu “Websemantics: Google, Yahoo! und Bing einigen sich auf einen „Standard“

  1. Vielleicht dumme Frage, aber heißt dass, das Microformats und/oder Microdata wie es sie jetzt gibt dann nicht mehr interpretiert werden?

    Verstehe das Schema-Wirrwarr gerade nicht so ganz….

    • In der Google „Webmaster FAQ“ steht, dass Microformats & Co. wohl weiterhin interpretiert werden:

      If you’ve marked up your content for rich snippets using microformats, microdata, or RDFa, then you’re already familiar with the process. schema.org works the same way, using the microdata markup format and a vocabulary that is shared by all the search engines and that supports a wide variety of item types and properties.

    • Für Microdata als Standard ist das natürlich großartig! Wenn Google, Microsoft und Yahoo! Microdata als neues Format vorschlagen, wenn demnächst jeder SEOler die Schema.org Formate einbauen. Für Microformats wird es in Zukunft nicht so gut aussehen… das ist aber auch gar nicht so schlimm… Microformats hatten ihre Zeit und haben Standards wie Microdata und RDFa inspiriert.

      Das schlimme an der ganzen schema.org Sache ist nicht der verwendete Standard (der prinzipiell total egal ist), sondern die Schemas! Warum portieren die Suchgiganten nicht die hCard oder FoaF auf Microdata sondern erfinden wieder komplett neue Attribute?

  2. Microformats sind ein im Großen und Ganzen gut gelungener Versuch, die vorhandene Semantik von HTML zu ergänzen und zu erweitern, ohne neue Elemente oder Attribute hinzuzufügen. Das finde ich sehr gut. Auch, wenn gerade in der hCard Spezifikation ein dicker Bug drin steckt, bleiben Microformats für mich doch erst mal das Mittel der Wahl. Alles Andere schaue ich mir mal an und warte erst mal ab.

  3. Laut Microformats soll man innerhalb eines vcard Containers z.B. so auszeichnen:

    <a href=“http://www.bla.blubb“ class=“url“>Max Mustermann</a<

    Und das ist grottenfalsch. Erstens besagt die Spezifikation von html schon von sich aus, dass das href Attribut eine URL zu beinhalten hat. Zweitens klassifiziert man mit dem class Attribut nicht irgendein Attribut, sondern den Inhalt des Containers. Und „Max Mustermann“ ist nun mal keine URL. Ein class=“url“ fügt hier also im doppelten Sinn eine falsche Semantik hinzu.

    Richtig wäre das, wenn man etwa wie folgt schreiben würde:

    Meine HP liegt unter <a href=“http://www.bla.blubb“ class=“url“> http://www.bla.blubb </a>

    Jetzt ist der Inhalt des Containers eine url, und das class Attribut korrekt besetzt.

  4. Das mit diesem „abbr Design Pattern“ ist in der Tat nur eine Notlösung. Für die damit angegangenen Aufgaben gibt es leider bis html 4 keine gute und saubere Lösung. Aber Du hast insofern Recht, als dass es der gleiche Murks ist.

    Bei dem value-class pattern ist der Ansatz schon richtig. Ob er besonders gelungen ist, weiss ich im Moment noch nicht, das muss ich mir mal eine Weile durch den Kopf gehen lassen.

    Immerhin _könnte_ man das beispiel auch anders lösen. So kann man z.B. annehmen, dass es in einer Adresse zwar n Telephonnummern gibt, aber davon nur jeweils 1 eines bestimmten Typs. Daher wäre es vermutlich besser, auf class plus id auszuweichen. Also etwa:

    <span class=“tel“ id=“home“>+1.415.555.1212</span>

    Der Haken ist hier natürlich die Dokumentenweit einmalige Verwendbarkeit einer id. Das könnte diese Variante verunmöglichen. Die vernünftige und logische Entscheidung ist hier alles Andere als einfach. Im Gegensatz zu dem class=“url“ Beispiel oben, da ist es ganz einfach.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert