Maintained by: David J. Birnbaum (djbpitt@gmail.com) Last modified: 2023-01-25T21:30:49+0000
Instructors
When and where: The course meets MWF 10:00–10:50 in G62 Cathedral of Learning. Office hours meet inside the Department of Slavic Languages and Literatures, 1228 Cathedral of Learning. All instruction and office hours are in person; we will update this information should the University at some point require online or hybrid sessions.
This course is entitled Computational methods in the humanities. The course
head is Professor David J. Birnbaum, assisted by Benjamin (Ben) Adams (senior
assistant), Camryn Dorney (senior assistant), Charlie Taylor (senior assistant),
Renee Dubaich (assistant), Ella Fosse (assistant), and Caroline McDonough
(assistant). Professor Birnbaum is a Professor of Slavic Languages and Literatures,
and you can find some of his Digital Humanities projects at http://www.obdurodon.org. Mr. Adams is
majoring in Computer Science and his course project was Grimm fairy tales. Ms. Dorney is
majoring in Information Science and her course project was Hip-hop humanities. Ms. Taylor is
majoring in History of Art and Architecture and Classics and her course project was
Van Gogh as a tortured
genius
. Ms. Dubaich is majoring in Anthropology and English writing and her
course project was Portrayals of gender in
The metamorphoses. Ms. Fosse is majoring in History and
Museum Studies, with a French minor and a Russian and Eastern European Studies
certificate, and her course project was War and peace in adaptation. Ms. McDonough is majoring in
nonfiction English writing and her course project was The agency of women in Sherlock
Holmes.
In addition to the University’s Canvas course management system, this course has its own web site, which is located at http://dh.obdurodon.org (Obdurodon). See below for details about which information is managed through Canvas and which is posted to Obdurodon.
The course carries three credits and it satisfies the Dietrich School of Arts &
Sciences General Education Requirement (GER) for Quantitative and formal reasoning. That GER reads as follows:
Quantitative and Formal Reasoning. All students are required to take and pass
with a grade of C- or better at least one course in university mathematics
(other than trigonometry) for which algebra is a prerequisite, or an approved
course in statistics or mathematical or formal logic in a department of the
Dietrich School.
Computational methods in the humanities is one of the very few courses offered at the University of Pittsburgh that is designed specifically to address the knowledge and skills involved in quantitative and formal reasoning within the context of the interests and needs of students in the humanities. The course meets three days a week for fifty minutes and involves a combination of lecture, discussion, and practical programming exercises. There are no prerequisites; in particular, students are not expected to have any prior computer programming experience and they are not required to know any foreign languages. On the other hand, as is the norm for courses with 1000-level numbers, students should normally have some experience with college-level study, especially in the humanities; this will assist them in identifying interesting humanities research questions, which they will then explore with the computational skills they will acquire in the course.
Students may enroll under any of the cross-listed rubrics and both undergraduate and graduate students are welcome (graduate students should enroll in Slav 2050, which is the same course, but the 2000 number means that graduate students will earn graduate credit). Whether the course satisfies requirements for a departmental major is up to the individual departments, and interested students should inquire about this with their major advisors. The course carries a University Honors College (UHC) designation; for information about enrolling in UHC courses, see https://www.frederickhonors.pitt.edu/academics/courses.
An Honors course provides a research-oriented, graduate-level educational opportunity, and students who complete this course have frequently commented that it was simultaneously one of the most demanding and one of the most rewarding experiences of their academic careers. That experience requires a commitment, appropriate for an Honors course, to attend all course meetings and complete all homework conscientiously and in a timely fashion. Given that commitment on your part, the instructors will be eager to work with you to help you finish the course having acquired skills that will enable you to use computational methods to conduct professional-level original research in the humanities.
Humanities students often do not realize (or even imagine) that 1) they are capable of learning to write useful and practical computer programs within the course of a semester even if they have no prior background in programming; 2) the ability to write one’s own programs can be valuable for scholars in the humanities, especially because commercial software often does not address research needs in the humanities; and 3) practical computer programming, no less than reading, writing, and arithmetic, is a useful skill that is within the reach of any educated person regardless of academic specialization.
This course will introduce students to the role that computational methods can play in primary research and scholarship in the humanities, using as a framework eXtensible Markup Language (XML) and related technologies. XML has excellent properties for document modeling, which makes it singularly useful for humanities computing, and it is not an accident that many Digital Humanities projects today are built around XML and related technologies. The related technologies addressed in the course include a powerful declarative programming language (XSLT), a formal model for the navigation of XML documents (XPath) used by XSLT, a metalanguage for the formal modeling of documents (Relax NG), a constraint modeling language (ISO Schematron), a graphic description language (SVG), and others.
While the focus of the course will be on computational methods, modeling, and programming for humanities research, it may be noted that XML is also the internal format for many general applications in broad use today (including the entire Microsoft Office and LibreOffice suites), it has been embraced by the relational database community as an application-independent interchange format, and it plays a substantial role on the World Wide Web, where HTML (the language underlying most web pages) may be expressed as an implementation of XML. The course does not concentrate specifically on the development of web pages, but because of the inherent relationship between XML and HTML and because so much Digital Humanities research is designed to exploit the advantages of Internet publication, students will also acquire a drive-by knowledge of how the technologies underlying the World Wide Web operate and will develop their own web sites to support their research projects for the course (about which see below).
Upon successful completion of this course students will be able to 1) identify opportunities for the application of computer technology to authentic research problems in the humanities; 2) analyze the structure of texts in the humanities and develop formal representations of those structures; 3) write original computer programs, using languages in broad use in the Digital Humanities and document processing communities, to conduct research on those texts; and 4) operate comfortably with industry-standard development resources for code development, project management, and discussion.
This course will involve lectures, discussions, reading, and small problem sets and related assignments. Additionally, early in the semester students will identify, through consultation with the instructors, collaborative humanities-based problems that interest them personally and that are amenable to computational processing, and over the course of the semester they will develop and implement their own systems to engage with the research questions they have identified. Both to provide a general survey of the range of activities subsumed under the rubric of Digital Humanities and to help identify suitable projects, the course will also introduce students to computer-related issues in the humanities, to Digital Humanities as a discipline, and to the relationship between Digital Humanities and traditional fields in the humanities, on the one hand, and to computer and information science, on the other. Grading will be based on a combination of small assignments, tests, and the large, semester-long research project.
As is appropriate for an Honors course, this course is run similarly to a graduate course: there is a lot of work and students are expected to attend all sessions and complete all assignments on time. Students who regularly keep on top of the workload typically earn high grades and are very satisfied with how much they have been able to learn in the course of the semester. Students who frequently miss class or assignment deadlines will not be able to complete the course successfully. Requirements, then, include regular attendance, timely completion of assignments, regular participation in online course and project discussion, successful completion of tests, and active engagement with and participation in the course project. Assignments include readings, small coding problems, response papers, and a large collaborative research project that will be developed over the course of the semester.
Students are required to have a laptop (not a tablet) in order to access coding software at home and/or during project meetings. Pitt IT offers Chromebooks for students to borrow for free. Students can access Windows-based software on University Chromebooks and desktop machines in computing labs through the Virtual Computing Lab.
The principal (and required) textbook is Michael Kay, XSLT 2.0 and XPath 2.0 programmer’s reference, 4th edition, Indianapolis: Wiley/Wrox, 2008, ISBN-10: 0470192747. ISBN-13: 978-0470192740. Earlier editions are not acceptable. This book is available from Amazon (do not buy the Kindle edition, which is difficult to use because of poor indexing) and other on-line vendors. A digital copy (PDF format) is accessible through the Pitt library system. Other required materials, a list of which will be distributed by the instructor for each topic, are available at no cost on the Internet. All of these materials, including the Kay book, are intended primarily for reference, which is to say that students should anticipate using them frequently and intensively to research solutions to particular problems, but they are not expected to read them cover to cover.
This course will use the <oXygen/> XML Editor and IDE (integrated development environment), which is available in all CSSD computing labs (including the Virtual Computing Lab) through a site license purchased by the University. The site license also permits students enrolled in this course (and only those students) to install a copy of the software on their personal computers (Windows, Mac, and Linux) for use at home (for course-related purposes only). The software can be downloaded from https://www.oxygenxml.com and the license code to register your home copy is available as an announcement inside Canvas. We will notify you about other course software (all free) as the need arises.
For ease of access and consistency, Canvas (https://canvas.pitt.edu/) information for this course will be published only under the Slav 1050 listing. All course participants have been added to this section (regardless of the section in which you enrolled) for Canvas purposes only; your schedule and transcript will reflect your official enrollment rubric.
We use Canvas only for the following purposes:
Most course materials will be distributed not on Canvas, but on the instructor’s server: http://dh.obdurodon.org (Obdurodon). This includes the course description (this document) and syllabus, readings, assignments, announcements, etc. We use Obdurodon for most purposes because it is integrated with course-specific resources not available on Canvas. We use Canvas for the purposes listed above because it provides appropriate controls for security and privacy.
Early in the semester groups of students will identify, though consultation with the instructors, a public domain text (that is, without copyright restrictions) in the humanities that interests them and a set of related research questions, and will work with that text throughout the semester, performing document analysis, developing and implementing a formal structural model, encoding (marking up) the text according to that model, developing programs to perform research with that text, and constructing a web site to publish their research. Each project team will meet weekly for approximately one hour with a project mentor (one of the instructors) outside class for project planning and discussion.
We will manage course projects in an online professional development environment called GitHub, and we’ll explain how it works and what the relevant terms (repo, issue, project, etc.) mean in class, so if you’re reading this at the beginning of the semester, don’t worry about the jargon or the technical details.
Once project teams have been formed, each team (not each individual student) will post a weekly project update, in the form of an Issue on their GitHub project repos, due each Friday. These postings should be status reports about your projects and should address four topics: 1) what you accomplished in the preceding week, 2) what you learned, 3) where you got stuck (and how you plan to get unstuck), and 4) what you plan to accomplish in the upcoming week. Reports are typically brief, but they should address both the state of the project in general and the specific weekly contributions of each of the individual team members. The instructors will show you how to use the Projects and Issues tabs in your GitHub repos (which is what we do in our own research) to manage tasks, timeliness, and any impediments you might face. Weekly project update postings should refer (with links) to specific new or revised content on the repo.
Unlike with projects in many other courses, the project evaluation is based not
only on the final product, but also on regular, steady progress on individual
project related tasks, and your instructors will work with you to identify
appropriate weekly goals for your project using Github Projects. Weekly progress
will be graded on the following scale: exceeds target
(A+), meets
target
(A), some progress
(B), minimal progress
(C), no
progress
(F); the lowest two Project Progress grades will be excluded
from the course grade. Because the primary purpose of the project is for
students to learn how to use the Digital Humanities tools and methods employed
by professionals, the instructors will work with you during your weekly project
meetings to help you learn to apply the necessary methods to your own research,
and obtaining your results according to those methods is part of the evaluation
of the project. If your team determines your research needs a technology or
method not taught in depth in the course, please speak with an instructor, who
will help you figure out how to incorporate it. All project components (weekly
progress = 30%, midterm task = 10%, final result = 20%), taken together, are
worth 60% of the course grade.
In addition to project tasks, course activities include reading, coding, and response paper assignments, as well as participation in formal and informal online discussion. Students must complete at least 90% of each homework component (programming assignments, response papers, project tasks, participation in online activities) on time in order to pass the course. For students who meet the 90% requirement, these assignments, taken together, are worth 25% of the course grade.
Students will need to observe file-naming conventions for all uploaded homework and project files. These conventions are explained at http://dh.obdurodon.org/file-naming_conventions.xhtml (also linked from the main course page); please ask the instructors if anything is unclear.
Coding assignments in this course are a technique for learning and studying,
and not—as in many other courses—a way of testing whether you’ve already
learned something covered in class or in an assigned reading. Because a
crucial skill in Digital Humanities development is the ability to look up
how to do something you don’t already know how to do, these assignments will
frequently challenge you to write code that you do not yet know how to
write. Students who are used to the homework-as-test model of course design
may find this disconcerting (But they haven’t told us how to do
this!
), but professional developers have to look things up all the time,
and learning how to look things up is a critical pedagogical goal of this
course. There may be times when you don’t get the result you want, and in
those cases you can still get full credit for the assignment if you’ve made
a serious attempt and if you submit, along with your code, a description of
what you tried, the results you expected, the results you got, and what you
think went wrong. Getting stuck is part of the learning process and the
instructors will be happy to help unstick you as long as you’ve described
your understanding of the problem and your attempts to resolve it on your
own. To help you develop the habit of carefully reading, and then
explaining, your code, you must submit at least one relevant, thoughtful
comment with each coding assignment.
Note: When submitting commentary with your homework
assignment, refrain from using any Canvas-specific commenting feature;
instead, you should write your message directly in your homework file as a
formal comment (we’ll show you how). This is the only way to guarantee that
the instructors will be able to see it.
The instructors will post solutions to and discussion of programming
assignments on Obdurodon after the assignment deadline. The instructors will
read and evaluate all student homework, and will post an assessment on
Canvas, and we will write back to you with individual comments only if your
specific submission raises an issue that we don’t address in our general
posted solution. If we don’t return your assignment, that means that we have
nothing to add to our posted solution, which you nonetheless need to read,
and should you have any specific questions after you’ve done that, please
ask the instructors. Coding assignments are assessed as check plus
,
check
, and check minus
. Don’t think of these as grades,
since they all receive full credit; they are feedback, for learning
purposes, about how well you engaged with the assignment. If you have not
engaged with the assignment adequately (whether that means solving the tasks
or discussing the coding impediments you encountered and how you dealt with
them), we will ask you to meet with us to review the issues and then
complete a followup (redo) task in order to receive credit. Submissions that
are blank, inappropriately short, or otherwise not reflective of reasonable
time or effort being spent on the assignment will be marked as not
submitted
. Because we post solutions to coding assignments and
review them in class and because homework assignments are sequenced, and
therefore time-sensitive, we cannot accept late homework submissions.
Students will be asked to submit 300- to 400-word response papers to readings
or as evaluations of Digital Humanities web sites, projects, and resources.
Your response does not have to be long, but it must show a thoughtful
intellectual engagement with the material. For example, don’t summarize an
article (which you could do just by skimming or reading the first paragraph)
and don’t just praise or condemn a web site without going into specifics
about why some component is or is not well designed and suggesting specific
ways it could be improved. Good response papers show thought and attention,
and may respond to a reading or site in general, or to a detail of specific
interest. Some sites are significant for their design and user experience,
others for their research methodology, and response papers should engage
with the aspects that are most significant to the project. In some cases the
syllabus will specify the focus of the response papers for a particular
assignment. Response papers are also assessed as check plus
,
check
, and check minus
, all of which earn full credit, and
your instructors will return them with individualized feedback.
This course will use Slack (https://slack.com/), a chat platform that has become a de facto standard for software developers, to host general discussion, and all students are required to contribute to that discussion by Wednesday each week. Despite the image of the programmer as a solitary soul bent over a glowing screen in a cubicle, programming is, in reality, a social activity, and real programmers make liberal use of discussion resources like Slack to ask and answer questions. Furthermore, despite the classroom tradition where students submit homework to a professor, who grades and returns it, so that nobody else ever sees it, that’s not the way coding works in the real world and it’s not the model in this course. Like real developers, we ask and answer questions in the open. This course component has two principal goals: 1) it provides a forum to ask and answer questions, and 2) it helps course participants become familiar with an industry-standard discussion platform.
Beginning in the fourth week of the semester, each student is required to read all new discussion postings (it is not necessary to read the backlog from prior semesters, although you may find that interesting) and contribute at least one posting a week to the general discussion: ask a question, answer a question (comment on an existing posting, typically in a thread [subdiscussion]), make a suggestion, pass along a link to a site that showed you something you could use in your project (and explain what it is and why it was useful), etc. Periodically throughout the semester, your instructors will also ask you to respond to a particular posting on Slack, and your response will be evaluated for, among other things, its thoughtfulness and consideration of other student responses. The syllabus will clearly note these Single-Issue responses, which will serve as that week's Class Discussion Posting.
Participation in the discussion beyond the minimum requirement is strongly encouraged. Don’t be shy about asking questions in this forum; your instructors do this all the time in their own work, and you can’t learn to code if you don’t learn how to participate in a coding community. And don’t be shy about answering questions, which is both good citizenship and personally satisfying. Much of the classroom time will be devoted to teacher-centered instruction, and the discussion framework offers an opportunity to interact with classmates to cultivate a community in which peers provide insight, solutions, and general discussion. This discussion forum should be the first resource for questions, comments, etc.
Over the course of the semester it is likely that you will find a technology or software we use to be frustrating. Please keep your postings professional and respectful.
Once the weekly project updates begin, each student is required to read all
new Issue postings on the other project repos and respond to at least one
status report by another team each month. These responses may be brief, but
they need to be thoughtful, something more than nice job!
or very
interesting!
or I look forward to seeing what you do next!
You might make a suggestion, offer a critique, ask (or answer) a question,
discuss how something in someone else’s posting gives you an idea of
something to do on your own project, share a link to a resource you
discovered that might be useful for the other team, etc. You will find it
helpful to follow the other teams’ repos, which you can do by clicking the
Watch
button at the top of their repo page. Issue responses are
also assessed as check plus
, check
, and check
minus
.
There are seven coding tests, of which only the best five are incorporated into the course grade (15%). There are no make-up tests; if you miss a test, it is effectively excused, since it just becomes one of the two that don’t count.
All test are assigned over a weekend. They will be open-book/open-notes, but they must be completed individually, which means that although you can look things up (and you are encouraged to do so, as needed, much as professional developers do), you are not permitted to request or receive help from any other persons. If you are confused or uncertain about anything on any of the tests, post an inquiry in Slack, which your instructors monitor regularly, and we’ll respond there.
There is one midterm evaluation (take-home; 10%), which is collaborative and project-related. There is no final examination.
This is an Honors course, and students should expect a minimum of two hours of outside preparation for each hour of class time. The workload will be heavier at the beginning of the semester, when students will need to acquire quickly a foundation for dealing with more complex or advanced topics. The tempo of the course changes in the last few weeks; before that point, you’ll be learning and practicing a lot of new technologies and beginning to apply them to your projects. After that turning point there are fewer new technologies, and more of your course time outside class will be devoted to developing your projects. Once the projects begin in the fourth week of the semester, project teams will meet once a week for approximately an hour outside class with one of the instructors, who, in the role of project mentor, will help guide the development of the project.
Letter grade (LG) or satisfactory/no-credit (S/NC). In accord with Dietrich School policy, students enrolled on an S/NC basis must earn at least a straight C to receive credit. G grades (incompletes) are given at the instructor’s discretion and only in conformity with the requirements described in the Undergraduate Student Handbook at https://catalog.upp.pitt.edu/content.php?catoid=72&navoid=6226#grading-systems.
Homework assignments | 25% |
Tests (best five) | 15% |
Midterm (project based) | 10% |
Weekly project grade | 30% |
Final project grade | 20% |
Students must complete at least 90% of each individual course component (coding assignments, response papers, discussion activities, project milestones) in a timely fashion and attend at least 90% of all class sessions in order to pass the course. There is no separate extra-credit option, but exceptionally ambitious and original projects will be recognized as such when they are evaluated and graded, as will exceptionally engaged participation in the discussion activities.
Because each topic in this course builds on topics introduced previously, students who wish to do well must attend regularly and complete all assignments on time.
Attendance: Attendance is strictly required, and students must attend at least 90% of the class meetings (arriving on time and remaining until the end; repeated late arrival or early departure may be counted as absence at the instructor’s discretion) in order to pass the course. Your instructors understand that Real Life may occasionally make attendance impossible, but you should be committed to attending all sessions except in case of unavoidable emergency.
Late work: Coding assignments and response papers must be uploaded to Canvas, and Github Issues and comment contributions, as well as Slack discussion contributions, must be posted by the date and time specified in the syllabus. Homework assignments will be posted on Obdurodon, where they will be accessible at any time, and students who miss class are nonetheless expected to consult this site and submit assignments in a timely fashion. Because the instructors will often have provided answers to the homework (either in class or by posting solutions to Obdurodon) after the submission deadlines, no late homework will be accepted.
Homework must be uploaded to Canvas before class on the due date. If you wish to upload a revised version afterwards, reflecting additional understanding you may have acquired from our posted solution or our discussion in class, you're welcome to do so, but in that case it isn't helpful to submit only a late, improved version because we can't tell whether that reflects your improved understanding of the problems you had originally or only your understanding (or even just copying) of our presentation of our solution. For that reason, if you submit a revision of a coding assignment, it should take the form of not just new code, but a critique of your original version, in which you discuss what you did wrong, why it’s wrong, what it does instead of what you wanted it to do, how you can fix it, etc. That type of resubmission can demonstrate that you understand how to approach solving the problem, which is more important in terms of learning to code than just understanding how we solved it. If you do this, please notify the instructors.
Make-up tests: There are no make-up tests, but only the best five test results (out of seven) will be counted in the course grade, which means that students may miss at least two tests without a grade penalty. There is a take-home midterm (a collaborative, project-oriented task), but there is no final examination.
During the Covid-19 pandemic it is important that all members of the University community abide by the public health regulations, the University of Pittsburgh’s health standards and guidelines, and Pitt’s health rules. These rules have been developed to protect the health and safety of all of us. At times when the University requires face covering, you must wear a face covering that properly covers your nose and mouth when you are in any campus building. If you do not comply, you will be asked to leave class. It is your responsibility have the required face covering when entering a university building or classroom. For the most up-to-date information and guidance, please visit https://coronavirus.pitt.edu and check your Pitt email for updates before each class.
If you are required to isolate or quarantine, become sick, or are unable to come to class, contact your instructors as soon as possible to discuss arrangements.
If you have a disability for which you are or may be requesting an accommodation, you are encouraged to contact both your instructor and Disability Resources and Services (DRS), 140 William Pitt Union, (412) 648- 7890, drsrecep@pitt.edu, (412) 228-5347 for P3 ASL users, as early as possible in the term. DRS will verify your disability and determine reasonable accommodations for this course.
This course permits (and encourages) collaborative homework preparation, but only under the conditions specified at http://dh.obdurodon.org/collaboration.xhtml. Receiving assistance from another person on a course activity without observing these conditions is an academic integrity violation because it misrepresents someone else’s work as your own.
Students in this course are required to comply with the University of Pittsburgh’s Academic integrity code. Any student suspected of violating this obligation for any reason during the semester will be required to participate in the procedural process, initiated at the instructor level, as outlined in the Code. To learn more about Academic Integrity, visit the Academic Integrity Guide for an overview of the topic.
We encourage you to look stuff up
as needed, and you may use code you find
online in your projects and assignments as long as you attribute it properly.
Please follow our guidelines for the
ethical use of code you found on the internet to avoid plagarism and
ensure that using the code contributes to your learning. Copying code without
attribution or that in other ways does not observe the guidelines at the link
above is an academic integrity violation because it misrepresents someone else’s
work as your own. Using ChatGPT or other AI services to help prepare homework
assignments, even if you edit the result afterwards, is not looking stuff up; it
is cheating and it constitutes a violation of Student Obligations 1 and 7 of the
academic integrity code.
Copying code from answer keys to our assignments, even with modification, is expressly prohibited, except that you may use (with proper attribution) information from answer keys that we have already posted and linked to our main course site this semester, that is, answer keys that we have deliberately and explicitly published for use by students in the course this semester.
This course fulfills the Dietrich School of Arts and Sciences Quantitative
Reasoning General Education Requirement (GER) as described for the GERs starting
Fall 2018 (term 2191; see https://www.asundergrad.pitt.edu/academic-experience/general-education-requirements).
That GER reads as follows: All students are required to take and pass with a
minimum grade of C- at least one course in university-level mathematics
(other than trigonometry) for which algebra is a prerequisite, or an
approved course in statistics or mathematical or formal logic in a
department of the Dietrich School of Arts and Sciences.