On the TEI mailing list, Martin Mueller recently raised some incisive comments on my previous posts detailing the process of publishing a scholarly editing project on Google Sites (see pt. 1 and pt. 2).
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)