Orchestrating Black-Box Schema Converters: An Empirical Study of Automated, Quality-Ranked Conversion Across Heterogeneous Schema Languages

PREPRINT

1

Orchestrating Black-Box Schema Converters: An Empirical Study of Automated, Quality-Ranked Conversion Across Heterogeneous Schema Languages arXiv:2606.26180v1 [cs.SE] 24 Jun 2026

Felix Neubauer, Giridhar Chinnikkaramadom Govindan, Jürgen Pleiss, and Benjamin Uekermann

and the effort of porting a model by hand grows with every additional language and every change. In principle, schema converters address exactly this need, and many of them exist. In practice, reusing them is hard. Converters are typically ad-hoc tools implemented in generalpurpose programming languages and embedded in diverse, loosely coupled tool ecosystems. They are scattered across package registries and repositories, of uneven and often undocumented quality, and frequently unmaintained; Section III-C gives concrete examples at the SHACL/JSON Schema boundary. The schema languages they connect also differ fundamentally in expressiveness and underlying data model: JSON Schema predominantly targets tree-shaped documents [1], XSD distinguishes elements and attributes [2], and SHACL [3] and OWL [4] describe RDF graphs whose resources and schema terms are identified by IRIs. As Bézivin et al. and Jouault et al. emphasize for transformations across technological spaces [5], [6], such heterogeneity makes conversions between schema languages generally lossy, non-bijective, and potentially ambiguous. For example, an XSD attribute can be Index Terms—Model transformation, software interoperability, mapped to a JSON Schema property, but no standardized namschema languages, empirical study, tool support, model-driven ing convention preserves its “attribute” status, which leads to engineering ambiguity and possible name clashes, and round-trip transformations cannot be guaranteed. A user who wants to combine I. I NTRODUCTION existing converters therefore faces several practical hurdles: CHEMAS and their schema languages are a foundational discovering and assessing suitable tools among many hetbuilding block of modern software systems. JSON Schema erogeneous implementations; hand-constructing and executing and XML Schema Definition (XSD) validate and document the indirect conversion chains when no direct converter exists; and data exchanged between services, database schemas provide judging information loss and correctness alone. Faced with consistency guarantees and enable efficient querying, and on these hurdles, users, and especially non-experts, frequently the semantic web, languages such as SHACL and OWL abandon converters altogether and re-author schemas by hand, capture rich semantics and support reasoning and inference. a labor-intensive, error-prone process, even though an imperThe same data model, however, is rarely needed in only one fect automated conversion that captures the bulk of the model of these languages: a model defined for a web API may also would already provide a valuable starting sketch. have to exist as a shapes graph for a knowledge base, as a Existing research offers partial answers along three lines, relational schema for storage, or as an ontology for integration. reviewed in Section II: structured model transformation Keeping these representations consistent as the model evolves in model-driven engineering, technology-agnostic pivot lanis a recurring software construction and maintenance task, guages, and large language models. Each helps in some ways but comes with their own limitations and does not make use F. Neubauer, G. Chinnikkaramadom Govindan, and B. Uekermann of the existing landscape of converters. are with the Institute for Parallel and Distributed Systems, University This motivates an empirical study of the current converter of Stuttgart, Universitätsstraße 32, 70569 Stuttgart, Germany (e-mail: [email protected]). landscape, organized around two research questions: J. Pleiss is with the Institute of Biochemistry and Technical Biochemistry, RQ1. To what extent can existing, imperfect converters be University of Stuttgart, Allmandring 31, 70569 Stuttgart, Germany. Corresponding author: F. Neubauer. orchestrated into automated, reproducible, and qualityAbstract—Modern software systems routinely need the same data model in several schema languages: a model may exist as JSON Schema for a web API, as XSD for data exchange, and as SHACL for a knowledge graph. Keeping these representations consistent as the model evolves is a recurring construction and maintenance burden, because converters between schema languages are hard to find, scattered across ecosystems, of uneven quality, and frequently lossy. We study, empirically, to what extent such imperfect, heterogeneous converters can be orchestrated into automated, reproducible, and quality-ranked conversions, and where the current converter landscape reaches its limits. Our approach models schema languages as nodes and converters, treated as black boxes, as directed edges, so that conversions become paths that are discovered, executed, ranked, and reported with full per-step provenance, with failures handled by trying alternatives. We realize it as the open-source Schema Conversion Orchestrator, integrate it into MetaConfigurator, and evaluate it on 60 conversion tasks built from real-world schemas across five schema languages, using agent-assisted, human-reviewed quality annotations. Orchestration surfaces a usable result for 43 of 60 tasks; the remaining failures localize concrete gaps in the converter landscape. We discuss implications for tool builders and for measuring conversion quality.

S

PREPRINT

ranked conversions between heterogeneous schema languages? RQ2. Where does the current converter landscape reach its limits, and which gaps most constrain automated crosslanguage conversion in practice? To answer them, we build an instrument that makes the questions measurable and then exercise it on real-world schemas, collecting and analyzing data on conversion coverage, output quality, robustness, and runtime. The instrument is the Schema Conversion Orchestrator, a language-agnostic orchestration framework for schema conversions that treats existing converters as black-box transformations across technological spaces. Instead of requiring a unifying metametamodel or a new pivot schema language, it models schema languages as nodes in a conversion graph and individual converters as directed edges, so that arbitrary chains of conversions between heterogeneous schema languages become paths in the graph. Modeling transformations as a graph is isejlf established in model-driven engineering [7]–[9], but those frameworks presuppose the shared metametamodel discussed above. The defining choice here is the opposite black-box stance: we treat each converter as opaque and rank whole paths by empirically measured quality. This stance, not the graph structure isejlf, distinguishes our approach from classical transformation chaining; Section VI develops the comparison. Given an input schema in any supported language and a desired target language, the orchestrator automatically discovers feasible paths, executes converters in sequence, ranks the resulting candidates, handles failures by trying alternative paths, and reports each result with full provenance, relieving users from locating, installing, and manually comparing multiple converters. This paper makes five contributions: (i) a graph-based formulation of schema conversion as black-box orchestration across heterogeneous schema languages; (ii) a modular, polyglot [10] architecture that integrates existing converters and pivot frameworks as black-box edges without forcing users to adopt a new pivot language, together with automatic path ranking using task-specific accuracy scores where available and empirical edge-quality estimates otherwise; (iii) per-step provenance metadata (path, library, URL, and version) for traceability and reproducibility; (iv) an empirical evaluation over 60 conversion tasks built from real-world schemas that quantifies conversion coverage, output quality, robustness, and runtime, and that characterizes where the current converter landscape succeeds and where it fails; and (v) an integration into MetaConfigurator [11]–[13] that exposes these conversions through an end-user interface. All study inputs, scripts, and quality annotations are published as a replication package [14], so the measurements can be reproduced and extended as converters evolve. II. R ELATED W ORK Existing research on cross-language schema and model conversion falls into three lines, none of which directly targets the reuse of many imperfect, heterogeneous black-box converters. From a Model-Driven Engineering (MDE) perspective, schemas can be viewed as models (M1) and schema languages as metamodels (M2). Declarative model transformation

2

