​

Author — Edit Mode

Edit mode turns the studio into an authoring workspace. It has two surfaces: Graph, for direct manipulation of concepts and relations, and Model, a workbench of structured modeling tools. Edit mode appears only if you hold EditAll, EditGlossaryTerms, or EditEntityRelationship on Glossary — or you are an admin.

​

The Editing Lease

Ontology edits are structural: one person retyping a relation while another deletes its target produces a model neither of them intended. OpenMetadata guards this with a lease rather than a lock you can forget to release.

• Entering Edit mode acquires a lease on the selected glossary.
• The lease is short — the UI takes 60 seconds and renews it on a heartbeat while you are working. The server accepts leases between 10 and 300 seconds.
• The lease status is shown in the sub-mode bar with a retry action.
• If someone else holds the lease you can still read the model; you cannot write to it.
• Abandoning the tab lets the lease expire on its own, leaving no stuck lock to clear.

API: POST /api/v1/ontologyEditLocks/acquire, PUT /api/v1/ontologyEditLocks/renew, GET|DELETE /api/v1/ontologyEditLocks/{resourceType}/{resourceId}.

​

Graph Authoring

With the lease held, the graph canvas becomes editable and the sub-mode bar gains an Add Concept action plus an Edit · Active lease indicator. Each concept node grows a + handle you drag to draw a relation.

• Add concept — new concepts are created in the glossary you have selected.
• Draw a relation — connect two concepts and pick the relationship type. Cross-glossary edges are only offered for types where crossGlossaryAllowed is set.
• Retype or remove a relation — select an edge and change its type or delete it.
• Inspect and edit — the authoring inspector edits everything that hangs off a concept.

​

The Authoring Inspector

​

Delete with an Impact Preview

Deleting a concept in an ontology is not like deleting a row. Children have to go somewhere, typed relations disappear, external crosswalks break, and assets lose their semantic anchor. Selecting Delete opens an impact preview before anything happens, showing:

• Children — immediate child concepts that must be reassigned, or explicitly cascaded.
• Relationships — every typed relation that would be removed.
• Bound assets — assets currently carrying the concept, with a total count and a flag when the sample is truncated (the preview shows up to 100).
• Mappings — external crosswalks that would be lost.
• Whether the resulting projection needs SHACL revalidation.

The preview is version-bound: it is generated against a specific version of the concept and carries a short-lived signed token (valid for two minutes) tied to both you and that exact snapshot. If the concept changes underneath you, the token no longer applies and you get a fresh preview instead of applying a stale decision. API: GET /api/v1/ontology/impacts/glossaryTerms/{id}/delete to preview, POST the same path with the token to apply.

​

The Model Workbench

Edit → Model is a set of structured tools for changes that are awkward to make node-by-node. Five tabs:

​

Concept IRI

Preview the IRI a new concept will receive under the glossary’s current baseIri and minting pattern before creating it. Placeholders are {glossary}, {term}, and {uuid}. API: POST /api/v1/ontology/modeling/iris/preview.

​

Template — Modeling Patterns

Instantiate a known-good sub-model instead of hand-drawing it. Three patterns ship today: You supply names for each role; the pattern is materialized as a draft change set for review rather than applied directly. API: GET /api/v1/ontology/patterns, POST /api/v1/ontology/patterns/instantiate.

​

Include — Subsets

Build a scoped application ontology from a canonical one. Pin the source concepts a project needs, optionally pull in descendants and relationships, and OpenMetadata produces a draft change set that creates them in the target glossary. Each materialized concept records its provenance: source glossary and term, the exact versions they were pinned at, the source IRI for exact-match traceability, and whether the modeler selected it directly or it came along as a descendant. That is what lets you answer “which version of the canonical model is this project actually built on” months later. API: POST /api/v1/ontology/subsets.

​

Merge — Structural Diff and Merge

Compare two ontology structures and reconcile them. The panel previews changes per concept — name, description, parent, entity status, relationships, mappings, custom properties — labels each as changed or unchanged, and offers conflict resolution before producing a draft change set. API: POST /api/v1/ontology/structure/diff, POST /api/v1/ontology/structure/merge.

​

Ontology Constraints — Axioms

Author OWL axioms with a structured class-expression editor: pick the constraint type, build the subject and target expressions, and Validate before saving. The type dropdown uses plain-language labels for the OWL axiom types: Class expressions compose named classes, intersections, unions, enumerations, and restrictions (SOME, ONLY, VALUE, MIN, MAX, EXACT). With RDF_STRICT_OWL_PROFILE enabled — the default — axioms outside the supported OWL 2 DL profile are rejected with an explanation. Axioms are versioned entities in their own right, with owners, reviewers, and history. API: GET|POST|PUT|PATCH|DELETE /api/v1/ontologyAxioms, POST /api/v1/ontologyAxioms/validate.

​

Change Sets

Patterns, subsets, and merges all produce an ontology change set — a durable authoring session containing typed, reversible operations. Operations are typed rather than free-form patches: CREATE_TERM, UPDATE_TERM, DELETE_TERM, ADD_RELATIONSHIP, UPDATE_RELATIONSHIP, DELETE_RELATIONSHIP, UPSERT_ATTRIBUTE, DELETE_ATTRIBUTE, UPSERT_MAPPING, DELETE_MAPPING, UPSERT_AXIOM, DELETE_AXIOM. Each operation that touches an existing entity carries a baseVersion for optimistic concurrency: if the target moved since the draft was built, application fails loudly instead of silently overwriting. An undoCursor tracks the undo/redo position, so a draft is genuinely reviewable — you can walk it backwards before deciding. API: POST /api/v1/ontologyChangeSets, then /{id}/operations, /{id}/undo, /{id}/redo, /{id}/submit, /{id}/apply, /{id}/discard.

​

Bulk Operations

Changes too large to make interactively — retyping every relatedTo edge in a glossary, find-and-replace across concept descriptions, mass attribute upserts — go through an asynchronous bulk API: Bulk submissions are planned and validated before execution, and can be run as a dry run that produces a full report without persisting anything. Like the workbench tools, they can land as a draft change set for review.

​

Next