|

Other thoughts and ideas about directories

1 Leave a comment on paragraph 1 0 Anything else that panelists want to talk about with regard to directories, that doesn’t fit in other questions.

Quinn Dombrowski

2 Leave a comment on paragraph 2 0 I’ve said my piece in the other questions, but to sum up the important parts (spread across those questions):

  • 3 Leave a comment on paragraph 3 0
  • Large, comprehensive directories are expensive and time-consuming to maintain. If you’re going to make one, you have to plan on ongoing labor costs because the work needs to be paid for there to be a chance of it reliably happening. Do not get a grant to do this work if you don’t have a good plan for covering the long-term costs.
  • Smaller, focused directories around a method and/or kind of data, mostly run by a single individual or small group, can work, at least for a time, if people can live with infrequent updates.
  • Tool reviews should be part of venues that have processes and infrastructure in place to handle a publication workflow — which is fundamentally different than a tool directory.
  • Finally, and most radically, I think we need to stop focusing on directories, and instead direct that energy towards giving better citation and credit to non-traditional scholarly outputs like tool reviews and tools themselves. Directories are a very expensive workaround that does nothing to solve this problem — and fixing it for real, so that it becomes the expected practice to cite DH tools alongside scholarly publications, would have significant benefit for alt-acs whose contribution to the field takes forms other than traditional publications. What if we could tell scholars curious about tools to just look at the literature — rather than directing them to these separate, less-respected silos we call “directories”?

Geoffrey Rockwell

4 Leave a comment on paragraph 4 0 As always I agree with what Quinn writes, especially the final point about credit for non-traditional scholarly outputs. Stéfan Sinclair and I have developed a praxis of developing hybrid projects like hermeneuti.ca that are both book (Hermeneutica, MIT Press, 2016) and tool Voyant, but such reflective work should not be necessary to get credit in the humanities. Some further thoughts:

  • 5 Leave a comment on paragraph 5 0
  • Alan Galey and Stan Ruecker have a nice paper on “How a prototype argues” (Literary and Linguistic Computing: 25(4): 405-424) that makes the case for design prototyping. Rather than build and then try to maintain tools, which leads to the same sustainability problems as directories, they suggest we should be building prototypes that make the argument, but don’t commit to being usable.
  • I would like to see tools discussed as theories. I would like to see us develop a culture of thinking critically about tools as technology that goes beyond just short utilitarian reviews of tools. Matthew Kirschenbaum’s work does this, for example Mechanisms: New Media and the Forensic Imagination (MIT Press, 2008) takes apart various hypertext fiction works using digital forensic tools.

LISA SPIRO

6 Leave a comment on paragraph 6 0 I agree with Quinn about the desirability of featuring tool reviews in publications, although I think more work would be required to encourage writing reviews and to make them easy to find. At present, recruiting authors for tool reviews might be difficult, given that this isn’t a standard academic genre in most fields and that it might take more work to review a tool than, say, a book. For example, DHQ lists reviews of “digital humanities systems and tools” among the materials it publishes, but over the last 20 issues, I found only one software review, and even then it was not for a stand-alone tool. So that tool seekers wouldn’t have to search across multiple publications, reviews could be indexed in a common source. Ideally authors would tag tool reviews with appropriate keywords, perhaps using something more flexible and less labor intensive to develop than an ontology.

7 Leave a comment on paragraph 7 0 Another option might be to establish a tool registry where developers describe their own tools, but I suspect it would run into the familiar problems of incompleteness and obsolescence. Perhaps a more lightweight approach would build upon ways that the digital humanities community already communicates, such as by using a twitter hashtag for #DHtools. Maybe people could come together in a sprint at an annual conference and generate an updated list of DH tools, using something simple like Google Sheets or AirTable. I’m a believer in the ability of a small group of motivated people, powered by coffee, to get things done, as long as the time commitment is manageable. It’s sustaining engagement through the ongoing slog that’s especially tough.

Laure Barbot / Frank Fischer

8 Leave a comment on paragraph 8 0 We would like to share some more thoughts on tools and their positioning within tool directories in this section. We are interested in actual tool usage in the Digital Humanities and developed a very basic tool called ToolXtractor that extracts tools mentioned in DH conference papers, journal articles or tutorials to better understand which tools are actually used in the community (knowing that some tools, even if they were officially released, are only or mainly used by their makers).

9 Leave a comment on paragraph 9 0 To that end, we did two little studies:

11 Leave a comment on paragraph 11 0 Ideally, this information would also find its way into a tool directory to sort tools by relevance and to show actual research contexts where a tool is used so that a researcher can better understand if a tool would help them or not. We would be happy to discuss this further and to get hints to other sources or better methods to extract tools from DH publications.

Page 2

Source: https://~^(?[\\w-]+\\.)?(?[\\w-]+)\\.hcommons-staging.org$/other-thoughts-and-ideas-about-directories/