In this essay, I would like to highlight the differences between mass digitization efforts such as Google Books, and small-scale scholarly editing projects, most of which use one of a number of standards developed by the academic text-editing community (for example, the Text Encoding Initiative or TEI).

Since the inception of large-scale book digitization projects from 2004 onwards, it has become clear that such initiatives start from a highly different point of view compared to academic digitization efforts. Quantity and commercial opportunity, rather than editorial accuracy, seem to be the primary motives. Still, both are partly engaged in the same project – the digitization of humanity’s printed past. Should they remain separate kinds of efforts, one commercial and the other academic?

My aim is not to theorize about the wider implications of both kinds of digital publishing, but to demonstrate how they may co-exist. Such partnerships, I will argue, consist in maximizing the links that can be constructed between both.

More particularly, it will be made clear that automatic text analysis could play a crucial role in the process of bridging the gap between scholarly editing projects and mass digitization undertakings. This would require the integration of three distinct areas of knowledge:

• scholarly editing;
• mass digitization projects, meaning million-volume online collections of texts which are not scholarly edited (examples include the Gutenberg Project, the Million Books Project, Google Books, the Internet Text Archive);
• automatic text analysis, i.e., instruments from language technology, also known as Natural Language Processing or Computational Linguistics, that may help in linking these two very different kind of document collections.

My argument will close with an elaborate discussion of two sample projects that may serve as ‘proofs of concept.’

Mass Digitization Projects

The most well-known example of mass digitization is probably Google Books, which was launched in 2004. Of the millions of books digitized by the company so far (in cooperation with a growing number of academic and public libraries in the US and in Europe) only a limited amount are in the public domain, and hence available for so-called ‘full view.’ The viewing of books that are still in print is restricted to a limited number of pages, or even short ‘snippets’ for works of which the owner has not been identified yet. (Google Books 2010; Wikipedia 2010)

The distinguishing characteristic of projects such as Google Books is their massive size, spanning millions of volumes. However, when it comes to collections of digital documents, ‘size’ is not merely a linear measure of information. A quote from a Google engineer from 2005, recorded by George Dyson, succinctly sums up the aims of the search company:

We are not scanning all those books to be read by people. We are scanning them to be read by an AI. (Dyson 2005)

What does ‘AI’ or ‘metadata extraction’ exactly mean for the end-user of a massive digital library? The most illustrating example is provided by the current interface of Google Books. Not only does it present the evident metadata concerning a book (author, publisher, year of publication, number of pages), but also a wealth of additional information:

• Chapter endings and beginnings are automatically detected, in order to create a table of contents that links to the correct pages.
• A list of references to this book from various web pages is compiled automatically, and also a list of references to this book from other books in Google Books.
• ‘Popular passages’ are extracted from the book, i.e., passages that are frequently quoted in other books.
• A list of ‘common terms and phrases’ for the book is provided, namely, keywords and names that the artificial intelligence engine believes are characteristic for this work. Just as corresponding features on websites such as Amazon.com (using ‘SIPs’ or Statistically Improbable Phrases to characterize a book), the list of characteristic terms seems to be composed using a bibliometric measure such as TF-IDF, or Term Frequency multiplied by Inverse Document Frequency. This metric will result in a selection of words or combinations of words that are relatively rare in the whole of the collection, but that occur significantly more often in this particular book.

All of this information is extracted automatically from the book’s textual contents. The various applications of AI or machine learning that are used (for example, the TF-IDF metric) may be grouped under the term of automatic text analysis.

These ‘extras,’ I believe, are already changing the way humanities scholars do research today. Semantic markup is added to the collection which is generated by means of the collection itself. This might be compared to how a catalogue of a traditional print library, or a particular ordering of the shelves (e.g., according to discipline or subject), adds information to the library’s collection.

Such automatically extracted metadata constitute the crucial innovation of mass digitization projects. Compared to the ‘markup’ or organizational structure that set apart a print library from a pile of books, the main differences introduced by this sort of markup may be summed up as follows. Automatically generated metadata carry much more information about the contents of the works, compared to a traditional catalogue or subject index. Moreover, the metadata can be easily updated as new items are added. And finally the number of interconnections between books (all of which are immediately available to the user) vastly increases.

The massive ‘size’ of a digital library, then, is not merely to be conceived as a linear measure of information – the depth and scope of the available metadata is actually increased exponentially.

Still, massive text collections also feature a number of important drawbacks. The resistance of academics and other readers to Google Books grew rapidly after the launch. One of the reasons was that the textual content of the books was often inaccurate. Such errors are mainly due to shortcomings in either the available materials (books that are badly printed, or stained) or in the OCR software (Optical Character Recognition) that is employed to ‘read’ the books.

Deficient text seriously endangers the potential of mass digitization projects. It leads to search errors (both in the sense of words that are not found while they are in the text, and words found while they are not in the text) and to erroneous classifications or incorrect metadata.

In 2009, following the Google Books Settlement Conference at UC Berkeley, Geoff Nunberg wrote a blog post where he described Google Books as a ‘metadata train wreck,’ precisely because its systems try to deduce so many metadata about the books in its collection through a purely algorithmic procedure. Amongst the many examples he cites, the following might illustrate the core of the problem:

More mysterious is the entry for a book called The Mosaic Navigator: The essential guide to the Internet Interface, which is dated 1939 and attributed to Sigmund Freud and Katherine Jones. My guess is that this is connected to Jones’ having been the translator of Freud’s Moses and Monotheism, which must have somehow triggered the other sense of the word mosaic, though the details of the process leave me baffled. (Nunberg 2009)

