Thursday, November 10, 2022

The Commentary on Pleiades

 The Mycenaean Atlas Project is more than just a Bronze Age gazetteer.  It is an accessible viewer for the entire ancient world - and at every period. It accomplishes this goal by integrating several very different data sets.  Here's an example:


The city of Aigion in Achaea as displayed in the Digital Atlas

One of those data sets is Pleiades.  But how do you handle or display a dataset with as many serious defects as Pleiades?  Its deficiencies are of three kinds.  Of Pleiades' approximately 39,000 records about 7,000 have no lat/lon coordinates at all.   As a result, these points cannot be displayed at all and  why they are in the dataset in the first place is a mystery.

Pleiades next problem is the 5,000 or so sites for which the lat/lon pairs are rounded to the nearest quarter degree.  This indefensible practice (and never corrected during the entire 20-year existence of this DB) puts these sites off by about 12 km. on average.  Even worse, it creates about 400 or so 'stacks' in each of which some 10 to 20 sites have exactly the same rounded coordinates and cannot be disambiguated.  (See the example of Boreion, below.)

The remainder 26,000 sites are simply inaccurate.  They are off by about 900 m. on average because this part of the DB was intended for the Barrington Atlas - a printed product in which accuracy, at the given scales, could never be better than a km. or so.  Accuracy is expensive and you never pay for more than you need.  This practice was fine for a printed product but a disaster when moved to the digital world in which representable locations are accurate to less than a meter.  The need to develop precise and accurate data for the digital world is far more urgent than it is for the world of the printed atlas.

When showing Pleiades data in a gazetteer viewer such as the Mycenaean Atlas Project the overwhelming temptation is to correct these numerous errors by adding additional information to the Pleiades data. Providing accurate lat/lon pairs is a chief priority.  The design problem is, somehow, to add that information in a way that new versions of the Pleiades database don't write over what people external to Pleiades, such as myself, have added.  How do we best add and store supplemental and updated information for Pleiades sites and how should this new data be displayed?

What is required is a Commentary on Pleiades.

      To support this Commentary I created a new DB table that would hold any additional information or corrected lat/lon pairs.  A table that is independent of the Pleiades database would not be overwritten by new versions of the Pleiades database.  It would exist alongside the Pleiades DB. And yet the new data in this table could still be connected to the old Pleiades database through the Pleiades id no.  That way if there was an entry in the new table for any specific Pleiades site record my browser would display THAT corrected/additional data instead of the incorrect Pleiades data.  This required that I accompany my new DB table with a new browser page in .html.  This will be the new Commentary on Pleiades page which stands between my viewer and Pleiades itself.  In addition to corrected information this new page maps the Pleiades places to their correct location on a new map instead of to the incorrect rounded quarter-degree locations where they are now displayed.


Design of old and new interaction with Pleiades.


The upper half of this diagram shows the current situation; the Mycenaean Atlas Project takes information from the unmodified local copy of the Pleiades database and displays it.  That display has a button that, when clicked, takes the user back to the original Pleiades page for more information.

The lower half of the diagram shows the new design.  In addition to the local copy of the Pleiades database as before (orange), there is a brand-new table that contains my own contributed material.  On the browser map, when the user clicks the Pleiades icon for more info they don't go to the Pleiades page as before but to the new Pleiades Commentary page that shows the corrected lat/lon pair along with more info and a browser map that shows the icon in its corrected position.  A link on that supplemental commentary page will send the user to the original Pleiades page (dashed line).

This whole process is transparent to the user who will only see the new commentary page when he or she clicks on a Pleiades place for which I have created commentary. 

The new Pleiades Commentary page will look like this (annotations in red):


The new Commentary on Pleiades page (here for Belminatis, Pleiades 570152).


Now I'd like to show a situation in which this commentary is invaluable.

Mt. Boreion in Arcadia is Pleiades 570158.  Pleiades gives its position rounded to the nearest quarter degree like this: 37.25, 22.25.  This is exactly the same position as seventeen other Pleiades sites.  I list them here:

Pleiades grouping 18 sites at the very same location: 37.25 N, 22.25 E.

This sort of practice is common in Pleiades and it must be corrected.  Even a casual user does not deserve to have all these sites shown in the identical location.

I corrected the rounded position of Boreion (37.25 N, 22.25 E) to  37.429300°,  22.342900°.  On the next map I compare my position, Topostext's position, and  Pleiades position:

Placement of Mount Boreion (Attica) in Pleiades, Topostext, and Mycenaean Atlas Project.


