MS chapter reviews
- Dorothy ‘Dot’ Porter (DP), working with Ben Withers, professor in Art History, University of Kentucky, who is producing an electronic edition of BL Claudius B. iv.
- Elizabeth Solopova (ES) at the Bodleian
- Torsten Schaßan (TS) of the Herzog August Bibliothek in Wolfenbüttel
- Jindrich Marek (JM) of the National Library of the Czech Republic
- Gautier Poupeau (GP) of the Sorbonne
The reviewers point out many small errors and inconsistencies, some owing to the nature of the ODD system, such as statements in the specifications that elements have no attributes other than global and inherited ones, when according to the surrounding prose in fact they do (about a dozen of these are mentioned by TS), and descriptions of standard TEI elements or attributes which are inappropriate to manuscripts, for example <extent> , mentioned by almost everyone (GP feels that <extent> , which has a clearly defined purpose in the <teiHeader> , should not be used for something entirely different here).
Some ‘classic’ problems turned up again, such as the apparent inflexibility of the system when dealing with legacy data: the fact that one cannot, for example, take <physDesc> before <msContents> , which is precisely what the majority of printed catalogues do (ES). In this and a few other cases it is doubtful whether revisiting these issues now would be profitable; in other cases, however, it is clear that adequate solutions remain to be found to some of these problems.
There were also a number of comments which were simply wrong (people saying that you couldn't do things you in fact can); these, in some cases at least, indicate that the documentation needs to be better.
In addition to obvious mistakes, inconsistencies and lacks, which have been or are being dealt with, the following may be mentioned as suggestions for improvement on which action might be taken (comments on these would be gratefully received):
1. One problem which was mentioned by several people has to do with the change of <msHeading> to the standard TEI element <head> , one result of which is that it is no longer possible to use <textLang> to indicate the language of the manuscript as a whole ( <textLang> is allowed within individual <msItem> elements but is not, unlike <origPlace> , <origDate> and <title> , phrase-level). There is, of course, nothing to stop you simply writing ‘Latin with some French’ in your <head> element, but for search purposes and so on people will probably want to tag these things. One solution that occurs to me is to have the relevant attributes from <textLang> , viz. langKey and otherLangs, on <msContents> ; another would be simply to make <textLang> phrase-level. Doing either of these would also allow one to encode the languages of the manuscript even if one used the <p> option inside <msContents> , as requested by ES. (ES suggests <textLang> is also needed elsewhere, e.g. in <provenance> to indicate the languages used in ownership notes, but the xml:lang attribute can be used for such purposes). The inability to have <author> in <head> was also mentioned (e.g. by JM), but this is largely, one suspects, a result of its having been possible in MASTER; if one feels strongly about it, one can always wrap <author> and <title> inside a <bibl> .
2. Not for the first time, there is a request for a type attribute on <bibl> , which ‘would be extremely helpful for sorting, searching and general output’ (ES). In theory I agree (and proposed this myself on an earlier occasion); for what it's worth, we decided at the AMI that it was necessary to distinguish between editions of texts on the one hand and scholarly discussions of a philological nature on the other, and that there should also be a distinction between scholarly discussion which is based on first-hand investigation and that which is secondary in the sense that it derives not from an examination of the primary sources themselves but from other published materials. A third group consists of references which are no more than that, i.e. which add nothing to the discussion and are therefore unlikely to be of interest to the scholar. Similarly, we decided to distinguish between types of editions. In order to distinguish between the various types of secondary material and text editions we use a type attribute on <ref> (within <bibl> ), with the values primary and secondary plus a number to indicate the level. We put the type attribute on <ref> since such ‘ratings’ are only applicable to the bibliographical references in the individual <msDescription> elements, as the same work will inevitably have varying levels of relevance to different manuscripts.
3. Several reviewers queried the meaning and use of the type and status attributes on <msDescription> . These have long been problematic and are still in need of sorting out. The intention with the type attribute was to distinguish at the very top (as it were) between manuscripts proper and archival material (charters etc.). The inspiration for this came, as far as I can remember, from EAMMS and/or Digital Scriptorium, which had a simple tick-box: document yes/no; this was taken over in MASTER as type="document", with no alternative. As pointed out by TS, the form attribute on <objectDesc> provides the same information. The status attribute is defined as specifying ‘the compositional status of a manuscript or manuscript part’ and has the possible values uni, compo, frag, def or unknown. It has been pointed out that, for one thing, this should probably be called msStatus or something similar, since it refers to the status of the manuscript and not of the description, and for another that it is prefectly possible for a manuscript to be both composite and defective, which is why TEI-MMSS proposed splitting this attribute into two: status, with possible values frag, def and unknown, and composite, with possible values yes, no or unknown. It has also been pointed out that the distinction between uni and compo is in any case inferable from the presence or absence of <msPart> elements, while a manuscript which is defective will have defective="true" on <msContents> or <msItem> . Thus the only possible value of status which cannot be inferred from other places in the document is frag; this was always potentially problematic anyway, as the distinction between a fragmentary and a defective manuscript is somewhat arbitrary. I am not sure we need an attribute to indicate the completeness or otherwise of the description itself, as TS would like to see, since this would be better dealt with under <recordHist> . So my feeling is - drop 'em both.
<extent> <measure type="leaves">10 Bl.</measure> <measure type="dimensions">37 x 29 cm</measure> </extent>Regarding these two elements, GP points out that key is available as an attribute on <measure> but not on <dimensions> ; this is true, but I am not sure I see what its usefulness there would be.
5. Several people, TS and CD among them, mention that it needs to be made more explicit where the elements <origDate> and <origPlace> can (or should) appear. TS suggests that they should only appear in three places: in <head> , in <binding> (since the binding might have been done at a time and place different from the text) or in <origin> , which he says is the natural place for this kind of information. I have myself often wondered whether these elements should be allowed everywhere (as, being phrase-level, they are at present), or even if they are whether their use in more than one place should not be discouraged? A case could be made, it seems to me, that they should appear only once in each <msDescription> (or <msPart> ). Furthermore, it has never been clear to me where the attributes notBefore and notAfter should go (i.e. on <origPlace> , on <origin> , on both?).
6. In analogy to the class tei.datable TS proposes tei.placeable, of which (at least) the element <origPlace> should be a member; it would contain the attributes placeAttrib, with possible values localized, localizable and unknown, and evidence with the values internal, external and attributed (presumably also certainty, which he doesn't mention). This is, it seems to me, a good suggestion. Apropos datable things, GP wonders why the elements <date> and <docDate> are not members of the tei.datable class. A good question, to which I have no answer.
7. TS points out an inconsistency between <bibl> and <msItem> in that <biblStruct> , which was a more structured <bibl> , has been removed in favour of <biblItem> , which contains the structured content; <msItem> , on the other hand, contains the unordered content whereas the structured content goes into <msItemStruct> . This is a valid point, but what to do about it? Several other people, GP among them, thought the difference between <msItem> and <msItemStruct> was not explained clearly enough. This section has been completely rewritten and is now, I hope, clearer. I still wonder, though, whether anybody (other than David Birnbaum, for whom it isn't restrictive enough anyway) actually needs <msItemStruct> .
8. TS agrees with CD that the two attributes attested and accepted on the element <author> (as allowed in MASTER) were very useful and should be reinstated. The problem here, I assume, is that <author> is a standard TEI elements and thus cannot be redefined in another context. If the notions they represent are so different in these two contexts the only solution is to come up with new special-purpose element, e.g. <msAuthor> (there are obviously many examples of this already). I wonder, however, whether they really are so different, or whether what differences there are can't be dealt with using the existing <respStmt> element. GP, incidentally, would like to be able to include <respStmt> at various places in the physical description, so as to be able to indicate the names of ‘les différents intervenants dans la conception physique de l'ouvrage’. While I agree wholeheartedly with the idea behind this, I think the same result can be achieved using the mechanisms proposed for prosopographic information generally (key on <name> pointing to a <person> element); here again, however, the removal of the role attribute on <name> does not allow one to distinguish between different roles played by the same person (the same person could be the scribe of one manuscript and the owner of another). This is a problem which really does need to be sorted out; the most obvious way of doing this would be to reinstate role, or, if that's not acceptable (on the grounds that names don't have roles, other than naming things), coming up with another name (persRole perhaps?).
7. Several reviewers felt that the over-all structure of <physDesc> was illogical or inadequate, and the sections describing it confusing. JM suggests, for example, that the encoding of watermarks should be done not within <material> but in a specialised <watermarksDesc> element, containing one or more <watermark> elements. It is clear that the mechanism for dealing with watermarks is at present only very rudimentary, and this is certainly one direction in which future work might lead us, but I am not persuaded that this change needs to be made now. JM also argues that instead of <objectDesc form="codex"> there should be a <form> element; there was a <form> element in MASTER, which the task force agreed was unnecessary, and I must admit that I see no reason to reinstate it now. JM also says that the material attribute on <supportDesc> is unnecessary, given the availability of the <material> element within it (which even has a type attribute, allowing one, in theory, to provide the same information three times). I agree that using both the attribute and the element is a bit ‘belt-and-braces’, but I don't see anything wrong with offering people alternatives. ES complains that <decoNote> elements can't be grouped in a list and provided with a heading, but I don't see that the same effect can't be achieved by using <list> within <decoDesc> , i.e. where <decoDesc> is used to describe a type of decoration, rather than a particular instance of decoration (the documentation makes clear that both these are possible); this is, in fact, precisely what has been done by DP, who declares herself satisfied with the result.
<msWriting hands="4"> <date>Early 9c</date> <term type="fontDescription">littera carolina</term> Four hands, each writing one complete gospel: <handDesc scribe="Hiltfredus">A: <locus>ff. 2r-54r</locus> (= Hiltfredus)</handDesc>; <handDesc scribe="B">B: 56r-90r</handDesc>; <handDesc scribe="C">C: 92r-152r</handDesc>; <handDesc scribe="D">D: 153r-194r</handDesc>. </msWriting>Since this kind of structure cannot be encoded using the current model for <handDesc> , he says, one possible solution might be to ‘reinvent’ the element <msWriting> , with the attribute hands and children <p> or <handDesc> . <handDesc> might have a mixed content model with <handNote> as its main child. Alternatively, <handNote> or just <hand> could be made a phrase-level element, which would allow for its use within <p> . GP, for his part, bewails the fact that there is a degree of overlap between the system proposed here for describing hands ( <handDesc> ) and the existing system in chapter 18 and asks whether it wouldn't be ‘intéressant’ to try and merge the two systems. Trés intéressant, I should have thought. This is clearly an area in need of further work.
9. Finally, TS says that it would be nice if bibliographical information (or a link) were provided for the manuscript descriptions from which the examples have been taken so that one could see how they fit into the record as a whole. This is a good idea, the only problem being that some of the examples are made up for the purpose while others are (or were once) real; still, the longer ones are likely to be real, and I suppose one might, as a matter of principle, only use real examples in the TEI guidelines.