WordPress Blogposts mit Solid verbinden – wp-linked-data 0.5 verfügbar

Ich habe gestern Version 0.5 von wp-linked-data veröffentlicht. Mit diesem WordPress Plugin könnt ihre euer Blog und die Blogartikel als Linked Data verfügbar machen und somit auch mit eurem Solid Profil verknüpfen.

In meinem Solid Profil habe ich dazu folgendes Tripel hinterlegt:

:me <foaf:weblog> <https://datenwissen.de#it>.

Mit folgendem LDflex Ausdruck könnt ihr z.B. die letzten Blogartikel von datenwissen.de ermitteln:

[https://datenwissen.de#it][„sioc:container_of“].dct_title

Auf eurer Benutzerseite in der WordPress-Adminoberfläche könnt ihr eure Solid WebID hinterlegen:

Die Daten eures Blogs verweisen dann auch zurück auf euer Solid Profil.

Die neue Version von wp-linked-data unterstützt zusätzliche RDF Serialisierungen, darunter auch JSON-LD.

Solid – Fragen & Antworten

Auf der FrOSCon 14 habe ich einen Talk zu Solid gehalten. In der anschließenden Fragerunde gingen überwältigend viele Hände nach oben. Ich möchte diesen Blogartikel nutzen, um die zahlreichen Fragen noch einmal aufzugreifen, sie zu dokumentieren und gegebenenfalls etwas ausführlicher zu beantworten, als es in der knappen Zeit möglich war.

Ist es geplant, Daten von Facebook importieren zu können?

Ja, das ist definitiv geplant und Leute arbeiten daran. In der Praxis ist es tatsächlich nicht so einfach, da sich Facebook mit Händen und Füßen gegen solche Initiativen wehrt. Facebook hat eigentlich die Pflicht – spätestens seit der DSGVO – alle Daten herauszugeben.

Ruben Verborgh hat versucht, von diesem Recht Gebrauch zu machen und wirklich alle Daten von Facebook zu erhalten. Sein Ringen mit dem Konzern zieht sich nun schon seit Monaten hin.

Es ist aber nur eine Frage der Zeit, bis Facebook sich dem geltenden Recht beugen muss. Dann wird es für uns alle einfacher, unser Recht durchzusetzen. Tools, welche die Daten in ein Solid-kompatibles Format übersetzen, lassen sich dann recht leicht programmieren.

Wer kann Bobs Kommentar unter dem Beitrag von Alice sehen? Wer legt die Zugriffsrechte fest?

Wenn Bob einen Kommentar schreibt, wird dieser in Bobs eigenem Pod gespeichert. Bob selbst kann bestimmen, wer darauf zugreifen darf. Der Pod steuert die Zugriffsrechte über Web Access Control (WAC). Damit Alice den Kommentar lesen kann, wird Bob ihr zumindest Leserechte geben. Er kann darüber hinaus aber auch der Öffentlichkeit, oder einer bestimmten Gruppe Rechte erteilen. Ob der Kommentar tatsächlich unter Alices Beitrag erscheint, kann Alice entscheiden, indem sie zu Bobs Beitrag verlinkt, oder dies unterlässt.

Ich identifiziere mich über eine URI im Web. D.h. mein Hoster kann sich als mich ausgeben?

Die URI allein reicht dazu nicht. WebID-OIDC erfordert zur Authentisierung auch Benutzername und Passwort. Wie bei regulärem Webspace oder zentralen Diensten gilt aber auch bei Solid: Ich muss meinem Anbieter vertrauen. Ein Server- bzw. Dienste-Betreibender kann grundsätzlich die dort gespeicherten Daten einsehen und ggf. auch die Identität von Accounts annehmen. Solid unterscheidet technisch zwischen reinen Daten-Pods und dem Identity Provider, welcher die Authentifizierung vornimmt. Nur letzterer könnte mit böser Absicht deine Identität missbrauchen. Das wäre in etwa so, als wenn dein Mail-Provider eine Mail in deinem Namen versendet. Ein seriöser Anbieter ist also essentiell.

Wenn du auf Nummer sicher gehen willst, betreibst du den entsprechenden Pod selbst. In weniger sensiblen Bereichen kannst du dann dennoch auf gehostete Pods setzen. Jede Person kann ihr persönliches Maß an Schutzbedürftigkeit und Vertrauen selbst definieren.

Kann ich Daten von einem Pod exportieren und zu einem anderen umziehen? Was passiert mit den bestehenden Links?

Ja, das geht. Bestehende Links können durch eine Weiterleitung (HTTP Redirect) auf das neue Ziel verweisen.

Alternativ kannst du eine eigene Domain benutzen. Das geht durch entsprechende DNS-Konfiguration auch dann, wenn du den Pod nicht selbst betreibst. Wenn du den Pod-Provider wechselst, ziehen nur die Daten um, bleiben aber unter deiner Domain erreichbar.

Angenommen ich erlaube, dass in einem Post mein Bild angezeigt wird. Kann ich explizit einer Anwendung verbieten, dieses Bild anzuzeigen? Wird bei jedem Linkzugriff die Authentifizierung geprüft?

Ja, du kannst einzelne Anwendungen und auch einzelne Nutzer:innen sperren. Dein Pod prüft die Berechtigungen, bevor er dein Bild, oder irgendwelche Daten, an eine Anwendung ausliefert.

Wie sieht es mit mobilen Apps aus?

Solid ist nicht auf Web-Apps beschränkt. Auch native Apps sollen auf Pods zugreifen können. Solid Apps sind oft Webanwendungen oder Progressive Web Apps (PWA), weil dies für die meisten Anwendungsfälle ausreicht. Für native mobile Apps brauchen wir noch mehr Leute, die sich mit dem Thema beschäftigen. Die Library-Unterstützung ist hier noch nicht so gut.

Wie gut skaliert Solid? Gibt es Probleme mit mehreren Pods / Datenquellen?

Bis jetzt habe ich in der Praxis keine Performanceprobleme gesehen. Auch wenn ich angenommen hunderte Freunde habe und tausende Bilder in der Timeline: Eine App zeigt ja nie alles auf einmal an, sondern hat eine Seitennavigation oder Endless-Scrolling. Wenn gleichzeitig nur 10 oder 20 Bilder angezeigt werden, passieren auch nur 10-20 Requests. Das ist absolut kein Problem. Auch mehrere Datenquellen sind kein Thema: Das Web kennt nur URIs und ruft die Daten von diesen ab, egal wo sie liegen. Die Last verteilt sich dann sogar auf mehrere unabhängige Server.

Was wenn ich meinen Server abschalte?

Nehmen wir an, du hast einen Kommentar zu meinem Beitrag geschrieben. Mein Beitrag verlinkt zu diesem. Nun schaltest du deinen Server ab. Eine App, die meinen Beitrag lädt und dann dem Link zu deinem Kommentar folgt, wird einen HTTP Status 404 (Not Found) oder vielleicht 500 oder ähnliches bekommen.

Die Apps müssen mit so etwas umgehen können, den Kommentar vielleicht ausblenden, oder „gelöschter Kommentar“ oder ähnliches anzeigen. Solche Fehler werden definitiv auftreten. Eine gute Solid App ist resilient programmiert und geht vernünftig damit um.

Macht es Diskussionen nicht unübersichtlich, wenn Server ausfallen oder abgeschaltet werden?

Möglicherweise ja. Die Frage ist, wird es unübersichtlicher als heute auf zentralen Plattformen? Auch dort kommt es vor, dass der Anbieter Inhalte sperrt oder Accounts löscht. Oder Diskutierende löschen ihre Beiträge wieder, oder blockieren dich. Ich gehe davon aus, dass die Masse der Solid Pods auf zuverlässigen Systemen betrieben wird. Das garantiert aber nicht, dass alle Inhalte für alle Zeit erreichbar sein werden.

Bei Diaspora und Mastodon sind am Ende doch alle bei einer zentralen Platform gelandet. Wo ist der Unterschied?

Der Unterschied ist, dass wir alle frei wählen können, wo wir welche Daten speichern und über welche Apps wir diese nutzen. Wenn 90% am Ende bei einem einzigen Anbieter sein wollen, ist das aus meiner Sicht ok. Daraus allein ergibt sich noch kein Problem. Entscheidend ist, dass unsere Daten und Interaktionen zueinander kompatibel sind. Im Gegensatz zu z.B. Mastodon ist Solid auch nicht auf einen einzelnen Use-Case („twittern“) beschränkt, sondern bietet eine Plattform um alle denkbaren Apps zu entwickeln und miteinander zu vernetzen. Es trennt strikt zwischen Apps und Daten. Bei „dezentralen Daten-Silos“, wie Mastodon und Diaspora ist es bequem sich einfach bei einer prominenten Instanz anzumelden und diese zu nutzen, was ungewollt un einer Zentralisierung führt. Bei Solid hingegen, ist es bequem Daten zu dezentralisieren und Apps zu wechseln, weshalb ich denke, dass dies passieren wird, ohne dass Menschen darüber groß nachdenken.

Wo liegt der Unterschied zu Protokollen wie ActivityPub?

Beide haben gewisse Überschneidungen in den Zielen. ActivityPub und Solid können sich gut ergänzen. Ein Solid Server könnte z.B. das Activity Pub Protokoll implementieren. Das Activity Streams Vokabular lässt sich schon heute wunderbar nutzen, um Social-Web-Aktivitäten in einem Solid Pod zu speichern. Solid insgesamt bietet aber deutlich mehr Freiheiten und geht über den Zweck von ActivityPup hinaus. Im Solid Ökosystem lassen sich alle möglichen Daten miteinander verlinken.

Gibt es einen Standard um Referenzen zu eigenen (wissenschaftlichen) Publikationen abzulegen?

Da Solid und allgemein Linked Data im wissenschaftlichen Umfeld entstanden sind, sollte es gerade in diesem Bereich an nichts mangeln. Mit Dublin Core z. B. lassen sich die wichtigsten Metadaten über Veröffentlichungen erfassen.

Wo liegen denn die verlinkten Daten? Was wenn ich berühmt werde und zehntausende Requests bekomme?

Um viele Anfragen verarbeiten zu können, muss ein Pod-Server skalieren. Daten die ein so großes öffentliches Interesse wecken, wirst du definitiv nicht mehr auf einem Raspberry Pi bei dir zuhause hosten können, sondern du suchst dir einen guten Dienstleister.

Das heißt aber nicht, dass du alle deine Daten bei einem Provider hosten musst. Bei Solid kannst du die Daten auf beliebig viele Pods verteilen und miteinander verlinken. Während du öffentliche Daten mit vielen Requests bei einem passenden Dienst einstellst, wirst du private Daten vielleicht weiterhin zuhause lagern.

Ist es nicht für die Masse zu kompliziert und aufwändig sich mit Solid zu befassen?

Die Nutzung von Solid-Apps und Pods muss nicht komplizierter sein, als die Benutzung von Social-Media-Diensten heute. Wenn ich mich nicht mit der Technik befassen möchte, dann kann ich die Daten weiterhin „in der Cloud“ speichern. Diese „Cloud“ wird dann jedoch kein abgeschottetes Daten-Silo sein, sondern ein Netzwerk aus verlinkten Solid-Pods. Dadurch habe ich jederzeit Zugriff auf meine Daten und kann frei entscheiden, mit welchen Apps ich sie verwende.

Durch die Verlinkung der Daten sind auch hybride Lösungen kein Problem: So kann ich zum Beispiel öffentliche Bilder im Pod einer kostenlosen Fotoplattform hosten und private Urlaubsfotos beim Pod-Anbieter meines Vertrauens oder auf einem eigenen Server.

Zertifikate muss ich mir selber holen?

Wenn du einen Solid-Server selbst betreiben möchtest, dann muss dieser unter HTTPS laufen und du brauchst ein Zertifikat, ja. Das ist jedoch heute dank Let’s Encrypt keine große Sache mehr.

Wie kann ich darauf vertrauen, dass die Rechte korrekt verwaltet/gesetzt werden?

Auch für die Berechtigungen kann es Solid-Apps geben und du kannst frei wählen, welche du dafür verwenden möchtest. Nimm eine App deines Vertrauens, oder programmiere dir bei Bedarf eine eigene. Grundsätzlich kannst du die Rechte aber direkt im Solid-Server setzen. Da alle Daten (zumindest beim Node Solid Server) als Textdateien vorliegen, kannst du im Zweifel sogar die Rechte über einen einfachen Texteditor wie vim setzen, wenn du auf Nummer sicher gehen möchtest.

Kostet ein Pod wirklich 15-20 Euro?! Also muss ich ordentlich blechen oder meine Privatsphäre aufgeben?

Nein, das ist eine salopp dahergesagte Zahl! Wie die Preise sich entwickeln und welche Geschäftsmodelle und Initiativen entstehen ist völlig offen. Neben bezahlten Dienstleistern können auch öffentliche und soziale Lösungen entstehen: Zum Beispiel könnten Bibliotheken, Vereine und Universitäten als Pod-Hoster in Erscheinung treten. Was auch immer passiert ist jedoch ein Fortschritt im Vergleich zu heute, wo für uns alle nur die Option „Privatsphäre aufgeben“ besteht.

FrOSCon 2019: Die Rückeroberung des Social Web (Video)

Ich bin war dieses Jahr auf der FrOSCon mit einem Talk über Solid präsent:

Die Rückeroberung des Social Web

Eine Einführung in Solid

Video auf media.ccc.de öffnen

Folien des Vortrags: Web | PDF

Solid tritt an die Misstände im Social Web zu beheben. Dieser Vortrag erklärt die grundlegenden Konzepte und Technologien hinter Solid. Was macht Solid einzigartig? Welche Probleme löst es? Wie kann man mitwirken?

Letztes Jahr ging Web-Erfinder Tim Berners-Lee mit einem neuen, spannenden Projekt an eine größere Öffentlichkeit. Social Linked Data – kurz Solid – soll die Misstände des zentralisierten Social Webs beheben indem es das dezentrale WWW um soziale Funktionen erweitert und die Nutzer:innen in den Mittelpunkt stellt.

In diesem Vortrag erkläre ich die grundlegenden Konzepte und Technologien hinter Solid, erkläre warum dieser Ansatz so revolutionär ist und was Solid von verteilten Anwendungen wie Diaspora und Mastodon unterscheidet.

Ich werde zeigen, was mit Solid bereits heute möglich ist, was uns in Zukunft erwartet und wie jede:r diese Zukunft mitgestalten kann.

Vollständiges FrOSCon Programm

Solid Basics #002 – Deine Daten gehören dir

Ein wesentliches Merkmal von Solid ist die Trennung von Apps und Daten. Während deine Daten im traditionellen Social Web stets an eine bestimmte App bzw. einen bestimmten Dienst gekoppelt sind, liegen sie im Solid Ökosystem grundsätzlich in deinem eigenen Pod und du hast freie Wahl mit welcher App du sie verwalten und benutzen möchtest. Schauen wir uns an, was das praktisch bedeutet! Wenn du noch keinen Pod hast, besorge dir jetzt deine Identität im Web und wir legen los.

Als Beispiel schauen wir uns eine einfache Bookmarking App an: markbook.org. Dort kannst du beliebige Links als Lesezeichen hinterlegen, zum Beispiel um sie dir zum späteren Lesen vorzumerken.

Dank Solid benötigst du keinen Account bei marbook.org. Deine WebID genügt zum Einloggen: Nach einem Klick auf Login öffnet sich eine Providerauswahl. (Leider zur Zeit in einem Popup, was du ggf. im Browser erlauben musst)

Providerauswahl

Wenn du dich, wie in Teil 1 beschrieben, bei solid.community registriert hast, wählst du „Log in with Solid Community“. Dort loggst du dich dann mit deinem Username und Passwort ganz normal ein und wirst anschließend zurück zu markbook.org geleitet.

Login bei deinem Pod (z.B. solid.community)

Du wirst feststellen, dass markbook.org bereits deinen Namen und – falls du eins hinterlegt hast – dein Profilbild anzeigt. Diese Informationen lädt die App live aus deinem Solid Profil.

Markbook.org speichert selbst überhaupt keine Daten über dich. Nicht einmal die Lesezeichen, die wir gleich dort hinterlegen werden!

Um ein neues Lesezeichen anzulegen, klicke auf „Create Bookmark“ in der blauen Leiste oben. Es erscheint dann ein Dialog, in dem du einen Titel und die URL des Lesezeichen angeben kannst.

Ein Lesezeichen anlegen

Nach einem Klick auf „Post“, wird das Lesezeichen in deinem Solid Pod gespeichert und erscheint bei markbook.org in der Liste.

Das neu angelegte Lesezeichen, angezeigt auf markbook.org, gespeichert in deinem Solid Pod.

Der springende Punkt bei Solid ist, dass dieses Lesezeichen in deinem persönlichen Pod gespeichert wurde – markbook.org speichert keine Daten über dich oder deine Lesezeichen. Es ist eine reine Browser-App, die nur auf deinem Rechner oder Smartphone läuft.

Wenn du dich mit den Entwicklungswerkzeugen deines Browsers auskennst, kannst du dort verfolgen, dass markbook.org lediglich Daten an deinen Solid Pod sendet.

Schauen wir uns zum Abschluss die Daten einmal an! Mit Solid hast du volle Kontrolle über alle Daten die gespeichert werden und kannst diese jederzeit einsehen und löschen. „Deine Daten gehören dir“ ist hier kein Marketing-Bla-Bla, sondern technisch gewährleistet.

Deine Lesezeichen findest du unter einer URL der Form https://<username>.solid.community/public/bookmarks.ttl. Warum ich das weiß, bzw. wie man die genaue URL herausfindet erkläre ich in einem späteren Artikel. (Tipp für Neugierige: Alle Daten sind von deiner WebID ausgehend verlinkt. Folge dem Link namens „publicTypeIndex“). Für heute reicht es, wenn du in der genannten URL einfach deinen Benutzernamen an Stelle von <username> einsetzt.

Wenn du die URL im Browser öffnest, findest du dort die Daten des eben angelegten Lesezeichens.

Viel Spaß beim Experimentieren und Erkunden!

23.05, HamburgJS: Einführung in Solid

Nächsten Donnerstag, 23.05.2019, halte ich einen Talk über Solid beim HamburgJS Meetup.

The inventor of the Web, Tim Berners-Lee, introdruced a project called Solid, which is meant to re-decentralize the Social Web by extending the WWW as we know it with socially interlinked data. Solid shifts the way we have to think about building web applications fundamentally and gives interesting new opportunities. I will give an introduction of what exactly is Solid, how we can be part of it and how to build Solid applications.

(Talk submission)

Das Meetup findet bei Xing, Dammtorstraße 30, statt und beginnt um 19 Uhr.

Solid Basics #001 – Deine Identität im Web

Um am neuen Social Web teilhaben zu können, benötigst du zunächst (mindestens) eine globale Identität (WebID). Da Solid ein völlig offenes Ökosystem ist, kann im Prinzip jede Webaddresse (URI) mit entsprechender Konfiguration als WebID dienen. Ich möchte in dieser „Solid Basics“ Reihe die Dinge aber möglichst einfach halten. Ich zeige dir daher nun, wie du einen Account bei einem offenen Solid-Provider anlegst und direkt loslegen kannst.

Ein solcher Provider ist solid.community. Du kannst die Registrierungsseite benutzen um dort einen Account anzulegen und so eine WebID erhalten. Username und Password benötigst du um dich später einzuloggen. Der Username wird auch Teil deiner öffentlichen WebID. Die Email dient zur Account-Wiederherstellung, External WebID kannst du leerlassen.

Registrierungsformular bei solid.community

Nach der Registrierung landest du auf der Startseite deines neuen Solid Pods:

Deine WebID nach der Registrierung lautet https://<username>.solid.community/profile/card#me Neben einer WebID stellt dir solid.community, auch Speicherplatz für deine Daten zur Verfügung (Solid Pod). Wenn du die WebID im Browser abrufst siehst du dein Profil mit dem bei der Registrierung eingetragen Namen:

Du kannst über die Felder weitere Informationen eintragen und auch ein Profilbild hochladen. Die Oberfläche ist allerdings sehr sehr rudimentär und alles andere als schön zu bedienen. Die Stärke von Solid liegt jedoch darin, dass du nun beliebige (bessere) Solid-Apps im Web benutzen kannst um deine Daten zu verwalten und zu ergänzen. Mehr dazu folgt! Eine Identität mit der du dich einloggen kannst, hast du nun schon mal.

Solid – Social Linked Data

Die Idee eines Social Webs, losgelöst von zentralen Plattformen, rückt mit dem Solid-Projekt in greifbare Nähe.

Was ist Solid? – Solid steht für Social Linked Data. Das Projekt basiert auf Linked Data und vereint zahlreiche W3C-Standards aus diesem Umfeld, um das World Wide Web als Plattform für soziale Interaktionen zu nutzen.

Damit unterscheidet es sich wesentlich von verteilten sozialen Netzwerken wie Diaspora, Mastodon und Co., die im Grunde nur verteilte Daten-Silos sind. Mit Solid kann jede Website, jede Webanwendung, Teil des neuen Social Webs werden.

Eine Grundidee von Solid besteht in der Trennung von Anwendungen und Datenspeichern. Die Daten können an beliebigen Orten im Web gespeichert werden. Als Benutzer:in habe ich freie Wahl, wo ich meine Daten speichern will und wem ich Zugriff darauf gebe. Ebenso kann ich wählen, mit welchen Anwendungen ich die Daten verwalten möchte.

Dieses Prinzip möchte ich an einem konkreten Beispiel verdeutlichen:

Unter https://angelo.veltens.org/ läuft ein Solid-kompatibler Server. Aus dem dokumentenbasierten Web kennen wir Server wie nginx oder Apache httpd. Ein Solid-Server ist diesen sehr ähnlich, stellt aber darüber hinaus Funktionen für das Social Web bereit. Es ist auch denkbar, dass bestehende Webserver um Solid-Funktionen erweitert werden.

Der Server stellt mir eine Identität in Form einer WebID zur Verfügung und dient als „Personal Online Datastore“ (POD) zum Speichern von Daten. Unter meiner WebID https://angelo.veltens.org/profile/card#me sind einige Basis-Informationen zu meiner Person abrufbar. Alle weiteren Daten, die ich im POD, oder an anderen Orten im Web gespeichert habe, sind von dort aus verlinkt. Unter https://angelo.veltens.org/public/bookmarks liegen zum Beispiel einige meiner öffentlichen „Social Bookmarks“.

Der Solid-Server stellt auch ein rudimentäres Web-Interface zum Anzeigen und Bearbeiten der Daten bereit. Das spannende an Solid ist jedoch, dass ich beliebige Solid-Apps im Web verwenden kann. Zum Anlegen von Bookmarks zum Beispiel markbook.org. Ich habe markbook.org dazu schreibenden Zugriff auf https://angelo.veltens.org/public/bookmarks erteilt. Wenn ich mich mit meiner WebID einlogge, kann die App meine Lesezeichen verwalten.

Das gute an Solid ist, dass diese Lesezeichen eben nicht auf dem Server von markbook.org gespeichert werden, sondern in meinem POD. Wenn ich mit der Anwendung nicht mehr zufrieden bin, kann ich zu einer anderen Bookmark-App wechseln und die Daten einfach dort verwalten. Ebenso kann ich unterschiedliche Daten in unterschiedlichen PODs speichern und so im Web verteilen. Ich muss dabei auch nicht unbedingt einen eigenen Server betreiben, sondern kann auf Provider, wie z.B. inrupt.net zurück greifen. Dank Linked Data können alle Daten untereinander verknüpft und beliebigen Web-Apps zugänglich gemacht werden.

Dies geht soweit, dass jede Nutzer:in volle Kontrolle über die eigenen Daten hat. Während Alice einen Beitrag unter https://alice.example/articles/hello-world veröffentlicht, schreibt Bob einen Kommentar dazu unter https://bob.example/comments/my-two-cents und Trudy äußert ihre Zustimmung zu Bobs kommentar mit einem „Like“ unter https://trudy.example/likes/2019/02#123. Durch die Verlinkung der Daten kann alles aggregiert direkt beim Artikel angezeigt werden, liegt in Wahrheit jedoch in den PODs der jeweiligen User.

Dies ist soweit die Grundidee hinter Solid, ohne zu sehr auf die technischen Details einzugehen. Über einzelne davon werden sicher noch Blogposts folgen.

Wenn ich eurer Interesse für Solid geweckt habe, hier einige Follow-Up-Resourcen:

2019 – Das Linked Data Jahr?

In den vergangenen Jahren hatte ich wenig Zeit mich mit Linked Data zu befassen, obwohl mich das Thema nach wie vor interessiert. Inzwischen habe ich mich der Sache aber wieder angenommen und möchte dieses Blog reaktivieren.

Seit 2013 hat sich viel getan. Ein Auszug:

  1. Mit JSON-LD ist ein praxisorientiertes Serialisierungsformat entstanden, mit dem Entwickler:innen schnell vertraut werden.
  2. Hydra und Linked Data Platform standardisieren Linked-Data-APIs.
  3. Das Solid-Projekt von Tim-Berners-Lee verwirklicht die seit langem bestehende Idee der Dezentralisierung des Social Webs mit Linked Data.

Auch speziell in den letzten Wochen und Monaten passiert wieder mehr in diesen Bereichen. Die W3C JSON-LD Working Group hat die Arbeit an JSON-LD übernommen. Die Hydra Community Group hat sich neu formiert und arbeitet verstärkt an der Erweiterung der Spezifikation und konkreten Beispielen. Solid vereint eine wachsende Community von Leuten aus unterschiedlichen Bereichen. Im Chat und im Forum ist immer was los.

Ich selbst habe im codecentric-Blog Artikel über JSON-LD geschrieben, arbeite derzeit an Hydra-APIs und experimentiere mit Solid. Mehr erfahrt ihr demnächst hier im Blog.