Casebooks

Metadata (information about the electronic file and its contents) is recorded in a <teiHeader> element. This has four components, <fileDesc>, <encodingDesc>, <profileDesc> and <revisionDesc> (always in that order).

I. <fileDesc>

describes the electronic file and its source and consists of the following elements:

1) <titleStmt>, which contains only the element <title>. Once files have been made available online, this is the word CASE followed immediately by the number assigned in the pilot project or subsequently. However, this has no real significance beyond being a unique number by which to identify the case. If another case turns up or we decide that what had been recorded as one case is really two, the new file becomes CASE[whatever the next number in the sequence is at the time]. If we decide that what had been recorded as two cases is really only one, one of the titles simply disappears from the sequence.

Provisional titles are assigned to transcriptions in progress, based on the call number, folio, and sequence on the page (e.g. MS_Ashmole_237-f0153r-3 is the third case (reading first down the left column and then down the right, irrespective of whether or not this equates to the chronological order of the entries) on f. 153r of MS Ashmole 237). These provisional titles are then auto-converted to arbitrary but unique CASE numbers once a given volume has been completed.

2) <publicationStmt>, which contains <publisher> (The Casebooks Project), <pubPlace> (Cambridge) and <date>, with the date expressed in ISO style (yyyy-mm-dd) as the @when value of <date> and spelled out using the formula '01 April 2010' as the content of <date>. The content and @when values of <date> will be auto-generated as files are released online.

3) <notesStmt> (optional), which contains one or more <note>s, which in turn may contain either text or <p> (though it seems unlikely that a note here will run to more than one paragraph: if it does it should probably be two or more <note>s). These notes each take one of the @type values defined in the entry for <note> in the Element Set (and, optionally, a @resp value of # and the relevant editor's @xml:id value if he or she wishes to claim/admit authorship) and can be used to supply more detailed information about the source document or particular problems associated with its transcription, e.g. 'This aborted entry has been given an approximate time and a date based on its position in the manuscript', 'This entry is a note inserted between the question and chart of CASE3884, and the date and time are taken from that entry', 'The manuscript is water-damaged here'.

Where such references to other entries are included, a link should be provided by means of a <ref> element as explained in the entry for <ref> in the Element Set.

There can be no hard and fast rules about what can or cannot be expressed in <notesStmt>, whether in terms of describing the source document itself, its content, or the interpretation of that content. So far as possible, information about both the document itself and its contents should be recorded in the tagging rather than the <notesStmt> but this provides a useful fallback option for at least provisionally recording any supplementary data.

4) <sourceDesc>, consisting of the following:

<bibl type="positionOnPage">: the content of this element records the location of the entry on the page or pages it occupies. Each page is regarded as consisting of up to nine 'zones', designated uL, uC, uR, mL, mC, mR, bL, bC, bR. Here the lower case letters stand for 'upper', 'middle', 'bottom', and the upper case ones for 'left' 'centre' and 'right'. In the majority of cases, no more than four zones are encountered on a given page (upper left, upper right, bottom left and bottom right), but especially in Napier's casebooks, the layouts are quite often more complex than this, especially when he or one of his assistants starts dividing a page (or part of it) into three columns. Hence, uC, mC and bC will be needed relatively rarely, but often enough to make them worth having, and it is not at all uncommon for a given column to be divided into more than two rows.

The content of <bibl type="positionOnPage"> normally refers to the zone in which the record begins, irrespective of whether or not it then proceeds into a lower zone (e.g. from uL to mL or from uR directly into bR). Geometric precision is not the aim: the purpose of this element is to give a general idea of whereabouts on the image to find the entry in question, relative to the other entries on that page. As a rule of thumb, if there are (say) two entries in the left column and three in the right, they can be regarded as uL, bL, uR, mR and bR. In entries on the more complex and chaotic pages, or where there are more than three entries in a given column, the precise content of this element is a matter of editorial judgment,

There are, however, the further options of uS, mS and bS (upper spanning, middle spanning and bottom spanning) for entries that run the full width of the page, for instance CASE23640. This can not have its <bibl type="positionOnPage"> defined as 'bL, bR' as this would mean that it consists of one column in the bottom left and another in the bottom right, whereas it runs seamlessly across all the 'bottom' zones of the page, with no column break(s): this is expressed by 'bS'.

If more than one case begins in the same zone, they can be distinguished as (for instance) uR-1, uR-2, uR-3 etc - following the order the entries were written in (or what seems the most plausible order if there is no concrete evidence).

If, however, an entry is divided by a column break or jumps from one part of the page to another, this needs to be spelled out. Both practitioners quite often begin a case in bL and finish it in bR (i.e. they have divided the page horizontally as well as vertically). In such cases, it is sufficient to record <bibl type="positionOnPage"> as 'bL, bR' (or 'bS' if there is no column break). Napier in particular is prone to scatter the component parts of a given entry around a page in a counter-intuitive order, but provided there is only one page involved, the same procedure can be used, e.g. '<bibl type="positionOnPage">uR-1, bR, bL</bibl>' (where the entry is interrupted by other entries or parts of entries in uR-2 and mR, and it jumps from the right to the left column towards the end).

If the entry occupies more than one page (e.g. CASE1387, which begins in zone bR of MS Ashmole 226 f. 42r and for some reason continues in zone bR of MS Ashmole 226 f. 46r), this needs to be spelled out as '<bibl type="positionOnPage">f. 42r/bR, f. 46r/bR</bibl>'. Similarly, if an entry occupies more than one page and more than one column on one or more of those pages, each new column needs its own full reference, e.g. '<bibl type="positionOnPage">f. 50r/bL, f. 50r/uR, f. 51v/uL</bibl>'.

An <altIdentifier> is also provided (automatically, at the time of the file's creation) to indicate that, for instance, the shelfmark 'MS Ashmole 182' equates to 'Napier volume 2' in Casebooks terminology.

b) <msDesc>, which contains:

i) <msIdentifier>, which in turn contains <country>, <settlement>, <repository> and <idno>. The attribute values (if needed) and content of these elements are auto-generated from existing project documentation, but if component parts of the entry appear on more than one page the content of <idno> requires handcrafting.

The content of <idno> consists of the manuscript number in question and the number(s) of the page(s) on which the entry appears, e.g. 'MS Ashmole 207, f. 104v'. If the manuscript has been paginated rather than foliated, the original page numbers should be cited here, preceded by 'p.' rather than 'f.'.

If the entry runs to more than one page and is in a logical, uninterrupted sequence, the relevant pages should be cited as a range, on one of the following models:

• f. 246r-v (singular 'f' since only one folio is involved, albeit both sides of it)
• ff. 246v-247r
• pp. 246-247

If the entry runs to more than one page and is not in a logical sequence, e.g. it proceeds backwards from f. 246v to f. 246r, or it leapfrogs a page somewhere in the middle, the page or folio numbers given in <idno> should be presented in the order they were intended to be read in (or a best guess at the order they were intended to be read in) and separated by commas, e.g. 'f. 106v, f. 109r'.

ii) <msContents>. This contains <msItem>, which in turn contains <locus> and <title>. These elements, too, are auto-generated from existing project documentation. However, the @from and @to values of <locus> require handcrafting if the component parts of an entry appear on more than one page.

The @from and @to values of <locus> are normally both the same and are the page or folio number in question rendered as a 4-digit string with leading zeros if necessary, and with a suffix of 'r' or 'v' if the document is foliated rather than paginated, e.g. '<locus from="0104v" to="0104v"/>' for an entry in a foliated document, or '<locus from="0104" to="0104"/>' for an entry in a paginated document.

If the entry runs to more than one page and is in a logical, uninterrupted sequence, the @from value is that of the page it begins on and the @to value that of the page it ends on. If it runs to more than one page and is not in a logical sequence, it needs two or more <locus> elements, each defining one of the pages, listed in (what is presumed to be) the intended reading order (see under <locus> in the Element Set for examples).

There are some cases in which the foliation or pagination is itself illogical, e.g. there is no f. 50, there are two f. 50s, or there is an unnumbered folio between f. 50 and f. 51. In the first of these cases, the omitted folio number can simply be omitted from the transcribed texts (i.e. there will be no entries with 'f. 50r' or 'f. 50v' as the content of <idno>, or f0050r or f0050v as the @from or @to value of <locus>). In the latter two, the second page or folio takes the number of the first one with a capital A appended to it (e.g. 'f. 50Ar' or 'p. 50A'). If there are more than two pages or folios with the same number, or more than one unnumbered page or folio between consecutively numbered pages or folios, the second misnumbered or unnumbered page or folio takes the suffix B, and so forth.

