At The IC we spend a lot of time thinking about museum data, because when we build a museum website it has to work seamlessly with the museum's collections and events data. As we've built GLAMKit, we've realised that some widespread issues need general solutions.
One of the particular challenges faced by almost every museum is how to deal consistently with dates. Most of the time, computers are used to dealing with complete, precise, unambiguous dates, such as "August 28, 1979". If everything is unambiguous, it's easy to say whether one date is the same as another, or comes before, or after.
As with many things, life isn't so simple when it comes to museum data…
If your collection is geological, a date like "August 28, 3 million BC" isn't quite right.
If your collection is at all historical, then you're very quickly going to run into uncertainties and approximations.
For example, you know a vase was from the Edo Period, then it was probably made between 1603 and 1808, give or take. You may even be able to narrow it down to a decade, say the 1770s. But getting a complete and unambiguous date is unrealistic at best, misleading at worst.
For database designers, it makes more sense to treat museum dates less like a single point in time, and more like a region of time.
In the collections databases we've worked with, like Axiell Emu and Vernon CMS, it's most common to store a 'display date' string, which can be any text, plus two precise dates that indicate the start and finish of a region of time.
Occasionally, there's no computer-readable date information, which leaves a museum with no way to query its collection by date!
But even when there is, this approach still presents several problems –