Jelly-Patch: a Fast Format for Recording Changes in RDF Datasets

Anastasiya Danilenka; Kacper Grzymkowski; Piotr Sowinski

REVIEW 4 major objections 4 minor 14 references

Jelly-Patch: a Fast Format for Recording Changes in RDF Datasets

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims Jelly-Patch, a binary format for RDF changes, outperforms existing RDF Patch formats in benchmarks, achieving 3.5–8.9x better compression and up to 4.6x faster parsing.

desk verdict A real format with clean benchmarks, but the headline compression advantage needs a gzip-compressed baseline before it convinces. read the letter →

arxiv 2507.23499 v2 pith:HJFM6VVZ submitted 2025-07-31 cs.DB

Piotr Sowinski , Kacper Grzymkowski , Anastasiya Danilenka This is my paper · ORCID

classification cs.DB

keywords RDFchangedatacapturediffsPatchdatabasesserializationformatbinaryencodingIoTstreams

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Recording changes to RDF datasets is expensive when the change log is large or slow to read and write. Jelly-Patch is a binary serialization format for RDF Patch that records changes as a compressed stream, reusing the compression machinery of the Jelly-RDF format. In benchmarks on two real workloads, a change-data-capture log and a stream of IoT weather-sensor deltas, Jelly-Patch produced files 3.5–8.9x smaller than the text RDF Patch baseline, serialized up to 2.5x faster, and parsed up to 4.6x faster than the binary format used by the leading Java toolkit. The paper argues this makes change-data capture, replication, and streaming sensor pipelines less bottlenecked by serialization overhead.

What carries the argument

The mechanism that carries the result is a streaming term dictionary. Each new IRI, prefix, literal, or blank-node identifier encountered in the patch stream is stored in a fixed-size table, and every later occurrence is encoded as an integer index into that table; tables of 4000 names and 1024 prefixes are used, with the stream divided into frames of 512 operations. Because the dictionary persists across the whole stream, terms that recur in later transactions are nearly free, which is exactly what makes the format compress streaming changes and repeated IoT readings. Patch-specific messages add transaction boundaries and add/delete markers on top of the underlying statement stream, turning the format from a statement stream into a change stream -- the paper's phrase is a 'derivative of a stream.'

What would settle it

Take the weather-stream dataset and re-serialize it with the name-table size reduced to 100 and increased to 80,000 while keeping everything else fixed; if the 8.9x compression ratio falls to a small fraction of the published value, the paper's headline numbers are not stable under the very parameter that is asserted rather than justified. A complementary check is to run the same two datasets through gzip-compressed RDF Patch text and compare against raw Jelly-Patch, which would test whether the 3.5–8.9x range is specific to the uncompressed-text baseline.

Watch

Extended reading notes

Core claim

Jelly-Patch claims that recording RDF changes can be made cheap enough to stop being the bottleneck in change-data capture, replication, and streaming pipelines. It represents an RDF Patch stream not as text but as a binary stream of transactions in which previously seen terms are compressed through streaming lookup tables, so a later patch can reuse an IRI, prefix, or literal via a small integer reference. The evaluation covers a change-data-capture log and a rolling-difference IoT weather stream; Jelly-Patch files come out at 28.9% and 11.2% of the RDF Patch text size (that is, 3.5x and 8.9x smaller), and parsing is 2.4x and 4.6x faster than the binary RDF Patch format used as the fastest baseline. Serialization is 2.5x faster than that baseline on the weather stream and roughly equal on the change-data-capture log, which the paper attributes to long, hard-to-compress literals. The paper further reports that the weather stream stored as rolling differences in Jelly-Patch is 5.4x smaller than the original stream stored in Jelly-RDF.

Load-bearing premise

The claimed ratios depend on the fixed compression settings (dictionary sizes of 4000 and 1024 entries and a frame size of 512) being reasonable defaults for RDF workloads generally, rather than values chosen to flatter the two benchmark datasets; the paper does not provide a sensitivity analysis.

Editorial extensions

If this is right

