On 12/01/2026 10: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.
This also include a binary form using Apache Thrift.
Protobuf could be done c.f. the binary forms data formats.
Aside: Thrift is slightly faster than protobuf - this seems to be down
to protobuf needing to allocate a java object to slice the stream which
isn't needed in Thift. At speeds faster than 1 microsecond/row, every
allocation makes a difference.
The important speed factor is whether it can feed the changes to the
database - the bottleneck is the update of the database step which
slower than producing the patches even for the text form.
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.
Yes, Delta needs a v2 with a focus on being easier to deploy and
managed. RAFT (Ratis), gRPC, ...
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
> - will RDF patch functionality be mainlined into Jena,
It's there, as Rob notes.
Andy