languages such as ATL [15] provide structured, rule-based transformations over well-defined metamodels; orchestration mechanisms such as Wires* [8] and generic frameworks chain transformations in a type-safe, analyzable manner [9]; and further work addresses reuse and modularity [16]–[18], contractbased testing [19], fault localization [20], and multi-objective exploration of transformation chains [21]. These techniques assume a controlled environment with a shared metametamodel (M3) such as the Meta Object Facility (MOF) in the Model Driven Architecture technological space [5], [15], over which transformations are typed, analyzed, and composed. This assumption does not hold for the heterogeneous schemalanguage landscape, however, where no common metametamodel unifies JSON Schema, XSD, SHACL, and OWL [6], so these MDE techniques cannot be applied directly. A second line of work proposes central, technology-agnostic schema formalisms as pivots. LinkML [22] defines an open, ontology-aligned data modeling framework from which implementations in different concrete schema languages can be generated, and MD-Models [23] provides a human-readable, Markdown-based modeling environment with the same goal. These approaches keep a single model instead of many custom ones, but they introduce new dependencies: users must adopt and learn an additional modeling language and tooling, rely on the completeness and maintenance of the provided generators, and may be constrained when specific target schema languages or advanced language features are unsupported. In terms of technological spaces [6], a pivot effectively adds a new intermediate space and relies on maintained bridges between it and the diverse schema ecosystems. No single pivot language can be as expressive as all specialized schema languages combined: it is unlikely that one language will ever subsume SHACL, XSD, JSON Schema, OWL, and the rest. Large language models (LLMs) offer a third, increasingly popular option for schema conversion [13], [24]. However, LLM-based services are inherently non-deterministic, can be distracted by irrelevant context [25], show reduced accuracy on low-probability inputs even for deterministic tasks [26], and degrade in reasoning performance as input length grows [27], so correctness, reproducibility, and coverage of complex schema features cannot be guaranteed. Their promise in our setting therefore lies in complementing deterministic converters: inferring ontology terms for conversions into the semanticweb space, post-processing conversion results, or serving as a fallback when no converter path succeeds; Section VI develops these roles in the light of our results. III. A PPROACH This section presents the Schema Conversion Orchestrator: its conceptual framework and architecture, the conversion libraries it integrates, and the path ranking it uses. The evaluations are presented in Section IV. The Schema Conversion Orchestrator is a service that exposes a REST API. The API takes an input schema s0 in a source language lsrc together with a desired target language ltgt , and returns the converted schema(s). Given such a request, the orchestrator searches the conversion graph for feasible conversion paths from lsrc to ltgt ; if one or more paths p1 , p2 , . . .

PREPRINT

3

Docker container (single image, built and published in CI)

Orchestrator core (Python / Flask) conversion graph · path search · execution + sub-path caching · ranking · per-step provenance

POST /convert

Caller (e.g. MetaConfigurator) in-process

sub-process, self-describing

sub-process, self-describing

sub-process, standalone jar

Internal converters

Node.js service

Java service

Python classes (e.g. LinkML)

TypeScript converters (e.g. shacl-bridge)

Java converters (e.g. Trang)

Standalone executables e.g. ROBOT

Fig. 1. Architecture of the Schema Conversion Orchestrator: a single Docker image bundles the Python core with the external converter runtimes, integrated in-process, as self-describing sub-process services, or as directly invoked standalone executables. The concrete converter libraries are listed in Table I.

exist, it executes them, ranks the results, and returns them to the caller. Each conversion path pi is a chain of conversion steps [c1 , c2 , . . . ], where each step ck = (lk , lk+1 , fk ) applies a converter function fk that maps a schema from language lk to language lk+1 . The first step consumes the source language (l1 = lsrc ) and the last step produces the target language. A. Design The orchestrator follows a modular monolith architecture [28], [29] (Fig. 1): a core Python service calls external converters written in other languages via sub-processes. This design keeps the converters cleanly isolated behind module boundaries while remaining simple to deploy and operate as a single service; a microservice architecture would provide similar isolation, but at a major complexity overhead [30]. Extending the service with a new conversion is deliberately lightweight. A converter requires only a small amount of glue code that invokes the underlying library: an internal converter is one Python class that declares its source and target language, its library metadata, and a single conversion method, while external converters in other languages or ecosystems are self-describing modules behind a thin sub-process interface, discovered automatically at startup (or, for standalone executables, one registry entry with the invocation command). We currently integrate converters written in Python, TypeScript, and Java; step-by-step instructions with code templates are part of the repository documentation.1 New schema languages are added simply by introducing converters that produce or consume them, which keeps the cost of supporting an additional converter, schema language, or whole technological space low. The offline evaluation harness is extensible in the same spirit: a new conversion task is added by defining its benchmark inputs, ground-truth outputs, and a comparison function (Section IV). At service startup, all converters are registered and the conversion graph is assembled from their declarations: every language that appears as a source or target of a registered converter becomes a node, every converter becomes a directed edge from its source to its target language, and several converters for the same language pair form parallel edges (Fig. 2). 1 https://github.com/MetaConfigurator/schema-conversion-orchestrator\ #add-a-converter

Because the graph is derived entirely from the registrations, a newly registered converter or language participates in path finding without any further changes. When a conversion is requested via the REST API, the orchestrator first enumerates all cycle-free conversion paths from lsrc to ltgt by depth-first traversal, prunes dominated paths, ranks the remaining paths before executing any converter, and finally executes only the 10 most promising candidates. A path P2 is dominated by a shorter path P1 if P1 ’s non-empty set of converter libraries is a subset of P2 ’s: P2 then adds only extra steps without introducing any library capability not already available via P1 , so it is redundant. For example, a direct SHACL → JSON Schema path via shacl-bridge dominates any longer path that routes through an intermediate SHACL JSONLD serialization and then again applies shacl-bridge, because the indirect route uses a strict superset of the direct path’s libraries. A longer path that relies on entirely different libraries is never pruned, as it may reach a better result via a distinct conversion strategy. The path counts remain moderate: in the five-language graph subset used in the evaluation (Section IV) there are at most 10 paths between a source and target language and 3.6 on average over all ordered pairs, while in the full registered graph the maximum is 26 and the average is 4.28 over all ordered pairs (6.24 when restricted to the 144 reachable pairs, i.e., those with at least one path). Sub-path results are cached and reused where paths share intermediate steps (quantified in Section IV-C). Finally, the executed results are returned to the caller in ranked order; the orchestrator applies a ranking chain, which we introduce in Section III-D.

