Within the context of VerbaAlpina, the term digitisation> is not only used to describe the simple use of computers for electronic data processing. The term describes essentially the digital deep development of the material by *structuring* it systematically and transparently and by categorising it.




VerbaAlpina works almost exclusively with the relational data model which organises the data material in principle in the form of tables. The tables consist in rows (= data sets, tuples) and columns (= attributes, fields, properties). Every table can be widened by additional rows and columns in every direction. Between the tables, there are logical relations which allow coherent nexus and corresponding synoptic depictions (the so-called "joins") of two or more tables. At the moment, VerbaAlpina uses the database management system MySQL for the management of the tables. However, the tables are not bound to this system, but can be exported at any time, for example in the form of text with separators that have to be defined unambiguously both for field and data set limits; they are exported together with the row names and the documentation of the logical relations (entity-relationship model). The XML structure that is often used at the moment is not used in the operational activities of VerbaAlpina. But XML is anchored as export format within the interface concept.

Besides the logical structuring of data, the coding of the characters is the second important concept in connection with the term "digitisation". The right handling of this topic is of fundamental importance with regard to the long-term filing of the data material. As far as possible, VerbaAlpina gets its bearings by the encoding table and the guidelines of the Unicode Consortium. In the case of the digitisation of characters that have not been included yet in the Unicode table the digital data capture of a single character takes primarily place by serialisation choosing a sequence of characters out of the Unicode code space x21 to x7E (within the ASCII range). The corresponding allocations are documented in special tables; this procedure allows a conversion in Unicode values which possibly will be available at a later date.