Wednesday, June 29, 2022

Digital Antiquities Databases; Their Visualization and The Mycenaean Atlas Project Digital Atlas

Several of the common digital antiquities databases have very poor or non-existent visualization tools.  Their focus is showing you individual sites on a map and with precious little other support.  The least satisfactory in this regard is Arthur deGraauw's Harbors project.  Dr. deGraauw is an outstanding expert in the field of harbor research; he freely and generously makes his data available to everyone.  This data is, however, in the form of a spreadsheet (computer types refer to this as a 'flat file') and no map visualization is possible on his site.  The remainder among these various DBs provide a dedicated page for each site along with minimal, mostly useless information about it, but without any larger visualization.  The best user interface among these databases is Vici which provides a visualization map for each site and shows you the context.  I do notice, though, that when I use Vici that there is often no site description or indication of the site's significance.   Here's an example: this shows Neftina on Lemnos which appears to be a quarry although we are not told this:



Vici is actually pretty good and contains nearly everything you want in map visualization.  Vici also  provides context in the form of other near-by sites.  The zoom-level is user controlled and jumping to another site does not require you to go back into outer space before zooming in again.  

Multiple Databases

When research involves the several popular databases dealing with antiquity it necessitates running back and forth from one window to the next and trying to put all this data into context.
   
There must be a better way.

What do we require when visualizing geographic data from antiquity?  Ideally we should be able to see all the data simultaneously on one map so the databases are inter-comparable.  Is the site coverage around Peristeria in Messenia significantly different between Pleiades and Vici?   To answer this question you need these two DBs on the same map so that they can be compared.  And each site on this combo-map should link back to the dedicated page which contains more info about that one site.  The map itself should be interactive. You should be able to click/tap on it and have it redraw centered on where you've clicked/tapped; restoring the data context at the same time.

 We're talking about a lot of data here.  The M.A.P. Digital Atlas can display abut 100,000 data points.  So when the user looks for one site (Chania on Crete, say) how many surrounding DB sites should be drawn automatically? 

Dumping the entire DB is too much.   It's time consuming.  Most of the DB would not be of concern to the user.  And the program response would take a significant hit.

Showing just the individual site is too little.  (Pleiades is worst in this regard.  P. annoyingly zooms in from outer space for every site search and it never shows any context.) 

Pleiades: Searching for Kydonia.
Phase 1: Outer Space!


Topostext shows the context around a sought-for site but it also forces the user back into outer space in most instances.)

The Mycenaean Atlas Project Digital Atlas chooses a middle way.  What is needed is enough context so that the user can work for an extended period on that specific level (Zoom levels 12-18 in most instances).  The Digital Atlas creates and  populates a frame which is about 1/5 of a degree in lat and lon.  In practice this seems to afford adequate space for investigating the immediate surroundings with little or no detectable drawing time.  When the user clicks/taps on the map it is redrawn with the new frame centered at the click.  The new frame is filled in from whatever data sets the user has chosen.

Part of Lemnos in the Mycenaean Atlas Project Digital Atlas
Features (red F paddles), M.A.P. sites (Bronze Age) in blue and Trismegistos sites are displayed

In any solution all the data sets should be visible.  In practice, even when limited by a frame, this can produce a great deal of confusing data overlay.  The user should, therefore, be able to  pick and choose among the various sets - showing all, or none, or some combination.  One wants to be able to see what Pleiades has covered as opposed to what Vici has covered, for example.  The M.A.P. Digital Atlas features a pull-down menu which allows the user to select as many/few database layers as desired.

The Lemnos map (detail)
Layer Menu visible along with 'spotter' map

In sum, then, the Digital Atlas from the Mycenaean Atlas Project adheres to the following design features:
  1. Supports visualization for the following DBs: DARE, deGraauw's Harbors Project, Mycenaean Atlas Project (with features), Pleiades, Topostext, Trismegistos, VICI
  2. Displays these databases in a frame that is 0.18° 'square'.
  3. Differential selection among the seven data sets
  4. Persistent zoom level (user-controlled zoom) (The user is never catapulted into outer space against his/her will)
  5. User-controlled redraw of the frame by clicking anywhere on the map
  6. Links from each DB icon to the relevant details page (Pleiades, Topostext etc., even deGraauw's Harbors).
  7. User-selectable map sheet backgrounds
The result is a quick and easy way to examine coverage for a place (e.g. Siteia on Crete) among the several databases.

I have said that each icon has links to a site details page.  Pleiades icon to Pleiades site, Topostext icon to Topostext site, etc.  The only exception is Dr. deGraauw's Harbors project.  There are no detail pages on his site for individual harbors and so I created a harbor details page for him.  Those pages faithfully reflect HIS data.  Here's an example:

Sample detail page for Arthur deGraauw's Harbor data.
This is Neftina on Lemnos

Looking at this I see that this page should have a 'spotter' map like the Digital Atlas.  Always something more to do.

Databases aren't just created for random and unstatable purposes.  They are created for reasons.  These reasons take their form in the software that is written to execute over them.  One thing that is absolutely essential is careful thinking about the user interface and visualization.  With awkward or non-existent visualization tools the database is incapable of effectively displaying itself.


 

Tuesday, May 17, 2022

Achaia-Klauss and environs in the Prehistoric


Achaia has benefitted from much recent scholarship that demonstrates how pervasive Mycenaean culture was during the Late Helladic.  However, enthusiasts, and even scholars, when attempting to learn about Achaia in the Bronze Age, are faced with confusing and unclear maps as well as multiply-named sites that make it difficult to get a clear picture of Mycenaean influence in this time and place.  

It is time for a series of clear blog posts that look at the important sites and which use clear maps for the purpose.  This post is the first in that series.  I have begun with the area covered by the orange rectangle in this next aerial photo.  Let's call this the Achaia-Klauss complex.






IDNameLatLonType
C494Koukoura/Achaia  Klauss38.19613321.774009Cemetery
C7531Skondreika38.19430521.778006 Settlement
C3148Mygdalia/Mygdaleia38.18740521.776154Settlement
C7530Tomb38.18633621.776582Tomb
C500Petroto: Tholos38.19381721.76769Tholos
C7532Hagios Konstantinos Β38.18690821.764875Cem
C5009Hagios Konstantinos Α38.18567421.766758Cem

Many more details about these sites are available at the ID field links.




The region shown in the map is on the western foothills  of Mt. Panakaikos.  In this area the foothills take the form of long ridges orientated primarily NW-SE.  On the NW edges of these ridges, about 5 km.  from the ocean on the WNW and overlooking the plain of Patrai, a series of settlements sprang up in the Middle and Late Helladic.  Mygdalia (C3148) was, perhaps, the earliest of these settlements; its presence is attested as early as MH III.  A tomb associated with it (C7530) was constructed in 'early Mycenaean times'.  A second settlement at Skondreika (C7531) on the hill of Koukoura may have been a later contemporary of Mygdalia.  The owner of this site has refused access to investigators and little is known about it.  In the immediate vicinity there are two known cemeteries.  One is the well-known chamber tomb cemetery (C494) at the eastern edge of the Klauss vineyard.  The other (C500) is of tholos form and located at the west edge of the hill on which sits the Klauss winery.  The first  use of this tomb is given as LH II.

Two additional cemeteries are nearby and it is thought probable that they are associated with C3148 or C7531.  The first of these is Hagios Konstantinos Α (C5009) and the second is Hagios Konstantinos Β (C7532).  Panagiotopoulos suggests that the chamber tombs here were used from LH IIIA to C.

Saturday, May 7, 2022

Where are the Chamber Tombs of Achaea Klauss? (C494)

 For a long time the Mycenaean Atlas has contained a location for the chamber tomb cemetery at the winery in Achaea called 'Achaea Klauss'.  This is C494.  However I have never been entirely certain of this position.  Many archaeologists have worked at Achaea Klauss but they have all been decidedly cagy about exactly where the chamber tombs were located.  For example Papadopoulos says this:

"At the north-west foot of the steep hill Koukoura (east of Eglykas in the neighbourhood of the wine factory Achaea-Klauss and ancient Antheia) is a small field belonging to A.K. Skondras.  Kyparisses excavated twelve chamber tombs - variously called "Klauss", "Antheia", or "Skondras" in the PAE reports - and some others were found plundered."

While I'm sure that 'A.K. Skondras' is a fine and honorable person as well as a credit to the Greek nation it doesn't help us to know that these chamber tombs are on his property unless we're able to visit the land registry in Patras.[1]

A map of the area looks like this: 





In the center is the large vineyard which lies behind the Klauss Winery (the orange roofs in the upper center left).  Pleiades places its marker for the chamber tombs in the center of the field.  Topostext puts its marker on the road just to the S of the winery.  My long-standing marker (C494) which is in the lower center right of this  picture is at the SE corner of the vineyard and in the woods.  Which of these, if any, is correct?

I just recently ran across Paschalidis [2018] and while he and his team are just as cagy about the exact location as all other archaeologists he does let the mask slip just a bit and the result is a much more reliable location for Achaea Klauss.  In that work (Fig. 5 on p. 8) he  publishes the following photograph:


The caption reads "Fig. 5. The vineyard of Achaea Clauss wine factory as it looks from the cemetery site (from southeast)."

Crucially this picture is taken from the chamber tombs.  This photo shows the east front of the Klauss complex, most notable are the two towers on the left.  I reproduced this view in Google Earth in the next picture:



I drew in approximations for the towers along with a yellow line to join the towers along with the east face of the winery.  I then led the red line from the winery face back to the observer.  Let's see where that red line ended up.



In this photo from Google Earth the Klauss winery is in the lower center.  The red line is the axis along which the previous picture was shot.  When we follow that red line from Klauss buildings to the foothills we find the location from which the shot was made.  That looks like this:



On the right-hand side of this picture is the location of the Achaea-Klauss chamber tombs.  Let's blow up the right side and see where the photograph was taken from.




And right at that point there is a large structure.  I don't know that that structure corresponds to the archaeological dig but it is not inconsistent with it.

At any rate I have now moved my point for C494 in the Atlas and I have much more confidence in its new location.

FOOTNOTES

[1] A long-time bugbear of mine.  See this.

BIBLIOGRAPHY

Ålin [1962]:  Ålin, Per. Das Ende der mykenischen Fundstätten auf dem griechischen Festland. Carl Bloms Boktryckeri A.-B., Lund, 1962., 'Koukoura', pg. 63.

Åström [1965]:  Åström, Paul. ‘Mycenaean Pottery from the Region of Aigion, with a List of Prehistoric Sites in Achaia’, Opuscula Atheniensia, V, pp. 89-110, C.W.K. Gleerup, Lund, 1965., 'Koukoura.', pg. 104.

Giannopoulos [2008]:  Giannopoulos, T.. Die Letzte Elite der mykenischen Welt: Achaia in mykenischer Zeit und das Phänomen der Kriegerbestattungen im 12.-11. Jahrhundert v. Chr.. Bonn: Habelt. 2008., 'Clauss', pg. 55.

Kaskantiri [2016]:  Kaskantiri, Sophia  ΤΑ ΜΥΚΗΝΑΙΚΑ ΝΕΚΡΟΤΑΦΕΙΑ ΣΤΙΣ ΘΕΣΕΙΣ ΖΩΗΤΑΔΑ ΚΑΙ ΑΓΙΟΣ ΚΩΝΣΤΑΝΤΙΝΟΣ ΣΘΝ ΚΡΗΝΕ ΠΑΤΡΩΝ, ΔΙΔΑΚΤΟΡlΚΗ ΔΙΑΤΡΙΒΗ, ΙΩΑΝΝΙΝΑ 20Ι6   Online here.

Papadopoulos [1979]:  Papadopoulos, Thanasis J.. Mycenaean Achaea; Part 1: Text. Paul Åströms Förlag, Göteborg, Sweden. 1979. Vol 1., '12. Klauss (Koukoura, Antheia)', pg. 27.

Paschalidis [2018]: Paschalidis Constantinos, The Mycenaean Cemetery at Achaia Clauss near Patras: People, material remains and culture in context.  Archaeolpress Publishing Ltd. 2019.  ISBN: 978-1784919191                   This book retails for more than $100.00 but I was able to read it for free on play.google.com.  Even if you have to pay for this book the price is still only about $22.00 for this e-books version.  Find it here.

Simpson [1981]:  Simpson, Richard Hope. Mycenaean Greece. Park Ridge, New Jersey: Noyes Press, 1981., 'D 29 Koukoura', pg. 90. Online here.

Simpson and Dickinson [1979]:  Simpson, Richard Hope and O.T.P.K. Dickinson. A Gazetteer of Aegean Civilization in the Bronze Age, Vol. I: The Mainland and the Islands. Paul Åströms Förlag, Goteborg. 1979., 'B 44 Koukoura (near the Achaia-Klauss factory)', pg. 87. Online here.



Monday, March 28, 2022

Do Not Use the Pleiades Data Set

 

The river Quartaccio is a brook (described as 'fossa') just near Marina di San Nicola on the Lazio coast of Italy. This brook diverges from the Statua (another brook) at 41.9298 N, 12.135 E and flows N towards the town of Quartaccio and Valcanneto. Along this brook at about 41.9356 N, 12.1381 E a modern road crosses it. This is approximately the position of a Roman bridge which is given no name. This bridge is marked at this place in the Barrington Atlas (Map 43, A2, no. 2).   Here's what it looks like in Google Earth:



All in all it took me about half an hour to trace down the right Quartaccio (there are several) and take a stab at the position of the bridge based on the Barrington Atlas.


In Pleiades this bridge is no. 426578 and its position is given by Pleiades as 41.875 N, 12.125 E which is in the Tyrrhenian some 3.69 km. from the nearest land and 6.83 km from the putative bridge.  See it at the bottom of the next photo:


Now these gross errors of placement in the Pleiades data are nothing new. I looked at five examples last time and I attributed them to careless digitization and the complete lack of any quality control.   I did notice that Pleiades puts their accuracy estimate for the Quartaccio Bridge as 'Rough'. I thought, 'Aha!',  if I can see what 'Rough' means to the Pleiades group then maybe I can see  how far the  problem goes.   I got the 'Rough' points out of the database that I made from Pleiades' data and plotted that on Google Earth. There are about 5000 points labelled 'Rough' in the Pleiades DB. I used a select to retrieve the first 3000 of these (about 1/10 of the entire Pleiades DB). Here's the result of plotting these 3000:



This is shocking.  

Even if the location of these sites was not known (most of them are known as I will show) Pleiades has made no effort to place them even approximately.  These points are simply dumped off at the nearest half-degree or quarter-degree vertex.  Nothing else could make such a pattern.

And most of these points are not singles.  They are multiples of 5 to 10 distinct locations which are simply dumped on top of each other. All these sites have simply been rounded to the nearest degree or half-degree. And most of these points are easily locatable. When I was criticizing P. for errors I truly believed that the number was, perhaps, about 100 points. Now I see that it is thousands of points that could be known but which are simply dumped off at the nearest vertex.

Greece looks like this:




I've said that many of these points are just carelessly dumped in a pile even though the locations they denote are easily locatable.  Here's an example.  In the Corinthian Gulf Pleiades has overlain six points at 38.25 N, 22.25 E.



I've drawn red lines from the vertex where they were dumped to their real locations.  The line drawn to Phocis is drawn to the nearest point of land in Phocis.  The lines from the  rivers are drawn from the mouths of the respective rivers.  The Styx is the modern Mavronero above Solos.  The village of Solos is marked.  Every point was easily locatable and the average error is 13.9 km.  

In Pleiades-world four rivers, an entire province, and a gulf are all in exactly the same location.   All of their 'rough' points are exactly the same.

I can think of no toponymical practice that can explain this pattern.  What's absolutely clear is that the Pleiades data set has no conceivable use for any scholarly purpose.   

The Pleiades data set is approaching twenty years of existence.  In that time the P. team had plenty of time to fix these gross errors.  I concluded long ago that Pleiades never had any interest in creating a scholarly (or even a reliable) map of the ancient world.  Soon I will dedicate one of these posts to discussing what I think their real interest is.

The Pleiades data is unsuitable as a reference.  

It is unsuitable for study of the Ancient World.  

It is unusable as a basis for developing further geographic tools.

Pleiades owes the scholarly community an explanation of why their data so bad and what they intend to do to rectify this very poor database.









Monday, March 7, 2022

Lies, Damn Lies, and Digitization


So about the year 2000 the data which now makes up the Pleiades 'database' was created by digitization either from Barrington Atlas maps directly or from maps that were contributory to the Barrington Atlas.  This data has not been looked at, proofed, or corrected since that time.

How do I know?

Let's take a look.

On the coast of southern Laconia a small peninsula juts out into the Aegean.  For centuries it has been the home of the community of Monemvasia - a world-renowned tourist destination.  In antiquity it was called the promontory of Minoa.  Its location is 36.683 N and 23.05 E.  I show it here as it appears  in the Barrington Atlas.




Pleiades has 'Minoa Prom.' in a very different place: 36.75 N and 23.25 E.  How far is the real Minoa Pr. from the Pleiades marker?  More than eighteen kilometers and smack dab in the middle of the ocean.  Here it is in Google Earth:



The distance between the two is more than 18 km.

Now I'm not picking on Pleiades because of this one error.  There are lots of errors in my own Mycenaean Atlas.  I have made errors of commission, omission, faulty reasoning, and pure ignorance.  I know this because I sometimes catch them.  This error of Pleiades', however, is something different.  Failure to see this glaring digitizing error results from never actually working with their own data - a dataset which has been in existence for more than twenty years.  

There are more examples of failure to catch digitization errors:

Pleiades 603253 is described as "An ancient place, cited: BAtlas 61 E4 unnamed quarry (on Horomedon M. on Kos)"   Pleiades locates it in the middle of the strait separating Kos from the Turkish mainland.  This is about 8.7 km distant from its true location which is shown on the Barrington Atlas at about  36.8312 N,  27.234 E.  This is how it looks in Google Earth:


Mt.Dhikeos on Kos is the ancient Horomedon.  The radius of the circle centered on Pleiades 603253 and extended to the quarry's approximate location in the Barrington Atlas  is ~8700 m.  

Pleiades 570688 is called "Spiraion Pr." and placed at 37.75 N, 23.25 E, in the middle of the Saronic Gulf.  The true location of Spiraion (the modern Spiri) is 37.8025 N, 23.1754 E, about 8500 m. distant.  Topostext (green arrow) places it correctly.


The Mycenaean Atlas Project's new Digital Atlas of Antiquity.
Pleiades position (red arrow) is about 8500 m. from the
true position (green arrow) where the Topostext marker is.

The ancient Grotta was located where the Chora of Naxos is located now, at 37.1084 N, 25.3748 E.  Pleiades (599630) has it in the middle of the bay at 37.1129,  25.3783 just over 500 m. distant.  This error, though very minor, is a particular clue because it was digitized accurately.  The Barrington Atlas shows it in the middle of the Bay (in order to print clear of other labelled places) in the very place Pleiades shows it.  But no one caught this error when going from printed map to digitized data point.

The harbor of Naxos with Pleiades 599630 in the middle of the bay just as depicted in the Barrington Atlas.


Pleiades 585129 described as "An ancient place, cited: BAtlas 59 B3 unnamed wall (Phalerikon Teichos, Leophoros Syngrou)" is shown deep in the Saronic Gulf at 37.875 N, 23.625 E which is about 8700 m from the nearest part of the Phaleron wall.    

The Piraeus.  End of the Phaleron wall at green. 
Pleiades 585129 in the middle of the bay (red).




I found these problems in just a few minutes because the Mycenaean Atlas Project is now offering a way to see the entire Pleiades data set.  I anticipate running across many more of these digitizing errors.

At one time I thought I saw a curious error signature in Pleiades' data.  There appeared to be two different values around which their errors tended to cluster which made the error distribution bimodal.  We even see that a little bit here.  Three of the five values I've noticed here are about 8500-8700 m. off.  This has to be a regularity.  I was puzzled by this at the time I first saw it and yet now I may have discovered the reason.  I suspect that Pleiades digitized their data from maps of different scales.  Errors would be greater on small-scale maps and smaller on large-scale maps.

What factors might be responsible for Pleiades' lack of interest in their own data?  There are several.

1. Size.  The Pleiades database (if that's the word I want) contains nearly forty thousand items.  The consensus among people who work in creating maps of antiquity is that it takes at least one hour per data point.  Often it takes five or six hours.  In six years of steady work on the Mycenaean Atlas I have mapped about eleven-thousand sites both modern and Bronze Age.  A man-year is 2200 hours.  Six man years is 13200 hours.  So: 1.2 hour per site.  Using the same number of 1.2 hours on 38000 sites (the size of Pleiades' database) suggests that it would require 20.72 man years to validate the sites in the Pleiades DB.  Who has that kind of time?  It's clear that when the Pleiades managers were faced with this potential cost they decided that what they had was based on the Barrington atlas and so the raw digitized data was great.  Pleiades as a scholarly endeavor was never in the cards.

2. Pleiades appears not to have their data in a true database.  They provide downloads in several different formats: .csv, .kml, .json, .xml, .turtle, etc. but no .sql or anything that looks like true DB output.  I created a true relational DB from their data in about four days but I had to use their .csv version.   If I'm right in my opinion that there is no true relational DB behind Pleiades then it means that their basic representation of all this data is just incredibly long lists, probably in .json format.  If that's true it might  explain the instability of their Peripleo product.  There is a lot of talk on the Internet about .json  databases.  That's a contradiction.  .json formatted data is just a heap of data, not a database.  It has none of the advantages of a DB and all of the disadvantages of a verbose, over-inflated list, including long run times which get longer as the list gets longer.

3. Lack of interest.  I have read a number of the Pleiades papers over the years.  From these papers it is obvious that the Pleiades team's real interest is Computer Science.  Their primary focus is the netherworld of symbol-based Artificial Intelligence where computers are 'semantically aware' and new knowledge is always just one Improved Reasoner away.  It is a world of religious belief, of the faith that moves mountains and in which continued funding is the new version of everlasting life.  It's not that they don't talk much about toponymy - they don't talk about toponymy at all.

4.  Inability to easily see their data on a map.  It's not clear to me that the Pleiades team ever had
decent tools for looking at their own data.

Soon, perhaps next time, I'm going to put the Pleiades enterprise into perspective and try to explain what they're really doing.








Tuesday, February 22, 2022

 ... by their fruits ye shall know them.

Matthew 7.20

Tom Elliott and Valeria Vitale, two members of the Pleiades team, have left us imaginary visions of what it is that they hope to achieve through their software initiative.  These statements, the first from 2009 and the second from 2021, reveal in  exciting detail what kinds of software they hope to produce.  I  quote a bit from each but their entire statements are worth reading and I urge readers of this post to do so.
  1. "As I settle into my chair, a second cup of morning coffee in my hand, an expansive view of the eastern Mediterranean fades in to cover the blank wall in front of me. It's one of my favorite perspectives: from a viewpoint a thousand kilometers above the Red Sea, you can look north and west across an expanse that encompasses Jordan, Egypt and Libya in the foreground and Tunisia, Calabria and the Crimea along the distorting arc of the horizon. A simple voice command clears some of my default overlays: current precipitation and cloud cover, overnight news hotspots, and a handful of icons that represent colleagues whose profiles indicate they're currently at work. Now I see a new overlay of colored symbols associated with my current work: various research projects, two articles I'm peer-reviewing and various other bits of analysis, coding, writing and reading. These fade slowly to gray, but for two. Both of them are sprawling, irregular splatters and clumps of dots, lines and polygonal shapes." [1]
  1. "As we settle into our chairs for the monthly meeting of the Early Islamic Interest Group, some with a second cup of tea in hand, the Chair’s voice assistant brings up the ‘Pelagios Network spatial feed’. An expansive view of the Mediterranean appears on our screens, with current weather patterns, the latest research publications and colleagues’ avatars briefly appearing above their respective locations – Egypt, Tunisia, Italy and Cyprus among them. These are, however, quickly replaced by a layer of content reflecting the main business of the day: a regional museum in Libya has digitally published their numismatic collections with associated spatial data. Reem Fathi, the museum’s curator, introduces her team’s work and begins by displaying the distribution of the early Islamic coins. Their alignment with settlements along the Cyrenaican coast, hinterland and adjoining islands is immediately apparent. Now the fun begins."  [2]

It is a remarkable fact that when Elliott (1) and Vitale (2) are deprived of the use of computer buzzwords and jargon they are capable of describing what they want with startling clarity.   Two observations:

a. It really would be tremendous to have such powerful tools.

b. How extraordinarily sad it is that they have staked their entire effort on the one software approach that has not produced, and can never produce, the results they want.

Their total and absurd commitment to the concept of the Semantic Net (the computer equivalent of spinning straw into gold) has driven them into an epistemological corner such that after having spent millions of dollars in grant money over the last decade (It was north of 2 million USD when I added it up 4 years ago) they have given the Humanities community three things:

a. bad data (Pleiades)
b. non-working product (Peripleo)
c. do-nothing software (Recogito)

They are now at an impasse.  They have no success to show and no way forward.  Their only hope is to get other projects to re-engineer themselves into Pleiades' semantic net.   By convincing others to change themselves, instead of Pleiades changing itself,  Pleiades gives the illusion of activity and obscures the fact that, as currently managed, it has no hope of accomplishing its goals.

In the meantime the Pleiades team continues to spawn a tornado of papers couched in a nearly impenetrable computer jargon (I give a lexicon of this rubbish here) which gives the illusion to naive Humanists[3] that the Pleiades team is Doing Something Really Important.   Vitale et al. [2021]'s restatement (twelve years later) is nearly identical to Elliott's original thus exposing that their progress towards accomplishing their stated goal has been precisely zero.

How have things come to such a pass?

As a former computer professional myself it's easy to recognize the signs of a disaster in the making.  Aside from the two statements I reproduced above I have seen no other example of their ever having performed what professionals call 'Use-Case Analysis'.  It is here that designers put down in great detail exactly how the final product is to be used and what specific abilities it will give the user/operator.   From the Use Case flows the requirements document which details the specific things that the resulting software must do.  And not only the software is involved but requirements also directly control database design.  Database design is carefully specified in documents of its own and these are keyed to the software documents.  You won't be able to fulfill a DB query if the DB itself doesn't support what's being asked.  The P. team might respond with such piffle as 'that is the old stodgy way of doing things and that such formal documents only get in the way of creativity'.  

But it is exactly the 'compute first, figure it out later' mentality of Pleiades that is the old stodgy way of doing things.  

Understanding the design specifics by creating detailed and shareable documents represents hard-won knowledge consequent to many expensive failures.

The primary problem here is either poor software management or, more likely, none at all.  Lack of transparency, cost overruns, extraordinary amounts of development time, over-promising, under-delivering, etc., etc.  Believe me, I've seen all these pathologies before.

Pleiades' current problem is that the more projects they convince to come on board the more likely it is that these project leaders will start to ask embarrassing questions.   Questions such as 'why should we expose our data for your benefit  and how does this benefit us?', 'Why doesn't Pleiades/Peripleo give useful results even though we expended the time and resources to reverse-engineer our own project to fit it?'  As more time goes by the  leaders of the Pleiades/Peripleo effort will be less and less able to give satisfactory answers to these legitimate questions.

I. The disappointment of Pleiades becomes all the more acute when we compare it to an initiative that deals with exactly the same subject matter, namely, The Levantine Ceramics Project[4], which, as websites go, is a thing of beauty and has not cluttered up the design process with Semantic Net jargon and simply gotten on with it.

II. If the  Pleiades team had chosen a professional approach they might very well have accomplished what they wanted to.

What then must we do?

Questions will inevitably arise concerning what Pleiades is delivering to the Humanities community for all the money that they have spent.  The day of reckoning must eventually come.  There are real reasons for concern that Pleiades is freezing into a kind of fetal crouch.  They have no way forward.  I have heard, although I do not know for a fact, that they have exhausted their funds - which seems incredible to me.  Peripleo, their flagship product, has been down at least since November.  It is down as I write. [Although down through most of February, as of 2/22/2022 at 10:18  PST it has come back up.]  It came up briefly at the end of November and I noticed that all their links to the British Museum database were broken.  This was a good indicator that the system is unstable and breakage-prone. That seems to be what led to their next down-period.  Pleiades appears to have no infrastructure in place in the form of any sort of team that can react to problems in real-time.  We must anticipate further such disruptions in Peripleo's service.  I see on GoFundMe many archaeological projects begging for tiny amounts of money in order to carry on their work; amounts like five hundred dollars to fund the rental of a storage shed for finds.  And yet Pleiades/Peripleo has received millions in grant money to produce products that are inappropriate for scholarly work.

Remedial steps need to be taken and the sooner they are taken the better the possibility that Pleiades can recover.  If nothing is done to restrain them in their course their inevitable embarrassment and collapse will be all the more stark.

I, like Elliott and Vitale, have a vision for the future.  It consists of the following four recommendations.

(a) The Pleiades team needs to explain to the Humanities community exactly what it is trying to do that will benefit the community; e.g. what computer/software faculties are gained for the community which did not previously exist.  It needs to do this in a transparent manner and without resort to the computer buzzwords or formalisms with which it has cloaked its work so far.[5]  The PT needs to prepare a set of Use Cases that detail how their end product will be used. 

(b) The Pleiades team needs to be very clear about the state of the licenses of its  own products as well as the licenses of those who have contributed their data to the Pleiades backbone. 

(c) The  Pleiades team needs to make a public pledge that it will never seek to sell or license the Pleiades technology to any customer, particularly schools, museums, or universities.  In particular it will not bundle and sell data and projects that were donated to them by other teams.  If the ultimate plan of Pleiades is to sell or lease its technology (and, yes, these things have happened) then they need to be transparent about that fact and transparent about what use they intend to make of the data from those forty or so teams that freely contributed to Pleiades/Pelagios/Peripleo.  For example, will their contributors be compensated?

(d) The Humanities community (AIA?, SCS?) needs to appoint an independent working group to evaluate Pleiades' products for utility and likely usefulness for workers and projects in the disciplines of Anthropology, History, Toponymy, Classics, and allied disciplines.  One emphasis should be on how much the product has cost vs. what it has delivered.  When that working group has completed its study it should prepare an open and clear report about what they have learned and make this a formal recommendation to the National Endowment for the Humanities which has provided the bulk of Pleiades' funding so far.

Next time:  What use should be made of Pleiades (non) database?

Footnotes
  1. Elliott and Gillies [2009], first paragraph.
  2. Vitale et al. [2021] 5.  This is the first part of the first paragraph.  
  3. I mean no insult by the phrase 'naive Humanists'.  Indeed, why should workers in the Humanities be expected to be computer experts?    But the inescapable fact that they are not experts makes Humanists an inviting target for schemes such as Pleiades'.
  4. Online here.
  5. See this post for a lexicon of 'Pleiadese'.


Bibliography

Elliott and Gillies [2009] : Elliott, Tom and Sean Gillies.  'Digital Geography and Classics', Digital Humanities Quarterly(3:1) 2009.  Online here.

Vitale et al. [2021] :  Vitale, Valeria and Pau de Soto, Rainer Simon, Elton Barker, Leif Isaksen, Rebecca Kahn.  'PELAGIOS – Connecting Histories of Place. Part I: Methods and Tools'.  International Journal of Humanities and Arts Computing 15.1-2 (2021): 5–32.  Online here.

Sunday, February 20, 2022

An Electronic Barrington's Atlas. A New Feature in the Mycenaean Atlas Project

 The Mycenaean Atlas Project is happy to announce that it is now possible to see several well-known geographic databases side by side on the same map.  These databases, right now, are the complete Pleiades dataset, the harbor dataset from Arthur de Graauw, and the Topostext dataset from Brady Kiesling.  

Here's what the area of the Piraeus looks like on the new page which I call 'Coverage':

Area of the Piraeus.  Click on map to enlarge.

The key here is 'P' : Pleiades, 'H' : Arthur de Graauw's Harbor site, 'T' : Topostext and the blue paddle is from the Mycenaean Atlas Project.  When you mouse over these icons the tool-tip giving the id no. as well as the name string (if there is one) appears.  When you click on an icon you will see an info box with a link to an appropriate page that gives more info about the site.

The Topostext icons provide a link to the relevant Topostext page.  The Pleiades markers link to the appropriate Pleiades page and the M.A.P. markers link to the right page in the Mycenaean Atlas.  The geo-locations marked with an 'H' link to Arthur de Graauw's splash page only.  It is very unfortunate that M. de Graauw does not have a more significant web presence.  In my view he should be able to provide individual pages for each of his harbor sites.  If these existed then I would happily link to them.

Currently your access to this product is through the M.A.P. Place Key Report page.  On that page you pull down the toolbox drop-down and select 'Coverage'.  When you do that the Coverage page appears with your site in the center.  


Arrow pointing to Coverage Page selector

In this picture the arrow points to the 'coverage' selection on the tool box menu.  This is the Place Key Report page.  The lat/lon center of the coverage page will be the lat/lon position of the site currently being examined.  This is site C1232 for Cape Manika on Euboea.

There is a third parameter to the page which governs how wide an area is searched and shown.  This value ranges from 0.01 to 0.09 and represents fractions of degrees.  0.01 searches a rectangle about 2 km in width and 0.09 searches a rectangle about 18 km in width.  The coverage page is currently defaulted to 0.09.  

The ability to display these datasets on the same map creates what all of us have wanted for a long time - a complete Digital Atlas of the ancient world which covers time periods from the Early Bronze Age to the early Medieval period.   And it is fascinating to look at the several perspectives about what such an atlas should include as seen by the different contributors.

Area of Chalcis on Euboea

de Graauw's harbor markes cluster on the coasts or in the watter.  Topoguide seems to have conentrated on Roman ruins in Chalcis.  Pleiades' coverage here is sparse.  Mycenaean Atlas blue paddles are mostly not where anyone else's are (Bronze Age, don't you know?).


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now I need to say  some stuff for legal purposes:

Locations associated with an  are the work of Arthur de Graauw and are used with permission (bottom of page).   His site is called "Ancient Coastal Settlements, Ports and Harbours" and is found here.  When a link associated with a  is clicked on the user will be on the splash page of M. de Graauw's site.

Locations denoted by a  are the work of Brady Kiesling and are used with permission. As he says: "Linked Open Data Files for use with appropriate attribution to ToposText."   His site is called "Topostext" and is found here.  When a link associated with a  is clicked on the user will be on the Topostext site.

Locations denoted by a  are the work of the Pleiades Project and are used with permission. Their site is called "Pleiades" and is found here.  As they say: "Using, sharing, and remixing of the content is permitted under terms of the Creative Commons Attribution 3.0 License (cc-by)."  When a link associated with a  is clicked on the user will be on a Pleiades page.


Each geo-location marker provides a pop-up info box with a link.