ster

Software

Dependencies

   _____ ______ ______ ____
  / ___//_  __// ____// __ \
  \__ \  / /  / __/  / /_/ /
 ___/ / / /  / /___ / _, _/
/____/ /_/  /_____//_/ |_|

  [ Breton: "Meaning" or "Sense" ]
  [  Semantic Knowledge Editor  ]

ster is a terminal editor for semantic knowledge bases. Build and explore SKOS taxonomies and OWL ontologies together in one full-screen TUI — then visualise them as interactive graphs and run SPARQL, all from your terminal. No database required.

ster is the Breton word for meaning, with homonyms for river and star — keep the flow, and follow your star.

The TUI

The heart of ster is a Textual terminal app that shows your SKOS taxonomy and OWL ontology in a single tree:

• One unified tree — concept schemes, concepts, classes, named individuals, and properties side by side. Create, rename, delete, and edit any entity inline; every field is editable in a detail panel.
• Puns (class ⇔ concept) — an entity can be both an OWL class and a SKOS concept. Promote a concept to a class or demote it back with one action.
• Tag individuals with concepts — link named individuals to SKOS concepts (dcterms:subject), one at a time or in bulk from a checklist.
• Live quality & coverage — a semanticlint pass colour-codes each tree node by its worst issue (🔴 error · 🟠 warning); hover for a per-entity issue count, and open the node to see the full list and its label/comment/property-fill coverage.
• Markdown notes — attach rich notes to any entity with a full-screen editor and a live rendered preview; markdown links are URL-checked when you open or edit them.
• Ontology overview — editable title/description; opening a pure-OWL file jumps straight to the overview.
• Bundled demo — a mixed SKOS + OWL sandbox you can load from the file list to try everything out (it resets on each load).

Beyond the tree

Every capability below is reachable from the home menu, acting on the file you selected:

In-browser views

Three views open in the browser from the TUI, on the entity you have selected or on the whole file. Each one refuses to open on a file that has nothing to show, rather than presenting an empty canvas that reads as a bug:

From the SPARQL screen the same views open on the current result — ctrl+g for the map, ctrl+t for the timeline — and the status line says how many rows each one can place before you try.

Ask your AI agent about your ontology

ster exposes a read-only MCP endpoint, so whichever AI agent you already use can answer questions about the ontology you are editing. ster provides the context; you bring your own agent, your own model and your own keys. No AI provider is bundled, and nothing is sent anywhere by ster itself.

The endpoint comes up on its own when you open a file in the TUI (or run ster serve). Point an agent at it once:

claude mcp add --transport http ster http://127.0.0.1:8765/mcp \
  --header "Authorization: Bearer $(cat ~/.config/ster/api_token)"

Any MCP-capable client works the same way — the endpoint is plain JSON-RPC over HTTP, guarded by the same bearer token as the rest of the API.

Grounded queries, any agent. Ontologies differ in vocabulary: labels sit on skos:prefLabel or rdfs:label, hierarchy on skos:broader or rdfs:subClassOf, and the labels may be tagged @fr rather than @en. An agent that assumes wrong writes a query that parses cleanly and returns nothing. ster answers those questions from the file itself via get_vocabulary, and tells every client to ask them first through the MCP instructions field — so this works with any MCP-capable agent, not only the one you happen to use.

Read-only by design. There are no write tools, SPARQL update forms are refused, and the endpoint rejects browser requests from foreign origins (the DNS-rebinding defence the MCP spec requires). An agent can read your ontology and answer questions about it; it cannot change it.

Browse a SPARQL endpoint

No file? Point ster at a triple store (GraphDB, Fuseki, …) and browse, query and draw what it holds, read-only:

ster show --endpoint https://graphdb.example/repositories/arch          # default graph
ster show -e https://graphdb.example/repositories/arch --graph https://example.org/graphs/arch
ster show -e https://graphdb.example/repositories/arch --query my.rq    # your own CONSTRUCT
ster show -e URL --limit 20000 --header 'Authorization: Bearer …'

ster sends one CONSTRUCT and keeps the answer in memory, so it is a snapshot: press R in the viewer to fetch again, and editing is refused (there is no file to save to). --limit caps the triples fetched for the default and named-graph forms (default 100,000, or the last value you chose in the menu), and ster tells you when it was reached. Headers are sent as given and never saved. The same flow is in the file list as Open a SPARQL endpoint.

For scripts and CI, a failure prints one line to stderr, leaves stdout empty and uses ster's exit codes: 2 for a URL, header or option that cannot be sent (a malformed URL, a user:password@ in the URL, a bad --header), 3 when the endpoint cannot be reached or refuses (DNS, refused, an HTTP error with the server's own message, a redirect, a timeout, a dropped connection), 4 when it answers with something that is not RDF. --timeout SECONDS (default 600) bounds both the wait for an answer and the whole transfer. ster never follows a redirect (a header would travel to the new host); the error names the new URL. Credentials and query strings are left out of every message, so pass tokens with --header, never in the URL.

Installation

ster is a CLI app, so the cleanest install is as an isolated uv tool — no virtualenv to manage, ster goes straight on your PATH:

uv tool install ster        # install
uv tool upgrade ster        # update to the latest release
uvx ster                    # or run once, without installing

Prefer pip? That works too:

pip install ster            # install / upgrade with: pip install -U ster

That's everything — TUI editing, graph viewer and SPARQL, no extras required.

Quick start

ster

The home screen lists the ontology and taxonomy files in the current directory (plus a Load demo entry). Pick a file, then choose an action:

  Select a file:
    ☑  my-ontology.ttl
    🎒 Load demo ontology / taxonomy

  ▶  🖥  TTL Viewer-Editor
     🔍 SPARQL Query
     ◈  Load Graph Viewer
     ✕  Quit

Arrow keys navigate; Enter confirms. Inside the tree editor, press ? for the full keymap — the essentials are + add, d delete, e edit, Enter expand/open, Esc back.

Supported formats

Large Files & Performance

For large ontologies or taxonomies (over 100k triples), ster provides several performance boosts out of the box:

• Fast Rust Parsing: ster uses the high-performance Oxigraph engine automatically for near-instant RDF parsing.
• N-Triples Acceleration: Reading .nt files is significantly faster than Turtle for massive datasets. Use ster convert large.ttl large.nt to switch.
• Binary Caching: After the first successful parse, a secure binary cache is created. Subsequent loads are near-instant (typically under 2s for 150MB+ files).

Key dependencies

Development

See CONTRIBUTING.md for the full workflow.

git clone https://github.com/gbelbe/ster.git
cd ster
uv sync --extra dev
bash scripts/install-hooks.sh   # git pre-push hook (once per clone)
bash scripts/ci.sh              # full local gate: lint · types · security · tests · coverage

The local gate mirrors GitHub Actions (ruff · mypy · bandit + pip-audit · pytest on Python 3.12 / 3.13), and a pre-push hook blocks any push without a passing run in the last 24 hours. Coverage is reported to Codecov.

Release notes live in the GitHub releases.

Optional plugins

• ster[semanticlint] enables live ontology-quality checks.
• ster[rdfdiff] enables Semantic History, which reads a tracked RDF file's Git history as additions, modifications, renames, deprecations, and removals.

License

MIT