Another relevant project that may be of interest to you is Jelly RDF
-https://jelly-rdf.github.io/dev/
I believe recent versions have also incorporated support for a custom
high-performance encoding of RDF patches. Again, that supports various
different messaging systems for streaming patches (and other RDF data) around.
Maintainer of Jelly here – yes, that's correct. :) Jelly-Patch is an
implementation of RDF Patch based on a throughput-optimized binary
serialization format. We use it internally for our projects.
Spec: https://w3id.org/jelly/dev/specification/patch
We have implementations for Jena and RDF4J currently:
https://w3id.org/jelly/jelly-jvm/dev/#jelly-patch-experimental
It can work with Kafka or any other intermediary... for example, S3 or gRPC.
Piotr Sowiński
On 1/12/26 11:05, Rob @ DNR wrote:
Hi Lawson
I would say that there’s a niche of users who are using it, myself included,
and that it fulfils specific use cases that only a subset of users are likely
to have.
The core RDF patch functionality, readers/writers and APIs has already been
mainlined into Jena for some time.
rdf-delta being archived likely more reflects the fact that it’s a standalone
project that Andy did some time ago and his attention has been focused on more
pressing matters - like RDF 1.2 and SPARQL 1.2 support which impact far more
users. Also, since rdf-delta was created other technologies have come along to
solve the same problem as it using the same building blocks (the RDF patch
format) but with more modern and reliable systems for exchanging patches.
For example -https://github.com/telicent-oss/jena-fuseki-kafka - (disclaimer:
this is something I maintain as part of my $dayjob) but was also something Andy
worked on previously when he also worked at the same employer.
I don’t expect that aspect of functionality to ever come to mainline Jena
because Kafka is one of many possible messaging systems. There’s also lots of
ancillary details around solutions like this that are very workload dependent,
e.g. our approach has evolved over time a very opinionated batching approach
driven by our production workloads. There are lots of other messaging systems,
and surrounding integration concerns, such that a purely volunteer driven
project Jena can’t/shouldn’t attempt to maintain support for every possible
messaging system, configuration combination etc.
Jena maintaining the core RDF patch format and API should be sufficient for
most people. Jena Fuseki has specifically evolved over the last couple of
years to make it easier for projects like ours and others to integrate
additional features into Fuseki with minimal friction.
Another relevant project that may be of interest to you is Jelly RDF
-https://jelly-rdf.github.io/dev/
I believe recent versions have also incorporated support for a custom
high-performance encoding of RDF patches. Again, that supports various
different messaging systems for streaming patches (and other RDF data) around.
Hope this helps,
Rob
From:[email protected] <[email protected]>
Date: Sunday, 11 January 2026 at 23:25
To:[email protected] <[email protected]>
Subject: Future of RDF Patch format
Hi Jena community,
With RDF Delta<https://github.com/afs/rdf-delta> soon to be archived, my team
and I are trying to understand what the future holds for the RDF patch format and the
functionality it enables.
i.e.
- are lots of people using RDF patch logs,
- is no one using it,
- will RDF patch functionality be mainlined into Jena,
- is there some equivalant format/feature coming in Jena v6 that performs the
same role,
- is there just no interest, and the functionality is not being developed?
Thanks in advance to anyone who can help to answer.
regards,
Lawson Lewis
Infrastructure and Development
KurrawongAI
[emailAddress][email protected]
[website]https://kurrawong.ai
