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

225
technical requirements for use or download; provide easy-to-use <strong>in</strong>structions on how to download a
tool or <strong>in</strong>teract with it (e.g., if tool is embedded <strong>in</strong> a Web browser); and, perhaps most important, plan
for the susta<strong>in</strong>ability of a tool.
Further research by Shilton (Shilton 2009) explored the susta<strong>in</strong>ability of digital tools <strong>in</strong> terms of the
<strong>in</strong>stitutional support that existed to susta<strong>in</strong> the 39 tools identified <strong>in</strong> the previous study. Shilton
proposed two new metrics, “longevity of support,” or the date a tool was established or other
version<strong>in</strong>g <strong>in</strong>formation, and “support for tool,” def<strong>in</strong>ed as the level of technical support (e.g., number
of updates, release time l<strong>in</strong>es, open standards, long-term fund<strong>in</strong>g) provided for a tool. While
acknowledg<strong>in</strong>g that <strong>in</strong>frastructure is a very broad term, Shilton expla<strong>in</strong>ed that her report focused on the
“aspects of <strong>in</strong>frastructure” that could be evaluated by exam<strong>in</strong><strong>in</strong>g tools public websites. Further
research, she argued, should consider the more “subtle and <strong>in</strong>tangible” aspects of <strong>in</strong>frastructure, such
as “human capital, dedication and <strong>in</strong>stitutional context.” Another important dimension that she argued
should be explored was the utility of a tool to humanities research.
Utiliz<strong>in</strong>g the above metrics, Shilton analyzed those tools that still existed of the 39 tools that were
<strong>in</strong>itially identified <strong>in</strong> the earlier report, and found that most of the tools that were rated highly <strong>in</strong> the
first project also scored highly <strong>in</strong> terms of susta<strong>in</strong>ability. “The f<strong>in</strong>d<strong>in</strong>gs suggest that accessibility of
tools and the quality of their support<strong>in</strong>g <strong>in</strong>frastructure,” Shilton observed, “are, <strong>in</strong> fact, correlated. A
successful comb<strong>in</strong>ation of accessibility, longevity and support add to the value of a tool for
researchers”(Shilton 2009). While some older tools had evolved <strong>in</strong>to new ones, other tools had simply
been “abandoned” because of loss of “<strong>in</strong>terest, time or fund<strong>in</strong>g.” Shilton offered a number of best
practices <strong>in</strong> terms of susta<strong>in</strong>ability, <strong>in</strong>clud<strong>in</strong>g website design that makes tools easy to f<strong>in</strong>d and <strong>in</strong>dicates
that they are supported, and professionalism, or view<strong>in</strong>g tools not just as one-time programm<strong>in</strong>g
projects but as “products to support rigorous and long-term scholarship” that require both stewardship
and ongo<strong>in</strong>g <strong>in</strong>stitutional support. In agreement with Cohen et al. (2009), Shilton noted that develop<strong>in</strong>g
a strong user community is a critical component of encourag<strong>in</strong>g tool accessibility and susta<strong>in</strong>ability.
Shilton concluded that a seamless and <strong>in</strong>visible cyber<strong>in</strong>frastructure of digital tools for humanists was
still <strong>in</strong> its <strong>in</strong>fancy. Nonetheless, she still proposed that “imag<strong>in</strong><strong>in</strong>g the components of a curated
<strong>in</strong>frastructure is an important next step for digital humanities research.”
The workshop report by Cohen et al. (2009) listed a number of components that would be required for
a curated <strong>in</strong>frastructure for digital tools and del<strong>in</strong>eated the problems with creat<strong>in</strong>g, promot<strong>in</strong>g, and
preserv<strong>in</strong>g digital tools such those an <strong>in</strong>frastructure would need to address. To beg<strong>in</strong> with, this report
outl<strong>in</strong>ed the myriad problems faced by the creators of digital tools, <strong>in</strong>clud<strong>in</strong>g the conceptualization of
the tool (e.g., what type of application should be built), the ambiguous notions regard<strong>in</strong>g what
constitutes a tool, the failure of tool registries to ga<strong>in</strong> builder participation, and the challenges of
categoriz<strong>in</strong>g tools with<strong>in</strong> taxonomies so that they can be found. Even after successful tool
conceptualization, they stated, digital tool design projects still face issues with staff recruitment,
community participation, and project management. In agreement with Shilton, Cohen et al. reported
that much tool build<strong>in</strong>g did not meet acceptable levels of professionalism, with effective plann<strong>in</strong>g,
version control of code, communication among staff, and plans for long-term support.
Another important problem Cohen et al. described was that even after a tool has been developed to the
po<strong>in</strong>t where it can be distributed, there is a need to “attract, reta<strong>in</strong> and serve users.” The issues outl<strong>in</strong>ed
by Nguyen and Shilton regard<strong>in</strong>g the f<strong>in</strong>dability, accessibility, and lack of transparency and
documentation for tools were reiterated as barriers to build<strong>in</strong>g successful user communities. “In short,
if concerns about the creation and production of tools has to do with the supply of new digital