TEI-MS: 8 - Additional Areas

8. ADDITIONAL AREAS

ADDITIONAL

<additional> groups information relating to curatorial issues, and to the bibliography and subject headings of the manuscript as a whole.

This element contains a number of subelements that have often been ignored in traditional printed catalogues of medieval manuscripts, hence their "additional" character. The five subelements may be grouped under an optional <head> but in fixed order: <adminInfo>, <surrogates>, <accMat>, <listBibl> and <keywords> (the last named element may occur more than once); none is required.

Examples:

<additional><head rend ="bold">Supplementary notices</head><adminInfo audience ="internal"><remarks>If Mr. Smythe-Pike comes to look at this manuscript again, stop all work at the reading room desk and observe him closely.</remarks></adminInfo><surrogates>Planning for digital images in process.</surrogates></additional>

<additional><keywords scheme="APIS"><list><item>subliterary</item></list></keywords></additional>

ADMINISTRATIVE INFORMATION

<adminInfo> batches information of interest primarily to the holding institution regarding metadata on the electronic description, and the availability and conservation of the manuscript.

The <adminInfo> element must contain either or any of a series of specialized subelements that are primarily used in-house by libraries. An "audience" attribute, with legal values of "internal" or "external" may be applied to the element overall (as well as to its individual subelements); the attribute will simplify masking or displaying certain parts of the description.

METADATA ABOUT THE RECORD

<recordHist> describes the source of a description of a manuscript and, if desired, successive revisions of the description, including the date of the change, the person(s) responsible for the change, and the nature of the change.

Three scenarios exist: 1) that the cataloguer is working ex novo to produce a traditional printed catalogue; 2) that the cataloguer/encoder is working ex novo to produce an electronic catalogue that will be made public without visible authorship; 3) that the encoder is working to produce an electronic version of an extant printed, and often authored, catalogue.

In the first scenario, the cataloguer may have limited use of the <recordHist> attribute: presumably the changes that are made to a description until it reaches print would be made directly to the text of the description; the cataloguer might use <adminInfo>’s <remarks> element more easily for these interim purposes.

In the second scenario, the <recordHist> element comes into its own, and should be used for the behind-the-scenes tracking of changes to the publically-viewed electronic catalogue. The changes themselves would be entered silently into the description, and only an assiduous and attentive reader might notice that today’s online version contains different information from yesterday’s version. This is the way OPAC systems function (MARC records in RLIN, OCLC, or a given library’s local on-line public access catalogue). Internally, however, consistent use of the <recordHist> element will allow a library to review numbers of changes, the names of those who made them, the nature of the change.

The third scenario is the most complex: the author of the printed catalogue has the responsibility for its intellectual content; issues of version control muddy the readers’ waters when print versions continue to circulate with one set of information, while an electronic version absorbs changes. The element <recordHist> serves the in-house tracking of changes, just as it did in the second scenario, but this time the changes to the public on-line version may not be made silently, but must contain explicit documentation to the same issues that <recordHist> has handled behind the scenes.

The changes to the OPAC description should be entered in the electronic record at their appropriate places, under <msContents> or <physDec> or <history>, etc., as if "footnotes"; the "new" cataloguer or authorized encoder is reminded of the necessity for documenting the date and source of the change, as well as its new intellectual content.

The <recordHist> element must contain <source>, which itself contains . The <source> subelement is intended to mark the original source of the cataloguing record, which might be a person’s name or initials or an abbreviated title; for example, "de Ricci" or "Ker, MMBL." Changes made to the electronic record at later moments are encoded via repeatable use of the standard TEI <change> element, with its three subelements: <date> for when the change was made; <respStmt> which is used for the name(s) of those responsible for the change, both intellectually and effectively to the record; <item> which explains, in as much or as little detail desired, the nature of the change. The <respStmt> element itself must contain at least one of a number of subelements, of which the most useful in this context is <name>, potentially repeated several times: for example, once for the person on whose authority the change in intellectual content is made (<name role = scholar>), once for the person who authorized the change in the record (name role = cataloguer), once for the person who concretely effected the change in the electronic record (<name role = inputter>). By contrast, the publically-viewable change need necessarily only contain the name of the person responsible for its intellectual content (i.e. the person who, in <recordHist>, is encoded as <name role = scholar>).