II. <encodingDesc>

serves, for Casebooks purposes, solely as a container for <samplingDecl>, which in turn contains (in <p>) a brief, standardised, natural-language statement of the sampling policy followed in the transcription. In the overwhelming majority of cases, this means transcribing only the question section of the entry and merely recording the presence of other sections such as judgment, treatment, urine note etc. In these cases, the appropriate <samplingDecl> will be entered automatically. Where, however, these other sections have been transcribed for whatever reason, or where there are no other sections apart from charts and/or astrological notes, a different <samplingDecl> is called for. All transcribers need to do in such instances is to add an <encodingDesc> between <fileDesc> and <profileDesc>, containing only the entity &wholeEntry;, from which the appropriate declaration will be generated automatically.

III. <profileDesc>

describes the contents of the file and of its source. This is the most important part of the file, and the source for data harvesting. It consists of the following:

1) <handNotes> (mandatory). This in turn contains one or more <handNote> elements, each with a @sameAs value of #sforman or #rnapier, or # followed by the @xml:id value of the scribe as declared in <listPerson>. These point to the <person>(s) in whose hand(s) the transcribed text is written. Hands that only feature in the untranscribed portions should not be recorded in <handNotes>, though it is helpful to note their presence in comment tags. The content of <handNote> is simply the scribe's identity in natural language ('Simon Forman', 'Richard Napier', 'Gerence James', 'Unidentified Hand', or whatever appellation has been decided on for distinguishable but as yet unidentified scribes).

2) <langUsage> (mandatory except in the few cases where the entry has no textual component at all, e.g. it consists solely of a chart). This contains one or more <language> elements, each with the @ident value en, la, el, he, fr or und (English, Latin, Greek, Hebrew, French, Undetermined). 'Undetermined' is for entries that did contain text originally but have been damaged to such an extent that it is impossible to determine what language it was in.

Only the languages that feature in the transcription should be listed, not those that appear only in other, untranscribed, parts of the document. Where there is more than one language they should be listed in order of priority: e.g. if the document is primarily in Latin with a few words of English, <language ident="la"> should be the first element in <langUsage>; if the contrary, <language ident="en"> should be.

The various abbreviations of 'ante meridiem', 'in meridie' and 'post meridiem' are being normalised anyway and do not count as 'Latin' for <langUsage> purposes if they occur in otherwise English text. Forman's idiosyncratic term 'questo' appears to mean either 'question' or 'quaestio' according to context, and does not need to be distinguished as 'foreign' in either case. The same goes for 'Anno', 'stat' (meaning either 'state' or [in Latin] 'status'), and for his even more idiosyncratic 'halk/halek' (meaning 'has/have/had sex with'), which may occur in either language.

For guidance on how to deal with language changes within the body text, see the Content tagging section of the Guidelines.

3) <particDesc> (participant description: mandatory). 'Participant' is here defined very broadly, meaning the practitioner(s), the scribe(s) (if relevant), and anyone mentioned in the transcribed portion of the entry, even if they do not, strictly speaking, participate in the consultation. It may also, as explained below, include people mentioned only in the untranscribed portion of the entry if they seem relevant.

If, as quite often happens in Napier's records, it appears that a locum or assistant was standing in for the astrologer and delivering judgments, treatments etc. without the master's supervision, the locum or assistant should be treated as practitioner and Forman or Napier should be omitted entirely from <particDesc> The @name value of <cb:practice>, however, remains forman or napier. In some cases, the question of whether the person who wrote the entry really was acting on his own initiative or merely taking dictation is a matter of editorial judgment, but there are a number of entries in which it is objectively demonstrable that Napier had left his practice in the hands of an assistant.

<particDesc> contains the mandatory <listPerson>, which consists of the following:

a) a sequence of <person> (and, if appropriate, <org> and/or <personGrp>) elements, each of which has a mandatory @xml:id. The @xml:id value for Forman is always sforman, for Napier rnapier, for Gerence James gjames and for Sir Richard Napier srnapier. Values for other identifiable (or at least recognisable) scribes or practitioners will be added as need arises. Completely unidentified scribes take the @xml:id value unknown (or unknown1, unknown2 etc. should there ever turn out to be more than one unidentified hand in a given entry). In all other cases apart from the editors, the @xml:id value for an individual person is generated, if possible, from the person's initials (in lower case), e.g. rc for Richard Carter. If only one initial is known, a one-letter value is permissible. If this leads to duplication, numbers can be appended to the letters to differentiate them, e.g. ar1, ar2.

People who are referred to in the record solely by a <roleName> such as 'Bishop of London' or 'Lady Sanquhar' (where 'Sanquhar' is a title, not a surname, as in the case of Anne Crichton, Lady Sanquhar) should be given an @xml:id value of "person1" (or "person2", "person3" etc. should more than one such person appear in a given entry).

If there is no indication whatsoever of any other participant's name and no means of inferring it from the judgment or other contextual evidence, he or she should be entered as <person xml:id="anon"> (e.g. CASE1173 where the question reads only 'At 3 post m the first feb &Tuesday; 1597', and no judgment is given). If there are two or more completely anonymous but obviously distinct persons involved, they should be designated anon1, anon2 etc.

If people who have some fairly obvious relevance to the case are specified only in the untranscribed part of the document, they should be listed in the header with the relevant <person> element taking an @evidence value of internal. People mentioned only in passing in the untranscribed portion can be ignored in the header. The question of whether or not people mentioned in the untranscribed portion are in fact relevant is a matter of editorial judgment, but suspected thieves or witches, for instance, should certainly be included and listed in <cb:consultation> as <cb:object>s (see below). Other people referred to by name or occupation in the untranscribed section should also be included (though not necessarily ascribed a role), on the grounds that this is surely concrete information provided by the querent rather than something the practitioner believed he had read in the stars. Thus, 'shee loved on that did deceive her' does not warrant the inclusion of an anonymous male participant, but 'shee loved John Smith that did deceive her' or 'shee loved a baker of Stony Stratford that did deceive her' does warrant the inclusion of John Smith or an anonymous male baker in <particDesc> (it seems reasonable to assume, when dealing with texts from this period, that same-sex romantic or sexual partners would not have been referred to as such during a consultation). There are even a few cases in which a querent or subject is mentioned only in the untranscribed section, in which case <cb:querent> and/or <cb:subject> should also take an @evidence value of internal.

There will always be at least one <person>, viz. the practitioner (who may also be the querent and may also be the subject).

<person> contains as many of the following as are applicable:

i) <persName>, which in turn contains as many as applicable of <roleName>, <forename>, <surname>, <genName>, <nameLink>, <addName>, <name>.

<roleName> covers appellations such as 'Mr', 'Mrs', 'Sir', 'Goodwife', or other formulae besides personal names, family relations (e.g. 'Smiths cosen') or job titles used to specify a person's identity. E.g.

• <persName><roleName>Mr</roleName> <forename>John</forename> <surname>Perkins</surname></persName>
• <persName><roleName>Lady</roleName> <surname>Throckmorton</surname></persName>

Titular role names such as 'Lord', 'Mrs', 'Alderman', 'Dr', 'Goodwife/Goody' should be placed first within <persName>, while more descriptive ones (e.g. 'Bishop of London') should be placed last. In most cases this reflects the way in which they are presented in the original.

There are cases in which it is debatable whether a given formulation counts as a <roleName> or not. Less clear-cut examples will have to be resolved by editorial consultation. Aristocratic role names can be particularly problematic in this respect: for instance, the regular client Napier refers to as 'Lady Zancher' turns out to be the historically attested Anne Crichton, nee Fermor, Lady Sanquhar, and should be given the <roleName> 'Lady Sanquhar' if none of her alternative appellations is mentioned in the transcribed part of the entry.

Role names given in Latin in the original should be translated into English in the header. This is a fairly rare occurrence usually involving 'Domina' or 'Dominus', meaning (confusingly) either 'Mrs/Mr' or 'Lady/Lord', but it is normally possible to determine either from external evidence or from elsewhere in the casebooks which translation is to be preferred.

Where variant forms of some or all of a person's name are specified, more than one <forename> and/or <surname> can be used, with whatever is considered to be the less canonical version taking the @type value alternate. E.g.

<persName><forename>Edward</forename> <surname>Mabsden</surname> <surname type="alternate">Butcher</surname></persName>

