So we have a nifty database that supports organization charts and unit rosters. Now we’ve got to indicate how those organizations (collective groups of participants) moved and reacted on the battlefield. Here’s the part where many will have different definitions of the elements, but allow me to use some simple conventions here, which may gloss over some details for the moment, in order to facilitate the examples.
For my hypothetical “Battle of Mudpuddle” web resource, I’d define an “event” as any recorded or recordable (giving options for deductive reasoning) action taken or reacted to by a participant or unit. I know it is not a sound legal definition, but work with me here, this is a blog, not a requirements document! Under this definition we have different flavors of events. Arbitrarily I’ll call two in particular – situation reports or movement reports. There certainly will and should be other types, but allow me to work with these two for clarity.
Those nice dispatches reporting enemy contact make easy translation to situation reports. But while those specified when the “friendlies” saw “enemy,” movement reports should detail what the “friendlies” are doing to the enemy. It is possible to break down after action reports and other accounts written after the battle as a set of situation reports and movement reports. Consider the reporting officer is re-stating the chain of events encountered in the battle. Might require some work on our end however to define the breaks.
The relation is straight forward – “Events” break down into different “flavors” which have different attributes:
Events then are defined by a time, person recording the event, and a type ID. In addition, I’d provide maybe a “narrative” column for remarks, even though I deplore such unstructured data holes. A “Bookmark” pointer might be used to reference the line in a document from which the event is derived. Works good if we have the “artifacts” cataloged as mentioned in the previous post. Again for this example, I’d only use two event types:
TypeID 1 is a Situation Report
Type ID 2 is a Movement Report
Some sample event table entries would look like this:
For reference here’s the Participants table from the earlier post, from which the PersonID is derived:
So we have a movement order from Col. Smith (bookmarked to an Official Record entry), followed by a situation report from an OR, a diary entry from Mrs. Johnston, reference to a letter from Pvt. Butler, and lastly another reference to Col. Smith’s OR.
Now let’s look at some generic data for a “Movement Report” table:
Purists looking at normalization will quickly point out the re-use of the Unit name and time columns. I’m presenting them here for ease of reading (to those not acquainted to the elegance of SQL). The important columns here are the waypoint and endpoint locations. Translated to English this entry into the table should mean “the 111th was moving from point 1 to point 2 at 9 am on the 2nd of July.” The event ID ensures it is identified coming from Col. Smith.
And then the “Situation Report” Table:
Those familiar with the Army’s SitRep format know this well. SALUTE – Size, activity, location, unit, time, and equipment. It’s a nice, concise format that works for many generic field reports. Arguably it isn’t the most useful for the Civil War. But for this example, it works for a simple demonstration.
In this set we have good Capt Jones reporting an encounter with the 5th Arizona’s skirmish line. Shortly after that his Mrs. Johnston recalled seeing a battery of the 1st Nevada deploy their 3 inch Rifled cannon nearby. Private Butler said “we ran like the devil” in a letter home, which matches to around 10:30 a.m. that morning. And the good Col. Smith let us know by 11:00 a.m. the Arizonians were advancing through.
I could, if I had time, further refine out events by “flavors.” One lacking in this example is a category for friendly action reports – “We stood and fired” type events. However we can begin to link this into the larger data structure now:
Given these basic relations it is possible, if our “Lat/Long” entries support it, to overlay the events, particularly unit locations, onto a map display. This display could be managed to show all activities within a set time frame, or to display all the events related to a particular unit. The “hard work” of relating the data is entrusted by all those lines pointing to the tables which represent either the coded application logical rules or defined database relations. Fairly easy at this point to call up “events where participant is Col. Smith,” or better still “events where the participant is anyone who is included within the unit 111th Alaska.”
Personally I’d tweak it one step further. How about an additional flag for “visible to” attributes for events? In other words, given some analysis of the first person accounts, and perhaps some assumptions, could a particular “event” be seen by a participant? Would be nice to lay out what “was” and then compare to what Col. Smith “saw” at the Battle of Mudpuddle. Such would at least offer some great fodder for the “what if” conversations.
That’s my Civil War Battle database on a bar napkin, if you will. As a card carrying solutions consultant, I’m the first to say “this is just a general idea of how it could be done, and the solution defined here is not intended to be implemented as is….”