Change logs for RDF databases can be stored in roughly one-third to one-ninth of the current text size on the tested workloads, cutting storage and network transfer costs for change-data capture and replication.
Consumers of change streams can parse Jelly-Patch up to 4.6x faster than the binary RDF Patch format used as the fastest baseline, so replicas and stream processors can absorb higher update rates without adding CPU.
Even on the dataset that is pessimistic for compression, Jelly-Patch is about as fast to write as the binary format while producing files over 4x smaller, shifting the tradeoff decisively toward fewer bytes.
For streaming IoT data, representing rolling differences in Jelly-Patch is 5.4x smaller than representing the original stream in Jelly-RDF, making diff-based storage attractive for sensor histories.
Because Jelly-Patch only replaces the serialization layer, systems that already compute diffs with RDF Patch can adopt it without changing how changes are calculated or applied.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper's own explanation of why compression differs on the two benchmarks -- long literals resist compression while repeated IRIs compress well -- implies that a workload with both many distinct IRIs and long literals would land near the 3.5x end, and one with highly repetitive short terms near the 8.9x end; this is an inference, not a measured result.
A natural follow-up that the paper explicitly leaves open is whether gzipping Jelly-Patch output closes the gap for long-literal workloads, since the format does not apply binary compression to literals.
Because compression state is carried over the entire stream, Jelly-Patch should scale to unbounded, continuously arriving changes without reprocessing history; the paper evaluates finite datasets, so this streaming-behavior claim is an inference from the design.
The two datasets are public under open licenses, so any group can run the same benchmarks with different dictionary sizes or different datasets; sensitivity analysis is the obvious next test of whether the 3.5–8.9x range transfers.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things to know up front. Jelly-Patch is a real artifact: a Protocol Buffers-based binary format for RDF Patch streams, building on Jelly-RDF's compression tables and adding patch-specific messages. The authors provide a spec, Apache-2.0 Java code integrated with Jena and partially RDF4J, and public benchmark data. Second, the headline compression claim—3.5–8.9x smaller—is measured against uncompressed text and binary baselines only. There is no gzip- or zstd-compressed RDF Patch baseline, so the practical advantage over a reasonable compressed alternative is not established. The stress-test note is correct on this.

What's genuinely new: the format itself, as far as I can tell. No prior artifact combines delta encoding of RDF changes with Jelly-style streaming compression. The benchmark methodology is also sound: JMH with warmups and blackholes, 95% confidence intervals, all formats share Jena APIs, and the code and data are public. The paper is honest about scope—it's a serialization format, not a new diff algorithm—and it flags its own limitations, including the long-literal issue.

Where it's soft: the missing compressed baseline is the main one. RDF N-Quads text compresses well, and a gzip-compressed RDF Patch stream could plausibly sit within a factor of two of Jelly-Patch on these workloads, which would shrink the headline ratio dramatically. The fixed Jelly-Patch settings (name table 4000, prefix table 1024, frame 512) are given with no sensitivity analysis, so we don't know whether they're tuned to these two datasets. And there are only two datasets, one from RiverBench, which the authors co-maintain, so the evaluation is narrow. None of this is fatal, but it makes the central claim conditional.

Who this is for: people working on RDF change capture, replication, and streaming. They'll get real value from the spec and implementation. The paper deserves a serious referee, but the referee should require a compressed-text baseline and ideally a small parameter sweep before acceptance.

Recommendation: send it to peer review, with the expectation of a revision. It's a legitimate engineering contribution with reproducible evidence, just not yet a fully fair benchmark.

Referee Report

4 major / 4 minor

Summary. This paper proposes Jelly-Patch, a binary, Protocol Buffers-based serialization format for RDF Patch change streams, reusing Jelly-RDF's streaming compression mechanisms. The authors provide an open specification, a Java implementation integrated with Jena and RDF4J, and a JMH-based benchmark comparing Jelly-Patch with Jena's RDF Patch text, RDF Patch binary (Thrift), and SPARQL Update on two datasets: a BSBM CDC trace and an IoT weather stream. The headline results are 3.5--8.9x smaller serialized sizes, up to 2.5x faster serialization, and up to 4.6x faster parsing compared with the RDF Patch baselines. The paper also reports a 5.4x size reduction of the weather change stream relative to a Jelly-RDF encoding of the original graph stream.

Significance. The contribution is potentially useful: change tracking in RDF is underserved, and the authors make the format specification, source code, and benchmark artifacts publicly available. The benchmark methodology is generally sound: JMH with warmups, blackholes, 95% confidence intervals, and shared Jena APIs reduce the risk of microbenchmark artifacts. If the reported gains hold under fair baselines, Jelly-Patch would be a practical improvement for RDF change serialization. However, the significance of the quantitative claims is bounded by the choice of baselines and by the narrow dataset coverage. The missing compressed-text baseline and absent parameter sensitivity analysis mean the headline ratios should be treated as upper bounds for specific uncompressed settings rather than established practical gains; the central claims are empirical and not circular, but they are not yet fully de-risked.

