---
question: Does disabling an ontology unload the module Turtle?
kind: task
via_web: available
via_cli: na
via_python: na
via_api: available
via_config: available
ref_web: Settings › Ontologies
ref_api: PUT /api/workspaces/{workspace_id}/resource-access/ontologies
ref_config: workspaces[].ontologies
prereq: You need the owner or admin role in the workspace, and an ontology the engine has loaded from a module under `modules:`.
next:
  - /capabilities/build/knowledge-graph/import-an-ontology
  - /capabilities/build/knowledge-graph/creating-an-ontology
---

# Enable in a workspace

The engine loads every module ontology at startup, whether or not a workspace uses it. Each Nexus workspace then keeps its own list of the ontologies it may use: the Ontology screen and its `/api/ontology` routes show only those.

The catalog lists each module `.ttl` under `ontologies/` that declares `a owl:Ontology`. Process slices under `processes/` are not listed: their classes are carried by the module ontology. Enabling a file does not enable the files it `owl:imports`: enable each one.

## Web UI

### Open the ontology list

In the workspace, open Settings, then Ontologies. The page reads "Choose the ontologies available in this workspace." Each row is an ontology, with its module underneath. Only workspace owners and admins can open the list: for anyone else it does not load, and the page shows "Only workspace owners and admins can manage assignments."

### Tick the ontologies

Tick **Enabled** on each row the workspace should use. Search and the **Status** and **Availability** filters narrow the list. A row marked "Unavailable" names a file the engine no longer loads.

![Workspace Settings on Ontologies, enabled ontologies](/abi/Screenshot_Settings_Ontologies.png)

*Settings › Ontologies, filtered to the three enabled for this workspace.*

### Save

Click **Save changes**. The page confirms "Assignments saved."

## CLI

Not applicable. `abi workspace` creates, lists and deletes workspaces and their members; it has no option for ontologies. Use the Web UI or the REST API, or seed the list in `config.yaml` (Config tab).

## Python

Not applicable. The list is a Nexus workspace setting, not an engine service a module can call. From a script, send the REST API request on this page.

## REST API

### Sign in

```bash
curl -s -X POST "http://localhost:9879/api/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"email": "admin@example.com", "password": "'"$NEXUS_PASSWORD"'"}'
```

The response holds `access_token`. Export it as `NEXUS_ACCESS_TOKEN`. The Nexus routes take this login token, not `ABI_API_KEY`. The same sign-in is under [Nexus API options](/user-guide/reference/cli#nexus-api-options).

### Read the current list

```bash
curl -s "http://localhost:9879/api/workspaces/$WORKSPACE_ID/resource-access/ontologies" \
  -H "Authorization: Bearer $NEXUS_ACCESS_TOKEN"
```

`$WORKSPACE_ID` is the workspace id (`ws-...`), which `abi workspace list` prints. Reading the list needs the owner or admin role in the workspace too: anyone else gets 403. The response holds `data` (the enabled ids), `revision`, `updated_by` and `catalog`, the ontologies you can pick from. Catalog ids look like `my_module:mymoduleontology.ttl`.

### Save the new list

```bash
curl -s -X PUT "http://localhost:9879/api/workspaces/$WORKSPACE_ID/resource-access/ontologies" \
  -H "Authorization: Bearer $NEXUS_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"revision": 3, "policy": {"enabled": ["my_module:mymoduleontology.ttl"]}}'
```

Send the `revision` you read. A stale one returns 409: read again, then save. An id that is not in the catalog returns 422. The same owner or admin role applies (403 otherwise).

## Config

### Seed the list

Under the `naas_abi` module, a workspace in `nexus_config.organizations[].workspaces` takes an `ontologies:` list:

```yaml title="config.yaml"
modules:
  - module: naas_abi
    enabled: true
    config:
      nexus_config:
        organizations:
          - name: "Dev"
            slug: "dev"
            owner_email: "admin@example.com"
            workspaces:
              - name: "Default"
                slug: "default"
                owner_email: "admin@example.com"
                ontologies:
                  - "my_module:mymoduleontology.ttl"
```

An entry is `module:filename.ttl`, the file name alone, or its path. The list is exclusive: listed files are on, the others off. A missing or empty list shows none.

### Restart the engine

Nexus stores the seed the first time it reads the workspace's list. From then on the stored list wins: changing `ontologies:` in `config.yaml` does not change a workspace whose list is already stored. Use the seed for new workspaces, and the Web UI or the REST API after that.