rdf-pub architecture

Auf der Bits und Bäume 2018 habe ich mich zum ersten mal mit Vertretern von fairmove.it getroffen. Für mich waren sowohl Tätigkeiten und Beteiligte ein schwarzes Loch, ich hatte nach mehreren Gesprächen wenig konkretes darüber erfahren.

Dies war jedoch der Grund, warum ich mich im Jahr 2019 mit Vertretern von

getroffen habe. Damals hatten wir unter anderem folgendes Problem besprochen:

Wenn mehrere Initiativen online Karten anbieten, gibt es die herausforderung der Synchronisation der POI’s. Ein Besucher möchte unabhängig von der Plattform/Instanz die er besucht möglichst viele POI’s sehen und nicht mehrere Plattformen/Instanzen besuchen müssen um sich zu informieren. Damals wurde Activity-Pub als Lösungsansatz für dieses Problem in die Diskussion eingebracht, wobei keiner der Beteiligten wusste, was hinter Activity-Pub steckt.

Roland Alton und ich haben einen Förderantrag bei nlnet für das Projekt FairSync gestellt. Wir haben dann Ende 2019 den Zuschlag bekommen. Leider gab es keinen aus dem fairmove.it Team, der sich der Aufgabe angenommen hat. Darauf hin habe ich begonnen mich in Activity-Pub einzuarbeiten.

Activity-Pub war für mich eine ganze Weile ein Buch mit sieben Siegeln, ich hatte nicht im Ansatz verstanden, wie dieses Protokoll oder vielmehr das Domainmodel aussehen soll. Auch JSON-LD hat mich mehr als verwirrt. Erst als ich begriffen habe, dass ich mich zuerst in RDF einarbeiten muss, wurde nach und nach alles etwas klarer.

Schnell wurde mir klar, dass JSON-LD nur eine von vielen Möglichkeiten ist RDF zu repräsentieren (Und meiner Meinung nach eher eine der schlechten).

Erst danach konnte ich mit der Activity-Pub Spezifikation ein bischen etwas anfangen. Schnell hatte ich festgestellt, dass es für die Lösung meiner Probleme kein bestehendes Projekt gibt, denn so gut wie keiner befasst sich mit den Client-to-Server(C2S) Teil der Activity-Pub Spezifikation.

Aus den Erfahrungen, entstand das Projekt linkedopenactors. Und eine erste Code Basis, die eine Art Activity-Pub Server war, die eine C2S API hatte.

Im Laufe der Jahre habe ich viele Erfahrungen gesammelt und viele Fehlschläge hinter mich gebracht. Erst heute 2024 entsteht diese Doku, nach einem weiteren Grundlegenden Refactoring meiner rdf-pub Implementierung.

Ich hoffe aus der vorgehenden Beschreibung wird in etwa klar, was die Anforderungen und die treibenden Kräfte hinter rdf-pub steckten.

Mein Ziel ist es einen generischen Activity-Pub Server bereitzustellen, der sowohl C2S als auch S2S unterstützt. Und der nicht an bestimmte Objekttypen wie Article, Message, Image, Blog, …​ gebunden ist, sondern alle RDF Objekte verarbeten kann. Meine Hoffnung ist, dass es eines Tages möglich ist auf Basis von rdf-pub Activity-Pub Anwendungen bereit zu stellen, ohne sich zu tief mit dem Activity-Pub Protokoll beschäftigen zu müssen, oder gar einen eigenen Activity-Pub Server implementieren zu müssen.

Somit ist eine sehr relevante Interessengruppen "App Entwickler" die via C2S API einen rdf-pub Server benutzen.

Ich wünsche Euch viel Spaß mit dieser technischen Lektüre ;-)

The fullfillment of the Activity-Pub Specification and if necessarry some FEPs

TODO

The decisions result from the experience of the main developer