Hier geht es um Webdesign, Microformats, (X)HTML und CSS, Web2.0, usw.
Benjamin Nowack hat auf der Webinale in Karlsruhe einen sehr interessanten Vortrag über das Semantic Web – Technik und Einsatz. Die Folien geben einen sehr schönen (und kompakten) Überblick von HTML-Semantiken wie RDFa oder Microformats bis zu hochwertigen XML-Strukturen wie RDF und OWL.
Schade dass ich den Vortrag nicht hören konnte…
(via)
(mehr …)
Mit Hilfe des vorhin erwähnten GreaseKit funktionieren die Monkeyformats jetzt auch im Safari 🙂
Benötigt wird:
Und genau in der Reihenfolge sollte man die Tools auch installieren…
Leider funktioniert das Szenario nicht ganz so reibungslos wie auf mit Firefox + Greasemonkey + Operator da die SIMBL-Plugins wohl in umgekehrter Reihenfolge (zuerst Microformats-Plugin und dann GreaseKit + Monkeyformats) die Seite abarbeiten.
Es gibt aber ’nen kleinen Workaround:
Das Safari-Microformats-Plugin ist leider auch noch etwas spartanisch und nicht ganz so komfortabel und flexibel wie Operator für Firefox, aber es reicht um hCards und hCalendars zu verarbeiten.
Schön dass die Idee mit etwas Mehraufwand (aber ohne Anpassungen) auch im Safari funktioniert 🙂
(via: monkeyformats.org)
Vor ungefähr einem Jahr habe ich schonmal über einen Microformats Bluetooth-Export mit Hilfe von Tails-Export geschrieben. Da sich aber nach und nach der Operator als DAS Microformats-Addon für den Firefox durchgesetzt hat, wurde natürlich auch das Bluetooth-Script portiert.
Das Mac-Script findet man auf der Seite von Michael Kaply (direkter Link).
“Send to Bluetooth Device” action for sending ICS and VCF files via Bluetooth. Works with the hCard and hCalendar microformats.
…und seit letztem Monat gibt es auch ein Windows-Script von Thom Shannon (direkter Link).
I’ve modified the Mac only bluetooth user script for operator to work on windows. It’s based on this script, and originally inspired by Johns hack of Tails.
Da ich mich in den letzten Monaten viel mit Themen wie DataPortability oder dem Semantic Web beschäftigt habe, kam mir die Frage welche Rolle Microformats in Zukunft einnehmen werden.
Bisher sind zwei (mit hAtom drei) Mikroformate im DataPortability-Konzept enthalten:
Ich denke aber nicht, dass Microformats (zumindest in der klassischen HTML-Version) über längeren Zeitraum diese Position in der DataPortability-Idee einnehmen werden. Microformats sind zwar weit verbreitete und simple Formate um Informationen semantisch aufzubereiten, sind aber schwer zu parsen (HTML) und bieten keinen wirklichen Authentifizierungsmechanismus (da sie direkt im HTML-Quelltext stehen).
Ich bin der Meinung dass OpenID und FoaF alle Eigenschaften von Microformats auf eine wesentlich bessere Weise lösen können. FoaF ist losgelöst von der normalen Webseite und kann so problemlos über OAuth oder OpenID geschützt werden und bildet sogar Profildaten und Freundesnetze ab. Noch einfacher wäre OpenID Attribute Exchange, da so SingleSignOn, Portabilität und Authentifizierung mit einem Standard abgedeckt sind.
Den einzigen DP-Anwendungsfall den ich mir für Microformats vorstellen könnte wäre eine Alternativ-Form (zu HTML) wie z.B. JSON oder XML, da sie sich im Gegensatz zu Attribute Exchange oder FoaF an bestehende Standards (z.B. vCard) halten und wohl definiert sind, würde aber nicht mehr viel mit der klassischen Idee der Microformats zu tun haben.
Microformats werden auch immer wieder (fälschlicherweise) als Teil des Semantic Web bezeichnet und lassen sich dank GRDDL auch problemlos in dieses integrieren, bieten aber sonst keinerlei Semantic-Web-Eigenschaften. Nach der Veröffentlichung von RDFa haben Microformats aber auch einen schlechten Stand als „real world semantics“.
Ein wesentliches Defizit der µF im Vergleich zu RDFa ist die schlechte Skalierbarkeit und das Problem der fehlenden Triples.
Sieht man das Semantische Web als Zukunft des Internets, werden µF wohl in nächster Zeit auch auf diesem Gebiet von dem wesentlich semantischeren RDFa abgelöst.
Bei Medientheoretikern gibt es die These dass „bislang noch kein Medium von einem anderen überflüssig oder verdrängt worden wäre„, warum sollte das nicht auch für offene Standards gelten 🙂
Ich kann mir zwei sinnvolle Anwendungsgebiete für Microformats vorstellen (über die ich auch noch etwas detaillierter schreiben möchte), in denen es (noch) keine bessere Alternative gibt.
Microformats sind direkt in die Webseite integriert und benötigen keinen Backchannel wie z.B. bei XML-Schnittstellen wie RSS, deshalb bietet es auch eine Ideallösung für Semantische Suchmaschinen wie z.B. Yahoo!s Search Monkey oder Technorati Kitchen. Suchmaschinen haben durch uF die einmalige Möglichkeit, strukturierte Inhalte zu indexieren und auf deren Basis, Systeme wie z.B. Kalender, online Telefonbücher und Musiksuchen abzubilden. Hier haben Mikroformate durch die Anzahl der schon definierten Formate und deren weite Verbreitung auch einen enormen Vorteil gegenüber RDFa.
Eine zweite Niesche beschreibt Sascha Konietzke in seinem Artikel What Are Microformats and What Do They Mean to Mobile?. Die meisten Handys unterstützen mittlerweile normales XHTML und wären somit ein idealer Client für Microformats. Der Hauptfokus neben dem Telefonieren und dem SMS schreiben liegt bei Handys auf dem Adressbuch oder dem Kalender, also genau den zwei weit verbreitetsten Mikroformaten hCard und hCalendar. Auch die, ursprünglich für Twitter entworfenen, Nanoformats wären ein idealer Standard um semantisch zu SMSen 🙂
Auch wenn Microformats keine Ideallösungen für DataPortability sind und nicht der Semantic Web Idee entsprechen, gibt es sicherlich genug sinnvolle Anwendungsgebiete.
Jetzt wo der Release Candidate 1 von Firefox 3 erhältlich ist, fragen sich einige wo denn die „versprochenen“ Microformats sind. Michael Kaply, der Macher von Operator (und meines Wissens auch der Mann hinter der Firefox-Microformats-API) versucht diese Frage in seinem Weblog zu beantworten:
The answer is that there is a microformats API in Firefox 3, but unfortunately there is nothing available in the UI for this release.[…]
The primary reason that microformats aren’t exposed in the Firefox UI is that there was never any agreement as to how to expose them.
Da hatte ich damals ja gar nicht so unrecht:
Ich bin mir nicht 100%ig sicher, aber ich glaub es wird nur eine API für das Parsen von Microformats gestellt, da es das Operator Plugin ja auch für Firefox 3 gibt.
Wie das mit den oben genannten Selektoren aussieht weiß ich auch nicht.
Wer sich für das Thema Firefox, Microformats und die Zukunft von Operator interessiert, sollte sich einfach mal Kaplys kompletten Artikel durchlesen.
Martin McEvoy von WebOrganics hat gerade den Microformats Transformr angekündigt. Die Daseinsberechtigung des Transformr neben Optimus, dem Chef-Transformer (ich hoffe die Transformers sind euch ein Begriff 🙂 ), ist die umfassende hAudio-Unterstützung, was wohl daran liegt dass Martin McEvoy aktiv an diesem Standard mitarbeitet.
hAudio Features:
XSPF („spiff“) steht für XML Shareable Playlist Format und ist ein offener XML-Standard für Playlisten.
Ein weiteres interessantes Feature ist hFoaF welches hCards und XFN in FoaF wandelt.
Ist SMOB (Semantic Microblogging) das dezentrale Twitter über das in den letzten Tagen an verschiedenen Stellen nachgedacht wurde?
SMOB is a distributed / decentralised microblogging system built on RDF and Semantic Web technologies, mainly SIOC and FOAF. Currently, we have simple prototypes of a publishing and an aggregating service, less than 100 lines of PHP code each.
Links:
Nach seinem Artikel über DataPortability und Chris Saads Antwort, äußert sich Chris Messina nochmals sehr kritisch zu dem Thema in der DP Google-Group.
Gerade nach den Pressemeldungen über MySpaces „Data Availability“:
[…] MySpace is announcing a broad ranging embrace of data portability standards today, along with data sharing partnerships with Yahoo, Ebay, Twitter and their own Photobucket subsidiary. […] #
…oder über Googles „Friend Connect“:
As we reported on Friday, Google will be launching its own data portability effort called Friend Connect. […] #
…ist (meiner Meinung nach) einer der treffendsten Punkte in Chris‘ Kommentar:
The behavior indicates […] that the DP-PR machine is simply more effective at taking credit for big moves that they had nothing directly to do with than to promote smaller independent, more „grassroots“ groups who are *actually* making moves towards effective data portability, like Dopplr, like TripIt, like Satisfaction and Twitter and the rest. I don’t believe I’ve seen any press releases go out about them, and yet I would consider them to be on the vanguard giving people access to their data in real-world, useful ways.
Ich muss Chris Messina leider recht geben, keines der groß angekündigten (und mit DataPortability in Verbindung gebrachten) Systeme betreibt wirklich DataPortability (zumindest zum aktuellen Zeitpunkt). Sowohl MySpace als auch Google verwenden zwar offene Standards (Facebook nutzt sogar keinen der erwähnten Standards für „Facebook Connect“) wie OAuth oder OpenID, aber bisher leider nur hinter ihren „Walled Gardens„.
Was ist mit den wahren DP „Helden“ wie Dopplr, Magnolia oder Satisfaction, die wirkliche Anwendungsfälle schaffen und sich dem Ziel der portablen Daten Schritt für Schritt nähern?
Carsten Pötter beschreibt das bestehende Problem auch noch einmal von einer etwas anderen Seite:
DataPortability, Data Availability, Facebook Connect, Google Friend Connect, DiSo,… […] All the mentioned initiatives just lead to confusion. We can’t be sure if we mean the same thing when talking about data portability anymore. It’s probably best to abandon that term and just focus on single issues. Can I export my profile or can it just be accessed by a third party?
Man sollte in Zukunft vielleicht etwas sparsamer mit dem Titel DataPortability umgehen und ihn nicht für jede „simple“ hCard vergeben.
Letzte Woche ist auf Robert Basics Artikel zu APML eine interessante Diskussion zu dem Sinn und Zweck von APML entstanden. Einer der größten Kritikpunkte an dem Attentiondata-Format ist das fehlende „normierte Vokabular“ und die daraus entstehenden Probleme beim verarbeiten.
Ich kann diese Kritikpunkte zwar nachvollziehen, bin aber dennoch der Meinung dass es auch für die aktuelle Form des Attention-XMLs einige Anwendungs-Szenarien gibt, die ich hier beschreiben möchte…
Die Informationsflut im Internet wird immer größer und schneller, wie Herr Scoble in seinem Artikel „The noise reduction system“ sehr treffend bemerkt:
Oh, the glorious noise! Everyone loves beating me up for causing the noise. No, I am not the cause. I pass it along. You should see my inbound streams. Every second or two a new Twitter is aimed at me. Every few seconds, a new blog post comes into Google Reader. Every few seconds, a new thing on FriendFeed.
Der Artikel ist auf alle Fälle lesenswert und beschreibt auch einige Lösungsansätze, auf die ich aber nicht weiter eingehen möchte. Was ich viel interessante finde ist, dass APML genau der richtige Filter für dieses Signal-Noise-Ratio – Problem ist.
Einer der Themen in Scobles Beitrag ist die enorme Flut von Informationen/News die täglich in seinem News-Reader auflaufen. Um diesem Problem Herr zu werden bräuchte man einen Filter, der selbstständig entscheidet was für ihn relevant ist und was nicht.
Ein APML-File bietet alles was für einen einfachen Filter notwendig ist:
Mit diesen Informationen sollte es doch recht einfach möglich sein, die Neuigkeiten die in (z.B.) meinem Feed-Reader auflaufen zu bewerten und mir einen (ausgewählten) News-Stream zu präsentieren. So zusagen ein Spam-Filter für News (und einem Spam-Filter sind wir ja auch nicht böse wenn mal eine Mail durchrutscht, weil er uns doch ne ganze menge Arbeit erspart).
Da es sich bei diesem Filter nur um ein optionales Feature handelt, bleibt es dem Nutzer selbst überlassen welcher Art des Informations-Konsums er frönen will.
NewsGator, einer der führenden Feed-Reader Anbieter, hat auch schon einige Schritte in diese Richtung angekündigt und bietet bei einigen seiner Produkte auch schon ein paar APML-Funktionalitäten an.
Der andere angesprochene Punkt ist die Kommunikation verursacht durch Microblogging-Dienste wie Twitter, Jaiku oder FriendFeed. Will man diese aktiv verfolgen ist es nahezu unmöglich nebenher noch einer normalen Tätigkeit nach zu gehen.
Um noch einmal Herrn Scoble zu zitieren:
The problem? Twitter and FriendFeed have brought new noise into our lives (at least for the early adopter types) and there aren’t good ways to reduce the noise.
But FriendFeed shows us a way out. How about seeing only posts that have at least two “likes?” Isn’t that a way to reduce the noise? Yes! […]
Auch hier würde ein Filter in Form meiner Attention-Daten den Kommunikations-Stream enorm reduzieren. Wenn Auszeichnungen wie #hashtags weiter Verbreitung finden sollte es nicht schwer sein, diese mit meinen Attention-Tags zu vergleichen und zu bewerten. Selbst ohne #hashtags ist es immer noch möglich, den Inhalt (sind ja nur 140 Zeichen) mit den Interessen abgleichen.
Im nächsten Schritt könnte man den User (ähnlich wie bei Facebook) entscheiden lassen, welches Ranking die Inhalte mindestens haben müssen um angezeigt zu werden.
Ich denke gerade bei diesen zwei Anwendungsbeispiele ist die einfache XML-Struktur eher ein Vorteil als ein Nachteil. Das Ranking sollte schnell und unkompliziert funktionieren und es sollte auch kein Problem sein, wenn eine Information durch diesen Filter rutschen sollte.
Via Marcel Weiss‘ Artikel „Der biblische Signal-Noise-Kampf“
In den letzten Tagen wurde in der Microformats-Community viel über das Thema standardisiertes Parsen und einheitliches Darstellen der verschiedenen Mikroformate (hCard im speziellen) diskutiert.
Leider gab es bisher keinen einheitlichen „Microformats-Acid-Tests“ sondern nur vereinzelte (projektspezifische) Seiten um einige Spezialfälle zu testen.
Glenn Jones, einer der Macher von ufXtract hat jetzt eine sehr schöne Microformats-Testsuite erstellt, die parser-unabhängig funktionieren soll um eventuelle Interpretationsfehler erkennen und vergleichen zu können.
Um die Tests so einfach wie möglich zu gestalten, hat Glenn einen einen JavaScript-Testrunner entwickelt (siehe Screenshot). Testen kann man den Runner unter z.B. http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm in dem man einfach Alt + X drückt (CTRL + ALT + X auf dem Mac).
Hier sei nochmal erwähnt warum es so wichtig ist, dass jeder Parser das gleiche (micro)JSON-Format nutzt:
Please note that at this stage the JSON standardisation process can cause a test to be marked as failed when it could be judged to have passed. #
Nur bei einer gleichen JSON-Struktur kann der Output sinnvoll verglichen werden. Eine erste Version der jCard (danke nochmal an Gordon Oheim für sein Engagement) findet man im Microformats-Wiki.
Wer die Testsuite für seinen eigenen Parser einsetzen will, sollte sich mal die Testsuite-API zu Gemüte führen.
Rather than just build something in isolation I thought it would be nice to find a way to share this work with the community. #
Großartige Arbeit!
Interessante Links zu dem Thema:
