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?"

My productivity has been taking a hit lately because of Apple's default keystroke sequence for Frontrow. I have no beef with the software, but it's been driving me crazy that I frequently overshoot CMD+GRAVE and hit CMD+ESC, which invokes a full-screen blackout, followed by a slow fade-in of the Frontrow interface, which can't be banished (using the ESC key) until it's fully displayed. Yes, it's all about my sloppy typing, but still .... Argh!

Given that I'm still re-adjusting to the Mac (having been moved to Windows ca. 1998 -- long before the advent of OSX -- and only recently re-mac'd), I wasn't sure where to look to fix this. Thanks to motulist and xUKHCx over at the Mac Basics and Help forum on MacRumors (by way of Google), I now have the answer.

Standby for a work speed-up!

Here's my list:

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.

Shawn is trying out Omeka. Thanks, and thanks for blogging about the experience. We're beginning to think about what we'll do for online avatars of ISAW exhibitions beginning in 2009, and so Omeka is on our list of things to look at closely.

G. Rendell's Friday piece at Inside Higher Ed (Journal Boxes) has touched off a couple of interesting threads at classics-l:

• Sustainability in publishing: print vs. open source journals (initial post; follow-ons)
  
• Open access (again): an example

Unfortunately, the discussion has almost immediately got itself wrapped around an axle of conflation. Pacem the subject line, there are two axes of interest here, not one:

1. Print vs. digital (delivery format)
   
2. Open access vs. subscription-based services (licensing and distribution policy)
   

When these two axes get conflated, we immediately see (as here) a boiling over of the ire of non-affiliated scholars (and those affiliated with financially challenged institutions) who feel locked out of access to important (digital) journals they feel they'd be able to get access to if those journals were in print. This is often painted as a reason why journals should not "go digital" when in fact it's simply evidence of bad (or indifferent) decision making when it comes to publication models.

Proponents of open access should be at pains to point out this difference, lest their baby get thrown out with the bathwater. Editors of fee-and-subscription-based journals should be prepared to explain and revise their licensing and access policies to address the legitimate concerns of scholars in the long tail outside the wealthy-tier institutions.

Aside: it's irritating that the UKY listserv software breaks topic threads on a month transition. Somebody should complain.

I see that Sebastian has submitted his post on URLs to PDQ. That seems to me to be a good thing, and not just because I'm a clean URL fettishist. Sebastian helped me explain our Pleiades URLs and the thinking behind them -- their sanity is Sean's brainchild -- in a series of posts and comments last fall.

I've been thinking more about URLs lately (which partly prompted yesterday's mouthing off about the TEI website) ... and here's why:

This morning, I gave a talk to a group at the British School in Rome (remotely, alas). The topic was "Atom+GeoRSS for interoperability". I imagined a feed-of-feeds that might aggregate glosses/citations/summaries of content on multiple websites related to the archaeology and epigraphy of Cyrene (this, an example of what we'd like to do for every place cited in Pleiades).

Most feed aggregators now bring feed content together thematically as a consequence of selection and filtering criteria established by the aggregator's editor (consider my Planet Atlantides, or Planet OSGeo or Planet Code4Lib). But we could also bring feed entries together by virtue of the values contained in the href attribute on <link rel="related"> tags (think: "all entries related to Cyrene, if the href value is the Pleiades URL for Cyrene"). Spatial correlation (containment, proximity) could also be a great way to aggregate feed content (see Sean Gillies' Mush demo) if your feeds have coordinates in them (by way of GeoRSS) or if you can geocode on the basis of an asserted link relationship with a reference that has coordinates.

I hacked up a fake, hypothetical result feed:

• nearby/cyrene.atom
  

And a fantasy of one way the content could be exploited in the Pleiades website:

• nearby/cyrene.html

The latter was generated from the former using an xslt stylesheet (atom2nearby.xsl).

In these mockups, I re-imagined the URLs of the resources glossed/described in the various entries (in some cases, I imagined their web resources structure pretty much from scratch!). The consequences for various otherwise innocent websites are as follows:

Inscriptions of Roman Cyrenaica: Cyrene
Base URL (now):
http://ircyr.kcl.ac.uk/
Real URL for collection/search of resources (now):
n/a (in development)
Fantasy URL for collection/search of resources:
http://ircyr.kcl.ac.uk/inscriptions/cyrene
Real URL for basic resource (inscription) now:
n/a
Fantasy URL for basic resource:
http://ircyr.kcl.ac.uk/inscriptions/C61300

Epigraphische Datenbank Heidelberg
Base URL (now):
http://www.uni-heidelberg.de/institute/sonst/adw/edh/Fantasy base URL:
http://edh.uni-heidelberg.de/
Real URL for collection/search of resources (now):
http://edh12.iaw.uni-heidelberg.de/offen/suchen2.html?fuan=Cyrene (hidden by frames and a form)
Fantasy URL for collection/search of resources:
http://edh.uni-heidelberg.de/findspots/cyrene
Real URL for basic resource (inscription) now:
http://edh12.iaw.uni-heidelberg.de/offen/suchen2.html?hdnr=000838 (hidden by frames and a form)
Fantasy URL for basic resource (inscription) now:
http://edh.uni-heidelberg.de/inscriptions/HD000838

Cyrenaica Archaeological Project
Base URL (now):
http://www.cyrenaica.org
Real URL for collection/search of resources (now):
n/a (in development)
Fantasy URL for collection/search of resources (in this case, an index to a reference of features and monuments on the site, as indexed in an earlier publication, Bonacasa 2000):
http://www.cyrenaica.org/bonacasa-2000/
Real URL for basic resource (monument/feature) now:
n/a
Fantasy URL for basic resource:
http://www.cyrenaica.org/bonacasa-2000/fontana-dei-buoi-di-euripilo

American Numismatic Society
Base URL (now):
http://numismatics.org/
Real URL for collection/search of resources (now):
http://publicserver.numismatics.org/collection/accnum/list?field1=mint&field1op=equals&field1kws=Cyrene (hidden by a form)
Fantasy URL for collection/search of resources:
http://numismatics.org/mints/cyrene
Real URL for basic resource (coin) now:
http://numismatics.org/dnid/numismatics.org:1997.9.200
Fantasy URL for basic resource (coin) -- I left Sebastian's DNIDs, but I was tempted to replace them with:
http://numismatics.org/coins/1997.9.200/

So, what principles do I think I've embodied in these fantasy URLs? Simplicity. Intuition. Implementation-hiding. Elimination of redundancy. Linkability and browseability for collections and likely searches (and therefore visibility of database content that would otherwise be hidden from 3rd party search engines).

Your thoughts?

The influenza kept me off the plane to Rome, but happily I was at least able to give my talk (via Skype) this morning. The occasion is a meeting at the British School in Rome, organized by the Inscriptions of Roman Cyrenaica project, to bring together scholars working in Cyrenaica to explore the potential for cross-project collaboration and data sharing. I used our work so far on Pleiades (and a bunch of Sean's ideas exchanged on IRC) as a spring-board for a methodological proposal: using Atom+GeoRSS feeds to facilitate cross-project data discovery and citation.

There will be more about this in future posts, but for now, the slides (mostly screen shots) are available:

• Tom Elliott: Atom+GeoRSS for Interoperability (ODP zipped)


• Tom Elliott: Atom+GeoRSS for Interoperability (PPT zipped)

Does anybody besides me find this bizarre:

http://www.tei-c.org/index.xml

gets you:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

http://www.tei-c.org/index.xml?style=raw

gets you:

<?xml version="1.0" encoding="UTF-8"?>
<?oxygen RNGSchema="http://www.tei-c.org/cms/system/modules/org.tei.www/_common/schemas/teilite.rnc" type="compact"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" rend="home">

http://www.tei-c.org/index.xml?style=printable

gets you:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

Why not:

http://www.tei-c.org/index.html
http://www.tei-c.org/index.xml
http://www.tei-c.org/index-printable.html

or some such (in which filename extensions actually bear some relationship to what the user gets, rather than the hidden underlying format or application/file hierarchy on the server) -- and thus throughout the whole website.

Stefano Costa has an interesting new post at Omniverdi's Blog on using OGR Python bindings for statistical analysis of medieval stone walls.

Spotted by way of the recently relocated Planet OSGeo.