Describing Handwriting, Part I
A fundamental problem of the DigiPal project is how to describe handwriting in clear, unambiguous and (ideally) standardised ways. This question has been bothering palaeographers since the eighteenth century when Scipione Maffei criticised the terminology used by Jean Mabillon, and the Comité international de paléographie latine has been working on a list of standard terms since 1953 without success. With such a history behind it, this problem is probably well beyond anything the project team can achieve in four years, but it has become critical with the advent of digital resources and the DigiPal project, and so we need to provide a working proposal, however imperfect it may be. The reason for this is simple: how can you find what you are looking for on our website if you don't know what we called it?
The issue was raised at the recent European Science Foundation Workshop for Digital Palaeography at Würzburg, as a result of which I agreed to lead a small working group to address this in more detail. The working group is not yet formed, but this blog post is the first in a series that will begin to lay out some of the issues and begin proposing one possible solution. The discussion, at least initially, will be how to model letters and other aspects of medieval script in a computer so that we can describe and search for them effectively. [Edit, 25 August 2011: The discussion in this post focuses on describing script, that is, the ideal model of writing 'in the mind's eye' (to quote Parkes). Part III of this thread applies this to the description of scribal hands, namely what the scribe writes on the page.]
Problems and Principles
Leaving aside for now the problem of terminology, there is still the issue of how to describe parts of different letters. It seems to me that there are two main approaches which for now I will call 'morphological' and 'style-based'.
The 'morphological' approach tries to describe the letter as a whole, so 'Caroline a', or 'insular r', for example. Aspects of this approach are visible in almost all palaeographical handbooks, particularly those that provide alphabets or selections of letter-forms. An example is Albert Derolez's Palaeography of Gothic Manuscript Books who also provides a useful discussion of morphology as a palaeographical method. This approach allows a typology which is straightforwardly hierarchical: for example, one can start with 'Letter', then proceed to 'g', then perhaps 'insular g', then perhaps 'insular g, closed tail'. This, or something very like it, seems to underly the ManCASS C11 Palaeographic Catalogue.
The second approach I have called 'style-based', by which I mean focussing on the overall aspect and on components of the writing which might be common to any number of letters. Examples might be 'wedged ascenders', 'angled minim feet' or 'flat pen'. Once again this could be presented hierarchically but less obviously so.
In practice, neither approach is sufficient in itself: as palaeographers, we want to search both for letter shapes and for details of style. This mixed approach is used by some font identification programs such as Identifont. However, the two systems do not form a single neat hierarchy. This simple point alone has an important consequence: that a conventional XML structure such as TEI is probably not appropriate. Instead I think a richer model is required.
Towards a Model of Script and Letterforms?
If a hierarchical structure is not likely to work then what is? It seems to me that an alternative model might be one that includes three categories of entities and a set of relationships between them. These can then be used to build up rules about what letters must and can look like in any given script, and the computer can then use these rules to search for letters or even make inferences about a script or scribal hand. Let me explain.
- The first category of entities is the grapheme: the letter as an abstract entity, such as a, æ, or a single mark of punctuation. [Edit, 17 October 2011: I now realise that Grapheme is incorrect in this context and prefer 'character'. See the discussion under 'Terminology (again)' in Part IV of this series.]
- The second category is the allograph, namely a particular way of writing the letter such as 'Caroline a' or 'Insular r'. This corresponds approximately to the 'morphology' level described above.
- The third category is the component: that is, the basic parts which make up letters, such as minims, serifs, ascenders, and so on. This corresponds somewhat with the 'style' level described above.
- The relationships then connect these parts.
At this point, I envisage five relationships to describe possible graphemes and allographs:
- MUST_HAVE
- MAY_HAVE
- MUST_IMPLY
- NORMALLY_IMPLIES
- EXCLUDES
[Edit, 25 August 2011: Note that we also need a relationship to connect graphs to allographs: ALLOGRAPH_OF or similar. I later decided that features also need to be entities, and added some further entities and relationships. See now Part III of this series.]
Some example relationships are then:
- GRAPHEME.h MUST_HAVE COMPONENT.ascender: All letter hs must have ascenders, otherwise they are not an h but an n.
- GRAPHEME.h MAY_HAVE COMPONENT.wedge: The ascender on the letter h may have a wedge but does not have to.
- COMPONENT.wedge EXCLUDES COMPONENT.attack-stroke: If a graph (i.e. a single instance) of a given letter has a wedge on its ascender then that same graph cannot also have an attack-stroke on its ascender. Note, however, that there may be wedges on some letters and attack-strokes on others, or wedges on ascenders but attack-strokes on minims.
- ALLOGRAPH.teardrop-shaped-a MUST_IMPLY ALLOGRAPH.insular-a. 'Teardrop-shaped' a is a type of Insular a; therefore, if a scribe writes teardrop-shaped a, by definition he also writes Insular a.
- ALLOGRAPH.insular-a EXCLUDES ALLOGRAPH.caroline-a. A single graph (instance) of a cannot be both Caroline and Insular. A scribe may wrote both Caroline and Insular forms, and perhaps even a hybrid of the two, but a single letter a cannot be both clearly Caroline and clearly Insular.
- ALLOGRAPH.insular-h NORMALLY_IMPLIES COMPONENT.wedged-ascender. The Insular h is normally wedged, and so if we have Insular h and lack further information then we could guess that it has a wedge on its ascender, but this is not necessarily the case. The main purpose of this relationship would be not for inference but to aid data entry, since the NORMALLY_IMPLIES relationships could be filled in automatically by the UI, thereby saving a lot of time but still allowing the data-entry person to remove them if they are not present.
This model seems to make some sense to me. To describe a graph, one can simply connect it to an allograph entity using an IS relationship, and/or list its features by connecting to components with HAS relationships. [Edit, 25 August 2011: This is now discussed further in Part III of this series.] To describe a scribal hand, one can connect it to all the allographs found in it, either directly with SHOWS relationships and/or via graphs (also using SHOWS relationships?).
It's also worth noting that this is a purely graphic conception of letters. To illustrate this, consider the first example relationship given above, that hs require ascenders. What about an informal script where (for example) a scribe clearly intended to write an h, in a context which demands an h, and where any self-respecting editor would print an h, but where the script was rapid enough that the scribe did not actually write the ascender? Is it not still an h? Yes, according to Peter Robinson in his article on 'What Text Really is Not', where he argued that an i is not simply a line with a dot above it but rather that an i is an i when we all agree that it's an i. This is an important point and can have significant consequences, but for now I can only say that we must always allow for exceptions in humanities content, even in the 'must' of MUST_HAVE.
No doubt the model given here still has problems that will need to be tested in practice: for example, ligatures and conjoined letters which must presumably be entities that operate above graphemes but which are still allographs. It is also unashamedly 'morphological' in the sense that it ignores ductus, the direction of strokes and movement of the pen; I consider ductus beyond the scope of DigiPal for various reasons that I'm happy to elaborate. To test this system thoroughly, though, we need first to start enumerating all the required entities. This will be discussed in the next post, and that in turn will bring us back to the question of terminology.
Share on Twitter Share on Facebook
Comments