Pleiades: News and Views

This is P. Strictus, perhaps the most beautiful perennial wildflower of the Mountain West, just beginning to bloom today. We've got several of these around the yard, grown from seed I collected near Granby, CO in 2006. The neighborhood bees are also big fans, and last year inspired our little toddler to yell, "the bees are going in the tunnels"! Indeed. I'm rather pleased at how this shot turned out.

In the background you can see a crimson eruption of P. eatonii, a native of the Colorado Plateau.

In other news, my wonderful gig at UNC is up. I've got a break before my next one starts (continuing Pleiades and getting more into digital humanities), and plan to spend some of it on vacation, some of it in the garden, some of it getting back into home brewing (beer for sure, electronics maybe a little), and some of it on cool Web projects.

Sean Gilles has blogged about deriving unique representations of geographic names from the Barrington Atlas.

He suggests the pattern:
http://pleiades.stoa.org/batlas/{label-normalized}-{map}-{grid}

See the complete post for how to transliterate names containing non-ASCII characters into URL friendly (near) equivalents. It's mostly simple: 'Ağva' becomes 'agva' but there are more interesting cases.

Quick question: should the host component of the url be 'pleiades.stoa.org' or 'atlantides.org'? This may not matter from a redirection point-of-view but consistency, searchability, and interchange issues might make it desirable to designate one or the other as the preferred form.

Dear Jeremy, Dave, Tom, Dan, and the CHNM crew, thank you for having me out for the inaugural THATCamp! I met 50 of the most thoughtful and computer-savvy people in the humanities, many of whom have digital projects that intersect with Pleiades or its technology choices in interesting ways, and all of whom had knowledge and experience to share. Digital humanities newbie me, I tried to soak up as much as I could, and kicked off a useful session on neo-geography featuring great stuff from Mikel Maron (Mapufacture), Josh Greenberg (New York Public Library), and Shekhar Krishnan (MIT).

Here are a few blog posts from other attendees:

Dan Cohen: 1.

Mills Kelly: 1, 2, 3.

Lisa Spiro: 1.

Karin Dalziel: 1.

I'll point to more as I find them.

Looking at the xISBN service docs tonight while running Pleiades data import tests, I see that there is support for "REST-ful" short URLs in version 1 and cool URIs in version 2. That seems pretty cool to me, so let's try one out:

sean@lenny:~$ curl -v http://xisbn.worldcat.org/webservices/xid/isbn/0596002815
> GET /webservices/xid/isbn/0596002815 HTTP/1.1
> Host: xisbn.worldcat.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 305
< Date: Wed, 28 May 2008 06:04:12 GMT
<
<?xml version="1.0" encoding="UTF-8"?>
<rsp xmlns="http://worldcat.org/xid/isbn/" stat="ok">
<isbn    >0596002815</isbn>
<isbn    >1565928938</isbn>
<isbn    >1565924649</isbn>
<isbn    >0596513984</isbn>
<isbn    >2841770893</isbn>
<isbn    >1600330215</isbn>
<isbn    >8371975961</isbn>
</rsp>

Looks good (links would be even better), but that "stat" attribute on the rsp element smells a little fishy ... let's try a bogus ISBN:

sean@lenny:~$ curl -v http://xisbn.worldcat.org/webservices/xid/isbn/05960bogus
> GET /webservices/xid/isbn/05960bogus HTTP/1.1
> Host: xisbn.worldcat.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 103
< Date: Wed, 28 May 2008 06:13:38 GMT
<
<?xml version="1.0" encoding="UTF-8" ?>
<rsp xmlns="http://worldcat.org/xid/isbn/" stat="invalidId"/>

The response has a status code 200, which should mean success, but there's an error code specific to xISBN in the representation: "invalidID". The underlying RPC nature of xISBN leaks through the cool URI abstraction in this situation. That request has to result in a 404 ("Not Found") if xISBN is going to be RESTful, right?

Speaking of curl, Mark Nottingham points out a potential pitfall and collects a bunch of useful comments here.