B. Integrated Conversions Table I lists the integrated conversion tools, their implementation or integration type, and the conversions they support; we summarize them here and refer to the table for details. The integrated converters deliberately span several technological spaces and toolchains: the XML space (e.g., Trang, xsd2jsonschema, and jsons2xsd [31]), ShEx (XMLSchema2ShEx [32]), the GraphQL boundary (graphql-json-schema [33]), the semantic-web/JSON boundary (@comake/shacl-to-json-schema, shacl-jsonschema-converter,

PREPRINT

4

TABLE I T HE D IFFERENT C ONVERSION T OOLS I NTEGRATED I NTO THE S ERVICE Conversion Tool

LinkML / schema-automator [22] MD-Models [23] Trang xsd2jsonschema xsd-json-converter jsons2xsd [31] XMLSchema2ShEx [32] graphql-json-schema [33] RDFLib n3 and rdf-ext shacl-bridge @comake/shacl-to-json-schema shacl-jsonschema-converter jsonschema2shacl ROBOT

Implementation / integration type

Integrated Conversions

{ JSON Schema, OWL} → LinkML LinkML → { JSON Schema, SHACL, Protobuf, GraphQL, OWL, ShEx, SQLAlchemy } JSON Schema → MD-Models MD-Models → { XSD, JSON Schema, SHACL, Rust, Python Protobuf, GraphQL, ShEx, Mermaid } Java DTD → XSD Node / TypeScript XSD → JSON Schema Node / TypeScript XSD → JSON Schema Java JSON Schema → XSD Standalone executable XSD → ShEx Node / TypeScript GraphQL → JSON Schema Python SHACL (Turtle) → SHACL (JSON-LD) Node / TypeScript SHACL (Turtle) → SHACL (JSON-LD) Node / TypeScript SHACL ↔ JSON Schema Node / TypeScript SHACL (JSON-LD) → JSON Schema Node / TypeScript SHACL → JSON Schema Python JSON Schema → SHACL Standalone executable OWL TTL ↔ { OWL OFN, OWL OBO } Python

Fig. 2. Complete conversion graph based on all registered converters. Nodes denote schema languages; directed edges denote converters, with parallel edges representing alternative converters for the same source–target pair. Edge labels show the underlying converter library.

and jsonschema2shacl, together with SHACL Turtle → JSONLD serialization edges), OWL serializations via ROBOT, and the technology-agnostic pivot frameworks LinkML [22] and MD-Models [23]. Different libraries can also form useful multi-step routes; for example, the SHACL Turtle → JSONLD serialization edges make JSON-LD-only converters available for ordinary SHACL/Turtle inputs. Figure 2 shows the resulting conversion graph over all currently registered schema languages and converters.

C. shacl-bridge: SHACL ↔ JSON Schema Conversion The orchestrator also accommodates new converters built to fill gaps in the conversion landscape. We illustrate this with the SHACL/JSON Schema boundary and shacl-bridge, a converter library developed in accompanying work and documented in full in a self-contained master’s thesis [34]. A particularly challenging boundary is between the semantic-web space, where SHACL constrains RDF graphs, and the JSON ecosystem, where JSON Schema validates tree-shaped documents. Several open-source tools al-

PREPRINT

ready cross this boundary, but each does so only partially, typically in a single direction, over a subset of JSON Schema keywords and SHACL constraint components, and several are no longer actively maintained: @comake/shacl-to-json-schema [35] and shacl-jsonschemaconverter [36] for SHACL → JSON Schema, and jsonschema2shacl [37] and JS2SHACL [38] for the reverse. We are furthermore not aware of peer-reviewed academic work specifically targeting direct SHACL ↔ JSON Schema conversion; the closest research addresses analogous pairs of tree- and graph-based validation languages, such as SHAX, an abstract XML syntax compiled into SHACL, XSD, and JSON Schema [39], XMLSchema2ShEx for converting XML Schema validation to ShEx [32], and mappings from relational (SQL) constraints to SHACL [40]. A single, reasonably complete library covering both directions is therefore still missing. This is precisely the gap that shacl-bridge [34], [41] was built to fill: an open-source TypeScript library that converts in both directions with broader construct coverage, integrated into the orchestrator as one more edge and evaluated against the existing alternatives below (Section IV-A). It serves this paper in two ways: it demonstrates that the orchestrator can incorporate a new converter bridging two poorly connected languages, and, because several alternative SHACL ↔ JSON Schema paths exist, it gives the path ranking (Section III-D) enough competing paths to be meaningful. Internally, shacl-bridge maps each direction through a language-independent intermediate representation, covers the core SHACL constraint components as well as selected SPARQL-based constraints, and makes information loss explicit when a construct has no equivalent in the target language. In this paper we reuse its SHACL ↔ JSON Schema benchmark for the accuracy-based ranking (Section IV-A). D. Path Ranking The orchestrator does not commit to a single “best” conversion; it returns a ranked list of the paths it chose to execute. This order matters for two reasons: even when all results are shown, it guides the user toward the most faithful conversion; and because the currently implemented ranking criteria are input-insensitive, the orchestrator can rank candidate paths before any converter runs and execute only the 10 most promising ones, which keeps both quality and runtime under control as the graph grows. Ranking is applied as a fallback chain: Failed attempts are always ranked below successful ones, and the successful attempts are ordered by three criteria of decreasing priority, each breaking only the ties left open by the previous one: benchmark accuracy where a benchmark exists, then the empirical edge-quality estimate, and finally the larger output. 1) Benchmark Accuracy: Where a per-task accuracy benchmark exists, paths are ranked first by their benchmark-derived accuracy for the requested source–target task. The benchmark is run once offline: every available path is executed on each benchmark input and scored against the ground truth with a structural F1 metric, and the per-path mean (counting failures as zero) is persisted. These scores are coarse-grained (one

5

mean per path and task, independent of the features of a particular input); a finer, feature-sensitive variant is left as future work (Section VI). We provide such scores for the SHACL ↔ JSON Schema conversions; the benchmark results are reported in Section IV-A. 2) Empirical Edge Quality: The second criterion is an empirical edge-quality estimate, assembled from per-edge values: edges that the broad evaluation measured contribute their observed quality, and any others fall back to a neutral default. From the broad evaluation (Section IV-B), each directly evaluated converter edge receives two separate values. First, its robustness or conversion success rate is Re =

Ns , N

where N is the number of direct one-step outputs for edge e and Ns is the number where the conversion path did not throw an exception and a result was obtained. Second, its conditional quality is 0.9G + 0.5L , Qe = Ns computed only over successful outputs and using the humanreviewed labels good (G), lacking (L), and invalid (I). The good label is weighted at 0.9 rather than 1.0 to reflect that even a high-quality conversion is assumed to incur some information loss; no schema converter can guarantee perfect fidelity across language boundaries. Thus, completed but unusable outputs reduce Qe , whereas failed conversions reduce Re but are not part of the conditional quality denominator. A path’s empirical score is the product of its edges’ conditional quality values Qe ; edges that were never evaluated default to 0.5. The robustness Re does not enter this score, because failed attempts are already ranked last; among the remaining successful candidates, only their expected output quality is informative. Because Qe ≤ 0.9 for every edge, the product strictly decreases with each added hop, so shorter paths are naturally preferred without a separate length criterion. Unevaluated edges default to 0.5, keeping them in play while still penalizing each added hop. The robustness rate Re remains useful as a per-edge diagnostic of conversion success and is reported alongside the quality in Figure 4. 3) Tie-Breaker: Larger Output: The remaining criterion resolves ties that the quality estimate leaves open. The orchestrator prefers the result with the higher character count, on the assumption that a conversion either maps a feature or drops it (shortening the output) and that converters do not add spurious content, so that the longest result preserves most of the original schema. This assumption is crude: it weights all elements equally (a missing description counts as much as a missing constraint) and is biased by element length, which is why it sits at the very end of the chain. E. Implementation The Schema Conversion Orchestrator is implemented as a Python service using the Flask2 web framework; its source 2 https://flask.palletsprojects.com/

PREPRINT

6

