Integrate ENERO Foundry ontologies into Semantic-SQL

[cmungall]

Summary

Add first-class support for ENERO Foundry ontologies in Semantic-SQL so they can be built and downloaded the same way we handle other non-OBO ontologies.

The ENERO Foundry is positioning itself as a coordination layer for interoperable energy-domain ontologies, with early ontologies including OEO, CEPO, MENO, MUNO, OTO, and CHIO. Semantic-SQL already has a partial oeo entry in src/semsql/builder/registry/ontologies.yaml, but the broader ENERO set is not yet modeled here in a consistent way.

Why

• Energy ontologies are increasingly relevant for FAIR research data workflows.
• ENERO is explicitly trying to make these ontologies interoperable, which aligns well with SemSQL's SQL view layer over OWL/RDF.
• The repo already supports a curated registry of non-OBO ontologies, so ENERO onboarding fits the existing architecture.

Proposed scope

• Audit candidate ENERO ontologies for stable release URLs, serialization, imports, and licensing.
• Decide which ontologies should be added to src/semsql/builder/registry/ontologies.yaml.
• Add registry entries, prefixmaps, and any necessary build_command overrides.
• Validate that each selected ontology can be turned into a working SemSQL SQLite build.
• Add focused tests or documented smoke-test commands for the new entries.
• Update user-facing docs so the new ontology IDs are discoverable.

Candidate ontologies

• oeo (already present, likely needs validation/refresh)
• cepo
• meno
• muno
• oto
• chio

Open questions

• Which ENERO ontologies publish stable machine-readable release artifacts today?
• Do any require non-default preprocessing before rdftab / relation-graph?
• Should we stage this as oeo hardening first, then add the rest incrementally?
• Are there any energy-adjacent artifacts we should explicitly exclude because they are not OWL reference ontologies in the SemSQL sense?

Acceptance criteria

• At least one additional ENERO ontology beyond oeo is integrated end-to-end in the registry.
• The oeo entry is verified or corrected against the current upstream release layout.
• New entries are documented and reproducible from a clean checkout.