# The daba inner system (and software)

## Daba itself

Daba itself is simply an abstract string of characters. In the semantic sense, daba is a single dabanese phrase (but contains quoted material too which is not strictly dabanese). It simply stores data. Thus daba is a dynamically growing string which needs to reside on a permanent memory device like a large hard disk. Here we enter the hardware and software considerations. For practical purposes this string has to be divided into several files. The files have to be controlled by software. But the daba itself is independent of software, it can be served by any computing language or other software means. The same or different users, at the same or different locations, may use different software tools to perform the same task.

For the practical reasons, the official copies of daba should preserve not only the string itself but also the partition into files, at every time; or else there would be likely a big mess.

Otherwise the software tools which search data and do all kind of postprocessing of the data can be quite arbitrary. It is crucial though that there are certain common standards and common habits.

## Daba references

The daba proper should include certain daba references. Daba referenced material should be stored in an indestructible way, just like daba itself. Physical objects like a city park (just an example) cannot itself serve as a reference because it may get covered by future buildings. The daba referenced material should be stored as some computer memory constructions. The daba references should be relatively rare. As much as practically possible should be included inside the daba proper.

## Data base operations

Daba by itself would have a very limited use without data base operations. While the daba is unique, there are many different software systems which can serve the daba by doing data searches and similar.

## Character set and related items

As it is now, the character set of daba includes ascii characters, the Polish characters

Ą  Ć  Ę    Ł Ń Ó    Ś Ź Ż

ą  ć  ę    ł  ń  ó    ś ź ż

and actually all Unicod characters. In addition, the $\ \LaTeX\$ will be used widely.

In the furure there will be a standard set of dabagrams. At this time I will use only $\LaTeX$ or pigeon dabagrams (mostly English or Polish pigeon).

There will be certain daba decoration and meta-notation.

## The daba external view (as a dabanese statement)

The external view of the daba is a dabanese statement of the following form:

( ( -1 { $\forall\ \,\emptyset\$} ) { $\ \ldots\ \,\ldots\ \,\ldots\ \,$ } )

Here the true data are stored as dabatems  "$\ \ldots\$"  in the unordered list

{ $\ \ldots\ \,\ldots\ \,\ldots\ \,$ }

presented earlier above on the right hand side of the total expression. This list is going to be very long, it is suppossed to store all relevant information of our world.

The initial dabatem

( -1 { $\forall\ \,\emptyset\$} )

serves as the daba's identifier. It should be copyrighted and/or similar. It'd by highly impolite to start any other daba-like database with the above identifier.

## Hierarchical order of daba

The elements of the true daba are called the dabatems or the main dabatems or the top dabatems. By this I mean the top dabatems which appear inside the unordered list which follows the header (see above):

{ $\ \ldots\ \,\ldots\ \,\ldots\ \,$ }

The dabatems are partially ordered. This is a more general construction than a rooted tree. The rooted trees were popular in computer science for a longer time. In the recent times it's the partial orderes which become more and more common. The order is established by subitems which list parents and children. Listing just parents (or just children) would be theoretically as good while listing children (or respectively parents) too is more practical; and that's what is done--each dabatem must list all its parents, and all its children.

The number 0 dabatem, namely $\ \forall\$ (which stands for the daba, or for all, i.e. everything), is the only dabatem which has no parent. Thus this is the top dabatem of the hierarchy. And the number 1 dabatem, namely $\ \emptyset\$ (which stands for nothing, i.e. emptiness, or for falsehood), is the only dabatem which doesn't have any child. Thus this is the bottom of the entire daba. every other dabatem has at least one parent, and at least one child.

Some subitems of a dabatem never change, e.g. the number of the dabatem. These numbers are assigned in the chronological order. But the list of parents and children gets updated each time a new dabatem is introduced. each new dabatem gets properly inserted between existing dabatems. When a dabatem X gets inserted between dabatems A B, where A is a parent of B, and B is a child of A (the two events always occur in a pair), then A becomes a parent of X, while X becomes a child of A; and also A becomes a parent of B, while B becomes a child of X.

The same new dabatem can be inserted betweeb more than one parent-child pair. But the partial order must be obeyed--no insertion is allowed to cause a loop, where two dabatems both serve as a descendant and a ancestor for each other.

When a dabatem X is inserted between A and B then it's common that the parent-child relation gets broken, stops being useful. But it's not necessary. As in real life families. Sometimes a parent A and a child B may have a child C. Then both B and C are children of A, even when C is a child of B as well. A similar situation may happen to some combinations of dabatems.

## Robustness: updates and obsolete material

Daba has no problem with errors or with obsolete material, and there is no formal tag to indicate it. Instead, when (always minor and, by definition, very restricted) improvements of an dabatem are not possible then new dabatems are defined with new or old names (titles). The historical (chronological) numbers (id's) of dataitems, and tracking of the dates, provide the whole image of the evolution. Whenever there is a question of which version of a daba definition (a dabatem) should be used one can always restrictg daba up to a given date, so that only the notions introduced before the time of writing of a document would be taken into account. Also, whenever necessary, a special construct in a document will allow to indicate the respective historical numbers of the respective dabatems. Such an historical number would be hidden under regular reading but can be divulged when needed.

## A practical solution

The engineering implementation of referencing the daba dabatems by a daba document is solved as follows. Let "$\ \ldots n \ldots\$" be an arbitrary dabatem from the daba, which has the historic number $n$. A segment of some consecutive three dabatems of the daba can look like this:

_<<a name="25084"></a>>_  $\ \ldots 25084 \ldots\$

_<<a name="25085"></a>>_  $\ \ldots 25085 \ldots\$

_<<a name="25086"></a>>_  $\ \ldots 25086 \ldots\$

If an author of a daba document needed to indicate a specific version 25085 of a dabatem named xyz then s/he may insert it in the document as link

<a href="http://wlod.net/2014++/daba%202014++/The%20daba.html#25085>xyz</a>

This way the reader (dabaner) can always retrieve the right version.

IMPORTANT:  Even when html were long gone you will not need to change anything about the daba. You can read the daba with any proper new software. It's possible that there will be a new way to format the source of the daba documents. But the format of the daba itself (the original data base) will stay the same. Furthermore, even in the case of old daba documents, the new software should either read them or should translate these documents to an up to day format, or both.

REAMRK:  Some additional software constructs exist and are needed to help finding the anchored daba dabatem on the screen or similar (or in general, to efficintly find any anchored text).