major comments (4)

[§3.3, Figure 1] The headline compression claim is measured against uncompressed baselines only. The text states that Jelly-Patch is the only format employing any compression, and Figure 1 compares it with RDF Patch text, RDF Patch binary, and SPARQL Update without applying gzip or zstd to any of them. Because external compression is standard for storage and transfer, the reported 3.5x and 8.9x ratios may not reflect the practical size advantage over RDF Patch text or binary once those formats are gzip-compressed, since text N-Quads is highly compressible. The authors should either add gzip/zstd-compressed baselines for the competing formats or explicitly scope the claim to "uncompressed serialized size" and adjust the abstract and conclusions accordingly. This is load-bearing because the compression ratio is the first quantitative claim of the paper.
[§3.2] The Jelly-Patch settings (name table size 4000, prefix table size 1024, frame size 512) are given but not justified, and no sensitivity analysis is reported. These parameters directly determine how much repetition is exploited; if they were tuned on the two benchmark datasets, the reported ratios would not transfer to other workloads. The authors should state whether these are the library defaults and provide a small sweep (e.g., over table sizes and frame sizes) showing that the compression and throughput results are not artifacts of a particular configuration.
[§3.3, Conclusion] The 5.4x comparison to Jelly-RDF is not a like-for-like compression comparison. The original RiverBench dataset is a sequence of full graphs, whereas Jelly-Patch stores a sequence of changes; the size reduction therefore confounds the effect of the delta representation with the format's compression. The sentence in Section 3.3 presenting this as a "size reduction of 5.4x" and the conclusion's wording "5.4x better compression than the already well-compressed Jelly-RDF" should be revised to make clear that this is a comparison of a delta stream against full snapshots, not a compression ratio within the same representation.
[§3.1--3.3] The evaluation covers only two datasets, one synthetic BSBM CDC trace produced by the authors and one IoT weather stream. Both are change-heavy, and the qualitative explanation of the results (long literals vs. repeating IRIs) suggests that dataset characteristics strongly affect the ratios. The paper's conclusion generalizes to "large-scale RDF systems," but the evidence base is too narrow to support that breadth. A third dataset with a different mix (e.g., ontology updates, many small named graphs, or many blank nodes) or a sensitivity analysis over dataset characteristics would materially strengthen the external validity.

minor comments (4)

[Figure 2] The bar labels in Figure 2 are dense and difficult to read in printed grayscale; a table of mean values and 95% confidence intervals would improve readability and reproducibility.
[§1] The RDF Patch example uses no spaces between terms (e.g., 'A_:sensor001<http://example.org/hasTemperature> "23" .'), which is not valid N-Quads-like syntax; adding spaces would improve clarity.
[§3.2] The inclusion of SPARQL Update as a baseline is not fully motivated, and since SPARQL Update has no parser, the deserialization comparison is asymmetric; a sentence explaining why this baseline is included would be helpful.
[§3.3] The authors note that gzip could improve Jelly-Patch's handling of long literals; if compressed baselines are added in response to the major comment, it would also be informative to report gzipped Jelly-Patch sizes.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: all headline numbers are direct benchmark measurements against external baselines, not derivations from fitted inputs or self-cited claims.

full rationale

The paper's central claims are empirical: Jelly-Patch's compression ratios and throughput figures are measured in Section 3.3 against concrete baselines (RDF Patch text, RDF Patch binary based on Jena Thrift, and SPARQL Update) on two published datasets. There is no equation-level derivation in which an output is equivalent to an input by construction, and no fitted parameter is renamed as a prediction. Although Jelly-Patch reuses compression mechanisms from Jelly-RDF (cited as [7,9]) and the assist-iot-weather dataset comes from RiverBench (cited as [11], with overlapping authorship), the paper does not infer Jelly-Patch's performance from those citations; it reports directly measured byte sizes and JMH throughput, with code and datasets publicly available. The absence of a gzip-compressed RDF Patch baseline is a legitimate benchmark-completeness concern about the significance of the compression advantage, but it does not make any reported number reduce to the paper's own inputs. No self-citation is load-bearing in the sense of supplying the evidence for the measured results. Therefore no circular step can be exhibited, and the appropriate score is 0.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central claim is an empirical benchmark result, so the ledger records the benchmark-configuration choices and domain assumptions on which the measurements depend. No new physical or formal entities are introduced.