for 'Edward Mabsden alias butcher' (CASE1784).

If the entire name consists of two alternative but not mutually exclusive formulations, e.g. 'mres Elis: Tyrrle the young Lady Tyrle' (CASE30263), two <persName> elements should be given, without attributes:

<persName><roleName>Mrs</roleName> <forename>Elizabeth</forename> <surname>Tyrrell</surname></persName> <persName><genName>Young</genName> <roleName>Lady</roleName> <surname>Tyrrell</surname></persName>

In most cases, where alternative surnames are recorded in the source text, they are the maiden, married, or previous married names of female participants. Normally, one of the alternatives is referred to in the record as 'alias' or 'otherwise', with no indication of the status of either name. In the comparatively rare cases where the status of such names can be at least conjecturally determined, the variant surnames can each take the @type values maiden or married.

<surname> may also take the @type value adopted in the extremely rare event of someone being explicitly described as having adopted a different surname (as opposed to acquiring one by marriage or being referred to under a false name).

The basis on which a name has been determined where none is explicitly stated in the document may be clarified by applying @evidence values of internal, external or inferred. internal means that it has been taken from the untranscribed part of the entry in question. external means that it has been taken from a source external to the entry in question (including elsewhere in the casebooks). inferred applies to cases such as assuming that an unnamed wife has the same surname as her husband, an unnamed father has the same surname as his 5-year-old daughter, etc.

@cert values of high, medium or low may also be applied to any or all of <persName>, <forename> and <surname> to express the editor's confidence about the content of the element in question. For instance, if an entry clearly states a woman's surname and includes a mention of her husband, the husband's surname may be inferred to be the same as the wife's, but only (in the absence of any evidence that the name in question is the wife's married name) with a medium level of certainty, as it is not at all uncommon at this period for married women to be referred to by their maiden names.

There are, moreover, a few cases in which it appears that the practitioner or the querent has given a false name for one of the participants. This applies mainly to entries Napier has copied from Forman's records, in which the case details are virtually identical in all respects except the name of the querent and/or subject. There are also cases (e.g. 14425, 14473, 20540, 20541, 20615) in which the querent demonstrably gives a false name to the person he or she is asking about. In such cases, the relevant part(s) of the name should be given the @type value deckname.

In the case of Decknamen, a @resp attribute may also be applied to resolve any ambiguity as to who is responsible for the subterfuge, e.g. a @resp value of #rnapier if Napier is falsifying the name, a @resp value of #t if (as in the cases cited above) Mr Trendall is asking about a subject under a cover name, or values of # plus the @xml:id value of the person in question for self-conferred Decknamen.

There are also very occasional instances of two variant spellings of a forename or surname being explicitly presented as alternatives, as in CASE2937, for 'Richard Gore (Cuer)'. (If the name is simply spelled two different ways at different points in the entry, it should be regularised in the header, but here Forman is clearly going out of his way to point out that these two very variant spellings do indeed mean the same person.) In such cases, the second option takes the @type value variant.

Nicknames, if identifiable as such, can be dealt with by applying the @type value nickname to <forename>, <surname> or <name>.

In other cases of people being given variant designations that have nothing to do (or nothing obviously to do) with their marital status, the relevant element should also be given the @type value alternate.

If there is no evidence to the contrary, where someone is identified in the records as 'X alias Y', Y should be considered the 'alternate' name. Note that 'alias' in 16/17th century English is used much more loosely than in modern English and does not necessarily imply disguise or subterfuge, being more akin to the modern 'aka'.

<genName> contains standard formulae used to distinguish between people who otherwise have the same name, e.g.

• <persName><roleName>Mrs</roleName> <forename>Elizabeth</forename> <surname>Shaw</surname> <genName>junior</genName></persName>
• <persName><genName>Old</genName> <forename>Anne</forename> <surname>Emerson</surname></persName>

From currently available evidence, it seems that Napier consistently uses 'old' and 'young', in formulae such as 'Old Mr Smith' or 'Young Mrs Blundell', as <genName>s rather than simple adjectives.

<nameLink> covers connecting (usually possessive) prepositions within proper names, such as 'ap', 'van', 'de'. There are frequently inconsistencies in the source as to whether or not these should be capitalised, and as to whether or not they should be regarded as part of the surname (van Dyck, Vandyck?). There are also instances of their being mutilated by anglicisation, e.g. 'Fan Hoeck'. In the material under consideration here, however, these are fairly rare, so the precise rendition can be sorted out on a case-by-case basis.

<addName> (which is used very rarely) can be applied to soubriquets (typically nominal phrases) that defy more precise classification, e.g. 'The Grand Turk' or 'Deaf Alice' (see the entry for <addName> in the Element Set).

<name> can be used in cases where it is unclear whether the name given is a forename or surname (or, indeed, nickname or anything else).

If some or all of a person's name is not explicitly stated, or is given in code, or is drastically abbreviated, but can be deduced from external evidence, <persName>, <forename> and <surname> (but not, for some reason, <name> or <genName>) can all take an @evidence value of external and, if there is any doubt about the identification, a @cert value of high, medium or low. If all or part of the name is given only in one of the untranscribed sections of the entry in question, @evidence takes the value internal.

The proper nouns in <persName> should be given in regularised forms as established on the project's wiki page.

If any of the components of <persName> is unclear or only partially legible from the available image, whatever is legible or conjecturable should still be recorded in the header, with the same tags as are applied in the text, e.g. '<persName><roleName>Mr</roleName> <forename>John</forename> <surname>V<gap extent="1" unit="chars" reason="hand"/><unclear cert="low" reason="hand">own</unclear></surname></persName>' (CASE23404). In such a case, regularisation is obviously impossible, but only completely indecipherable components of <persName> should be omitted from the header.

ii) <sex>, which may be '<sex value="1">M</sex>', '<sex value="2">F</sex>' or '<sex value="0">U</sex>' (unknown). This can also have a @cert value of high, medium or low if sex can be inferred but with less than total confidence, and an @evidence value of conjecture, external or internal to indicate the grounds on which sex has been determined or conjectured if this is not evident from the transcribed part of the entry. <sex> should always be included, even if the @value value is 0 (unknown), as this provides a means of checking that the gender really is unknown as opposed to the transcriber's having forgotten to record it. The gender even of wholly anonymous participants can quite often be deduced from personal pronouns, Latin grammar or other internal evidence.

iii) <age>, if one is specified in the source document, with a numerical @value value (in years by default) repeated as the content, e.g. '<age value="12">12</age>'. This can also take a @precision value of high, medium or low if the age is explicitly given as approximate, e.g. 'of about 20 yeres'. However, it can be taken as read that almost all ages are guesses or approximations (if not outright lies by the querent). Where a range is given, e.g 'of between 40 and 50 yeres', 'of more then sixty', @value can be replaced by @atLeast and/or @atMost. Where the age of small children is given in days, weeks or months rather than years, in fractions of years, or in a mixture of temporal units, a @unit value can be invoked: '<age value="6" unit="months">6 months</age>', '<age value="30" unit="months">2 and a half years</age>'. In such cases, the content of <age> should be a modernised form or English translation of whatever formulation is used in the original.

In the case of ranges, the content of <age> should be the upper and lower limits of the range (if both are available), linked by a hyphen and with no spaces. E.g., taking the hypothetical example above, '<age atLeast="40" atMost="50">40-50</age>'. Where only one limit is known, the following models can be used:

• <age atLeast="61">over 60</age>
• <age atMost="19">under 20</age>

Or the content may use the formulae 'at least' and/or 'at most' if it seems more appropriate in natural language. This applies especially in the case of inferred ages of young children, e.g. a child is known to be either the same age as or at least nine months older than its one-month-old sibling, in which case the content may read 'at least 1 month'. (In such a case it would in principle be feasible to describe the child as either 1 month or at least 10 months old, discounting the possibility of premature birth, but it hardly seems worth it.)

@atLeast and @atMost can also be used if, for instance, the second digit of someone's age is lost or illegible. Matters become more complicated if the first digit is lost, so that '<gap unit="chars" extent="1">6' may mean 16, 26, 36, etc. up to 96 (it seems reasonable to suppose that none of the people mentioned in the casebooks lived to much more than 100, though centegenarians are not unknown). In such cases, multiple <age>s can be given, each with an @xml:id value of age1, age2 etc. and an @exclude value pointing to all the incompatible alternatives, on this model (assuming for brevity's sake that the person in question is known to be under 40):