Last week I was NYU's Institute for the Study of the Ancient World to plan our Concordia project, an effort to interlink projects like Pleiades, IRCyr, the ANS database, and APIS, and build a traversable, searchable network of data based on Web architecture. I'll be blogging more about this all through the year -- expect my blog to intersect more with the Mapufacture and FortiusOne blogs if they continue on course. Some may even be interesting to mainstream GIS designers and developers. ESRI's implicit embrace of Web architecture (along with the explicit embrace of Google) was one of the big stories out of Where 2.0, after all.

One thing that cropped up in our sessions was the need of other Ancient World projects to be able to refer to Barrington Atlas features in Pleiades by URIs derived from their atlas labels. Tom came up with a template for these URIs:

http://pleiades.stoa.org/batlas/{label-normalized}-{map}-{grid}

and simple rules for normalization that just so happen to be already implemented in plone.i18n. We've forked (in a friendly way: forking is now cool thanks to git, right?) plone.i18n and removed the Zope utilities and all dependency on the Zope component architecture. The result is pleiades.normalizer, and it reduces Barrington Atlas labels which may contain annotation and non-ASCII characters to ASCII strings suitable for use in the URI template:

>>> from pleiades.normalizer import normalizer

>>> list(normalizer.normalizeN(u'Tetrapyrgia'))
['tetrapyrgia']

>>> list(normalizer.normalizeN(u'Timeles fl. '))
['timeles-fl']

>>> list(normalizer.normalizeN(u'*Tyinda'))
['tyinda']

>>> list(normalizer.normalizeN(u'[Agrai]'))
['agrai']

>>> list(normalizer.normalizeN(u'Kalaba(n)tia'))
['kalabantia']

>>> list(normalizer.normalizeN(u'Tripolis ad Maeandrum/Apollonia ad Maeandrum/Antoniopolis'))
['tripolis-ad-maeandrum', 'apollonia-ad-maeandrum', 'antoniopolis']

>>> list(normalizer.normalizeN(unicode('Ağva', 'utf-8')))
['agva']

>>> list(normalizer.normalizeN(unicode('Çaykenarı', 'utf-8')))
['caykenari']

The algorithm normalizes non-ASCII characters (normal form KD) and discards elements which are not letters or digits:

U+011F -> (g, U+0306) -> g

U+0131, the last character in Çaykenarı, is a bit of a troublemaker. Our ASCII "i" has the diacritical mark relative to its dotless latin cousin, the inverse of the usual situation, and we have to make a special exception for it in the code.

If you're getting started in web development with Python you might find pleiades.normalizer handy, or at least a starting point for your own normalization code. We won't be publishing it to PyPI, but you can get an egg via:

$ easy_install http://atlantides.org/eggcarton/pleiades.normalizer-0.1.tar.gz

I attended a workshop yesterday on digital geography at NYU's Institute for the Study of the Ancient World. It was billed as a hackfest and the participants focused on strategies for interoperability of geographic datasets, which is a primary concern of the Concordia Project. My contribution was discussion of the work I'm doing at the American Numismatic Society to provide a geographic infrastructure for accessing our collection. The most concrete result of this work is an incipient list of "geographic entities" that are linked into the ANS database. Here's a sampling of URL's that make this list actually usable:

• http://numismatics.org/xml/geography.html. This is a Google Maps API interface to all the sites for which I currently have lat/long info.
• http://numismatics.org/xml/geography.atom. Here's the same information as an Atom feed (similar to RSS).
• http://numismatics.org/xml/geography.kml. And as a KML file. Depending on how you have your browser set up, this may open in Google Earth.
• http://maps.google.com/maps?q=http://numismatics.org/xml/geography.kml. You can also open that URL directly in Google Maps. Cool!