free parameters (3)

name table size = 4000
Sets lookup-table capacity for IRI and name compression in benchmarks; no sensitivity analysis is shown.
prefix table size = 1024
Sets the number of prefix entries in streaming compression; selected for benchmarks without sensitivity analysis.
frame size = 512
Sets the protobuf frame chunk size; may affect throughput and is fixed in the benchmark setup.

assumptions (3)

domain assumption RDF Patch blank node identifiers are treated as global and unique across documents, as adopted from RDF Patch.
Section 1 states Jelly-Patch inherits this practical deviation from the RDF specification. If a system requires spec-compliant blank node semantics, Jelly-Patch patches may conflate distinct blank nodes.
domain assumption The two benchmark datasets are representative of change data capture and IoT streaming workloads.
Section 3.1 bases the evaluation on bsbm-cdc and assist-iot-weather. The paper does not test other workloads, so the generalization of the speedup ratios rests on this assumption.
domain assumption Jelly-Patch settings (name table 4000, prefix table 1024, frame 512) are reasonable defaults rather than values tuned to the test datasets.
Section 3.2 lists the settings without sensitivity analysis. If they are tuned, the reported ratios may not generalize to other datasets.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Jelly-Patch: a Fast Format for Recording Changes in RDF Datasets." pith.science (2026). https://pith.science/paper/HJFM6VVZ

@misc{pith2026250723499,
  author       = {Pith},
  title        = {Pith review of: Jelly-Patch: a Fast Format for Recording Changes in RDF Datasets},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HJFM6VVZ}},
  note         = {Machine review of arXiv:2507.23499}
}

read the original abstract

Recording data changes in RDF systems is a crucial capability, needed to support auditing, incremental backups, database replication, and event-driven workflows. In large-scale and low-latency RDF applications, the high volume and frequency of updates can cause performance bottlenecks in the serialization and transmission of changes. To alleviate this, we propose Jelly-Patch -- a high-performance, compressed binary serialization format for changes in RDF datasets. To evaluate its performance, we benchmark Jelly-Patch against existing RDF Patch formats, using two datasets representing different use cases (change data capture and IoT streams). Jelly-Patch is shown to achieve 3.5--8.9x better compression, and up to 2.5x and 4.6x higher throughput in serialization and parsing, respectively. These significant advancements in throughput and compression are expected to improve the performance of large-scale and low-latency RDF systems.

Figures

Figures reproduced from arXiv: 2507.23499 by the authors.

