Build.ZSR: Fostering & Sustaining Scholarly Digital Projects at Wake Forest
•Download as PPTX, PDF•
1 like•755 views
Part of a panel session titled "The Care & Keeping of Digital Humanities Projects" at Electronic Resources & Libraries 2015.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (6)
Similar to Build.ZSR: Fostering & Sustaining Scholarly Digital Projects at Wake Forest
Similar to Build.ZSR: Fostering & Sustaining Scholarly Digital Projects at Wake Forest (20)
Recently uploaded
Recently uploaded (20)
Build.ZSR: Fostering & Sustaining Scholarly Digital Projects at Wake Forest
- 1. BUILD.ZSR FOSTERING & SUSTAINING SCHOLARLY DIGITAL PROJECTS AT WAKE FOREST Chelcie Juliet Rowell ER&L 2015 Austin, TX @ararebit
- 2. FRAMING THE PROBLEM DESIGNING INFRASTRUCTURE AMIDST UNCERTAINTY
- 3. Digital humanities is not a service. So how should libraries foster & sustain scholarly digital projects?
- 4. THE FACULTY WEBSITE PROBLEM WHAT DOES ‘WEBSITE’ MEAN? Wiki or blog Custom database Tools for collaboration Integration with other platforms Some combination of all these! WHAT SUPPORT IS NEEDED? Single consultation Semester-long course collaboration Open-ended commitment to implement new tool or manage scholarly digital collection At New York University “we find ourselves challenged to respond effectively to what we have come to call ‘the faculty website problem’ — an evergrowing number of requests for webbased spaces and tools to collaborate on scholarly research and share the results.” — Jennifer Vinopal & Monica McCormick
- 5. At Wake Forest, we scrambled to provide support for 18th-Century Common, a public humanities website and flagship project of our Humanities Institute
- 7. THE LIBRARY IS NOT A BOOKSHELF, BUT A SPACE FOR THE ACTIVE CREATION OF NEW KNOWLEDGE
- 8. WHO’S BUILDING BUILD.ZSR? N O T A N E W U N I T, B U T A G R A S S R O O T S T E A M F R O M A C R O S S O U R L I B R A R Y ’ S O R G C H A R T
- 9. COMPONENTS OF BUILD.ZSR tiered service model project charter web presence at build.zsr.wfu.edu featured projects wanna get started? people to help related resources on-campus
- 10. SERVICE TIERS OF BUILD.ZSR TIER 1 Provision TIER 3 Creation TIER 2 Customization
- 11. PROJECT CHARTER Title: Project Owner: Project team: Summary: Bulleted list of deliverables: Timeline for completion: Launch or production plan: End of life issues:
- 14. QUESTIONS? SUGGESTIONS FOR FUTURE DEVELOPMENT?
- 15. APPENDIX: ASSESSMENT OF BUILD.ZSR determining success criteria evaluating client satisfaction identifying what did & didn’t work calculating staff hours spent on development & support activities estimating costs & possible efficiencies considering next steps
- 16. REFERENCES DH curation guide: A community resource guide to data curation in the digital humanities. Retrieved from http://guide.dhcuration.org. Munoz, T. (2012) Digital humanities in the library isn’t a service. Retrieved from http://trevormunoz.com/notebook/2012/08/19/doing-dh-in-the- library.html. Nowviskie, B. (2011) A skunk in the library: The path to production for scholarly R&D. Retrieved from http://nowviskie.org/2011/a-skunk-in-the-library. Varner, S. (2014). Project charter. Retrieved from http://stewartvarner.com/2014/05/06/project-charter. Vinopal, J., & McCormick, M. (2013). Supporting Digital Scholarship in Research Libraries: Scalability and Sustainability. Journal of Library Administration, 53(1), 27–42. doi:10.1080/01930826.2013.756689
- 17. IMAGE CREDITS SLIDE 5: The 18th–Century Common, A Public Humanities Website for Enthusiasts of 18th-Century Studies. Retrieved from www.18thcenturycommon.org. SLIDE 7: Hackathon. SPRUCE Digital Preservation Illustrations. Retrieved from wiki.dpconline.org. SLIDE 8: Branding People. City Park Technologies. Retrieved from cityparktechnologies.com. SLIDE 12: The Wake Forest Student viewed in the Wayback Machine. Retrieved from https://wayback.archive- it.org/1104/20121231023944/http://wakestudent.com. SLIDE 13: Humanities for the Environment. Retrieved from http://hfe.wfu.edu.
Editor's Notes
- Build.ZSR is a service we are designing to support scholarly digital projects on Wake Forest University’s campus. We hope to begin making this service available for the 2015–2016 AY.
- Trevor Munoz argues very forcefully and eloquently that digital humanities is not a service. Rather, it’s a methodology, a set of methodologies, an argument, a set of arguments. Consequently, no, digital humanities can’t be a ‘service’ provided by a library or any other unit on campus. Instead, the service rendered may be sustainable support for web projects of various levels of complexity, or consultations about metadata, or a referral by a library liaison to relevant campus or library resources, or an embedded librarian in undergraduate courses doing digital projects. The varieties of examples of ‘services’ illustrates that it’s difficult to design infrastructure (technological or human) without knowing what we’re infrastructuring.
- “Without precedent, we agreed to host this project (for free) on the understanding that it would require minimal work on our part. At every step along the way it has required more time and effort than expected.”
- Build.ZSR versus Find.ZSR Fit to context Sustainable (able to be maintained over time) Scalable (able to benefit as many scholars as possible) To start designing this service, we wanted to understand — to really understand — the context of the problem. Here, we supply a specific foundational principle: the library is not a bookshelf but a space for the active creation of new knowledge. This understanding, this claim, may be controversial to some faculty, even to some librarians perhaps, who think of the library — and librarians — in certain static ways. By starting with a foundation of creating and building new knowledge, we’re changing the initial context, the space for solutions, the terms of interaction. We’re changing the terms of what problems we can solve and how we can solve them.
- Project agreements may stipulate the length of time any resulting systems (e.g., a specially designed website) will be supported, by whom, and what kind of ongoing support is to be expected (for example, bug fixes only, ongoing development of new functionality, platform and content migration, etc.).
- We have — will have — 3 services tiers: provision (several platforms and technologies available where you can use to 'build on your own' - a wordpress install, an omeka site, etc) customization (less hands-on than the 'build your own' model, we provide individual support for a project (cost recovery basis) creation (the premier tier where we build from scratch) Bethany Nowviskie has described a “path to production for scholarly research and development” that leads me to speculate whether projects that are initially conceived and executed in Tier 3 could eventually become support that we could offer in Tier 2, or whether support that we offer first in Tier 2 could in due time be offered in Tier 1.
- Borrowed from Stewart Varner, who developed the charter with Brian Croxall and Miriam Posner at Emory’s Center for Digital Scholarship. Stewart sees the charter as having three purposes: First, it guides you through an important series of conversations about what, exactly, you are doing and when you are doing it. Second, it asks you to think about maintenance and preservation. Third, having a charter in place gives you something to refer to when partners inevitably remember things differently. To that, we would add that the process of the project lead drafting the responses to the questions posed by the charter, and then perhaps revising it in consultation with a member of the build.zsr team, is an opportunity to build consensus. It’s also an opportunity to engaging in the situated practice of briefing with clients and reframing the problem space, in the way that the research project we discussed earlier found was fulfilling for both designer and client, librarian and scholar.
- Mention DH curation guide, the sometimes difficult leap that humanists have data. Sometimes the most helpful thing I can do is to help them articulate what their data is, because if we know what their data is, we have a better understanding of how we might preserve it.