“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.
~~~~~~~~~~~~~~
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.
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.
