I just got back from the Tools For Data-Driven Scholarship meeting organized by MITH and the Centre for New Media and History. This meeting was funded by the NEH, NSF, and the IMLS and brought together tool developers, content providers (like museums and public libraries), and funders (NEH, JISC, Mellon, NSF and IMLS.) The goal was to imagine initiative(s) that could advance humanities tool development and connect tools better with audiences. I have written a Conference Report with my notes on the meeting. One of the interesting questions asked by a funder was “What do the developers really want?” It was unclear that developers really wanted some of the proposed solutions like a directory of tools or code repository. Three things the breakout group I was in came up with was:
- Recognition, credit and rewards for tool development – mechanisms to get academic credit for tool development. This could take the form of tool review, competitions, prizes or just citation when our tool is used. In other words we want attention.
- Long-term Funding so that tool development can be maintained. A lot of tool development takes place in grants that run out before the tool can really be tested and promoted to the community. In other words we want funding to continue tool development without constantly writing grants.
- Methods, Recipes, and Training that are documented that bring together tools in the context of humanities research practices. We want others with the outreach and writing skills to weave stories about their use to help introduce tools to others. In other words we want others to do the marketing of our tools.
A bunch of us sitting around after the meeting waiting for a plane had the usual debriefing about such meetings. What do they achieve even if they don’t lead to initiatives. From my perspective these meeting are useful in unexpected ways:
- You meet unexpected people and hear about tools that you didn’t know about. The social dimension is important to meetings organized by others that bring people together from different walks. I, for example, finally met William Turkle of Digital History Hacks.
- Reports are generated that can be used to argue for support without quoting yourself. There should be a report from this meeting.
- Ideas for initiatives are generated that can get started in unexpected ways. Questions emerge that you hadn’t thought of. For example, the question of audience (both for tools and for initiatives) came up over and over.
Dear colleages.
During the conference I snatched up some catchwords that, well, really caught me: reputational sites, discoverability and atomic tools. Obviously they are in close relation to the items Geoffrey’s breakout group came up with.
As a non-native speaker I do not know as to whether “reputational sites” is a common labeling, but recognition and reputation seem to point at the same concept of why people are motivated to do things – and sometimes even doing things for free. Look at at the open source community in general! It actually works. As a example of an already existing “reputational site” the website “http://www.ohloh.net/” might serve even better than “http://iterating.com/” which is more concerned about structuring the items.
Long-term funding without constantly writing grants – that sounds like a scientific utopia. Nevertheless, when it comes to funds it is always easy to argue that reusing what has already been paid for reduces costs. But what is out there to reuse? “Discoverability” appears slightly more apposite here than “visibility”. In my opinion it includes not only finding the tool, but finding out if it fits you. In short: discovering its context of use.
The last catchword “atomic tools” is something that kept my mind busy the recent two years. Tech guys like me fancy the concept of doing things as generic as possible. Beauty is our business. Although, in the end, being utimately generic is very often a kind of utopia thinking, too. A hard but inevitable lesson. Pondering on it, even defining what a tool _is_ seems to be really difficult.
I would describe a tool as an “artifact that supports or enables you to perform a task”. In order to talk about what makes something a tool for you, you first need to specify what task you are willing to do. (On the conference it took me a while to roughly find out what this meant to the majority.) The artifact, on the other hand, can scale from (cyber-)infrastructures down to systems, from systems to servers and applications (and nowadays often services), further down to scripts, macros and templates. (Perhaps even a piece of documentation could become a tool according to that definition. A recipe, if you like so.)
From this hierarchical point of view it might become clearer why the e-publishing working group at Humboldt University likes to talk about “publishing components” instead of “publishing tools”. It accents that there is a more complex context, a workflow or a process that frames the task in multiple ways and that the tool must fit in. Therefore, when it comes to tool silos I personally share the belief that finding suitable ways of describing the component character of a tool will increase “discoverability”.
What I take home for the CARPET project (http://www.dini.de/english-pages/carpet/) – which is actually addressing many of the discussed ideas for the domain of e-publishing – is an increased focus on the social side of tools, their usage and development. People talking to each other will step into the breach whenever a given structure of description has come to its limitations.
Thanks a lot,
Robin
Robin,
You make a number of good points and it is interesting to hear the catchwords through your ears. On the subject of long-term funding we do have another model and that is the Library. Libraries have base funding for services – they don’t have to write grants. That doesn’t mean we want a library model for tools, though libraries effectively now run all sorts of search tools. Perhaps what we want is a model where new tools are developed by grant funded teams and then, if they are worth using on content, they get taken over by libraries.
I think you are right about the tool vs component business. I think that is what we were trying to get at with the idea of methods and recipes. A tool becomes a component when it is in the context of a research task.
The social side to tool development is the new perspective. We are all trying to figure out how to leverage all that creative thinking out there. I’m not sure we know how.