**Figure 1.** Serialized dataset size, expressed as percentage of baseline (dataset’s size in RDF Patch text). any information. This is a size reduction of 5.4x, made possible by applying differential compression (stream derivative) on top of an already well-compressed file. This highlights the great potential of diff-based formats in streaming use cases, which we will investigate further in future research [PITH_FULL_IMAGE:figu… view at source ↗

**Figure 2.** presents the serialization and deserialization throughput results. SPARQL Update does not have a RDF Patch-compatible parser, so only its serialization speed was tested, with it being by far the slowest format. In bsbm-cdc, Jelly-Patch is only ∼5% faster at serializing than Jena’s binary format. This is due to the dataset being a pessimistic case for Jelly-Patch, with a lot of incompressible data (long strings) and … view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 12 canonical work pages

[1]

Kleppmann, Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems, O’Reilly Media, Inc., 2017, p

M. Kleppmann, Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems, O’Reilly Media, Inc., 2017, p. 454. Chapter 11: Change Data Capture

work page 2017
[2]

Mynarz, A

J. Mynarz, A. Sotona, Change data capture of large-scale RDF data., in: SEMANTiCS (Posters & Demos), 2019

work page 2019
[3]

Berners-Lee, D

T. Berners-Lee, D. Connolly, Delta: an ontology for the distribution of differences between RDF graphs, World Wide Web, http://www.w3.org/DesignIssues/Diff 4 (2004) 4–3

work page 2004
[4]

Sambra, A

A. Sambra, A. Bertails, P.-A. Champin, Linked Data Patch Format, 2015. Https://www.w3.org/TR/2015/NOTE-ldpatch-20150728/

work page 2015
[5]

Prud’hommeaux, SparqlPatch, 2014

E. Prud’hommeaux, SparqlPatch, 2014. https://www.w3.org/2001/sw/wiki/SparqlPatch, accessed on 28 July 2025

work page 2014
[6]

Seaborne, RDF Delta, 2025

A. Seaborne, RDF Delta, 2025. https://afs.github.io/rdf-delta/, accessed on 28 July 2025

work page 2025
[7]

Sowiński, K

P. Sowiński, K. Bogacka, A. Danilenka, N. Kozlov, Jelly: a fast and convenient RDF serialization format, arXiv preprint arXiv:2506.11298, SEMANTiCS 2025 Developers Workshop, September 03, 2025, Vienna, Austria (2025)

arXiv 2025
[8]

https://protobuf.dev/, accessed on 31 July 2025

Google LLC, Protocol Buffers Contributors, Protocol Buffers, 2025. https://protobuf.dev/, accessed on 31 July 2025

work page 2025

Show all 14 references

[9]

Sowiński, K

P. Sowiński, K. Wasielewska-Michniewska, M. Ganzha, M. Paprzycki, et al., Efficient RDF streaming for the edge-cloud continuum, in: 2022 IEEE 8th World Forum on Internet of Things (WF-IoT), IEEE, 2022, pp. 1–8. doi:10.1109/WF-IoT54382.2022.10152225

2022
[10]

Bizer, A

C. Bizer, A. Schultz, The Berlin SPARQL benchmark, International Journal on Semantic Web and Information Systems 5 (2009) 1–24. URL: http://dx.doi.org/10.4018/jswis.2009040101. doi:10. 4018/jswis.2009040101

2009 doi
[11]

Sowiński, M

P. Sowiński, M. Ganzha, Realizing a collaborative RDF benchmark suite in practice, arXiv preprint arXiv:2410.12965, 24th International Conference on Knowledge Engineering and Knowledge Management (EKAW 2024), 26–28 November 2024, Amsterdam, Netherlands (2024)

2024 arXiv
[12]

Sowiński, K

P. Sowiński, K. Grzymkowski, Datasets and results for Jelly-Patch benchmarks, 2025. URL: https: //doi.org/10.5281/zenodo.16498682. doi:10.5281/zenodo.16498682

2025 doi
[13]

URL: https://jena.apache

Apache Software Foundation, RDF binary using Apache Thrift, 2025. URL: https://jena.apache. org/documentation/io/rdf-binary.html, accessed on 12 June 2025

2025
[14]

https://github.com/openjdk/ jmh, accessed on 31 July 2025

OpenJDK Contributors, Java Microbenchmark Harness (JMH), 2025. https://github.com/openjdk/ jmh, accessed on 31 July 2025

2025

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

Kleppmann, Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems, O’Reilly Media, Inc., 2017, p

M. Kleppmann, Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems, O’Reilly Media, Inc., 2017, p. 454. Chapter 11: Change Data Capture

work page 2017

[2] [2]

Mynarz, A

J. Mynarz, A. Sotona, Change data capture of large-scale RDF data., in: SEMANTiCS (Posters & Demos), 2019

work page 2019

[3] [3]

Berners-Lee, D

T. Berners-Lee, D. Connolly, Delta: an ontology for the distribution of differences between RDF graphs, World Wide Web, http://www.w3.org/DesignIssues/Diff 4 (2004) 4–3

work page 2004

[4] [4]

Sambra, A

A. Sambra, A. Bertails, P.-A. Champin, Linked Data Patch Format, 2015. Https://www.w3.org/TR/2015/NOTE-ldpatch-20150728/

work page 2015

[5] [5]

Prud’hommeaux, SparqlPatch, 2014

E. Prud’hommeaux, SparqlPatch, 2014. https://www.w3.org/2001/sw/wiki/SparqlPatch, accessed on 28 July 2025

work page 2014

[6] [6]

Seaborne, RDF Delta, 2025

A. Seaborne, RDF Delta, 2025. https://afs.github.io/rdf-delta/, accessed on 28 July 2025

work page 2025

[7] [7]

Sowiński, K

P. Sowiński, K. Bogacka, A. Danilenka, N. Kozlov, Jelly: a fast and convenient RDF serialization format, arXiv preprint arXiv:2506.11298, SEMANTiCS 2025 Developers Workshop, September 03, 2025, Vienna, Austria (2025)

arXiv 2025

[8] [8]

https://protobuf.dev/, accessed on 31 July 2025

Google LLC, Protocol Buffers Contributors, Protocol Buffers, 2025. https://protobuf.dev/, accessed on 31 July 2025

work page 2025