Because language technology fundamentally works by generalizing from a limited amount of textual data, errors such as these will be endemic, certainly in the first phase of the project. Especially when speed and size is valued above data quality and consistency, which is precisely what sets apart mass digitization from scholarly editing. Errors in the text of books and their metadata have technological causes, but derive from a principled starting point: the choice not to use a rigorous editing procedure (according to scholarly standards) in order to save time. Moreover, the editing procedure is not publicly documented, for instance, through an editorial declaration.

Scholarly Editing Projects

Mass digitization projects are unlike digital scholarly editing projects on virtually every point. (A broad range of examples may be found on the ‘Projects’ page of the TEI website, tei-c.org/Activities/Projects.) First, the amount of data in editing projects is extremely small when compared to initiatives such as Google Books. Even the largest of academic digitization projects at most include a few hundreds or thousands of works (for example, the Oxford Text Archive, the Digital Library for Dutch Language and Literature (dbnl.org), or the Deutsches Textarchiv).

Due to the smaller amount of documents, using language technology to automatically extract metadata will also be less successful. Applying a metric for computing characteristic words such as TF-IDF depends substantially on the amount of words available; otherwise the results may easily be skewed.

Scholarly projects have far different characteristics that set them apart. The textual data, although often also generated by OCR, is almost always checked and double-checked by hand, so errors are rare. The same holds for metadata, which is manually entered, often in great detail. Finally, the editing procedure is carefully documented. Standards such as TEI reserve specific portions of the document encoding format for declaring editorial procedures, and encourage editors to use them. (TEI Consortium 2007, 2.3)

Crossing the Divide

So far, my story has followed the established dividing line between these two very different kinds of projects: one based on small-scale but careful and rigorous editorship, the other on bringing together very large quantities of swiftly gathered ‘junk text.’

However, this divide may soon become outdated. The texts of Google Books and the Internet Archive may be inaccurate sometimes, but the quality of both scanning equipment and OCR software has been steadily improving. Metadata is sometimes poor, but is becoming richer and more fine-grained as the collections expand.

As I see it, the question is not when to cross the divide between scholarly publication projects and mass digitization projects, but how. In that scenario it is crucial to investigate what opportunities and threats may present themselves.

A Hybrid Model for Interchange

I propose a hybrid model of possible interactions between TEI projects and mass digitization projects. The model is constituted of three distinct components.

At the core of the model is a carefully curated but relatively small collection of reliable textual data, for instance generated by a scholarly editing project, which will probably be strongly interrelated (e.g., from the same author, genre, and/or period). The documents feature extensive metadata and are edited according to an accepted standard such as TEI-XML.

Next is the cloud, not a single resource but a conglomerate of large and publicly available repositories of text or data, which may preferably be queried in an automatic way (more on this below). Examples of text repositories include large-scale digitization projects such as discussed above, but possibly also other scholarly editing projects that are thematically or chronologically associated with the Core texts. Examples of data repositories are lexical reference works (WordNet, Wordnik, WordHoard), online encyclopedias (Wikipedia and its machine-readable variant DBpedia.org), scholarly databases (JSTOR), bibliographical catalogues (WorldCat), and subject headings (Library of Congress Subject Headings).

Connecting the core with the cloud is the bridging component of the model, namely the interface. The interface includes a website or a number of web services that enable researchers to visualize and annotate the contents of the Core. It provides metadata that complement the markup produced during the scholarly editing process of the Core documents. This metadata is generated by constructing queries based on either the raw textual data or the layers of markup, which may first be pre-processed by means of automatic text analysis. The queries are then sent off to the Cloud, and the returned information is added as metadata to the document and immediately visualized to the user.

In other words, the crux of the model is to query, analyze and re-format the data in the Cloud, in order to stream relevant information to a specialized audience of researchers studying a particular set of Core texts.

The Programming Scholar

One element in the model sketched above is vital to its success. First, the repositories that constitute the Cloud must allow programmatic access to their resources by means of an API or Application Programming Interface. Put briefly, an API allows web programmers to query a given web resource in the background, serving up its results in a different form to the users of their own web applications.

A travelling website, for instance, may query both a weather service and an airline fares service when a user searches for information on a given location, in order to deliver all of these results (together with information from its own resources) on a single page. This practice is often known as a ‘mash-up.’

Some of the text and data repositories mentioned above already provide programmatic access to their resources through an API. It may be noted that, at the time of writing, there is a well-documented public API available for Google Books, but not for the Internet Text Archive.

If no API is available for a given resource, and it is unlikely it will be made available in the future, one may resort to querying the website through a general search API (provided by search engines such as Google or Bing). For instance, in order to present search results automatically collected from Wikipedia or another resource next to the Core documents of your editing project. More examples will be discussed in detail in the ‘Proofs of Concept’ section below.

If we would take the model one step further, it is possible to envision a future kind of digital editing projects, whose essential feature would be the combination of manually added markup and metadata with automatically extracted metadata. Imagine the wealth of information to describe your documents that would be available in a system that is both rigorously edited and automatically analyzed using:

• topic detection
• genre detection
• keyword extraction
• named entity recognition
• automatic translation of foreign terms
• automatic summarization
• automatic authorship attribution of disputed documents

All of these technologies (combined with the initially added markup) could lead to a very extensive method for profiling documents. If all of the metadata describing a document are fed into a document profile, these may be compared internally (e.g., for searching related texts in the Core) or used for external purposes (e.g., for use in a larger text profiling project, such as authorship attribution research). Document profiles could be employed to draw up a typical profile of the texts written by a certain author, or written in a certain genre.

Proofs of Concept

I would like to illustrate this model by means of two recent publishing projects in which I was involved. Both were small-scale scholarly editing projects collecting documents on Flemish theatre. The texts stem from various periods of the twentieth century. Access to both projects is provided through the website corpustoneelkritiek.org. (Although the source texts are mainly in Dutch, the interface is entirely in English.)