• <age xml:id="age1" value="16" exclude="#age2 #age3">16</age>
• <age xml:id="age2" value="26" exclude="#age1 #age3">26</age>
• <age xml:id="age3" value="36" exclude="#age1 #age2">36</age>

The same procedure should be adopted if two or more conflicting ages for a given person are specified in the same entry and there is no evidence as to which should be preferred or which represents the practitioner's last thought on the matter.

iv) <residence>. If anyone's address is specified (however vaguely) in the transcribed part of the entry, it should be marked up in the body text with <rs type="address" xml:id="address1"> (or @xml:id values of address1, address2, address3 etc. if more than one address is mentioned in a given case). Any terminal punctuation should be placed after the <rs> tag, though medial punctuation may be included within it. The <residence> element in <person> then takes the @sameAs value of # plus the @xml:id value of the relevant <rs>. Obviously, more than one person may live at a given address, and if there are good reasons for supposing two or more <person>s to have the same address, they can (and should) have the same <residence sameAs> value - even if this is not explicitly stated in the text of the document. E.g. if there is no evidence to the contrary, it seems reasonable to assume that children under ten probably live with their parent(s), spouses probably live together, servants probably live with their employers and vice versa. In such cases, <residence> takes an @evidence value of inferred. Where there are grounds for doubt, @cert can be invoked.

<residence> also takes, invariably, a @key value of databaseNormalizedIDKey. This is a placeholder that will be converted to something more meaningful once a proper database of all the addresses mentioned in the casebooks has been constructed.

In the very rare cases in which residence can be determined from the untranscribed part of the entry, <residence> takes an @evidence value of internal and as content a literal transcription of the address as it appears in the source (see the entry for <residence> in the Element Set for an example).

Where former places of residence are mentioned in the text, these should be marked up in the same way but with <residence> taking a @notAfter ISO value of the last plausible date at which it might have been a current residence (the day before the consultation if no other evidence is available) or a @to value of the date on which it ceased to be one if this can be ascertained.

v) <birth>. If a date (and/or time, and/or place) of birth is specified (typically, but by no means exclusively, in nativities), this should include <date>, <time> and/or <placeName>. <date> and <time> take @when (or @notBefore/@notAfter) ISO values. <placeName> takes a @sameAs value of # followed by the @xml:id of the relevant <rs type="address"> or <placeName> as marked up in the body text. Or if the place name does not occur in the transcribed part of the text, <placeName> takes a literal transcription of the relevant text as its content (see the example given under <death> in the Element Set: at the time of writing, this situation has never arisen in the context of <birth>).

Where two (or more) mutually exclusive dates or times of birth are given in the text, both or all should be recorded in the header, each with an @xml:id value of date1, date2 (etc.) or time1, time2 (etc.), and an @exclude value pointing to the incompatible alternative(s), on the same principle as incompatible <age>s.

The same applies if a single date is given in the text but there are two or more plausible interpretations of it (e.g. 'Friday 13 July' if the 13 July in question was a Thursday), and it is not possible to establish which option is to be preferred.

The same mechanism can be applied to ambiguous or mutually contradictory dates for <death> or <event>.

<date> may also take an @n value of Monday, Tuesday etc. if the day of the week is (correctly) specified in the text, but if not there seems little if any point in supplying this from external sources.

Where any of this data occurs in an untranscribed part of the document, either <birth> itself or any or all of its children should take an @evidence value of internal. Where a date or date range (typically of birth but sometimes of other things) has been worked out by deciphering one of Napier's characteristic circumlocutions such as 'Thursday a sennet before St Peters', <date> takes an @evidence value of "extrapolated".

In the not unusual event that the date of birth given in the entry is incompatible with the age stated in the entry, this can be mentioned in a comment tag, but the data should be left as the source presents them. If the discrepancy is wild enough we may see fit to mention it in the <notesStmt>, but since the value of <age> is generally assumed to be approximate anyway, this does not normally merit any public comment.

In nativities (and, mercifully, only in nativities), Napier quite often uses what looks to modern eyes like the 24-hour clock for times of birth. For instance, in MS Ashmole 224, f. 151r, he casts a nativity for his nephew's wife Lady Frances Napier, stating that she was born at '16 p m' on Tuesday 18 October 1602. 18 October 1602 was a Monday, and it is clear from other nativities for the same person that he in fact means 4 am on Tuesday 19 October, i.e. 16 hours after noon ('post meridiem') on Monday 18 October.

This is presumably because he is thinking in terms of 'sidereal' time, according to which the day begins at noon. However, he quite often manages to confuse himself and (as in the above example) present a mismatch of one day between the date and the day of the week of the recorded birth. The mismatch may occur in either direction, and he quite often 'corrects' either the day or the date by one day, either bringing them into or out of kilter.

In such cases, timeanddate.com is an invaluable resource for figuring out which day and date is actually intended. The times and dates should be given in the transcriptions as they stand in the text, but either corrected in the header on the above principles or presented as two mutually exclusive alternatives if the correct option cannot be ascertained. If this leads to either the day or date of birth given in the header conflicting with that given in the text, a <note> should be added within <notesStmt> explaining so far as possible why the mismatch has occurred. Transcribers may either add such notes themselves or enter a comment tag asking a senior editor to do so.

vi) <death>. If a date (and/or time, and/or place) of death is specified, even if it is not in the transcribed section of the document, it should be recorded using the same elements as in <birth>. If it is in an untranscribed section, <death> or any or all of its children should take an @evidence value of internal.

vii) <event>. If a date (and/or time, and/or place) is specified in the entry for significant events relevant to a participant's life history other than birth, death or anything covered by <relation> (q.v.), e.g. christening, baptism or burial, it should be encoded in an <event> element, in much the same way as <birth> and <death>, except that <event> needs a @type value explaining what sort of event it is, and must have content (contained in a nested <p>). This should consist of the bare minimum of relevant information, on this model:

'<event type="baptism"><p>Baptised on <date when="1587-01-01">1 January 1587</date> at <time when="11:00:00">11 am</time> at <placeName sameAs="#place1">St Pancras&rsquo; Church</placeName>.</p></event>'.

viii) <occupation>. Where a participant's occupation is stated in the entry, this should be recorded (in modernised form with an initial capital) as the content of <occupation>, e.g. 'Midwife', 'Baker' (see our element set our master occupations list for all supported occupations). Where an occupation is given in terms that seem potentially confusing to non-specialist readers (e.g. 'man' or 'boy' meaning male servant or apprentice), explanations may be added in brackets, e.g. 'Man (Servant)'.

If a person has more than one occupation, e.g. Humphrey Caucot, 'souldier & shoemaker' (CASE18164), two or more <occupation> elements may be used.

If a person's occupation is explicitly stated but only in the untranscribed portion of the document, <occupation> takes the @evidence value internal.

If a person's occupation is not explicitly stated but can be inferred from the content of the entry (whether the transcribed portion or not), for instance a reference to someone's 'master' or 'mistress' suggesting that the person in question is a servant, <occupation> takes the @evidence value inferred. If there is some doubt or dispute about the inference, it may also be given a @cert value (high, medium or low).

If someone is described as having formerly had a particular occupation, <occupation> takes a @notAfter ISO value of the last plausible date on which he or she might have ceased to have it (normally the day before the consultation unless any further evidence is available), or a @to value of the date on which he or she ceased to have it if such precise information is present in the record.

ix) <trait>. In the very rare cases where someone is defined in the original record by her or his place of origin, nationality or other regional affiliation (whether or not this is accompanied by any of the other available components of <person>), e.g 'Segnior frenchman' (CASE5497) or 'denshir woman' (CASE5388), this should be recorded in a <trait> element with the @type value regionalIdentity. <trait> in turn contains <desc>, which contains a succinct natural-language description of the regional identity, based on the source but with modernised spelling and if necessary English translation ('Frenchman' and 'Devonshire woman' respectively in the above examples).

b) <org>. Where any of the parties to a consultation is not an individual person but a formally constituted group of unspecified people, e.g. 'the docters' (the London College of Physicians) or 'the University of Oxford', such a group - or such groups, if there are more than one - should be noted in one or more <org> elements. Each <org> takes a mandatory 3-letter @xml:id value, and as content the element <orgName>, containing a modernised version of the original description (with an initial capital), e.g. '<org xml:id="drs"><orgName>The doctors</orgName></org>'.

