LinkML-Scala: a Robust, Fast, and Portable Implementation of LinkML

Andriy Plokhotnyuk; Kacper Grzymkowski; Piotr Sowinski

REVIEW 3 major objections 6 minor 13 references

LinkML-Scala: a Robust, Fast, and Portable Implementation of LinkML

T0 review · 3 major / 6 minor · reviewed 2026-08-01 · deepseek-v4-flash

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

Pith's one-line read LinkML-Scala gives LinkML a second full implementation, written in Scala 3, that runs on JVM, JavaScript, and native binaries and beats the Python implementation by 22.9–38.5x in the paper's benchmarks.

desk verdict A genuinely useful engineering contribution—first non-Python LinkML implementation—but the headline speedup numbers are only point estimates and may partly reflect uneven feature coverage, a limitation the authors themselves acknowledge. read the letter →

arxiv 2607.22335 v1 pith:TUD6WJSW submitted 2026-07-24 cs.DB

Piotr Sowinski , Kacper Grzymkowski , Andriy Plokhotnyuk This is my paper · ORCID

classification cs.DB

keywords LinkMLLinkedDataModelingLanguageScala3integrationJSONSchemaSHACLperformancebenchmarks

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

The paper sets out to show that LinkML, a YAML-based data-modeling framework that translates schemas into JSON Schema, SHACL, RDFS, and Table Schema, can have a complete implementation outside Python. It presents LinkML-Scala, a Scala 3 implementation covering the metamodel, runtime support, schema derivation, and generators, and able to run in browsers, on JVM, and as native binaries. The paper claims substantial speedups in every benchmarked scenario, with geometric means of 22.9–36.5x in cold starts and 26.8–38.5x in warm loops, and argues this opens LinkML to real-time editors and enterprise server applications. A sympathetic reader would care because a portable, faster second implementation turns LinkML from a single-implementation niche tool into a more credible interoperability basis.

What carries the argument

The central piece is the SchemaView package: a shared layer that implements LinkML semantics once, above any individual generator. It handles schema loading and validation, enum text-to-meaning mappings, slot derivation for classes, inlining-mode inference, case conversions, and LinkML-to-runtime type mapping, exposing them as Scala enumerations and algebraic data types. Because generators pattern-match over these types, unhandled semantic cases become compile-time errors rather than silent output differences. Around it, a custom Scala macro codec decodes YAML schemas into immutable, type-safe classes with reflection-free generated code, a step needed because LinkML's compact dictionaries in

What would settle it

Compare generated JSON Schema and SHACL outputs from both implementations on the model catalog, checking semantic equivalence (constraint-for-constraint) rather than just accept/reject on sample instances. If the Scala outputs turn out to omit constraints the Python outputs include, the speed benchmark is measuring coverage, not raw performance, and the 22.9–38.5x claim as a pure performance statement would not stand.

Watch

Extended reading notes

Core claim

The paper's central claim is that LinkML-Scala is a complete, second implementation of LinkML: it loads YAML schemas, validates them against the metamodel, derives typed Scala classes with compile-time macro codecs, and generates JSON Schema, SHACL, RDFS, Table Schema, Scala, and LinkML output. It runs on the JVM, in browsers through JavaScript, and as native binaries. On benchmarks over 11 real-world schemas, it reports speedups over the Python implementation in every scenario, with geometric means of 22.9–36.5x for cold starts and 26.8–38.5x for warm generator loops; it is delivered as a CLI, a library for JVM and JavaScript, an in-browser playground, and a CI action.

Load-bearing premise

The headline speedups assume both implementations produce functionally equivalent schemas on the benchmark models; the paper itself notes uneven feature coverage between the implementations may explain some of the speed difference.

Editorial extensions

If this is right

Real-time schema linting and editing in browsers becomes feasible; the paper identifies this as previously blocked by Python-runtime latency.
Enterprise server applications can embed LinkML on the JVM or in native binaries without Python interop.
The LinkML specification now has a second full implementation to serve as an interoperability check, and the authors plan to feed fixes back into the specification.
The language-agnostic model catalog lets other implementations test behavioral equivalence of generators, not just structural output matching.
The benchmark datasets and harness are published, so the measured speedups can be independently reproduced.

Reading between the lines

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