If you open any of these links and click on one of the symbols, you will see a link to a URL similar to http://numismatics.org/id/1. The resulting page is a little spare but it points to a future in which the ANS establishes unique identifiers for conceptual entities of numismatic interest. In this case, Patara is a geographic entity that is also a mint. "Mint" is an ambiguous term but that's a discussion for another context. What matters is that the ANS now has a simple syntax for establishing identity. Such identities can be linked to third party authority lists, in this case the Pleiades definitions of ancient places. Anybody else using that identifier can know that s/he is referring to the same concept as is the ANS when we say, "Here is a list of coins from Patara." That is a huge step forward.

These id URLs can also be extended with ".atom" and ".kml" to produce an automatically parseable Atom feed or Google Earth compatible representation for each entity. A further implication of this is that I can show maps in the search results produced by the ANS database. If you scroll down in http://numismatics.org/collection/accnum/list?region=cyrenaica&imageavailable=yes, you'll see a "show map" button for the records from Cyrene. Click there for the relevant Google Map.

The NYU/ISAW workshop provided an incentive to get this infrastructure up and running on a preliminary basis. I'm grateful for that and for the hospitality of our hosts. It was an enjoyable day all round!

I bet we're going to want to fiddle with the Open Library API and the Bibo Ontology in the context of the Pleiades bibliography application (and some others we're thinking about, like a next-generation Checklist of Editions for papyri and the like).

• Seek and get digital books from the Open Library.
• Use Bibo in other-than-html serializations of the underlying MODS records, and maybe even microformatishly in the HTML version. (We already use COinS -- for interop with Zotero -- but it's lossy, ungainly and suboptimally human-readable).
  

Thanks to Dave Pattern (via planet code4lib) for the pointer to the OA API).

Now back up and running: all public-facing services hosted on atlantides.org (including the Concordia website, the Pleiades development environment, the Atlantides feed aggregators and the inscriptol mercurial repository) are up and running.

Update (0855 EDT, 13 May): at present the server is down; individual services, beginning with Concordia, will come back up as they are reinstalled over the course of today.

It's time for a server operating system upgrade, so atlantides.org will be down today (6 May 2008), between noon and 8:00 p.m. U.S. Eastern time (GMT/UTC + 5). The length of the outage is likely to be shorter than this window. The Atlantides feed aggregators, as well as the Pleiades and Concordia development environments will be inaccessible during this upgrade. pleiades.stoa.org will remain up and accessible throughout.

Keytree (also known as pleiades.keytree in our repository) is a simple package of ElementTree helpers for parsing KML. I needed it, didn't see anything else like it out there, and put in a little extra work to make it more generally useful. If you're already using ElementTree and are curious, give it a try. It plays well with Shapely, of course:

>>> from xml.etree import ElementTree
>>> tree = ElementTree.parse(open('archaic.kml', 'rb'))
>>> kmlns = tree.getroot().tag.split('}')[0][1:]
>>> placemarks = tree.findall('*/{%s}Placemark' % kmlns)
>>> p0 = placemarks[0]
>>> import keytree
>>> f = keytree.feature(p0)
>>> from shapely.geometry import asShape
>>> shape = asShape(f.geometry)
>>> shape.wkt
'POINT (21.9725000000000001 32.8962999999999965)'

Keytree parses out points, line strings, and polygons, but not yet geometry collections. I'll make a real release of it after I get a chance to work on compatibility with lxml.

The MCRSR first appeared in October, 2007. For the seventh installment I am making one addition, no. 18, Roman Amphorae: a digital resource from the United Kingdom Arts and Humanities Data Service's Archaeological Data Service. Astute readers will note that the URL I use re-directs to a interstitial page that asks for compliance with a Copyright and Liability Statement and with a Common Access Agreement. I don't usually use redirects but in this case I do because the publication explicitly asks that citation be only to this URL. It is helpful when sites specify a citation form so that I am happy to comply. But see below for comments on an unfortunate side effect of the site enforcing compliance in this way. In general, however, this is an excellent resource that is highly recommended to anyone interested in the topic. There is much to say about the high quality of the scholarly content but for now I'll keep myself to just a few technically-oriented comments.