The @xml:id value for 'the docters' (or words to that effect, in Forman's records normally meaning the College of Physicians of London or its representatives) is drs. @xml:id values for other such groups will be assigned by the editors as they arise. (See the 'orgs and personGrps' page on the project wiki.)

Named ships (such as 'The Richard' (CASE882) or 'The Lion's Whelp' (CASE1661) should be defined as <org>s in the header, with a @type value of ship, since they occasionally turn up as subjects or objects of a consultation, or need to feature within <listRelation> if someone is described as owner, captain, purser etc. of a specific ship (e.g CASE4588, in which John Wallis is described as shipmaster of The John Francis). For consistency's sake, all named ships should be recorded as <org>s, even if they do not otherwise feature in the metadata.

Ships' names should be recorded in the metadata in normalised, modernised forms with initial capitals, as with CASE1661, in which 'The Lion's Whelp' is actually written 'the Lyons whelp' in the source.

In other respects, <org> functions exactly like <person> except that it does not contain <sex>, and its @xml:id value can similarly be used to derive @ref values for <cb:querent> (though not in the case of ships, obviously), <cb:subject> and <cb:object>, or the @active, @passive or @mutual values of <relation>.

Where any of the participants is not an individual but a group of unnamed people not definable as an <org>, e.g. 'the servants' or 'her friends', they can be defined as a <personGrp> taking an xml:id value in the same way as an <org> and as content the elements <sex> (male, female or unknown), and if relevant (i.e. if all members of the group have the same job) <occupation>. See the entry for <personGrp> in the Element Set for examples. Like <org>, <personGrp> can be pointed to by the @ref value of <cb:querent>, <cb:subject> or <cb:object>, or by the @active, @passive or @mutual value of <relation>. (See the 'orgs and personGrps' page on the project wiki for xml:id values defined to date.)

c) <listRelation> (optional). Where relationships of any sort between persons and/or groups mentioned in <listPerson> can be identified, these are recorded in one or more <relation> elements in <listRelation>, using the @xml:id values defined in <listPerson> preceded by #, thus:

• <relation name="master" active="#person1" passive="#person2"/> means person1 is person2's master
• <relation name="mother" active="#person1" passive="#person2 #person3"/> means person1 is mother of both person2 and person3
• <relation name="friend" mutual="#person1 #person2"/> means person1 and person2 are friends
• <relation name="member" active="#person1" passive="#drs"/> means person1 is a member of the College of Physicians of London

Where a relationship is not explicitly stated in the original document but has been deduced by the editor on whatever grounds, <relation> takes a @type value of editorial, an @evidence value of external, internal, inferred or conjecture, and if necessary a @cert value of high, medium or low (not needed if there is no reasonable doubt about the deduction).

The attributes @active and @passive are purely notional and do not imply that one person is more responsible than the other(s) for the nature of the relationship: '<relation name="slave" active="#person1" passive="#person2"/>' is perfectly valid coding to indicate that person1 is person2's slave.

If two people are described as lovers/sweethearts/boy or girlfriends, they can be linked by e.g. '<relation name="romanticPartner" mutual="#person1 #person2"/>'. However, if it appears that person1 is person2's sweetheart but person2 is not, or at least not necessarily, person1's sweetheart, the @name value wouldBeSweetheart should be applied, with the unrequited lover as the @active participant, and <relation> taking a @type value of editorial, since this is a matter of editorial interpretation rather than straight representation of the source data: '<relation name="wouldBeSweetheart" active="#person2" passive="#person1" type="editorial"/>'. In ambiguous cases - for instance, if it is clear that X has an affection for Y but unclear whether the feeling is reciprocated - a <!-- REVISIT --> comment tag should be added explaining the situation, in the hope that some as yet untranscribed entry will shed light on Y's feelings, in which case it will be possible to add an @evidence value of external to the earlier entry and (if necessary) revise the @name value of <relation>.

If the dates at which relationships began and/or ended are specified in the entry, <relation> may take the attributes @from, @to, @notBefore and/or @notAfter. @from is most likely to apply to marriage where a wedding date is given, but may also be used in defining professional, romantic or any other relationships if the evidence is available. @notAfter is particularly useful for ex-relationships, e.g. 'Jeane wit that was mrs blages maid' (CASE10082), for which a @notAfter value of the day before the consultation can be given if no more precise information is available.

It can be taken as read that if the death date of one of the partners in a relationship is recorded, this constitutes the relationship's @notAfter date, so it does not need to be specified in <relation>.

If the time as well as the date of the commencement (or, theoretically, the termination) of a relationship is specified in the source (this applies almost exclusively to marriages where the date and time of the wedding are given), @from-custom and/or @to-custom should be used. For instance,

'<relation name="husband" active="#xx" passive="#yy" from-custom="1555-07-01T12:00:00"/>'

indicates that XX and YY are recorded as having married at noon on 1 July 1555.

On the mercifully rare occasions where a range of plausible dates can be postulated for the beginning (or end) of a relationship, a series of <relation> elements each with a different @from or @to value can be used, with @xml:id values of relation1, relation2 etc, and @exclude values, as with <age>.

Any number of <relation> elements may be used.

See the values of @key in our element set and relations master list, relations.xml, for relationships defined to date.

4) <textClass> (mandatory: defines the type of text in question). This contains only the empty element <catRef>, which points by means of its @target value to one of the types defined in @target, which correspond to values in our consultation type list (consultation-types). <catRef> may also take a @cert value of high, medium or low in the very rare instances in which there is some doubt about the categorisation of the text.

5) <creation> (optional: records the stages in which an entry was composed if it was demonstrably not written at one sitting).

This contains the element <listChange>, with an @ordered value of "true". This in turn contains two or more chronologically ordered <change> elements detailing the steps of the entry's composition.

Each <change> element takes an @xml:id value of "stage1", "stage2", etc., and where possible, a @date value giving the date on which the change was made. This is rarely possible for any but the first <change> element, giving the date on which the consultation was held and the entry first written. It can be taken as read that any subsequent changes are posterior to this so the relevant <change> elements do not require a @date value unless there is some indication of when exactly, or within what date range, a given change occurred. In the unusual event of a range being definable, @notBefore and/or @notAfter should be used instead of @date.

The content of <change> consists of a <name> element with a @sameAs value pointing to the @xml:id of the relevant person, followed by a natural-language account of the nature of the change. By far the commonest reason for adding a second <change> element is that the practitioner, or one of the practitioners, or someone else, has added information about the outcome of the case (typically the subject's recovery, deterioration or death, or the effects of the prescribed medicine). However, there is a significant number of entries in which the process is more complicated, involving (for instance) Napier copying one of Forman's entries into one of his own casebooks and then revising it, or Napier making corrections or additions to an entry originally written by one of his scribes or collaborators. The precise wording in such cases is a matter for editorial judgment, but for some examples see the entry for <creation> in the Element Set.

6) <settingDesc> (mandatory: details about the consultation itself).

a) <date>, which nests in <p>. @when gives the date of the consultation (if known, which it usually is) in ISO format (yyyy-mm-dd) and @n gives the day of the week in natural language. Except in <publicationStmt> and <revisionDesc>, all dates should be given according to the Julian calendar (which is how they are almost always given in the source texts).

If, as quite often happens, there is a discrepancy between the day of the week and the date as recorded in the source (e.g. a date of 'Feb 1 Wednesday' when Feb. 1 of the year in question was a Tuesday), two options are available. If there are compelling grounds for deducing which of the components is a mistake (it should be corrected as 'Feb 2 Wednesday' rather than 'Feb 1 Tuesday', or vice versa), the corrected version should be recorded in the metadata and the relevant parts of the transcribed text marked up using <sic>/<corr> as explained in the Normalisation section of the Guidelines. If both options seem plausible, both should be given, using @xml:id and @exclude values on this model:

• <p><date when="1601-02-01" n="Sunday" xml:id="date1" exclude="#date2"/></p>
• <p><date when="1601-02-02" n="Monday" xml:id="date2" exclude="#date1"/></p>

If both options are plausible but one is more plausible than the other, the two alternative <date>s can take @cert values of high and low respectively. In such cases, the offending part of the source should be corrected using <sic>/<corr> with a @cert value of high on <corr>. If both options seem equally plausible, no @cert values need be applied in the header, and the source text should simply be given as it stands.

b) <time>, which nests in another <p>. @when gives the time of the consultation (if known) in ISO format (hh:mm:ss).