There is some ambiguity as to the use of <change><respStmt><resp> and <change><item>: the lowest level element in both sequences seems to be intended to signal the nature of the change. Since internally to <change>, both subelements <respStmt> and <item> are required, we propose that the function of <name> be assigned to <respStmt> and the function of noticing the change itself be assigned to <item> (that otherwise has no purpose).

All the above implies that <recordHist> will take advantage of its attribute: audience="internal."

Note: Both <source> and <change> mimic elements employed in the TEI header, respectively as <sourceDesc> and, internally to <revisionDesc>, the element <change>. The header will contain information about the entire electronic file of the catalogue overall, as opposed to the individual description of each manuscript, as discussed here.

Examples:

<additional><adminInfo><recordHist><source>De Ricci</source></recordHist>

[Note: The full bibliographic citation of De Ricci or a <ref> to it could be included in the electronic description under <additional><listBibl>.]

<additional><adminInfo audience ="internal"><recordHist><source>C.W.D., from the ms, February 1985</source><change><date>20 June 1997</date><respStmt><name role =scholar>Tilly de la Mare</name><name role = cataloguer>C. W. D.</name><name role = encoder>Sharon Goetz</name></respStmt><item>Attributed script to Antonio di Mario in conversation with C. W. D. </item></change></recordHist></adminInfo></additional>

