I’m still thinking back to Robert’s discussions about “information compilations” and specifically the presentation of information. What’s tickled my fancy in the last week is how best to approach the information organization, with a mind to that presentation, of the tactical details of a Civil War battle inside of a web application (for example a web site intended to provide an authoritative resource on a battle). What follows is sort of a suggestion, call it a “straw man” for a system. Call it just “talking out loud.” Probably won’t work for any specific requirement. Sort of what we used to call in the Army as “A Way” thinking.
First off and foremost, you’ve got to have the data organized and categorized in some form of data structure. Lets just say we are documenting the “Battle of Mudpuddle.” There are several basic elements of data which form the framework of our understanding – Participants and Events stand out right off the bat. Break down participants one step further – Units and People. Events further breakdown into different types and flavors, which we can deal with later on.
The participants, when you really want to spin it out, have a straight forward parent-child relationship. People make up units. Some people hold special spots in the units (commanders, color guards, etc.). However not all participant people are in units, say perhaps reporters at the battle for instance. But all participant people will have some perspective, or in other words a link to the battle. Confused? Simple terms – participant people are defined by their perspective on the battle in which they play a role, which may or may not be defined within the context of a unit. That make sense?
Well how about a data layout, not completely normalized (as that would cause headaches among some readers) depicting said data relation:
The “perspective” table has a reference to a “Person ID” as well as a “Role ID.” People also have a defined attribute of “Unit ID” referring to an organization. Now with regard to my hypothetical Battle of Mudpuddle, we’d have to massage the data relations a bit based on actual context, but lets just assume some generic stuff. Say the list of Roles would be some basic ones – Commander, Adjutant, Reporter, Civilian, Infantryman, Bugler, and courier. The list probably needs to be longer, but I won’t bore you to death.
So we have a Role table like this:
Now for the people table, lets say we use some sample data:
Now go back and lets match up the “perspectives” table:
My goodness… just numbers! Really what this table does is formalize the linkage between a person and their role. If you decode the numbers, you see that Col. Sam Smith is a “Commander,” Capt John Jones is an Adjutant, and Pvt Bill Butler carries a musket. Why do we need that? Wait for it….
Next we need to populate the Organizations table to depict the units. For our sample data, we’ll just do two units for simplicity, of which only one has members in our system for now:
Notice the “parent” value is what we call a “self referencing” column with a value indicating the Unit ID of the parent. Level is a number value stating what tier of the hierarchy the unit sits in the organization chart. Might not need it, but there are times when writing raw database queries such attributes are handy. lastly the Weapon ID number is a bit beyond what I’d want to discuss today. Should be a simple reference to a “Weapons” table calling the ID of a weapon type used by the unit. Might look at that later as time permits. What it does explain is why one should consider this “database” format over say just a flat spreadsheet – the ability to build defining attributes on different elements without making a mess of the other elements. In this case, we can easily add another column showing “county recruited from” or “muster date” without modifying any other table.
What does all this mess allow us to do? The simple stuff should be apparent – a query within our web application for all members of a unit might offer a drop down menu. From that menu, the value of the matching Unit ID is passed as a variable into a query looking for “all people who’s Unit ID = 1.” I won’t bore you with the SQL query unless you really need it bad. Same technique would allow a query for “all buglers from any unit” or any mix or derivation thereof.
A good presentation twist here, however. Say you have what the knowledge management gurus call “an artifact.” We tend to call them less elegant things like, say, official reports, letters, or dispatches. Given all those ID numbers, it is rather easy to build out a simple list of IDs that help frame the context of that document. The technical term is “metadata.” The manifestation would be a set of attributes like: “Role ID – 1; Person ID – 2; Perspective ID – 2; Unit ID -1″ which would define a document from good old Col. Smith commanding the 111th Alaska. Sort of makes it easy to “call” a document quickly within your data set.
Nothing really rocket science here… yet. We’ve only formalized the relations which define about half of our data. We could easily at this point present a fine order of battle list linked into a roster of each units. But that’s not much fun. Units “do” things. Those things are called events. We’ll look at that next.