code is openly available.3 Its single REST endpoint returns the ranked list of conversion attempts, each with its full path and per-step converter library, URL, and version. Converter versions are fixed at build time. Python converters are declared as package dependencies of the service, Node.js converters as npm dependencies of the bundled TypeScript glue project, and the Java tools (Trang, ROBOT) are bundled as executable jar files. On startup the service dynamically discovers external converters, registers them together with the internal converters, and builds the conversion graph. The service ships with a Dockerfile and is packaged as a self-contained container image that bundles the Python core together with the external (Node.js and Java) converter runtimes. A continuous-integration pipeline automatically builds the image, runs the test suite and an integration test, and publishes the image to a container registry on every change. The orchestrator can therefore be run out of the box without local setup; the same image is used in the MetaConfigurator production deployment. IV. E VALUATION We evaluate the orchestrator with two complementary evaluations, each serving a dual purpose: calibrating the rankings and assessing the system. The accuracy benchmark (Section IV-A) yields the per-path accuracy scores used by the accuracy-based ranking and, from the same runs, measures the relative accuracy of individual converters and paths for a task. The broad orchestrator evaluation (Section IV-B) yields the empirical edge-quality measurements used by the fallback ranking, together with the per-edge robustness rates reported alongside them, and, from the same runs, measures how the orchestrator behaves as a whole system: whether it discovers paths, executes heterogeneous converter chains, ranks attempts, and reports failures across the conversion graph. A runtime measurement (Section IV-C) completes the picture. All code and input data for these evaluations are openly available [14]. A. Accuracy Benchmark The accuracy benchmark scores how faithfully each conversion path reproduces a ground-truth target schema. Example (SHACL → JSON Schema). For the SHACL ↔ JSON Schema conversions, for which several alternative paths exist, we reuse the benchmark that was developed alongside shacl-bridge in the accompanying thesis [34]; in this paper it both calibrates the accuracybased ranking and measures the relative accuracy of the available converters and paths. The benchmark consists of hand-constructed test pairs, each pairing a source schema that exercises one constraint construct with a ground-truth schema in the target language: 39 SHACL → JSON Schema pairs covering the core SHACL constraint components (value-type, cardinality, value-range, string-based, property-pair, logical, and shape-based constraints) plus selected SPARQL-based constraints. For scoring, the produced and the ground-truth 3 https://github.com/MetaConfigurator/schema-conversion-orchestrator

TABLE II P ER -PATH ACCURACY FOR THE F OUR SHACL → JSON S CHEMA PATHS T HAT S URVIVE D OMINATED -PATH P RUNING , U SED TO R ANK THE C ONVERSION PATHS Conversion path shacl-bridge (direct) shacl-jsonschema-converter (direct) via RDFLib JSON-LD → @comake via n3/rdf-ext JSON-LD → @comake

Mean F1

Mean Jaccard

0.93 0.47 0.45 0.21

0.89 0.34 0.43 0.16

The two indirect paths via JSON-LD that reuse shacl-bridge (mean F1 0.88 and 0.85) are dominated by the direct path and excluded before ranking. Scores are mean structural F1 and Jaccard over the SHACL constraint suite; the per-category breakdown and the full bidirectional benchmark are reported in the thesis [34].

schema are both $ref-resolved and flattened into sets of path–value entries, from which precision, recall, F1 , and the Jaccard index are computed: entries present in both schemas with equal value count as true positives, entries present in only one as false positives or false negatives, and value mismatches as both. The full construction of the test pairs and the metric is documented in the thesis [34]. The benchmark keeps each case minimal and isolated: it covers many simple, well-defined constraint components but omits deeply nested shapes graphs and combinations of constraints, and its source schemas and ground truths are hand-constructed. The metric is moreover purely structural: it weights all schema elements equally and compares output and ground truth without regard to semantic equivalence, so outputs that are semantically equivalent to the ground truth yet structured differently are penalized (why semantic comparison remains out of reach is discussed in Section VI). Within these limits, we use the benchmark to demonstrate the ranking feature; it is unsuited for an independent comparison of the converters. Table II lists the per-path scores for the four paths that survive dominated-path pruning: the dedicated shacl-bridge converter scores highest (mean F1 0.93); the two indirect paths via JSON-LD that also reuse shacl-bridge are pruned as dominated before execution (they score 0.88 and 0.85 on the benchmark but are subsumed by the shorter direct path); and the remaining third-party alternatives are substantially weaker (the direct shacl-jsonschema-converter [36], 0.47; the two JSON-LD paths into @comake/shacl-to-json-schema [35], 0.45 and 0.21). At runtime the orchestrator therefore ranks the direct shacl-bridge path first. B. Broad Orchestrator Evaluation For the broad integration evaluation we select five schema languages (JSON Schema, XSD, SHACL, LinkML, and MDModels) and, for each source language, three real-world input files that we manually classified as simple, medium, and complex by structural complexity (the source line count in Table III is only a rough proxy). The input schemas and their origins are listed in Table III; their full source URLs and any local adaptations are part of the published evaluation data [14]. The medium tier is the same EnzymeML v2 data model expressed in each of the five languages, which lets us compare conversions of an identical model across technolog-

PREPRINT

7

TABLE III I NPUT S CHEMAS U SED FOR THE B ROAD O RCHESTRATOR E VALUATION Source

Tier

Input schema (origin)

simple Address example (json-schema.org) JSON Schema medium EnzymeML v2 data model [42] complex GitHub Workflow (SchemaStore)

Lines 26 892 1,939

XSD

simple Ship-order (tutorial example) medium EnzymeML v2 data model [42] complex Apache Maven POM 4.0.0 model

31 988 2,578

SHACL

simple W3C property-shape example medium EnzymeML v2 shapes graph [42] complex DCAT-AP 2.1.1 shapes (SEMIC) [43]

18 254 639

LinkML

simple PersonInfo example medium EnzymeML v2 data model [42] complex NMDC schema (materialized) [44]

416 602 22,281

MD-Models

simple Hello MD-Models example medium EnzymeML v2 data model [42] complex ThermoML model [45]

16 480 2,702

Three representative files per source language (a small documentation/tutorial example, the shared EnzymeML v2 model, and a large real-world schema), manually classified as simple, medium, or complex. Size is the source line count and is only a rough proxy for modeling complexity.

ical spaces. We then request conversions from each source language to every other evaluated language and, for each resulting source–target–input combination, rank all feasible paths before execution and run only the 10 most promising ones. This cross product of 5 source languages, 4 non-identity target languages, and 3 inputs per source yields 5×4×3 = 60 source–target–input tasks. The outputs are annotated with three labels: good (G), meaning the result is valid and practically usable overall, even if minor details are imperfect; lacking (L), meaning the result is valid and partially useful but misses important structure, constraints, or naming quality; and invalid (I), meaning the path failed or produced an unusable result. To reduce human bias and make the annotation reproducible, the first annotation pass is performed by a coding agent (Claude Code running Claude Sonnet 4.6) that inspects each input–output pair and assigns a label following written instructions published with the evaluation [14]. Every agent label was then reviewed by a human using an interactive annotation viewer developed for this purpose, a browser-based tool displaying input and output side by side with a label and notes field. Disagreements were resolved over several iterations, in most cases by correcting the individual label during review and, where a disagreement revealed an unclear criterion, by refining the instructions and re-running the agent on the affected outputs. For example, the agent initially judged a structurally complete conversion as lacking only because the converter emits a bloated schema name (embedding the library name and a date); the instructions now direct it to judge the actual schema content and treat such naming artifacts as minor. We use these labels at two levels: the result matrix (Figure 3) aggregates the best-ranked final outputs, while the edge-level plot (Figure 4) evaluates direct converter edges separately. For the latter, we use only one-step rows in the final-output table: if a path consists of a single converter, the final output is also that converter’s