Corpus Toneelkritiek Interbellum (Flemish Theatre Reviews 1919-1939) is a collection of short documents on theatre, chiefly reviews and essays, from the inter-war period. It includes 686 documents which were marked up according to the TEI P5 Guidelines. Mainly semantic elements are used, such as , and , to indicate where a personal name, an organization’s name, or a title occurs. (CTI 2009)

For instance, in the following passage the <persName> element was used to encode different spellings of the Flemish director J.O. de Gruyter’s name. Using the @key attribute, these variant spellings all refer to a single entity (here abbreviated JODG) in a database of names. Furtherwise, all occurrences of personal names are typed using the @type attribute to specify the person’s main profession (such as writer, director, poet, composer, or philosopher).

De herinnering aan dr J.O. de Gruyter, die zich ook in Nederlandsche tooneelkringen grooten naam verwierf, blijft levendig. Telkens verschijnen er artikelen aan hem en zijn levenswerk gewijd. In dit najaar zal het licht zien, samengesteld door Emmanuel de Bom, een “De Gruyter-Boek”. Dit bevat bijdragen van verschillende specialiteiten en herinneringen van De Gruyters vrienden.

The corpus is made available online through the project’s website corpustoneelkritiek.org/cti. For this purpose, all XML source files were converted to static HTML using the XML parsing modules from the Python programming language. Additionally, a simple search engine was added, again written in Python and based on the search engine described in Toby Segaran’s book Programming Collective Intelligence (Segaran 2007).

However, the website does not merely present the text of the digitized documents. The manually added metadata, encoded in the markup, is processed during the generation of the HTML files in order to enrich the visualization of the documents with meta-information. Most importantly, document metadata was collected in document profiles, which were then mutually compared to determine internal links. This was again done by parsing and analyzing the content of the XML files using Python.

Document Profiles

A document profile contains the author of the text, its year of publication, its month of publication, and the full list of personal names, organization names, and titles mentioned. Additionally, terms that are supposed to characterize the document are added using automatic text analysis. After reading each file’s textual contents, highly frequent function words are removed by comparing the text with a dictionary of Dutch stop words. Any single word (or ‘unigram’) that occurs four times or more in the remaining text is considered to be ‘characteristic’ for this document and added to the profile. Any combination of two words (or ‘bigram’) that occurs two times or more is also added.

I should immediately add that this a quite rudimentary method for computing document keywords. More sophisticated methods, such as TF-IDF, will be discussed in the second case study. However, the method was sufficiently effective for the purpose of this corpus, since most texts are of equal length (on average 1120 words). Hence, it was possible to establish an absolute threshold for both unigram and bigram frequency (resp. four and two occurrences).

With the document profiles for each corpus text at hand, documents may be compared in order to detect relations. In this case, two documents were considered to be ‘related’ if more than half of their document profiles overlapped. This overlap was further normalized by taking into account the length of the document profiles, so that exceptionally long texts would not be prioritized because of their higher number of keywords.

On the project website, ten possibly related texts are suggested to the user who is consulting a corpus document. The interface specifies on which overlapping elements the suggestion is based, e.g., if a text is considered to be related because there is a thematic relation, or because it was written by the same author, or in the same period. Furthermore, a sidebar next to the text lists all personal names, organizations (e.g., theatre companies), locations (e.g., playhouses), and titles that have been marked up in that specific document.

Advanced Search

So far, the extra information that the web interface added to the visualization of TEI-encoded documents was strictly derived from the corpus itself. Next, I will discuss an example of how this may be connected to external text and data repositories.

All names and organizations presented in the sidebar of documents on the CTI website are clickable. These hyperlinks point to an ‘advanced search’ function that queries multiple resources for quotations mentioning that specific name. When an item from the sidebar is clicked, an ‘advanced search’ launches that collects quotations on that item from:

1. the corpus itself
2. Google Books
3. the Dutch version of Wikipedia (nl.wikipedia.org)
4. the Digital Library of Dutch Language and Literature (dbnl.org, the largest online collection of scholarly editions of Dutch books)

While the rest of the website consists of static HTML files derived from the XML source files, the advanced search functionality depends on Python web programming. Queries generated from the list of names in the sidebar are sent to the Google Book Search API, to collect titles and extracts from books mentioning the query, and to the Yahoo Web Search API, to collect pages from the Dutch Wikipedia and from DBNL. The APIs generally return their results as RSS feeds, i.e., using the XML protocol, which can be conveniently parsed in Python using XML parsing modules, or Mark Pilgrim’s Universal Feed Parser (feedparser.org).

The final result is a remarkably efficient ‘research engine.’ During an advanced search query, information is harvested from so many sources that the page starts to function as an ‘improvised encyclopedia.’ Because both the page’s information as well as the presumed user’s background and interests are quite narrowly circumscribed, search results are almost always relevant. The suggestions of related texts, on the other hand, serve as an easy tool to browse the collection (instead of the inherently meaningless search box that is offered on the landing page of many web resources).

Named Entity Detection

A different plan was followed for the construction of Pieter T’Jonck Theatre and Dance Reviews, a research website collecting 1455 reviews by Belgian critic Pieter T’Jonck (from 1985 up to the present). For this project, the collection of documents was too large for the editorial team to mark-up manually. Only basic metadata were added manually by the editors, such as the publication platform, date of publication, and the performance under review.

In order to enrich the available metadata for each document, the reviews were analyzed by an automatic linguistic parser to extract all named entities. For this purpose, a Dutch-language version of MBSP (Memory-Based Shallow Parser) was used. MBSP was developed at the universities of Tilburg and Antwerp (clips.ua.ac.be/pages/MBSP) and automatically applies various levels of linguistic annotation.

