{"id":"1a5912cd-2a76-4e19-b899-4d6c20dc5d9b","arxiv_id":"2507.23499","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"low","formal_verification":"none","parameter_count":3,"one_line_summary":"Jelly-Patch encodes RDF dataset changes as compressed binary deltas, shrinking patches 3.5 to 8.9 times and parsing up to 4.6 times faster than current RDF Patch formats.","lead":"Jelly-Patch is a new compressed binary format for recording changes in RDF datasets, built on Protocol Buffers and the earlier Jelly-RDF serialization. In benchmarks on two datasets it produced RDF Patch files 3.5 to 8.9 times smaller and parsed them up to 4.6 times faster than existing formats.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Compression ratios are measured against uncompressed baselines; without a gzip/zstd-compressed RDF Patch baseline, the headline 3.5–8.9x compression advantage is not validated.","rationale":"I read the paper as claiming a materially smaller and faster change-serialization format. The most load-bearing risk to that claim is not the specific table sizes but the absence of any compressed baseline: as Section 3.3 states, Jelly-Patch is the only format employing compression, so the 3.5–8.9x compression ratios compare compressed vs uncompressed representations. Since RDF text is routinely compressed in practice (gzip, zstd), the headline ratios may overstate Jelly-Patch's practical advantage. The reader's weakest assumption (parameter tuning) is also a valid concern; the paper provides no sensitivity analysis for the three settings. However, even if the settings are defaults, the compression claim remains unvalidated against compressed baselines. I therefore partially agree with the reader: the two issues are related benchmarking gaps, but I consider the compressed-baseline omission more fundamental. A concrete gzip/zstd comparison would settle whether the 'better compression' claim extends to realistic storage/transfer use. The throughput claims are less affected because they compare parsing/serialization of the raw formats; but end-to-end gzip+text would be the fairer operational comparison. Overall, a conditional verdict remains appropriate until either the compressed-baseline comparison is added or the authors narrow the claim to 'uncompressed RDF Patch formats'. I do not see an internal inconsistency or a fatal flaw.","tokens_in":5502,"tokens_out":10511,"duration_ms":100994,"concrete_test":"Run the bsbm-cdc and assist-iot-weather size and throughput benchmarks with three additional baselines: (i) RDF Patch text compressed with gzip -6 (or zstd --fast); (ii) RDF Patch Thrift (binary) compressed with gzip; (iii) the same Jelly-Patch settings. Measure file size and end-to-end serialization+compression and parsing+decompression throughput. If Jelly-Patch is not at least, say, 2x smaller and comparably fast end-to-end than the gzip-compressed baselines, the headline compression advantage is overstated.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The headline claim (Abstract; Section 3.3) is that Jelly-Patch achieves 3.5x and 8.9x smaller files than RDF Patch text on bsbm-cdc and assist-iot-weather. However, in Figure 1 the only baselines are RDF Patch text, RDF Patch binary (Thrift), and SPARQL Update — none of which applies any compression; the paper states 'Jelly-Patch is the only format employing any compression' (Section 3.3). Thus the reported compression ratios are inherently compressed-vs-uncompressed comparisons. RDF text (N-Quads) is highly compressible: standard gzip/zstd typically reduce such text by 5–10x. The paper even mentions that gzip could be applied to improve Jelly-Patch's handling of long literals (Section 3.3), but it never benchmarks a gzip-compressed RDF Patch text or binary baseline. If gzip-compressed RDF Patch text reaches, say, 1.5–2x the size of Jelly-Patch, the '3.5–8.9x better compression' claim would no longer describe the practical size advantage of Jelly-Patch over a reasonable alternative for storage/transfer. This directly affects the central claim's significance, independent of whether the Jelly-Patch table/frame parameters are tuned. A conditional acceptance should require this baseline.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":5891,"tokens_out":7460,"duration_ms":73832,"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":[{"comment":"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.","section":"§3.3, Figure 1"},{"comment":"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.","section":"§3.2"},{"comment":"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.","section":"§3.3, Conclusion"},{"comment":"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.","section":"§3.1--3.3"}],"minor_comments":[{"comment":"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.","section":"Figure 2"},{"comment":"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.","section":"§1"},{"comment":"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.","section":"§3.2"},{"comment":"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.","section":"§3.3"}],"recommendation":"major_revision","confidential_remarks":"The authors are also the maintainers of Jelly-RDF and RiverBench, and the benchmark compares their own new format against baselines from the same ecosystem. This is not improper given the public code, data, and specification, but I would ask the editor to ensure the artifact review checks that the fixed Jelly-Patch settings are indeed library defaults rather than values tuned for the two datasets, and that the Zenodo results match the paper. An explicit conflict-of-interest statement would also be appropriate, even though the relevant works are cited."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nWhat'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.\n\nWhere 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.\n\nWho 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.\n\nRecommendation: 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.","headline":"A real format with clean benchmarks, but the headline compression advantage needs a gzip-compressed baseline before it convinces.","tokens_in":6328,"tokens_out":2668,"would_cite":false,"duration_ms":22973,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["RDF","change data capture","diffs","RDF Patch","databases","serialization format","binary encoding","IoT streams"],"falsifier":"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.","tokens_in":5293,"feed_emoji":"🗜️","tokens_out":10028,"duration_ms":94233,"temperature":0.7,"pith_summary":"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.","feed_headline":"Change logs 3.5-8.9x smaller with new RDF diff format","feed_subtitle":"Jelly-Patch compresses RDF Patch streams and reads them up to 4.6x faster, helping replication and IoT pipelines.","key_machinery":"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.'","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the Jelly-RDF streaming compression scheme (term and prefix tables) that Jelly-Patch reuses as its base encoding.","marker":"[7]"},{"why":"Defines RDF Patch text and the RDF Delta server used to generate the change-data-capture benchmark patches.","marker":"[6]"},{"why":"Provides the benchmark workload generator used to create the change-data-capture dataset of transactional adds and deletes.","marker":"[10]"},{"why":"Provides the IoT weather sensor stream from which the rolling-difference dataset is computed.","marker":"[11]"},{"why":"Supplies the binary RDF Patch format that serves as the main throughput and size comparison baseline.","marker":"[13]"},{"why":"Supplies the Protocol Buffers serialization layer on which the Jelly-Patch message definitions are built.","marker":"[8]"},{"why":"Provides the benchmark harness methodology used for all timing measurements, accounting for JVM warmup and dead-code elimination.","marker":"[14]"},{"why":"Archives the two datasets and full benchmark results for independent verification.","marker":"[12]"}],"fun_headline_variants":["RDF change logs 3.5-8.9x smaller with Jelly-Patch","Jelly-Patch shrinks RDF diffs up to 8.9x, parses 4.6x faster","New binary format for RDF patches: 8.9x smaller, 4.6x faster","RDF patch format 8.9x smaller, 4.6x faster to parse"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["RDF change logs 3.5-8.9x smaller with Jelly-Patch","Jelly-Patch shrinks RDF diffs up to 8.9x, parses 4.6x faster","New binary format for RDF patches: 8.9x smaller, 4.6x faster","RDF patch format 8.9x smaller, 4.6x faster to parse"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000791,"raw_usage":{"total_tokens":3492,"prompt_tokens":960,"completion_tokens":2532,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":576,"completion_tokens_details":{"reasoning_tokens":2424}},"tokens_in":576,"tokens_out":2532,"duration_ms":17432,"temperature":1.0,"reasoning_tokens":2424,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T10:40:02.293791+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Seaborne, RDF Delta, 2025","cited_arxiv_id":null,"evidence_quote":"Defines RDF Patch text and the RDF Delta server used to generate the change-data-capture benchmark patches."},{"cited_title":"Bizer, A","cited_arxiv_id":null,"evidence_quote":"Provides the benchmark workload generator used to create the change-data-capture dataset of transactional adds and deletes."},{"cited_title":"URL: https://jena.apache","cited_arxiv_id":null,"evidence_quote":"Supplies the binary RDF Patch format that serves as the main throughput and size comparison baseline."},{"cited_title":"https://protobuf.dev/, accessed on 31 July 2025","cited_arxiv_id":null,"evidence_quote":"Supplies the Protocol Buffers serialization layer on which the Jelly-Patch message definitions are built."},{"cited_title":"https://github.com/openjdk/ jmh, accessed on 31 July 2025","cited_arxiv_id":null,"evidence_quote":"Provides the benchmark harness methodology used for all timing measurements, accounting for JVM warmup and dead-code elimination."},{"cited_title":"Sowiński, K","cited_arxiv_id":null,"evidence_quote":"Archives the two datasets and full benchmark results for independent verification."}],"review_version":1}