Fig. 3. Broad orchestrator evaluation over JSON Schema, XSD, SHACL, LinkML, and MD-Models. Rows are the source (input) languages and columns the target (output) languages, so each cell summarizes conversions from the row language into the column language. Each cell reports the number of discovered paths (P; only the 10 most promising paths are executed per task) and the best-ranked final outputs over three input schemas, annotated as good (G), lacking (L), or invalid (I). Cell color encodes the quality score (0.9G + 0.5L)/N over the N annotated outputs (here N = 3 inputs) on a 0–0.9 scale, from red (0, all invalid) through yellow (0.5, all lacking) to green (0.9, all good).

direct output on a real source-language schema. Across the broad evaluation this yields 42 direct outputs over 14 evaluated converter edges (27 G, 6 L, 9 I). Of these, 35 produced a result and enter the conditional quality calculation; the seven failed conversions contribute to robustness but not to conditional quality. Intermediate step outputs are still recorded for diagnostics and provenance, but they are not used for the default paper-facing edge metrics. Figure 3 summarizes the orchestrator-level result as a user would see it: only the best-ranked result per input contributes to a cell’s quality, while the path count remains visible as context about graph connectivity. Across the 60 source–target–input tasks, the best-ranked result is good in 31 cases, lacking in 12, and invalid in 17; that is, a usable (good or lacking) best result is surfaced for 43 of the 60 tasks. Overall, the orchestrator executed 216 final path attempts, of which 119 produced a result and 97 failed or produced no output. These failures are not hidden: failed paths remain part of the returned diagnostics, including the failing converter step and error message, while successful alternatives are ranked and presented to the caller. The empirical edgequality ranking is decisive for this result: for pairs such as MD-Models → JSON Schema and XSD → JSON Schema, the best-ranked result is a usable direct conversion because the ranking favors the empirically higher-quality converter rather than whichever produces the largest output (Section III-D2). The strongest coverage is obtained for conversions involving JSON Schema, SHACL, LinkML, and MD-Models over direct

PREPRINT

or near-direct paths; the remaining invalid cells concentrate on conversions into XSD or MD-Models from graph- or semanticweb sources (e.g., LinkML or SHACL), where the integrated converters provide no reliable path. One instructive case is MD-Models → SHACL. Although MD-Models advertises a direct SHACL template, the evaluated direct edge is not a reliable structural schema conversion. Inspection of the upstream MD-Models exporter4 shows that SHACL and ShEx generation first filters the model to objects with explicit semantic Term annotations; models without such annotations therefore produce an empty shapes graph. This explains why the direct MD-Models → SHACL edge is annotated as invalid in the review data, while the indirect MD-Models → JSON Schema → SHACL path can still produce useful shapes: the JSON Schema template is driven by the structural MD-Models object model, and the subsequent SHACL converter receives a non-empty structural schema. Running the same models through several target ecosystems also surfaced data-quality issues in otherwise valid-looking source schemas (for example, a schema name that is not a valid LinkML identifier and an undeclared Turtle prefix); the concrete cases are documented with the published evaluation data [14]. We reported these cases to the respective upstream maintainers through issues and pull requests, and they have since been fixed in the source schemas, which is a concrete side benefit of exercising a schema across several ecosystems at once. The roughly one quarter of tasks that still yield no usable best result reflect genuine gaps in the integrated converters, for which no path of sufficient quality exists; the orchestration and ranking themselves behave as intended. We discuss the implications in Section VI. Figure 4 visualizes the per-edge scores used by the empirical edge-quality ranking.

8

izing research data models, with form and code generation, schema inference, and AI-assisted mapping [11]–[13]. To make the orchestrator usable without any commandline interaction, we extend MetaConfigurator with schemaconversion import and export workflows. The integration exposes the orchestrator through a user-friendly graphical interface with two entry points: an import dialog, which converts a schema authored in another language (e.g., SHACL or XSD) into JSON Schema for further editing and visualization, and an export dialog, which converts the current JSON Schema to a chosen target language. In both cases MetaConfigurator calls the orchestrator’s REST API and presents the ranked list of resulting attempts. By design, this integration only surfaces conversions that have JSON Schema, MetaConfigurator’s native format, as either the source or the target; conversions directly between two other schema languages (e.g., XSD to SHACL) remain available through the orchestrator’s API. For each attempt, the interface renders the full conversion path as a sequence of language nodes connected by labeled edges, one edge per converter step (Figure 5). Because the orchestrator returns, for every step, the underlying converter library, URL, and version, hovering over an edge reveals this provenance together with a link to the corresponding library, so users can see precisely which tool produced a given result and can cite or report against it. When a path fails, the interface highlights the responsible edge and shows the corresponding error message plus intermediate conversion results if applicable, giving users actionable diagnostics. Successful attempts are shown with the converted schema and can be applied directly, with the best-ranked path presented first. VI. D ISCUSSION A. Implications of the results

C. Runtime Measurement To measure the runtime effect of sub-path caching, we run both registered SHACL ↔ JSON Schema accuracy-benchmark directions once with caching enabled and once disabled while counting the complete evaluation runtime; the timing script and its results are part of the published evaluation data [14], and the script can be rerun whenever converters or benchmarks change. The measurements were taken on a consumer laptop (Apple MacBook Air with an M1 chip and 8 GB of RAM). For SHACL → JSON Schema, running all 39 benchmark cases over all paths takes 55.5 s with caching and 62.6 s without, a reduction of 11.35%, because several attempted paths share the same intermediate SHACL JSON-LD serialization. For JSON Schema → SHACL, the 88 cases take 54.2 s with caching and 53.8 s without, a slowdown of 0.87%; there is still some overlap, but the benchmark is dominated by short paths and the cache bookkeeping slightly outweighs the reuse in this case. V. I NTEGRATION INTO M ETAC ONFIGURATOR MetaConfigurator5 is an open-source, JSON Schema-based web application for creating, editing, validating, and visual4 https://github.com/FAIRChemistry/md-models/blob/main/src/exporters.rs 5 https://metaconfigurator.org

The evaluation answers RQ1 constructively: orchestration can turn a fragmented set of imperfect converters into usable, reproducible conversion support for many practical cases. Across the 60 evaluated tasks, the orchestrator surfaced a usable best result in 43 cases, including 31 directly usable conversions. Its main contribution is therefore not that it improves individual converters, but that it changes the engineering workflow around them: users no longer have to find tools, assemble indirect chains, and compare failures manually. They receive ranked alternatives, failed paths remain visible as diagnostics, and every step carries library, URL, and version provenance. Even partially correct (“lacking”) outputs are useful in this setting, because they provide starting sketches that reduce the manual effort of porting a model. The same results answer RQ2 by localizing the remaining limits. The invalid cases are concentrated where no reliable path exists, especially conversions into XSD or MD-Models from graph- and semantic-web sources. This is a property of the current converter landscape, not a failure of path orchestration. For tool builders, the conversion graph and edgelevel robustness measurements make these gaps actionable: they show where a new or improved converter would have the largest effect. For practitioners, the coverage matrix makes current expectations explicit. For both audiences, provenance

