Interview with Syd Bauman
Syd Bauman is the XML Programmer-Analyst for the Digital Scholarship Group in Snell Library. Syd spoke with Colleen Nugent McLean, CDS Coordinator, about his work with XML, the TEI, and the Women Writers Project. His comments have been edited for brevity and clarity.
Colleen: Thanks for taking the time to meet with me. How did you get into Digital Humanities?
Syd: That's a really interesting question in the way it's phrased. Because of course, I thought digital humanities came to me, not I went to it. Which is to say, I was involved with this stuff before it was called digital humanities, as was Julia [Flanders].
I thought I was going to be a systems programmer in the late 1980s. But I took a break from doing that in 1989 to go to paramedic school, and when I came back, I didn't have a permanent position as a systems programmer anymore. I was looking around for a job and got offered this position, which would now be considered the digital humanities, with this kind of weird offshoot group that was attached to the English department at Brown University called the Women Writers Project. I don't think I'd ever heard of it at that point, I'm not sure.
I mean, at that point, how long had it been in existence?
Well over six months, maybe 18 months. I think they came into being roughly the same time I left for California to get my paramedic license. It was February-ish in 1990, and I'm looking around for a job. The managing director of the WWP was a friend of mine and she essentially offered me a job. She said, why don't you come on over and see if you can help me out with this stuff.
And it turned out that the stuff she wanted help with was right up my alley. It was exactly the kind of stuff I found fascinating and interesting. She had a bunch of documents that were in the wrong format. She wanted to upgrade the format of these documents. So it required scripting or programming or you know, clever macros in your editor to improve all these files, to change all these files. And so I got very into it right away. It was a lot of fun. And I never left. So that was July 1st, 1990 —at the same job ever since.
Wow. I would love it if you could speak a little bit more about what the experience was of being in a field before it was formally established and then having that as you said, sort of coalesce around you.
It was just something I was doing that was interesting. I realized, you know, without any doubt that what I'm doing is helping English professor types, right? It was a literary project. It was restoring these old works and it felt like the right thing to do. It was a good thing to be doing, right? The canon could use shifting. I mean, the canon of English literature didn't have enough representation of women at all, let alone women of this period, right? Now I didn't know that off the top of my head. Someone told me that, but once you know that it seems it's the right thing to do to fix that, to help correct that. So I was eager to do that, which means I kind of gave up other opportunities to do this.
It turns out, in the early phases of this project, that some of the things that needed doing was explaining to the other English professor or English professor types who were not directly involved in the project what we were doing or what had to be changed. They were scholars who were helping out with various documents in various ways that didn't know much about how this worked. And so explaining that to them was part of the job in a way. I turned out to be pretty good at that. I wasn't a computer scientist, I had taken a few computer science classes as an undergraduate, but I wasn't a CS major. I wasn't an engineer. I had a strong math and science background, but I also had political science and linguistics and I thought very highly of the humanities. So I kind of had the requisite—I don't know if it's vocabulary so much as attitude to be able to chat with people who are humanities scholars about the computing aspects. That was kind of part of what I was doing along the way.
And then also in the very early 90s, the idea that using computers to achieve humanities scholarship goals came about writ large. At least to my knowledge, it came about at Brown. The Computing and Humanities Users Group, aka CHUG, developed at Brown, and I was an on-again, off-again member of this group. Not being actually a humanities scholar myself, in some ways I didn't quite fit in. And not being a computer scientist myself, in some ways I didn't quite fit in. But I wasn't completely estranged from either camp. And the whole point of the group was to get the two camps together. So I kind of fit in that way. Then I can't remember exactly when the idea came along, sometime in the early 2000s, that we shouldn't call this computing in the humanities, rather we should call it digital humanities, and I barely noticed.
Who were your mentors in this field and what have you learned from them?
So the first thing to lay out there right away is, you know, by far the two biggest influences on my DH worldview career life are Allen Renear and Michael Sperberg-McQueen, closely followed by Julia Flanders. Allen and Michael had an enormous influence on how I think about the world.
Steven DeRose introduced me to the idea of descriptive markup. One day Steve and I were walking down Brook Street in Providence, and he just sort of taught me about descriptive markup. And it seemed so obvious to me that I even wondered why it was a thing. Why was anybody doing anything else? Of course, this is the way you do this. So Steve also deserves some credit for being a mentor because he's the one who introduced me to the concept. The ones who formalized it in my brain were Michael and Allen and then later on Julia.
There were quite a few others. I mean, I don't want to say for a moment that there weren't other big influences, but those are the really major ones. What have I learned from them? Interesting, there's a lot of technical stuff and how to approach things which is what immediately jumps to mind. One of the things I really learned is that the approach to doing this work is an approach where everybody's voice matters. These guys didn't brush off someone making suggestions who was not necessarily a part of the core. They were very inclusive in their thinking. I think that there's a bidirectionality here that their attitude was both because they're just inclusive, nice, interesting, interested people and because they understood that there were multiple disciplines and fields that were contributing to this endeavor.
I remember I was working as the tech guy for the Women Writers Project, working on the encoding system, working on documenting the encoding system, working on documenting a way to teach students who show up and don't know how to use the mainframe, how to use the mainframe, working on organizing the files. I would do all that kind of stuff. When the then project manager dropped this book on my desk and it was a blue spiral bound blue book that was kind of thick. And he said, here, I thought you might be interested in that. I looked at it and the title page said it was called Guidelines for Text Encoding and Interchange. Version P1.1.
I kind of started thumbing through it, and my eyes got wider and wider as I went through it. And I eventually just started reading and reading and reading. This thing felt like how you do the encoding of humanities text part of the job. Here was a group of people, international people, some of whom were actual scholars and some of whom were actual technologists, who were literally spending their time thinking about these very same problems and coming up with answers and writing them down. I thought this is exactly what I wanted to do. This is perfect. This is great. I wanted to implement their system right away. Then of course, I found there were problems with their system. And when I got to meet Michael a few months later, he asked, why are you doing X instead of Y, which is what the guidelines recommend. And I explained it to him, and the next release of the guidelines used X, used my way.
I was stunned. He heard the argument and thought, that makes sense. And then went ahead and talked to other people. What do we think of this? How do we do it? But it had a real influence. These people were willing to be influenced by what users actually thought. That was dramatic. That was really important.
I think this inclusivity is true for other aspects of digital humanities as well, that there are lots of different attitudes and histories and approaches that different scholarly communities take. And there's no particular reason that the technology should discount any one of them in favor or pick another as more important or better.
I don't think I ever used similes or metaphors in my teaching before I met Julia. You're laughing because of course, you know, Julia is Miss metaphor and it actually is a very good technique and she uses it very well. I also think I got a lot better at simply writing a paper and giving a presentation. Julia was very helpful as a mentor.
We went to the same conferences and I watched her speaking all the time and she was great at it. That was very helpful. There are a lot of things I learned from Julia, I’m thinking particularly of teaching now. Where I could tell you what was the wrong way to do it, or a wrong way to do it, or even many wrong ways to do it, but I couldn't tell you the right way to do it. And she would come along and say, oh, do it this way. She would take you that step further that I wasn't really able to go on my own. She is very, very good at that.
Somebody at some point, I think in the 1990s, pointed out I was a good mentor. And I thought, Oh, thank you. Am I mentoring anybody? I exaggerate for effect. My attitude from the very beginning was that teaching people, and by people, I mostly mean the undergraduates who were working for one project, was very important to me. Teaching them about these processes, how important descriptive markup is, how important keeping your XML trees aligned is, and how these various things work. The education aspect of it was very important to me from the very beginning, and I have no explanation why. It's just that's the way life is.
Yeah, that's really interesting. I think next if you could just maybe describe your current role in the DSG, including the Women Writers Project, but also any other things you work on.
My expertise is in the XML stack and in fact not even the whole stack. I'm not a particular expert at XForms or XSpec or XQuery. I can manage stuff in all of them a little bit, but I'm not an expert on any of them. So my number one role obviously is providing support for anything that's using the X stack, right? Writing the XSLT or the shell scripts around it or the XProc around it or whatever is necessary.
That's one of my major roles at DSG. I also end up doing a bit of system maintenance and upkeep on machines. It's not that hard, but it does take time. I mean, you have to go learn these languages and learn these processes and learn these systems.
I like providing the technological infrastructure for people whose time is better spent somewhere else. So that includes system maintenance stuff, in particular the X stack work I just mentioned. I also think of myself in some ways as an editor, at the copy editing level. I do some of that here and there as well. And of course, this mentoring role, right? Bringing people into an inclusive atmosphere that lets you have freedom to think your thoughts and have information about what might be better ways to do things available to you.
I would love it if you could talk a bit more about XML in particular, give a very brief gloss of what it is, but mostly from the perspective of why it's something that you're so particularly interested in and why you think it's important.
XML is the idea of marking up a text so that you store it as a tree structure and have explicit indication of where the boundaries of each node in the tree are. The concept of describing what a piece of text is, rather than telling the computer what to do with that text, but just saying this piece of text is whatever, and this other piece of text is that thing, and this piece of text is a thing over here. Descriptive markup is, to quote a seminal paper, not only the best way to manipulate, to process text, to think of texts, to represent texts, it is the best imaginable way to represent Text.
But that's the principle of saying what something is. The actual nitty-gritty of how you say what each part is, there are dozens of different ways of doing that. XML is not the best in the sense that it is not the most expressive. It limits you to this tree idea. A book is divided into chapters, is divided into sections, sections have headings and paragraphs, and paragraphs have sentences, and sentences have words. For a book this nice, neat hierarchy of things that fit inside other things works very well. XML represents that very well, natively. XML is by nature a tree.
But there are things that do not fit in that tree, and XML is not good at representing. XML is also very verbose and has this somewhat annoying syntax for how namespaces work. XML has other limitations, like, “identifiers can't start with a digit” and these kinds of things are just kind of weird and a little annoying.
So I'm not claiming XML is the perfect way to do this in any way, shape, or form. But if you dream up a better way than XML (and several people have) the problem you're faced with is you have to have software that processes it. XML is ubiquitous. Every piece of software that you want for XML, the parser, the interpreters, the linters, the things that find the error messages, the validators, the things that help you developing test suites for your programs, all that stuff is already done for you. It's all out of the box. You have XSLT, you have XQuery, you have XPath, you have XSpec. So that ecosystem together is all there ready to be grabbed. And for the most part, it's all open source, or at least there's some version of it available in open source. That's a huge plus. There's no disadvantage to XML that's bigger than that plus. In fact, all disadvantages combined are not bigger than that plus.
That makes a lot of sense. And am I right in thinking that XML is more pervasive than the people who maybe haven't heard of it before would imagine it is?
So it is. To be fair, in library worlds, there are a lot of folks who consider XML old school, and think everything should be JSON. And there's some truth to that in the sense that for sending certain kinds of simple structures from one machine to another JSON is significantly more efficient. There's no reason to use the overhead of XML if you don't need it. But that said, you know, you can't create a representation of all 14 versions of Walden, let alone a variorum of them in JSON. You just can't, you'd be crazy. Whereas in XML, it's a little tough in some corners, but overall, it's designed for the purpose, right? Even just transcribing Moby Dick into JSON would be an insane thing to do.
XML is just the king of the document world. I mean, if what you want is documentation for your aircraft or for your nuclear missiles, XML is clearly the way to go. There's no if, ands or buts about that. And that includes, you know, documentation for your operating system or your phone or whatever it is you're writing. Descriptive markup is the way to go when XML is, generally speaking, the representation you're gonna wanna use, and there are many systems designed for marking up documentation in XML. One example that I like to give is the communication between the gas pump where you fill your gasoline from and the cash register inside the little office, that communication between the two is in XML. But if what you want to do is just transfer information from a server to a client, whether you choose XML or JSON or something else, there are reasons for one, reasons for the other, it depends what you're doing.
I know you’ve been involved for a while, so I think it would be great if you could explain what the TEI Council is, and explain the relationship between TEI and XML?
There's an understatement. So the TEI, the Text Encoding Initiative, are the folks who think about how to encode extant humanities texts for scholarly processing such that they will outlive whatever computer system you're currently using. And they, the TEI folks before my time, settled on SGML as the best way to do that. XML was released in 1996. Come roughly 2002–2004, TEI switched from SGML to XML. XML, by the way, is just a pared down version of SGML. SGML in retrospect had lots of capabilities and features that nobody used or cared about. So getting rid of them was a good idea. But the core ideas of SGML were fantastically wonderful. So we kept those in XML. And anybody you talk to will disagree on which were the exact features we should have gotten rid of and which were the exact features we should have kept. But everybody was at least reasonably pleased with the result.
In 2002, the TEI started a serious effort to transform itself from SGML to XML, and the year earlier had switched its funding model in the United States. The TEI changed its funding from a bunch of grants from funding agencies contributing money that paid for the two paid editors who organized and met with various working groups that would do stuff to contribute to the guidelines. Instead, the new funding model would be a consortium of institutions, libraries, and universities mostly, but not necessarily all, who would contribute an annual fee to this group that would pay for the two editors. And instead of having disparate work groups in particular areas, we would pay for meetings of a set group of people called the TEI Council. Or to be more precise, the TEI Technical Council, which would be responsible for maintaining the Guidelines, be responsible for making the decisions, doing the work of maintaining the guidelines, and of keeping it up to date with current DH practices.
At that time, I was one of those two editors. And that continued until roughly 2008. The editors work for the technical council and produced P5 in 2008. This was a huge change in how we thought about the TEI. I mean, first we did P3 to P4, which was not a huge change. It was just changing the underlying structure from SGML to XML. But then we went to P5, which is a big, a radical difference in how we thought about constructing guidelines. The actual guidelines themselves were different, but not radically different. But the way they were constructed was radically different. It took advantage of this XML stuff. So the guidelines at that point were written in XML and had an entire XML stack to produce them.
Then the editors went away. The consortium decided it didn't need paid editors anymore, and there was a technical council and a board of directors. The technical council maintained the role of being the ones who think about and maintain the guidelines. But the workload shifted, because in prior years the technical council made a lot of the major decisions, but most of the work was on the editors' shoulders — the editors actually did the editing, came up with examples, copy edited, and made sure everything was valid. That kind of work was mostly up to the editors initially. Which isn't to say the technical council did nothing, but the editors did a lot of that work. And that work went away from the paid editors and now became part of the technical council's role. So starting in 2008 or 2009, the technical council now absorbed the responsibility for actually doing the work of maintaining the guidelines. I stepped away for a couple of years, and then in 2012 I was elected to the council, and have been on it ever since.
Is that around the same time that the Women Writers Project moved here from Brown?
Almost exactly. We moved to Northeastern in 2013. So I think I might have just become a member of the council the year before. Of course, I paid attention to what the TEI was doing to some extent before that, but I wasn't as involved as I had been as an editor or as I am now as a member of the council.
As a member of the TEI Council, we work on what should the guidelines say, what should the schemas say, how should they get built, and a lot of what we do is fixing bugs that we find in the programming that supports it. A lot of what we have to do is make decisions. How do you decide whether this should be an empty element or an element with content? How do you decide this should be a pointer or a keyword? That kind of decision. There's more expertise on council now about that kind of thing, or at least there are more people who can make that kind of decision than there used to be, I think. So I feel less like I'm necessary there. There is not very much expertise at all on Council about schema design content model algebra and that kind of stuff. There are only a few of us on council that really are comfortable in that realm. I find myself doing more work on the ODD language, which is the TEI schema language, than any other part of the TEI. Not more work than all other parts of the TEI combined, but the plurality of my work is on the ODD language.
Thank you. That's really interesting. Outside of the major projects you support, are there projects at the DSG that you find fascinating or have played a role in?
Talking about other projects at DSG, I mean it is kind of TEI related, but I find TAPAS and CERES very interesting. Also though not actually part of DSG, the Digital Repository Services (DRS) as well. I find all those things really interesting. I have no direct involvement with any of them anymore. For many of these projects, I've played a little role in the beginning, right? I answered some questions about setting it up and how they might do this, that or the other, but I never had any real hands in the pie, except for TAPAS.
I kind of feel like my plate is already pretty full. But that said, the Civil Rights and Restorative Justice project is just such an important project. It is a project that I kind of wish I were more involved in because I think it is such an important project in the social constructs of it, as opposed to the actual technology parts of it. I think it's because of the subject matter that I'm really drawn to that so strongly. I'm also similarly drawn to the Homosaurus in a way.
I really was appreciative to get the opportunity to go to the CRRJ conference last summer and just see all those talks and the movie that they made too was really powerful. It was a really great experience.
Right, even though I can't say I made that, I can say those people made that next to me. This is a really interesting, really cool, really important, well done project. I'm vicariously proud of it, you know?
Are there projects that you support in terms of the technology?
For technology, I'd like to help to work with projects, where my input is actually really helpful, and for a lot of these projects, they just don't need the kind of expertise I have. I really like helping projects, professors, groups, whatever it is, where my input can make a difference. My skill that was in much more demand in the early 90s to 2000 was the ability to talk to both an English professor on one side and assistant programmer on the other side and kind of bridge that gap. That is much less necessary in the modern world. That particular feature of Syd is not as important. There are a lot of technologists who can understand humanities people and vice versa these days.
Ok, and finally what is the strangest or most wonderful place you have had to travel for your work?
So the most wonderful place, that's an interesting question. There are a lot of great places and a lot of great things to say about the various places I visited. I've had the opportunity in large part, thanks to the workshop series that the TEI project puts on. I could not afford to go to a lot of places that the TEI would be willing to send me to go to meetings like Iceland, for example.
I think one of the most wonderful places I went to was Zadar, Croatia. It's across the sea from Italy and it was just the most fascinating place. This is a TEI conference 2010, I think it was. The weather is Mediterranean. It's just a gorgeous place, weather-wise.
It was just wonderful, as many old European cities are, but it was really starkly well done. Dramatic. Well-preserved. It was an area that had ruins back from the Roman era, from the 12th century, from the 15th century, ruins from the 20th century before World War II around, and there were buildings from the 1970s, 90s around. And that sense of sliding history, as it were, was really great. It was on the sea and it was just a beautiful place. I would like to go back there. That's high on my list of wonderful places I've been. I would really like to go back. Nonetheless, I think my favorite city in the world is probably Prague. I would highly recommend Prague to anybody who's going. It was also very fun to be in Taiwan, where Julia and I got to be in the tallest building in the world.
One of the strangest places I've been, though, that jumps to mind is not that strange. In the middle of Montreal, there's a hotel called the Europa. That's the hotel where the predecessor conferences to Balisage were held for years. It was just a very bizarre place. It had a mildly interesting architecture and very interesting artwork attached to that architecture. So if you're not interested in heading out to Europe, the Europa Hotel in Montreal is a little bit closer.