Chronology in the Mycenaean Atlas Project

“Absolute chronology is simple in concept

but fiendish in practice;…”

Manning [2010], 18

Use Cases for Relative and Absolute Chronology 

in the Mycenaean Atlas Project.

In my previous post I discussed the ‘findt’ table which identifies the general type of a Mycenaean site.

In this post I want to discuss the ‘Period’ and ‘Time_span’ tables which give values for the time or era in which any particular site was created and/or occupied.

Periods in Bronze Age archaeology are usually conceived of as ‘Ceramic Horizons’ (in this post I’ll refer to these as ‘CH’) - those broad blocks of time in which certain types of ceramics were in customary use.  These periods are the ones most of us are familiar with: LHII, LHIIIA1, MH, etc.  The essential insight is that, while we may rarely know the specific year in which any ceramic type was in use, we can arrange the ceramic horizons themselves in a time sequence.  We can say, for example, that dishes typed as ‘LHII’ were used at a time earlier than those typed ‘LHIII’ no matter what specific years those names may correspond to.

Sites in the Mycenaean Atlas Project that are securely typed 'LHIIA'.

The result of a century of pottery study has led to a profusion of (sometimes conflicting) names as well as an unhelpful overlap between differently named ceramic horizons from other regions such as Cyprus or Crete.

In addition to these problems there has, in recent years, grown up a heated debate over when the transition between LHI and LHII occurred .  The resolution of this problem rests on exactly when the volcano on the island of Thera erupted.[1]  Since this problem has been allowed to go unresolved and since passions are high on both sides it has become the custom to maintain two dating schemes in which the start and length of LH II differs between the schemes by a century.  These two schemes are referred to as the ‘High’ and the ‘Low’ chronology.

As a result, with respect to Bronze Age and Iron Age chronology, we have the knowledge organization problem par excellence. 

The intended goal of my database implementation of both the relative and absolute chronologies is to support Use Cases such as the following:

1.  Provide a mechanism for storing CH information for specific Myceaean sites along with the literature source that the CH is derived from.

E.g., if Simpson [1981] says on page 133 that site ‘C102’ was used in the LH IIIA then that association needs to be stored.[2]

2.   Retrieve all the CH information for a specific site or sites.  This is the reverse of the previous.  Here the user wishes to retrieve what anyone has said about the CH for any specific site or sites.

3.  Select start (and/or stop) year for a specific ceramic horizon.  In other words the user must be able to retrieve start and stop years corresponding to a CH name such as ‘LHII’.  This, of course, is the absolute chronology criterion.[3]

4.  Select start (and or stop) year for a specific CH using either the low/high chronology.  This is the same as the previous except it further specifies that the user may retrieve either ‘High’ or ‘Low’ chronology time spans.

5.  Produce output for CH names using one of a variety of user-specified conventions, e.g. LH IIIA1, or L.H. III a1, or SH iii A1, etc.  This is because the literature, which uses a variety of styles as well as foreign languages, refers to the same CH in very different ways.

6.  Select a range of different CHs for a site and output them in chronological order.  To explain this requirement consider that ‘LH’ is alphabetically prior to ‘MH’ but posterior to it in time.

7.  Support overlapping CH names.  For example we must be able to get sensible answers to queries for ‘LHII’ as well as its subperiods, ‘LHIIA’ or ‘LHIIB’ even though these overlap.  

8.  Fundamentally different systems such as Cycladic and Minoan have to be handled sensibly with respect to each other and with Helladic.

How are these use cases to be implemented?  The first thing is to agree on an internal representation of the CH names.  I have used the convention in which all spaces and periods are removed, all letters are capitalized.  Numbers such as I, II, or III are retained as roman numerals in upper case.  All other numbers are simple cardinals.  All foreign language usages are converted to the English language equivalent For example:

L.H. IIIb1 à LHIIIB1;   remove periods and spaces and convert LC to UC.

SH II à LHII          ; German.  Foreign language CH names are translated.

Every CH name must map onto a distinct character sequence for that horizon.  These names are stored in the era field of the period table and the time_span table.

I stress that these are the internal names only.  No one will ordinarily see them except those who work on the DB.  Corresponding to these internal names we must also have an external or printable form or forms.  The DB supports that with the field ‘EraPrint’. 

Imagine the following query:

select EraPrint from Time_Span where Era = ‘LHIIIA2’;

At present the DB would return the value ‘LH IIIA2’.