PREPRINT

9

Fig. 4. Per-edge robustness and quality over the evaluated subset of the conversion graph. Edge labels show converter libraries together with robustness R (automatic target-language validity rate) and conditional quality Q (human-reviewed quality over automatically valid direct outputs). Edge color encodes the combined empirical edge reliability R · Q on the same 0–0.9 red–yellow–green scale as the result matrix (Figure 3). Across the direct one-step rows used here we annotated 42 outputs over 14 converter edges (27 G, 6 L, 9 I). Unlike that matrix, this evaluates individual direct converter edges rather than best complete paths. The edge color combines both components as a reliability diagnostic, whereas the path ranking isejlf multiplies the conditional quality Q along a path (Section III-D2).

Fig. 5. Running and inspecting a conversion in MetaConfigurator: the export workflow shows a conversion result. Hovering over a path edge opens a tooltip with the converter library name, URL, and version.

and the published evaluation package [14] make conversions and converter comparisons more findable, reproducible, and reusable, aligning with the FAIR principles for data and research software [46], [47]. Because adding a language or converter requires only glue code and registration, the same graph also supports sustainable evolution: narrow or unmaintained converters can be diagnosed through provenance and failure reports, replaced, or supplemented by targeted new converters such as shacl-bridge [34], [41].

B. Relation to model-driven engineering and pivot languages The conversion graph is a lightweight, untyped counterpart to megamodels and transformation-chain frameworks in model-driven engineering, where systems and transformations are themselves modeled as graph elements [7]–[9]. Those frameworks assume a controlled technological space with a shared metametamodel; within that setting, prior work has studied chaining across incompatible metamodels and multiobjective selection of transformation chains [21], [48]. Our schema languages do not share such a foundation, so the orchestrator treats converters as black boxes and ranks paths by empirical quality rather than by static metamodel coverage. This sacrifices analyzability of the individual transformation rules, but it allows reuse of ad-hoc tools embedded in different ecosystems. Pivot frameworks such as LinkML [22] and MD-Models [23] remain complementary: they are attractive when users can adopt a single source language, while the orchestrator also serves cases where models already exist in several languages or where pivot generators are only one set of edges in a larger graph. C. Transferability and AI-assisted repair The results also give a practical lesson for authors of portable schemas: the more a model relies on constructs specific to one schema language, the more loss to expect when translating it. When portability is a design goal, authors should either stay within a transferable subset or use a pivot language explicitly designed for generation into several targets. The

PREPRINT

boundary into semantic-web languages is harder still, because useful SHACL or OWL usually requires ontology terms that local schemas do not contain. The MD-Models → SHACL case illustrates this distinction: without explicit semantic Term annotations, the structural model remains present but the SHACL exporter emits no shapes. Round trips could make this transferability measurable. By converting a schema through paths that return to its source language and diffing the result against the original, the orchestrator could identify which constructs survive translation and which are consistently dropped. The same observations delimit useful roles for LLMs. They can act as fallbacks when no deterministic path yields a usable result, repair “lacking” outputs by filling the missing structure rather than performing the whole conversion, or infer ontology terms before a deterministic semantic-web exporter runs. In this framing, LLMs complement reproducible converter chains instead of replacing them. D. Measuring and ranking conversion quality Ranking paths requires a quality signal, but conversion quality is difficult to define. Ground-truth target schemas are useful, yet constructing them requires conventions for choices that have no canonical answer, such as how XSD attributes or IRI-valued SHACL property paths should be named in JSON Schema. Structural comparison is implementable and sufficient for ranking, but it penalizes semantically equivalent outputs with different structure. Exact semantic equivalence can be decided for JSON Schema using witness generation [49], but equivalence is binary while converter outputs are often partially correct. Graded semantic similarity remains open; existing distances such as JSON edit distance [50] are still structural, and language-specific comparison functions are needed for each target language. The implemented ranking criteria should therefore be read as pragmatic baselines, not as definitive measures of semantic correctness or ecosystem quality. The benchmark-backed scores demonstrate the mechanism where task-specific ground truth exists, and the empirical edge-quality estimate covers the rest of the graph. Future work should add larger languagepair benchmarks, reviewed intermediate outputs for multihop chains, weighted or multi-objective scores [21], roundtrip tests, and feature-sensitive ranking that scores only the constructs present in the current input. As the graph grows, learned path selection could avoid executing historically weak paths. E. Threats to validity Several limitations qualify these results. The broad conversion matrix is primarily an integration and usability evaluation: it uses three inputs per source language and agent-assisted, human-reviewed G/L/I labels rather than task-specific ground truth, so it does not establish semantic correctness for every supported conversion. Semantic accuracy is measured in depth only for SHACL ↔ JSON Schema, and that benchmark uses minimal, isolated, hand-constructed cases with an equally

10

weighted structural metric. Because the benchmark was developed together with shacl-bridge, its high score for that converter should not be interpreted as an independent comparison; complex nested schemas would be needed for that. The complexity tiers and source line-count proxy are coarse, and the evaluation covers only single-file schemas. Finally, weak graph regions such as OWL as a source and XSD as a target reflect the integrated converters available today. These threats could be reduced by adding ground truth for more language pairs, systematically covering constraint combinations and nesting, refining metrics toward input-dependent accuracy, and evaluating multi-file schemas. VII. C ONCLUSION We studied, empirically, to what extent existing, imperfect converters can be orchestrated into automated, reproducible, and quality-ranked conversions between heterogeneous schema languages (RQ1), and where the current converter landscape reaches its limits (RQ2). Answering RQ1, the Schema Conversion Orchestrator shows that the orchestration is feasible and effective: schema languages become nodes, black-box converters become directed edges, and each request returns ranked conversion alternatives together with failure diagnostics and per-step library, URL, and version provenance. Across the broad evaluation over five schema languages, it surfaces a usable best result for 43 of the 60 source–target–input tasks (31 of them directly usable), so orchestration delivers automated, reproducible, and qualityranked conversions for roughly three quarters of the evaluated tasks. Answering RQ2, the remaining quarter localizes the limits: the orchestration and ranking behave as intended there as well, and what is missing is a converter path of sufficient quality, with the gaps concentrated on conversions into XSD or MD-Models from graph- and semantic-web sources. The evaluation thus makes these gaps in the converter landscape explicit instead of hiding them. The orchestrator’s value lies in systematically finding, ranking, and transparently reporting the good conversions among many mediocre or failing ones, and in making the resulting conversions findable, reproducible, and easy to benchmark. Because new languages and converters can be registered with little effort, the approach grows with the ecosystem it serves, and deterministic converter chains and LLM-based suggestions become complementary instead of competing. Future work includes feature-sensitive and multiobjective ranking, learned path selection as the graph grows, task-specific ground truth for more language pairs, round-tripbased transferability analysis of schemas, support for multi-file and instance-level (data) transformations, and complementing deterministic converters with LLM-based suggestions for constructs that have no direct mapping. ACKNOWLEDGMENTS Financial support by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under grant numbers 390740016 (EXC 2075), and 441958208 (NFDI4Chem) is gratefully acknowledged. During the preparation of this work the authors used Claude Code and ChatGPT Codex in order