On the project website, the named entities extracted by MBSP are presented to users consulting a document, together with the manually added metadata such as the date of publication and the performance reviewed in that document. Again, these metadata serve as the basis for new queries using an advanced search functionality analogous to that described above.

Closing Remarks

The case studies discussed in the previous section may hopefully throw sufficient light on the possibilities of the hybrid model that I have introduced in this essay. It must be added that the case studies only touch the tip of the iceberg. For instance, although external resources are queried to enrich the research experience of the user, these queries do not contain any ‘semantic’ information.

For instance, the advanced search functionality does not query Wikipedia for persons corresponding to a certain name, but merely for Wikipedia pages mentioning that name. More sophisticated systems that use semantic web technology (such as the Linked Data initative) go far beyond these restrictions and provide much more controlled searching. On the other hand, semantic descriptors are only available for a handful of resources. Using publicly available APIs and repositories (such as Wikipedia) has the advantage of searching the widest possible array of sources.

I would like to conclude with a statement by Daniel J. Cohen from a discussion on ‘the promise of digital history,’ published in the September 2008 issue of the Journal of American History:

Digital history and the abundance it tries to address make many historical arguments seem anecdotal rather than comprehensive. Hypotheses based on a limited number of examples, as many dissertations and books still are, seem flimsier when you can scan millions of books at Google to find counterexamples. (Cohen et al. 2008)

Although I fully agree with Cohen that digital repositories open up new vistas of research which require new methodological training for many humanities scholars, the hidden question that remains unanswered is how we will cope with the challenges of digital abundance. It is not only more and more vast repositories that will be needed, but also the adequate tools and interfaces to query, browse, and interconnect the information they hold.

List of Works Cited

Cohen, Daniel J., Michael Frisch, Patrick Gallagher, Steven Mintz, Kristen Sword, Amy Murrell Taylor, William G. Thomas III and William J. Turkel. 2008. “Interchange: The Promise of Digital History.” Journal of American History 95.2. http://www.journalofamericanhistory.org/issues/952/interchange/index.html

CTI. 2009. Corpus Toneelkritiek Interbellum. http://www.corpustoneelkritiek.org/cti

Dyson, George. 2005. “Turing’s Cathedral: A visit to Google on the occasion of the 60th anniversary of John von Neumann’s proposal for a digital computer.” Edge: The Third Culture. October 24. http://www.edge.org/3rd_culture/dyson05/dyson05_index.html

Google Books. 2010. “History of Google Books.” Accessed August 25. http://books.google.com/intl/en/googlebooks/history.html

Nunberg, Geoff. 2009. “Google Books: A Metadata Train Wreck.” Language Log. August 29. http://languagelog.ldc.upenn.edu/nll/?p=1701.

Segaran, Toby. 2007. Programming Collective Intelligence: Building Smart Web 2.0 Applications. Sebastopol, CA: O’Reilly.

TEI Consortium. 2007. TEI P5: Guidelines for Electronic Text Encoding and Interchange. Last updated July 6, 2010.

Wikipedia. 2010. “Google Books.” Accessed August 25. http://en.wikipedia.org/wiki/Google_Books

(And the other conditions of its production: publishing house, printing quality …)

Nowadays, a huge amount of ‘text’ is indeed, as Teresa Fishman of Clemson University rightly remarks, “hanging out there.”

Now we have a whole generation of students who’ve grown up with information that just seems to be hanging out there in cyberspace and doesn’t seem to have an author (…) It’s possible to believe this information is just out there for anyone to take.

It’s an incredible change of mind, and it is happening as we write.

According to the organizers,

A Day in the Life of the Digital Humanities (Day of DH) is a community publication project that will bring together digital humanists from around the world to document what they do on one day, March 18th. The goal of the project is to create a web site that weaves together the journals of the participants into a picture that answers the question, “Just what do computing humanists really do?” Participants will document their day through photographs and commentary in a blog-like journal. The collection of these journals with links, tags, and comments will make up the final work which will be published online.

I think it’s a wonderful project — not merely for promoting the digital humanities, but also to gain insight in the working methods & daily routines of fellow scholars & teachers. I expect to learn a lot today, and in the following week, when we’re expected to comment on the others’ posts & link to them.

So, if you’d like to eavesdrop on my personal activities, fly to http://ra.tapor.ualberta.ca/~dayofdh2010/thomascrombez/

More particularly, Turkel showed how you may train an automatic classifying program (known as a “Naive Bayes Classifier” for mathematical reasons) to identify the type of crime based solely on the transcript of the court session.

Image via Wikipedia

In the conclusion of his series, Turkel sums up various reasons why machine learning can prove a valuable tool for historical research. The real eye-opener for me was when he demonstrated the advantages of scrutinizing the errors turned up by a not-so-well performing classifier. In the example of the Old Bailey, Turkel trained a classifier to identify cases of assault amongst nineteenth-century court records. The accuracy of the classifier is not particularly good, but neither is this the prime interest. It gets interesting when you study the cases falsely identified by the classifier as belonging to the assault category. One example is particularly revealing for the kind of “fuzzy” searching that machine learning may lead to:

In other words, about 96% of the learner’s false positive “errors” in this case were other kinds of assault. What of the trials classified as “miscellaneous – other”? One was this trial, where 44 year old William Blackburn was found guilty of “unlawfully and maliciously administering to Hannah Mary Turner 6 drachms of tincture of cantharides, with intent to excite, &c.” I understand that this case probably doesn’t fit the definition of assault used by either Blackburn’s contemporaries or by the person who coded the file. Nevertheless, it is not completely unrelated to the idea of an assault, and is exactly the kind of source that a historian could use to shed light on gender relations, sexuality, or other topics.

