Jelly: a Fast and Convenient RDF Serialization Format

Anastasiya Danilenka; Karolina Bogacka; Nikita Kozlov; Piotr Sowinski

REVIEW 3 major objections 4 minor 2 cited by

Jelly: a Fast and Convenient RDF Serialization Format

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

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

Pith's one-line read Jelly is a binary RDF serialization format that targets both batch and streaming use, claiming compression to about 16% of N-Triples size with multi-million-triples-per-second throughput.

desk verdict A genuinely useful and honestly described binary RDF format, but its central performance claim is currently unverifiable from the paper itself. read the letter →

arxiv 2506.11298 v2 pith:FJ7IHPMD submitted 2025-06-12 cs.DB cs.NI

Piotr Sowinski , Karolina Bogacka , Anastasiya Danilenka , Nikita Kozlov This is my paper · ORCID

classification cs.DBcs.NI

keywords RDFserializationformatstreamprocessingknowledgegraphsSemanticWebdataformatsProtocolBuffersbinarystreamingcompression

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

Jelly is a binary RDF serialization format aimed at a gap left by text formats such as Turtle, N-Quads, and JSON-LD: none of them parses quickly, compresses tightly, and natively represents RDF streams at the same time. The paper claims Jelly fills that gap with one format that works for both batch files and streaming pipelines, and it supports the claim with an open protocol specification, Java and Python implementations, a command-line tool, and two deployed use cases. The headline figures, drawn from benchmarks the authors publish on the project website, are an average compression ratio of 16.2% relative to N-Triples, serialization at 7.28 million triples per second, and deserialization at 15.16 million triples per second. If those figures hold, Jelly would be a practical drop-in replacement for common RDF formats in large dumps, client-server communication, and stream ingestion.

What carries the argument

The load-bearing mechanism is Jelly's streaming compression scheme, specified in the Jelly protocol. The encoder maintains three fixed-sized string lookup tables, one for IRI prefixes, one for suffixes, and one for datatypes, indexed by integers; as the stream moves, old entries can be evicted and replaced, which keeps memory bounded for indefinite inputs. IRIs are written as pairs of variable-length integer table references, delta coding uses the value zero to mean 'repeat the last ID or increment it by one,' and a term identical to the corresponding term in the previous statement is omitted altogether. Frames group statements into batches or whole graphs/datasets, so the format is equally a stream of triples and a stream of graphs. Because Protobuf supplies the wire encoding, the binary layer is generated by standard compilers and implementers only write the translation between Protobuf messages and their RDF library's data types.

What would settle it

Re-run the exact benchmark suite behind the published performance page on the same machine and dataset mix used by the authors, comparing Jelly-JVM 2.7.0 with the closest competing binary RDF format; if the average compression ratio, serialization speed, or deserialization speed falls materially short of 16.2%, 7.28 million triples per second, or 15.16 million triples per second, or if the competitor wins, the central claim collapses.

Watch

Extended reading notes

Core claim

The paper's central claim is that a single binary format, Jelly, can simultaneously give RDF practitioners high-throughput serialization, small files, and native stream support without sacrificing ease of integration. The format encodes RDF as framed Protobuf messages, and its compression comes from three fixed-sized lookup tables for IRI prefixes, IRI suffixes, and datatypes, together with variable-length integer identifiers, delta coding, and omission of terms that repeat in consecutive statements. The authors report that on their published benchmarks, Jelly-JVM 2.7.0 reaches an average compression ratio of 16.2% relative to N-Triples, 7.28 million triples per second serialization, and 15.16 million triples per second deserialization, which they state makes it the most compressed and fastest RDF format available in either of the two major Java RDF ecosystems. They also document practical deployments, including a nanopublication service where switching to Jelly streams over HTTP reduced the time to retrieve 60,000 nanopublications from over an hour to less than four seconds.

Load-bearing premise

The central performance claim rests entirely on benchmarks published on the project website rather than on measurements in this paper, so if those external benchmarks are not reproducible or were obtained on unrepresentative hardware or datasets, the "most compressed and fastest" assertion has no in-paper support.

Editorial extensions

If this is right

RDF files and database dumps can be stored at roughly one-sixth the size of N-Triples and read back faster, shortening maintenance and transfer times.
Streaming RDF over message brokers can run in constant memory, because each frame is independent and the encoder processes one statement at a time.
Existing applications using mainstream Java RDF libraries can add Jelly as a plugin and use it wherever text formats are accepted.
Service-to-service RDF exchange gains a natively streaming option, with the reported nanopublication network upgrade cutting retrieval from over an hour to under four seconds.
Because the binary format is generated from a Protobuf schema, new language bindings can reuse the same specification instead of reimplementing by hand.

