quote
· · zu lesen

The desire for better Web APIs is what motivated the creation of JSON-LD, not the Semantic Web. If you want to make the Semantic Web a reality, stop making the case for it and spend your time doing something more useful, like actually making machines smarter or helping people publish data in a way that’s useful to them.

JSON-LD and Why I Hate the Semantic Web

Manu Sporny über seine Aversion gegen das Semantic Web und wie (bzw. warum) er JSON-LD ausgerechnet in diesem Umfeld entwickelt hat.

Text

· · zu lesen

Ausgabe 20 vom SCREENGUIDE Magazin ist draußen und das bedeutet, dass auch meine Kolumne "20" wird!

(Naja… In Ausgabe 1 war es streng genommen "nur" ein Artikel über Microformats (Semantic Surfing), aber thematisch ist da ja kein großer Unterschied 😉 )

In der aktuellen Kolumne geht es jedenfalls um HTML5 und DRM:

Mit der Entwicklung eines Digital-Rights-Management-Systems für HTML5 hat das W3C in den letzten Wochen für viel Aufmerksamkeit gesorgt. Warum arbeitet gerade die Organisation, die sich „Open Standards“ und „Web for All“ zu Grundsätzen gemacht hat, an einem System, um genau diese einzuschränken?

Viel Spaß beim lesen und auf die nächsten 20 Ausgaben 🙂

Text

· · zu lesen
W3C Community Logo

(Kleiner Nachtrag zu der „OAuth ist tot“ Kolumne in der SCREENGUIDE Ausgabe 15 um zu zeigen, warum gerade das W3C auch für Community Formate durchaus nützlich sein kann)

Vor ein paar Wochen kam eine E-Mail mit der Bitte, an einer Umfrage zu den W3C Community and Business Groups teilzunehmen und das hat mich daran erinnert, dass ich mich bisher noch gar nicht zu dem Thema geäußert habe… das hole ich hiermit kurz nach!

Ich beschäftige mich ja jetzt schon eine ganze Weile mit dem Web und seinen diversen Formaten, Standards, Techniken, Spezifikationen usw. usf. Leider ist das Web aber ziemlich vergänglich und eine Menge guter Ideen und Formate sind, aus Mangel an Interesse, mangelndem Durchhaltevermögen, nicht genug Ruhm oder einfach nur aus kurzfristigen „Publicity“ Interessen wieder spurlos verschwunden.

Hier ein paar Beispiele:

  • MicroID – Ein simples Format um das leidige Thema „Webseite verifizieren“ zu vereinheitlichen. Domain nicht mehr erreichbar!
  • POSHFormats – POSHFormats wollte alle Websemantiken sammeln die es leider nicht zu einem Microformat geschafft haben. Domain nicht mehr erreichbar!
  • MicroJSON – Ein Projekt welches sich mit der JSON-Serialisierung von Microformats beschäftigt hat. Zum Glück hat die Diskussion einen Weg ins Microformats-Wiki gefunden. Domain nicht mehr erreichbar!
  • Portability Policy – Das DataPortability Vorzeige-Projekt wollte eine vereinheitlichte Policy für die Portability von Daten schaffen. Domain nicht mehr erreichbar!
  • Microsyntax – Eine Sammlung von Microblogging Syntaxen wie z.B. das „@username“ oder „RT“. Domain nicht mehr erreichbar!
  • AXSchema.org – Die Seite wollte die Attribute für OpenIDs Attribute Exchange sammeln. Domain nicht mehr erreichbar!
  • Monkeyformats.org – Eine etwas schräge Idee, Webseiten per Greasemonkey-Scripts mit Microformats zu versehen um sie dann mit Microformats-Plugins interpretieren zu können. Alleine wegen dem Namen aber schon großartig :(|)! Domain nicht mehr erreichbar!
  • Bioformats – Mikroformate um biologische Daten abzubilden. Domain wurde verkauft!

…um nur einige zu nennen. Ob jetzt alle Projekte gut waren, darüber lässt sich streiten, aber es ist auf alle Fälle schade dass sie mittlerweile gar nicht mehr erreichbar sind. Viele Ideen waren vielleicht zu früh gedacht oder das Problem, das sie versuchten zu beheben, war einfach noch nicht groß genug. Oftmals braucht es vielleicht einfach nur ein wenig mehr Zeit! Lange Rede, kurzer Sinn: Die W3C Communities bieten genau für diese Community Formate die ideale Plattform:

A W3C Community Group is an open forum, without fees, where Web developers and other stakeholders develop specifications, hold discussions, develop test suites, and connect with W3C’s international community of Web experts. Community Groups may produce Specifications; these are not standards-track documents but may become input to the standards process. For instance, a Community Group might gather to work on a new technical specification, or convene to have discussions about a tutorial for an existing specification.
W3C FAQ

Auch wenn aus den Formaten kein „Standard“ werden sollte, so sind sie beim W3C doch besser aufgehoben und HOFFENTLICH auch für längere Zeit erreichbar! Gerade Junge Projekte wie „Unhosted Web“ oder „Federated Social Web“ scheinen die W3C Communities gut anzunehmen und auch Facebook forciert eine „Mobile Web“ Gruppe (die jetzt vielleicht nicht mehr so aktiv betrieben wird ;)).

Vielleicht macht sich jemand ja mal die Mühe und zieht zumindest die MicroID und die Portability Policy um!

Text

· · zu lesen
openid-complex

Hat der erste Entwurf von OpenID Connect noch auf eine (übersichtliche) Seite gepasst, braucht der Draft der OpenID Foundation schon 7 unterschiedliche Spezifikationen.

Wieso müssen „Standard“-Organisationen wie das W3C (z.B. RDFa) oder der OpenID Foundation denn alles so unnötig kompliziert machen? Immerhin schafft es ja sogar Facebook seinen Authentifizierungsprozess auf einer Seite zu erklären. …und noch besser! Er lässt in drei Sätzen zusammenfassen:

  1. Hol dir über folgende URL einen Access-Token:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL
  2. Häng ihn an folgende URL, auf den du den User weiterleitest:
    https://www.facebook.com/dialog/oauth?
    client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&
    scope=email,read_stream
  3. Fertsch!

…dazu kommen eine weitere Discovery-Variante die Webfinger, host-meta, XRD, XRDS oder YADIS komplett ignoriert und eine Identity-API die SREG oder AX noch nicht einmal ähnelt!

Mike Jones, einer der Hauptentwickler der Spezifikation, schreibt zwar:

The design philosophy behind OpenID Connect is “make simple things simple and make complex things possible”.

Das ist aber nur die halbe Wahrheit. Webseitenbetreiber, die zukünftig einen OpenID Connect Login anbieten wollen, haben es in der Tat etwas einfacher, da sie sich auf die „Minimalanforderungen“ konzentrieren können. Seiten die einen OpenID Connect Provider stellen wollen haben aber folgendes Problem:

Authorization Requests can follow one of two paths; the Implicit Flow or the Authorization Code Flow. […]
The OpenID Connect Basic Client profile only documents Clients using the Implicit Flow. OpenID Providers MUST support both flows. […]

Damit begeht die OpenID Foundation wieder den gleichen Fehler wie bei OpenID 2.0. Am Schluss gibt es so viele unterschiedliche und halbfertige Implemenrierungen, dass man wieder auf SaaS-Dienste wie Janrain oder Gigaya zurückgreifen muss. Wozu braucht es dann noch einen „Standard“?

Warum denn immer 1000 Alternativen anbieten? Bei Facebook klappts ja auch ohne…