Since version 4 the development of Dédalo is based on a new programming model. This model is based on the development of the object-oriented MVC model with the addition of programming control through ontologies. These generate an abstraction layer for code and data, allowing great versatility in code generation.

The definition of ontology comes from the branch of philosophy known as metaphysics, which raises questions like "what exists?" and "what is the nature of reality?" Ontologies explore existence through entities, properties, and relationships between particulars and universals.

This programming model has been inspired by the use of thesauri, ontologies and indexing, typical of the humanities research field, and has been applied to the generation of the Dédalo source code. 

Unlike the ontological models that we can find in research projects in digital humanities, which use ontologies as definitions (like dictionaries), our ontological model of programming is not a "static" model without direct action on the result. Our model is dynamic and directly connected with the code and the data, therefore a change in the ontology implies a change in the source code of Dédalo, its behavior and interpretation of the data.

As of version 4 there is no longer direct programming of the inventory cards, as the programming is dependent on one or more ontologies that control the flow of code generation. For this, a new programming model has been designed and it has been structured as follows within the ontology:


  1. Term: entity that defines the instance of the object, with its properties.
  2. Model: programming object.
  3. Paradigmatic relationship: hierarchical generation dependency.
  4. Semantic relationship: relationship with other instances necessary for the generation of the element.
  5. Properties: modification, defined in JSON, of the standard behavior of the object.
  6. Translatable: modification of the basic behavior of the component that adds the possibility of translating its content.


The ontology terms have a behavior defined by the term model, its properties, dependencies and relationships with other terms. The main models within Dédalo and that define basic behaviors of the application are:

  • Area: General term (TG) that can be used in code generation for the grouping of sections. 
  • Section: Specific term (TE). Inventory file model and relationship with the database. Area dependent (parent relationship).Management of registration data. 
  • Component: Specific term (TE). Field within the inventory / resource tab. Section dependent (parent relationship). It can have dependencies and relationships (TR) with other components. Field data management. 
  • Tool: Tool that is applied to the components. Component or section dependent. Direct relationship in programming with modification in the component / section of the behavior of the tool (modification in properties).
  • Diffusion: Defines the structure and data model that will be used to process the information when it is published.
  • Button: Execute an action. Dependent on the sections (parentship relationship).
  • Label: Generates a translatable "string", which allows the inclusion of text within the programming.

The operation of object programming in Daedalus is structured as follow

  1. The ontology term is defined.
  2. A model is assigned to it.
  3. The kinship relationship is defined.
  4. Relationships with other terms are defined.
  5. The properties are defined.
  6. It is defined if the term will be translatable. 


Each term in the ontology will generate an instance of the object defined by the model. Dédalo will interpret the term, generate the code necessary for its operation and execute it every time it is required.

The object within the schedule follows the MVC (Model, View, Controller) programming pattern. In addition, the extension of the controller has been necessary to generate the code in a server / client environment, which sends data from the client (JS) to the controller on the server (PHP or JS with Node).

Within Dédalo it is possible to generate as many terms in the ontology as there are programming instances that are necessary for the generation of "inventory cards" with their corresponding fields.