Auf meinem Blog findet man mittlerweile über 50 Artikel zu Microformats … aber bisher kaum einen, der die negativen Aspekte beleuchtet. Da Microformats immer stärker adaptiert werden und an Beliebtheit zunehmen, ist es an der Zeit die kritische Brille aufzusetzen und einen Blick auf die Schattenseiten von Microformats zu werfen.
1. Die kleine Semantik
Bei Microformats handelt es sich zweifelsohne um eine Möglichkeit mit Hilfe von standartisierten Class-Names (und noch ein paar Punkten mehr) das semantische Markup einer XHTML Datei wesentlich zu verbessern … aber:
Ein ganz entscheidender Punkt, hin zu einem semantischen Web, was in einem Maße vernetzt ist, dass Maschinen es komplett ohne die Hilfe menschlicher Fähigkeiten “verstehen” können, kann mit Microformats nicht erreicht werden!
Beispiel hCard: Findet ein Parser eine hCard auf einer Webseite, weiss er zwar: “Hey - hier handelt es sich um Kontaktdaten”, er versteht die einzelnen Teile der Information (Name, Telefonnummer, Email usw.) und kann sie weiterverarbeiten, aber er kann nicht den Kontext verstehen, indem sich die hCard befindet:
- Ist diese Person der Author der Webseite?
- Ist diese Person der Author eines Artikels auf der Webseite?
- Befindet sich hier ein Text auf der Webseite über diese Person?
Diese wichtige Unterscheidung bleibt dem Parser verborgen. Microformats können leider nur in einem ganz begrenzten Radius Relationen untereinander deutlich machen, indem sie verschachtelt werden … aber auch da stösst man schnell an die Grenzen.
2. Die 80/20 Regel
Bei dem Entwicklungsprozess von Microformats hält man sich strickt and die 80/20 Regel. Das bedeutet im Klartext, dass Microformats ganz bewusst einfach gehalten werden (damit also so auf 20% rumköcheln), um mit ihnen 80% der Probleme lösen zu können.
Ist der Anspruch aber höher und man möchte auch noch die letzten 20% lösen, würde man die Formate unnötig aufblähen und komplex gestalten müssen. Dies ist ausdrücklich nicht gewünscht und daher kann man jetzt schon sagen, dass man mit Microformats immer wieder an Grenzen stossen wird und niemals alles abbilden können wird.
Bereits jetzt finden auf der Mailingliste Diskussionen statt, wo es Vorschläge für neue Formate gibt, bei denen man dann feststellt, dass eine Kombination aus bestehenden Formaten doch schon 80% des Problems löst und damit werden dann die neuen Vorschläge abgewiesen, da sie nur dazu da sind, die letzten 20% zu lösen.
Das klingt im ersten Moment zwar hart, ist aber in Summe gut für Microformats, da peinlichst darauf geachtet werden muss, dass wir am Ende nicht mit mehreren hundert Formaten darstehen, die alle ganz kleine Spezialprobleme lösen.
3. Mangelnde Skalierbarkeit
Damit wären wir auch schon beim nächsten Punkt: Microformats beruhen immer auf bereits existierenden Datenformaten. (z.B. hCard auf vCard) Das hat natürlich große Vorteile, aber auch den Nachteil, dass sie an diese dann gebunden sind und somit nicht frei skalierbar sind.
Wenn man jetzt was erweitern wollen würde, wäre man streng genommen darauf angewiesen, dass sich nicht nur hCard verändert, sondern auch das zugrunde liegende Format vCard modifiziert wird. Das Konzept von Namespaces und Onthologien fehlt an dieser Stelle und schadet in dem Fall der Skalierbarkeit. (bzw. die Namespaces sind extrem flach)
Ähnlich wie RDF Schema gibt es zwar für Microformats auch die XMDP Profile - mit deren Hilfe die Parser in der Lage sein sollen, die Datenformate zu validieren - aber der strikte Entwicklungsprozess von Microformats erlaubt es nicht, diese XMDP Profile beliebig zu erweitern, auch wenn rein theoretisch ein guter Parser anhand des XMDP Profils dann in der Lage wäre mit erweiterten Formaten umzugehen.
4. Die Verknüpfung mit XHTML
… ist eigentlich Segen und Fluch zu gleich! Der Fluch liegt darin begründet, dass es für einen Parser leider auf Grund der weit verbreiteten Invalidität von XHTML schnell zu Problemen kommen kann, die ein korrektes auslesen des Microformats verhindern oder zumindest stark erschweren.
XHTML Code ist numal leider nicht immer 100%ig korrekt verschachtelt und oft unsauber geschrieben oder generiert worden. Das erhöht natürlich die Gefahr einer Fehleranfälligkeit der Parser enorm und macht die ganze Geschichte zu einer instabilen Angelegenheit.
Daneben bringt es auch noch den Nachteil mit sich, dass immer das komplette XHTML File übertragen und geparst werden muss, auch wenn man nur die kleine hCard haben möchte. Mit ausgelagertem RDF/XML zum Beispiel hat man diese beiden Probleme nicht wirklich, bzw. in einem viel viel geringerem Maße.
5. Humans first, maschines second
Aus diesem - an sich sehr positiven - Leitsatz leitet sich leider der fünfte Nachteil von Microformats ab: Es werden ausschliesslich für Menschen sichtbare Informationen mit Microformats ausgezeichnet!
Das bedeutet, dass bei der Implementierung von Microformats der Grundsatz gilt, dass man mit ihnen keine Informationen auszeichnen soll, die z.B. per CSS bewusst unsichtbar gemacht worden sind.
Hier stösst man somit erneut an eine Grenze der Flexibilität und Skalierbarkeit. Verfolgt man das Ziel an menschliche Leser andere (bzw. weniger) Informationen auszuliefern, als an Maschinen/Programme, die evtl. auf den gleichen Content automatisiert zugreifen wollen, sind Microformats nicht das Mittel der Wahl.
… und die Moral von der Geschicht:
Microformate sind trotzdem toll und sollten weiterhin gefördert und implementiert werden! 
Diese fünf Faktoren sind zwar sicherlich noch nicht alle Nachteile von Microformats, stellen für mich aber die wichtigsten Punkte dar, die man im Kopf haben sollte, wenn man Microformats betrachtet und mit Ihnen arbeitet will.
Trotzalledem bin ich natürlich weiterhin von Microformats begeistert, da sie dem semantischen Web an sich gut tun und einfach sehr viel Bewegung ins Spiel bringen und Aktivitäten freisetzen.
Mit 80% kann man immerhin schon sehr viel machen und darüber hinaus lösen Microformats ein Problem, was so oder so gelöst werden sollte: Die Schaffung von Standards für CSS-Class-Names!
Ich denke daher auch, dass sich Microformats als solche nicht wieder in Luft auflösen werden, wenn z.B. RDFa seinen Siegeszug mit XHTML2 antreten wird (was ich stark vermute). Aber sie werden dann, was das Thema “Semantic Web” angeht, vielleicht nicht mehr in der ersten Reihe stehen.
10 responses so far ↓
1 Jens Grochtdreis // Sep 25, 2006 at 1:45 pm
Ich habe noch ein uuuuuuuraltes Blogsystem, ohne Trackback und son Gedöns. Deshalb hier mein manueller Trackback: http://www.grochtdreis.de/weblog/index.php?id=P1110
2 Sebastian Küpers // Sep 25, 2006 at 2:27 pm
Mal als Tipp für fehlende Trackbackfunktion: http://kalsey.com/tools/trackback/
Ansonsten hab ich auf deinen Beitrag bei Dir in den Comments geantwortet.
3 Jens Meiert // Sep 25, 2006 at 4:11 pm
Es gibt mindestens ein klares technisches Defizit bei Mikroformaten: Sie stellen nie die eleganteste Umsetzung dar, verbraten also immer mehr Code und Zeichen, als prinzipiell notwendig (und dennoch verständlich) wären.
(Und ich lasse andere technische Aspekte wie Wartbarkeit - eine echte “Herausforderung” zum Beispiel bei XFN - oder Invalidität - “compact”-Attribut bei XOXO - mal beiseite…)
4 Sebastian Küpers // Sep 25, 2006 at 6:06 pm
@JensM … ja - wobei sie schon in den meisten Fällen wirklich geringfühig mehr Code verursachen. Die CSS Class-Names würde man ja in den meisten Fällen so oder so setzen.
In den Beispielen, die man gerne für eine hCard anführt (oder auch bei den Creators), werden immer extrem viel div oder span Tags bentutzt, die aber in der Form natürlich nicht wirklich notwendig sind, da man dem Class Attribut ja mehrere Werte zuordnen kann und somit die Sache meist eher “platzsparend” lösen kann und sollte.
Im idealfall sollte also das Kosten/Nutzen Verhältniss eigentlich stimmen. Gerade wenn man die Alternative betrachtet: Eine zusätzliche RDF/XML Datei
Insgesamt finde ich diesen “Zwei Fliegen mit einer Klappe” Ansatz schon sehr sympatisch.
Die Wartbeikeit hängt meines erachtens ja im Regelfall von denn Publishing-Tools ab. Wenn man jetzt z.B. Wordpress nimmt, ist dort ja schon sehr komfortabel die XFN Funktionalität integriert.
Lediglich beim selber coden, ist ein RDF/XML File ausnahmsweise mal übersichtlicher, als der ganze Wust eines XHTML Files.
5 Harald Kampen // Sep 29, 2006 at 3:36 am
Als ich den Artikel gefunden hab, dachte ich weniger an technische Nachteile. Mir schoß gleich der Datenschutz durch den Kopf. Ist XFN nicht ein Paradies für Martforscher und Geheimdienstler? Und was passiert mit einer hCard? In welchen Verzeichnissen landet sie? Sicher werden die Einträge in zig Datenbanken nicht gelöscht, wenn ich sie von meiner Site nehme.
Die genannten technischen Nachteile ergeben sich IMHO aus den Nachteilen von der aktuellen Unterstützung durch verbreitete Software. Es ist doch nur logisch, auf das aufzusetzen, was in der Breite verfügbar ist, wie z.B. vCard oder vCalendar (was selbst noch nicht mal vollständig diversen Kalendertools interpretiert wird). Klar fehlt mir auch eine Menge, ganze Bereiche werden nicht abgedeckt. Aber das ist nun mal der Stand der Technik.
Detaillierte Versionen in XML seperat abzulegen finde ich in manchen Fällen sinnvoll. Aber vor dem Einsatz RDF und Microformats sollte sich doch jeder erstmal fragen, welche Informationen er überhaupt maschinenlesbar verbreiten will - vor allem wenn es um die Daten Dritter geht.
6 Sebastian Küpers // Sep 29, 2006 at 8:38 am
Danke für den Comment. Was nochmal ganz wichtig ist: KEINER der oben genannten Faktoren ist abhängig von der Unterstützung durch Applikationen, sondern liegt in der Architektur und Philosophie des Formates selbst begründet und wird sich auch mit einer stärkeren Verbreitung nicht ändern!
Das Spam/Datensicherheit Argument wird in dem Kontext Microformats eigentlich immer angeführt. Wichtig wäre es mir an der Stelle zu sagen, dass das kein Microformats spezifisches Problem ist, sondern ein “Semantic Web” Problem an sich. Technologie unabhängig.
Dazu vielleicht dann nur ganz kurz meine Meinung:
——————-
- Sich vor Spam und Datenklau/Speicherung zu schützen, beginnt mit der Publikation von Content und nicht mit dem semantischen Markup.
- Schutz vor Spam ist nicht Sache des semantischen Markup, sondern findet an anderer Stelle statt und muss an anderer Stelle bekämpft werden. Denn Spam wird immer seinen Weg finden.
- Durch semantisches Markup wird es Usern in Zukunft möglich sein, ihre Daten aus Diensten heraus zu exportieren. (Siehe openBC Diskussion)
Das ist der Anfang einer Entwicklung, die die Kontrolle über die Daten in die Hände der User zurückgibt und zu einer Politik im Netz führen wird, die Datensilos eher verhindert, als dass sie sie schafft.
7 Siegfried // Oct 9, 2006 at 12:03 pm
Hi,
zu Punkt 1: Autorenschaft oder nicht muß man auch nicht mit hCard auszeichnen. Man kann sämtliche Miktoformate prima miteinander kombinieren, und man kann sie auch mit älteren Pseudostandards kombinieren.
hCard enthält u.A. die Möglichkeit, Links mit einzubauen. hCard spezifiziert ja nur Klassennamen, keine Elemente. Also muß man beileibe nicht nur span verwenden. Und links bieten die Möglichkeit, einen hCard-Klassennamen plus einem rel oder rev-Attribut zu verwenden. So kann man zum Beispiel den Namen mit einem Link zur Impressumsseite einfassen, diesem Link den Klassennamen “fn” geben und das rev Attribut “author” verpassen. Das würde besagen, daß die somit verlinkte Person der Autor der verlinkenden Seite ist. Alternativ ginge das auch mit dem XFN Microformat, wenn man voraussetzt, daß “me” immer den Author dieser Seite bezeichnet. In dieser Art könnte man beispielsweise den hCard-Adressensatz im Impressum auszeichnen, vorausgesetzt, man würde die xfn-Spezifikationen ausdehnen auf die rel- und rev-Attribute. Ich hatte Sowas dort schon mal vorgeschlagen, aber leider absolut überhaupt gar keine Reaktion bekommen. Also mache ich es bei mir einfach so.
Durch die Kombination der diversen Mikroformate lässt sich die Semantik prima erweitern, ohne neue Spezifikationen zu benötigen. Und bekanntlich ist ja das Ganze mehr als die Summe seiner Teile. So kann mit der richtigen Kombination Semantik hinzugefügt werden, die mit den einzelnen Mikroformaten nie erreichbar wäre.
8 Kaffeeringe.de // Jan 29, 2007 at 7:17 pm
Microformats - Yet another Hype?…
Eines der Buzzwords des letzten Jahres ist “Microformats”. Microformats sind ein Ansatz mit den Mitteln der verbreiteten Standards Inhalte im Internet mit semantischen Metadaten anzureichern. Aber was steckt dahinter? Und sind Microformats dafür gee…
9 Mikroformate - Damit es auch Maschinen verstehen - NET- BUSINESS BLOG // Apr 18, 2007 at 8:45 pm
[…] Der Einsatz von Mikroformaten ist bislang schon mehrfach diskutiert worden. Sebastian Küpers (alias Pixelsebi) hat in einem Blogbeitrag fünf Nachteile von Mikroformaten aufgeführt. Im Wesentlichen führt er die leichtgewichtige Philiosophie hinter dem Ansatz als Kritik auf. In gewisser Weise mag er damit recht haben. Allerdings würde ich die genannten Punkte nicht nur aus der negativen Brille betrachten: sie haben durchaus auch positive Merkmale! […]
10 Prices temp soma. // Nov 12, 2007 at 8:21 pm
Prices temp soma….
Temp soma. Prices temp soma. Temp and soma and mattress. Temp soma mattress topper….
Leave a Comment