PREPRINT

11

to support code development and to assist with language editing of the text. After using these tools/services, the authors reviewed and revised the content as needed and take full responsibility for the content of the published article. DATA AVAILABILITY All evaluation inputs, scripts, and results are archived on DaRUS [14], together with snapshots of the used versions of MetaConfigurator and the Schema Conversion Orchestrator. The Schema Conversion Orchestrator and the MetaConfigurator integration of it are openly available on GitHub.6 R EFERENCES [1] A. Wright, H. Andrews, B. Hutton, and G. Dennis, “JSON Schema: A media type for describing JSON documents,” Internet-Draft draftbhutton-json-schema-01, IETF, 2022, jSON Schema 2020-12. [Online]. Available: https://json-schema.org/draft/2020-12/json-schema-core.html [2] S. Gao, C. M. Sperberg-McQueen, H. S. Thompson, N. Mendelsohn, D. Beech, and M. Maloney, “W3C XML Schema definition language (XSD) 1.1 part 1: Structures,” World Wide Web Consortium (W3C), W3C Recommendation, 2012. [Online]. Available: https: //www.w3.org/TR/xmlschema11-1/ [3] H. Knublauch and D. Kontokostas, “Shapes constraint language (SHACL),” World Wide Web Consortium (W3C), W3C Recommendation, 2017. [Online]. Available: https://www.w3.org/TR/shacl/ [4] P. Hitzler, M. Krötzsch, B. Parsia, P. F. Patel-Schneider, and S. Rudolph, “OWL 2 web ontology language primer (second edition),” World Wide Web Consortium (W3C), W3C Recommendation, 2012. [Online]. Available: https://www.w3.org/TR/owl2-primer/ [5] J. Bézivin, F. Büttner, M. Gogolla, F. Jouault, I. Kurtev, and A. Lindow, “Model transformations? transformation models!” in Model Driven Engineering Languages and Systems, O. Nierstrasz, J. Whittle, D. Harel, and G. Reggio, Eds. Springer Berlin Heidelberg, 2006, pp. 440–453. [6] J. Bézivin, G. Dupé, F. Jouault, G. M. Pitette, and J. E. Rougui, “First experiments with the atl model transformation language: Transforming xslt into xquery,” in OOPSLA 2003 Workshop on Generative Techniques in the Context of the Model Driven Architecture, 2003. [7] J.-M. Favre and T. Nguyen, “Towards a megamodel to model software evolution through transformations,” Electronic Notes in Theoretical Computer Science, vol. 127, no. 3, pp. 59–74, 2005. [8] J. Rivera, D. Ruiz-González, F. López-Romero, J. Bautista, and A. Vallecillo, “Orchestrating atl model transformations,” in Proceedings of the 1st International Workshop on Model Transformation with ATL (MtATL 2009), 2009, pp. 34–46. [9] M. Wimmer, G. Kappel, A. Kusel, W. Retschitzegger, J. Schönböck, and W. Schwinger, “Fact or fiction – reuse in rule-based model-tomodel transformation languages,” in Theory and Practice of Model Transformations, Z. Hu and J. de Lara, Eds. Springer Berlin Heidelberg, 2012, pp. 280–295. [10] G. Mussbacher, B. Combemale, J. Kienzle, L. Burgueño, A. Garcı́aDomı́nguez, J.-M. Jézéquel, G. Jouneaux, D.-E. Khelladi, S. Mosser, C. Pulgar, H. Sahraoui, M. Schiedermeier, and T. van der Storm, “Polyglot software development: Wait, what?” Software, vol. PP, pp. 1–8, 07 2024. [11] F. Neubauer, P. Bredl, M. Xu, K. Patel, J. Pleiss, and B. Uekermann, “MetaConfigurator: A User-Friendly Tool for Editing Structured Data Files,” Datenbank-Spektrum, pp. 1–9, 2024. [12] F. Neubauer, J. Pleiss, and B. Uekermann, “Data model creation with metaconfigurator,” 2025. [Online]. Available: https://dl.gi.de/handle/20. 500.12116/45927 [13] F. Neubauer, B. Uekermann, and J. Pleiss, “Ai-assisted json schema creation and mapping,” in 2025 28th International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), Oct 2025, pp. 79–83. [14] F. Neubauer, “Replication dataset for: Orchestrating Schema Conversions Across Heterogeneous Schema Languages: A Graph-Based, BlackBox Approach,” 2026. 6 Schema Conversion Orchestrator: https://github.com/MetaConfigurator/ schema-conversion-orchestrator; MetaConfigurator: https://github.com/ MetaConfigurator/meta-configurator

