Archives
Author Archive
June 15, 2014
In My End is My Beginning
With the support of EMiC I have attended DHSI as a student from the very beginning and have learned an enormous amount – only part of my huge debt to EMiC over the years.
In the course of my years at DHSI, I believe I have set two precedents: I am the first person to have retired since joining EMiC and I am the first EMiCite to have graduated from the status of student to instructor.
Previous to teaching this year’s DHIS/DEMiC course I had taught TEMiC in Peterborough, but while that course dealt to some extent with digital editing its primary focus was editorial theory. The course this year grew out of a text/image tool for genetic editing which Josh and I are in the process of developing (see Chris Doody’s post, The Digital Page: Brazilian Journal ). The course did not focus on this tool, however: its focus was on the XSLT which is the backbone of the tool, and the collaborative process that went into developing it.
We had originally intended to call the course Every Batman Needs a Robin (a bow to another, very successful digital humanities collaboration involving Mike DiSanto and Robin Isard) but we soon realized that this would misrepresent the true nature of our non-hierarchical working relationship. We considered Every Batman Needs an Alfred but that seemed a bit esoteric.
Although Josh and I worked very closely together in planning the course, I was very much his assistant in teaching it, since his mastery of XSLT far exceeds mine. But this was a central thrust of the course. If digital humanists are to succeed in their projects, unless they are highly experienced programmers themselves – which few are, or have the time or inclination to become – it is necessary to establish a strong, personal, longstanding relationship with a developer. Our experience, and the experience of other digital humanist/developer teams, is that the project will take shape as a result of this collaboration, and the shape that it will take is often very different than what the digital humanist who initiated the project had in mind.
My role in the course was twofold: to help students out with the numerous hands-on exercises which we had devised for them (I wasn’t nearly as good at this as Josh) and to act as a kind of stand-in for the students, asking for clarification or repetition of points that were blindingly obvious to Josh but perhaps less so for the non-programmers amongst us. I was obviously much better at this than Josh was.
We had a very wide range of students in the course – from Master’s students to a Professor Emeritus – with a similarly wide range of projects, skills and aptitudes. But, judging by our interactions with the students and the student evaluations we struck a pretty good balance.
Certainly, from my point of view teaching such a committed and intelligent group of students who seem to have genuinely appreciated the work we put into the course, and doing so with my son (we didn’t fight once!) was a great experience – a real high point of my career and life.
I was very pleased to hear, then, that we have been asked to return with the course next year. So one of my many debts to EMiC, as it comes to its appointed end, is that my association with it has marked a new beginning for me – as a DHSI instructor.
June 13, 2013
Every Batman Needs a Robin
As a result of numerous discussions I have had this year at DHSI with EMiC scholars at all levels of experience—MA students, PhD students, postdocs, and profs from assistant to full, I have put together a proposal for a DHSI course next year. It has not been officially approved, but Ray and Dean are very interested in it and I will be discussing it with them next week.
I thought it would make sense to outline what the aim of this course—actually its double aim—is, and why I think it would be useful for many EMiC-scholars. It would be useful for my discussions with Ray and Dean if I had some sense of whether there is real interest in such a course.
The course would deal with 2 problems simultaneously:
- If you can’t do XSLT you can’t display your TEI documents—and you probably can’t do XSLT
- It is impossible to achieve mastery of XSLT or any other tool without spending so much time on it that you may have a negative impact on your career, especially if you are at the beginning of it.
The answers to these problems are 1) to develop enough basic familiarity with the tool you are interested in (such as XSLT, for example) so that you can discuss what you need with a developer partner—a week-long course at DHSI should be enough to do this—and 2) to develop a long-term working relationship with such a partner.
Some background first. I took the XSLT course from Syd and Martin and got a very good grounding in the basics. However, I was able to move on to the point where I can actually use XSLT in my project only because I happen to have a close working and personal relationship with an expert in the field, who happens to be my son. I know enough to write very basic XSLT, but, much more importantly ,I am familiar enough with the concepts and terminology that I can speak to my son and he can speak to me—and together we have produced some pretty sophisticated XSLT which does everything I want it to do. Because of my unusual situation I believe I am the only editor associated with EMiC who actually can work in XSLT—that is, who can turn my TEI files into web pages that people can actually read.
I have been aware of this very troubling situation for some time now. However, I became aware of something else at DHSI this year: everyone I know who is making real progress on their projects has a relationship between a humanist and a developer which is similar to my own. In each case the humanist/developer pair have enough of an understanding of each other’s fields to talk to each other and work together productively. Some examples: Dean Irvine & Alan Stanley and the Modernist Commons, Paul Hjartarson & Harvey Quamen and the Wilfred Watson project, Michael DiSanto & Robin Isard and the George Whalley project. Scholars who do not have such a working relationship seem to me to be in a high state of anxiety, especially graduate students and junior faculty. They feel that they have to acquire mastery of a range of tools while at the same time pursuing their research—when in fact what they really need to do is to acquire a basic understanding of their tools—such as a week-long course at DHSI can provide—PLUS a relationship with someone they can talk to and work with on an ongoing and well-informed basis concerning their plans and needs.
The course I am proposing would have as its aims to model the dynamics of such a relationship—with specific reference to XSLT—and to provide advice on how to develop it. You might compare the NetSquared project which has similar aims in relationship to social-benefit projects. We would begin by outlining the basics of XSLT; we would then go through in detail some of the XSLT we developed for use in the Digital Page project, while at the same time modelling the collaborative process that led to this development; finally we would help the students in the course to create their own XSLT to transform TEI files which they bring to the class. The takeaway for each student would be (1) XSLT files that would generate real HTML files for use in their editions and (2) guidance on how to establish the kind of ongoing working relationship that would result in the development of a wide range of more sophisticated XSLT files. We would invite other successful working partners to speak to (2) with regard to their own projects, and, indeed, in later years a course with a similar focus on collaborative digital humanities work could focus on entirely different aspects of digital humanities, such as databases, or interface design, for example. Taking our cue from Michael DiSanto & Robin Isard I am thinking of calling the course Every Batman Needs a Robin: A Collaborative Approach to XSLT.
A course of this sort will by necessity have limited enrolment—maybe 15—to allow for intensive hands-on mentoring. Because of the heavy emphasis on mentoring, we need to ensure that everyone has the appropriate basic skill set and has given serious thought to what they want their XSLT to produce. Therefore, everyone will be required to submit, before the course begins, 1) a text which they have already marked up in TEI and 2) a clear idea of how they would like it presented, perhaps in the form of a mock-up in Word. The more preparation the instructors can make leading up to the course the better.
If you think you would be interested in such a course, or if you have any suggestions please contact me at zpollock@trentu.ca. If you have a Robin, feel free to bring him or her along.
June 13, 2011
The Agony and the Ecstasy of XSMLT
This year I took the workshop on XSMLT. It was probably the most useful of the three workshops which I have so far taken at DHSI but by far the most frustrating — one might almost say agonizing. Since returning from DHSI I have been generating, through XSLT, exactly the HTML files based on TEI-conformant transcriptions of some very complicated revised manuscripts. Though I am sure my coding will increase in efficiency and elegance as time passes, I really am fully confident for the first time that I have exactly what I need for my project — and that I have the wherewithal to explain my needs to the research assistants who will be encoding texts for me. I therefore would strongly urge anyone who is going to be involved in digital editing to take this course — even if they entirely lack a programming background, which I do . You may end up hiring someone to design your XSLT stylesheets, but even so, it is very important that you have some sense of exactly what it is you want them to do.
The experience, however, was definitely not fun. In fact, you might characterize it at times (and with a bit of exaggeration) as agony. This had nothing to do with how the course was actually designed and taught. What it did have to with was the fact that people taking the course came from very different backgrounds, with varying degrees of programming skills. As one of the least skilful people in the course, I found the going very rough. I have written a detailed assessment of the workshop from this point of view for its two instructors, Martin Holmes and Syd Bauman — who did an absolutely first-rate job — and I hope that some of my comments might help future instructors make the workshop less stressful and more appealing to people without backgrounds and programming — but I thought it might be a good idea, in any case, to share my experiences with other EMICites. My aim is both to encourage people to take the course, and to give them some sense of its challenges and how they might prepare for them.
The workshop was billed as being about XSLT, but in fact, virtually all of it was about XPath, for reasons I will explain in a moment. An XSLT file instructs your computer to go to a particular point in your XML file and to do something to it. I use XSLT exclusively for presentation purposes. That is, I may want it to present revisions in a certain colour, to centre headings, to indent the final couplet of a sonnet, or whatever. To do this you need to put directions in your XSLT file so that it will know where to go on the XML “tree” to find the part of the file you want it to transform. XPath is the language you used to do this, using terms like siblings, descendants, ancestors, parents, etc., informing you how to get where you want to go. I had no problem with the principles of XPath which are very simple, but I don’t think like a programmer (and I have a terrible sense of direction, which didn’t help) so I quickly found myself getting lost in the maze of any but the simplest XPath paths. I simply did not have the time to absorb and retain all the details of XPath syntax, even though I worked away in my room like a demon after classes, making this the least sociable DHSI I have attended. The difficulties were all the greater because by the end of the week Syd and Martin — and a number of the more advanced students in the class — were performing all kinds of magic tricks with their documents, which seemed to me totally irrelevant to anything I would ever want to do with mine.
What made the workshop extremely useful though, was 1) the very lucid account we were given of the basic principles of XSMLT/XPath and 2) the very very valuable hands on help I got from both instructors, not only with details of XPath that I had failed to grasp in class, but also with my attempts to work with a TEI text I had prepared in anticipation of the workshop. After talking to the two of them about these matters, I was encouraged that two of the most knowledgeable experts on TEI thought my approach to encoding my project, though not particularly sophisticated, was fully adequate to my needs and perfectly kosher TEI, without any need for “tag-abuse” or re-configuring the TEI schemata for my own purposes. Syd suggested a somewhat different kind of approach which would be somewhat more flexible but considerably more complex, and we agreed to continue discussions about it. But I was left with a strong sense that the choices that I had made early on in my project were reasonable and justifiable. By the end of the course I had accomplished what I had hoped for and I was kind of ecstatic.
What could have been done to make the experience of this workshop less frustrating, though? I would make the following suggestions:
1. If you happen to be one of those rare but not quite extinct DHSI birds who uses a PC, practice on a Mac before you start your class. I know this sounds trivial, but I wasted a huge amount of my time, as well as the time of my fellow students and my instructors, trying to figure out how to find my way around the Mac.
2. We used Oxygen for editing our files. Oxygen is a wonderful program and very easy to use. But you still need to learn how to use it. The instructors provided good instructions, in the course material and in their presentations, but with so much else to absorb I kept getting snarled up in technicalities until well into the 3rd day. Another enormous source of frustration.
3. Do some preparatory work before the workshop. Syd and Martin provided useful slides but they would have been vastly more useful if I had had access to them before the class. I suggested to them that they send a list of materials online, as well as of books, to all of the students enrolled in the course a few weeks ahead of time. With some of this behind you, you will be able to take full advantage of the many examples, exercises, quizzes, and discussions of basic principles that went on all week and which were received with great enthusiasm for those who were prepared, by their past experience, to fully appreciate them.
If this course is offered again, I think I may take it. With more experience I am sure I will have a much better time and learn a lot of things that were over my head this time around. — and I fully expect the ratio of agony to ecstasy to shift in my favour.
March 9, 2011
Editing Page
I have just submitted my report on a very valuable experience supervising Emliy Ballantyne as my research assistant in the Digital Page project, so I thought it might be appropriate to say a few words about thoughts and feelings that arose as I was doing so.
I have been involved in textual editing for about 30 years now, and there is no doubt in my mind that the project I am currently involved in, a digital edition of the Collected Works of P.K. Page, is the most exciting of my career, to a large extend owing to the support of EMiC. EMiC has, of course, provided much desired funding for the project — the RAship is a case in point — but much more important is the sense of community it has fostered, through institutes, conferences, this web site, and also by generating an exciting buzz in the world of scholarly editing in Canada that has simply not been there before. At Trent we are particularly fortunate to have several faculty members involved in editing various volumes of the Collected Works as well as a group of outstanding students enrolled in our Public Texts MA program and a recently announced SSHRC postdoc — congratulations to Michele Rackham! The lonely task of the textual editor has never seemed less lonely. I have been particularly inspired and moved by the many gifted and accomplished young people who have been attending DEMiC in Victoria and TEMiC in Trent, as well as the recent conference on Editorial Problems in Toronto, and it has been a real privilege to have been involved in teaching TEMiC along with Dean. When EMiC has run its course, part of its legacy, I am sure, will be a body of texts edited to the highest possible scholarly standards. But equally important will be a community of scholars at all stages of development who will have done great work together and will continue to do and to inspire great work in the future. Sorry if this comes across as a gush, but it is a gush from the heart. In future blogs I will be much more technological and theoretical and philosophical, but I did want to testify to how important EMiC has been to me.
June 8, 2010
Report to Scaling the Digital Humanities
In the unavoidable absence of Dean, Megan and I did a report on EMiC. The aim of Scaling the Humanities is to explore ways in which the Digitial Humanities can “scale up” to avoid unnecessary duplication, to encourage co-operartive development, and to produce the strongest possible face to granting bodies. The first couple days have consisted of a series of reports from a wide range of projects. Tomorrow we will be pooling our various experiences.
Meagan, who is more knowlegeable about EMiC than I am — or than anyone is except for Dean — did a quick survey of the origins of EMiC and I carried on with a brief version of Dean’s update on recent developments, focussing on:
1. image-based editing and markup
2. digitization
3. text analysis
4. visualization
Response to the report was very positive. EMiC is clearly seen as a model digital humanities project, especially in its flexibility and openness to development in previously unforeseen directions. I will report on the results of tomorrow’s discussions and their relevance to EMiC.