I’d like to propose a talk session to exchange ideas, opinions, and share experiences with the archivists and librarians (of course others are welcome!) who have been involved or asked or expected to be involved with their institutional anniversary celebrations.

Every institution wants to tell its story with a “timeline”, oral histories, stories&memories, multimedia presentations, exhibitions, online exhibitions, coffee-table books, etc. and they all need photographs, publications, files, facts and legends, and other “cool stuff”. Who do they call? Archivists and librarians… When do they call? When they need something “yesterday”!

Wouldn’t it be nice to be prepared or to be invited right in the planning stage? Well, as we know, things are not always perfect in the library world. So, please come to share or takeaway.

Digital Scholarship is often collaborative and the final product is inherently different than a thesis, dissertation, journal, or book. How should digital scholarship be evaluated? Is it only the content or does the interface and user experience need to be evaluated as well? Who are the peer viewers? How should credit be shared or “counted” if you are a student, faculty member, librarian or technologist? And of course the larger question- does Digital Scholarship count, full stop?

Scholarly works like masters theses and dissertations are already preserved in print and electronically through services like ProQuest. But what should happen when the scholarly work is a digital project? How should that content be preserved? Who is responsible for the preservation of digital work once the scholar leaves the institution? For example, if a graduate student creates a digital project instead of a dissertation, who preserves that work and how? Who should pay for perpetual storage? What about academic blogs? How should they be captured and preserved? In this session participants will thrash out some of the preservation issues unique to digital works, especially those produced by students. Hopefully there will be no Silence during this session. As always, fezes are optional.

In the near future (or maybe even now?), people will do their reading almost exclusively via device (i.e. on a digital reader, laptop, tablet, and/or smartphone) instead of  via paper.  Given this change of medium, some questions naturally follow:  Should digital readers be used like traditional books (i.e. just to display text)?  Or can technology be integrated into the reading experience without becoming distracting?

I propose a session in which we investigate the latter question.  I believe we can create integrated text analysis and mining tools that will not only improve students’ reading comprehension but also aid anyone’s literary scholarship.  I will start my session by introducing two techniques—sentiment analysis and social network extraction—that work toward this goal, and then the session will open-up into a discussion of what kinds of computational text analysis and visualization tools could be intergraded into literary analysis and the digital reading experience and how useful these tools would be.  If there is interest, we could even try to hack our own text analysis / reading aide tool.  Below are some examples of the capabilities of automated sentiment analysis and social network extraction.

Sentiment Analysis:

• Visualization of sentiment in the Bible: shows the old testament to be generally negative and the new testament to be generally positive.
• The picture below shows the results of sentiment analysis on Shakespeare’s Othello. Othello’s sentiment (how positive/negative he feels) towards Desdemona is algorithmically tracked over the course of the play and is represented by the black line, which we see drastically declines over time. 

Social Network Extraction:

• A social network algorithmically extracted from Hamlet: 

I’d like to lead a discussion that includes a variety of perspectives about what you would want to see in a digital humanities program, degree, or specialization at your university/college/school.

Some questions to consider:

What skills/tools/methodologies should be taught?  (To code, or not to code?)

Will the program be stand-alone, situated within a certain department, or have multiple centers?

What theory or background knowledge of the field will students need?

What career paths will the program prepare students for?

What institutional support is needed to create and maintain this kind of program?

I welcome any other interested parties to co-moderate.  I intend to take my observations from this discussion back to the University of Maryland, where our Digital Studies Colloquium has been charged with developing a plan for such a program.

This is a companion “play” session to the “talk” on crowdsourcing in the digital humanities. In this session we would visit various sites and contribute by reviewing menus, tagging photos, transcribing letters, etc.

We could share our thoughts informally during the process and more formally in a “debriefing” after our group crowdsourcing session. This is seen as a companion to the talk on crowd sourcing, but the two sessions could be compressed into one if necessary.

Possible sites on which to “play”:

• wardepartmentpapers.org
• diyhistory.lib.uiowa.edu/
• www.archives.gov/citizen-archivist/
• menus.nypl.org/
• www.brooklynmuseum.org/opencollection/tag_game/start.php
• www.brooklynmuseum.org/opencollection/freeze_tag/start.php

Crowdsourcing is becoming more and more common in the digital humanities. Here is a sampling of projects which currently include crowdsourcing features:

• wardepartmentpapers.org
• diyhistory.lib.uiowa.edu/
• www.flickr.com/photos/library_of_congress/
• www.pepysdiary.com/
• www.ucl.ac.uk/Bentham-Project
• www.archives.gov/citizen-archivist/
• menus.nypl.org/
• www.brooklynmuseum.org/opencollection/tag_game/start.php
• www.brooklynmuseum.org/opencollection/freeze_tag/start.php
• swem.wm.edu/news/fights-rights/transcription-project
• www.medici.org/

I would be interested in a discussion of how crowdsourcing can be used in digital humanities projects. Topics of discussion could include:

• How to  implement crowdsourcing
• Successes / Failures
• Strengths / Weaknesses
• Issues / Barriers

See also the proposal for a “play” crowdsourcing session.

In the Scholarship of Teaching and Learning (SoTL), faculty study and improve their teaching and the learning in their classrooms and courses, and share their findings to advance the practice of teaching.

SoTL may focus on any pedagogical approach – guided inquiry, lecture, problem-based learning, project-based learning, etc. SoTL may use a variety of qualitative and quantitative research methods – case studies, content analysis, focus groups, interviews, surveys & questionnaires, etc.

Many faculty are not familiar with the literature and research methods used in education, and (for various reasons) not all faculty or SoTL studies reach the level of rigor required for formal publication. Thus, for faculty new to SoTL, it would be helpful to receive guidance and templates they could adopt or adapt with less effort than developing such materials from scratch.

This session seeks to design and prototype a SoTL Design Wizard that would guide users through a series of questions and decisions, leading to materials that could be adopted or adapted, including sample materials for an Institutional Review Board (IRB). For example, to study the effects of a single classroom activity, the wizard might lead to some simple surveys with basic demographic information, a few Likert-scale questions, and an open ended response. For a longer term study, the wizard might lead to longer, more details surveys, and outlines for individual or group interviews.

Thus, the SoTL Design Wizard offers several benefits:

• Faculty will find it easier to start with SoTL.
• Initial SoTL studies will use better methods for design, data collection, and analysis.
• Meta-analyses could be performed if the same materials and templates are used for multiple studies.

Free & Open Source Software (FOSS) is distributed without charge and with the underlying source code, so that anyone can fix defects, update documentation, add enhancements, or otherwise modify the software and share the changes with others. Thus FOSS is free as in free speech, not free beer. Although many people associate FOSS with software development and Internet infrastructure, there are FOSS projects for any area of interest, including audio editing (Audacity), image processing (GIMP), library subject guides (SubjectsPlus), mind mapping (FreeMind), music notation (MuseScore), and project management (OpenWorkbench). Furthermore, a wiki or content management system can be customized to support teaching and scholarship (or other activities) across a wide variety of disciplines.

The communities that develop and support FOSS can be represented as layered onions or pyramids (Jensen & Scacchi, 2007). Typically, the largest, outermost group is people who use or monitor the project, but do not contribute to it. Within this group are progressively more active but smaller groups, such as users who share ideas and defect reports, developers who work on specific sub-projects or supporting modules, leaders of sub-projects, and finally the overall project leaders and core developers. Thus, FOSS communities are communities of practice that leverage legitimate peripheral participation. Although many FOSS participants have technical backgrounds and skills, most FOSS projects also involve non-programming work – graphic design, testing, documentation – and the projects benefit from participation by a more diverse community of people.

Participating in FOSS helps students gain experience with professional reading and writing, diverse and distributed teams, and managing and prioritizing work in extended projects. FOSS can also help students shift from being reactive (complete assigned work) to more proactive (decide what is most important and take ownership). Thus, faculty at many institutions are working to involve students in FOSS (e.g. SoftHum; Teaching Open Source). At one recent NSF-sponsored workshop, a group of faculty, students, and other FOSS participants drafted a list of ~100 activities that could contribute to FOSS projects and provide useful experiences for students and faculty (50 Ways to be a FOSSer).