In the concluding post, Turkel sums up the advantages of automatic classifiers for research into large digitized collections. Learning from false positives proves particularly important, “giving you a way of finding interesting things just beyond the boundaries of your categories.”

For a long time I had wanted to move beyond digitizing and making available online the corpora that interest me (such as Corpus Toneelkritiek Interbellum), and to start exploring computational tools such as machine learning. Recently, just such an occasion turned up when PhD student Dries Lyna asked me for some tools to analyze the ca. 5000 auction lots he digitized from catalogues of auctions in eighteenth-century Antwerp and Brussels. More particularly, Dries is interested in the evolving literary style of these catalogues. His starting point is the distinct impression amongst art historians of this period that

during the second half of the eighteenth century paintings’ descriptions in catalogues in general became longer, more detailed and increasingly precise (…). Not surprisingly, longer accounts were accompanied by a growing richness of vocabulary and often more florid use of language.

Using the digitized records from more than forty catalogues, we were able to show how the art vocabulary actually evolved during the second half of the eighteenth century. Not only did the vocabulary richness greatly increase, but discourse also became much more specific. In the 1840s the generic term tableau (painting) is used almost indiscriminately, while the next decade sees a decrease in the use of this word and an increase in more specialized terms such as paysage (landscape) and portrait.

We were both quite excited about these results. But Dries also wanted to know if there was a correlation between the style of the descriptions and the price the paintings eventually fetched during the auction. In other words, was the evolving language also a performative tool in the rapidly maturing late-modern marketplace for artworks?

More on that soon……

Related articles by Zemanta

• Machine Learning in One Sentence (smellthedata.com)
• Link-based document classification using Bayesian Networks (slideshare.net)

Image via Wikipedia

His first criticism concerns the limitations of HTML, which de facto becomes the “target for all indexing and searching” in my approach, negating some of the intricacies of your TEI markup.

One disadvantage of this approach, however, is that the html transformation becomes the target for all indexing and searching, and since that transformation is intrinsically lossy you give up a lot. If  the goal is to display a site for reading and global searches, this does not matter. But if you had, say, an archive of several hundred plays from Shakespeare’s day and wanted to have your students look for differences in lexical uses by verse or prose, you’d be stuck.

The second point is about the relevancy of my central problem — escaping the burdens of hosting. Here, he compares it to a much more luxurious situation at other research institutes:

I appreciate the advantages of Google Sites in terms of getting you out of the business of babysitting your web server. But at my university and generally at American research universities that is not really where the shoe pinches.  At my university we are moving very rapidly into virtual server environments of one kind or another. If I think of myself as the owner/editor of a project, I’m likely to get help from my Academic Technologies group with getting some application environment installed, maintained, and updated if it runs on a standard platform. For instance, if I had an eXist or a Django/Berkeley implementation, I could count on its being installed and maintained on a Linux server. But I’d be largely on my own with regard to everything that happens ‘inside’ my application. And that would be OK provided there is adequate documentation for how to work with TEI documents. I look forward to Lou Burnard’s Demonstrator.

On the first point, Mueller is absolutely right. Converting to HTML eliminates a lot of the editorial complexity that may have been the central impetus in starting a TEI editing project in the first place.

However, this is not precisely where the charm of the Google Sites solution lies — that is nothing but speed & simplicity. Here we touch on the second point. I can perfectly imagine projects like my own that are small-scale and do not have grand IT facilities at hand. In my case, as in the case of other projects I’m acquainted with, I’m basically my own IT guy.

And that’s where the convenience of Google Sites steps in. Suppose you have recently started a relatively small editing project — not small in terms of documents or richness of markup, but small in funding. You figure that there will probably be some funding opportunities further on the road ahead, so it could turn into a conventional book publication or into a full-blown, rich web app for doing research on those documents. But for the moment, they have not materialized. Yet you do want to have a preliminary publication, for advertising your work in the scholarly community or just making the edition searchable for students and colleagues. In this case, Google Sites will do a great job.

In this usage scenario, it does not matter very much that some of your markup richness gets lost in the transformation process to HTML, nor that the search engine is basically just a Google box. What counts is that your research gets visible, on a platform that is swiftly deployed and at zero maintenance cost.

Related articles by Zemanta

• Google Sites Become Prettier With Templates (techcrunch.com)
• How To Import & Export Google Sites Data? (techie-buzz.com)

When a discussion on a difficult paper is in full swing, it really helps to follow the conversation when two or three more knowledgeable people are simultaneously sending the key phrases through the air on Twitter.

The real-time magic works even more beautifully when a nice conference you could not afford to visit is streamed live to your living room through tweets. It first happened to me the other day, when a grad conference with the magnificent title The Past’s Digital Presence took place at Yale. I did not attend any of the talks in person (nor am I well acquainted with the speakers) but simply by tuning in to the conference’s hash tag #pdp2010, I could get the gist of the talks — and pick up some nice one-liners on Digital History in the process. More on those below.

I guess following a conference through Twitter might be compared to attending a sports game through the radio.

Radio and tv reporters have long realized that the medium is the message, and that their reporting, imperfectly though it may represent the event, also adds a significant dimension. The speaker’s intonation and the many many background stories (on cyclists, I have a terrible love/hate relationship to Michel Wuyts, who can tell you off the top of his head what color of underwear was worn by any biker at any major racing event) — they all add tons of drama, narrative, and heroics to the game.

So, what does the Twitter medium add to the game of conferencing?