I have not adopted Topostext's position here but the rounded Pleiades position (at the bottom of the map) is 21 km. from my proposed location and almost 19 km. distant from Topostext's. 

My Commentary to Pleiades will change all this. If you search for 570158 or 'Boreion' and display it on the digital atlas you will be shown this next page (Be sure to select 'Pleiades' layer from the (not shown) map layer selector on the top right):

Mt. Boreion (Pleiades 570158) displayed in correct position.



The top link in the info box ("Pleiades (S) 570158") will not bring the user to the main Pleiades page for 'Boreion'.  Instead the new Pleiades Commentary screen will be displayed:


Commentary on Pleiades - supplemental information page


My goal for the future is to correct all the locations whose lat/lon coordinates have been rounded.  For the Peloponnese alone this amounts to about 160 such rounded markers.  Presently there are about 150 corrected Pleiades sites (primarily for the Peloponnese) and the work of adding corrections to Pleiades will be ongoing.












Tuesday, November 8, 2022

Pleiades' pages and how to fix them

 How Pleiades pages look:


If ever there was a mutual appreciation society that society is Pleiades.  Look at all the bloviating thank-yous and credits-given on the left side of this window.  No user cares about that and all this extraneous info should be relegated to a secondary page that users can look at if and when they want to.
The map is way too small.  I mean, the map is what it's about, right?  Unless naming the several  Pleiades honchos over and over is the actual purpose of Pleiades ... that couldn't be the real purpose could it?
With respect to the map panel (which is way too tiny to be useful) we're zoomed in so far that context is lost. What can P. do about restoring that context?   Even for a specialist it's easy to forget exactly where we are.  And don't get me started about the annoying zoom-in-from-outer-space (ZIFOS, tm) which is cool and kicky the first time you see it but is actually a time-waster and the fiftieth time makes me -like Oedipus - want to scratch out my eyeballs

How Pleiades pages should look:


In the revised version we've done away with the annoying zoom-in-from-outer-space and settled on a nice large map.   Context which is lost by being zoomed-in is restored with the new spotter map which you see on the upper right.  The spotter map is zoomed out (level 4,5?) so that you can tell at a glance where you are in the world.

All the ridiculous back-scratching, log-rolling, and mutual thank-yous are moved off to one of the tabs on the top.  Users can click on that tab if they want to see whose bright idea this site was but - spoiler alert - they won't.  I left the bibliography off of this new map but there is room for one or a button that will pop the bibliography up on a new window.  New windows for subsidiary purposes are easy to write and not enough advantage is taken of this idea.

And, in fact, now that I look at it, we should lose the right-hand side margin which is crapped up with stuff that could easily be buttons.  How about this:

The new and improved, user-forward, Pleiades page!

Lean and mean.  No wasted space.  User's needs are foremost.  The search field has been moved to where it belongs and is enlarged so as to be actually visible.  Do you see the new Credits button?  No?  Good.

Instead we have something actually useful which is a new bibliography button.  When you click on it you get a simple bibliography page (not shown).  Now if  Pleiades would just fix all the broken bibliography links and then link to something actually useful instead of a Zotero page.

Next, On to Peripleo!  If it ever works.

Monday, November 7, 2022

The Pheneos Plain and the location of Lykouria

The town of Lykouria was only ever notable for the fact that Pausanias once passed through it and there are few or no other mentions of it in antiquity.   Its isolation explains this.  It is set in northern Arcadia, surrounded by mountains, and sitting on the edge of a remarkable karst landscape (the plain of Pheneus) to which there is no easy entrance or exit.  Let's go to the map.


The area of the Pheneos Basin in N. Arcadia.


The Pheneos Basin in more detail.  Lykouria was located somewhere on the southwest edge of the valley, and just to the north of the jagged white line in the lower left that indicates a road.

The Pheneos Basin from the SE and looking NW.  Lykouria was located somewhere by the center left corner of the superimposed line map.

Here's what we know about Lykouria.  In Paus. viii.19.4 we read "One of the roads west out of Pheneos I have still to deal with, the one on the left, which leads to Kleitor, past Herakles Labour, the channel he made for the river Aroanios.  Beyond that point, the road goes down to a place called Lykouria, which is the territorial boundary of Pheneos and Kleitor."[1]

Let's look at each of the bolded names in turn:
Pheneos (ID: F7322): An ancient town of Arcadia situated in the NW corner of the Pheneos Plain.

