Behind the scenes

From Heraldry of Lincoln Cathedral
Jump to: navigation, search

Data Model

This website is constructed using Mediawiki, the power behind Wikipedia. Although Mediawiki allows for a great deal of ad-hoc data, I have tried to impose some order by carefully organising all the information. This is illustrated by the "data model" shown below:

Data model.png


The fundamental unit of information is the "Heraldic Item", typically a shield or full achievement of arms. I have collected basic data about each heraldic item, for example the material it is made from, its size, the time period in which it was created and so on. In addition, there is narrative information giving background. Each item is represented by a single Mediawiki "page", which is named with a reference id (these take the form "holc-NNNN" where NNNN are digits). There is no significance to the numbering, they are simply unique identifiers.

Each item belongs to the Category "Items", thus a count of pages in this category is the total number of items on the website.


These heraldic items do not exist in isolation but are (usually) part of an "object". To reflect this, there is also a "page" for this "object". An object may include more than one heraldic item. If a single object contains multiple, identical items then I have only created one "item" page, and in the narrative part I describe this multiplicity. For example, the exterior of the Longland Chantry has many repetitions of the Longland crest, but these is represented by a single item.

The choice of what constitutes an "object" is fairly arbitrary, and is basically whatever seems sensible to me. The object could range from a single "kneeler" (with an embroidered shield design) to a particular wall (with many carved designs on it).

As with items, objects have a page named with a unique reference number (of the form "hobj-NNNN"). Unlike items, objects also have one or more specific names, such as "Exterior Walls, Longland Chantry".


Owner here is used in the sense of the name of the person or organisation to whom the arms belong. Obviously, in the case of marshalled arms there may be more than one owner. Up to three owners are listed in the information box for each item, if there are more than three these are listed in the descriptive text. Owners have one or specific names. In full names I have put the family surname in capital letters.


At first glance, it might seem that the location should be associated with an object, since an object can only be in one place! Whilst this is true, we are interested in the heraldry here and location is used in the sense of "viewing location" (which, in hindsight, might have been a better name). If this is different from the objects actual location the descriptive text will make this clear.


The use of wikimedia categories, both hidden and visible, along with the "Display Page List" extension allows very flexible sorting and presentation of data. For example, viewing a location automatically includes a list of all the objects in that location; objects include a list of all the items that are part of the object, owners list all items including their arms and so on. All of these cross-links are maintained automatically through the unique identifiers. When items, objects, locations and owners are created initially some HTML forms and PHP code ensures all these identifiers and links are set up correctly and the pages are then created through an API call. Subsequent page editing is done through the normal wikimedia process.

To ensure consistency of page layout and organisation, only the basic descriptive text is actually contained in each page, topped and tailed by "templates" that provide the main formatting items. Thus, every item page includes near the top an invocation of the template {{item-start}} and at the bottom {{item-end}} (these templates are sometimes empty but are always provided for consistency and future expansion). The PHP code used on creation also ensure that these templates are inserted correctly.

It is possible that there are other more "standard" ways of achieving such consistency (I am aware, for example that there are extensions to help with data input) but this simple "hand-crafted" approach has worked for me!