Dedomenon Concepts

Dedomenon is an online structured information storage system. The world of concepts in Dedomenon can be divided into two logical zones:

  • Definition Zone
  • Instantiation Zone

Shortly, in definition zone, you define the structure of your data and in instantiation zone, you place your data.

Definition Zone

Definition zone describes the structure of your storage space. This is where you tell what you want to store in what organization. Here are the components that describe structure and organization of your data in Dedomenon:

  • Database
  • Detail
  • Entity
  • Relation

Databases

A database is the top most container of your data. It does not contain any data itself, but it contains many entities. Also, it has many details. A detail can be linked to many entities. For example, in a database Contacts there might be two entities ‘Friends’ and ‘Family’ and two details ‘Name’ and ‘Phone’. The detail ‘Name’ can be associated with both entities ‘Friends’ and ‘Family’. This lets you reuse details in defining what your entities will hold.

Entities

An Entity holds information about a particular object of your domain. For ease, you can perfectly think of an entity analogous to a table as in a typical database system. Each entity has many details. Again, you can think of details as fields of a table.

Details

A database has many details. These details are then linked to entities to define the structure of the data you will store in Dedomenon. As mentioned in the section on entities, you can think of a detail analogous to a field of a table. A detail has a name and a data type which might be any of the following:

  • Short text
  • Long text
  • Date
  • Integer number
  • Email
  • Web URL
  • Choose in proposition list
  • File attachment

In Choose in proposition list data type, you will have to choose a value within a list of proposition that you provide at the creation of detail of this data type. Also note that a detail may be linked to many entities.

Relations

Any two entities in your database might have some sort of relationship among them. For example, if you have two entities in your database named Artists and Songs then its obvious that a song belongs to an artist (or even more if sung by many). Similarly, an artist might have many songs. This type of information is captured as Relation in Dedomenon.

A Relation has two participant entities, type of relation at each end (one-to-one, one-to-many). Moreover, it has a name from each side of relation.

In the example of Artists and Songs, An artist can have many songs (one-to-many) but a song can only belong to a single artist (one-to-one). Note that we assume that a song is sung by a single singer. Then a Relation has name from each side. So in this example, fron Artists to Songs the relation side will have a name Sings on (or whatever you think describes the relationship better) and from Songs to Artists it will have Sung by as name.

Instantiation Zone

This is where your actual data is stored.

  • Instance
  • Detail Value
  • Links

Instances

Instances are similar to rows or records in tables. They got their name from the view that they are instantiations of entities. Each instance contains data defined by one entity. An instance cannot be linked to two entities. As entities have details, instances have detail values.

Detail Values

When talking about details in their section, we described them as analogous to fields of a table. Similarly, when talking about instances, detail values are the values for those details. As an example, lets suppose we have an entity Songs with details Tittle and Length. This describes the structure of what a Song. When you create instances for this entity, the values you enter against the details of the entity are known as detail values.

To elaborate further, if we have an instance for Songs entity like this:

Title Length
“I can’t stop loving you” 2:41

Then “I can’t stop loving you” is detail value for detail Title and 2:41 is detail value for detail Length of entity Songs.