The hill on which Pheneos was built is in the center of this image.  
Here S is to the lower left.



Kleitor is Pausanias' destination.  What geographical relationship does it have to Pheneos?




This map shows the route Pausanias takes.  He starts at Feneos and travels more or less along the blue line and reaches ancient Kleitor.  The distance is about 26 km; a day's trip perhaps.  The town of Lykouria is somewhere near the end of that first leg just before it bends to the SW and descends into a valley.  Can we be more precise?

In the very next paragraph (viii.20.1) Pausanias says this: "Six miles or so from Lykouria you arrive at the SPRINGS OF THE LADON.  I had heard that the water of the Phenean lake which drops into the pot-holes in the mountains comes up again here to form the springs of the Ladon."[2]

The Ladon is a major tributary of the Alpheios which it joins (at  37.593682° N,  21.820481° E) from the N and just above the complex at ancient Olympia.  The primary source of this river is a spring at F7315.  Here is a user-submitted photo of the Spring.

Springs of the Ladon where they emerge from underground at F7315.
Original  work of Chris Karagounis.  All rights reserved to the creator.

The Pheneos Plain forms a basin at an average elevation of about 750 m. sloping down to about 710 m. at its S end.  Any water that enters the plain (which it does from the N) exits from the south by the way of sinkholes or katavothrai.  The water that leaves the Pheneos Plain reemerges at this spring and from here it becomes one of the major contributors to the Ladon river.  This spring at F7315 has an elevation of 475 m.  The distance to the katavothrai is just about 9 km. or 5.66 miles.  In that distance the waters to the spring fall about 235 m. or 771 ft.  This is about the height of a 72-story building.

So  Pausanias says that the Spring and the town of Lykouria are about 50 stades distant from each other.  All we have to do is work backward from the Spring about 50 stadia and we should be in the region of Lykouria.  So how long is a stadion?  A stadion was a rough and ready estimation of length and it varied from about 157 m/stadion to 209 m/stadion.   I gathered various stadion equivalents from sources around the internet and put them into this table:


These values of m/stadion have a standard deviation of 14.175 m.

I could think of no better solution than to take the average of 185.4 m/stadion.  This would suggest that the distance Pausanias traveled was about 5 and 3/4 miles (9.27 km.)    To confirm that that makes sense let's look at the next photo.

Pausanias's plausible route in green (R to L)


Here we see the territory stretching from the Springs of the Ladon to the edge of the Pheneos Plain.  On this map I traced a plausible route for Pausanias in green.  This route goes to the edge of the plain and it is just a hair over 5.5 miles (8.87 km.).  So this suggests that Lykouria is north of where the green path reaches the plain and south of Louzion (F7321).  Levi suggests that 'Pausanias took roughly the track from LOUZION.' [3]

The ancient town/village of Lykouria may safely be placed somewhere on the SW edge of the Pheneos Plain where it meets the hills and between 37.865 N to 37.879 N longitude which is a distance of 0.94 miles or (1.52 km.)  The total area to search would be about 1 square km. (100 ha.) or 0.39 sq. miles.  It looks like this:



Here I removed the vector-map overlay so you can see what the country looks like.  The orange polygon encloses the 1 sq. km. search area.  The two horizontal lines are the bounds in longitude which I referred to above.

This work was undertaken to improve the guesses of Pleiades and Topostext.  Topostext has the location of Lykouria at the Ladon Springs.  This cannot be because Pausanias has already told us that the Springs and Lykouria are 50 stadia distant from one another.  Pleiades, with their usual carelessness, has placed Lykouria on the other (west) side of Mt. Dourdoubana/Pentelia at 37.90495, 22.230895.  I'm not even going to bother to plot that.

There is a modern town of Lykouria in this area which is 3.8 km. from the Ladon Springs.  It has nothing to do with the town/village of ancient Lykouria.  Frazer, when he comments on viii.19.4, says

"The modern village of Lykouria can hardly occupy the site of the ancient place of that name.  For Pausanias's description of the route to it implies that it was situated in the plain of Pheneus, lower down than the city of Pheneus, and that it was on or near the canal.  Moreover, he says (20. 1) that Lycuria was 50 Greek furlongs (5 1/2 miles) from the springs of the Ladon; whereas the modern Lykouria is only 2 1/2 miles (less than 20 furlongs) from the springs."[4]

As it was so close to the head of the valley leading to the Ladon Spring I wonder whether the business model of Lykouria wasn't primarily to provide guides down the risky descent to the Springs and then on to Kleitor.

