There is one primary database containing the columns:
Element Name, Parent Name(s), Key Name, Genius species, Synonyms, Antonyms, Alternate Text Name
(Multiple databases are generated from data which will remain static to make processing more efficient.
An example is the descending(child) sequence database.)
Every element must have an element name.
Every element must have at least one parent (the highest element uses the keyword TOP)
The presence of an entry in the Genius species column means the data element is a species element. No entry in this column means the element is a characteristic element.
Characteristic elements have only one parent.
Genus species elements have many parents.
The program contains the rules to process the relationships expressed in the database elements and to communicate with the user.
Parent/Child Relationship Rules:
If an element is true, all parent elements must also be true.
If an element is false, all children elements must also be false.
Peer Relationship Rules:
An element may have zero, one or many synonyms.
Synonyms will be assigned the same Y/N value.
An element may have zero, one or many antonyms.
Antonyms will be assigned the opposite Y/N value.
In the instruction example,
YELLOW FLOWERS has an antonym, BLUE FLOWERS so as Yellow is Y'd it causes Blue to be N'd
as BLUE is N'd it causes all it's children to be N'd
YELLOW FLOWERS is Y'd so all it's parents are also Y'd
when it gets up to FLOWERING PLANTS, that has an antonyn NON-FLOWERING PLANTS which is N'd
when NON-FLOWERING PLANTS is N'd all its children also get N'd
A significant portion of the 'intelligence' of this program comes from the relationships between data elements. One of these relationships, I call 'antonyms'. An example of an antonym would be; when yellow petals is true, then blue petals MUST be false.
The 'marking' of the elements is accomplished through the use of four 'buckets'. There is an Add-Y-Bucket, an Add-N-Bucket an Add-S-Bucket and an Add-Unmarked-Bucket. When the program determines that an element should be marked, it simply adds the name of that element into the appropriate Add Bucket. The program then loops through processing the Add Buckets until there are no more contents. A little 'twiddling' is necessary to stop the program from oscillating.
Finally, there is a 'garbage collector' routine which eliminates (by N'ing) orphaned characteristic elements (still unmarked but not pertaining to any remaining plant).
Following is the content of the KeyLog.Txt file. This file shows the processing sequence as the program marks elements. I originally created this file to aid in debugging faulty relationships between the data elements. As it is primarily a debugging tool, all users overwrite the same file. I have included it here as it clearly demonstrates program processing. To display processing steps below, on the Identification Key page, mark an item and press a Process Button. 'Processing' writes a new KeyLog.Txt file and you need to refresh this page to display this new version. The contents will reflect the steps done while processing that mark.
-- top of loop --
Page created by: firstname.lastname@example.org