Currently the DB does not support foreign languages but that is a simple add-on.  Additional fields can be implemented for values such as ‘EraPrint_G’ or ‘EraPrint_F’ for German or French.

The above query could then become:

select EraPrint_G from Time_Span where era = ‘LHIIIA2’;

Such a query would output: ‘SH IIIA2’.

Requirement 6, above, specifies the ability to output date ranges in CH name order.  Under this requirement the CH name ‘LH’ must appear after ‘MH’.  How is that to be arranged?  In order for this to work there must be at least one field in the time_span table on which sorts can be performed.  We want to facilitate queries of this kind:

select EraPrint from time_span where Era in (‘EH’, ‘LHIIIB’, ‘MHIII’, ‘MHII’, ‘MHI’);

This query might return the values like this:

‘EH’,

‘LH IIIB’

‘MH III’,

‘MH II’,

‘MH I’

This result is in the wrong chronological order.  In order to make chronological ordering possible the time_span table must contain a sequence field.  This is a simple integer field which provides a unique number whose magnitude corresponds correctly to the actual chronological period of each CH name.  For example the previous query can be rewritten like this:

select eraPrint from period where era in (‘EH’, ‘LHIIIB’, ‘MHI’, ‘MHII’, ‘MHIII’) order by Seq;

Using the seq field will always return values in the right chronological order like this:

‘EH’,

‘MH I’,

‘MH II’,

‘MH III’

‘LH IIIB’

Under requirement 4 the DB must support the return of start and stop period years for either the ‘High’ or ‘Low’ chronology.  The solution to this is to provide both date ranges in the time_span table and require the user to supply either the word ‘High’ or the word ‘Low’.  Queries such as the following, which return the start and stop years for each named CH must be possible:

select distinct EraPrint, yPost, yAnte from time_span where hilo = 'High' and Era in ('EH', 'LHIIIB', 'MHIII', 'LHI', 'LHII', 'MHII', 'MHI') order by seq;

EH, 3100, 2100

MH I, 2100, 1850

MH II, 1850, 1775

MH III, 1775, 1700

LH I, 1700, 1635

LH II, 1635, 1410

LH IIIB, 1320, 1190

select distinct EraPrint, yPost, yAnte from time_span where hilo = 'Low' and Era in ('EH', 'LHIIIB', 'MHIII', 'LHI', 'LHII', 'MHII', 'MHI') order by seq;

EH, 3100, 2100

MH I, 2050, 1900

MH II, 1900, 1775

MH III, 1775, 1650

LH I, 1650, 1550

LH II, 1550, 1410

LH IIIB, 1320, 1190

If you examine the LH I and LH II start dates for each of the previous two queries you will see the difference between ‘High’ and ‘Low’ chronologies.  As I look at these results I think that I may have begun LHII too soon in both of these modes.  This is a simple data change that does not affect the structure of the DB tables. 

The time_span table is basically a table of DB constants and is never modified by the user.

Now that I’ve discussed some of the preliminaries I will devote the next post to the exact structure of the ‘Period’ and ‘Time_Span’ tables.

~~~~~~~~~~~~~~

Anyone who would like to have a copy of the MAP database can send an e-mail to bobconsoli 'at' gmail.com or leave a comment on any of my posts.  To run the MAP database requires a SQL server running on your desktop computer.   MySQL is such a server and it is powerful, industry-standard, and free.  

I can and will make .kml or .kmz files, which can be opened directly in Google Earth, available to those who would like them.  

I can also create .csv files for people who would like to import Mycenaean Atlas Project data into Google Earth but would like it in tabular form.

Those who do not have a SQL server but would like the full database in .pdf form can have that for the asking.

If you like these posts then please follow me on Twitter (Squinchpix) or on Google+   (Robert Consoli)

Facebook?  Sorry.I.just.can't.

Footnotes

[1]  A nuanced study of the problem of high vs. low chronology is in Manning [2010], esp. pp. 18-24.

[2] Simpson [1981], p. 133, ‘F 139 Stoupa: Ancient Leuktra’.

[3] Manning [2010], 18.

Bibliography

Cline [2010]: Cline, Eric H., ed., The Oxford Handbook of the Bronze Age Aegean.  Oxford University Press, Oxford, United Kingdom. 2010.  ISBN: 978-0199873609.

Manning [2010]: Manning, Sturt.  ‘Chronology and Terminology’, in Cline [2010], pp. 11-28.

Simpson [1981]: Simpson, Richard Hope. Mycenaean Greece. Park Ridge, New Jersey: Noyes Press, 1981.