Well, first: the medium is the massage, too. I happen to pick up Northern American daytime tweets at about 8pm, happily enjoying the comforts of a reclined seat & some good Belgian Trappist beer. I don’t know why, but it sure helps me digest academic conferences better.

Seriously, even if Twitter undoubtedly subtracts an awful lot from the live event, it also adds something. That something must be semantic, I would guess. In a way, Twitter may be considered an “auto-summarization service” for academic conferences, and that is surely because the tweets are very high-quality.

Speaking of high-quality tweets, let’s move over to the actual subject of this post.

Some tweets on #pdp2010 caught my attention, because they succinctly expressed some of the crucial questions in Digital Humanities today.

(On the subject of an Ivy League university such as Yale hosting a digital humanities conference, there’s been ample discussion on the Humanist mailing list. It all started out with this fascinating post by Willard McCarty.)

I’m not sure whose statements these are, or who twittered them, but I’ll just quote them as I received them — anonymous infobits, whose main reason of existence is to be re-tweeted. (Are tweets the materialization, at last, of Dawkins’ ill-famed memes?)

We haven’t yet dealt with the issues of reliability and bias (as historians) of digital primary sources. #pdp2010

Digital resources (humanities in particular) are often “link graveyards,” growing collections of broken interfaces #pdp2010

Important comment from a digital librarian-descriptive metadata is key. Scanned images are not the entirety of the situation

We have got to talk to our users more – there’s no excuse for scholars not knowing about the existence of descriptive metadata #pdp2010

All of these statements could be the starting point for interesting discussions. However, for now I’d like to leave them in the air for a moment (just as they kept floating around my head for a few days) and focus instead on one comment that is particularly dear to me. Apparently it came from a talk by April Merleaux:

Merleaux: If u don’t program, your work will always be at the mercy of those who do

I believe that is quite true, and it’s also the main reason why I started investing so much time in learning new technical skills (back in 2008, when I wanted to set up my first online digital document collection). If you do not grasp some core concepts from information science, web programming, or state-of-the-art natural language processing (as it is used by search companies whose interfaces we use daily), you will never fully understand what possibilities digital tools may hold for your own research.

There’s a variety of different opinions on this subject, however. Recently, on the TEI mailing list, Martin Holmes commented (this is from a discussion on eXist, a tool for indexing XML source files):

It’s fair to say that to use eXist effectively, you have to learn quite a lot. Our researchers (faculty, RAs, etc.) never have anything to do with it. We (the technical support) set up eXist, write the XQuery and all the other web application logic, and so on. (…)

So I think people like you need people like me, and vice versa. Sometimes there are people who happily live in both camps — active faculty researchers who are also quite comfortable programming their own web applications — but these are few and far between. But that’s one of the things that makes digital humanities an inspiring enterprise: it’s almost always more collaborative than traditional humanities research.

Holmes is certainly right, only he is advocating one ‘role model’ of digital humanities — that of collaboration between technically skilled programmers & academically skilled scholars. Only, these kind of collaborations always need some time to grow and (more importantly) a well-funded research framework to take place in.

I don’t have the resources for such a framework, and I do not feel like spending the next few years of my academic life obtaining the funds for them. But I do want to do research in digital humanities.

That’s why I prefer the DIY attitude that (I believe) Merleaux represents. It’s tempting (because it feels flattering) to identify with Holmes’ rare individuals — “active faculty researchers who are also quite comfortable programming their own web applications” — but actually our predicament is a little less comfortable. We have to keep up with our ‘traditional’ specializations in the humanities-at-large, and program ourselves.

The medium, then, not merely is the message, no longer is the massage — the medium is the bricolage.

Some endnotes:

• Podcasts from the talks at PDP 2010 may be found at Jana Remy’s blog (who was also one of the excellent & magnanimous twitterers for PDP, thanxalot!) makinghistorypodcast.com

• Douglas Knox commented on the Humanist mailing list:

Date: Wed, 3 Mar 2010 08:45:51 -0600
From: Douglas Knox

What I thought I glimpsed between the tweets about PDP2010 was nascent home-grown theory arising out of methodological reflection within historically oriented disciplines. Digital challenges to presumptions about research, evidence, analysis, communication, and audience certainly call for this reflection throughout the humanities, not just in humanities departments but in libraries, archives, museums, and publishing enterprises driven by an intellectual mission. The grad students who came together for PDP recognize the necessity of thinking about, and historicizing, the role of libraries, archives, their own collecting and publishing, and, not least, the dark matter of missing information, in the production of knowledge about the past.

Related articles by Zemanta

• How to Hack A Conference (AKA Attend One Productively) (profhacker.com)
• Resources for journalists using Twitter (stevebuttry.wordpress.com)
• Introducing Digital Humanities Now (dancohen.org)

In my earlier publishing projects (e.g., the SARMA project for collecting dance & theatre reviews by Pieter T’Jonck) there seemed to be no other option but to master the power overcome the restrictions of HTML and CSS, throw a website together, add a search engine, and host the whole bunch on your own webserver or your university’s or a hosting company’s. That means lots of work, and between three and five new areas of expertise you need to explore if you’re coming from a traditional humanities background, as I do (I studied Philosophy and Theatre Studies, and those are still the main subjects of my teaching assignments).

That’s how I got into maintaining my own webserver, and although it’s certainly been a rich and rewarding process (insert your favorite funny accent to pronounce these words) it is getting on my nerves, too.

Still, other systems seemed like either still more work to do (such as learning the ropes of a Content Management System) or too limited in possibilities. That how I first thought of Google Sites (or similar systems).