In another post, I would like to write more about the karst landscape (or polje) of Pheneos but this is enough for today.

Notes

[1] Translation in Levi [1971] 418.
[2] Idem.
[3] Levi [1971] 418, fn. 141.
[4] Frazer [1898] 262.

Bibliography

Frazer [1898] : Frazer, J.G. Pausanias's Description of Greece; Translated with a Commentary by J.G. Frazer. Vol. IV, Commentary on Books VI-VIII., London, MacMillan and Co. Limited. 1898.

Levi [1971] :  Levi, Peter.  Pausanias; Guide to Greece; Vol. 2 Southern Greece.  Translated with an Introduction by Peter Levi.  Penguin Books, 1971.  ISBN: 978-0-14-044226-7.

Friday, September 23, 2022

When is an alona not an alona?



  Recently I've been refining my knowledge of southwest Rhodes - I was never quite confident that I understood what was going on with Ayios Fokas (C1384) and Kymisala (C1383). 

Let's look at the area in Google Earth:



In this image Ayios Fokas is a hill at the upper center (C1384).  Simpson [1981] 197 says "Ayios Fokas was the centre of a considerable settlement in the Classical and Hellenistic periods, despite its elevated and remote situation." and  "The only signs of a possible prehistoric habitation site are a few coarse sherds found in 1970 on Ayios Fokas, including part of a lug of a type resembling Late Neolithic or Early Bronze Age examples ... " [1]  

'Kymisala' is actually the name of a region, here shown in Google Earth in light green.  The C1383 marker sits at the top of this light green area.  This was possibly the remains of a lake but, already in Archaic times, had been converted into farmland, a use to which it is still being  put.  Simpson [1981] says " ... good arable land  ... in the  plains of Kymisala ... " [2]  The C1383 marker is placed where it is to indicate a complex of ancient cemeteries, mostly from the historic period.

I looked into McGilchrist's Rhodes in an attempt to understand what this area looks like today.  He gives a detailed description:

"After a further 4.5km, (1.5km before entering Siána) a track leads west (right) to Steliés (69km), and the empty, southern loop of Mount Akramytis.  Although little visited, there is a large area here— designated with the ancient name ‘Kymisala'— with widely scattered remains of habitation from the Classical and Hellenistic periods.  One kilometre down the track from the junction, on the right hand side, is an open area where the bases of stone walls of houses and other structures, constructed in large blocks, can be seen.  There is considerable overlay of later use, however, and the ancient blocks have in several places been re-arranged in circles so as to create winnowing areas. " [3]

Let's expand the map to show what McGilchrist is talking about:



McGilchrist has already called out a scenic overlook which is at the upper right where I've marked it 'Start'.  He now has us driving S along the lavender segment of the line which is supposed to be 4.5 km until we reach the intersection and the church of Ayios Anastasios (F1956).  At that intersection we turn right, along the green segment, and on those two segments (the green and the second lavender) he draws our attention to some alonia (threshing floors).  Let's look at these in close-up.





Starting at the lower right center with F1956 (Ayios Anastasios) we proceed to the W along the route marked in green.  At the end we encounter, at F7183, the alonia which McGilchrist mentions.  Let's look at these alonia:




This seems amazing to me.  An alona is a threshing and winnowing floor.  You encounter them in most villages in Greece.  They are usually stand-alone although a single village may support three to five scattered around the edges of the settlement.  They consist of circles, perhaps 10 m in diameter, and with a smooth floor of concrete or packed earth.   

Here are pictures of a typical alona (F3342) located at Kerteszi in Achaea.  The diameter of this alona, along the red line in the upper picture, is just over 14 m.

Alona (F3342) at Kerteszi in Achaea. 
Diameter as measured across the red line is 14+ m.
  As seen from above in Google Earth.

Alona (F3342) at Kerteszi in Achaea.  As seen from the road.
Note the (formerly) paved floor.

When grain is harvested, farmers use these surfaces for threshing which is the operation of beating the grain stalks with flails in order to separate the grain kernel from the stalk. [4]  Winnowing is the operation of using shovels (winnowing fans) to toss the grain into the air so that the breeze will blow away the chaff. [5]   There are various threshing methods but when reading about farm societies such as these it should always be borne in mind that threshing and winnowing are the largest consumers of energy on the typical farm.

