Skip to main content

Ontology Releases

Editing an ontology doesn’t change what other users see. Edits collect as unpublished changes on the working Draft. Publishing turns them into a release: a frozen, numbered snapshot that can’t change afterward. Only one release is Active at a time. The active release is what users without edit permission read and query, and what the knowledge graph uses. How a release goes live depends on whether the ontology has reviewers:
  • No reviewers: An author or owner clicks Publish, and the release goes live immediately. The release is recorded as published without review.
  • One or more reviewers: The author clicks Request review. Reviewers approve or reject the release in the Tasks drawer. After approval, an author or owner clicks Publish to make the release live.
Set reviewers when you create the ontology or in its settings.

Open the Review & Publish Dialog

Click Publish in the Studio header. The number in parentheses, as in Publish (15), shows how many changes are waiting.
  • With one ontology selected, Publish opens the Review & publish dialog for that ontology.
  • With All ontologies selected, the button reads Review & publish and is disabled. Choose an ontology first.
The dialog also opens from Review & publish on the ontology’s Overview tab. The dialog has two tabs: Changes and Releases. The header shows the version path, for example from Draft to v0.1.0.

The Changes Tab

The Changes tab lists the unpublished changes and is where you publish a release or request a review. Review and publish dialog on the Changes tab, showing the change list, the Validation and Version panels, and the Publish button

Review the Changes

The summary line, for example “14 changes: 8 concepts, 6 rules”, shows how much changed. Below it:
  • Search changes: Filters the list by name.
  • All, Added, Changed, and Removed: Filter by type of change. Each shows its count.
  • Change cards: Changes are grouped under Concepts, Properties, Relationships, Rules, and Ontology settings. Each row shows the item, for example “Class Clinical Record · 0 properties”, and whether it was Added, Changed, or Removed.
  • Previous and Next: Page through the list.

Check Validation

The Validation panel checks the working draft before any release is captured:
  • Structural validation: Whether the ontology is well formed. It reads Passed or Failed. A failure blocks publishing, with the message “Fix these to publish.”
  • Logical consistency: Not checked. Studio checks that the ontology is well formed, but it doesn’t prove that the rules are free of contradictions.
For a captured release, the panel also shows:
  • SHACL validation: The number of violations and warnings found by the built-in ontology shapes. This check doesn’t need a triple store.
  • Deprecation impact: The bound assets, subclasses, and properties that still use a deprecated concept.

Choose a Version

The Version panel offers three increments. It shows the resulting number next to each choice. Studio preselects an increment from your changes: removals suggest Major, additions suggest Minor, and edits suggest Patch. Choose a different one if needed. Studio bases the new version on the active release. For the first release, Minor is preselected and gives v0.1.0. A note explains that v0.1.0 starts the unstable 0.x line, and that Major gives v1.0.0 as the stable release.

Set Reviewers

The Reviewers panel lists the people who will review the release. It appears when the ontology has reviewers. Reviewers panel showing the reviewer list, the Add reviewer search, the Approval rule menu, the Release notes field, and the Request review button
  • Reviewers: The current reviewers appear as chips. Click the x on a chip to remove one.
  • Add reviewer: Search for a user or team to add.
  • Approval rule: Choose how many reviewers must approve.
    • Any one: One approval is enough.
    • All: Every reviewer must approve.
Reviewers and the approval rule are locked while a review is open. The panel then reads “Reviewers and approval rule are locked by review .” If you are the only reviewer, Request review is disabled with the message “You are the only reviewer. Add another reviewer, or remove yourself to publish without review.”

Add Release Notes

Use Release notes to explain what changed, up to 16,384 characters. The notes are kept with the release.

Publish or Request Review

The footer shows the version path and the number of changes, for example “Draft → v0.1.0 · 14 changes”, with a status message. Which buttons you see depends on the ontology’s reviewers and the state of the release. Save as release draft is available in each case. It saves the version as a release in Draft status without publishing or requesting review. If nothing changed since the saved draft, Studio tells you it is the same draft. Withdrawing a request returns the release to Draft.