First, the title of the work gives me an opportunity to highlight a personal bugaboo of mine. Many digital resources qualify themselves by prepending "electronic" to their titles. This is a misnomer as electricity is only one component of their storage and transmission. Plastics, light, magnetism, etc. are all involved so "digital" is a better term. But this is a somewhat petty observation that doesn't apply here so I'll move on quickly.

About that compliance page, it seems to come at a high cost. If one clicks past the page and makes one's way to the entry for Africana 1 Picolo amphoras, you can read the phrase "Production is attested at Ariana near Carthage...". Try searching for it in Google and you won't find anything. I don't think this can be due to the format of the URL for that particular page - http://ads.ahds.ac.uk/catalogue/archive/amphora_ahrb_2005/details.cfm?id=1 - because Google usually handles such strings with no problem. Rather, I'm guessing that any links to this page first run the Google spider through the compliance page and that interferes with indexing. Regardless of cause, the result is that these superb pages are not discoverable via search engines. That is unfortunate. And having read both the Copyright and Liability statement and the Common Access Agreement, they did not strike me as so unique as to require this intrusion. To put it another way, what benefit is worth that cost?

Readers may be aware that the AHDS' funding will soon run out. Fortunately, as announced on its website, ADS funding will continue. It will be interesting to see if the published URLs of ADS resources change.

There has been one significant change for the previously listed URLs. The JSTOR link to Robinson's Agora V is now http://www.jstor.org/stable/i285178. Unfortunately, the previous URL, http://links.jstor.org/sici?sici=1558-8610%281959%295%3C%3E1.0.CO%3B2-3, no longer works. And to compound the issue, the new URL takes one to a login page that does not indicate the title of the linked work. This is an unexpected situation that I hope results from temporary errors. One reason to think they are temporary is that there are "old style" URLs that do redirect to the new and improved URL format. For example, http://links.jstor.org/sici?sici=0002-9475(1949)70%3A3%3C299%3APPFATT%3E2.0.CO%3B2-S remains usable.


1. Walters' Catalogue of the Roman Pottery in the Departments of Antiquities, British Museum from Google Books: http://books.google.com/books?id=M2UEAAAAYAAJ

2. Robinson's Agora V from JSTOR: http://www.jstor.org/stable/i285178, previously http://links.jstor.org/sici?sici=1558-8610%281959%295%3C%3E1.0.CO%3B2-3

3. Lattara 6: http://www.lattara.net/LATTARAPUB/PUBLAT/LATTARA6/lattara6.html

4. K. Greene's AJA article on Early Roman lead glazed pottery: http://www.ajaonline.org/pdfs/111.4/AJA1114_Greene.pdf

5. Heath and Tekkök, Greek, Roman and Byzantine Pottery at Ilion (Troia): http://classics.uc.edu/troy/grbpottery/

6. Vessel from Çatalhoyuk (via Flickr): http://www.flickr.com/photos/catalhoyuk/971964416/

7. A Late Minoan III Pyxis from the Metropolitan Museum of Art: http://www.metmuseum.org/toah/ho/03/eus/hod_1999.423.htm

8. An undocumented ARS Hayes 70 bowl from the dealer Classical Numismatics Group: http://cngcoins.com/Coin.aspx?CoinID=86618

9. Fifteenth Century Mosque Lamp from Jerusalem now in the British Museum: http://www.britishmuseum.org/explore/highlights/highlight_objects/me/m/mosque_lamp.aspx

10. The Perseus Project Vase Catalog: http://www.perseus.tufts.edu/cgi-bin/ptext?doc=Perseus%3Atext%3A1999.04.0043

11. Wikimedia Commons Image of a Greek Geometric Skyphos in the Louvre: http://commons.wikimedia.org/wiki/Image:Skyphos_birds_Louvre_CA3822.jpg

12. Sagalassos from Pleiades: http://pleiades.stoa.org/places/639087

13. Inscribed pot from Aphrodisias (HTML): http://insaph.kcl.ac.uk/iaph2007/iAph150353.html

