About rdf-pub

rdf-pub is an activity-pub server implementation, that is not limited to the activity-stream vocabulary, but supports RDF per se.

Version 0.0.7.1-fixTheClient-SNAPSHOT

Created, maintained and © by Fred Hauschel and contributors. See https://rdfpub.org.


1. Introduction and Goals

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 ;-)

1.1. Requirements Overview

  • Bereitstellung eines Activity-Pub Servers, der Client to Server und Server to Server unterstützt.

  • Der Server soll alle RDF basierten Objekte verarbeiten können.

  • Ein Webentwickler soll einen rdf-pub Srever vie C2S API nutzen können um eine Föderierte Anwendmung bereitstellen zu können, ohne einen Activity-Pub Server implementieren zu müssen.

2. Architecture Constraints

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

3. System Scope and Context

TODO

3.1. Business Context

<Diagram or Table>

<optionally: Explanation of external domain interfaces>

3.2. Technical Context

<Diagram or Table>

<optionally: Explanation of technical interfaces>

<Mapping Input/Output to Channels>

4. Solution Strategy

The decisions result from the experience of the main developer

  • The programming language used is Java 21

  • The Application and Dependency Framework is Spring

  • The rdf abstraction layer and domain layer is done with commons-rdf

  • rdf4j is used as the RDF framework

  • gitflow-maven-plugin is used for development process

  • Build Process / Automation is done with maven

5. Building Block View

level0
Figure 1. Level 0

5.1. Whitebox rdf-pub

level1
Figure 2. Level 1
Component Description

rdf-pub-adapter-driven

An output port (driven port) is another type of interface that is used by the application core to reach things outside of itself (like getting some data from a database).

rdf-pub-adapter-driving

An input port (driving port) lets the application core to expose the functionality to the outside of the world.

Here are the entry points into the application for clients

rdf-pub-app

Cell in column 2, row 3

rdf-pub-domain

This is the Domain layer (Core), which is indepenend of the tech stack.

rdf-pub-store

Abstraction of an rdf store that hides the concrete store implementation like rdf4j from the domain layer.

rdf-pub-store-rdf4j

Implementation of the rdf-pub-store interfaces using rdf4j

rdf-pub-client

A Library, that can be used by java client apps or tests.

rdf-pub-spring-boot

This is the component that puts everything together and provides an executable file

<Overview Diagram>

Motivation

<text explanation>

Contained Building Blocks

<Description of contained building block (black boxes)>

Important Interfaces

<Description of important interfaces>

5.1.1. <Name black box 1>

<Purpose/Responsibility>

<Interface(s)>

<(Optional) Quality/Performance Characteristics>

<(Optional) Directory/File Location>

<(Optional) Fulfilled Requirements>

<(optional) Open Issues/Problems/Risks>

5.1.2. <Name black box 2>

<black box template>

5.1.3. <Name black box n>

<black box template>

5.1.4. <Name interface 1>

…​

5.1.5. <Name interface m>

5.2. Level 2

5.2.1. White Box <building block 1>

<white box template>

5.2.2. White Box <building block 2>

<white box template>

…​

5.2.3. White Box <building block m>

<white box template>

5.3. Level 3

5.3.1. White Box <_building block x.1_>

<white box template>

5.3.2. White Box <_building block x.2_>

<white box template>

5.3.3. White Box <_building block y.1_>

<white box template>

6. Runtime View

6.1. <Runtime Scenario 1>

  • <insert runtime diagram or textual description of the scenario>

  • <insert description of the notable aspects of the interactions between the building block instances depicted in this diagram.>

6.2. <Runtime Scenario 2>

6.3. …​

6.4. <Runtime Scenario n>

7. Deployment View

7.1. Infrastructure Level 1

<Overview Diagram>

Motivation

<explanation in text form>

Quality and/or Performance Features

<explanation in text form>

Mapping of Building Blocks to Infrastructure

<description of the mapping>

7.2. Infrastructure Level 2

7.2.1. <Infrastructure Element 1>

<diagram + explanation>

7.2.2. <Infrastructure Element 2>

<diagram + explanation>

…​

7.2.3. <Infrastructure Element n>

<diagram + explanation>

8. Cross-cutting Concepts

8.1. <Concept 1>

<explanation>

8.2. <Concept 2>

<explanation>

…​

8.3. <Concept n>

<explanation>

9. Architecture Decisions

10. Quality Requirements

10.1. Quality Tree

10.2. Quality Scenarios

11. Risks and Technical Debts

12. Glossary

Term Definition

<Term-1>

<definition-1>

<Term-2>

<definition-2>