Skip to content

area_ontology

The back-office area that edits Dédalo's own ontology tree — the same tree-editing machinery as area_thesaurus, retargeted at the ontology hierarchy. Superuser, or a global admin granted it in their profile.

See also: area_thesaurus · area · Ontology · TS tree / ts_object · Architecture overview

This page assumes you have read area_thesaurus: area_ontology is the same tree area pointed at a different hierarchy, and the two share one implementation. For the conceptual model of what an area is, read area first.

Superuser or granted global admin, fail-closed

area_ontology opens for the superuser (DEDALO_SUPERUSER), or for a global admin whose profile grants the area (dd5, read or higher). Both conditions are needed: a global admin without the grant is refused, and so is a non-admin with it. One rule, canAccessOntologyArea (src/core/security/permissions.ts), serves both doors, and it runs before any ontology read:

  • dispatchAreaRead (src/core/area/read.ts) refuses with 403 — checked both when the request declares the area_ontology model and when its source.tipo is the ontology area tipo (dd5).
  • The menu walk (src/core/api/handlers/menu.ts) leaves the dd5 node out of the menu of anyone the rule refuses.

Inside the area there is no admin bypass: each ontology hierarchy (the TLD section, e.g. dd0, rsc0) is served only when the profile grants read on it, and every section and field answers the ordinary profile permissions. Editing the ontology rewrites the active schema of the whole installation — grant it per TLD, deliberately.

Role

area_ontology is the ontology model of the Ontology editing area. Functionally it is the same hierarchical tree editor as the Thesaurus area, but pointed at a different hierarchy: instead of editing curatorial thesauri (the hierarchy* family stored in matrix_hierarchy_main), it edits Dédalo's own ontology — the nodes that define sections, components, areas and tools — stored in the ontology* family in matrix_ontology_main.

Like every area it holds no records of its own: it has a tipo but no section_id and no matrix row. Its tree behavior means a read serves the hierarchy boot payload the client's tree widget renders, not a dashboard.

One implementation, two areas

The single most important fact about this area: it is the same machinery as area_thesaurus, differentiated by an argument, not by parallel code.

readAreaHierarchyData (src/core/area/tree.ts) is one function that takes the area model as its first argument and branches on it. There is no area_ontology-specific resolver:

concept area_ontology area_thesaurus
hierarchy section tipo ontology35 hierarchy1
main table matrix_ontology_main matrix_hierarchy_main
children component tipo fixed ontology14 resolved per target section (its component_relation_children)
typology section id fixed 14 resolved per hierarchy record
per-hierarchy permission read on the TLD section (target_section_tipo) read on the target section and on each root term's section
active_in_thesaurus skip not applied — inactive hierarchies are kept applied
"no root terms" skip not applied — rootless hierarchies are kept applied

The ontology area keeps entries a thesaurus would skip because an ontology hierarchy must always be reachable for editing, even when it is not published.

The tree nodes themselves are built by the ts_object stack — the ontology is just another hierarchy of parent/children relations, walked through component_relation_parent / component_relation_children.

Model view

The client can ask for the model view by sending source.build_options.terms_are_model = true. readTreeArea (src/core/area/read.ts) passes it through to readAreaHierarchyData, which then reads the model-view root terms instead of the ordinary ones. In that mode the tree line displays each node's model, which is what makes the ontology readable as a schema rather than as a vocabulary.

The model badge (Ctrl+M)

Independently of the model view, every ontology tree line whose term declares a model carries an M button, and the server attaches that model's name to it (model_value — see ts_object). The client renders it as a small orange badge to the right of the M:

Processes [dd35] + M area_tool ▸

The badge is hidden by default and toggles with Ctrl+M, anywhere in the tree area. The state persists per browser in the local DB status store (show_models), so it survives a reload. The same shortcut works in area_thesaurus, where hierarchy lines carry the typology instead.

Reading the area

There is nothing to instantiate. A read is dispatched off (model, tipo), the access gate runs, and the shared resolver builds the payload:

// src/core/area/read.ts — dispatchAreaRead refuses with 403 here unless
// canAccessOntologyArea(principal), before any ontology read happens.
const item = await readAreaHierarchyData('area_ontology', 'dd5', 'lg-spa', termsAreModel);

The dispatcher also validates the request: if source.model and the real ontology model of source.tipo disagree, the read is refused with 400. An unvalidated client string cannot choose a server code path.

The response is the standard area envelope — {context, data} — where data[0] carries the active hierarchies, their root terms and the typologies. See area_thesaurus for the payload shape in full.

How it fits with the rest of Dédalo

  • area_thesaurus — the sibling tree area and the same implementation. Read it for the payload and the search path.
  • Ontology — the data this area edits: the active schema (sections, components, areas, tools) stored in matrix_ontology_main. This area is the back-office UI over that tree.
  • TS tree / ts_object — the node builder, repository and term resolver that turn parent/children relations into renderable tree nodes.
  • Sections / Components — the record-bearing leaves the ontology defines. Editing an ontology node in this area changes how those sections and components behave at runtime, with no code change.
  • Menu — area_ontology is a root menu area, shown only to the superuser and to global admins whose profile grants it.

Extend the shared machine, not this area

area_ontology deliberately carries no logic of its own. Before adding behavior "for the ontology area", check whether it belongs in the shared resolver (src/core/area/tree.ts) behind its existing model branch — the two tree areas are intentionally kept as one machine.