[Note: The electronic record that previously read:

". . .Written in a <scriptTerm>humanistic script</scriptTerm> . . ."

would now read:

". . . Written in a <scriptTerm>humanist script</scriptTerm><note>The scribe’s name, Antonio di Mario, has now been supplied by Dr. A. C. de la Mare, June 1997.</note>

AVAILABILITY

<availability> supplies information about the availability of a manuscript, and about restrictions on its use.

Of the four subelements of <adminInfo>, the <availability> element is the most likely to apply the attribute/value of audience ="external" because the library and its readers are both well served by public knowledge of availabilty. The "status" attribute would presumably only be applied in the case of "status = restricted." Note the possibly related elements: <condition> in <physDesc> and <custodialHist> in <additional>’s <adminInfo>.

Examples:

<availability>On deposit at the Cambridge University Library.</availability>

<availability>Viewed by appointment only, to be arranged with curator.</availability>

<availability>In conservation, Jan. – Mar., 2002. On loan to the Bayerische Staatsbibliothek, April – July, 2002.</availability>

CONSERVATION HISTORY

<custodialHist> records the conservation history of a manuscript.

<custEvent> describes a single event in the conservation history of a manuscript.

Internally, <custodialHist> requires either any number of elements or any number of <custEvent> elements (and this latter requires an internal ), but not a mixture of both and <custEvent>. The subelement <custEvent> demarcates specific instances in which conservation work has taken place; it has numerous attributes, of optional use.

Examples:

<custodialHist>Sarebbe da rilegare quando avremo qualcuno che ce lo faccia (e i soldi per pagarlo).</custodialHist>

<custodialHist><custEvent>Conservator says leaves cannot be flattened without loss of pigment. Feb. 1998.</custEvent></custodialHist></adminInfo></additional>

IN-HOUSE NOTES

<remarks> contains informal notes about a manuscript.

The element serves the purpose of an ad hoc scratch pad where the cataloguer can jot reminders, questions, worries about the manuscript and about the cataloguing process on the manuscript. The element must contain at least one . While there may occasionally be reason to display the remarks publically, the "audience" attribute will most frequently be set to "internal."

Examples:

<remarks audience ="internal">Re ff. 33-36v: According to Leroquais, the feast of Corpus Christi with its octave was instituted for Franciscans in 1319; the hymn here is the standard Tantum ergo.

Re a photo: yes, do one, since the ms is signed and dated; how about f. 7v? (nice cadelled initials, and f. 18 with Clare has already been reproduced elsewhere).</remarks>

SURROGATES

<surrogates> contains information about photographic and / or digital surrogates of the manuscript.

The <surrogates> element occurs internally to the <additional> element; <surrogates> must contain . Libraries might wish to use this element to signal the existence of facsimiles, microfilm print masters, negatives, or digital images with an appropriate <bibl> or <idno> element within <surrogates>’s . If desired, published facsimiles of a manuscript could, instead, be encoded by means of the <bibl> or <listBibl> element, internally to <msItem>. The advantage to placing such information in the <surrogates> element is that all reproductions from one manuscript may thus be encoded as a group, and with comments.

Examples:

<additional><surrogates>Master Neg. 37-628990A. for entire text, including flyleaves.</surrogates></additional>

<additional><surrogates><bibl><title>The Ellesmere Chaucer Reproduced in Facsimile</title> with introduction by A. Egerton (Manchester, University Press 1911)</bibl>reproducing by collotype, generally uncolored, but in color for the 71 leaves with borders.Full set of detail 4 x 5 transparencies of the pilgrims. 12-slide packages available in the Gift Shop.</surrogates></additional>

ACCOMPANYING MATERIALS

<accMat> provides encoding for physically separate items that are associated with the manuscript.

The <accMat> element occurs internally to the <additional> element; <accMat> must contain . Its "type" attribute allows for further characterization of the physical item, assuming that the item is of sufficiently common nature as to expect a semi-standard value to describe it.

This would be the case with traditional library materials such as a letter or a bound extract of a relevant article, but less so with items that fall into the category of realia, such as a lock of hair, or a stone from Joan of Arc’s prison (unless, of course, the encoding read: type = "realia").

Note: This element is not intended to describe other medieval or renaissance manuscripts that have become an integral part of the manuscript under description, whether as flyleaves, binding material, or as completely separate codices bound together. This situation should be handled via the <msPart> element.

Examples:

<additional><accMat type ="realia">Zucchetto di Pio IX, in apposita cassetta.</accMat></additional>

<additional><accMat>Small stone from the prison of Joan of Arc (via the base of the Anna Hyatt Huntington statute of Joan of Arc on Riverside Drive).</accMat></additional>

<additional><accMat>Collation of the text against the other two manuscripts, shelved with the Babbitt papers.</accMat></additional>

<additional><accMat>Bibliographic folder.</accMat></additional>

BIBLIOGRAPHY

<listBibl> contains a list of bibliographic citations of any kind.

This standard TEI element occurs in <msItem> as well as in <additional>; use of the element in <msItem> is appropriate for bibliography that pertains directly to the one text, while the <listBibl> element in <additional> may be reserved for bibliographic citations referring to the manuscript as a whole.

KEYWORDS

<keywords> contains a list of keywords or phrases identifying the topic or nature of a text.

In the present context, this element is used internally to <msContents> (as one of its subelements) and internally to <additional> (necessarily at the end of its subelements) with the same content and the same function: to provide subject headings, which may thus be considered as reflecting specifically the subjects of the manuscript’s text, or the subjects of the manuscript overall. The "scheme" attribute is required, to identify the controlled vocabulary within which the set of keywords is defined. The various subject headings will themselves be <item>s within a <list>.

In both locations, <keywords> can be used more than once; this is a provision for adopting more than one scheme at the same time.

Examples:

<msContents><keywords scheme = LCSH><list><item>XXXXXXX</item> <item>YYYYYYYYYYY</item></list></keywords>

<additional><keywords scheme = DS><list><item>liturgical</item></list></keywords>