If feature coverage explains part of the speedup (the paper's own Discussion flags uneven coverage as a possible cause), the 20–40x figures compare capabilities as well as raw speed; a stricter equivalence test would likely reduce the gap in some schemas.
The authors' future-work list (SQL DDL, Avro, Parquet, Protobuf) suggests the SchemaView design makes generators cheap to add, since semantics stay centralized even as targets multiply.
A behavioral accept/reject test convention could become the standard way to certify LinkML implementations, because it tests meaning rather than schema text.

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

Should know: this paper is a real systems contribution—the first non-Python, fully-featured LinkML implementation, in Scala 3, running on JVM, JavaScript, and native binaries. That's genuinely new and important within the LinkML/data-modeling niche. The authors shipped code, a model catalog, benchmark datasets, a CLI, a browser playground, and a CI action. They followed a self-hosting path: generated Scala via a Python prototype, then discarded the Python generator once the Scala version could self-host. That kind of detail suggests real engineering.

What it does well: the benchmark design is mostly sensible—11 public schemas, cold and warm scenarios, hyperfine and JMH, published data. The model-zoo approach—test that generated schemas accept valid and reject invalid instances rather than asserting output structure—is a nice, language-agnostic idea. The authors also report outliers honestly and explicitly flag uneven feature coverage as a possible cause of speed differences. That's more candor than most systems papers.

The soft spot is the one the stress-test note highlights: the headline speedups (22.9–38.5x geometric means) are only interpretable as raw performance if the Scala and Python generators produce functionally equivalent output for the 11 benchmark schemas. The paper does not compare the generated artifacts on those schemas. The model zoo is separate and covers only a small hand-curated set. So the speedup could partly measure missing features, not just faster implementation of the same features. The authors admit this in the Discussion, which lessens but does not remove the concern. The words "robust" and "drop-in replacement" in the introduction overclaim relative to what is demonstrated: two main generators tested, 11 schemas, no equivalence proof.

Is this load-bearing? It undercuts the precision of the performance claim, but not the existence or usefulness of the system. LinkML-Scala is still a serious second implementation, and even a conservative reader should find value in its portability and the benchmark dataset.

Who should read it: anyone building tools on LinkML, or anyone interested in engineering papers about implementing an existing spec in a cross-platform language. It deserves a serious referee—not desk-reject material. For review, ask for an artifact comparison on the benchmark schema set, or at least a feature-coverage matrix, before taking the speedup numbers at face value. This is a revise, not a reject.

Referee Report

3 major / 6 minor

Summary. The paper presents LinkML-Scala, a Scala 3 implementation of the LinkML data-modeling framework, claimed to cover the metamodel, runtime support, schema derivation, and generators for JSON Schema, SHACL, RDFS, and Table Schema. The implementation is distributed as a CLI, an in-browser playground, a GitHub CI Action, and JVM/JavaScript libraries. The main empirical claim is that LinkML-Scala outperforms the Python linkml package in every tested scenario, by geometric-mean speedups of 36.5x and 22.9x in cold-start JSON Schema and SHACL generation, and 38.5x and 26.8x in warm scenarios. The evaluation uses 11 public schemas, with cold-start timings via hyperfine and warm timings via JMH for Scala and a Python script for linkml. The paper also describes a model zoo for behavioral testing of generators and releases benchmark datasets.

Significance. If the results hold, this is a significant systems contribution: LinkML currently has only one full implementation, and a portable, substantially faster second implementation would unlock real-time schema editing, browser-based tooling, and JVM/enterprise deployments. The paper's strengths include open-source distribution, public benchmark datasets and code, use of both cold-start and warm scenarios, and a reusable model catalog. The speedups are large but the central interpretation depends on the unexamined assumption that the two implementations produce functionally equivalent generator outputs on the benchmark schemas. The paper itself acknowledges uneven feature coverage as a possible cause. The benchmarking methodology also lacks variance reporting. The contribution is potentially important, but the headline claims need additional evidence before they can be accepted.

major comments (3)

[§4, Figures 2–3; §2 Testing] The headline speedups (geometric means 36.5x/22.9x cold, 38.5x/26.8x warm) are meaningful as performance comparisons only if LinkML-Scala and linkml Python generate functionally equivalent outputs for the 11 benchmark schemas. The evaluation measures throughput alone and does not compare the generated JSON Schema or SHACL artifacts. The model zoo described in §2 checks only that generators accept valid and reject invalid instances on a small, hand-curated catalog; the benchmark schemas are not included in that behavioral test, and the accept/reject criterion cannot detect omitted or simplified features such as inheritance flattening, derived slots, enum constraints, or inlining decisions. The paper's own Discussion states that 'uneven feature coverage between the implementations' may explain the speed differences. As written, the speedups may measure coverage rather than raw performance,
[§4 Results summary] No within-run variance or confidence intervals are reported. Cold-start hyperfine runs and warm JMH runs should yield standard deviations or confidence intervals, but Figures 2–3 show only point estimates and the text gives no uncertainty measure. Given the very wide spread across schemas (e.g., 1.7x to 187x for warm JSON Schema), the geometric mean alone is not a sufficient summary. Please report per-schema standard errors or confidence intervals, the number of repetitions actually used (the '5 warm-up runs and 10 measure runs across 5 forks' is ambiguous), and ideally a paired test that the speedups are statistically distinguishable from 1.
[§1 and §4 Discussion] The paper states that LinkML-Scala 'aims to be a drop-in replacement' for the Python package, but no evidence is provided that the CLI interface, library API, or generated outputs are compatible beyond the specific benchmark commands. The Discussion's own caveat about uneven feature coverage is in direct tension with the drop-in claim. A feature-coverage matrix and a list of known unsupported or divergent behaviors are needed to substantiate the replacement claim; without these, the 'robust' and 'consistent' language in the abstract is stronger than the presented evidence.

minor comments (6)

[§2] Typo: 'can also also be transpiled' should read 'can also be transpiled'.
[§4] The figure captions contain 'T arget = JSON Schema' and 'T arget = SHACL' with a spurious space; likely a rendering or copy-paste artifact.
[§4 Results summary] The text alternates between 'average speedup' and 'geometric mean' without making clear which one is reported; the geometric mean should be used consistently and spelled out in the abstract.
[§5] Typo: 'ingrate' should be 'integrate' in 'We also plan to ingrate LinkML-Scala with Jelly'.
[Author affiliations] The corresponding-author email appears mangled: '/envel⌢pe-⌢penpiotr@neverblink.eu' should be fixed to a normal email address.
[§4 Benchmark methodology] For the warm benchmark, please clarify exactly which phases (YAML parsing, import resolution, schema derivation) are included in the measured region versus the set-up phase, since this affects the interpretation of the speedups.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the central claims are an external benchmark against the Python implementation and a self-contained engineering report; no fitted parameter is renamed as a prediction and the only self-citation (Jelly) is future work, not load-bearing.

full rationale

The paper's central claims are (1) that LinkML-Scala is a full, portable implementation of LinkML and (2) that it outperforms the linkml Python package in benchmarks. Neither claim is derived from a parameter fitted to the data being predicted. The benchmark methodology compares two independently implemented tools on 11 external schemas; the speedup ratio is a direct throughput measurement, not a quantity constructed from its own inputs. The model-zoo testing asserts behavioral acceptance/rejection of instances, which is an external validation strategy, not a definitional equivalence. The paper's own acknowledgement in Section 4 that 'uneven feature coverage between the implementations' may explain some speed differences is a threat to the interpretation of the benchmark as a pure performance comparison, but it is not circularity: it does not make the predicted quantity equal to the model's input by construction. The only self-citation is reference [13] (Jelly), which appears in the future-work paragraph and is not used to support the central performance or coverage claims. The self-hosting history of the Scala generator is a development detail, not a load-bearing derivation. No uniqueness theorem, ansatz, or fitted input is imported from prior work by the same authors. Therefore the paper is not circular; the appropriate finding is score 0.

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

The paper introduces no new theoretical entities or fitted parameters. Its load-bearing premises are empirical: that the benchmark comparison measures equivalent work and that the tested schemas/targets represent real LinkML usage.

assumptions (3)

domain assumption Generator outputs from LinkML-Scala and linkml Python are functionally equivalent for the benchmark schemas.
The speedup comparison in §4 is only meaningful if outputs are equivalent; the model zoo tests acceptance/rejection behavior, not full equivalence, and §4 admits uneven feature coverage may explain some speed differences.
domain assumption The 11 benchmark schemas and the two generator targets are representative of LinkML usage.
The generalization 'outperforms the Python implementation in every tested scenario' relies on this representative workload in §4; several schemas required minor manual repairs.
domain assumption The native-image CLI used in cold-start benchmarks and the JVM/JavaScript builds exhibit the same behavior.
The portability claims in §2 and §3 assume behavioral consistency across JS, JVM, and native targets, but only the native CLI and JVM warm-loop benchmark are actually measured.

how reviews work

0 comments

Cite this review

Pith. "Pith review of LinkML-Scala: a Robust, Fast, and Portable Implementation of LinkML." pith.science (2026). https://pith.science/paper/TUD6WJSW

@misc{pith2026260722335,
  author       = {Pith},
  title        = {Pith review of: LinkML-Scala: a Robust, Fast, and Portable Implementation of LinkML},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TUD6WJSW}},
  note         = {Machine review of arXiv:2607.22335}
}