What is going on here in the Kymisala area is astonishing.  As you can see I have numbered 38 definitely identifiable alonia (and there are certainly more).  Questions: Why are there so many and why are they packed all together?  I can conceive of no reason why alonia would be positioned in this way.  The Kymisala plain is a relatively small area that couldn't possibly supply enough grain in order to keep 40 or so alonia in operation.  The real alonia for the Kymisala plain would have been much closer to where the grain was actually grown.  And why are they packed together?  And another question: why are there no visible remnants of paved floors?   You would never winnow or thresh on the bare earth.  And I should think that being so close, that winnowing and threshing operations would interfere with each other.  The hypothesis that identifies these stone circles with 'alona' is not supportable.

What we see is more compatible with growing plants in stone circles to shield them from the wind and to retard evaporation.  Here is an example of such cultivation from Easter Island.  The Polynesian people there gardened in stone circles called 'Manavai'.    Here's a picture.[6]



Santiago Cordero Guerrero, also on Flickr, submits the following picture which shows bananas growing in another of these manavai on Easter: [7]


Of this picture Mr. Guerrero says: 

"“Manavai”, pequeño jardín rodeado de muro. Estas estructuras circulares de piedra eran utilizadas para cultivar diferentes plantas al abrigo de los vientos y mantener así la humedad. Se cree que este método de cultivo está inspirado al observar el ecosistema que se crea en los cráteres de los volcanes como el Rano Kau o el Rano Raraku, en cuyo interior abunda la vegetación."[8]

Of course, because my suggestion is entirely hypothetical, it is quite impossible to say what plants or trees might have been cultivated on this open ridge line but it seems consistent, given the situation and the morphology, with a vineyard.

I have written a letter to Dr. Manolis Stefanakis who is the point of contact for the website eulimene.eu.  In my letter I ask about this area and I'll publish more on this if he replies.[9]

The sites identified so far can be accessed in the Mycenaean Atlas at:

The 'Alonia': here.

Update: On September 23, 2022 Dr. Stefanakis kindly replied to my questions:

"The alonia (thresholds) are of later times (19th c. AD) when locals were cultivating cereal in the area. It is documented by the elder inhabitants of the area, who were still using them before the WWII. Of course, they are built with ancient materials from the nearby archaeological site.

I do not know of any other examples around Greece of alonia so thickly packed, to be honest..."


Footnotes
[1] Simpson [1981] 197, 'Siana: Ayios Fokas and Kymisala'.

[2] Idem.

[3] McGilchrist [2010] 230-1.

[3a] McGilchrist is just following recent research in this area.  A map published in eulimene.eu here clearly identifies this area as 'Alonia' ('Αλώνια').

Area labelled 'Alonia' at center right.


[4] A good description of threshing is in Wiki, s.v. 'Threshing'.  And see the interesting video there which was shot in l'outre forêt in Kutzenhausen, Alsace-Lorraine.

[5] Again Wiki provides a basic introduction to winnowing.

[6] Find the original in the Flickr account of Elias Rovielo here.

[7]  Mr. Guerrero's Flickr account is here.  The picture can be found here.  A similar picture is here.

[8] "'Manavai', a little garden encircled by a wall. These circular structures of stone were used to cultivate different plants, sheltering them from the wind and maintaining moisture (i.e. slowing evaporation).  It is thought that this method of cultivation was inspired by observing the ecosystem which arises (se crea) in the volcanic craters such as Rano Kau or Rano Raraku, in the interior of which vegetation abounds."   My translation.

[9] Dr. Manolis is at the University of the Aegean, Department of Mediterranean Studies, Rhodes.  The excavation of the Kymissaleis area is described here.  It is good to know that there is ongoing research in this important archaeological area.
 

Bibliography

McGilchrist [2010] : McGilchrist,  Ian.  6. Rhodes with Symi and Chalki.  Genius Loci Publications. London.  2010.  Mr. McGilchrist's work is described on his website.  His volume on Rhodes may be purchased here.

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







Monday, July 25, 2022

Scholarly Citation of Digital Resources; Proofing your Site against Link Rot

 In my last posts, here and here, I started to deal with the idea of academic citation to digital resources.  I explained that Elliott's insistence that Pleiades was 'citation-ready' is nothing more than a server rewrite rule.  Such a rewrite rule does nothing for digital citation for the following primary reason:


A digital resource (online) is liable to change or disappear.  If they do this then the result is known as 'link rot'.  Wikipedia is probably our civilization's greatest example of exactly that.

