Three-column scratch work as a tool for thinking about thinking and a genealogical tool.
I have been blessed by many excellent teachers over the years. Among them is Dr. Michael Jones who taught several of the more theoretic courses that I took as a Masters’ student at Brigham Young University. One tool he taught me in a graduate computational theory course stands out in my mind as being something I use only rarely but think about often.
A major topic in computational theory is the writing a proofs. The writing of proofs is something that I have had interest, training, and aptitude in for far more years than most—my first real exposure to the idea came as a mere child. However, in this course Dr. Jones taught us to us a particular aide in our proof designing Dr. Jones also taught that proofs were a social construct, a class of persuasive writing, and that even once we had mapped out all the steps of our proofs we still had to actually write them. This tool is only for pre-writing part. . He called it three-column scratch work. At the time I had the impression that such work was a generally known tool, but I have never encountered it outside of his classes.
The idea of three-column scratch work is simple. In the first column goes things you know. In the second column goes things you want to prove. In the third column goes an explanation of how the current row came to be, something like “axiom” or “applied modus tolens to rows 3 and 7”. Each row is numbered, and each has information in only one of column 1 or column 2, not in both.
| Known | Goal | Reasoning | |
|---|---|---|---|
| 1 | 42 is even | objective | |
| 2 | ∃ x ∈ ℤ : 2x = 42 | 1, definition of “even” | |
| 3 | 21 ∈ ℤ | axiom | |
| 4 | 2 × 21 = 42 | 2, 3, instantiation | |
| 5 | 2 × 21 = 42 | arithmetic |
There are many things I could clarify here, such as the role of instantiation and skolemization in such tables and how you pick which of the many things you know should be added as an axiom; but the basics are enough for the point I wish to make.
Three-column scratch work embeds within it a number of interesting characteristics of deductive reasoning. For example, reasoning is acyclic: there is a way to write any proof in a table such that each row depends only on earlier rows, not later ones. A new goal row should, if true, imply the earlier goal rows it replaces; a new known row should be implied by the earlier known rows on which it depends. ∀ implies example implies ∃. And so on.
There is also an assumption in scratch work that you know the goal in advance and that knowing it can help you reach it more quickly. I’ve heard it argued that this existence of a goal in advance and the ability to come up with arguments that lead toward the goal is a core cause of rationalization; the other cause being a sloppiness or lack of understanding that causes some of the reason entries to be insufficient to actually support their row.
As I mentioned, I rarely use three-column scratch work myself when I am designing proofs, but I do appeal to it either mentally or on paper when I need to analyze some particularly involved reasoning, either my own or that of someone else. It helps to make the reasoning process transparent.
When I tell my friends about my work on genealogy data models, I generally get one of four reactions:
“Genealogy what?”—this from non-technical non-genealogists.
“There’s interesting problems there?”—this from technical non-genealogists.
“What we have works; what are you adding?”—this from the few genealogists for who the current systems seem to work.
“That sounds amazing; how soon can I use it?”—this from most amateur genealogists I know.
Unfortunately, the fourth response, while gratifying, has a rather sad answer. I am not a tool designer, I have no knack for designing user interfaces, and I have neither the resources nor the interest needed to build a large-scale collaborative genealogy tool myself. It’s just a data model and a prototype library right now…. I am working on several paths to make it more than that, but I can’t even guess how long those paths might take.
However, you can start thinking and working in a manner suited to a more powerful data model than the existing conclusion-with-sources systems even before such a model exists. All you need is three-column scratch work—and often just two columns are enough. An example, using the book of Genesis as the source for citation simplicity, let’s look at the goal “Find Issac’s age when he was almost sacrificed”:
| Known | Reasoning | |
|---|---|---|
| 1 | Abraham was 100 years older than Isaac | Gen 21:5 |
| 2 | Sarah was about 10 years younger than Abraham | Gen 17:17 |
| 3 | Sarah was about 90 years older than Isaac | 1, 2 |
| 4 | Sarah was 127 years old when she died | Gen 23:1–2 |
| 5 | Issac was about 37 years old when Sarah died | 3, 4 |
| 6 | Sarah died after Issac’s sacrifice | Gen 23 is after Gen 22; assumption: chronological narrative |
| 7 | Isaac was no more than 37 when sacrificed | 5, 6 |
| 8 | Isaac carried the wood for a burnt offering | Gen 22:6 |
| 9 | A burnt offering requires enough wood to cook a lamb | Informed guess; see e.g., Deut 18:1 |
| 10 | It takes a lot of wood to cook a lamb | Total guess |
| 11 | Isaac carried the wood “afar” | Gen 22:4–6 |
| 12 | Isaac was old enough to carry a lot of wood a long distance | 8, 9, 10, 11 |
| 13 | Isaac is never described large or strong | Gen 21–49 |
| 14 | Isaac was not unusually large or strong | 13, negative evidence |
| 15 | Isaac was at least in his mid teens when sacrificed | 12, 14, current expected rate of musculature development |
| 16 | Isaac was between 14 and 37 years old when sacrificed | 7, 15 |
I probably ought to split up some of these rows; for example, row 16 probably ought to have at least two more rows before it, perhaps “people younger than 14 can’t carry heavy loads long distances today” and “people in Abraham’s time did not mature faster than they do today.” Conversely, I could also combine some rows; for example, rows 10 and 11 could be combined into “it takes a lot of wood to perform a burnt offering”. The exact breakdown is not particularly important; the idea is just to break apart the various steps used in the reasoning.
One way of thinking of my family history data models is as ways of having the computer store information like the rows in scratch work instead of just the claim “Isaac was between 14 and 37 when he was almost sacrificed” and the list of sources “Gen 17:17; 21:5; 22:4–6; 23:1–2”. There are many reasons to prefer this storage: it gives the computer more scope to point out possible weak points in your work, it makes it easier to identify where you disagree with someone else, it makes translation easier, it makes it easier to see which decisions need to be revisited if new light sheds doubt on previous assumptions, etc.
Writing a single long table is probably I say probably because I have not used scratch work in family history extensively myself, mostly using early prototypes of my digital data models instead. Using prototypes means re-doing the work repeatedly… the cost of developing a new system. not the best way to do your work. I’d suggest having one scratch work for each source your consult and one for each multi-source match. Matches are a common source of error; for example, I might have a scratch work page titled “Assuming Luke 11:1–13 and Matthew 6:5–15 are the same address” and include both (1) why I think they are the same and (2) what I can derive from the pair but cannot derive from just one of the two, including how I rectify any inconsistencies between the two merged sources.
One of the things I tell every math and theory student is “don’t skip steps”. One of the side effects of maturity in any field is that habit makes common actions subconscious. education Novices often try to imitate the behavior of experienced practitioners, meaning in particular that they naïvély try to skip the steps that they observe the experienced people skipping. But if you skip a step as a novice, that step will get enough use to become subconscious and expertise will never be gained.
Scratch work is designed to be almost tediously long-winded. Sixteen steps just to say “Isaac could carry wood and his mother was alive”? Sure, you could skip steps. Some of them may already be subconscious for you, or perhaps you can think three or four steps ahead and just write down every fifth row. But there are at least three reasons to put some effort into including every row, enumerating every step you can.
First, a step that is subconscious or obvious to you today may not be as obvious to someone else trying to work with your data, including your future self. Unless you are so productive that writing your work down takes more time than the work itself, save your future self time by making it explicit today.
Second, if you knew it would work it wouldn’t be research See posts 112 and 322 for more on this idea. . Some of your ideas will be wrong, as evidenced by them contradicting other ideas. It will be much easier to discover where the incorrect idea come from if you have each step were you can look at it then if you have lumped a dozen steps into one.
Third, I assume most of my readers are novices partly because there are more Citation needed novices than experts in most fields, but also because most people I know are novices in genealogy Either that or most of the experts feign novice status. and I assume without evidence that most people who read my blog are people I know. As a learner, know this: a step skipped is a step unlearned.
Can you skip steps? Certainly. Indeed, you will almost certainly want to. Skipping steps is easy, and what human is not lazy? Further, almost all of the family history websites and software out there makes recording the steps difficult if not impossible, and we’ve learned to adapt to our software’s expectations to a frightening degree. But not everything you want to do is worth doing.
Looking for comments…