As we can grasp it now the node table is mess: nodes don’t appear in the order of their chain but according to the moment in which they were created. Though located in another table, symbols look like nodes but constitute another type of entry. But of what types are we talking about in this context? Let’s put in light the differences between Sqlite types, unidSql objects, and property types, for they interact in various ways. Starting with the coded features of Unidatab, we find five SQL tables in Unidatab, and only four of them are interfacing explicitly with data management : tables ‘data’, ‘node’, ‘symbol’ and ‘alias’. These contain the structures whose properties define objects that are functionally specific to Unidatab : records, symbols and aliases.
The data table is made of utf8 strings and positive integers. The alias table is made of utf8 strings and integers. The node table is only made of integers. These are SQL data types, and it is a first and least sense in which we use the word ‘type’.
When we look inside a record we find parts that are physical nodes in the corresponding table which contains only integers. A record is thus a list of entries – let’s say ‘links’ – in the node table. On one hand, each link points either to the preceding one or to the next one, or 0 at the end. On the other hand, each link points also to one symbol.
The symbol would like to be seen as a column name associated with a value (they’re actually most of the time presented on lines). Symbols are like physical nodes, but they can’t be mistaken for they live now in an independant table (this wasn’t the case in the beginning) and most of all, they have the ‘d’ field set to 0 or 1: this can’t happen to links. Inside a symbol, we thus have at least a « name » and a « value » and we call the same « type » and « property » because we want to attribute this association to something that has to be conceived by definition in the outer world (even when the thing would be a word, a number or a process).
The symbol does not refer to anything by itself except when nested into a record, then the value becomes a property of the object of the record, seen as belonging to a certain type and possibly unique in its type for this object. This way the type can be said the angle from which the property is seen within that object. But the record itself has a type too : its format, that makes possible groupings and subdatabases. So in Unidatab the concept of type subsumes two similar expressions at different structural levels : the recording level, and the symbolic level. For it is clear now that the format of a record, i.e. the type that qualifies the whole record, is also the angle from which the object was grasped when the record was made.
Unidatab, originally adopted this feature in prevision of some kind of « unicity type policy ». Unicity is probably one of the most basic type charachter, so basic that its expression (few possible values in an integer field) can be used differently and thus supports various type policies.
Let’s imagine a different type policy in order to match some peculiar scientific needs. In the seventies, a French theoricist in archaeology tried to codify and standardize the way remains were collected, described and interpreted. He had informatical treatment in mind yet. His type policy was based on a first dichotomy like our unicity feature, the distinction between intrinsic and extrinsic characteristics of an object (a drawing is an extrinsic characteristic, but the pigment is an intrinsic one). Unidatab provides what is needed to implement Jean-Claude Gardin’s archaeology, simply by assuming differently the role of the ‘d’ field in table node.