read the original abstract

LinkML is a unified framework for data and domain modeling that spans diverse formats and ecosystems: JSON, RDF, CSV, SQL, spreadsheets and more. However, until now it had only one fully-featured implementation, written in Python, which is limited in terms of performance, portability, and behavior consistency. This restricts LinkML's usability in settings such as real-time schema editing and enterprise server applications. To address these issues, we present LinkML-Scala: a robust, fast, and portable implementation of LinkML that covers the metamodel, runtime support, schema derivation, and generators for JSON Schema, SHACL, RDFS, and Table Schema. Written in Scala 3, it runs in the browser (JavaScript transpilation), on the JVM, and as native binaries. LinkML-Scala is distributed as an in-browser playground, a CLI application, a GitHub CI Action, and JVM / JavaScript libraries. In our benchmarks, it outperforms the Python implementation in every tested scenario, on average by 22.9--38.5x. We consider LinkML-Scala an important contribution toward increasing LinkML's adoption and we outline a plan for further work to ensure implementation interoperability and stability.

Figures

Figures reproduced from arXiv: 2607.22335 by the authors.

**Figure 1.** LinkML-Scala in-browser playground: https://linkml.neverblink.eu/playground/ GitHub CI Action. We package a ready-made GitHub CI Action3 that allows for fast schema validation and generation. The Action is written in pure JavaScript, so it runs on all platforms. Libraries. We publish library JARs to Maven Central – this allows for accessing the SchemaView interface, generators, and other features in Scala, Java, or … view at source ↗

