I started to write this as a comment on Lindsay’s latest post, but then thought I should boost it a bit, so that it becomes a part of the overall conversation about next steps for Prism.
I’ve been out of the mix of the discussions you guys have been having, so it may be that Lindsay is responding more to a building group consensus about how to use textual data than to the model “reference interview” introducing Prism that Jeremy conducted two weeks ago.
In case the opposite is true, I want to jump in with some clarifications. The first is that there is no aspect of this project that is not up for consideration, critique, and potential re-casting. Because we are building the tool collaboratively, under a charter I hope you guys will propose to us for adoption on Tuesday, user requirements and overall vision for Prism will need to be negotiated with the group. Project-building in DH invariably requires compromise, but to get there in a healthy way, it first requires a great deal of clarity about team-members’ stances and goals, and the basic theoretical orientation of the work they are trying to conduct (and enable!) together.
In the case of Prism, Lindsay’s (and perhaps others’) skepticism about the utility of that potential text-mining piece – and, I think, about what algorithmic approaches mean in the overall scene of literary studies in an age of “big data” – is certainly being heard. What I’m less clear on is what the team might be imagining is possible to do with the marked passages of Prism’s crowd of users. I would encourage you, at this point in the planning, not to reject approaches without exploring them – without feeling fully informed as to their potential and (more importantly, in cases where you intuit a problem) the intervention you might make, or the twist you might bring, to their use in the scholarly community. Our suggestion about the potential of this project to re-cast the vogue for mechanical “crowd sourcing” in DH in more interpretive and pedagogical terms is an example of one such intervention.
The role of the more experienced members of the Prism team will be to make sure we’re all aware of (sadly, well-trodden) pitfalls in project design and execution. Examples of this from our first requirements conversation were the design and UX dangers of starting the project with a large or unconstrained number of user-extensible color-codings and, likewise, diving into a complex user-accounts system before specifying and architecting the basic functionalities of the tool.
You can think of those as an example of some negative course-corrections we may try to make as the group moves forward. A positive one would be my suggestion that you learn about and think fully through the possible value of data-mining approaches – and the potential for this project to model good ones, or critique from within – before rejecting the notion out of hand. If you ever feel us pressuring you to move in a certain direction, it will be out of a desire to help you and the overall community grow. If that’s not evident in the moment, it’s your job (as Lindsay has done admirably!) to tell us what you’re hearing and pressure us for clarity.
In terms of the overall vision for Prism, it’s true that it stems from longstanding conversations and experiments, and that we came in with some big ideas for the kinds of scholarly intervention it might make, and the directions it was possible to go. But if we had really wanted to build it exactly as specified, we’d have done so, and made up another project for you guys to sink your teeth into.
This one’s just an offering, for the whole group to make of what we will.