Rome Wasn't Digitized in a Day - Council on Library and Information ...

41
In this new digital world, where there is an endless amount of edit<strong>in</strong>g to be done, Rob<strong>in</strong>son urged
humanists to actively guide the build<strong>in</strong>g of the necessary <strong>in</strong>frastructure by provid<strong>in</strong>g tools, examples of
good practice, and key parts of their own editions, s<strong>in</strong>ce, after all, it is <strong>in</strong> their own best <strong>in</strong>terest as well
to have a say <strong>in</strong> any <strong>in</strong>frastructure designed for them. He stressed, however, that “there is not and will
not be a Wikipedia for editions, nor <strong>in</strong>deed will there ever be any one tool or software environment
which does everyth<strong>in</strong>g for everyone. What there might be is a set of tools and resources, built on
agreed nam<strong>in</strong>g conventions” (Rob<strong>in</strong>son 2010). He thus argued for basic standards and nam<strong>in</strong>g
conventions but aga<strong>in</strong>st any massive universal <strong>in</strong>frastructure. Rob<strong>in</strong>son def<strong>in</strong>ed what he was call<strong>in</strong>g for
as “distributed, dynamic and collaborative editions” (Rob<strong>in</strong>son 2009) and argued that:
The concept is not that there is a s<strong>in</strong>gle system, a s<strong>in</strong>gle set of software tools, which everybody
uses. Instead, across the web we have a federation of separate but co-operat<strong>in</strong>g resources, all
with<strong>in</strong> different systems, but all <strong>in</strong>terl<strong>in</strong>ked so that to any user anywhere it appears as if they
were all on the one server (Rob<strong>in</strong>son 2009).
In fact, Rob<strong>in</strong>son expressed frustration at the fact that most fund<strong>in</strong>g agencies were obsessed with what
he considered to be “Grand S<strong>in</strong>gle Solutions.” He saw little utility <strong>in</strong> projects such as SEASR or
Bamboo, and summed up his op<strong>in</strong>ion thusly: “Let me say this clearly, as most scholars seem afraid to
say it: projects like these are vast wastes of time, effort and money” (Rob<strong>in</strong>son 2009). He argued that
the future did not lie with massive, s<strong>in</strong>gle-purpose <strong>in</strong>frastructure, but <strong>in</strong>stead with projects such as
Interedition 127 and the Virtual Manuscript Room 128 that are not only seek<strong>in</strong>g ways to create more
resources such as manuscript images onl<strong>in</strong>e but also to l<strong>in</strong>k disparate parts (images, tools,
transcriptions) that are already onl<strong>in</strong>e together, rather than try to force them all <strong>in</strong>to one new
<strong>in</strong>frastructure.
The Interedition Project is seek<strong>in</strong>g to create an “<strong>in</strong>teroperable supranational <strong>in</strong>frastructure for digital
editions” across Europe that will promote <strong>in</strong>teroperability of the tools and methodologies used <strong>in</strong> the
field of digital textual edit<strong>in</strong>g. Still <strong>in</strong> its early stages, this project is work<strong>in</strong>g on a tool called
CollateX, 129 “a java library for collat<strong>in</strong>g textual sources” that is the latest version of the tool Collate.
Collate was created by Peter Rob<strong>in</strong>son to support the collation of multiple versions of an electronic
text <strong>in</strong> order to create scholarly editions, and its functionalities are be<strong>in</strong>g enhanced <strong>in</strong> CollateX
(Rob<strong>in</strong>son 2009).
In his discussion of Collate, Rob<strong>in</strong>son emphasized that developers of scholarly collation tools should
recognize two essential facts, the first and foremost of which is that “scholarly collation is not Diff”
and that any attempt to build a collation program that meets all scholars’ needs will meet with failure.
He listed two major reasons for this. The first is that while automated programs could easily identify
differences between texts, these differences are not necessarily variants; and second, teach<strong>in</strong>g a
mach<strong>in</strong>e to determ<strong>in</strong>e the best way to present “any given sequence of variants, at any particular
moment” would be a monumental task. One of the features, Rob<strong>in</strong>son argued, that allowed Collate to
receive a reasonable measure of uptake was that it “allows the scholar to fix the collation exactly as he
or she wants” (Rob<strong>in</strong>son 2009).
127 http://www.<strong>in</strong>teredition.eu/
128 http://vmr.bham.ac.uk/
129 https://launchpad.net/collatex