If links do change or disappear then when a user tries to use a link YOU supplied he or she will get a 404 (page-missing) error.  That makes you look bad and seem a lot less reliable.  I gave an example of how link-rot has negatively impacted Peripleo which is Pleiades' flag-ship (if that's the word I want) product.

Is scholarly citation to digital resources even possible?  I admit that it's easier to cite a physical product such as a book or an article because, with few exceptions, they aren't going to disappear if you stop paying the fees.  

In this blog post I'm not going to deal with the citation of digital resources directly.  I'm going to deal with checking to see whether your links (embedded in your database) are still good.  You may not be able to do anything about link rot; that's in someone else's hands.  You can, however, regularly, check to see that your embedded links are still good.  If they're not then you can do something about it.  The real problem with link-rot is that it's an invisible process (invisible to you, that is).  I'm going to present a program that makes that process visible.

// Program chechLink
<?php

function checklink($l2ch)                    //    This routine uses cURL to get the headers back
{
    $ch                 = curl_init();
    curl_setopt($ch, CURLOPT_URL, $l2ch);
    curl_setopt($ch, CURLOPT_HEADER, 1);
    curl_setopt($ch , CURLOPT_RETURNTRANSFER, 1);
    $data             = curl_exec($ch);
    $headers     = curl_getinfo($ch);
    curl_close($ch);
    return $headers['http_code'];
}

function  connectToDB()            // You have to write your own DB connect routine
{}

$link = connect();    // connect to the Database

//  The query retrieves the title of the work and the URL  It weeds out JSTOR links because I
// already know that these are 'stable'.
$query = "select Src, Tl, URL from biblio where URL is not null and URL not like '%jstor%';";
$result         = mysqli_query($link,$query);
$lcount = 0;

while($row = $result->fetch_assoc())
{
$lcount++;
$URL                = $row['URL'];  // Get the stored URL for this resource
$Tl                = $row['Tl'];  // Get the Title
$src = $row['Src']; // get my own personal DB code for this title

$check_url_status = checklink($URL);          // Call the checklink routine

echo "$lcount: Title: $Tl for URL: $URL\n URL status is: $check_url_status\n";  // make the URL and Title visible ...

// examine the result:
switch ($check_url_status)
{
    case 200 : {echo "Success";                              break;}
    case 201 : {echo "Created";                             break;}
    case 202 : {echo "Accepted but not complete"; break;}
    case 203 : {echo "Partial information"; break;}
    case 204 : {echo "No response";                        break;}
    case 301 : {echo "Moved and assigned a new URL.";   break;}
    case 302 : {echo "Resides under a different URL, however, the redirection may be altered on occasion";
break;}
 
  case 400 : {echo "Some kind of error";             break;}
    case 404 : {echo "Not found";                         break;}
default : {break;}
}

echo "\n\n";      // skip a couple of lines

}         // end of while loop

?>
Here's a trace of what it looks like when executing:

λ Php chlink.php
1: Title: Höhenheiligtümer und Schreine in Palästen und Siedlungen der Altpalastzeit Kretas. Ein Vergleich des rituellen Inventars for URL: https://core.ac.uk/download/pdf/18263645.pdf
URL status is: 200
Success

2: Title: for URL: http://www.archaeology.wiki/blog/2015/04/08/archaeology-tzoumerka-part-1/
URL status is: 301
Moved and assigned a new URL.

3: Title: 1. Geschichte der wissenschaftlichen Erforschung von Paros. for URL: https://www.google.com/books/edition/_/9iAKAAAAIAAJ?hl=en&gbpv=1&pg=PA366&dq=Avyssos,+Paros
URL status is: 302
Resides under a different URL, however, the redirection may be altered on occasion

4: Title: for URL: https://www.dainst.org/documents/10180/16114/00+JB+2010/93bf4ab7-e4c4-4614-9b1a-56c0d32ce8f8
URL status is: 404
Not found

5: Title: Archeologie au Levant for URL: https://www.persee.fr/issue/mom_0244-5689_1982_ant_12_1?sectionId=mom_0244-5689_1982_ant_12_1_1199
URL status is: 200
Success

6: Title: The Warrior Grave at Plassi, Marathon for URL: https://www.archaeology.wiki/blog/2017/04/06/the-warrior-grave-at-plassi-marathon/
URL status is: 200
Success

7: Title: Vlochos: Ruins of a city scattered atop a hill for URL: https://www.archaeology.wiki/blog/2018/09/14/vlochos-ruins-of-a-city-scattered-atop-a-hill/
URL status is: 200
Success

