August 2023 - Big Refactoring "versionInRepo"

Angefangen hat alles mit der Idee die Version und ein Objekt Identifier schon im core-repository zu behandeln. Grund für diese Idee waren starke Performanceprobleme beim Import von rund 30.000 Organisationen aus http://kartevonmorgen.org

Die Vision eine einfache activity-pub Implementierung zu haben, die es erlaubt durch eine HTTP / SPARQL Schnittstelle komplexe Adapter und Anwendungen umzusetzen, wurde zerstört.

Beim Importieren der rund 30.000 Organisationen (von einer Organisation gibt es im Durchschnitt mind. 10 Versionen) wurde klar, dass eine Abfrage mit SPARQL zu aufwändig wird und viel Instabilität in das System bringt.

Nach langer Überlegung habe ich mich entscheiden, das Datenmodel in rdf-pub „intelligenter“ zu machen. Die ID eine Aktivität, bzw. eines Objektes hinter einer Aktivität macht Probleme, sobald wir von verschiedenen Versionen eines Objektes reden. Denn jedes Objekt hat in activity-pub eine eindeutige id. Es gibt jedoch keine eindeutige id Objekt-übergreifend. Führt man also ein Property 'Version' in das Objekt ein, dann hilft das alleine nicht, da man die Zugehörigkeit zu vorhergehenden bzw. nachfolgenden Versionen nicht findet.

Ich habe mit dem Gedanken gespielt, verkettete Listen einzuführen. Oder Container, die alle Versionen eines Objektes beinhalten. Die Container realisiert als 'activity-pub' OrderedList' wäre dann wohl kompatibel zu activity-pub. In der Umsetzung bedeuten beide Möglichkeiten allerdings eine hohe Komplexität.

Daher habe ich mich zusätzlich für eine Eigenschaft 'identitifier' entschieden.

Die activity-pub Community ‚streitet‘ sich noch darum, was Kompatibilität bedeutet. Aus meiner Sicht ist das jedoch keine Frage, da activity-pub auf JSON-LD aufbaut und hinter JSON-LD RDF steckt, ist alles was dies erlaubt auch kompatibel. Die Realität sieht noch anders aus und ich habe das Gefühl, dass viele activity-pub Implementierungen eher JSON statt JSON-LD unterstützen. Das wird noch eine spannende Zeit ;-) Also rdf-pub basiert auf 2 Attributen, die in activity-pub nicht definiert sind:

Da https://linkedopenactors.org/ auf https://schema.org basiert und rdf-pub durch https://linkedopenactors.org/ entsteht, ist das mehr als konsequent!

Allerdings wird, wie gesagt, das Thema Interoperabilität noch ein sehr spannendes. Wobei es vorerst sowieso keine activity-pub Implementierungen geben wird, die das https://linkedopenactors.org/ Datenmodel unterstützen. Ich überlege kompatibel zu bleiben, indem ich Objekte ohne Identitifier und Version zulasse und dann immer eine UUID für den Iidentifier vergebe und die Version auf 1 setze. Das wird sich zeigen. Um mehr auf Kompatibilität zu achten, werde ich mit rdf-pub das Ziel https://linkedopenactors.org/ hinten anstellen und mich vorerst mehr auf einfache Nachrichten like mastodon zu konzentrieren. Um dann die Komplexität der Objekte langsam zu erhöhen und zu schauen, was andere Implementierungen daraus machen.

Zuletzt wurde aus dieser ursprünglichen Vision 'die Version und ein Objekt Identifier schon im core-repository zu behandeln' ein großes Projekt, welches mich Monate beschäftigte.

Wesentliches, was zusätzlich im Laufe des Refactorings geändert wurde.

Heute Sonntag, 20.8.2023 ist es nun aber soweit, der feature branch 'feature/versioninInRepo' wurde in den 'develop' branch zurück gemerged. Es gibt immer noch viele Baustellen im Code, aber es scheint eine stabile Version zu sein und alle Tests inkl. der Integration tests laufen so weit wieder. Die linkedopenactors Anwendung habe ich noch nicht getestet. Das ist noch ein Thema für die Zukunft. Ein weiteres, offenes Issue ist, aus der linkedopenactors Anwendung eine rdf-pub Anwendung zu machen, welche als Test, Debug und Admin Anwendung für rdf-pub dienen soll.

Außerdem hoffe ich bald zusammen mit befreundeten Admins auf ein kubernetes cluster umzusteigen und dort eine dev (und ggf. test) Version bereitzustellen.

It all started with the idea to handle the version and an object identifier already in the core-repository. The reason for this idea were strong performance problems when importing about 30.000 organizations from http://kartevonmorgen.org.

The vision to have a simple activity-pub implementation, which allows to implement complex adapters and applications through a HTTP / SPARQL interface, was destroyed.

When importing about 30,000 organizations (on average there are at least 10 versions of an organization) it became clear that a query with SPARQL would be too time-consuming and would bring a lot of instability into the system.

After long consideration I decided to make the data model in rdf-pub "smarter". The ID of an activity, or of an object behind an activity, causes problems as soon as we talk about different versions of an object. Because every object has a unique id in activity-pub. But there is no unique id across objects. So if you introduce a property 'version' into the object, this alone does not help, because you cannot find the predecessors or successors.

I have been playing with the idea of introducing chained lists. Or containers that contain all versions of an object. The container realized as 'activity-pub' OrderedList' would then probably be compatible to activity-pub. However, in the implementation both possibilities mean a high complexity.

Therefore I decided to add an 'identitifier' property.

The activity-pub community is still 'arguing' about what compatibility means. From my point of view this is not a question, because activity-pub is built on top of JSON-LD and behind JSON-LD is RDF, everything that allows this is also compatible. The reality is still different and I have the feeling that many activity-pub implementations support JSON rather than JSON-LD. This will be an exciting time ;-) So rdf-pub is based on 2 attributes which are not defined in activity-pub:

Since https://linkedopenactors.org/ is based on https://schema.org and rdf-pub is created by https://linkedopenactors.org/, this is more than consistent!

However, as I said, the topic of interoperability will still be a very exciting one. But for the time being there will be no activity-pub implementations that support the https://linkedopenactors.org/ data model. I’m thinking about staying compatible by allowing objects without identifier and version and then always assigning a UUID for the identifier and setting the version to 1. This will be seen. I’m going to prioritize the https://linkedopenactors.org/ goal down and focus more on simple messages like Mastodon uses for now. Then I will slowly increase the complexity of the objects and see what other implementations make of it.

Finally this original vision 'to handle the version and an object identifier already in the core-repository' became a big project, which kept me busy for months. This is partly because I still have a life without a PC and a job that finances my life, https://linkedopenactors.org/ and https://rdf-pub.org/.

What was additionally changed during the refactoring.

Today Sunday, 20.8.2023, the feature branch 'feature/versioninInRepo' has been merged back into the 'develop' branch. There are still many issues in the code, but it seems to be a stable version and all tests including the integration tests are running again. I have not tested the linkedopenactors application yet. That is still an issue for the future. Another open issue is to turn the linkedopenactors application into an rdf-pub application, which will serve as a test, debug and admin application for rdf-pub.

Also, I hope to move to a kubernetes cluster soon with some admin friends and deploy a dev (and possibly test) version there.