In both cases, @notBefore and/or @notAfter can be used instead of @when to offer a time range if the exact date or time is not known, and @cert can be applied in doubtful cases. If part of the time is lost or illegible, resulting in a number of mutually exclusive alternatives, @xml:id and @exclude values (of time1, time2, etc.) should be used in the same way as for <age> and <date>.

If no date or time is given, but it can be deduced with reasonable confidence (typically on the basis of manuscript position and/or internal evidence) that a consultation took place between time A on date X and time B on date Y, @notBefore-custom and @notAfter-custom values should be used. E.g.

'<date notBefore-custom="1599-01-08T11:00:00" notAfter-custom="1599-01-09T07:20:00"/>'

means some time between 11 am on 8 January 1599 and 7.20 am on 9 January 1599. In such cases, if a range has been systematically inferred, for instance on the assumption that the entry was written after the previous one and before the next one in the manuscript (bearing in mind Napier's habit of filling in his pages in an inconsistent and often counter-intuitive order), or that an interrogation was obviously written after the event it refers to and presumably before the next entry in the manuscript, <date> takes an @evidence value of "inferred".

It is permissible for @notBefore and @notAfter-custom or @notBefore-custom and @notAfter values to co-exist within a given <date> if one end of the range can be determined with more precision than the other.

If no evidence at all is available as to the time of a consultation, <time> can be omitted from the header. <date>, however, should always be included, either as a specific date or as a range with specific lower and upper limits, even if it can be narrowed down to nothing more precise than a range of 'some point between the date when the consultant began practising and the date of the consultant's death'.

Dates and times should always be given in full (yyyy-mm-dd/hh:mm:ss) even if no precise date or time can be established. In such cases, a range should be offered, e.g. '<date notBefore="1598-01-01" notAfter="1598-12-31"/>' rather than simply '<date when="1598"/>'.

c) <cb:consultation> (mandatory), which contains as many as applicable of the following:

i) <cb:questionNumber> (optional), with a numerical @n value stating that this is explicitly recorded (whether in the transcribed or the untranscribed portion of the entry) as the querent's first, second or whatever consultation (e.g. <cb:questionNumber n="2" /> where the text contains a formula such as '2^a questo' or '2^a figura'). This applies even if (for instance) '2^a questo' or '2^a figura' is appended to what is in fact the querent's fifteenth recorded question: this formulation clearly had a special meaning for Forman and Napier, indicating a sequence of connected questions, though we have not yet categorically established the nature and purpose of these groupings.

ii) <cb:consultant> (mandatory), with a @ref value of the consultant's @xml:id value as defined in <listPerson>, preceded by #.

If necessary (i.e. if there is more than one practitioner), there may be more than one @ref value, e.g <cb:consultant ref="#sforman #rnapier" />. The same applies to <cb:querent>, <cb:subject> and <cb:object>.

It is also permissible to include more than one <cb:querent> and/or <cb:subject> if they need different @present and/or @evidence values, though if both or all have the same values it is simpler to subsume them into a single @ref as above.

iii) <cb:practice> (mandatory): the practice in which the consultation took place, with a @name value of either forman or napier. In the vast majority of cases, entries in either practitioner's casebooks refer to his own practice (even if someone else is standing in for him as practitioner), but there are a very few examples of cases in Forman's practice being recorded in Napier's casebooks or vice versa, either because one of them is standing in for or collaborating with the other, or because Napier has copied a record from Forman's practice into his own casebook.

iv) <cb:querent> (mandatory): the person(s) who asked the question. This takes a @ref value of the querent's @xml:id value as defined in <listPerson>, preceded by #. (This may be the same person as the practitioner.) Also a @present value of yes, no or unclear to say, if possible, whether the question was put in person, unless the querent is or is assumed to be the same person as the subject, in which case @present is only required on <cb:subject>.

In most cases, the querent is assumed to be the same person as the subject if there is no clear statement of her/his identity. In these cases no further attributes are needed. But where there is an explicit statement, however vague, of the querent's identity, e.g. 'her self' (querent=subject) or 'the mother for the child' (querent=mother), @evidence should be internal. If the querent's identity can deduced from some external source such as another case or Forman's guide to astrology, @evidence should have the value external. If we can infer that the querent is not the same person as the subject but we have no clear evidence about who he/she is, <cb:querent ref="#anon" evidence="inferred" /> (where the subject, obviously, is someone other than anon). Where there is significant doubt about the querent's identity, the element can take a @cert value of high, medium or low. NB this is certainty about whether the person in question really is the querent, not whether he or she was present.

The formulation 'himself/herself/the woman (etc.) present' or 'in presenc' (as Napier usually spells it) should be treated with caution. While 'she sent', 'himself came' and the like seem fairly unambiguous indications that querent=subject, a mere statement of presence may very well suggest that the subject was not present of her or his own volition. In any case, it does not constitute solid evidence that the person in question is the querent. In such cases, if querent is assumed to be subject since there is no positive evidence to the contrary, <cb:subject> should of course take a @present value of yes but <cb:querent> should not take any @evidence value.

The main exception to the default querent=subject assumption is children under ten. It is assumed that someone else is asking the question on their behalf unless they are expressly described as asking it themselves. By the same token, if a subject who is not the same person as the querent is ten or over, he/she is assumed not to be present unless otherwise stated, but under-tens seem likelier to have been brought along to their consultations and should be given a @present value of unclear if there is no explicit statement on the issue.

There are occasional cases in which it is apparent that a child of ten or more has been accompanied by an unspecified querent, as in CASE3118, for 12-year-old Margery Heath, where 'the child present' can hardly be taken as meaning that Margery put the question herself, but no other querent is recorded.

Where the subject is known to be under 10 and no querent is specified, the presumed querent should be given the @xml:id value anon, as there is a very considerable chance that he or she is not the child's birth parent, if he or she exists at all.

The other exception to this rule of thumb is where subjects are manifestly deranged or incapacitated, or the entry features such derogatory accounts of their behaviour, which are clearly not the practitioner's own comments, as to make it barely conceivable that they could themselves be the source of the information (or allegation). In such cases, the querent should be treated as anonymous, with an @evidence value of conjecture and a @cert value if appropriate.

If there is reasonable doubt as to which of the people recorded in <listPerson> is the querent, both or all the mutually exclusive candidates should be listed, each in a separate <cb:querent> element, with an @xml:id value of quer1, quer2 (etc), a @ref value pointing to the @xml:id value of the relevant person as declared in <listPerson>, and an @exclude value or values pointing to the @xml:id value(s) of the incompatible alternative(s), on this model:

• <cb:querent xml:id="quer1" ref="#ab" exclude="#quer2"/>
• <cb:querent xml:id="quer2" ref="#cd" exclude="#quer1"/>

These alternatives may also be weighted by adding different @cert values to the different <cb:querent> elements if both or all options seem plausible but one seems more plausible than the other(s). If, however (as is almost always the case), no option seems likelier than the other(s), there is no need for a @cert value on any of them.

v) <cb:subject> (mandatory): the person(s) about whom or in whose interests the question was asked, with the same attributes as <cb:querent>. If subject and querent are or are assumed to be the same person, only <cb:subject> needs a @present value.

Just as with <cb:querent>, if there is reasonable doubt as to which of the people recorded in <listPerson> is the subject, both or all the mutually exclusive candidates should be listed, each in a separate <cb:subject> element, with an @xml:id value of subj1, subj2 (etc), a @ref value pointing to the @xml:id value of the relevant person as declared in <listPerson>, and an @exclude value or values pointing to the @xml:id value(s) of the incompatible alternative(s), on this model:

• <cb:subject xml:id="subj1" ref="#ab" exclude="#subj2"/>
• <cb:subject xml:id="subj2" ref="#cd" exclude="#subj1"/>

Again as with <cb:querent>, @cert values may be applied to each <cb:subject> element to establish a hierarchy of plausibility, but no @cert value is needed if neither or none of the candidates seems significantly likelier than the other(s).

In this extremely rare situation (at the time of writing, the situation has arisen only twice in over 34,000 entries), <cb:topic> must contain <person> elements for both or all the mutually exclusive candidates, each with an @xml:id value of pers1, pers2 (etc.), an @exclude value or values pointing to the @xml:id value(s) of the incompatible alternative(s) as stated within <cb:topic>, and a @sameAs value pointing to the @xml:id value of the person in question as declared within <listPerson>.

Thus, supposing that an entry has the topic lossAndTheft and that this applies either to someone called Andrew Burton or to someone called Catherine Davis (but not to both):

