========================================================================= Date: Mon, 25 Nov 1991 11:33:36 GMT Reply-To: Donald A Spaeth Sender: "TEI-L: Text Encoding Initiative public discussion list" From: Donald A Spaeth Subject: TEI Norway meeting issues Thanks for sending the report on the issues raised at Norway. Very interesting! Has the character set group looked at issues raised by manuscripts (many of which lead to ambiguity?) - the use of multiple symbols to represent a single character (within a single document) - changing formulation of symbols representing characters over time - the presence of particular standard hands, e.g. Court hand, Secretary hand - the use of non-character symbols, e.g. shapes representing days of the week or used as marks in place of signatures (which may be 'x's, shapes representing a trade or unknown shapes) - minims, which may need to be encoded where the transcriber cannot determine the word but can count the number of minims - diacritic-style abbreviations in standard use in medieval/early medieval to represent endings or duplicate letters (for example); these may cover several letters and may be ambiguous (e.g. a crossed 'p' may be 'per', 'par' or even 'pro' depending upon the context). - notes on the hand, e.g. that it is shaky, disciplined, in a different colour ink, similar to the one used above These features need to be encoded because they may help to identify both reading and authorship of texts/documents. Donald Spaeth Working Party, History University of Glasgow Received: by UICVM (Mailer R2.07) id 8347; Tue, 26 Nov 91 08:49:58 CST Date: Tue, 26 Nov 1991 15:46:54 MET Reply-To: Harry Gaylord Sender: "TEI-L: Text Encoding Initiative public discussion list" From: Harry Gaylord Subject: medieval characters To: Wendy Plotkin Donald Spaeth raises very important issues about encoding of manuscript material. It is my understanding that TR9 on W4 manuscripts should be making recommendations on this subject. The character set group can make some recommendations on how to encode this information. No coded character set will be able to include separate characters for each dingbat that a scribe invents. Character entity sets must be developed for this. In medieval manuscripts we do not have a discrete set of characters, but an open repertoire. This is going to be a continuing problem, but there will be more guidelines on creating new character entity sets in P2 and P3. If more than one symbol is used for a single character in a document, then it depends on what the encoder intends to do with it. If one is studying the writing system of the scribe, one would probably use a different character or character entity for each symbol. If one is not focussing on those features, but primarily comparing textual agreements, then one might regularize the readings. On non-character symbols, one would need to create appropriate character entities. Standard hands could be handled with a rendition attribute, but we would need a list of these ideally. On the issue of abbreviations, the text criticism group proposed mirror tags of abbrev and expan with attributes for type, responsibility, (abbrev or expan), and confidence. Perhaps Peter Robinson will say something about ambiguity. Harry Gaylord Received: by UICVM (Mailer R2.07) id 7731; Tue, 26 Nov 91 17:47:30 CST Date: Tue, 26 Nov 1991 16:47:56 CST Reply-To: "C. M. Sperberg-McQueen" Sender: "TEI-L: Text Encoding Initiative public discussion list" From: "C. M. Sperberg-McQueen" Subject: Re: Spaeth on MS character problems X-To: Donald A Spaeth , Text Encoding Initiative Public Discussion List To: Wendy Plotkin In-Reply-To: Your message of Mon, 25 Nov 1991 11:33:36 GMT On Mon, 25 Nov 1991 11:33:36 GMT Donald Spaeth said: > ... > Has the character set group looked at issues raised by >manuscripts (many of which lead to ambiguity?) Some of these issues have indeed been explicitly considered by various work groups, though not always by the character set group; some have not. For some, I am not sure what one can say beyond noting the need for the scholar doing an encoding to think about what goes into the encoding and what does not. For each item you list, I give below my best understanding of the current state of the guidelines and the recommendations of the competent work groups; it would probably be unwise, however, to think of these notes as authoritative. > - the use of multiple symbols to represent a single character > (within a single document) This would be synonymy, not ambiguity, no? If the distinction is important, I would use distinct transcriptions for the different forms; as always, if one of the forms were not present on the keyboard, I would use an entity reference to transcribe it. > - changing formulation of symbols representing characters over time I am not sure this is an encoding problem. It *might* be an encoding problem if one envisaged searching a database for all occurrences of the letter 't' formed by method 1, vs. all occurrences of 't' formed by method 2, vs. method 3, etc., which I assume would occur in corpora transcribed for the study of paleography. The use of aptly named entity references to transcribe the different letter forms seems the obvious way to go (by the same logic as above: if it's not on the keyboard, use an entity reference). > - the presence of particular standard hands, e.g. Court hand, > Secretary hand For just such purposes as this was the RENDITION attribute provided. Since no one seems to agree on what the standard hands are, or what details of hand / typography / layout / presentation are to be recorded, the RENDITION attribute remains pretty much of a blank slate. We had hoped to provide much firmer guidance on its use in version 2 of the Guidelines, but it would appear that the detailed physical description of the running text in books and manuscripts is not quite ripe for standardization. Be this so or not, we are not going to have much on using RENDITION in version 2: it's still going to be something one works out for oneself. The TEI case book (which will accompany the guidelines themselves, but be prepared separately) will, I hope, have an example of a rational extension of the RENDITION attribute with the characteristics of rendition considered useful by one specific project. > - the use of non-character symbols, e.g. shapes representing days > of the week or used as marks in place of signatures (which may be > 'x's, shapes representing a trade or unknown shapes) Entities. Entities all. The Writing System Declaration provides a slot for describing character shapes, though at present it does not prescribe any particular form for the description. The font-information people (separate from the TEI) are working on this and one hopes they will produce something useful for such ms. marks. For the moment, I'd use bit maps or Metafont programs or even little drawings with exes and spaces. If I were transcribing 20,000 medieval charters and I found myself finding more than a few brand new shapes to describe in every charter (i.e. if I found myself looking at a total, over the project, of more than about 50,000 distinct entities), I might consider trying to capture the information in prose annotations (or rethink my approach to capturing the characters). I would not hesitate, however, to build up a library of entities with about the same number of entries as one finds in Capelli's dictionary of abbreviations and signs, if I needed them. > - minims, which may need to be encoded where the transcriber > cannot determine the word but can count the number of minims Hmmm. I'm not sure I understand. If by 'count the minims' you mean actually count the number of minim strokes on the page, then I'm stumped, because I don't know how to do this except by putting in a note saying '7 minims here'. If you mean not actually to count marks on the page but to give the width of an illegible passage by saying how many minims it would take to fill it (thus adjusting for the size of the writing), then I think the normal methods of indicating width of lacunae etc. (developed by the work groups on mss and text criticism) can do what is needed. (I.e. whenever one must specify the width of something, the units to be used are not prescribed by the TEI, so one can say '7-minim gap' where appropriate.) > - diacritic-style abbreviations in standard use in medieval/early medieval > to represent endings or duplicate letters (for example); these may > cover several letters and may be ambiguous (e.g. a crossed 'p' > may be 'per', 'par' or even 'pro' depending upon the context). Both the text criticism and the mss work group did consider this, as has one of the TEI's affiliated projects. The text critics suggest that one (1) define crossed-p as a grapheme in the writing system declaration, (2) define an entity for the abbreviation, or (3) use the ABBREV tag to record the abbreviation and one's expansion of it. These are not mutually exclusive, of course. One can transcribe abbreviations with entity references and expand the entities either as characters or as ABBREV elements. If one wishes to disambiguate the abbreviation, one can of course use several entities; here I would use &per; ∥ and &pro;, unless I needed to distinguish several different abbreviations for 'per', in which case I would use names like &per.1; &per.2; unless I could find something more mnemonic. The mss group mostly just chuckled at the notion of retaining detailed information on the abbreviations in a ms, taking the view that it is the business of the transcriber to know how to resolve the abbreviations, and if one tried to record them all one would have died before reaching the colophon of any substantial manuscript. They did not take the view that one should be *prohibited* from recording individual abbreviations, though, and thought the choice of specialized character set, entity reference, or ABBREV tag could usefully be left to the encoder. The affiliated project will record abbreviations (in early printed books) with entity references (the &per; ∥ &pro; mentioned above), so they can print out a text with the abbreviations as in the copy text, expanded silently, or expanded in italics. > - notes on the hand, e.g. that it is shaky, disciplined, in a different > colour ink, similar to the one used above Rendition features, again, I think. It might be useful to record this information in feature-structure notation (soon to be renamed F notation), as being an analysis of the text on which different analysts might disagree. I do not claim any particular originality for what I have said here; most of it, indeed, seems only a restatement of what is in TEI P1, or what follows from it. It is not an accident that what I have written here agrees with what I have just seen in Harry Gaylord's posting on this thread. (Not everyone agrees, of course, that the inferences are so obvious, and it is to be hoped that P2 may be clearer in some respects than P1. Cross your fingers.) Cordially, Michael Sperberg-McQueen Received: by UICVM (Mailer R2.07) id 3013; Wed, 27 Nov 91 03:17:45 CST Date: Wed, 27 Nov 1991 09:15:00 GMT Reply-To: PETERR@VAX.OXFORD.AC.UK Sender: "TEI-L: Text Encoding Initiative public discussion list" From: PETERR@VAX.OXFORD.AC.UK Subject: Spaeth, ambiguous abbreviations To: Wendy Plotkin Harry Gaylord and Michael Sperberg-McQueen have said pretty much what I would have wanted to say, only better. A tailnote on encoding of ambiguous abbreviations: the Text Criticism draft explicitly proposed a mechanism for this. First, you represent the character itself with an entity reference. Second, you use either the "expan" or "abbrev" tags to indicate just what you think the charachter represents. If you think it could mean several different things, then you group the various interpretations "in parallel" within an app element. Suppose we have a ms. with p_underbarred_vert. Various authoritie s differ as to whether this should be expanded as "provert", "pervert" or "parvert". The proposed mechanism would let you encode this thus: p_ubarvert p_ubarvert p_ubarvert You could also attach to each abbrev element an attribute "resp" naming the person responsible for each expansion ( etc) etc. The same mechanism could be used for grouping alternative conjectures etc. Of course, like everything else about TEI the sands are shifting under this. There has been chatter about using the already-legendary feature structures to capture such information (they could well take over everything). In the meantime, this will serve a lot of us a lot of the time. Finally: I am amused by Michael's remark that if we stopped to encode *every* abbreviation we would not reach the colophon. I have been encoding every abbreviation some years now in Old Norse and Middle English manuscripts and we are well past the colophon. It is horses for courses, a reminder that what some people do in one corner can't stand as a model for us all. Peter Robinson, Oxford. Received: by UICVM (Mailer R2.07) id 7430; Mon, 02 Dec 91 05:50:07 CST Date: Mon, 2 Dec 1991 11:46:15 GMT Reply-To: Donald A Spaeth Sender: "TEI-L: Text Encoding Initiative public discussion list" From: Donald A Spaeth Subject: Manuscript characters To: Wendy Plotkin Thanks to Harry, Michael and Peter for their responses. It all sounds embarrassingly straightforward. On reflection, entities are the answer for minims, too, e.g. &minim. Michael suggests that the use of multiple symbols doesn't appear to be ambiguity. The problem arises when the transcriber is unable to identify a character which may take several forms, some of which are similar to the forms other characters may take. The current process is to scan by eye the page looking for other forms which look the same. This procedure falls down when no known word seems to contain the ambiguous form in the appropriate location, and is time-consuming. The example provided for encoding readings seems to assume the need to choose between a limited number of seen possibilities, rather than possibilities that are unperceived because of difficulties reading the letter. It would make sense automate the search for letters described above, possibly tied to a dictionary. Entities could be used to represent different sets of topographical features. A similar procedure would be followed to disambiguate minims, e.g. to help decide whether &minim&minim&minim represented 'ui', 'ni', 'm', etc., by pulling out all possibilities from a dictionary. Donald Spaeth Glasgow University