What changed my mind was the release of the Google Data API for Google Sites in September 2009. That’s quite a mouthful. The Data API is Google’s backdoor for programmers. Using the “Application Programming Interface,” you may automate the sending of emails through GMail, automatically update events in Google Calendar, upload movies to YouTube, request maps from Google Maps etc. etc. Basically, anything you can do through one of Google’s services by mouseclicks, you can automate through the Data API. Moreover, there’s not only an API client for serious Java people, but also one for the queen of playful code — Python!

It’s a godsend, and I love every inch of it.

(Well, except for that little one stupid inch that makes it impossible to publish the PDF files in your Google Docs account automatically, but more on that in a future post.)

Using the Google Data API, you can automatically post HTML-formatted documents to a Google-hosted website, where they are instantly made available online and fully indexed for site searching.

Read that sentence again. It’s crazy, if only because of this: although there is an upper limit to the amount of stuff you can freely post on a Google Site, this limit only holds for page attachments. If it’s simple HTML pages you are posting, there is a no upper limit.

To give a concrete example: this is the workflow I followed for the current version of Belgium is Happening, an online register of post-war performance events.

1. Students collected information on performance events through research in books, journals, and archival records. They recorded this info in a gigantic spreadsheet on which they could work simultaneously (i.e., collaborative editing — I used Google Docs but there’s other systems, too). Each row of the spreadsheet holds one event, detailing its date, place, participants, and a short description.
2. A first script pulled in the data from the Google spreadsheet through the Google Data API for Google Docs. (If they put Google in the name of one more new service they devise, I’ll have them sued for artificially limiting the vocabulary richness of my blogposts.) Note that this step isn’t strictly necessary — the script could also read in the data from a local data file.
3. A second script formatted the event data as HTML, logged in to the Google Sites API (using my normal Google account details), selected the first event, created a new page on the Google Site for the project, posted the HTML to the new page, and then continued to do so for the next 1,399 events.

And that’s how I posted no less 1,400 separate pages on the site of Belgium is Happening, and made all of those events fully searchable at the same time. Running not on my server, not on my time, but on Google’s servers — i.e., much more efficiently than I could ever aspire to do. Check out a sample of events here: belgiumishappening/home/events

(To be perfectly honest, what you see there is already a bit of a hack — I really wanted to offer visitors a random selection of events, which is impossible in the current setup of Google Sites. You can present an overview of subpages, but since all my events are under one ‘parent’ page, this list would be very large and unwieldy. So I cheated a bit, more on this later….)

I first wanted to share the Python scripts I used at the end of this post, but they’re really too much tailor-made for my project to be informative for others. However, I strongly suggest reading the code for the sample applications that is provided with the gdata Python client — all the basics are there.

Related articles by Zemanta

• Data Liberation Front Advances to Google Sites (dataliberation.blogspot.com)
• Using Google Interactive Maps On Your Website (pelland.com)
• How To Import & Export Google Sites Data? (techie-buzz.com)

Or, as in my case, you have collected data on a humungous amount of performance events from twentieth-century theatre, letting various groups of students work together using a Google Spreadsheet. (A project going by the name of Belgium is Happening, more on this below & in upcoming posts.)

It goes without saying that for the editing phase of those projects the Text Encoding Initiative has been a tremendous boon.

But how about publishing your results? For some projects, ‘going print’ is no longer a viable option. The materials you have collected may simply be too large or cumbersome for print. Besides, a scholarly publication (at least in my experience) takes at least half so much time for negotiations with publishers, going through another editorial process, &c., as the edition itself took to complete.

So, you want to do an online scholarly publishing project.

When I started out my first project in the summer of 2008 — the Corpus Toneelkritiek Interbellum, a corpus of Dutch theatre reviews from the interwar period — the natural choice for publishing my TEI files online seemed to be the formatting language XSLT. As a TEI beginner, it was the evident way to go, as it is used in many projects for the presentation of an edition.

XSLT is basically a powerful formatting language (and, in some ways, also a rudimentary programming language) that tells the web browser how to sort, lay-out, and present the intricacies of your XML edition for the benefit of the illiterate masses out there who prefer to do their reading without angle brackets or namespace declarations.

XSLT has the distinct advantage of a ridiculously simple publishing model. If you simply connect a stylesheet to an XML document on your web server, the browser will pick up both, and render your XML documents accordingly. At least, that’s what supposed to happen after you managed to write or customize your own XSLT stylesheet.

For the sake of clarity, I did not reach that stage of my initiation.

As it happened, I was also picking up some basic Python scripting skills at the time. And what I saw in Python — delicious pseudo-code featuring non-offending commands such as file.open() — looked quite different from the verbose and swollen style of your average XSLT stylesheet.

I decided to convert my source files into run-of-the-mill HTML using Python’s quite powerful XML parsing capabilities. And then publish them, first as static files on a general-purpose server at our university, later on as part of a dynamic (and again Python-driven) website on my own web server.

However, there are certain distinct disadvantages & upper limits to these approaches. Either way — running your website on a university server, a private hosting solution, or your own server — you are basically into self-publishing. Will you use an established platform aka CMS (Content Management System, e.g., WordPress or Drupal) or do you prefer to grow your own HTML/CSS? What is the most advantageous and flexible place to host it? If you run your own server, when does it need to be updated? Do you really need that latest Apache update? If you are doing a dynamic website, will the database continue to behave as it does today? When to update your database software? Is it possible that your website will one day attract a lot of traffic, necessitating more than one server? What search engine do you use for your collection of texts? Do you simply plug in a Google search box, or do you want some more searching power for your users? If so, what software do you choose?

Ah, the joys of server maintenance.

While looking for alternative models of publishing online, I stumbled upon Google Sites. It is part of the Google Apps suite that is marketed to companies, schools, and groups. Using Google Sites, you design a basic website and populate it with content. Plus, every page you add is automatically indexed for powerful and lightning-fast site searching.