<listPerson> will include

• <person xml:id="ab"><persName><forename>Andrew</forename> <surname>Burton</surname></persName></person> and
• <person xml:id="cd"><persName><forename>Catherine</forename> <surname>Davis</surname></persName></person>

The two possible subjects will be listed within <cb:consultation> as

• <cb:subject xml:id="subj1" exclude="#subj2" ref="#ab"/>
• <cb:subject xml:id="subj2" exclude="#subj1" ref="#cd"/>

and the <cb:topic> element within <cb:consultation> will appear as

• <cb:topic key="lossAndTheft"><person xml:id="pers1" exclude="#pers2" sameAs="#ab"/><person xml:id="pers2" exclude="#pers1" sameAs="#cd"/></cb:topic>

If the subject is not, or is assumed not to be, the same person as the querent, this element can optionally take the @consent and/or @knowledge values yes or no if there is an explicit statement that the consultation occurred with or without the subject's consent and/or knowledge. Alternatively, @consent may take the value explicitlyUnclear if the practitioner actually expresses uncertainty as to whether the subject consented or not. (Consent, or the lack of it, is normally expressed in the records by the stock Latin phrases 'cum consensu' or 'sine consensu', or very occasionally some such formulation as 'credo sine consensu', which calls for an explicitlyUnclear value.) If there is no explicit statement one way or the other, on either count, these attributes should not be applied.

Napier has a bewildering habit of describing consultations as having occurred with or without the subject's consent when the subject is manifestly too young (e.g. 8 months old) to have expressed an opinion on the matter. Our current working hypothesis is that this in fact refers to the child's presence rather than her or his consent, so it can be used to infer a @present value. However, a @consent value should also be entered, in the interests of remaining faithful to the source, however implausible it may seem.

vi) <cb:messenger> (optional): if a messenger is specified, the @ref attribute points to the @xml:id value of the person in question as declared in <listPerson>.

This includes people such as servants or relatives who have brought a question. However, it is often hard to be sure whether the bringer of a question counts as querent or messenger (i.e. whether they are putting the question themselves or simply conveying it). In such cases, comment tags, editorial consultation, and as a last resort <notesStmt> are the best tools we currently have available.

vii) <cb:object> (optional): the person(s) who is/are not the principal person(s) in whose interests the question was asked but is/are highly relevant to it: e.g. if X asks whether she should marry Y, X is querent and subject, Y is object, or if A asks whether B has bewitched C, A is querent, C is subject and B is object. Or if D asks about the whereabouts or wellbeing of her absent husband E, D is both querent and subject (since it is in her own interests that she is asking) and E is the object. Again, the @ref value points to the @xml:id value of the person in question. As with querent/messenger, the borderline between subject/object is not always easy to define.

In the unlikely event of there being two or more mutually exclusive candidates for the role of <cb:object> (as distinct from there simply being two or more <cb:object>s, which is not at all uncommon), the mechanism described above under <cb:querent> and <cb:subject> should be invoked, with @xml:id values of obj1, obj2 (etc.) on the relevant <cb:object> elements.

viii) <cb:location> (optional) with @type values of neutralGround, practitionerReceivesMessage, practitionerVisitsQuerent, querentSendsSubject, querentVisitsPractitioner or unknown. practitionerVisitsQuerent and querentVisitsPractitioner are hopefully self-explanatory; the others (which are used only rarely) are explained in more detail in the entry for <cb:location> in the Element Set. Note in particular that practitionerReceivesMessage should only be used in conjunction with ref (concerning which see below), where there is an explicit statement of where the practitioner was when he received the message. A mere statement that a message was sent, with no indication of where it was sent to, does not call for the use of practitionerReceivesMessage, as this is already apparent from the no value for @present on <cb:querent>.

<cb:location> also has an optional @ref value of e.g. #place1 or #address1, pointing to the @xml:id value of a <placeName> or <rs type="address"> in the body text (cf. <residence> above) if the location of the consultation is specified in the source text.

The great majority of Forman's and Napier's consultations almost certainly took place at their respective homes, but it should not simply be assumed that this is the case if there is no statement to that effect. Even a formulation such as 'he came to me' or 'she visited me' does not necessarily mean that the encounter was in the consultant's home, and indeed there are some cases where we know that Napier was 'visited' while he was staying at his brother's house in Luton or with a friend in some other town.

ix) <cb:topic> (mandatory), with a @key value of any one of the categories defined in the topics list. There may be any number of topics bar zero. Each <cb:topic> element must contain at least one <person>, <personGrp> and/or <org> element, pointing to the person or people being asked about, thus: '<cb:topic key="XXX"><person sameAs="#yy"/></cb:topic>', '<cb:topic key="XXX"><person sameAs="#aa"/><person sameAs="#bb"/><person sameAs="#cc"/></cb:topic>'. In most cases, this will be the subject, or one or more of the subjects, but the element may also, or instead, contain one or more objects. Within topics such as lossAndTheft or witchcraft, both the victim(s) and the alleged perpetrator(s), if any are mentioned, should be included here: the question of whether they should be regarded as victim(s) or perpetrator(s) will be determined by whether they have been defined as subject(s) or object(s).

There are some cases, most notably absentPerson entries, in which the person asking is the subject but the person being asked about is the object. In these instances, only the object(s) should be included as <person>s within <cb:topic>.

To summarise:

If A is asking about the welfare or whereabouts of absent person B, only B belongs in <cb:topic>, since A is not the person being asked about, although he or she counts as the subject. If A is asking whether B has robbed or bewitched C, both B and C belong in <cb:topic>, but A does not, since A is not the robbed or bewitched party, and not the supposed robber or bewitcher. If, however, A is asking whether B has robbed or bewitched A, both A and B should be <person>s within <cb:topic>.

Where there are two or more mutually exclusive candidates for the @key value of <cb:topic>, they can be dealt with by entering two or more <cb:topic> elements with @xml:id values of topic1, topic2 etc., and @exclude values, as with <age>, <date> and <time>.

Certain topics should only be assigned to an entry if the practitioner himself has specified them in the question section using a particular constrained vocabulary. In these cases, <cb:topic> should take a @resp value pointing to the practitioner in question, to indicate that the choice of topic is based directly on the practitioner's own categorisation rather than the editor's interpretation. The @key values in question are:

• diz (where the practitioner has used the term 'diz', 'disease', 'diseased' or cognates in a medical question)
• morbus (where the word 'morbus', however declined, features in the question section of a medical entry)
• morbusPassions (where the word 'morbus', however declined, features in the question section of a passions entry)
• nonMedicalState (where the word 'stat', 'state' or 'status' features in the question section of a non-medical entry)
• passionsDiz (where the practitioner has used the term 'diz', 'disease', 'diseased' or cognates in a passions question)
• sickness (where the word 'sick' or 'sickness' features in the question section of a medical entry)
• sicknessPassions (where the word 'sick' or 'sickness' features in the question section of a passions entry)
• state (where the word 'stat', 'state' or 'status' features in the question section of a medical entry)

In the case of <cb:topic key="liveOrDieMedical"> (as opposed to plain liveOrDie, which is for questions that are not, or at least not obviously, medical in nature), an @evidence value of internal should be applied if either the fact that the question is about whether someone will live or die or the fact that the question is medical in nature is only apparent from the untranscribed section.

If the topic cannot be even conjecturally defined (because it has been lost through damage, it is unstated, it is stated so cryptically that none of the editors can make sense of it, or it has been deleted to the point of indecipherability), <cb:topic> takes a @key value of unknown and a @reason value of msDamage, notGiven, notUnderstood or deleted. If a question concerns more than one topic, it is permissible for one or more to have the @key value unknown even if the other(s) can be more precisely defined.

x) <cb:item> (optional) with a @type value of urine, letter, token or blood. Normally this will only feature if urine or blood samples, a letter, or some other unspecified token is explicitly mentioned in the record, but it may take the @present values explicitlyNo (if the consultant actually notes the absence of such an item) or unclear (if there is some reason to suppose the item was probably present but no conclusive evidence).

xi) <cb:judgment> (optional): included if a judgment section is given.

xii) <cb:treatment> (optional): included if a specific treatment is recorded, or if there is an explicit statement that no treatment was offered. Napier quite often, especially in cases of mental disorder and/or witchcraft, includes one or more sigils in his prescriptions: these are of especial interest and should be flagged by a <cb:treatment> tag with the @type value sigil. Only one such tag is needed (or permitted), regardless of how many sigils are prescribed. This may be either instead of or in addition to a <cb:treatment> element with no attributes, indicating the prescription of more conventional treatment. See the entry for <cb:treatment> in the Element Set for guidance on how to spot sigil prescriptions.