14. Inscribed pot from Aphrodisias (XML): http://insaph.kcl.ac.uk/iaph2007/xml/iAph150353.xml

15. Hellenistic lamp from Assos, Turkey at the Museum of Fine Arts, Boston: http://mfa.org/collections/search_art.asp?recview=true&id=199476&coll_keywords=&coll_accession=84%2E110&coll_name=&coll_artist=&coll_place=&coll_medium=&coll_culture=&coll_classification=&coll_credit=&coll_provenance=&coll_location=&coll_has_images=&coll_on_view=&coll_sort=2&coll_sort_order=0&coll_view=0&coll_package=0&coll_start=1

16. Open Context record for Halaf period jar from Domuztepe, Turkey: http://www.opencontext.org/database/space.php?item=14926_DT_Spatial

17. Abbasid Ceramics from the Museum With No Frontiers: http://www.discoverislamicart.org/exhibitions/ISL/the_abbasids/exhibition.php?theme=5

18. Roman Amphorae: a digital resource: http://ads.ahds.ac.uk/catalogue/resources.html?amphora2005

Hey Tom,

Note that there's also an EpiDoc category on the CEp blog, and we could easily (and probably should) also have one at the Stoa. Worth aggregating those in the same way as Concordia and Pleiades (since EpiDoc doesn't have it's own blog either)?

Neither Pleiades nor Concordia has its own news blog; and I hope you'll forgive the fact that the team members were reluctant to create same, since some of us already blog in multiple places. The solution? Aggregate and filter our regular blog posts into project-specific streams. So today I have added to the Atlantides system the following:

• Concordia: News and Views (html | rss)
• Pleiades: News and Views (html | rss)

Hat-tip to the regexp_sifter.py filter in Sam Ruby's Venus.

Andy Powell hopes "that the conditions of funding in this case mandated that the resulting resources be made open rather than just free" and wonders what licenses will govern the content produced or incorporated by the various projects funded under the joint NEH/JISC Transatlantic Digitization Collaboration grants.

I can only speak for the Concordia project, a collaboration of ISAW and CCH.

In answer to the first question: no, I am not aware of any mandate placed on us in this regard. We did make explicit commitments of our own in our proposal about licensing, and we're now bound to abide by those.

Here is a list of the software and content that we will use, modify or produce, indicating the license that now governs (or will govern) each:

• The Duke Databank of Documentary Papyri (cc-by)
• The Inscriptions of Aphrodisias 2007 (cc-by)
• The Inscriptions of Roman Cyrenaica (cc-by)
• The Inscriptions of Roman Tripolitania (cc-by)
• The Papyrological Navigator (GPL)
• Pleiades (code GPL; content cc-by-sa)
• EpiDoc toolset (GPL)
• Atom web feeds serializing OAI/ORE resource maps (following license of parent resource)
  

I've added a service to Mush that demonstrates the concept of dereferencing linked locations. Only GeoRSS entry locations are currently supported. See the wiki page there for more details.

I was going to use this as an excuse to learn more about Pylons. What I ended up learning is that I don't like Routes, the default Pylons URL dispatcher, and so I just made my own Selector-based app deployable with Paste Deploy. The public read-only repo for Mush is now here.

The MCRSR first appeared in October, 2007. For the sixth installment, I am again making only one addition, no. 17, the section "Abbassid Ceramics" in the Discover Islamic Art exhibition from the Museum With No Frontiers. This is a very well done website that has received substantial European Union and other funding. It will be interesting to see if the information it offers remains available over the long term.

The previously listed URLs for MCRSR items 1 through 16 remain valid. At the time of writing, I can't access number 3, Lattara 6, but I believe this is only a temporary disruption.

Number 10, the Perseus Vase Catalog, announces that "Perseus is changing! Please visit Perseus 4.0 for the current version". The new URL is http://www.perseus.tufts.edu/hopper/text.jsp?doc=Perseus:text:1999.04.0043. At some point, it may be appropriate to update item 10, but for now I am going to hold off until the current URL becomes invalid.

