the role of technology in scholarly editing

1

The Role of Technology in Scholarly Editing

Elena Pierazzo

2

Two main contrasting approaches

Editor as encoder (and programmer, web designer…)

3

Or..

The magic box

4

“the theology of the pointy bracket” (Prescott 2011)

• Encoding is interpretation• Encoding is a way to make explicit our

understanding about/of a text• Encoding is way to represent research

scholarship• Editing = Encoding• Encoding = Editing• XML is only one of the many ways for

encoding: editors encode even when using Word

5

Tim McLouglin 2010

Difficulties of the editor as encoder• Learning XML• Learning the TEI• Editors can add new elements to the

encoding: editor as standard developer• Editors need to learn/follow someone else’s

taxonomy• Time!! Encoding a supplied reading takes

much longer than adding […]

6

How “distracting” is the use of TEI?

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…

It is distracting…

7

What every editor must know

• Textual scholarship• Codicology• Palaeography• Historical linguistics• History• Literature

• XML• TEI• XSLT• HTML• CSS• Web design• Ontologies• Databases

8

Really?

9

The ugly truth

• Encoding TEI as a way of editing is not everybody’s piece of cake…

• Encoding TEI is not necessarily the only way to edit

… and as a matter of fact most editors don’t use TEI

10

Division of Labor

• Editor/Encoder• Encoder/Programmer• Programmer/

Web designer• Web designer/

Graphic designer

11

When Encoder ≠ Editor then…

• Time consuming• Room for mistakes• Very expensive• Examples: Jane Austen’s Fiction

Manuscripts, The Correspondence of Puccini

12

Collaborative work

• Editing is collaborative! (Greetham 1995)

• Well, not all of it…• With support of a DH centre it

may be possible, but what if you can’t make use of them?

• PhDs don’t have money and are lone business, most of the time

• Is this the end of the lone editor? The end of producing new editors?

13

The magic box

E) encouraging the development of third-party tools for TEI users

Development of Tools is one of the hottest topics in the TEI-L/TEI Community

14

What’s in the magic box?

– Intuitive editor– Imaging tool

• Zooming, annotation, cropping, enhancing

• Automatic sync, line detection – Concordances– Collation – Stemma– Output generator, output manipulator– …

15

D.C. Parker (2000 LLC)

What are computers for in editing?

1. in collating witnesses

2. in being able to alter a base text without having to revise a complicated apparatus criticus;

3. in analysis of manuscript relationships

4. in the selection of the most significant witnesses;

5. in producing an edition;

6. in the area of collaboration;

7. they do away with the need to redo good work;

8. they make possible a wide range of presentations

16

Problems

• Computers as tools to do what the editor used to do with no epistemological value on the digital methodology

• Many traditions, many disciplines have different approaches to editing. TEI can accommodate all of them (well almost). Can Tools?

17

Is this realistic?

• The extreme flexibility of TEI is the enemy of tool production

• Compromises!

• Are the required compromises acceptable from a scholarly point of view?

• Is the price to pay to high?

18

Two approaches

• Top-down: a tool is developed to be useful for the community with no specific project in mind (the tool is the project)– Too generic to be useful? Too much work to

customise it?

• Bottom-up: A tool is developed for a project and then generalised for a larger audience– Too specific to bee useful? Too many implicit

assumptions?

19

Early English Law

• Bottom-down approach• Magic box based on Django• Heavy / Idiosyncratic simplification of the

possibilities offered by TEI = very hard to reuse

20

The Third Way

• The bricks model approach: single, sharable, combinable, interchangeable tools

• Best practice from a computing point of view, but what about the scholarly/user-friendliness point of view?

• Is the abstraction level implied by these tools the correct one from a scholarly point of view?

• How much work/programming is required to tailor them for specific use?

21

Too many tools that are “almost” good…

… but “almost good” is not good enough• A certain level of abstraction is required to develop

universal tools

• Is there a level of abstraction that allows development of tools that are actually good enough?

22

Flexibility ≠ Out-of-the-Box

23

Solutions?

I’m afraid, I don’t have them…

But WE might have them!

24

• Agreeing on which technology to use is not enough

• Scholarly agreement is equally necessary• Many tables around which to sit and think• The latest: ESF NeDiMAH (Network for

Digital Methods in the Arts and Humanities)

25

Possible outcomes

Either we discover that we have to create our own tools for each new project…

…or we address these issues before going on with what we are doing

26

Thank You

Elena Pierazzo

elena.pierazzo@kcl.ac.uk