A Civil War Battle Database Part I

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:

Participants Tables and Relations

Participants Tables and Relations

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:

roles-table1

Now for the people table, lets say we use some sample data:

people-table

Now go back and lets match up the “perspectives” table:

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:

units-table

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.

About these ads

8 responses to “A Civil War Battle Database Part I

  1. Craig, Deep stuff here! Before laying out and organizing the data, what are your thoughts on conceptual design? How do you anticipate the needs of potential users? – Best, Robert

  2. Craig, Did you really mean to put Cenantua’s Blog among the “information compilation” blogs? “Opinion compilation” maybe, but… that’s closer to the definition of a blog. On the other hand, the Southern Unionists Chronicles info comp. blog looks quite nice in that category. Thanks for linking!

  3. Hi craig,

    This is a subject near and dear. The AotW databse is built on the concepts you describe. The beauty is the cross linking betwwen people, places, events, and the evidence for it all.

    The key, for someone designing a site from the ground up, is to create the most “atomic” possible model – storing the smallest practical information morsels – so that the information can be sliced and diced at multiple levels to answer many different needs. This supports both detailed analysis and flexible display.Information on demand.

    I can dump you the AotW schema if you’d be interested. It was not designed from the ground, though. It evolved over a long time as the site did. It’s not awful, but not elegant, either. :)

  4. Robert, I sort of agree with Brian’s take. Design the “data” structure, or schema, first. If done right, you can “slice and dice” (I prefer “dance”) the data as needed for any potential user needs. Abstractly, data should have its own set of relations which are independent from the higher levels of the system. Users will interact with the data at the “information” level – which is their user interface. A good data design would allow the developer to lay any user interface on top, without modifications.

  5. What I like about this, potentially, is the possibility of creating something other than traditional, linear narrative. Narrative is just a tool we use to organize an event or series of events in such a way that we can wrap our brains around it. I think it by definition has little to do with reality. Sure, everything’s connected, but almost never in a way that it can convert to a story. Inevitably, an interpretation of the events is what we get, rather than the events themselves. We get A story, not THE story. I don’t think THE story really is attainable. Now I think I’m making no sense at all, and I have the munchies.

  6. Uh oh Harry, You are thinking in abstracts… and have the munchies!? Hmmm. In all seriousness, I played with the hypertext non-fiction idea in another blog. It was fun, but I should have used a wireframe to make sense of it. Non-linear stories created in hypertext are interesting to read, not to mention fun to design.

  7. Craig, O.k., I get what you and Brian are saying. Actually, the IxD course may be compromising this very thing (which I practiced more in the creation of projects in my hypertext theory course).

    The IxD course puts more emphasis on conceptual design. Maybe it’s my interpretation of the importance of conceptual design and I need to step back a bit to reassess. Like I mentioned in my reply to Harry, in creating non-linear non-fiction narrative, I focused on the laying out info in the nodes first, and then hyperlinked to make sense of it all (with multi-linear paths), but not necessarily limiting the “making sense” part to linear flow.

  8. Pingback: Wiki! « Bull Runnings