**Figure 2.** Cold-start benchmark results. Warm benchmarks. Benchmark has split implementations: LinkML-Scala uses the Java Microbenchmark Harness [12], LinkML-Python uses a plain Python script. Both implementations are allowed to 4 https://www.npmjs.com/package/@neverblink/linkml 5 https://linkml.io/linkml-registry/registry/ 6 https://github.com/NeverBlink-labs/linkml-benchmark-schemas [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Warm benchmark results. Results summary. We calculate speedup as the ratio between LinkML-Scala’s throughput and LinkML (Python) throughput. The geometric mean of the speedup for the cold-start scenario is 36.5x (JSON Schema) and 22.9x (SHACL). For the warm scenario, the average speedup is 38.5x (JSON Schema) and 26.8x (SHACL). LinkML-Scala is faster than LinkML (Python) in every tested scenario. Discussion and limi… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

13 extracted references · 1 linked inside Pith

[1]

R. Guha, D. Brickley, RDF Schema 1.1, W3C Recommendation, W3C, 2014. https://www.w3.org/ TR/2014/REC-rdf-schema-20140225/

2014
[2]

Patel-Schneider, B

P. Patel-Schneider, B. Parsia, P. Hitzler, S. Rudolph, M. Krötzsch, OWL 2 Web Ontology Lan- guage Primer (Second Edition), W3C Recommendation, W3C, 2012. https://www.w3.org/TR/2012/ REC-owl2-primer-20121211/

2012
[3]

Knublauch, D

H. Knublauch, D. Kontokostas, Shapes Constraint Language (SHACL), W3C Recommendation, W3C, 2017. https://www.w3.org/TR/2017/REC-shacl-20170720/

2017
[4]

