Print

Print


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; &par; 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; &par; &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
https://listserv.brown.edu/cgi-bin/wa?A3=ind9111&L=TEI-L&E=0&P=87649&B=--&T=text%2Fplain&header=1
listserv.brown.edu
crawl=CC-MAIN-2019-22
8587
application/http; msgtype=response
sha1:Y5ADP4MFTCFQKLWP23KBNJVFEKFB62YP
<urn:uuid:4568e4fd-3407-4721-a0fc-7c1275bcae4f>
2019-05-27T05:18:13Z
128.148.252.33
text/html
sha1:YLH3KPUFRZSW6D4C2WFLOOO76XFXERGO
<urn:uuid:e2f14559-a4f3-4fcb-bfd9-41988065eaf3>
https://listserv.brown.edu/cgi-bin/wa?A3=ind9111&L=TEI-L&E=0&P=87649&B=--&T=text%2Fplain&header=1
response
<urn:uuid:bdfc5522-365d-45ea-a44b-7d1617209944>
isPartOf: CC-MAIN-2019-22
publisher: Common Crawl
description: Wide crawl of the web for May 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-99-168-2.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/