The new Chronological Report Page on Helladic.info

The helladic.info site is pleased to announce support for chronological table creation and chronological ordering of sites in the DB.  A new database (Rev. 0.064) and new software has been delivered to implement this addition to the functionality.

The new Chrono report generates a table of occupation times based on your choices from the selection control on the Controls page. The control page allows you to select a combination of Region, Ceramic Horizon, or Type. After making your selection click on the 'Report' button. This brings you to the main report page. That page now has a 'Chrono' button. When you click on that button you will be given a chronological table on which your selection sites will be plotted with 'x's in the appropriate time span columns. Let's look at an example.

From the controls page I select 'Building' under the type label. Then press 'Report'. You'll be taken to the main report page:

You'll see the new 'Chrono Report' button. When you press that you'll be taken to the new Chrono page:

In the left-hand column are the unique place key identifiers for all the places in your selection set. They are clickable. When you click on one you'll be taken to the specific Place Key Report page for that site.

The second column is the place name. The names in this column are mouseable. When you run the mouse over them the region name will pop up in a tool-tip.

Succeeding columns, 'EH', 'EH I', 'EH II' etc., are the ceramic horizon columns. If there is evidence for your site having existed, been used, etc. during any specific ceramic horizon then there will be an 'x' in the box for that ceramic horizon. Here we can see that C1164, Troullos on Kea, existed in the LH I and the LH II.

The column headers with the ceramic horizon names are mouseable. When you do mouse over them the approximate year range will pop up in a tool tip.

It must be emphasized that these ranges are very approximate and scholars differ over what the proper year ranges should be for any specific ceramic horizon. Please keep this in mind. As I learn better ranges for specific ceramic horizons then I will probably change these tool tips.

The 'x' characters in the table boxes are also mouseable. When you do pass the mouse over them then the ceramic horizon label will pop up. This is intended to make it easier to work with the table when the column headers are out of sight.

When creating this table I faced the choice of making the table pageable (column headers never out of sight) or sortable. I chose sortable as probably the more useful alternative. When you click on the column heads the table will be re-sorted to put your criterion at the top. Because spaces in the cells sort before the character 'x' by default you'll probably have to click twice on any specific column head to get the effect that you want.

Also keep in mind that there are really two chrono pages, one in the helladic name style: 'EH', 'MH', 'LH' etc. and one in the Minoan name style 'EM', 'MM', 'LM', etc. These pages function differently. If your chosen data set has sites from Crete then the default or initial chrono page will show few or no 'x' characters in the table.

In order to see a meaningful chart you will switch to the 'Minoan Scale' page. Probably the most disorienting thing that a user can do is to make some region choice such as 'Crete' and then be faced with an empty chart and not know why. Remember to switch scales. The button to do this is at the upper right of the page and labelled 'Minoan Scale'.

Also keep in mind that some sites, particularly in the islands, have ceramic horizons in both styles. You will need to look at such sites under both scales. If you are on the Minoan Scale page there is also a button, in the same place, for switching back to Helladic.

I have not yet implemented a page for the Cycladic time scale.

There are buttons on the chrono pages that allow you to go to the elevation report page or the gazetteer report page. Those pages now also support buttons that allow you to go to the Chrono page. This should make multivariate analysis more convenient.

The tables, like any .html table, can be selected with the mouse, in whole or in part, and dropped directly onto an Excel spreadsheet. Here is an example of a table from the chrono page dropped onto Excel:

After you have dropped this table into Excel you can change the formatting or delete it completely as you choose.   But that's another topic.

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

With a correspondent I've been discussing the question of whether putting exact locational information online is a good thing or a bad thing.  I'd like to hear from my readers on this question - do you have qualms about putting this kind of information online?  You can respond to this post or use my e-mail which is bobconsoli at gmail dot com.

If you like these posts then please follow me on Twitter (Squinchpix) or Google Plus (Robert Consoli).  Please do this.

You can e-mail me (and I hope you will) at  bobconsoli   at   gmail dot com

And please remember - Friends don't let friends use Facebook.

Most researchers in this field use some product like Microsoft's Excel to create a 'DB'.  This is fine; it's what is generally referred to as a 'flat file'.  That is, a single table representation of your data of interest.

The Mycenaean Atlas database, on the other hand, is a relational database with several tables that was built using MySQL.  Dumps of this DB are available but you need MySQL (or similar) and a knowledge of Structured Query Language (SQL) to run it.  Otherwise it doesn't make much sense to ask for it.  But If you'd like to have a copy of the Mycenaean Atlas database anyway then e-mail me and tell me about your project.  

And remember that useful .kml and/or .csv files can be generated directly from all the windows (including the new reports pages) of the website helladic.info   Try it out!   I'm also willing to generate custom .csv or .kml files from the atlas if you need something specific.

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.