Reading between the lines

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

The durable contribution is likely the compression scheme rather than the headline numbers, since the benchmark ranking is tied to a specific version and will shift as competing formats improve.
The repeated-term and delta coding should make compression sensitive to triple ordering, so sorting triples by subject could yield even smaller files, a property the paper does not quantify.
Jelly files are not random-access: an application that needs to query a single triple without scanning the stream will still need an indexed format, so Jelly is complementary to stores and indexes.

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

Worth a look. Jelly is a real artifact: an open, Protobuf-based RDF serialization format with streaming dictionary compression, delta encoding, and support for grouped streams of graphs/datasets. The Java and Python implementations are public, integrate with Jena, RDF4J, RDFLib, and Titanium, and the CLI is genuinely useful for debugging and transcoding. The protocol specification is open, the code is out there, and the Nanopublication Network use case gives a concrete sense of what the format can do. As a tool description, this is solid.

The soft spot is exactly where the stress-test puts it. Section 2's headline numbers—16.2% compression ratio, 7.28 MT/s serialization, 15.16 MT/s deserialization—come from a project website, not the manuscript. There is no dataset list, no machine spec, no methodology, no comparison protocol. The claim 'most compressed and fastest' is a comparative superlative that requires controlled evaluation, and the paper doesn't provide enough for a reader to judge it. The benchmarks are also self-published by the same team. That doesn't mean the numbers are wrong, but it means the central value proposition currently rests on an external link. The paper even cites RDF4J Binary speed ratios from the same website. For a workshop paper, this is a notable gap; for a journal it would be disqualifying as-is.

One small technical ambiguity worth flagging: the compression description says lookup-table entries 'can be replaced by new ones using any policy (e.g., least recently used).' If the policy is truly arbitrary, a decoder can't reconstruct the table state unless the spec fixes it or communicates it. I suspect the actual spec pins this down, but the paper's wording invites the question and it should be clarified.

The related-work coverage is fair, the AI-use declaration is honest, and the paper doesn't oversell: it carefully scopes the superlative to Jena and RDF4J and says 'as far as we are aware.' Self-citation isn't a real problem here because the cited work (RDF Stream Taxonomy, RiverBench) is genuinely the basis for the design.

Bottom line: this is a paper for Semantic Web practitioners who care about binary RDF exchange, and it deserves a serious referee. I'd accept it with a request to move the benchmark methodology into the paper—at least a summary of datasets, hardware, and protocol—and to clarify the replacement policy. The artifact itself is reproducible, which is a meaningful point in its favor.

Referee Report

3 major / 4 minor

Summary. The paper introduces Jelly, a binary RDF serialization format based on Protocol Buffers, designed for high-throughput streaming and batch serialization. Jelly uses streaming compression with fixed-size lookup tables for IRI prefixes/suffixes and datatypes, delta encoding, and per-term repetition skipping. The paper reports implementations for Java (Jelly-JVM) and Python (pyjelly), integrations with Jena, RDF4J, Titanium, and RDFLib, a command-line tool, and several use cases. The central quantitative claim is that Jelly-JVM 2.7.0 achieves an average compression ratio of 16.2% relative to N-Triples, serialization at 7.28 MT/s, and deserialization at 15.16 MT/s, making it 'the most compressed and the fastest RDF format implemented in either Apache Jena or RDF4J.' These numbers are cited from an external project website rather than from data presented in the paper.

Significance. If the performance claims are reproducible, Jelly is a practically useful addition to the RDF tooling ecosystem: it provides an open, language-neutral binary format with multiple library integrations and a streaming model that existing W3C formats lack. The availability of open-source implementations and a CLI tool lowers adoption barriers, and the Nanopublication Network use case (Section 4) suggests real deployment value. The paper's significance is, however, currently contingent on external, self-published benchmarks; the manuscript itself does not supply the evidence needed to verify the superlative performance claims. The protocol description and tooling contributions are credible and potentially citable, but the performance-centric framing of the paper cannot be assessed from the submitted text alone.

major comments (3)

