Concrete Evidence
Concrete Evidence was originally intended to be a small database of the pillboxes and World War Two defences I've visited in over 25 years of interest in the subject. However, this intention has been revised in the face of two unexpected events.
Firstly, the database has driven me out into the countryside and archives to uncover more sites to include in it, and secondly, several people expressed an interest in contributing material, even before the site was officially launched!
The Database
Every defence listed in the database has been assigned a Concrete Evidence Reference (CERef) number; this is a unique identifier for each record generated by the database when a new record is added. It is not a wartime designation, nor is it related to the Defence of Britain Project's UORN identifiers.
At this point, I should mention the Defence of Britain Project (http://www.britarch.ac.uk/projects/dob/) and the resultant database (http://ads.ahds.ac.uk/catalogue/specColl/dob/index.cfm).
Concrete Evidence bears a fundamental resemblance to the DoB Project Database, and for a reason; it simply makes sense to provide the same sort of information in Concrete Evidence as is provided in the DoB Database. While some of the entries here have already been recorded in DoB (and I reference their UORN number) my intention is not to reproduce what has already been done.
My information adds to that already recorded, and I cover some defences in greater detail with at least one photograph for every record in Concrete Evidence. Also, while being an absolutely fantastic and important project, DoB inevitably omitted numerous defences; Concrete Evidence currently contains 110 records (of which 44 were not recorded by DoB) and 396 photographs.
Database Structure
When designing the database, I encountered several problems, terminology and defence heirarchy being the most prominent.
As regards the former, should you list a defence work by the type of building it is, or by its function? For example, a "pillbox" is a type of building that, in most cases, serves the function of "machine gun emplacement." In these instances, I have recorded such defences as pillboxes.
However, there are exceptions to the rule, particularly where I have listed observation posts; these were frequently existing structures with completely unrelated purposes, such as church towers or windmills.
Then we have the problem of how to record defence works such as Martello Towers; several were occupied and refortified, perhaps justifying their inclusion as a "defended building". Several towers were employed as Battery Observation Posts (BOP), but they also served multiple purposes; Tower 73 at Eastbourne [CERef1084] was not only the BOP for the battery built in front of it, but a magazine as well. In July 1940, Tower 64 [CERef1005] housed a Vickers gun to fire along the beaches, but by December 1940, it is also listed as an alternative observation post for the local field artillery unit.
Defence Heirarchy and Relationships
Such anomolies bring me to the other problem, that of granularity; at what level of detail should defences be recorded? The DoB database includes obstacles such as cylinders and buoys listed at that level. However, their presence implies the location of a roadblock, and this latter "parent" defence is often not listed.
I have tried to resolve this issue in Concrete Evidence by the use of a parent/child relationship, allowing you to search for obstacles such as cylinders and also the roadblock of which they were a constituent. While this results in semi-duplication of information, I believe this is the best way to proceed.
The parent/child relationship doesn't stop at this level though; although the roadblock is the parent of the cylinders, it can have its own parent, such as a nodal point. The nodal point can be the child of a Sub-sector, the Sub-sector a child of a Sub-area, and so forth. However, I have stopped listing defences at a Sub-Area level for now.
DoB does have a relationship that appears to record defences up to nodal point level, but stops short of sectors and above; I imagine this is down to the fact that to record all the sectors and sub-areas in Britain would have been a project in itself, nevermind the fact that boundaries probably changed.
DoB also records the parent/child relationship between stop lines/defence groupings and lower-order defences, but without actually recording the former in the database as recorded defences. I have considered doing this, but it opens another door into the realms of complexity as regards recording locations and grid references.
This also helps in tracking down defences that are listed by their type of structure rather than their purpose. For example, if you search Concrete Evidence for "Emergency Coast Defence Battery" you will find among the results the Eastbourne battery. A constituent defence is Martello Tower 73, which, although it was the BOP, it is listed as a "Martello Tower (Refortified)" and so cannot be found by searching simply for a "Battery Observation Post."
As the database follows the relational model, to associate multiple descriptions with each defence would be a very simple matter, but I'm not entirely convinced of the need to do this, as it would either mean having to specify which description takes priority, or experience duplication within search results. If a priority can be placed, then I feel it best to stick to this and record each defence under just one title to avoid (more) confusion.
Another solution would be to include an extra entity into the database structure; again, this would be very simple to do at any time, but would start to increase the complexity of the structure. The knock-on from this is extra fields in the input and content management system, which generates extra work for a data inputter i.e., me! Databases are abstract machines; they don't (can't) describe everything. The database records each defence, but not the weather conditions or the clothes I was wearing when I visited. So for a one-man project (at the time of writing) I feel that the database is complex enough!
Doubtless there are many anomalies and contradictions within the database (and my attempts to explain myself), and some historians and archaeologists will disagree with how I've structured it. However, being an historian/information scientist, this is the way that seems the most logical to me!