...

This program works as follows. It first connects to the Database. Following that it forms a query that retrieves the title (Tl) and the URL from the Biblio table in the database. It skips over JSTOR URLs because those are assumed to be stable. JSTOR provides non-changing stable links which is what I put in my database. This program then falls into a while loop which will process every URL I have in my database (some 1268 by current count); one at a time. It sends each URL to a routine called check link() which uses cURL services to get the headers back in an accessible form. This status goes into the $check_url_status variable. Then the $check_url_status is run through a PHP switch statement. If the value is 200 then it's successful (the URL is good) and no further action is needed. The other 2xx values are rare. The 3xx pair (301,302) usually means that the URL has been changed on the server side but that a rule was left behind about how to find the new resource. These usually do not cause problems. The 400 series means that the link is broken and some other action needs to be taken on your part to find the desired resource or the URL has to be deleted from the database.

Item no. 4 in the trace is like that:

"4: Title: for URL: https://www.dainst.org/documents/10180/16114/00+JB+2010/93bf4ab7-e4c4-4614-9b1a-56c0d32ce8f8
URL status is: 404
Not found"

This was an attempt to find a resource hosted on the German Archaeological Society's website (DAI). Whatever it was it has now been moved and it's unretrievable at the present URL. I'm either going to have to find that resource some other way or I'm going to have to delete this URL from my DB.

The other URL checks return a status of 200 which means that they succeeded and no action is needed. You should probably change the lines:

case 200 : {echo "Success"; break;}

to

case 200 : {break;} // or even remove this altogether

That way you'll only ever see the questionable URLs; this is probably why you are doing this in the first place.

You could modify this routine so that this line:

case 400 : {echo "Some kind of error"; break;}

is rewritten as:

case 400 : { echo "update biblio set URL = null where src = '$src' limit 1;";
break;}

This change will cause a string of these SQL 'updates' to be generated which can easily be assembled into a script.

If this utility is used judiciously it should help you to dramatically reduce link rot in your product and make it a more robust scholarly resource.

Friday, July 22, 2022

 

Where broken links come from: the case of Peripleo


In my last post I suggested that rewrite rules were intended to make it easier for a user to search for an item on a web site.  The general concept looks like this:


Now, given this set-up we can change this (hypothetical) complex link:

{a} https://www.pleiades.org/stoa/locator-page-constructor?place=579885

the user would just type this on the URL line:

{b}  pleiades.stoa.org/places/579885

Of course that's not really true is it?  Just one difficulty: how would the user know the specific key (579885) for Athens? 

Rewrite rules are really intended for the convenience of the server-side developer.  In this case I'm talking about Pleiades but, in fact, there are probably millions of web sites (no exaggeration) which make use of rewrite rules for their own convenience.  For example, what  if I were to take my path:

{c}  https://www.helladic.info/MAPC/pkey_report_wparam.php?place=C4880

and change the program name to, oh, I don't know, let's say this:

{d}  https://www.helladic.info/MAPC/DEV/Places/key_param.php?place=C4880

In this case my original rewrite rule would still work.  The outer appearance of my site would not have changed.  If I made more radical changes it would still be o.k. as long as I came up with a new re-write rule.  This new rule should preserve my site's surface appearance to the outside world so that people invoking my site would not have to change their software or database or calling routines or all three.  So the purpose of a rewrite rule is to decouple my site's internal workings from the appearance which it presents to the outside world.

A failure to keep internal reality and outside appearance in synch is illustrated by the failure of all the links to the British Museum on Pleiades' Peripleo project.  When I search for 'kylix' for example I get this display:


The link to the British Museum (red arrow) does not resolve.  When I try it Chrome gives me this message:

"This site can’t be reached"

Now, to be fair, the  problem appears to be on the British Museum's side.  They have changed something in the path to their pictures but have not created a rewrite rule to preserve the previous appearance nor have they let Pleiades know about it.  Because this has never worked in the eight months that I've been trying it I find it curious, although not surprising, that Pleiades/Peripleo doesn't care enough to try to fix it.

After all, in the article I quoted from last time, Tom Elliott has this to say about URL/URIs:

"They’re cool because, if you construct them sensibly and connect them to interesting information and take care of them so they don’t rot into uselessness, they make citation happen." [1]

(emphasis mine)

Next time I want to address the idea of what it means to use digital resources for citation.

Notes
  1. Elliott [2018] 45.