[15] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev, “Atl: A model transformation tool,” Science of Computer Programming, vol. 72, no. 1, pp. 31–39, 2008, special Issue on Second issue of experimental software and toolkits (EST). [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167642308000439 [16] J. S. Cuadrado and J. G. Molina, “Modularization of model transformations through a phasing mechanism,” Software & Systems Modeling, vol. 8, no. 3, pp. 325–345, 2009. [17] M. Fleck, J. Troya, M. Kessentini, M. Wimmer, and B. Alkhazi, “Model transformation modularization as a many-objective optimization problem,” Trans. Softw. Eng., vol. 43, no. 11, pp. 1009–1032, 2017. [18] S. Höppner and M. Tichy, “Traceability and reuse mechanisms, the most important properties of model transformation languages,” Empirical Softw. Engg., vol. 29, no. 2, Feb. 2024. [Online]. Available: https://doi.org/10.1007/s10664-023-10428-2 [19] M. Gogolla and A. Vallecillo, “Tractable model transformation testing,” in Modelling Foundations and Applications, R. B. France, J. M. Kuester, B. Bordbar, and R. F. Paige, Eds. Springer Berlin Heidelberg, 2011, pp. 221–235. [20] L. Burgueño, J. Troya, M. Wimmer, and A. Vallecillo, “Static fault localization in model transformations,” Trans. Softw. Eng., vol. 41, no. 5, pp. 490–506, 2015. [21] M. Eisenberg, A. Sahay, D. Di Ruscio, L. Iovino, M. Wimmer, and A. Pierantonio, “Multi-objective model transformation chain exploration with momot,” Information and Software Technology, vol. 174, p. 107500, 2024. [Online]. Available: https://www.sciencedirect. com/science/article/pii/S0950584924001058 [22] 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. Ireland, J. O. B. Jacobsen, M. Krishnamurthy, C. Kroll, D. Linke, R. Ly, N. Matentzoglu, J. A. Overton, J. L. Saunders, D. R. Unni, G. Vaidya, W.-M. A. M. Vierdag, L. C. Contributors, O. Ruebel, C. G. Chute, M. H. Brush, M. A. Haendel, and C. J. Mungall, “Linkml: An open data modeling framework,” 2025. [Online]. Available: https://arxiv.org/abs/2511.16935 [23] J. Range and J. Pleiss, “MD-Models: Human-Readable, Model-Driven Specifications for FAIR and AI-Ready Research Data,” 2026. [24] M. J. Mior, “Large language models for json schema discovery,” 2024. [Online]. Available: https://arxiv.org/abs/2407.03286 [25] F. Shi, X. Chen, K. Misra, N. Scales, D. Dohan, E. Chi, N. Schärli, and D. Zhou, “Large language models can be easily distracted by irrelevant context,” in Proceedings of the 40th International Conference on Machine Learning, ser. ICML’23. JMLR.org, 2023, pp. 31 210– 31 227. [26] R. T. McCoy, S. Yao, D. Friedman, M. D. Hardy, and T. L. Griffiths, “Embers of autoregression show how large language models are shaped by the problem they are trained to solve,” Proceedings of the National Academy of Sciences, vol. 121, no. 41, p. e2322420121, 2024. [Online]. Available: https://www.pnas.org/doi/abs/10.1073/pnas.2322420121 [27] M. Levy, A. Jacoby, and Y. Goldberg, “Same task, more tokens: the impact of input length on the reasoning performance of large language models,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics, 2024, pp. 15 339–15 353. [28] L. F. Al-Qora’n and A. Al-Said Ahmad, “Modular monolith architecture in cloud environments: A systematic literature review,” Future Internet, vol. 17, no. 11, 2025. [Online]. Available: https: //www.mdpi.com/1999-5903/17/11/496 [29] R. Su and X. Li, “Modular monolith: Is this the trend in software architecture?” in Proceedings of the 1st International Workshop on New Trends in Software Architecture, ser. SATrends ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 10–13. [Online]. Available: https://doi.org/10.1145/3643657.3643911 [30] A. Kamisetty, D. Narsina, M. Rodriguez, S. Kothapalli, and J. C. S. Gummadi, “Microservices vs. monoliths: Comparative analysis for scalable software architecture design,” Engineering International, vol. 11, no. 2, pp. 99–112, 2023. [31] ethlo, “jsons2xsd,” https://github.com/ethlo/jsons2xsd, 2026, java/Maven library (version 2.3.0) converting JSON Schema to XSD; accessed June 2026. [32] H. Garcı́a-González and J. E. Labra Gayo, “XMLSchema2ShEx: Converting XML validation to RDF validation,” Semantic Web, vol. 11, pp. 235–253, 2018. [33] graphql-json-schema, “graphql-json-schema,” https://www.npmjs.com/ package/graphql-json-schema, 2026, typeScript library (version 0.1.2) converting GraphQL to JSON Schema; accessed June 2026.

PREPRINT

[34] G. Chinnikkaramadom Govindan, “Bridging SHACL and JSON Schema: Design, Implementation, and Evaluation of Bidirectional Conversions for JSON and JSON-LD Documents,” Master’s Thesis, University of Stuttgart, Institute for Parallel and Distributed Systems, 2026. [35] Comake, “@comake/shacl-to-json-schema,” https://github.com/comake/ shacl-to-json-schema, 2026, software library in TypeScript (version 1.0.3) converting SHACL (JSON-LD) to JSON Schema; accessed June 2026. [36] R. Siqueira, “shacl-jsonschema-converter,” https://github.com/ siqueirarenan/shacl-jsonschema-converter, 2026, software library in TypeScript (version 0.1.3) converting SHACL to JSON Schema; accessed June 2026. [37] CiTIUS, “jsonschema2shacl,” https://github.com/citiususc/ jsonschema2shacl, 2026, python library converting JSON Schema to SHACL shape graphs; accessed June 2026. [38] JS2SHACL, “JS2SHACL: JSON Schema to SHACL Conversor,” https: //github.com/gbd-ufsc/JS2SHACL, 2026, web application converting JSON Schema to SHACL in Turtle; accessed June 2026. [39] H.-J. Rennau, “Combining graph and tree: writing SHAX, obtaining SHACL, XSD and more,” in Proceedings of Balisage: The Markup Conference 2019, Balisage Series on Markup Technologies, Vol. 23, 2019, sHAX: an abstract XML syntax compiled into SHACL, XSD, and JSON Schema. [40] R. B. Thapa and M. Giese, “Mapping Relational Database Constraints to SHACL,” in The Semantic Web – ISWC 2022, ser. Lecture Notes in Computer Science, vol. 13489, 2022, pp. 214–230. [41] G. Chinnikkaramadom Govindan, “shacl-bridge: Bidirectional Conversion between SHACL and JSON Schema,” https://github.com/ MetaConfigurator/shacl-bridge, 2026. [42] S. Lauterbach, H. Dienhart, J. Range, S. Malzacher, J.-D. Spöring et al., “EnzymeML: seamless data flow and modeling of enzymatic data,” Nature Methods, vol. 20, no. 3, pp. 400–402, 2023. [43] Publications Office of the European Union, “DCAT Application Profile for Data Portals in Europe (DCAT-AP),” https://op.europa.eu/en/web/ eu-vocabularies/dcat-ap, 2021, specification, version 2.1.1 shapes used for the evaluation; accessed June 2026. [44] E. A. Eloe-Fadrosh, F. Ahmed, Anubhav, M. Babinski, J. Baumes, M. Borkum et al., “The National Microbiome Data Collaborative Data Portal: an integrated multi-omics microbiome data resource,” Nucleic Acids Research, vol. 50, no. D1, pp. D828–D836, 2022. [45] M. Frenkel, R. D. Chirico, V. V. Diky, Q. Dong, S. Frenkel, P. R. Franchois et al., “ThermoML—An XML-Based Approach for Storage and Exchange of Experimental and Critically Evaluated Thermophysical and Thermochemical Property Data. 1. Experimental Data,” Journal of Chemical & Engineering Data, vol. 48, no. 1, pp. 2–13, 2003. [46] M. D. Wilkinson, M. Dumontier, I. J. Aalbersberg, G. Appleton et al., “The FAIR guiding principles for scientific data management and stewardship,” Scientific Data, vol. 3, no. 1, p. 160018, 2016. [47] M. Barker, N. P. Chue Hong, D. S. Katz, A.-L. Lamprecht, C. Martı́nezOrtiz, F. Psomopoulos, J. Harrow, L. J. Castro, M. Gruenpeter, P. A. Martı́nez, and T. Honeyman, “Introducing the FAIR principles for research software,” Scientific Data, vol. 9, no. 1, p. 622, 2022. [48] F. Basciani, D. Di Ruscio, L. Iovino, and A. Pierantonio, “Automated chaining of model transformations with incompatible metamodels,” in Model-Driven Engineering Languages and Systems (MODELS 2014), ser. Lecture Notes in Computer Science, vol. 8767. Springer, 2014, pp. 602–618. [49] L. Attouche, M.-A. Baazizi, D. Colazzo, G. Ghelli, C. Sartiani, and S. Scherzinger, “Witness generation for JSON Schema,” Proceedings of the VLDB Endowment, vol. 15, no. 13, pp. 4002–4014, 2022. [50] T. Hütter, N. Augsten, C. M. Kirsch, M. J. Carey, and C. Li, “JEDI: These aren’t the JSON documents you’re looking for?” in Proceedings of the 2022 International Conference on Management of Data (SIGMOD ’22). ACM, 2022, pp. 1584–1597.

12