Events vs. Attributes

[Uncle Buddy]

I think about this all the time and it's finally time to make a decision.

Roughly speaking--and there's no precise way to do it--events are incomplete without a date whereas attributes are still attributes even if associated with a date. For example, Rex Roth got hired to build hydraulic valves in October of 1932. That's an event. Without the date it would be lacking in an essential way. Rex Roth had a career as a hydraulic technician. The date or date span, if added, will not make it an event. It's an attribute.

I'm not going to argue that this is precise. It's just the only differentiation I can come up with.

But there's no perfect way to express this in genieware. So here is the best compromise I've been able to come up with.

As usual, enforcing some point of view on the user is not a good idea. There are already enough unlikable genieware products out there, we don't need any more.

My idea is to suggest that the user can get a conclusion about a person to interfile by date on the events table by giving it a date. If the date is uncertain or competely unknown, a possible range or an estimated or approximate date can be used. On the contrary, to keep a conclusion from being interfiled by date on the events table, leave the date out and the conclusion will end up on the attributes table instead. In a case like this, a date can be given in notes if there is one to give. In this way, the user can decide where his conclusion is displayed.

Exceptions: birth, death and burial are on the events table in a set order determined by physical laws, so they will appear in the right place on the events table whether they have dates or not.

In the next post I'll discuss two model geniewares that I look at to get inspiration or negative inspiration as the case may be, and how they dealt with this problem.

[Uncle Buddy]

I have two genieware products which I've bought and tried to use. Model A I used for years before I got tired of the workarounds and tedium. Model B was meant to replace it, but it was just as tedious and the workarounds were more complex.

Model A has an events table similar to the one I'm creating for Treebard. I found it acceptable when using this genieware to add estimated dates or approximate dates so the event wouldn't end up messing up the table. The table doesn't make much sense unless the rows are sorted by date.

The attributes table is weak. It's on a separate tab for some reason even though there are less than half a dozen choices. If there's a way to define other attributes, it would take some digging to find out how. The attributes that are included with the program can be described by one or more of these adjectives: vague; could/should be associated with a date but there's no date field; redundant category that also appears on the events table.

So it appears that Model A's attributes table is loose as a goose and not very useful. Looking at it in conjunction with the events table is physically impossible since they're on two different tabs of the same notebook.

Model B has bypassed the issue by having only one table for both attributes and events, which are all called "facts". But there are no facts in genealogy. There are assertions and conclusions. The great majority of "facts" are based on evidence, not personal experience. If you're old enough to base a whole tree on personal experience then you're probably too old to use a computer. Everything else is an assertion based on a source other than person knowledge, or a conclusion based on personal opinions, theories, or assertions. Roughly speaking.

The facts table does appear on the same page as the main person's info which would be good if it wasn't compressed into a tiny space with resizable columns so that you have to change column widths one at a time to read everything that's there.

What about the dates issue? The table is sorted by date but I'm able to add events that purportedly took place before birth and they are filed ahead of the birth event. I'd rather see the birth event first no matter what date is reported because a wrong date should not make the rest of the table act silly. I added my own undated attribute and it was interfiled randomly after the birth event. That's the same problem as Model A. If the table's gonna be sorted by date then a date should be needed, otherwise the table is mud. Adding the undated attribute also made the pre-birth events mysteriously disappear. So I changed the current person and went back and now the undated attribute has disappeared and the pre-birth events are back. Sounds like some genieware is trying to act smart. Data should never disappear mysteriously. If the genieware senses a mistake it can say so but it can never try to make corrections. That is a woeful path to take. Lord save us from "smart" software.

[Uncle Buddy]

In Treebard I'm going to try using a small notebook for the attributes table and by changing tabs, the main image for the person will show and the attributes table will be hidden. So attributes and events can be seen side-by-side without trying to force fit them into one table.

If there are no images for the person, the attributes table will appear by default. The user can overrule this default by setting a personal preference, choosing to have either the attributes table or the image show by default. All of these settings would be ignored if a person's current person tab is left in a certain way; it will be displayed in the same way next time it opens.

[Uncle Buddy]

I'm now thinking the attributes table should be very similar to the events table but sit behind the picture. You can scroll it or expand it. It will have all the same columns as the events table below it, except the date column with have a button to "Add Date" instead of a date. If you add a date, the attribute becomes an event and moves to the other table. I think this is the best way to do it that I've been able to figure out so far. Giving them the same columns will make it easy to read and keeping undated conclusions out of the main conclusions chart is only right since that chart should be sorted by date in order to tell a chronological story.

The attachment is a screenshot showing current progress, i.e. just started by placing a small tabbed notebook under the main photo. I created this notebook myself since ttk.Notebook doesn't look right if the tabs are moved to the bottom.

The idea is for the attributes chart to be expandable so it will cover the pedigree window and show above the events table.

Attachments:

[Uncle Buddy]

Here's an example I just thought of, regarding the difference between an event and an attribute.

Let's say a man registered for the draft in 1918 and the registration form has his physical description on it. Does this really belong in an events table? The description I mean. Registering for the draft is an event but being described is not. In this case I'd say what date and place he registered for the draft and put that on the events table, using the form as a source. Then I'd go to the attributes table and create a separate attribute for each item of the description: eye color, hair color, height, weight, complexion, build, etc. It's clumsy to input a lengthy description with a bunch of text. Databases are perfect for singling out details, so why lump everything together in a list and stuff it into a note on an events table? Again the form would be input as a source. If someone cares what year he had blue eyes, they can look at the date on the source. If you put the date of the description on the chart, it will move to the events table, but in my opinion, eye color is not an event so I'd leave the date off and go find it by looking at the source of the event if I wanted to know what date the description was made.

Now if someone's hair turned gray in one day, that would be an event. I've experienced quite a few of those days but I forgot to write down the dates, so if my hair ever turns all the way white, someone would have to guess when it happened.