1. Walters' Catalogue of the Roman Pottery in the Departments of Antiquities, British Museum from Google Books: http://books.google.com/books?id=M2UEAAAAYAAJ

2. Robinson's Agora V from JSTOR: http://links.jstor.org/sici?sici=1558-8610%281959%295%3C%3E1.0.CO%3B2-3

3. Lattara 6: http://www.lattara.net/LATTARAPUB/PUBLAT/LATTARA6/lattara6.html

4. K. Greene's AJA article on Early Roman lead glazed pottery: http://www.ajaonline.org/pdfs/111.4/AJA1114_Greene.pdf

5. Heath and Tekkök, Greek, Roman and Byzantine Pottery at Ilion (Troia): http://classics.uc.edu/troy/grbpottery/

6. Vessel from Çatalhoyuk (via Flickr): http://www.flickr.com/photos/catalhoyuk/971964416/

7. A Late Minoan III Pyxis from the Metropolitan Museum of Art: http://www.metmuseum.org/toah/ho/03/eus/hod_1999.423.htm

8. An undocumented ARS Hayes 70 bowl from the dealer Classical Numismatics Group: http://cngcoins.com/Coin.aspx?CoinID=86618

9. Fifteenth Century Mosque Lamp from Jerusalem now in the British Museum: http://www.britishmuseum.org/explore/highlights/highlight_objects/me/m/mosque_lamp.aspx

10. The Perseus Project Vase Catalog: http://www.perseus.tufts.edu/cgi-bin/ptext?doc=Perseus%3Atext%3A1999.04.0043

11. Wikimedia Commons Image of a Greek Geometric Skyphos in the Louvre: http://commons.wikimedia.org/wiki/Image:Skyphos_birds_Louvre_CA3822.jpg

12. Sagalassos from Pleiades: http://pleiades.stoa.org/places/639087

13. Inscribed pot from Aphrodisias (HTML): http://insaph.kcl.ac.uk/iaph2007/iAph150353.html

14. Inscribed pot from Aphrodisias (XML): http://insaph.kcl.ac.uk/iaph2007/xml/iAph150353.xml

15. Hellenistic lamp from Assos, Turkey at the Museum of Fine Arts, Boston: http://mfa.org/collections/search_art.asp?recview=true&id=199476&coll_keywords=&coll_accession=84%2E110&coll_name=&coll_artist=&coll_place=&coll_medium=&coll_culture=&coll_classification=&coll_credit=&coll_provenance=&coll_location=&coll_has_images=&coll_on_view=&coll_sort=2&coll_sort_order=0&coll_view=0&coll_package=0&coll_start=1

16. Open Context record for Halaf period jar from Domuztepe, Turkey: http://www.opencontext.org/database/space.php?item=14926_DT_Spatial

17. Abbasid Ceramics from the Museum With No Frontiers: http://www.discoverislamicart.org/exhibitions/ISL/the_abbasids/exhibition.php?theme=5

I saw several references to "GeoRSS 2.0" recently by people who are attending the OGC TC meeting in St. Louis. Here's my 2 cents on 2.0:

• Deprecate the simple geometry encoding and just go with GML in a georss:where element already. Yes, this is a complete about face from my position in 2006. Nevermind XML Schema, I'm just saying that the GML encoding is more expressive, more clearly defined, and not significantly more difficult to produce or parse. I've even contributed a GML parsing patch for the Universal Feed Parser. If I can do it, how hard can it be?
• Specify cardinality: an entry should have 0 or 1 geometry (see following comments about multiple locations).
• According to the 1.0 spec: "GeoRSS geometry is meant to represent a real feature of the Earth's surface". Why not above the surface, or below? Do you really think that's going to stop Satan from using GeoRSS to geo-tag news from the hellish center of the Earth? I think this language can go in 2.0 and take elev, floor, and radius along with it. We're all better off using 3D coordinate reference systems, and the quick adoption of KML shows that a third dimension isn't a serious stumbling block.
• In the next paragraph, it is written: "GeoRSS is a way of relating Web content to Earth features". That statement is more dense and chewy that it seems. To me, it seems like specifying nothing more than how to add location to entries is a worthy enough effort. The relationship of entries to the real world is really more of a semantic web concern.
• The semantics of featuretype tag and relationship tag better belong to entry entities than to location entities. The fact that they are not significantly used is, in my opinion, tacit acknowledgement of the truth of that statement. Atom and RSS already allow you to categorize entries and items, which makes featuretype tags unnecessary. Atom also provides a mechanism to relate entries to other entities on the Web: links obviate the need for relationship tags.
• Multiple locations I have already blogged. Entries are cheap.
• The 1.0 spec only considers literal geometries. Referencing external geometries is something else that's being considered for a future version. I'm -0 on the first option (inspired by http://rest.blueoxen.net/cgi-bin/wiki.pl?XMLSemanticWeb) and -1 on the second (inspired by http://tools.ietf.org/html/rfc4287#section-4.1.3.2). I now prefer an approach that first came up on the GeoRSS list here, and which Tom Elliot and I had also been discussing that fall: using Atom links and custom relations. The equivalent of that first option could instead be something like:

<entry>
  ...
  <link
    rel="http://www.georss.org/relations/is-colocated-with"
    href="http://pleiades.stoa.org/places/639166.atom"
    type="application/atom+xml;type=entry"
    />
</entry>

Update (2008-03-28): Notes on my adventures in this direction are at http://atlantides.org/trac/concordia/wiki/AtomLocationByReference.

If you push more semantics from the location up into the entry, using Atom and its extensions, the ground that GeoRSS has to cover shrinks, a good thing for any specification. But what about RSS 1.0 and 2.0? The former can draw on RDF, of course. Maybe the latter needs links from SSE.

Yesterday I had the pleasure of attending a nice event at the Folger library during which the Chairman of the National Endowment for the Humanities announced the award of 5 grants under the NEH/JISC joint Transatlantic Digitization Collaboration rubric (press release).

I'm happy to report that Pleiades is part of one of the winning proposals. The award goes jointly to ISAW at NYU and to CCH/Classics at King's College, London for a collaboration we're calling "Concordia" (to reflect its focus on cross-project interoperability). The principal investigators are Roger Bagnall and Charlotte Roueché. Sean Gillies, Gabriel Bodard and I will join them in working on the project. The period of performance is 1 April 2008 - 31 March 2009.

What will we do?

• Add more content to Pleiades (Tripolitania and northern Egypt)
• Digitize Joyce Reynold's and J.B. Ward-Perkins' Inscriptions of Roman Tripolitania (IRT) and release it (in EpiDoc format) online
• Use the newly-released OAI/ORE specification to link up content in Pleiades with IRT, the Inscriptions of Roman Cyrenaica (now in preparation at King's), the Inscriptions of Aphrodisias 2007, the Duke Databank of Documentary Papyri and the Heidelberger Gesamtverzeichnis der griechischen Papyrusurkunden Ägyptens. We'll add geographic information, by way of GeoRSS tags and references to Pleiades places.
• Create software to exploit the Atom feeds that embody the ORE resource maps and provide search services (including spatial proximity search) that can be used by third parties. We'll integrate the output from those searches into Pleiades and some of the other collections (so e.g., you can see, from Pleiades, what inscriptions or papyri were found at a given site).

Our advisory board:

• Rodney Ast (Advanced Papyrological Information System, Columbia University)
• Hugh Cayless (Digital Library Research and Development, University of North Carolina at Chapel Hill)
• Elaine Matthews (Lexicon of Greek Personal Names, Oxford)
• Sebastian Heath (American Numismatic Society)
• Daniel Pett (Portable Antiquities Scheme, British Museum, London)
• Joshua Sosin (Duke Databank of Documentary Papyri, Duke University, Durham, NC)
• Richard Talbert (Ancient World Mapping Center, University of North Carolina at Chapel Hill)

There's no point in reiterating here what Dot, Brent, Chris and Cathy have so eloquently written about Ross. Even though I'd had the news of his death privately over the weekend, the deep emptiness of his being gone didn't really hit me until I saw the first public notice on Classics-l. There's something brutally liminal about a death notice in a professional forum, no matter how gently written: it is the crisp, formal ceremony that transfers a person from the active present to the static past of the discipline.

This sombre realization is rippling through the web of connections that was Ross' personal and professional network. You can detect it in the spattering of blog posts, emails and the subdued communications of his many colleagues and friends.

And yet, it is clear that the interpersonal fabric Ross wove will be a lasting, living contribution to the field, and to our lives. There are so many people Ross introduced to each other and encouraged in collaborative digital classics work. He watched our backs when things got rough, applauded our successes, pulled us out of ditches, and kicked our asses well and thoroughly when we deserved it. Vast indeed is the sea of those whom Ross has mentored and enabled.

I've written elsewhere about Ross's contribution to the EpiDoc effort. Pleiades owes him an equal debt. It was Ross's 2001 invitation to speak at the Center for Computational Sciences in Lexington that first forced me to formalize the ideas that I'd been batting around privately with Richard Talbert, Stephen MacGregor, Hugh Cayless, Noel Fiser, Amy Hawkins and others in Chapel Hill. And it gave those ideas their first public airing. Ross and I had originally discussed them, along with Sebastian Heath and Neel Smith, in Newport the previous year. Ross helped us refine the plan through subsequent iterations and grant proposals and, when it emerged that UNC could not provide us with the class of hosting we needed for development, he offered server space belonging to the Stoa. The collaborative editorial approach embodied in the Suda Online underlies our model for the Pleiades workflow, to be rolled out later this year. Ross remained deeply engaged in both the vision and the technical details of Pleiades, even during his illness. Without him, Pleiades would not be.

And so I have now both sadly and joyfully yielded -- like Patrick, Melissa, Troels, Hugh and others -- to the compulsion to hold up for you to see one more swathe of the Rossian fabric, saying "Look! Here's another bit he did with us. Doesn't it shine, gold and purple in the sun?"

Dan Cohen rocked my feed reader this morning with news that the Open Archives Initiative has unveiled the Object Reuse and Exchange (ORE) Specification. This initiative came in below my RADAR (as so many things do!); Dan's post is well worth a close reading, both as an introduction and as a rationale.

As I understand it so far, ORE provides a structured method for mapping relationships between digital resources (different formats, multiple versions, works that cite other works, reviews of works, etc.). Any party -- an author, an archivist, a (e)journal editor, an automated process -- can construct these maps and then publish them via a serialization format for use by other individuals and processes. As Dan writes:

Today's scholarship ... cannot be contained by web pages or PDFs put into an institutional repository, but rather consists of what the ORE team has termed “aggregates,” or constellations of digital objects that often span many different web servers and repositories ... By forging semantic links between pieces entailed in a work of scholarship [ORE] keeps those links active and dynamic and allows for humans, as well as machines that wish to make connections, to easily find these related objects. It also allows for a much better preservation path for digital scholarship because repositories can use ORE to get the entirety of a work and its associated constellation rather than grabbing just a single published instantiation of the work.

Sean and I have been poring over the ORE Spec for the last hour or so, and especially the section on the primary serialization format for ORE Resource Maps, which makes use of Atom.

Pleiades fans will already know that, at the beginning, Sean designed into our publication interface an Atom+GeoRSS serialization component (e.g., Pleiades Cyrene in Atom), and that he is a vocal advocate for RESTful geoapps that employ Atom and other appropriate formats. Last Friday, I gave a presentation about Atom+GeoRSS for cross-project interoperability to an audience at the British School in Rome. This approach that has grown out of our Pleiades work. In comparing where we have been going with where ORE is going, it's clear that the practice is very close (as Sean points out). In coming days I'll be reworking the example to match the ORE spec, and we'll be doing some upgrades to our standard Pleiadic Atom feeds as well.