[Section 2, Performance paragraph] The central claims (compression ratio of 16.2%, serialization of 7.28 MT/s, deserialization of 15.16 MT/s, and 'the most compressed and the fastest RDF format implemented in either Apache Jena or RDF4J') rest entirely on an external website (w3id.org/jelly/dev/performance). The paper provides no dataset list, no machine specification, no benchmark methodology, no comparison protocol, and no aggregation method (e.g., arithmetic vs. geometric mean across datasets). Because performance is the paper's main selling point, this missing evidence is load-bearing. Please include a reproducible benchmark description in the paper (or an appendix) with the exact dataset versions, hardware, JVM settings, and aggregation procedure, or alternatively reformulate the claims to reflect only what is demonstrated in the paper.
[Section 2, Compression paragraph] The compression behavior depends on parameters that are not fixed in the paper: the sizes of the three lookup tables, the replacement policy (e.g., LRU is only given as an example), and the frame size. The benchmark configuration for Jelly-JVM 2.7.0 is not reported. If the published numbers were obtained with a tuned configuration or a dataset mix favorable to Jelly, the claim that these results generalize to 'the most compressed and fastest' format would not be supported. Please specify the exact parameter values used in the benchmark, or state the range of configurations over which the performance claim holds.
[Section 5, Related Work] The superlative performance claim is scoped to formats implemented in Apache Jena or RDF4J, which is stated, but the paper does not provide a direct comparison table even for those systems; it only names RDF4J Binary as the closest contender and gives speed ratios, again citing the external website. For a claim of being the fastest and most compressed, the paper should show per-format numbers for at least Jena Thrift/Protobuf, Jena's standard N-Triples, RDF4J Binary, and RDF4J's N-Triples, in a table in the paper, so that a reader can verify the relative performance without navigating to external resources.

minor comments (4)

[Section 1, author affiliation block] The corresponding author's email address appears corrupted as 'envel⌢pe-⌢penpiotr@neverblink.eu'; please replace it with a plain-text email address.
[Section 3.1, code snippet] The Maven artifact version is shown as 3.4.0 while the performance numbers refer to Jelly-JVM 2.7.0; please clarify which version the benchmarks use and whether the API in the code snippet (e.g., JellyLanguage.JELLY) is current.
[Section 4, database replication item] The text says 'the Jelly-RDF protocol described in Section 2', but Section 2 describes the Jelly serialization protocol and does not describe a distinct Jelly-RDF protocol; please either add a description or rephrase to avoid the mismatch.
[Section 2, Compression paragraph] The full compression algorithm is deferred to an external specification; while this is acceptable for a workshop paper, including a concise algorithmic description in an appendix would make the paper more self-contained and would help readers assess the streaming and constant-memory claims.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the paper reports empirical performance measurements and does not derive its central claims from its own assumptions.

full rationale

Jelly is a tool and system paper rather than a formal derivation. It contains no equations, no fitted parameters, and no proof whose conclusion is equivalent to an input. The performance section reports measured compression ratio and throughput figures for Jelly-JVM 2.7.0 and attributes them to benchmarks published on the project website using RiverBench; these are empirical claims, not consequences of the protocol definition. The self-citations to the authors' RDF Stream Taxonomy and RiverBench supply terminology and benchmark datasets, but the paper does not invoke them as force-bearing evidence that would make a conclusion true by construction. The absence of an in-paper dataset list, machine specification, or comparison protocol is a reproducibility and evidence-quality limitation, but under the circularity criteria it is not a reduction of a prediction to its inputs. No specific circular step can be quoted because no equation or fitted quantity is reused as a result.

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

Jelly is a software artifact, not a mathematical derivation. It introduces a new binary format, but no fitted parameters or invented physical entities. The main assumptions are that the chosen streaming criteria and the external benchmark dataset mix are appropriate. The paper's central claim depends on benchmark data that is not included in the manuscript itself.

assumptions (2)

domain assumption The stream processing criteria defined in reference [3] are the appropriate standard for assessing streaming capability.
The design goal of fully streaming operation is defined by these external criteria; if different criteria apply, the streaming claim would need re-evaluation.
domain assumption The benchmark datasets used on the project website are representative of real-world RDF workloads.
The performance numbers cited in the paper come from external benchmarks on RiverBench; the paper provides no analysis of how the dataset selection affects the claimed averages.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Jelly: a Fast and Convenient RDF Serialization Format." pith.science (2026). https://pith.science/paper/FJ7IHPMD

@misc{pith2026250611298,
  author       = {Pith},
  title        = {Pith review of: Jelly: a Fast and Convenient RDF Serialization Format},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FJ7IHPMD}},
  note         = {Machine review of arXiv:2506.11298}
}

read the original abstract

