The Role of Technology in Scholarly Editing

1,411 views

Published on

Presentation delivered at TEI Members' Meeting 2011 in Würzburg, Philology in the Digital Age

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,411
On SlideShare
0
From Embeds
0
Number of Embeds
663
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

The Role of Technology in Scholarly Editing

  1. 1. The Role of Technology in Scholarly Editing<br />Elena Pierazzo<br />1<br />
  2. 2. Two main contrasting approaches <br />Editor as encoder (and programmer, web designer…)<br />2<br />
  3. 3. Or..<br />The magic box<br />3<br />
  4. 4. “the theology of the pointy bracket” (Prescott 2011)<br />Encoding is interpretation<br />Encoding is a way to make explicit our understanding about/of a text<br />Encoding is way to represent research scholarship<br />Editing = Encoding<br />Encoding = Editing<br />XML is only one of the many ways for encoding: editors encode even when using Word<br />4<br />
  5. 5. Tim McLouglin 2010<br />Difficulties of the editor as encoder<br />Learning XML<br />Learning the TEI<br />Editors can add new elements to the encoding: editor as standard developer<br />Editors need to learn/follow someone else’s taxonomy<br />Time!! Encoding a supplied reading takes much longer than adding […]<br />5<br />
  6. 6. How “distracting” is the use of TEI?<br />Editors have to control their text, the witnesses, the paleography, the codicology and the validation of XML, and the overlapping, and the values of attributes, and the IDs, the cross-references and the consistency…<br />It is distracting…<br />6<br />
  7. 7. What every editor must know<br />Textual scholarship<br />Codicology<br />Palaeography<br />Historical linguistics<br />History<br />Literature<br />XML<br />TEI<br />XSLT<br />HTML<br />CSS<br />Web design<br />Ontologies<br />Databases<br />7<br />
  8. 8. Really?<br />8<br />
  9. 9. The ugly truth<br />Encoding TEI as a way of editing is not everybody’s piece of cake…<br />Encoding TEI is not necessarily the only way to edit<br />… and as a matter of fact most editors don’t use TEI<br />9<br />
  10. 10. Division of Labor <br />Editor/Encoder<br />Encoder/Programmer<br />Programmer/ Web designer<br />Web designer/ Graphic designer<br />10<br />
  11. 11. When Encoder ≠ Editor then…<br />Time consuming<br />Room for mistakes<br />Very expensive<br />Examples: Jane Austen’s Fiction Manuscripts, The Correspondence of Puccini <br />11<br />
  12. 12. Collaborative work<br />Editing is collaborative! (Greetham 1995)<br />Well, not all of it…<br />With support of a DH centre it may be possible, but what if you can’t make use of them?<br />PhDs don’t have money and are lone business, most of the time<br />Is this the end of the lone editor? The end of producing new editors?<br />12<br />
  13. 13. The magic box<br />E) encouraging the development of third-party tools for TEI users<br />Development of Tools is one of the hottest topics in the TEI-L/TEI Community<br />13<br />
  14. 14. What’s in the magic box?<br />Intuitive editor<br />Imaging tool<br />Zooming, annotation, cropping, enhancing<br />Automatic sync, line detection <br />Concordances<br />Collation <br />Stemma<br />Output generator, output manipulator<br />…<br />14<br />
  15. 15. D.C. Parker (2000 LLC)<br />What are computers for in editing?<br />in collating witnesses<br />in being able to alter a base text without having to revise a complicated apparatus criticus; <br />in analysis of manuscript relationships<br />in the selection of the most significant witnesses; <br />in producing an edition; <br />in the area of collaboration; <br />they do away with the need to redo good work; <br />they make possible a wide range of presentations<br />15<br />
  16. 16. Problems<br />Computers as tools to do what the editor used to do with no epistemological value on the digital methodology<br />Many traditions, many disciplines have different approaches to editing. TEI can accommodate all of them (well almost). Can Tools?<br />16<br />
  17. 17. Is this realistic?<br />The extreme flexibility of TEI is the enemy of tool production<br />Compromises! <br />Are the required compromises acceptable from a scholarly point of view?<br />Is the price to pay to high?<br />17<br />
  18. 18. Two approaches<br />Top-down: a tool is developed to be useful for the community with no specific project in mind (the tool is the project)<br />Too generic to be useful? Too much work to customise it?<br />Bottom-up: A tool is developed for a project and then generalised for a larger audience<br />Too specific to bee useful? Too many implicit assumptions? <br />18<br />
  19. 19. Early English Law<br />Bottom-down approach<br />Magic box based on Django<br />Heavy / Idiosyncratic simplification of the possibilities offered by TEI = very hard to reuse<br />19<br />
  20. 20. The Third Way<br />The bricks model approach: single, sharable, combinable, interchangeable tools<br />Best practice from a computing point of view, but what about the scholarly/user-friendliness point of view? <br />Is the abstraction level implied by these tools the correct one from a scholarly point of view?<br />How much work/programming is required to tailor them for specific use? <br />20<br />
  21. 21. Too many tools that are “almost” good…<br />… but “almost good” is not good enough<br />A certain level of abstraction is required to develop universal tools<br />Is there a level of abstraction that allows development of tools that are actually good enough?<br />21<br />
  22. 22. Flexibility ≠ Out-of-the-Box<br />22<br />
  23. 23. Solutions?<br />I’m afraid, I don’t have them…<br />But WE might have them!<br />23<br />
  24. 24. Agreeing on which technology to use is not enough<br />Scholarly agreement is equally necessary<br />Many tables around which to sit and think<br />The latest: ESF NeDiMAH (Network for Digital Methods in the Arts and Humanities)<br />24<br />
  25. 25. Possible outcomes<br />Either we discover that we have to create our own tools for each new project…<br />…or we address these issues before going on with what we are doing<br />25<br />
  26. 26. Thank You<br />Elena Pierazzo<br />elena.pierazzo@kcl.ac.uk<br />26<br />

×