docs.txt

[Uncle Buddy]

D:\treebard\etc\docs.txt Last Changed: 2024-01-15

# docs.txt

CONTENTS:
ELEMENTS OF GENEALOGY
PLACES
PLACE AUTOFILLS
GENDER



ELEMENTS OF GENEALOGY

The elements of genealogy are those things which get their own database table, for the most part, and are endowed with unique ID numbers. The most elemental elements of genealogy are those things that pre-exist genealogy, like persons, places, and sources. Some elements of genealogy, such as couples and other relationships, are compound elements because they are comprised of two persons.

Primary tables exist for each of the elements so that each unique member
of each element category will have its own primary key or unique ID number
within that category. To link two elements together, they get their own
row in misc_links or another junction table, and the other columns in the
table will all be null except for misc_links_id, a primary key which might
seldom be used.

Conclusions and assertions are basic design
elements which exist separate from each other, but conclusions can
optionally be based on assertions while assertions must be based on
citations which must be based on sources. Sources can be linked to
repositories optionally. Conclusions are separated into events and
attributes in the GUI depending on whether or not the element is
officially associated with a date (event) or not (attribute). Attributes
can become events by having a date added and events can be changed to
attributes by having the date removed or added optionally to a
`particulars` or `note` column where it won't be officially recognized as
a date. In the code, collections of conclusions are called events (such as an event row in the conclusions table; conclusions are single conclusions such as "he was born in a manger" or "he was born" or "he was born on Christmas"; assertions are statements made by a source about a conclusion.

Some elements are pre-loaded with types in primary type tables, while some
are completely open-ended so aren't linked to types, such as projects and to-dos which can be linked to each other and anything else, but are not linked to any underlying primary type table. Type tables never have a foreign key in them, but their primary key is always used as a foreign key in other tables. Primary type tables underlie many somewhat primary tables such as the event table which stores events and attributes.

Event types are used for events and assertions, but since the event can be broken down into parts in the assertions table, and since a conclusion can reflect any number of assertions, the event type can be different in the conclusions table and the assertions table. For example, an event in the conclusions table can be labeled "invention" while the assertions backing it up can be labeled "patent filed", "patent granted" etc.

There's such a thing as splitting hairs too much. Treebard doesn't track
jurisdiction types such as "county", "parish", "township", "city", etc. as it
would be nearly impossible to do it well but adds nothing to the research.
I could think of no reason to classify sources by type. Is it a census or a gravestone? Isn't it obvious? But I might re-think this when I start working
on that part of the design. I think it would be silly to have types for citations. Is it a page number or a line number or a chapter number? Just say say it, that's what citations are. "Volume 5, Chapter 7, page 162". Having the single citation broken up into parts which are stored types might lead to the developer then trying to do the wrongness of formatting the citation. The user must format citations according to his own interests.

On the other hand, while the word "county" is the first part of the place name in Ireland and the last part of the place name in the US, in England it's just "Leicester", not "Leicester County". So jurisdicational categories would add some detail, but I don't think they would add detail that should be used to perform logic operations. A column could be added to the place table for jurisdiction, but it would just be a detail to display, not the basis for Treebard to draw any conclusions. Similarly, gender exists as a category but we can't use gender to assign spousal terminology. The user has to be given free reign to assign his own descriptions to a relationship, so relationships (called "kin" in the code) are one category that the user can add new members to as he sees fit.

PLACES

Unlike other genieware providers, your friendly neighborhood Treebard developer doesn't dumb down places to make our job easier. Since the first day of Treebard development, we have obsessed over detail upon detail to make our place data structure, input, and usage relevant to the pickiest genealogist while still being easy to use.

Some users might wonder why a place can't be autofilled into an input by typing "#65" for place ID 65. This could be done, as it's done with person autofill inputs, but it was a judgement call and this is the decision I made.

In Treebard, there are three different primary ID numbers which refer to places. Every single place has a unique ID number so that two different places can have the same name, like "Paris, France" and "Paris, Texas". This requires us to have separate IDs for every place name too: each "Paris" name has a unique ID number since they can't be told apart by their spelling. But for the most part, we don't just want to say "Paris" in genealogy at all; we want to say "Paris, Ile de France, France" or "Paris, Lamar County, Texas, USA". On top of that, any of the many Parises on earth is likely to have had different enclosing parents during its life span, so for example we need unique IDs for the nested places "Dallas, Texas, USA" and "Dallas, Republic of Texas". Then, if we want to include the county, the same single place "Dallas" will be included in separate unique nestings for the various counties it's in, now and in the past.

As your humble self-taught designer of genealogy software which intends to do complex work behind the scenes while providing a user interface that's easy to learn and easy to master, I've decided that the best approach is to prevent the user from ever seeing ID numbers for places. Juggling the notions of single place IDs, place name IDs, and nested place IDs is for the software developer, not for the average user. I propose to avoid the confusion that would ensue by never mentioning place IDs in the user interface at all.

There still has to be a way for the user to tell two same-named single places apart. One way is to look at other nestings that the single place is already a part of. These are given as examples on the New & Duplicate Places Dialog, which opens up more often that some users will like since Treebard tries to prevent mistakes of this kind before they happen. Another feature of this dialog is that you can assign a hint to a place or edit an existing hint. Here's a simple hypothetical example, not meant to be perfectly accurate. The place that westerners call "Israel" has had dozens of names over the millenia of its existence, with many of these places defined by different boundaries and governments. As a wildly over-simplified example, you could input two separate places named "Israel", providing one with a hint, "modern Israel" and the other with a hint "ancient Israel". As long as the HINTS are unique and relevant, you'll have no trouble figuring out which Paris the hint "Eiffel Tower" refers to when it displays instead of a confusing ID number.

PLACE AUTOFILLS

As for whether you can input names with their historically accurate alphabets, I haven't had time to try it yet, and you can inform me whether or not it's possible to do that. I think Python and Tkinter have the ability to use pretty much any alphabet on earth and possibly can be trained to use ancient hieroglyphics if you are descended from Cleopatra, but I have yet to delve into this topic in my research. Characters are one of my weak areas but I believe Python is up to snuff for anything reasonable that needs to be done, if someone has time to do it.

There are two kinds of place fields, autofill and non-autofill. Database places fill in automatically, whether it's a single place field or a nested place field. Database places are places stored in the database. If you enter a new place into an autofill, it can't autofill, so a dialog opens and you can sort through options to define a new place so it will autofill next time. But when creating assertions about sources, the text you input for that place is supposed to be just exactly what the source says the place is. In this case, the text is stored for that assertion only and will not autofill anywhere. For example, if your source says "Dalles, Texas", then you may want to spell it that way in the assertion, but on the conclusion you'd want to use the standard spelling "Dallas".

Most place fields are nested place name autofills, such as the places column in the conclusions table. Single place autofills are used in the places tab where you are able to add, edit and delete single places such as "Dallas" or "Texas" without reference to the larger places enclosing the single place.

There are other autofill fields in Treebard, but the nested place autofills have a special feature. When you input a place to an autofill field, that place is moved to the front of the hit list so it will be the first suggestion next time you start typing a word that starts with the same letters. For example, if there is a place called Zamora and a place called Zimbabwe in your tree, and you type a "z", then "Zamora" will fill in. If you then type an "i", then "Zimbabwe" will fill in. If you accept Zimbabwe, then next time you type a "z" in an autofill field, "Zimbabwe" will fill in first, not Zamora. This feature will save you lots of typing.

GENDER

Treebard recognizes three genders: male, female and unknown. We recognize biologically-imposed categories but don't use them to enforce anything except the roles of biological mother and father in regards to offspring. For example, on the persons tab, the father is designed to display on the left and the mother on the right, since that's where people will look for them. This doesn't affect adoptive parents, foster parents, or guardians since they're not biological parents. Treebard won't even notice if there are two female foster parents or if an adoptive male is input on the right. Even the biological parent will display on the side where he/she was input by the user, despite the gender. The user could literally input a female as father and a male as mother if he/she/it/they chose to do so for whatever reason.

As for the current (2023) gender hoopla, Treebard (the app) has no opinion and is not involved with gender issues other than to remain as flexible as possible under the circumstances. We (the developer) were youthful and omniscient once, and we try to flex to the demands of those who still are. Flex but not break. The evangelists of today's trends will get old someday too. Some of them. Disillusionment is enlightenment, but try telling that to those who have yet to earn their Stupidity Merit Badge through gruelling years of hard knocks and unfulfilled delusions. Treebard's overarching policy on fashions and trends--both political and computerish--is, "Which part of genealogy is supposed to be modern and politically enlightened, anyway?"

Treebard is about accuracy and ease of use for genealogists of all skill levels, all cultures, all political and religious persuasions, etc. And if we were to cater to the whims of passing fancy (even if those whims are considered gospel by some), we would have no time left to do our real work, which is to serve the interest of genealogists in general. If we were to cater to the whims of political opinion, we would be torn to pieces within minutes no matter which side we chose. Therefore we make Treebard as liberal as possible without burning it to the ground.

NOTES

In Treebard, notes do not have to be copy/pasted from one element to another, because any one note can be linked to any number of different elements. To help identify the notes, they have titles, but any one note can be titled differently when linked to various elements. Which isn't really recommended but it's not disallowed.

All notes linked to any one element (such as a particular person, place, source, citation, etc.) have to be uniquely named, but outside of that constraint, topic names can be reused. Which isn't really recommended but it's not disallowed.

Unique note titles will help you locate the note you want, when you are in the notes dialog hoping to link an existing note to the current element. This is done by starting to type and perusing the suggestions that pop up. If you can't remember the note title, or the first few letters of it, you can go to the search tab and see them all. The suggestions pop-up in the notes dialog appears when you enter an available new topic and tab out of the topic input. Click on the topic or note you want to use.

Notes can exist without a topic name or title, but when a note is linked to an element, it must be given a title. When an existing note is no longer linked to anything, it will still live in the database, and can be deleted completely by event it in the links tab.

To link a note to an element using a title other than the title the same note uses when linked to other elements, go to the links tab.

If you want to re-use an existing note but can't remember the topic, go to the search tab.

When you type a new note title into the note title input and tab out, a dropdown list will appear so you can choose among available notes in case you want to re-use an existing note. To close the dropdown, press the Escape key on the keyboard. The dropdown will also get closed if you resize the notes dialog. To re-open it if it closes or disappears, just tab out of the note topic input again. To use an existing note, click the corret row in the dropdown. To type a new note, close the dropdown and type a note into the large input box.

GEDCOM

How UNIGEDS handles GEDCOM's in-built inaccuracies and deficits. GEDCOM allows sources to be linked to other elements of genealogy without citations and assertions. UNIGEDS has to create a blank assertion in case this happens since its strict linking structure follows that of the real world, where a source can't say much without saying it at a certain place within itself (citation) and without the something that it is saying (assertion). After a GEDCOM import, if you find blank assertions, or placeholder text in place of real assertions, you are encouraged to fill these fields in with the right stuff, but this step is optional.