Existing RDF serialization formats such as Turtle, N-Quads, and JSON-LD are widely used for communication and storage in knowledge graph and Semantic Web applications. However, they suffer from limitations in performance, compression ratio, and lack of native support for RDF streams. To address these shortcomings, we introduce Jelly, a fast and convenient binary serialization format for RDF data that supports both batch and streaming use cases. Jelly is designed to maximize serialization throughput, reduce file size with lightweight streaming compression, and minimize compute resource usage. Built on Protocol Buffers, Jelly is easy to integrate with modern programming languages and RDF libraries. To maximize reusability, Jelly has an open protocol specification, open-source implementations in Java and Python integrated with popular RDF libraries, and a versatile command-line tool. To illustrate its usefulness, we outline concrete use cases where Jelly can provide tangible benefits. We consider that by combining practical usability with state-of-the-art efficiency, Jelly is an important contribution to the Semantic Web tool stack.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Jelly-Patch: a Fast Format for Recording Changes in RDF Datasets
cs.DB 2025-07 conditional novelty 6.0 of 10

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.
LinkML-Scala: a Robust, Fast, and Portable Implementation of LinkML
cs.DB 2026-07 conditional novelty 4.0 of 10

LinkML-Scala is a Scala 3 implementation of LinkML that runs on JVM, JavaScript, and native binaries and outperforms the Python reference implementation by 22.9–38.5x in benchmarked generation tasks.

Reference graph

Works this paper leans on

11 extracted references · 8 canonical work pages · cited by 2 Pith papers

[1]

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

arXiv 2022
[2]

Sowiński, P

P. Sowiński, P. Szmeja, M. Ganzha, M. Paprzycki, RDF Stream Taxonomy: Systematizing RDF stream types in research and practice, Electronics 13 (2024) 2558

work page 2024
[3]

Bifet, R

A. Bifet, R. Gavalda, G. Holmes, B. Pfahringer, Machine learning for data streams: with practical examples in MOA, MIT press, 2023. Chapter 2.1: Algorithms

work page 2023
[4]

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)

arXiv 2024
[5]

T. Kuhn, R. Taelman, V. Emonet, H. Antonatos, et al., Semantic micro-contributions with decen- tralized nanopublication services, PeerJ Computer Science 7 (2021) e387

work page 2021
[6]

J. D. Fernández, A. Llaves, O. Corcho, Efficient RDF interchange (ERI) format for RDF data streams, in: International Semantic Web Conference, Springer, 2014, pp. 244–259

work page 2014
[7]

Hasemann, A

H. Hasemann, A. Kröller, M. Pagel, RDF provisioning for the Internet of Things, in: 2012 3rd IEEE International Conference on the Internet of Things, IEEE, 2012, pp. 143–150

work page 2012
[8]

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

Show all 11 references

[9]

https://rdf4j.org/documentation/ reference/rdf4j-binary/, accessed on 12 June 2025

Eclipse Foundation, Inc., RDF4J binary RDF format, 2025. https://rdf4j.org/documentation/ reference/rdf4j-binary/, accessed on 12 June 2025

2025
[10]

Sporny, D

M. Sporny, D. Longley, CBOR-LD 1.0 Draft Community Group Report, 2025. https://json-ld.github. io/cbor-ld-spec/, accessed on 11 June 2025

2025
[11]

J. D. Fernández, M. A. Martínez-Prieto, C. Gutiérrez, A. Polleres, M. Arias, Binary RDF representa- tion for publication and exchange (HDT), Journal of Web Semantics 19 (2013) 22–41

2013

Pith tools

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

[1] [1]

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

arXiv 2022

[2] [2]

Sowiński, P

P. Sowiński, P. Szmeja, M. Ganzha, M. Paprzycki, RDF Stream Taxonomy: Systematizing RDF stream types in research and practice, Electronics 13 (2024) 2558

work page 2024

[3] [3]

Bifet, R

A. Bifet, R. Gavalda, G. Holmes, B. Pfahringer, Machine learning for data streams: with practical examples in MOA, MIT press, 2023. Chapter 2.1: Algorithms

work page 2023

[4] [4]

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)

arXiv 2024

[5] [5]

T. Kuhn, R. Taelman, V. Emonet, H. Antonatos, et al., Semantic micro-contributions with decen- tralized nanopublication services, PeerJ Computer Science 7 (2021) e387

work page 2021

[6] [6]

J. D. Fernández, A. Llaves, O. Corcho, Efficient RDF interchange (ERI) format for RDF data streams, in: International Semantic Web Conference, Springer, 2014, pp. 244–259

work page 2014

[7] [7]

Hasemann, A

H. Hasemann, A. Kröller, M. Pagel, RDF provisioning for the Internet of Things, in: 2012 3rd IEEE International Conference on the Internet of Things, IEEE, 2012, pp. 143–150

work page 2012

[8] [8]

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