At first, that was exactly how I used it. It was a good choice for course background materials & wikis — i.e., as a high-tech replacement for the idiotic constraints of your average Blackboard installation.

But then I realised the full potential of the feature allowing you the edit the HTML contents of any page. If you would simply convert your scholarly project’s source files to HTML (using any of the above-mentioned methods) and insert them into a Google Site, it could grow to be the ideal publication platform for your project:

Image via Wikipedia

• Styling is applied automatically to your text. No more fiddling about with CSS stylesheets, just choose a general theme for your site, insert the HTML, and you’re done. If you want to apply additional styling, you can use the WYSIWYG editor or the HTML editor that accepts in-line CSS styling, too.
• Your project is running on Google’s servers. They are doing the maintenance, and since they’re the world’s largest data farm, it should remain accessible even when under heavy load. (The Google approach to hosting is dealt with from a different perspective in a Campfire One video on Google App Engine)
• Your project’s texts are immediately indexed and fully searchable. Anyone who has dipped into the difficulties of configuring your own search engine (certainly when coming from a non-IT background) should be happy about this.
• If you decide to make your website public, it seems quite reasonable to expect that its contents are also swiftly added to the main Google search index, so your editing efforts may become more visible.

The only point is … how are you going to upload those [refer to crazy number 1] of HTML documents to your Google Site?
More on that soon, in an upcoming post.

However, for most beginning students, the obvious sources to scavenge are simply found through Google. They do not bother with scholarly databases or real books anyway. So what better way to detect their scams than Google itself?

As it stands, the collective intelligence a.k.a. Wikipedia has a not so positive opinion on plagiarism detection through search engines:

Although it can easily detect blatant cases, it is less effective when the plagiarizer has mixed multiple small fragments from different sources, and will not return any relevant results if the search engine has not indexed the original source or sources. Also, considerable effort is required to investigate each suspected case.

Still, I had the feeling I could make search engine-powered plagiarism detection work, even if it was only to help out with my own grading duties. There’s some terrific Web search APIs available right now. (An API or Application Programming Interface is like a ‘back door’ for programmers to query a web application’s data and programs — not through a user interface (such as a website) but through a programming interface, i.e., enabling automated queries. There’s a great tutorial to APIs available from ProfHacker.)

Web search APIs make it quite easy for a beginning programmer to do some automated googling. I particularly like Yahoo Web Search, or the Google AJAX Search API.

Image via Wikipedia

Here’s what I concocted with my basic Python scripting skills. (Full details on the script at the end of this post)

My DIY plagiarism detector takes a simple text file as input, then automatically strips punctuation, and divides the text into ngrams. Simply put, an ngram is any sequence of n words you can extract from a given sentence. So for “My name is Mark” the bigrams would be
“My name” — “name is” — “is Mark”
and the trigrams would be
“My name is” — “name is Mark”

Next, the script sends each of these “sentence chunks” to a search engine, and asks for hits that correspond to a phrase search, or a verbatim search of that exact sequence of words. Given that punctuation has been stripped, and the search engine itself disregards capitals, any available website containing that same word sequence (including the vast repository of Google Books, for instance) will be retrieved.

If my plagiarism detector finds many consequent hits, it’s a clear sign that the student has either quoted that passage, or has been engaging in some questionable copy-paste writing. I usually run the script at the same time I am “manually” reading and grading the paper, to see if any stolen goods turn up.

Some observations on my recent grading experiences.

• Eight or nine consecutive words seems like a good window for detecting plagiarism. It means you won’t be scoring too many false positives, i.e., hits for sequences of words which are just frequent turns of phrase instead of illegitimate copy/paste.
• Many students ‘plagiarize’ to a certain degree. Even the good ones. They may not copy whole paragraphs from the net, but they do snatch an occasional phrase. Is writing slowly turning into “montage”?
• The Wikipedia criticism that search engines are less effective “if the search engine has not indexed the original source or sources” has become quite obsolete, if only for the increasing number of print sources indexed through Google Book Search or similar mass digitization projects.
• The Wikipedia criticism that the search engine method “is less effective when the plagiarizer has mixed multiple small fragments from different sources” still holds very much true. Some students take an inspiring chunk of text and start ‘remixing’ it in a way that is very close to plagiarism, yet is more contrived than simple copy-pasting. I find it hard to judge them harshly, since some of them are obviously unaware that what they’re doing is fraudulent.
• A critical attitude toward all sources, be they written, oral, or digital, is undoubtedly one of the most important virtues an academic education should convey today.

Now, for those who want the full gory details of the script, read on …

The script is written in Python and details a number of functions that are combined in a final function GPlagFile() for sending a whole file to Google for plagiarism detection. Some of the functions were snatched from the magnificent introduction to using Python in the humanities that William J. Turkel and Alan MacEachern wrote (The Programming Historian). You can find the script here.

(Please note that you will have to download one additional Python module — namely simplejson — and that you may have to replace www.example.com with a website of your own to identify yourself to the Google API.)

Since 2008, my research in theatre history has increasingly focused on doing “digital history”.

What does it mean to have a digital corpus of source texts at our disposal, instead of a traditional library or archive? How can we apply techniques from rapidly advancing fields such as artificial intelligence, Natural Language Processing, and computational linguistics to such ‘traditional’ disciplines as literature and the arts?

My current projects are focused on how to make a large collection of source documents accessible through “research websites,” as I call it for lack of a better term. Examples include Corpus Toneelkritiek Interbellum, a collection of Flemish theatre reviews from the interwar period, and the collected reviews of dance and theatre critic Pieter T’Jonck from 1983 to 2008. (All documents are in Dutch, but the interface and background documents are in English.)