The data structure is build from some basic building blocks which are shown in the following picture:
The data structure is build from some basic building blocks which are
shown in the following picture:
It has a base object called **Entity**. Entities are either **Record Types**, **Records**, or **Abstract
It has a base object called **Entity**. Entities are either **Record
Properties** (and Record like objects for files).
Types**, **Records**, or **Abstract Properties** (and Record like
What *kind of data* is stored is defined by the Record Types. Actual data is then stored in CaosDB as Records which are of some Record Type. Those Records can have Properties that contain information about the Record. The following is a more detailed explanation (also see this [paper](https://www.mdpi.com/2306-5729/4/2/83)).
objects for files). What *kind of data* is stored is defined by the
Record Types. Actual data is then stored in CaosDB as Records which
> Record Types and Abstract Properties are used to define the ontology for a particular
are of some Record Type. Those Records can have Properties that
> domain in which the RDMS is used. Records are used to store the actual data and therefore
contain information about the Record. The following is a more detailed
> represent individuals or particular things, e.g. a particular experiment, a particular time series, etc.
explanation (also see this
[paper](https://www.mdpi.com/2306-5729/4/2/83)).
**Record Types** define classes or types of things, e.g. persons, experiments, timeseries, etc. Records
can be viewed as members of the class defined by its Record Type. These classes can contain
> Record Types and Abstract Properties are used to define the ontology
Abstract Properties which define key-value relationships for properties of the things along
> for a particular domain in which the RDMS is used. Records are used
with the expected data type and possibly the default unit, a default value, or a range of permitted
> to store the actual data and therefore represent individuals or
values. As files on the back-end file system are a major focus of this database management system,
> particular things, e.g. a particular experiment, a particular time
there is a special entity File that encapsulates typical file properties like path, size and checksum.
> series, etc.
**Entities** can be related via binary, directed, transitive is-a relations which model both subtyping
## Record Types
and instantiation, depending on the relata. These relations construct a directed graph of the
Entities. If A is-a B we call A the child of B and B the parent of A. No adamant restrictions are
**Record Types** define classes or types of things, e.g. persons,
imposed on the relate of the is-a relation and thus, Entities can be children of multiple Entities.
experiments, timeseries, etc. Records can be viewed as members of the
class defined by its Record Type. These classes can contain Abstract
Each Entity has a list of Entity Properties, or in short just **Properties**. An Entity Property is not an Entity of its own, but a triple of an Abstract Property, a value or Null, and
Properties which define key-value relationships for properties of the
an Importance. The values can be numericals, strings, dates, any other valid value that fits into
things along with the expected data type and possibly the default
one of several builtin data types, or, most notably, references to other Entities. The importance
unit, a default value, or a range of permitted values. As files on the
is either obligatory, recommended, suggested, or fix. A valid child of an Entity implicitly
back-end file system are a major focus of this database management
inherits its parent’s Properties according to their Importance, which means that it is obliged,
system, there is a special entity File that encapsulates typical file
recommended or only suggested to have a Property with the same Abstract Property (or
properties like path, size and checksum.
any subtype thereof).
## Entities
As opposed to Properties with other priorities, **Fixed Properties** have no effect on the Entity’s children. During the creation or update of Entities, the importances of the parents are
being checked by the Server. Missing obligatory Properties invalidate the transaction and
**Entities** can be related via binary, directed, transitive is-a
result in an error, by default. Missing Properties, when they are recommended, result in a
relations which model both subtyping and instantiation, depending on
warning, but the transaction is considered valid. Entities with missing suggested Properties
the relata. These relations construct a directed graph of the
are silently accepted as valid.
Entities. If A is-a B we call A the child of B and B the parent of
A. No adamant restrictions are imposed on the relate of the is-a
relation and thus, Entities can be children of multiple Entities.
## Properties
Each Entity has a list of Entity Properties, or in short just
**Properties**. An Entity Property is not an Entity of its own, but a
triple of an Abstract Property, a value or Null, and an
Importance. The values can be numerals, strings, dates, any other
valid value that fits into one of several builtin data types, or, most
notably, references to other Entities. The importance is either
*obligatory*, *recommended*, *suggested*, or *fix*. A valid child of
an Entity implicitly inherits its parent’s Properties according to
their Importance, which means that it is obliged, recommended or only
suggested to have a Property with the same Abstract Property (or any
subtype thereof). As opposed to Properties with other priorities,
**Fixed Properties** have no effect on the Entity’s children.
During the creation or update of Entities, the importances of the
parents are being checked by the Server. Missing obligatory Properties
invalidate the transaction and result in an error, by default. Missing
Properties, when they are recommended, result in a warning, but the
transaction is considered valid. Entities with missing suggested