xiii) <cb:recipe> (optional): included if a specific recipe is spelled out, normally (but not always) preceded by the glyph '&Rx;'. The distinction between 'treatment' and 'recipe' is somewhat subjective and may have to be sorted out on a case-by-case basis, but as a general guide 'prepare purg and bleed' is a treatment, '&Rx; Iuniper berries steeped in dew' is a recipe. The two are not, of course, mutually exclusive.

xiv) <cb:info> (optional), with a @type value of angel, divination, event, financial or urine. This records the presence of information about any of these four apparently discrete matters.

In April 1611, Napier took to consulting the archangels Asariel, Gabriel, Michael, Raphael and Uriel, and a somewhat lower-ranking angel called Aladiah (and possibly others) for advice about diagnoses, prognoses and treatments. Quite how he communicated with them remains something of a mystery but his records of their advice are clearly of considerable interest and the presence of such records in a given entry should be documented using <cb:info type="angel"/>, with a mandatory @subtype value of Aladiah, Asariel, Gabriel, Michael, Raphael, Uriel or Unspecified as the case may be.

These records tend to be extremely cryptic and can be hard to spot, but they are typically much more categorical than Napier's own determinations. Whereas Napier usually hedges his own judgments with formulae such as 'it seemeth that ...', 'videtur ...' or the like, those of the angels are presented with an air of confident finality, as statements of concrete fact: 'she will die', 'non est gravida' etc. (though in the case of favourable prognoses often with a proviso such as 'by the grace of god', 'with Gods help' etc). They are normally (but not always) prefaced by the capitalised initial of the archangel in question (A for Asariel, G for Gabriel, M for Michael, R for Raphael or V for Uriel) or a truncated form of his name (e.g. 'Gab' for Gabriel or 'Mich' for Michael). Current thinking is that Aladiah is normally given in truncated form as 'Al' (or in one instance spelled out in full as 'Alladia', which is how we identified him), but where only a letter 'A' is given it is advisable to add a comment tag of the form <!-- TODO CB ANGEL --> pointing out that it may mean Aladiah instead of Asariel.

<cb:info type="divination"/> applies where the practitioner has demonstrably used some other form of divination instead of or as well as astrology or geomancy to reach his judgment. It requires a @subtype value indicating what sort of divination was involved. To date, the only such 'alternative' method encountered in the casebooks is divination by dice, for which Napier briefly developed an enthusiasm in 1618-1619: this is recorded by the @subtype value dice. The characteristic indicators of the use of dice divination are a row of dots (presumably indicating the total number of dots on the upturned faces of the dice) and/or a rhyming couplet, most often in Latin, associated with that particular number of dots (e.g. CASE47477, in which a row of eleven dots just below the chart is followed by the formula 'Subruet in fine vim morbi vis medicinae' (the power of medicine will in the end overcome the power of the disease). The same couplets recur in different entries, always associated with the same number of dots, so it would appear that Napier was drawing on some as yet unidentified collection of possible judgments, using dice (as he states himself at one point) to determine which to select, rather after the fashion of I Ching.

<cb:info type="event"/> is used if information has been added about previous or subsequent events relevant or potentially relevant to the case: 'her former physick wrought not at all', 'he died 3 dais after' or the like. It takes the mandatory @subtype value previousConsultation or subsequentEvent. Information about previous events should be limited to remarks about previous consultations or treatments administered by the current practitioner. Details about past events in the patient's private life or treatments offered by other practitioners should be considered part of the judgment. Reports of subsequent events (which, by definition, constitute addenda to the original records) can be construed more broadly, including subsequent treatments not prescribed by the practitioner (if they are prescribed by the practitioner they count as <cb:treatment>), or reports of the subsequent effects of treatment prescribed by the practitioner, e.g. '24 stooles it gave her' (CASE10635).

<cb:info type="financial"/> applies if there is any explicit record of payment or other financial details relating to the consultation. In Napier's case, this quite often includes a statement that no charge was made, usually expressed as 'gratis' or simply 'gr'. There are also many instances in Napier's records of payments-in-kind, usually involving agricultural produce ('shee brought me apples', 'he sent me a paire of Conyes' etc.). In both cases, these should be recorded as <cb:info type="financial" /> with a comment tag briefly transcribing or summarising the information.

Distinguishing financial information can be problematic, thanks to Napier's habit of stating the weight as well as the price of medicines in pence. Generally speaking, a quantity expressed at least partly in pounds and/or shillings can be taken as <cb:info type="financial" /> but one expressed only in pence cannot, unless it is preceded by some other indication of the weight of the medicine in question (which may also be in pence). The term 'ob.', which is frequently appended to quantities given in pence, is short for 'obolus', meaning 'halfpenny', and may refer to either weight or price.

<cb:info type="urine"/> is included if there is a description of the patient's urine (as opposed to merely a record of its having been brought or sent), suggesting that urine observation is being used as a diagnostic tool. In a fairly small number of cases, it is a matter of editorial judgment whether an account of the patient's urine should be considered symptom description or analysis, but to take two relatively straightforward examples, 'his urine scalding hot' is symptom description but 'water too high coloured' is analysis.

xv) <cb:astrologer> (optional) points, by means of the @ref value, to the person responsible for the astrological analysis where this is not the same person as the consultant, or where both the consultant and someone else have provided astrological analysis. In the overwhelming majority of cases, consultant and astrologer are the same person, but in a relatively small number of entries one person (usually if not always Napier) has added or revised a judgment in a case for which he could not possibly have been the consultant. There are two main scenarios in which this can arise: a) where Napier has copied out one of Forman's entries but supplied his own judgment, and b) where a case has been conducted by one of Napier's assistants in his absence but Napier has added a judgment and/or treatment section at some later date. In the former case, Napier either adds a judgment where Forman had not included one at all, or Napier's supplied judgment is radically different from that of the original entry. In both, it is permissible to include two <cb:astrologer> elements if, for instance, Gerence James has acted as consultant in Napier's absence and provided his own astrological analysis (chart, treatment, judgment etc) but Napier has subsequently supplied similar information that either supplements or contradicts that of the original entry.

All the customised <cb:xxxx> elements listed above may take @cert and/or @evidence values if there are grounds for doubt about whether the element should be included or, in the case of <cb:topic>, what the @key value should be.

The presence of astrological and/or geomantic charts is noted in the <body> section of the document (see Content Tagging, section 4) and does not need to be recorded in the header.

Where any sort of information that would normally be noted in the metadata, such as judgment, treatment, urine note, financial information or event information, is present in the record but has been wholly deleted, it should not be recorded in the header, but can (and preferably should) be mentioned in a comment tag. Where such information is only partially deleted, however, the remaining section still needs recording.

IV. <revisionDesc>

records the work done on the electronic file, and consists of an indefinite series of <change> elements each with an ISO @when value giving the date, and content giving a natural-language account of each significant revision. The person who made it goes in a <name> element with an @xml:id value that will be assigned by the senior editors when someone starts work, but is normally based on that person's first initial plus her or his surname, e.g. mhawkins, lkassell, rralley or jyoung for Michael Hawkins, Lauren Kassell, Robert Ralley or John Young.

Proofreading a file counts as a <change> even if the proofreader has not in fact made any changes to it. The file itself may not have changed but its status has.

If the @xml:id value of any of the people working on the document has previously been declared, subsequent occurrences of her or his <name> take a @sameAs value of # followed by the relevant string.

For instance:

The <TEIHeader> is followed immediately by a <facsimile> element containing one or more <graphic> element(s) which point, by means of the @url value, to the filename(s) of the image(s) on which the transcription is based. This information is entered by the technical director before transcription begins (or, in the case of legacy files based on 'home-made' images, supplied by him when canonical images become available). The editors need only concern themselves with it if an entry runs to more than one page, in which case they need to supply one or more further <graphic> element(s) as explained in the entry for <graphic> in the Element Set, or in the very unlikely event of there being a mismatch between the @url value of <graphic> and the actual URL of the relevant image. These values will already have been vetted by both the technical director and a senior editor, but editors are encouraged to double-check them (this may sound horrendously complicated but in practice any such mismatch should be glaringly obvious). If something does seem to be wrong, editors should inform the technical director and not attempt to correct it themselves.