Skip to content

Glossary

A developer-oriented glossary of Dédalo-specific terms. Dédalo abandoned the standard SQL schema in v4 and built its own NoSQL-over-JSONB model driven by an active ontology, so most of the words below mean something different from their SQL homonyms. Each entry gives the closest SQL / standard equivalent (when one exists), a short definition, and cross-links to the relevant documentation and to related glossary terms.

The seed of this glossary is the nomenclature table in the Introduction. Terms are listed alphabetically; codes such as dd151 are filed under D, and acronyms under their first letter.

Notation

Ontology codes (oh1, rsc197, dd151…) are tipos. A live definition for any tipo can be inspected at https://dedalo.dev/ontology/<tipo> (e.g. oh1).

A

area

SQL equivalent: a top-level grouping / database schema namespace (no direct SQL analogue).

A group of related sections sitting at the top of the ontology hierarchy; areas are what appear in the main menu. Example: an Intangible Heritage area containing the Oral History and Intangible Cultural Assets sections. Working areas also drive editors — area_thesaurus and area_ontology are areas. See: Introduction. Related: section, ontology, area_thesaurus.

area_thesaurus

No SQL equivalent.

The working area that renders and edits thesaurus trees — hierarchies under the hierarchy TLD and any project thesaurus (ts1, es1, on1…). area_ontology (the editor of Dédalo's own ontology) is the same machinery, an alias differentiated only by runtime flags (is_ontology, area_model). See: Thesaurus and Ontology tree. Related: hierarchy / thesaurus, ts_object, node, TLD.

C

component

SQL equivalent: a column / field (with format and logic).

A field with managed data of a specific type, living inside a section. Because the matrix table has no real columns, components supply the column concept: each component resolves its value through the ontology and renders through client views. Server-side, a per-model descriptor (src/core/components/component_xxx/descriptor.ts) declares each component's behavior; descriptors are gathered by src/core/components/registry.ts and dispatched by the horizontal resolve/relations/save engines — there is no per-component class or controller file. See: Components, Introduction. Related: section, component_tipo, model, matrix (table).

component_tipo

SQL equivalent: a specific column.

A unique definition of a column in the ontology — the tipo of one component (e.g. rsc85 = person Name). Distinguished from tipo (any node) and section_tipo (a section node). See: Introduction. Related: tipo, component, from_component_tipo.

context

No SQL equivalent (the JSON-API description layer).

The small piece of the ontology that describes an element (section, component, tool…): its tipo, model, mode, lang, label, properties, permissions, tools, request_config, view. Context is used to build and instantiate or modify an element. In the JSON-API contract the transmitted unit is a {context, data} pair (a datum); context carries the description, never the values. See: dd_object, Introduction; skill dedalo-context-data-layers. Related: subcontext, data, datum, DDO (dd_object).

D

data

SQL equivalent: the cell payload (the value plus its envelope).

The data container of a component or element: the stored value plus optional companions such as the datalist (option list) or value fallbacks. Sits opposite context in the {context, data} datum. Note the difference from the raw JSONB storage of a matrix row — a single legacy datos column, or the v7 typed columns (string, number, relation, …) — which holds all of the record's data. v7 settled the vocabulary on data (not the v6 term dato): raw stored data, resolved value, transport datum.data — see the data model. See: Introduction, data model; skill dedalo-context-data-layers. Related: value item, value, datum, subdata, datalist, context.

datalist

SQL equivalent: the candidate rows of a foreign-key SELECT (the option list).

The list of selectable options/autocomplete suggestions a component offers (for select, check_box, radio_button and relation-based components). It travels inside data, is resolved from the target component's get_list_of_values() and served through relation_list, and is cached. See: component_portal; skill dedalo-datalist-resolution. Related: data, relation, value.

datum

SQL equivalent: a single resolved field result.

The transmitted unit of the JSON API: one {context, data} object describing and carrying one element's result. A component returns a datum; a portal appends the target components' datums and merges their context. Plural usage: datums. Companion resolved values pulled in for related records arrive as subdata via get_subdatum(). See: component_portal; skill dedalo-context-data-layers. Related: data, context, subdata.

dataframe

SQL equivalent: a side-table of per-cell annotations keyed to a row's array index.

A Dédalo v7 mechanism that pairs frame records (uncertainty, qualifiers, context) with the individual data items of a main component, via the unified id_key contract. Dataframe locators are positively marked with type = dd490 (DEDALO_RELATION_TYPE_DATAFRAME). See: component_dataframe; skill dedalo-dataframe. Related: locator, relation, component.

dd151

SQL equivalent: a foreign-key relation flavor.

The ontology tipo for the link relation type (DEDALO_RELATION_TYPE_LINK), the default kind of pointer a locator carries in its type. It is one of the relation tipos stamped on the relation JSONB column. Siblings: dd48 children (DEDALO_RELATION_TYPE_CHILDREN_TIPO), dd47 parent (..._PARENT_TIPO), dd96 index (..._INDEX_TIPO), dd98 model (..._MODEL_TIPO), dd675 filter, dd490 dataframe, dd89/dd620/dd467/dd621 related (uni-/bi-/multi-directional). These are declared where needed, split across src/core/ontology/ontology_tipos.ts (RELATION_TYPE_LINK/_PARENT/_CHILDREN/_INDEX), src/core/relations/related.ts (RELATED_UNIDIRECTIONAL/_BIDIRECTIONAL/_MULTIDIRECTIONAL) and src/core/concepts/subdatum.ts (DATAFRAME_RELATION_TYPE) — there is no single central constants file. See: locator. Related: locator, relation, relations array, dataframe.

dd_date

SQL equivalent: a normalized date/time literal (richer than SQL DATE).

A normalized Dédalo object representing dates, able to express ranges, periods, calendars and uncertainty beyond a single SQL date. It is the value of a value item in the date typed column, produced by component_date. See: Date values (data model), Introduction. Related: value item, DDO (dd_object), ts_object, dd_grid.

dd_grid

SQL equivalent: a flat result set / pivoted view with rows and columns.

A normalized Dédalo object that represents a table of rows and columns; dd_grid resolves data relations and flattens them into a table of plain data (used heavily by export). See: Introduction, Exporting data; skill dedalo-export. Related: DDO (dd_object), matrix (table), subdata.

DDO (dd_object)

No SQL equivalent.

The Dédalo Data Object — a normalized, extensible object that calls and modifies ontology nodes (it is not a node itself). One ddo is a configuration specific to the node it represents: it defines order, view, mode, permissions, properties, css and so on. ddos are assembled into ddo_map layouts (show/search/choose/hide) inside an RQO and let callers change section/component behavior on the fly. See: dd_object. Related: context, RQO, request_config, model, view.

descriptor

See properties / descriptor (ontology properties) and hierarchy / thesaurus for the thesaurus sense (a descriptor is a preferred term; a non-descriptor/ND is a synonym or variant).

diffusion

SQL equivalent: an ETL/publishing pipeline to a classic SQL schema.

The publication side of Dédalo: the system that publishes curated work data to SQL / RDF / XML / Markdown / CSV / JSON targets for public consumption. The publication database (MariaDB/MySQL by default) uses a classic columnar SQL schema, written only by the diffusion engine built into the work server — publishing runs as durable jobs, driven by the diffusion ontology. See: Diffusion (system overview), The diffusion engine. Related: work system vs publication system, ontology.

F

from_component_tipo

SQL equivalent: the source/owning column of a foreign key.

A locator property naming the source component that stores the locator (the caller side of the relation), prefixed from_. Companions: from_section_tipo and from_section_id identify the source section/record. In a thesaurus parent locator, for instance, from_component_tipo is hierarchy36 (the component_relation_parent tipo). See: Locator → Properties. Related: locator, component_tipo, relation.

H

hierarchy / thesaurus

SQL equivalent: a self-referencing parent/child taxonomy table.

A controlled vocabulary modeled as a hierarchical tree of terms (toponymy, onomastic, thematic thesauri, material/technique taxonomies, typology catalogues). A hierarchy is a record of section hierarchy1 (DEDALO_HIERARCHY_SECTION_TIPO) describing one tree; a term is an ordinary section record inside a thesaurus section (e.g. es1_42). Hierarchy is stored bottom-up: each term keeps one parent locator (type = dd47), and children are always computed by searching for that pointer. See: Thesaurus and Ontology tree. Related: area_thesaurus, ts_object, node, TLD, properties / descriptor.

I

id

SQL equivalent: the table primary key.

The unique row id of a matrix table — unique across the whole table, which holds many sections at once. It is therefore distinct from section_id, which is unique only within one section_tipo. The homonymy is exactly why Dédalo keeps both names. See: Introduction. Related: section_id, matrix (table), section_tipo.

L

lg-nolan

SQL equivalent: a non-translatable / locale-neutral column value.

The reserved "no language" language code (DEDALO_DATA_NOLAN, value lg-nolan) used to store data that is not translatable — codes, technical literals, root, internal values — so the value lives outside any real language slot (lg-eng, lg-spa…). There is no named config constant for it — 'lg-nolan' is used directly as a literal (e.g. src/core/section/read.ts, src/core/section/record/*.ts). Related: translatable / lg-nolan / transliterate, value.

locator

SQL equivalent: a foreign-key relation (a pointer between rows).

The object Dédalo uses to connect data — a relative, multi-reference, directional pointer. The minimal form is {section_id, section_tipo}; it can also target a component (component_tipo) or a tag (tag_id), and names its source with the from_ prefix. The type property carries the relation flavor (e.g. dd151 link, dd47 parent). A flat string form (component_tipo_section_tipo_section_id, e.g. rsc29_rsc170_3) is used as media filenames. A locator is the value item of every relation component, stored in the relation typed column. See: Locator, data model — relations. Related: value item, relation, from_component_tipo, dd151, relations array, datalist.

M

matrix (table)

SQL equivalent: a single physical table standing in for ~1100 logical tables.

The PostgreSQL table where Dédalo stores most data, with only four columns: id, section_id, section_tipo and datos (a JSONB column holding the whole record). There are a few sibling matrix tables sharing this schema (matrix_hierarchy, matrix_users, matrix_dataframe, matrix_activities…), plus per-type JSONB typed columns (data, string, relation, iri, number, date, geo, media, misc, relation_search, meta) that hold each data shape. The meta column keeps the per-component id counters that mint stable value item ids. A full schema can hold ~1100 sections / ~16,000 components in these few tables. See: Introduction, data model, Locator → Function and structure. Related: section, section_tipo, id, section_id, data, value item.

mode (edit / list / search / tm)

SQL equivalent: the request/view mode (no direct analogue).

How an element is configured for the current request. Core values: edit (single-record editing), list (tabular multi-record), search (build a query), tm (time machine — address a specific matrix row / history). Mode drives which components show, default pagination, and which client view files (yyy segment of view_yyy_*) load. See: RQO, request_config. Related: view, DDO (dd_object), RQO, request_config.

model

SQL equivalent: the column/table data type (the typology).

A node's typology — the unique definition that says what a node is and which logic it runs. section is a model; component_input_text, component_portal, button_new are models. A tipo has exactly one model: oh1 → section, rsc85 → component_input_text. (In a DDO, type is the broad family — section/component/button — while model is the specific one.) See: Introduction, Ontology. Related: tipo, node, component, DDO (dd_object).

N

node

SQL equivalent: a schema-definition row (table/column DDL entry).

A single entry in the ontology hierarchy: a definition (or instance) identified by a tipo and classified by a model. Nodes nest like thesaurus terms (parent / children / related) and carry translations and properties. Sections, components, tools, areas, buttons are all nodes. DDOs point at nodes; they are not nodes themselves. See: Ontology. Related: model, tipo, ontology, DDO (dd_object), hierarchy / thesaurus.

O

ontology

SQL equivalent: the database schema — but active, not passive.

The live, dynamic definition of Dédalo's behavior and schema: it defines tables (sections), columns (components), relations, tools, data formats and more. It is consulted at execution time, so editing the ontology changes Dédalo's behavior in real time (within limits) without touching code or the database schema. Organized by TLD and identified by tipo; its interface is a thesaurus-style hierarchy. See: Ontology, Introduction. Related: TLD, tipo, node, model, area_thesaurus.

P

permissions

SQL equivalent: row/column GRANT level.

The access level of a DDO, an integer (0 none, 1 read-only, 2 read/write). It defaults to the current user's permissions and can be reduced per node (to hide it or make it read-only) but never raised above the user's actual level. See: dd_object. Related: DDO (dd_object), mode, request_config.

properties / descriptor

SQL equivalent: column metadata / DDL attributes.

properties is the ontology configuration object attached to a node and surfaced on its DDO: data defaults, source/relation config, css, search behavior, etc. The v7 convention is properties (never the v6 propiedades). A node's properties->source->request_config is what the request_config v6 builder parses. (For the thesaurus sense of descriptor — a preferred term vs a non-descriptor/ND — see hierarchy / thesaurus.) See: dd_object, request_config; skill dedalo-request-config. Related: request_config, DDO (dd_object), node.

R

Raspa score

No SQL equivalent (a data-quality metric).

The Raspa Data Quality Score, Dédalo's cumulative 0–10 metric for evaluating cultural-heritage data across progressive levels of computational readiness, semantic richness and ethical transparency (e.g. L1 structured, L2 ontologically modeled, L4 traceable, L7 translatable, L10 fully FOSS-processed), with an extra point for sustainable data. It has a technical and a community/social dimension. See: The Raspa Data Quality Score. Related: ontology, diffusion, translatable / lg-nolan / transliterate.

relation (bidirectional / unidirectional)

SQL equivalent: a foreign key — one-way or mutually maintained.

A connection between records, materialized as one or more locators whose type carries the flavor. A unidirectional relation points only one way (the source stores the locator); a bidirectional relation is mirrored on both records so each knows the other; a multidirectional relation links several. The related-relation tipos: dd620 unidirectional, dd467 bidirectional, dd621 multidirectional (also dd89 related, dd151 link, dd47/dd48 parent/children). All relation locators are stored in the relation typed column, keyed by component tipo. See: Locator, data model — relations. Related: locator, dd151, relations array, from_component_tipo.

relations array

SQL equivalent: a join/junction table for one record (inline).

The relations container of a section record: a flat array of all the locators that record participates in. It is the section-level index of relationships, kept alongside the components' own data. Distinct from the relation typed column (the per-component locator store keyed by component tipo, from which a section-level index could be assembled). The write path (src/core/section/record/save_component.ts, src/core/relations/save.ts) writes only the per-component relation typed column; it does not maintain a section-level aggregate — inverse/related lookups instead compute on demand via src/core/search/search_related.ts (findInverseReferences). See: Locator, data model — relations. Related: locator, relation, section, matrix (table).

request_config

No direct SQL equivalent (a layout/retrieval configuration layer).

The system that defines how sections and components retrieve and display data — what fields/columns, how to search, where the data comes from, which elements show or hide. It bridges ontology properties with API requests through a trait-based orchestrator (get_ar_request_config()), preferring the v6 builder (properties->source->request_config) and falling back to v5 relation_nodes. Carried on a DDO and inside the RQO. See: Request Config Architecture, examples; skill dedalo-request-config. Related: DDO (dd_object), RQO, mode, properties / descriptor.

RQO

SQL equivalent: an API request envelope (wrapping the query).

Request Query Object — the single normalized message of every client→server work-API call. One RQO answers: who calls (source), what to do (dd_api + action), over which records (an embedded SQO), and what to return / lay out (show/search/choose/hide ddo_maps). Mantra: SQO = the query; RQO = the request. One RQO per HTTP call. See: Request Query Object (RQO). Related: SQO, DDO (dd_object), request_config, mode.

S

section

SQL equivalent: a table (with format and logic).

A group of records of the same kind (people, interviews, images…). It plays the role of an SQL table but is not one: many sections share the same physical matrix table, distinguished by section_tipo. Its fields are components. See: Introduction. Related: section_tipo, component, matrix (table), section_id, area.

section_id

SQL equivalent: a per-table primary key (scoped to one section).

The unique record id within a section_tipo — paired with section_tipo it addresses one specific row. Because one matrix table mixes many sections, two records can share section_id = 1 if their section_tipo differs. Distinct from the table-wide id.

Always an integer, negatives included (-1 is the root record). Values that are not integers are a different concept sharing the field name: an external-service remote id (001338683, Q42) or a synthetic client token (search_1), both kept verbatim. See Canonical form of section_id. See: Introduction. Related: id, section_tipo, locator, matrix (table).

section_tipo

SQL equivalent: a specific table identity.

The unique ontology definition (a tipo) of one section — e.g. oh1 (Oral History), rsc197 (People). It is the discriminator column that, combined with section_id, pinpoints a record in the shared matrix table. See: Introduction. Related: section, tipo, section_id, from_component_tipo.

service

No SQL equivalent.

A reusable piece of interface + logic shared between components, sections or tools — e.g. a text processor used by text areas, or an upload files service used by image/PDF/audiovisual components. See: Introduction, Services. Related: tool, widget, component.

SQO

SQL equivalent: a SELECT … WHERE … ORDER … LIMIT query (abstracted).

Search Query Object — a JSON abstraction of an SQL query, inspired by CouchDB's Mango language and adapted to Dédalo's ontology-driven, columnless schema. Its filter maps to WHERE, order/limit/offset to the rest; the search engine parses it into JSONB jsonpath SQL over the matrix tables. A client-built SQO is untrusted and passes the sanitize_client_sqo() / conform_filter() security chokepoint; a server-built SQO is trusted. See: Search Query Object, search config; skill dedalo-search. Related: RQO, matrix (table), component.

subcontext

No SQL equivalent.

The small piece of the ontology holding all the context needed to build a composite element: for a section it is the context of its inner components; for a component_portal it is the context of the components it points at in other sections. See: Introduction; skill dedalo-context-data-layers. Related: context, subdata, component.

subdata

SQL equivalent: the joined-in column values of related rows.

The data of other elements needed to build a composite element: for a section, all its components' data; for a component_portal, the resolved data of the pointed section/components. Resolved via get_subdatum() and merged into the datum. The singular subdatum is one such resolved unit. See: component_portal, Introduction; skill dedalo-context-data-layers. Related: data, subcontext, datum.

T

tipo

SQL equivalent: an internal identifier code.

The alphanumeric code identifying every node in the ontology (oh1, rsc85, dd151). Tipo is Spanish for "type" and is also glossed as the acronym Typology of Indirect Programming Objects. A tipo is a TLD plus a sequential number (dd5 = the 5th dd node) and resolves to exactly one model. Specializations: section_tipo, component_tipo. See: Introduction, Ontology. Related: TLD, model, node, section_tipo, component_tipo.

TLD

SQL equivalent: a schema/namespace prefix.

Top-Level Domain — the identifying prefix of a tipo that partitions the ontology so it can grow without code collisions. Examples: dd (Dédalo core), rsc (resources/media), hierarchy (thesauri), lg (languages), oh (Oral History), ich/tch/tchi (intangible/tangible heritage), utoponymy, ontology. Local projects can mint their own unique TLD. See: Ontology → TLD Organisation. Related: tipo, ontology, node, hierarchy / thesaurus.

tool

No SQL equivalent.

A self-contained interface + logic for a task — either a work process (e.g. transcription of interviews) or an action (e.g. propagate data between records). Tools are registered (v7 register.json), permission-checked (tool_security/API_ACTIONS), and attached to nodes via the DDO tools array. See: Creating tools, Introduction; skill dedalo-tools. Related: service, widget, DDO (dd_object).

translatable / lg-nolan / transliterate

SQL equivalent: per-locale column variants / collation.

Translatable data is stored per language in keyed slots (lg-eng, lg-spa, lg-cat…), decoupling linguistic content from structure; the DDO translatable flag (default true) marks whether a node is. Non-translatable values use the reserved lg-nolan slot. Transliterate is the orthogonal idea that a value in one language could be transliterated to others (handled by tool_lang): components expose a transliterate_value to signal that a translation exists. See: dd_object. The per-tipo translatable flag is resolved from the ontology in src/core/ontology/resolver.ts (getTranslatableByTipo, backed by node is_translatable), and a component model's OWN translation support is declared on its descriptor as classSupportsTranslation (e.g. src/core/components/component_input_text/descriptor.ts). Related: lg-nolan, value, Raspa score.

ts_object

No SQL equivalent.

A normalized Dédalo object representing thesaurus/ontology hierarchies — the server node builder (src/core/ts_object/ts_object.ts, buildNodeData) that turns a ddo_map into the JSON shape of one tree node consumed by the client tree widget. Backed by ts_node_repository (batched reads; src/core/ts_object/node_repository.ts) and ts_term_resolver (term cache; src/core/ts_object/term_resolver.ts). See: Thesaurus and Ontology tree, Introduction; skill dedalo-ts-tree. Related: hierarchy / thesaurus, area_thesaurus, node, DDO (dd_object).

V

value

SQL equivalent: the stored cell value.

The data actually stored in the database for a component — the payload inside the data container, distinct from its companions (datalist, fallbacks) and from the context that describes it. For relation components the value is an array of locators. See: Introduction, component_portal, data model. Related: value item, data, datum, datalist, locator.

value item

SQL equivalent: one stored cell value plus its identity/language envelope.

The consolidated v7 envelope every component stores inside a typed matrix column: an array of {id, lang?, value} item objects (even mono-value fields store a one-element array). id is a stable, server-minted per-item identity (never recycled — the pairing key for dataframes and Time Machine); lang is lg-xxx or lg-nolan; value is the payload (a scalar, or a structural object such as an IRI {title, uri} or a date datum). Relation components carry no value — their item is a locator. Empty values are deliberately preserved to hold a multivalue position and keep dataframe attachments alive. See: Value item, data model. Related: value, data, locator, dd_date, dataframe, lg-nolan.

view

SQL equivalent: none (a presentation/render template).

The render template (final HTML/CSS) used to display an element — default, line, mini, text, mosaic, etc. (the zzz segment of view_zzz_yyy_* client files). Set on the DDO view; if unset, default is used. children_view propagates a view to a node's children. See: dd_object, Components nomenclature. Related: mode, DDO (dd_object), component.

W

widget

No SQL equivalent.

A small, focused piece of code that performs a cross-cutting task — e.g. summarize some components, or collect data from sections. Lighter than a tool, it is composed into sections/areas (examples: media_control, dataframe_control). See: Introduction. Related: tool, service.

work system vs publication system

SQL equivalent: an editorial/staging database (PostgreSQL/JSONB) vs a published read database (classic columnar SQL).

Dédalo's two halves. The work system is where curators create and edit data: PostgreSQL/JSONB matrix tables, the ontology-driven work API (RQO/SQO), full history and permissions. The publication system (diffusion) exposes selected, finalized data to the public: the diffusion engine writes it into a classic columnar SQL database (MariaDB/MySQL by default) or file targets, and the Publication API serves it to websites. See: Introduction, The diffusion engine. Related: diffusion, ontology, matrix (table).