Source: notes file
Date: 21 Dec 2004
File name: Wh3868
Keywords: illegible, entity reference, technical
Apex captured vitâ as "vil&$circ;". I'm not sure that a $ should be combined with a character entity in this way,
PFS: for the keyers, this seems a reasonable thing to do, though more than a bit unexpected.
or how it might ultimately display.
PFS: we should convert, I think, (assuming that we can't read it either) to <GAP DESC="illegible" EXTENT="1">ˆ
Although the validator doesn't object to this, or any undefined entity with a $ following the &.
PFS: this *does* surprise me. NSGMLS apparently checks for the validity (i.e. the declaredness) of entity references only if they are formally valid entities to start with. For example, and most familiarly, if it finds:
& foo;
it does not shout that "& foo; is an undeclared entity; it simply assumes that what you really meant is (in effect) & foo;. I knew that. What I did not know is that it treats many other characters, when they are placed after the "&" in the same way that it treats a space character. It swallows all of the following, for example:
&!foo;
&@foo;
&$foo;
&%foo;
&^foo;
&*foo;
&(foo;
&)foo;
&-foo;
&_foo;
&+foo;
&=foo;
&1foo;
&2foo;
&3foo;
&?foo;
&/foo;
&\foo;
&>foo;
&,foo;
&.foo;
&:foo;
&'foo;
&"foo;
&]foo;
&}foo;
&~foo;
&`foo;
etc. --not because these are declared entities, but because it does not regard them as entities at all. At least that's my interpretation!
I will make sure that there is a check in my postprocessing review that will find all strings &[^a-z]
Source: notes file
Date: 14 Oct 2004
File name: Wh3098
Keywords: attribute, structure
Added LANG tags to everything [a multilingual book of proverbs, with sections devoted to various languages; now so tagged].
PFS: I removed some (on the principle that the LANG attribute is inherited, so
<TEXT LANG="eng">
<BODY>
<DIV1 LANG="eng">
<DIV2 LANG="eng">
contains (usually) superfluous information.
I also restored the division of the book into several TEXTs (within GROUP) and the use of TYPE="version" at the appropriate level. Since the split into versions was done at a high level (higher than I would have liked, actually: see email of Feb 17 2004), most of the texts here were split like this:
<TEXT>
<BODY>
<DIV1 TYPE="version" LANG="fre"> (or whatever)
<DIV2 TYPE="part">
<DIV3 TYPE="section">
<DIV1 TYPE="version" LANG="eng">
<DIV2 TYPE="part">
<DIV3 TYPE="section">
In those cases, only the DIV1s required LANG attributes (there were some messier bits, however, that required LANG attributes at a greater depth in the structure.) Also added some LANG attributes for the small sections of Portuguese, Catalan, and Gallician proverbs, and made those sections subordinate to the larger section devoted to proverbs 'from particular places' (in the Iberian peninsula).
Source: email
Date: 06 Feb 2002
Filename: S1667
Vid: 1282
Page ref: 17
Keywords: drama, SP
Query There are some bits of this in italics which have been tagged as stage directions, but they actually seem to be part of the dialogue. It isn't clear who is speaking, so I'm not sure what to do with them.
Answer I think these are asides: Cleophila is to be pictured kneeling in prayer before Cupid, addressing him formally in verse, then interrupting herself with asides addressed to Hero. I can't think of any specific rule that applies here, except to put text more or less where it belongs. In this case, the asides seem to belong at the end of the speech, since Hero's speeches directly answer them. And I think that I'd omit the opening parentheses (or are they clumsy curly braces?), since they are more an insertion marker than real punctuation (similar to the opening pars that mark the tail end of broken verse lines). But I'd include <HI> to mark italics, since we are not indicating the italics in any other way (no <ASIDE> tag, for example).
That is, I'd do this:
<SP>
<SPEAKER>Cleo.</SPEAKER>
<LG>
<L><HI>Cupid</HI> pardon what is past,</L>
<L>And forgiue our sinnes at last,</L>
...
<L>In the Fields, or by the Fire,</L>
<L>With the youth that haue desire.</L>
</LG>
<P><HI>How does shee yet?</HI></P>
</SP>
<SP>
<SPEAKER>Hero.</SPEAKER>
<P>O ill:</P></SP>
<SP>
<SPEAKER>Cleo.</SPEAKER>
<LG>
<L>Giuen Eare-rings we will weare,</L>
<L>Bracelets of our Louers haire,</L>
...
<L>O then pardon what is past,</L>
<L>And forgiue our sinnes at last.</L>
</LG>
<P><HI>What, Minds shee?</HI></P>
</SP>
<SP>
<SPEAKER>Hero.</SPEAKER>
<P>Nothing, you do it not wantonly, you shuld sing</P>
</SP>
Source: email
Date: 13 Feb 2002
Vid: 119494-01
Page ref: 17
Keywords: character
Query
There are a number of Js which ought to be I's to make sense. They could even be smudged I's but they've all been transcribed as Js. What should I do? Are they meant to be Js?
Answer
Looking at the rest of this section, in which every other clause begins "I," my guess is that a little into page 31, the printer ran out of "I"s in his upper case and was driven to substitute "J"s. If so, they are really "J"s, but were intended to stand for "I"s.
This would be an easier question if it did not run up against our previous inconsistency in dealing with I/J. In the keyers' instructions, because some typefaces make I and J indistinguishable, they were told to capture all capital Is and Js and "I". Some reviewers have been holding them to that, by globally changing "J" to "I" in received texts; others have left them alone. *I am inclined now to think that the original instruction was a mistake: we should distinguish I from J whenever the typeface allows us to do so.*
If we adopt this change, then I think we should leave these particular "J"s alone--i.e., leave them as "J". They in some sense stand for "I", but "vv" stands for "w" and we still record it as "vv".
Source: email
Date: 22 Feb 2002
Vid: 44491
Page ref: 14
Keywords: character, ligature
Query
The text I'm working on has a number of instances of the word faetus and the ligature does look very much like the ae ligature. I can't find any example in any dictionary of foetus ever having been spelt in this way, though. Do you think you could have a look and see if you think it is in fact an oe ligature before I go ahead and change them?
Answer
I've been trying to see where "correcting" the ae/oe ligatures would lead us. I think that we would do it only if we (1) couldn't distinguish the forms of the glyphs in the book; or (2) were confident that one glyph was in fact being used in the book deliberately to stand for two different ligatures. It is possible that the latter is true of this book, but it may simply be that the printer (or author) is a bad speller, or indifferent to the ae/oe distinction. Here is how the spelling in the book fall out:CORRECT SPELLINGS
In italic (spelt ae, should be ae)
Althaea
Arteriae
Blatiae
Nym|phae
Nymphae
P$aeputium
Perito|naeum
Peritonaeum
Phaedro
Portae
Praeputando
Prostatae
Sper|maticae
Spermaticae
Venae
Vesiculae
In roman (spelt ae should be ae)
Lamiae
Aqu$vitae
In roman (spelt oe, should be oe)
Foedita
INCORRECT SPELLINGS
In italic (spelt ae, should be oe)
Faetus
Phaenix
Assa-Faedita
In italic (spelt oe, should be ae)
Froenum
In roman (spelt ae should be oe)
Gonorrhaeas
In roman (oe should be ae? )
Coelestial
UNKNOWN
In italic, uppercase, maybe = Gk. Oistros, which means it should be Oestrum ('frenzy, passion'), but I'm probably wrong.
AEstreum
A true italic oe does appear once, so it was presumably available. We *could* correct the 5 or 6 misspellings, but I do not think that we have good grounds to do so. Let us leave them as they are and let posterity abuse the book as badly spelled.
Source: email
Date: 30 Apr 2002
Keywords: punctuation
Query
The book I am currently proofing has a great many hyphenated compounds e.g. Gospel-Testimony, New-Creation, Gospel-spirit and so on. These occur throughout the text, and where they occur across lines they have been captured, as we would expect, with a |, so Gospel|Testimony, New|Creation, etc. I can correct the ones in the sample and the most common ones I could search for, but I suppose there is no way of catching them all. Is it worth correcting all that I can or should I leave them as | for consistency's sake?
Answer
I don't think consistency is important: words divided by "|" are always candidates for selective correction to "-".
Not knowing how big the book is, it is hard for me to judge how practical it would be to change the |s to -s as appropriate throughout. I wonder, though: are the second elements of the real compounds usually capitalized? If so, could you change all the "|"s followed by an upper-case letter to "-" and get most of them that way? Perhaps supplemented by some of the more popular compounds? And ignore the rest?
Source: email
Date: 16 May 2002
Vid: 55311
Page ref: 95-7
Keywords: symbol
Query
In the advertisement at the back of this text what I assume is the book format is given as a number and what looks like a degree symbol (ie 4^o for quarto, 8^o for octavo). Apex have captured them as 4°. etc. Should these be changed to 4^0 or is there something else I should do?
Answer
We've been changing these to 4^o, 8^o (that is, 4 and superscripted lower-case "o"), since the "o" is really just the final "o" of "quarto", etc. We've done the same in the case of regnal years (e.g. "3^o Hen.8" = third year of Henry VIII). In both cases, vendors have been been known to use °. ° may not be wholly wrong, since I imagine that the origin of the "degree" sign is none other than a superscripted "o"; but we have, perhaps foolishly, tried to reserve "°" for uses which modern usage makes us think more appropriate, degrees of latitude or measures of angles, for example.
Source: email
Date: 22 May 2002
Vid: 97946
Page ref: 1
Keywords: greek, titlepages
Query The title page of this book has two greek characters in the title. These weren't spotted by the vendors, who transcribed it as BIAOANATOE. I don't think we have an entity reference defined for the last one. I've put in Θ and Σ for now. Is this ok?
Answer As regards representing these two characters, yes, this is ok. Greek characters are yet another thing I was sloppy with in the instructions, but lately we've been preferring the charents found in the ISO "greek 1" set. These should be referenced by the dtd; the set itself should appear as a file in your charents directory as the file isogrk1.ent. The entities for upper-case theta and sigma in ISO Grk1 are &THgr; and &Sgr; respectively.
(What you've used are the corresponding entities from ISO Grk3 (Θ and Σ). Theta was included in the EEBO character selection for reasons too complicated to go into; Sigma was, I guess, not. but both will will work either if the Sigma is added to EEBOchar.ent or if ISO Grk3 is invoked in the dtd and included in your catalog file. The sloppiness arises from the fact that I did not tell the vendors which alternative set to use. Let's see how far we get using ISO Grk1 and not go to 3 unless we need to.)
The question you don't ask is what to do with the rest of the word. Assuming that the entire word is meant to be Greek, the "B" is not really a "B" but a beta (&Bgr;); the "I" is not really an "i" but an iota (&Igr;), etc. If the word occurred in the body of the text, I think that we'd GAP it (<GAP DESC="foreign">). I'm not sure what to do with it as a title. Should we make an exception of book titles?
If we *do* make an exception of titles, I think the honest thing to do is treat is a Greek word and use entities throughout, i.e.,,/p>
&Bgr;&Igr;&Ogr;&THgr;&Agr;&Ngr;&Agr;&Tgr;&Ogr;&Sgr;.
If that seems too unhelpful, we could even add a "translit" attribute to <FOREIGN> and capture as:
<FOREIGN TRANSLIT="BIATHANATOS"> &Bgr;&Igr;&Agr;&THgr;&Agr;&Ngr;&Agr;&Tgr;&Ogr;&Sgr</FOREIGN>
Source: email
Date: 02 Aug 2002
Keywords: attribute, structure
We've noticed a pair of oddities in some files dating back, I guess, to May, namely: (1) the attachment of a LANG attribute to small structural elements (LG, L, Q, P, SP); and (2) the assignment of "lat eng" as the value of the LANG attribute (LANG="lat eng").
The first does no harm, though we've not asked for LANG attributes on anything but TEXT and the various levels of DIV.
And the second (supplying two values for the attribute) should be used only when two languages are both present and prominent in an organized way, e.g., in a Latin-English dictionary. Most of the examples I looked at were in fact entirely in Latin; a few were in French; and maybe one could be construed as containing a mixture--though the only Latin present was in an epigraph.
Source: email
Date: 23 Aug 2002
Keywords: DATELINE
Just a point of information, which you probably already know. The various phrases and abbreviations indicating the dating system in use should be treated as part of the <DATE>. Not only A.D., Anno Domini, etc., but also those having to do with the adoption of the Gregorian "new style" calendar: S.N. (stylo novo), S.A. (stylo antiquo), S.L. (stylo loci), and no doubt others
Examples:
<DATE>6 Sept. 1640. in the Stile of the place.</DATE>
<DATE>6. Sept. 1640. St. loci.</DATE>
<DATE>Feb. 14. 1662. S. A.</DATE>
<DATE><HI>Iuly</HI> 22<HI>d. Stylo Novo.</HI> 1679.</DATE>
<DATE>Sept. 14. S. N. 1640.</DATE>
Source: email
Date: 14 Jan 2003
Keywords: policy
From John Latta:
What I work from is the attached
list of authors [PUT IN LINK HERE] (taken, if I understand correctly) from the index to the
New Cambridge Bibliography of English Literature. I've been trying to
"finish" authors (hence, boldfaces and dates), but Hillary did far more
skipping around. In other words, we have done many works by many authors
whose names are not yet boldfaced. The other list I check is a huge list
of Paul's creation that includes bibliographical numbers, STC numbers,
VIDs, etc. It corresponds to those EEBO texts for which we have MARC
records--so if it's _not_ on that list, I don't select it.
Source: email
Date: 28 Mar 2003
Keywords: technical
Query
Whats a path environment variable? and where is it?
ahh (stroking his grizzled beard), so young, not to remember the DOS "path" command.
The "path" variable is the list of "paths" that the command-shell-formerly-known-as-DOS looks in when it is given a command to run. A simple one might look like this:
PATH="C:\Apps\Bin;C:\Apps\Sp\Bin;C:\Apps\Perl\bin;C:\WINNT\system;
That is, it is a series of directories (folders), listed end to end but separated by semicolons, each one including the full path from the root to the folder. When you type the command "makesample", DOS will look first in the current directory. If there is no makesample.bat or makesample.exe or makesample.com in the current directory, it will look in each of the folders listed in the path variable in turn. If it is none of them, it will give you the error message that you received.
To *look* at your path variable, you can usually just type "path" at the command line.
To *edit* it, the easiest way is usually through the Windows settings system. E.g., in WinNT, you start with the start menu -> settings -> control panel -> system -> environment then select "path" as the variable to edit, and edit the string that is displayed. In Win2000, it's the same, except that after system comes -> advanced -> environment variables. I've only looked at XP once, and do not have a machine to hand....
Source: email
Date: 10 Jun 2003
Keywords: EPIGRAPH
Query In the EEBO tagging cheat sheet, it says that <EPIGRAPH> can be used at the head or foot of a text division. However in the keyboarding instructions it only mentions use at the beginning of a division. Is it ok to use <EPIGRAPH> for e.g. a quote that appears at the very end of a text?
Answer I'm caught in another inconsistency. For what it's worth, the inconsistency seems to reside in TEI itself. The prose definition in P3 describes an epigraph as a quotation appearing 'at the start of a section or chapter.' On the other hand, the TEI dtd includes EPIGRAPH in the element class 'divbot' which is defined as containing 'elements which can occur at the end of a text division.' The same inconsistency persists in version P4 of the TEI.
Since there is no corresponding element for quotations at the end I'm inclined to go for symmetry and allow EPIGRAPHs at either top or bottom--in keeping with the TEI dtd, but in violation of the common meaning of the word and the TEI's prose description. I know that we've tagged closing quotations as EPIGRAPH before.
Source: email
Date: 23 Jul 2003
Keywords:
Every LIST should contain at least one ITEM.
I think I've modified the dtd now to make a list without items invalid.
Why can't the epigraphs on title pages be tagged as EPIGRAPH?
This follows from our original decision to make the title page simply another TYPE of DIV. Since title pages are just DIVs, we cannot allow EPIGRAPH anywhere on a title page without also allowing it anywhere in any DIV, which would be chaotic, confusing and very un-TEI-like. Only options (?) are: (a) create a special tag for t.p.s; (b) allow EPIGRAPH anywhere. I think for the moment we'll do neither.
Imprimaturs on title pages. How can their structure be tagged? Especially if they appear in the middle of the t.p. (not at the end, where they can simply be a subordinate DIV)?
<P><TEXT><BODY><DIV1 TYPE="imprimatur">
<P>Imprimatur.</P>
<CLOSER>
<DATELINE>In Aed. Lambeth.
<DATE>14 April 1611</DATE></DATELINE>
<SIGNED>J. J. Smith Episc. Cant.</SIGNED>
</CLOSER></DIV1></BODY></TEXT></P>
TYPE="imprimatur" vs. TYPE="license" vs. TYPE="approbation"
TYPE="imprimatur" is for ecclesiastical permission to publish, whether or not it contains the actual word "imprimatur." TYPE="license" is for secular permissions, licenses, instructions to publish, etc., including ambiguous cases. I.e., if you're not sure that it is an imprimatur call it a license.
TYPE="approbation" I've started to use (whether or not headed by a term like "Approbationes") for formal statements of approval of the content of a book that do not fall easily under imprimatur or license, e.g., "we the undersigned have examined this book on the duty of fishmongers and it appears to us that there is nothing in it contrary to sacred doctrine or honest living."
Is there a rule for where to break the Ps on the title page?
Aside from a general rule that the main purpose of the Ps on the t.p. is to break up the display into intelligible bits, no. Should there be one? Options: (b) always make the author statement a separate P; (c) always make subtitles separate Ps; (d) never separate the author from the title. Opinions?
The instructions say that MILESTONEs do not correspond with any structural division, but some things best tagged as MILESTONEs *do* correspond with structural divisions.
I will change the directions to say that milestones may but do not necessarily correspond to any structural division.
How can the reviewers discover info about books that are done, or about books and authors that have been selected?
Not easily. See (16) below.
Results of bibliographic search in current interface are not useful (e.g. search for Caxton and Bodleian in citation and examine results: cannot see where "Bodleian" appears in citation). Also, the display doesn't show <FIGURE> at all.
The trouble with the bib search seems to involve two problems: (1) there is no intermediate step available that allows you to see the 'hits' in context; and (2) only a part of the header is ever displayed, so if your search term found a match in the undisplayed portion of the header, you cannot see it. In this case, the full header looks like this:
<HEADER><FILEDESC>
<TITLESTMT>
<TITLE TYPE="245">In this tretyse that is cleped Gouernayle of helthe what is to be sayd wyth crystis helpe of some thynges that longen to bodily
helthe, ...</TITLE>
</TITLESTMT>
<EXTENT>20 600dpi TIFF G4 page images</EXTENT> <PUBLICATIONSTMT> <PUBLISHER>University of Michigan, Digital Library Production
Service</PUBLISHER>
<PUBPLACE>Ann Arbor, Michigan</PUBPLACE>
<DATE>2001</DATE>
<IDNO TYPE="marc">99845513</IDNO>
<IDNO TYPE="stc">STC (2nd ed.) 12138.</IDNO>
<IDNO TYPE="stc">Duff 165.</IDNO>
<IDNO TYPE="vid">10418</IDNO>
<IDNO TYPE="DLPS">A01993</IDNO>
<AVAILABILITY>
<P>This keyboarded and encoded edition of the work described above is
co-owned by
the institutions providing financial support to the Early English Books
Online Text
Creation Partnership. Searching, reading, printing, or downloading
EEBO-TCP texts is
reserved for the authorized users of these project partner institutions.
Permission must
be granted for subsequent distribution, in print or electronically, of
this text, in whole or in
part. Please contact project staff at eebotcp-info@umich.edu for further
information or
permissions.</P>
</AVAILABILITY></PUBLICATIONSTMT>
<SOURCEDESC>
<BIBLFULL>
<TITLESTMT>
<TITLE TYPE="245">In this tretyse that is cleped Gouernayle of helthe what is to be sayd wyth crystis helpe of some thynges that longen to bodily
helthe, ...</TITLE>
<TITLE TYPE="alt">Medicina stomachi.</TITLE>
<TITLE TYPE="alt">In this tretyse that is cleped Gouernayle of
helthe.</TITLE>
<TITLE TYPE="alt">Gouernayle of helthe.</TITLE>
<TITLE TYPE="alt">Governayle of helthe.</TITLE> <AUTHOR>Joannes, 14th century,</AUTHOR> <AUTHOR>Montagnana, Bartolomeo, fl. 1422-1460,</AUTHOR> <AUTHOR>Lydgate, John, 1370?-1451?.</AUTHOR> </TITLESTMT> <EXTENT>[36] p.</EXTENT> <PUBLICATIONSTMT><PUBPLACE>[Westminster :</PUBPLACE> <PUBLISHER>William Caxton,</PUBLISHER><DATE>1490?]</DATE>
</PUBLICATIONSTMT><NOTESSTMT><NOTE><P>The governal of health.</P></NOTE> <NOTE><P>The "Governayle of helthe" was originally written in Latin and is
attributed
both to Joannes de Burgundia and Bartolomeo Montagnana.</P></NOTE> <NOTE><P>Caption title; begins on A1r.</P></NOTE><NOTE> <P>Imprint conjectured from and publication date conjectured by
STC.</P></NOTE>
<NOTE><P>The verses at the end are a version of the John Lydgate's dietary
Medicina stomachi,.</P></NOTE>
<NOTE><P>Avii missigned Aiii.</P></NOTE><NOTE><P>Signatures: A-B
[C]2.</P></NOTE>
<NOTE><P>Reproduction of the original in the Bodleian
Library.</P></NOTE></NOTESSTMT>
</BIBLFULL>
</SOURCEDESC>
</FILEDESC>
<ENCODINGDESC><PROJECTDESC><P>Header created with script marc2tei.pl on
2001-12-12.</P>
</PROJECTDESC><EDITORIALDECL N="4"><P>Encoding has been done using the
recommendations
for Level 4 of the TEI in Libraries Guidelines. Digital page images are
linked to the text file.</P> </EDITORIALDECL></ENCODINGDESC><PROFILEDESC>
<TEXTCLASS>
<KEYWORDS><TERM>Hygiene -- Early works to 1800.</TERM> <TERM>Medicine -- Early works to 1800.</TERM></KEYWORDS> </TEXTCLASS></PROFILEDESC> </HEADER>
but the displayed part looks like this:
Title:
In this tretyse that is cleped Gouernayle of helthe what is to be sayd
wyth crystis helpe
of some thynges that longen to bodily helthe, ...
Availability:
This keyboarded and encoded edition of the work described above is
co-owned by the
institutions providing financial support to the Early English Books
Online Text Creation
Partnership. Searching, reading, printing, or downloading EEBO-TCP
texts is reserved for
the authorized users of these project partner institutions. Permission
must be granted for
subsequent distribution, in print or electronically, of this text, in
whole or in part. Please
contact project staff at eebotcp-info@umich.edu for further information
or permissions.
Print Source:
In this tretyse that is cleped Gouernayle of helthe what is to be sayd
wyth crystis helpe
of some thynges that longen to bodily helthe, ...
Medicina stomachi.
In this tretyse that is cleped Gouernayle of helthe.
Gouernayle of helthe.
Governayle of helthe.
Joannes, 14th century,
Montagnana, Bartolomeo, fl. 1422-1460,
Lydgate, John, 1370?-1451?.
[36] p.
[Westminster :
William Caxton,
1490?]
Many fields are not displayed at all, and those that are displayed largely lack any indication of the field that they come from. Both of these features are hard-wired into the TextClass interface. They can, however, be modified. We are starting a more formal list of suggestions for interface improvement, and this will go on it.
As for the non-display of FIGURE, I've put that on the list too.
Are Bibles being selected for EEBO? If so, which ones and why?
Yes, they are. I'll talk to John about which ones to select.
XMetaL can be taught to display tables, at least simple ones (without COLS or ROWS attributes). How?
These lines should be in the eebo2prf.css:
TABLE{
display: table;
}
ROW{
display: table-row;
}
CELL{
display: table-cell;
}
Unfortunately, this does nothing for tables of even moderate complexity. See (11) below.
Is there another way to facilitate editing tables?
I'm thinking about whether we can somehow use the true HTML table model within our dtd (instead of the TEI model). TEI and HTML are readily convertible at this point. Changing the vendors' dtd would be a nuisance; changing the data already delivered would be a nuisance. One option might be to add a add a third dtd for reviewers that uses the HTML model, and convert back into eebo2prf.dtd as part of the delivery process.
Less satisfactory, but much easier, would be a two-way temporary conversion that would allow people to edit tables in HTML, then convert them back to TEI for reinsertion in the document.
I've had a go at producing this, as follows:
It's a bit clumsy, but I just used it to fix two tables, so it can work.
There are at least some, and maybe many, bad tables in the texts already online--bad in the sense that they display incorrectly and even unintelligibly. How can we fix these and how can we prevent more bad tables from joining them?
Let me know when you spot one. I'll try to fix it. As for preventing them, all I can think of is to make it easier to view and edit tables while doing text review, see (11) above.
Should we be bolder in guessing than usual when proofing (and capturing) the title page?
yes. Try to be as complete as possible, even at the risk of introducing error. Make use of the bib record (citation) if necessary to help.
Should we distinguish publishers' and printers' lists of books with other things labeled 'Advertisement'?
Publishers' and printers' catalogues should be given TYPE="publisher's advertisement"; other kinds of thing headed "advertisement" should normally be given some other TYPE, e.g. TYPE="notice" or TYPE="publisher to the reader" (etc.).
Don't be afraid to use running title as clue to what kind of TYPE to assign to a division.
Can the EEBmgr database be made useful to staff?
Yes, probably, but only if staff are willing to specify the queries that they want to run, so that they can be added to the prepackaged 'reports' options.
In the meantime, I shall try to update the Oxford copy of EEBOdat more regularly, since EEBOdat now contains selection info. Unfortunately, neither EEBOdat nor EEBOmgr contain author info. For that, we would need to distribute a copy of John's selection spreadsheet or other selection documents. I'll ask John about this.
Source: email
Date: 26 Sep 2003
Keywords: OPENER, drama
Query Is there a consensus on how to tag 'spoken by' lines? Usually attached to the prologue or epilogue of a dramatic piece? Judging by the evidence, there is none: the examples below, plucked from the last couple of months' work, show use of <P> <STAGE> <HEAD> and <BYLINE>. I suppose <OPENER> is also possible. The person mentioned seems sometimes to be the character, sometimes the actor. Thoughts please.
Thoughts
John Latta:
What I do is this:
If the "Spoken by" is a line by itself, I make it a BYLINE.
If the "Spoken by" is a continuation of the title ("Epilogue Spoken by Mrs. Twitt") I make the whole thing a HEAD.
Jonathan Blaney:
I can't say this is what I actually do, but I think my preference would be for a <HEAD>-<STAGE> combo, unless there seemed to be a reason to put everything in the <HEAD>
Mona:
If the "spoken by..." is a separate line, I tag it as BYLINE, although I have suffered deep mental anguish wondering if it would be better tagged as STAGE. If the "spoken by..." is part of the same sentence, I just include it under HEAD (with no emotional distress to speak of).
Emma:
I only usually use <BYLINE> if it is a statement of authorship, eg. A poem "written by ...". In the context of a play, I'd use <STAGE> for spoken by, as it is a direction as to how the play is performed.
I'm not sure I've done that consistently in practice, but that's probably what I'd think if I encountered one. The "written for" line doesn't seem to me to be either byline or stage direction, so I might do <OPENER>, but then I'd probably worry about consistency. Would it be possible to do : <OPENER>Written for Mr. <HI>Hains</HI>, <STAGE>and spoken by him.</STAGE></OPENER>?
pfs:
Since we have some genuinely incompatible practice amongst us, some good things to be said on every side, and a need for some decision, I guess I have to make one. Namely:
(1) use <HEAD> as an acceptable fallback, especially if the 'spoken by...' portion is not typographically distinct from the rest of the <HEAD>; and (2) if there is reason (e.g., separate line or other visual distinction) to tag the line separately, prefer <STAGE> to <BYLINE>.
Source: email
Date: 26 Jan 2005
Keywords: structure, music, HEAD
Query In books of music, because heading, byline, opener, closer, and trailer information can occur among the lines of music proper, we have agreed to be a little loose with sequence, and 'pull' that information as needed to the top or bottom of the piece.
Also to allow 'generic' titles to serve as heads (e.g. "Ayre" "Songe" "Tune").
E.g.: from vid 95303/15 (&c.), the material captured as <HEAD> and <BYLINE> does not actually appear on the page till *after* the first line of music, but has been pulled up to the top in the transcription:
<DIV1 TYPE="musical pieces"> ...
<DIV2 TYPE="piece" N="29">
<HEAD>Ayre</HEAD>
<P><MILESTONE N="29">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music"></P>
</DIV2>
<DIV2 TYPE="piece" N="34">
<PB REF="16">
<HEAD>Ayre</HEAD>
<BYLINE>Mons^r. Peasable</BYLINE>
<P><MILESTONE N="34">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music"></P>
</DIV2>
<DIV2 TYPE="piece" N="48">
<PB REF="19">
<HEAD>Tom Iolly</HEAD>
<P><MILESTONE N="48"><GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music">
<GAP DESC="music"></P>
</DIV2>
Source: email
Date: 28 Jan 2005
Keywords: CLOSER, DATELINE
The name of the day belongs in <DATE> along with the number, e.g.
not this:
<DATELINE>Die Jovis <DATE>24. <HI>Octob.</HI> 1644. </DATE></DATELINE>
but this:
<DATELINE><DATE>Die Jovis 24. <HI>Octob.</HI> 1644. </DATE></DATELINE>
not this:
<DATELINE><HI>Die Lunae</HI>, <DATE>1. <HI>Feb.</HI> 1696.</DATE></DATELINE>
but this:
<DATELINE><DATE><HI>Die Lunae</HI>, 1. <HI>Feb.</HI> 1696.</DATE></DATELINE>
Source: notes file
Date: 28 Apr 2003
File name: S1446-5
Keywords: HI
<HI>s are wrong way round in the dedication - too lengthy to correct them.
PFS: about a half dozen global edits did the job: <HI> to {/HI} then </HI> to <HI> then {/HI} to </HI> then ^</HI> to nil then <HI> *$ to nil, then quick check.
Source: notes file
Date: 15 Oct 2002
File name: Wd849
Keywords: HI
When a whole line is in italics this has not been marked with <HI> even when clearly meant to be distinguished from rest of poem. Only changed these within the proofing sample.
PFS: I've gone and dded HI tags to all lines entirely in italics (or, in song, lines entirely in roman. Any highlighted items within these lines were treated as nested HIs.