Biblio
Elliott [2018]:  Elliott, Tom, 'The Pleiadic Gaze: Looking at Archaeology from the Perspective of a Digital Gazetteer',  Archaeology and Economy in the Ancient World; Classical Archaeology in the Digital Age – The AIAC Presidential Panel 12.1 (51), 43-51.  Kristian Göransson ed., 2018.  Online here.

Wednesday, July 20, 2022

The concept of citation-readiness and Mycenaean Atlas Project

 A URL  is a 'universal resource locator': it refers to a web site, e.g. pleiades.stoa.org.  A URI is a 'universal resource identifier': it refers to a specific item sheltered under the URL.  So, in the pleiades scheme, 579885 is a URI that refers to Athens.  And the link (URL + URI): pleiades.stoa.org/places/579885 is the pointer to 'Athens' in their database and which will be returned by Pleiades.   This is a very friendly form and easy for the user to remember.

The actual address of the Pleiades Athens page would not be friendly at all.  It's more likely to look something like this:

{a} https://www.pleiades.org/stoa/locator-page-constructor?place=579885

My example here is made-up but Pleiades' genuine locator is going to be very much like it and an awful lot for the user to remember.  Much easier to allow the user to write:

{b}  pleiades.stoa.org/places/579885

Now, to be clear, form {b} is for the user's convenience.  The server running at pleiades cannot use this string directly.  It has to convert this string into form {a} before the server can task the right resource.  A rewrite rule is what allows the server to do this.  The result is convenience for the user but correctness for the server.  Win-win.

Well, what one group can do another can also.  I created some rewrite rules for helladic.info so that, if you know the location key for a BA site you can just use that without  remembering the long pathname to the actual program.  So from now on you will be able to type and/or embed a simplified form.  E.g., such as here for the stadium at Argos:

{b}  www.helladic.info/C4480               

instead of the real full path:

{a}  https://www.helladic.info/MAPC/pkey_report_wparam.php?place=C4880

The rewrite rule itself is just this:

RewriteRule  ^(C[0-9]+)$  /MAPC/pkey_report_wparam.php?place=$1  [L,R]

... and the result looks like this:




In one of his foggier statements about Pleiades URLs (he clearly doesn't understand the technology), Tom Elliott has this to say about enhancing citation practice.

“On the world-wide-web, the identifiers necessary for citation should be front-and- center: they are the strings of characters that you put into the location bar of your browser in order to retrieve a web page.  They are the essential magic in a hyperlink.  Their technical name is “Uniform Resource Identifier,” a phrase usually abbreviated with  the acronym URI.  URIs (or yoo-ahr-ees, as they’re sometimes pronounced) are cool.  They’re cool because, if you construct them sensibly and connect them to interesting information and take care of them so they don’t rot into uselessness, they make citation happen.  In throwing off the normalizing tyranny of a single map view to embrace the radical equality of all places, Pleiades was born citation-ready.  Because Sean Gillies and others present at the creation payed attention to emerging best practice and cared about scholarly communication, Pleiades was born citation-ready.”[1]

(I removed Elliott's footnotes 17 and 18).

Elliott suggests that this practice makes pleiades 'citation-ready'.  'Citation-ready' in this sense requires, however, no special 'magic' (the word is Elliott's and it's one which he should avoid) because every server supports rewrite rules that will convert some simple address that you type into the URL box (here pleiades.stoa.org/places/579885) into the more complex 'actual' address where that resource resides.  As usual Elliott is erecting a cathedral on a postage stamp - overselling a normal web function.  If all it takes is a rewrite rule to make pleiades 'citation-ready' then helladic.info is now also 'citation-ready' ...

or something.

But is a simple rewrite-rule enough to create citation-readiness?  I'm not convinced.  We all could benefit from a discussion which tries to clear up the idea of scholarly citation in the context of on-line resources.  Maybe next time.

Notes
  1. Elliott [2018] 45-6.
  2. A guide to rewrite rules is here and a handy cheat sheet for regular expressions (RAs) is here.

Biblio

Elliott [2018]:  Elliott, Tom, 'The Pleiadic Gaze: Looking at Archaeology from the Perspective of a Digital Gazetteer',  Archaeology and Economy in the Ancient World; Classical Archaeology in the Digital Age – The AIAC Presidential Panel 12.1 (51), 43-51.  Kristian Göransson ed., 2018.  Online here.

It seems to me that this paper was actually written at least a decade ago but I can find no earlier reference to it.  Is it just me?  Does anyone else know better?