The Tasks Drawer

Review requests appear in the Tasks drawer. Click Tasks in the Studio header to open it. The badge shows your open tasks. Tasks drawer showing the Assigned to me and Created by me tabs, a review task with release details, the change list, and a comment box The drawer has two tabs:
  • Assigned to me: Review requests where you are a reviewer.
  • Created by me: Review requests you submitted.
Use Search tasks to filter either list. Click a task to open its details:
  • Task header: The review status, the task ID such as TASK-01218, the ontology name, and who requested the review and when.
  • Release summary: The release type, version, number of changes, and review status.
  • People and dates: The Assignee with their status, Created by, Opened on, and Last activity.
  • Changes: The same searchable change list as in the Changes tab.
  • Comments: A comment thread. Type in Leave a comment… and send.
If you are a reviewer on an open task, you also see the decision buttons:
  • Approve: Records your approval. With the approval rule set to All, the release is approved when every reviewer approves.
  • Approve & publish: Appears when you are also allowed to publish. It approves the release and makes it active in one step.
  • Reject: Asks for a reason, then returns the release to the author with the reviewer’s reason.
On the ontology canvas, banners keep everyone informed. Reviewers see Review now, and authors see View task and the number of reviews in progress. When a reviewer rejects a release, the author sees ” rejected : .” Edit the ontology, then click Request review again.

The Releases Tab

The Releases tab lists every release of the ontology, newest first. Releases tab listing versions with Active, Latest, Approved, and In Review statuses and an Export menu on each row The header shows the number of releases, as in Releases (5). The toolbar has:
  • Filters: All, Published, In review, Draft, and Rejected, each with its count. Rejected lists releases where a reviewer asked for changes.
  • Search Releases: Filters by version or name.
  • Compare versions: Choose a From version and a To version to see what changed between two releases.
Each row shows:
  • The version, for example 1.5.0.
  • Badges for Active and Latest, and the release status.
  • A summary of the changes, or “Change count unavailable for this release.” for releases created before change counts were recorded.
  • Who created the release and when.
  • Who approved it, for example “Approved by ram.balaji”.
  • An Export menu for that release.
The footer shows the state of the release you are working on, with a link to its open task, for example Open task · TASK-01218.

Release Statuses

A release moves through the following statuses.

Release Details

Click a release to see its details. Release details for v1.5.0 showing the Approved and Active badges, an Export menu, the release events, and the list of rule changes
  • Version and badges: The version with its status, for example Approved and Active.
  • Export: Download the release. For more information, see Export a Release.
  • Approval: A link to the release’s review task.
  • Release events: A log of what happened to the release, with who did it and when. Events include Captured, Review requested, Review withdrawn, Approved, Rejected, and Activated. Approved events list the reviewers.
  • Changes: The items in the release, grouped by type, with a before and after view of each item’s definition.

Activate and Roll Back

Publishing a release makes it the active one. To go back to an earlier version, open an older Approved release and click Activate release, or click Roll back to , and confirm. The newer releases stay in the list and can be activated again. Activation queues an update to the RDF knowledge graph in the background.

Export a Release

Every row in the Releases tab has an Export menu, to download any release, not only the active one. Export menu on a release row offering Turtle, RDF/XML, N-Triples, SKOS / Turtle, CSV, and JSON-LD To export the working draft, to run SHACL checks before you download, or to import a file, use Import & Export.

Permissions

The following permissions apply to releases. If you lack the role, Studio shows “You need the OntologyAuthor role to capture or publish a release. An admin can grant it.” For more information, see Ontologies.

Requirements

An ontology with reviewers needs a deployed approval workflow with a user approval step. If the workflow is missing or suspended, Studio can’t submit a release for review. An ontology with no reviewers publishes directly and doesn’t need the workflow.

REST Endpoints

Paths start with /api. For the full reference, see the Ontology API Reference.