I envision this session as seeking to:

1. Review and expand the list of FOSS activities.
2. Identify activities of particular relevance and value to teachers, students, and other humanists.
3. Develop descriptions, instructions, and supporting materials to make it easier to adapt and adopt these activities in a variety of courses and contexts.

References

• Jensen, C., and Scacchi, W. 2007. Role migration and advancement processes in OSSD projects: A comparative case study. In Proc of the 29th Int’l Conf on Software Engineering, 364-374. IEEE Computer Society.
• 50 Ways to be a FOSSer (activity list).
  xcitegroup.org/softhum/doku.php?id=f:50ways
• SoftHum: Software for Humanity.
  xcitegroup.org/softhum/doku.ph
• Teaching Open Source.
  http:// teachingopensource.org

There is a necessary tension between University IT departments and the curious digital humanist, computer scientist, and librarian.  IT departments pride themselves on building and supporting things that don’t ever break and that are always secure — we love them for that!   So, getting approval for a new, untested, open source project can be dicey.  On the right occasion, it’s really fun AND necessary to play fast and loose and forget about all that other stuff and just build something.  Sometimes, you just gotta have root access, right?

There is a GREAT solution to this quandary.  For the price of a textbook, you can sudo, script, and savor the best that the open source community has to offer.  Or build something without concern for impacts on your campus IT environment.

Linode.com is a VPS (virtual private server) hosting company that provides any Linux distribution your heart desires and they make it ridiculously easy to set up.  It also boasts great tech support, and a pretty impressive community of other hobbyists and hackers who know a lot and are happy to help you when you get stuck.

Lastly, and most importantly for our purposes, they offer what are called ‘StackScripts’ — a customized set of instructions that permits the deployment of a specialized ‘stack’ of servers and applications — such as Linux/Apache/MySQL/PHP (LAMP) + Omeka.  Or Linux + the language R + text mining packages.  Or Linux + Python + geospatial stuff like geonode (geonode.github.com).  Or Python + Django haystack + Solr + jetty …. I’m sure you get the idea.  StackScripts can help you bring up the thing you WANT to have, without your needing to know all that stuff you DON’T WANT to mess with.  Like server administration and configuration.

So here’s the really cool part.  A StackScript is basically a set of commands issued in a shell, all strung together.  You can even build user defined fields into a StackScript (stuff like, “Enter the name of your project here: ____”.  Someone with the necessary know-how can write and provide StackScripts to other folks to use on their own linodes.  We (at THATCamp Lehigh Valley) can compose a StackScript to bring up, say, Omeka.  Once done, others can use it to reduce the time and effort required to bring up their Omeka to as little as an hour.  No kidding!

And here is the other really cool part.  Using github [http://github.com] we can share, adapt, and update StackScripts for all sorts of projects.

In this StackScripted world I imagine, Campus IT is happy because they don’t need to worry about anyone breaking anything.  You’re happy because, if need be, you CAN break stuff.  More importantly, you can spend your time on your awesome new project instead of struggling on Stack Overflow or reading old Linux manuals!  If your project matures, moving it to campus hardware is so easy, you’ll weep with joy.

In summary, over only a couple of hours, I’d like to MAKE something where we:

* talk about Ubuntu as a Linux distro kind to the unfamiliar (5 minutes)

* bring up a new shiny linode (5 minutes)

* back up and fork our shiny linode just in case we break it (10 minutes)

* mess around a little in the Bash shell, particularly with the .bash_history file that is so useful when writing bash scripts (10 minutes)

* write a StackScript that utilizes User Defined Fields for interactive customization during setup.  Perhaps even demonstrate how you can reference other StackScripts in your StackScript, such that you can string them together (60 minutes)

* play with our new creation!  Maybe do it all again!

Any takers?