S. A. T. Moxon, H. Solbrig, N. L. Harris, P. Kalita, M. A. Miller, S. Patil, K. Schaper, C. Bizon, J. H. Caufield, S. C. Cuesta, C. Cox, F. Dekervel, D. M. Dooley, W. D. Duncan, T. Fliss, S. Gehrke, A. S. L. Graefe, H. Hegde, A. J. Ireland, J. O. B. Jacobsen, M. Krishnamurthy, C. Kroll, D. Linke, R. Ly, N. Matentzoglu, J. A. Overton, J. L. Saunders, D. R....

2026
[5]

Fowler, J

D. Fowler, J. Barratt, P. Walsh, Frictionless data: making research data quality visible, International Journal of Digital Curation 12 (2017) 274–285

2017
[6]

Doeraene, Scala.js: Type-directed interoperability with dynamically typed languages (2013)

S. Doeraene, Scala.js: Type-directed interoperability with dynamically typed languages (2013)

2013
[7]

C. Wimmer, GraalVM native image: large-scale static analysis for Java (keynote), in: Proceedings of the 13th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages, 2021, pp. 3–3

2021
[8]

Stucki, A

N. Stucki, A. Biboudis, S. Doeraene, M. Odersky, Semantics-preserving inlining for metaprogram- ming, in: Proceedings of the 11th ACM SIGPLAN International Symposium on Scala, 2020, pp. 14–24

2020

Show all 13 references

[9]

N. A. Stucki, Scalable metaprogramming in Scala 3, Ph.D. thesis, EPFL, 2023

2023
[10]

B. C. Oliveira, A. Moors, M. Odersky, Type classes as objects and implicits, ACM Sigplan Notices 45 (2010) 341–360

2010
[11]

Peter, hyperfine, 2023

D. Peter, hyperfine, 2023. URL: https://github.com/sharkdp/hyperfine

2023
[12]

https://github.com/openjdk/ jmh, accessed on 23 July 2026

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

2025
[13]

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, presented at SEMANTiCS 2025 Developers Workshop, 3 September, 2025, Vienna, Austria (2025). doi:10.48550/arXiv.2506.11298

2025 doi arXiv

Pith tools

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

[1] [1]

R. Guha, D. Brickley, RDF Schema 1.1, W3C Recommendation, W3C, 2014. https://www.w3.org/ TR/2014/REC-rdf-schema-20140225/

2014

[2] [2]

Patel-Schneider, B

P. Patel-Schneider, B. Parsia, P. Hitzler, S. Rudolph, M. Krötzsch, OWL 2 Web Ontology Lan- guage Primer (Second Edition), W3C Recommendation, W3C, 2012. https://www.w3.org/TR/2012/ REC-owl2-primer-20121211/

2012

[3] [3]

Knublauch, D

H. Knublauch, D. Kontokostas, Shapes Constraint Language (SHACL), W3C Recommendation, W3C, 2017. https://www.w3.org/TR/2017/REC-shacl-20170720/

2017

[4] [4]

S. A. T. Moxon, H. Solbrig, N. L. Harris, P. Kalita, M. A. Miller, S. Patil, K. Schaper, C. Bizon, J. H. Caufield, S. C. Cuesta, C. Cox, F. Dekervel, D. M. Dooley, W. D. Duncan, T. Fliss, S. Gehrke, A. S. L. Graefe, H. Hegde, A. J. Ireland, J. O. B. Jacobsen, M. Krishnamurthy, C. Kroll, D. Linke, R. Ly, N. Matentzoglu, J. A. Overton, J. L. Saunders, D. R....

2026

[5] [5]

Fowler, J

D. Fowler, J. Barratt, P. Walsh, Frictionless data: making research data quality visible, International Journal of Digital Curation 12 (2017) 274–285

2017

[6] [6]

Doeraene, Scala.js: Type-directed interoperability with dynamically typed languages (2013)

S. Doeraene, Scala.js: Type-directed interoperability with dynamically typed languages (2013)

2013

[7] [7]

C. Wimmer, GraalVM native image: large-scale static analysis for Java (keynote), in: Proceedings of the 13th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages, 2021, pp. 3–3

2021

[8] [8]

Stucki, A

N. Stucki, A. Biboudis, S. Doeraene, M. Odersky, Semantics-preserving inlining for metaprogram- ming, in: Proceedings of the 11th ACM SIGPLAN International Symposium on Scala, 2020, pp. 14–24

2020