Where you work
- App-managed
- Web app
- Git-managed
- Repository
Choose how your ontology is managed
Git-managed is the recommended default. If the people who will maintain the ontology are not comfortable with git, choose app-managed instead.
| Question | App-managed | Git-managed |
|---|---|---|
| Where you work | Web app | Repository |
| How changes are reviewed | Review the proposed changes in Cassis | Review a pull request |
| How changes go live | Publish in Cassis | Merge; the GitHub App or CI publishes it |
| Best fit | Ontology owners who do not work in git | Teams already comfortable with git |
How changes are reviewed
- App-managed
- Review the proposed changes in Cassis
- Git-managed
- Review a pull request
How changes go live
- App-managed
- Publish in Cassis
- Git-managed
- Merge; the GitHub App or CI publishes it
Best fit
- App-managed
- Ontology owners who do not work in git
- Git-managed
- Teams already comfortable with git
Choose a path
Git gives teams a familiar review history and lets people or coding agents work in a checkout. App-managed keeps the same review and versioning concepts without requiring a repository.
Choose one place to edit. On a git-managed project, make changes in the repository and use Cassis to ask questions, review issues, and inspect what is live. On an app-managed project, make and publish changes in Cassis. Using both editing paths is possible, but parallel changes can overwrite each other.
Switching later
You are not locked in. To move to git, pull the current ontology into a repository and connect it. To move back to the app, disconnect the repository; the ontology already published in Cassis remains available.
For the daily workflows, see Curate in the web app or Curate in a repository.
Cassis on your own warehouse
Running it against your data starts with a conversation about your stack and what you need answered.