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

148
One is toward openness; the other is toward dynamism. These are l<strong>in</strong>ked. We no longer see IDP
as represent<strong>in</strong>g at any given moment a synthesis of fixed data sources directed by a central
management; rather, we see it as a constantly chang<strong>in</strong>g set of fully open data sources governed
by the scholarly community and ma<strong>in</strong>ta<strong>in</strong>ed by all active scholars who care to participate. One
might go so far as to say that we see this nexus of papyrological resources as ceas<strong>in</strong>g to be
“projects” and turn<strong>in</strong>g <strong>in</strong>stead <strong>in</strong>to a community (Bagnall 2010).
The IDP, like many other digital classics and humanities projects, is shift<strong>in</strong>g away from the idea of
creat<strong>in</strong>g static, project-based, and centrally controlled digital silos to dynamic, community-ma<strong>in</strong>ta<strong>in</strong>ed
resources where both the data and participation are open to all scholars who wish to participate.
Bagnall argued that this shift <strong>in</strong>cluded reconceptualiz<strong>in</strong>g what it means to be an editor and that the
dist<strong>in</strong>ction that was once made between edit<strong>in</strong>g texts and creat<strong>in</strong>g textual banks should be abandoned.
As part of this new level of openness, the IDP plans to expose both their data and the code that was
used to create the system. This means that if other scholars wish to create a new <strong>in</strong>terface to the data or
reuse it <strong>in</strong> various ways, they may do so. The IDP also hopes to <strong>in</strong>clude more sources of data, and
Bagnall lists at least two projects that are reus<strong>in</strong>g their code. The data <strong>in</strong> the IDP are utiliz<strong>in</strong>g the
EpiDoc encod<strong>in</strong>g standard, which although created for <strong>in</strong>scriptions has been <strong>in</strong>creas<strong>in</strong>gly used for
record<strong>in</strong>g papyri and co<strong>in</strong>s. As EpiDoc uses standard TEI elements, new types of search <strong>in</strong>terfaces can
be created that “will <strong>in</strong>terrogate a range of ancient sources of different types.” In fact, the Concordia
project has begun to create a prototype for this k<strong>in</strong>d of <strong>in</strong>tegration between papyrology and epigraphy
and also connects the documents to the Pleiades database.
In this second phase of the IDP, they have created an onl<strong>in</strong>e edit<strong>in</strong>g system named “Son of Suda On
L<strong>in</strong>e” (SoSOL) 503 that will allow authorized participants 504 to enter texts <strong>in</strong>to the DDbDP and
metadata <strong>in</strong>to the HGV and APIS. The name was <strong>in</strong>spired by Ross Scaife’s project Suda On L<strong>in</strong>e
(SOL), a collaborative site that supports group translation of the Byzant<strong>in</strong>e encyclopedia the Suda. 505
This system supports the creation of editions that will become publicly visible only when the editor
chooses to do so. Where previously texts that were published <strong>in</strong> pr<strong>in</strong>ted editions had to be retyped <strong>in</strong>to
a database, the IDP supports a new form of dynamic publication that is controlled by the <strong>in</strong>dividual
editors and a larger editorial board. In a manner similar to that of the Pleiades model, any user can
contribute variant read<strong>in</strong>gs, corrections, new texts, translations, or metadata, with all suggestions
hav<strong>in</strong>g to be approved by the editorial board. The edit<strong>in</strong>g system records every step of this process,
from proposal through vett<strong>in</strong>g to a f<strong>in</strong>al status as accepted or rejected, and a prose justification must be
given at each step. Accepted proposals can be kept as limited access if the creator desires. One strength
of this model is that rejected proposals are not deleted forever, and are <strong>in</strong>stead reta<strong>in</strong>ed <strong>in</strong> the digital
record, <strong>in</strong> case new data or better arguments appear to support them. Additionally, all accepted
proposals are attributed to their contributor so that proper scholarly credit can be given to them. As
expla<strong>in</strong>ed by Joshua Sos<strong>in</strong>:
Permanent transparency is the guid<strong>in</strong>g pr<strong>in</strong>ciple beh<strong>in</strong>d SoSOL. The system keeps track of
everyth<strong>in</strong>g. When you log <strong>in</strong> and submit a text, SoSOL records it; when you submit a text or
propose an emendation SoSOL will not let you submit until you have written a message
expla<strong>in</strong><strong>in</strong>g what you propose. Similarly, SoSOL will not allow Editors to vote on a text without
expla<strong>in</strong><strong>in</strong>g why they vote the way they do. For every s<strong>in</strong>gle text SoSOL keeps a permanent and
503 An overview of this software and full technical details can be found at http://idp.atlantides.org/trac/idp/wiki/SoSOL/Overview/
504 Access to the prototype system is available at http://halsted.vis.uky.edu/protosite/.
505 Full details on SoSOL, as well as a walkthrough of the software, can be found <strong>in</strong> Sos<strong>in</strong> (2010).