Executive summary.
Give the average non-genius user the ability to actively manage a very large information base.
This is a purely mathematical solution which does not utilize artificial intelligence.
A small ceremony for organizing a company. Let us place, on this green cloth, a small statue of The Agent. We can place beneath this statue a list of instructions, or assorted small pages of instructions. We'll work on this. We can place a candle in the candle stand near by, the source of Light. An obelisk shaped stone would represent The Law. Gifts of food on little plates, Marzipan, maybe, represent sustenance and companionship and a dish of water is The Mirror. Dab the candle with holy oil, from bottom to top, at intervals, while working on the instructions. Statuettes of other participants can also be added, together with lucky charms.
A much better calendar would be very nice. This math would be perfect for that.
At root it seems to me the database is a string parsing and string indexing operation. The first record contains information about how long the second record is. That, however, is probably nonsense, or might be. Let's see. A record can contain shapes, for example triangles and ellipses. Each shape in a record is a record. Let's say a record for a shape begins with a 0, meaning it's an ellipse. An ellipse is defined by two points and a color. 16 bits would be ample to locate a point in a square with a reasonable degree of precision, perhaps, and a color is, I'm thinking, 48 bits, so the complete record for an ellipse is 64 bits. Oops, I'm wrong. You also need a radius, and each of the foci needs two locations, adding another 48 bits for a total of 112.
This requires some clarification. The database subdivides into location records. A location record can contain any number of shapes, if desired, and a location record can also contain other location records. Let's divide it into a shapes string and, after that, a records string. Although it's far fetched there could be any number of shapes in the shape string, so, presuming this, the location record needs to begin with a bit that indicates whether more than one bit is required to record the number of shapes in the record. If that bit is 0, only one bit is required to record the number of shapes, while if it's 1 then more than one bit is required in which case if the second bit is a zero, then more than two bits are not required, and so on, which will result in either 0 being the first bit, or a string of 1s ending in a 0. This logically reduces to mean that the first 0 in a record marks the beginning of the record of the number of shapes in the location, the 1s preceding the first 0, if any, record the length of the number, in bits, required to store the number of shapes, and the shape record begins after the end of number of shapes number.
We now move on to the records string, and make a somewhat perplexing discovery. We may know that there are a certain number of location records in the location record, or we would know it, but each of those location records may contain other locations records, so we have no apparent way of knowing how big a given location record is, or, no, it's not that, but its length can go to infinity ... wait ... At the beginning of the database would be a number ... it would need to be ... the number of location records in the location record, and then for each of those a number would be required that records the size of that location record, in bits.
On a final note, a user could possibly create an infinite number of location records within location records, thus creating a kind of attack. This can be prevented by charging a fee of some sort for every record created. In the case of a free medium this would be a time charge, slowing the next post, or maybe no charge for empty locations but locations with shapes in them get charged against the user's data limit. This, by the way, may appear to be trivial, but it's not.
