Diagrams describe the shape of your system. An ontology describes its meaning: the classes, properties, hierarchies, and roles of your domain, expressed in open standards (OWL/RDF/Turtle) that other tools can read. EcosystemCode treats the ontology as a living canonical model—it grows with your UML and database, drives authorization in the app you generate, and exports as a governed Turtle file you can reuse.
This tutorial walks through the ontology lifecycle: import → enhance → export, and shows how ontology roles become enforced permissions in generated code.
Why an ontology, not just a class diagram
A UML class diagram is great for modeling application data, but it is not a portable, standards-based semantic model. An ontology adds:
- Standard identifiers (IRIs) so concepts are stable and shareable across systems.
- Explicit semantics: properties with domain and range, class hierarchies, and role classes.
- Interoperability: OWL/RDF/Turtle exchange with knowledge graphs, governance platforms, and enterprise semantic tooling.
In EcosystemCode, you do not have to choose. You model as usual, and the ontology is maintained alongside your diagrams as one canonical source of truth.
Step 1: Import an existing ontology
If your organization already has an ontology, bring it in. At Quickstart (or on the project) upload an OWL, RDF, or Turtle file. EcosystemCode parses it into a structured semantic model—classes, properties, hierarchies, and role policies—and stores it as the project’s canonical ontology.
Starting fresh? Skip the import. The ontology will be generated and enhanced for you as a by-product of modeling.
Step 2: Enhance from your model
As you design, the ontology is enriched from multiple sources:
- Your UML class diagrams — entities and relationships map into ontology classes and properties.
- Your database import — imported entities and columns enrich the same canonical model.
- Confirmed role mappings — roles you approve are folded back into the model.
Crucially, imported IRIs are preserved and new concepts get stable identifiers, so the model does not drift between runs. See pre-generation validation for catching gaps before you generate.
Step 3: Turn ontology roles into enforced permissions
This is where ontology pays off beyond documentation. Roles identified in the ontology become suggested role mappings. When you confirm them and set the policy mode to enforce, code generation emits:
- a permission manifest derived from the ontology roles,
- authorization middleware in the generated backend, and
- seed users so the running app demonstrates the policy immediately.
Role classes are intentionally kept out of CRUD scaffolding—they model authorization, not data tables—so your generated entities stay clean.
Step 4: Export a governed Turtle model
When you are ready to share or govern the model, export it. EcosystemCode writes a standard Turtle (.ttl) file and runs a round-trip check that verifies classes, properties, semantics, and role policies survive export and re-import. The result is a portable, governed artifact you can:
- commit alongside your code,
- hand to a data governance or knowledge-graph team, and
- re-import later to continue the loop.
A practical workflow
- Import or start fresh — bring an ontology in, or let modeling seed it.
- Model and enhance — design diagrams; let the ontology grow from UML and DB import.
- Confirm roles — review suggested role mappings and switch to enforce.
- Generate — produce a runnable baseline whose authorization comes from your domain model.
- Export — download a governed Turtle file and re-import whenever you iterate.
When this pays off
- Enterprises with existing semantic models keep their ontology aligned with what they actually build.
- Architects get governance and interoperability without a separate authoring effort.
- Teams that care about authorization derive permissions from the domain model instead of hand-wiring roles.
Next steps
- Deep dive: the Ontology & Semantic Modeling feature page.
- Try the product: open the workbench, or watch the demo for a guided tour.