Delete or test untested compilers

[amc-corey-cox]

Problem

5 of 10 compiler implementations have no tests:

Compiler	Tests	Used in CLI
GraphvizCompiler	✅	No
MarkdownCompiler	✅	Yes
PythonCompiler	✅	Yes
AWKCompiler	❌	No
R2RMLCompiler	❌	No
SPARQLCompiler	❌	No
SSSOMCompiler	❌	No
SQLCompiler	❌	No

The untested compilers are largely stubs — most raise NotImplementedError or have partial implementations. They add maintenance burden (any datamodel change potentially affects them) without providing tested functionality.

Options

1. Delete untested compilers — remove AWK, R2RML, SPARQL, SSSOM, SQL. Reduces maintenance surface.
2. Add tests — if these compilers are intended for future use, write basic smoke tests so they don't rot silently.
3. Mark as experimental — move to a separate experimental/ directory with a clear disclaimer.

[github-actions]

Summary & Analysis

Correction: SQLCompiler does have tests

The issue table marks SQLCompiler as ❌ (no tests), but there is an existing test in tests/test_compiler/test_duckdb_compiler.py that exercises SQLCompiler against a live in-memory DuckDB instance (compile → generate DDL → execute). The updated picture:

Compiler	Tests	Implemented?	CLI
GraphvizCompiler	✅	Yes	No
MarkdownCompiler	✅	Yes	Yes
PythonCompiler	✅	Yes	Yes
SQLCompiler	✅ (duckdb test)	Yes — DuckDB-focused, has real logic	No
AWKCompiler	❌	Pure stub — raise NotImplementedError	No
R2RMLCompiler	❌	Pure stub — raise NotImplementedError	No
SPARQLCompiler	❌	Pure stub — raise NotImplementedError	No
SSSOMCompiler	❌	Pure stub — raise NotImplementedError	No

So the real count is 4 pure stubs with no tests and no implementation.

---

What the stubs contain

Each of the four untested compilers is ~13 lines: a class definition and a compile() method that immediately raises NotImplementedError. They share only their docstrings:

• AWKCompiler — "only expected to work for flat schemas"
• R2RMLCompiler — no caveats noted
• SPARQLCompiler — "compiles to SPARQL Construct"
• SSSOMCompiler — "SSSOM has less expressivity so this is expected to be highly lossy"

None of them have any logic beyond the raise. They are not referenced in the CLI or any other module — they are essentially aspirational placeholders.

---

Relevant prior issue

• GraphVis Compiler failure #63 (closed Sept 2025) — GraphvizCompiler had a failing test that was marked xfail. This is now resolved. It illustrates the maintenance risk: even tested compilers can silently break when the data model changes.

---

Strategic context for each stub

AWKCompiler — AWK is useful for flat-file ETL. Given that linkml-map operates on object graphs, AWK is only applicable to very flat schemas. Low priority; the use case is narrow and shrinking.

R2RMLCompiler — R2RML (W3C recommendation) maps relational tables to RDF. This would complement the existing SQLCompiler by enabling a two-stage pipeline (tabular data → SQL transform → R2RML → RDF). Non-trivial to implement well.

SPARQLCompiler — SPARQL CONSTRUCT queries are a natural output for schema-to-schema transforms over RDF graphs. This would be the most semantically rich target but requires the source/target data to be RDF. Potentially valuable in the LinkML/semantic web ecosystem.

SSSOMCompiler — SSSOM (Simple Standard for Sharing Ontology Mappings) is a widely adopted format in the ontology/bioinformatics community. A lossy compilation from linkml-map specs to SSSOM would enable interoperability with OAK, sssom-py, and related tools. This is potentially the highest-value stub given linkml-map's audience, though the docstring correctly notes the expressivity mismatch.

---

Recommendation

Given the CLAUDE.md principle of fail fast and avoiding maintenance burden from untested code, Option 1 (delete) is the most defensible path for code that is entirely NotImplementedError. This doesn't preclude re-adding these compilers later when there's a concrete use case driving them.

If any of the stubs are to be retained, SSSOM has the strongest case given the overlap between the linkml-map user community and SSSOM users. A GitHub issue specifically for a SSSOMCompiler implementation might attract a community contributor.

Option 3 (experimental/) is a reasonable middle ground — it keeps the intent visible without implying these are production features, and reduces the risk that a data model refactor silently breaks them.

The SQLCompiler (test_duckdb_compiler.py) is in decent shape but the test only exercises the INSERT INTO ... SELECT path (not the CREATE TABLE path, i.e., new_table_when_transforming=True). Worth noting for a follow-up test improvement.

[amc-corey-cox]

Investigation notes (2026-04-01)

Current state of untested compilers:

Compiler	Lines	Implementation	Referenced elsewhere
AWKCompiler	13	Pure stub (NotImplementedError)	No
R2RMLCompiler	12	Pure stub	No
SPARQLCompiler	12	Pure stub	No
SSSOMCompiler	13	Pure stub	No
SQLCompiler	139	Real functionality	Yes — DuckDBTransformer, compliance tests, tutorial notebook

SQLCompiler is active and has expansion plans (#150, #151). The other four are empty stubs.

Decision:

• Delete AWKCompiler — no meaningful use case for generating AWK from a TransformationSpecification.
• Keep R2RML, SPARQL, SSSOM stubs for now — these represent real compilation targets in the LinkML ecosystem (RDF mapping, triplestore transforms, mapping metadata). However, the current stubs are not useful starting points — they're just raise NotImplementedError with no structure. Future work should replace them with stubs that actually sketch the compilation strategy (iterate class derivations, emit target-language constructs) so they serve as a scaffolding for contributors.
• SQLCompiler — needs tests, not deletion. Tracked in Expand SQLCompiler to cover more of the TransformationSpecification #150.

The compiler architecture is sound: the TransformationSpecification is an IR that can be projected into different target languages. SchemaMapper, ObjectTransformer, and the compilers are all consumers of the same spec. The stubs should eventually embody that pattern, not just raise NotImplementedError.