According to the current documentation, references to persons occuring
inside a msDesc should be tagged with a name element, which can have
one or more of the attributes TYPE (always "person" presumably for a
person) ROLE (a suggested set of values is given but the dtd doesnt
enforce it) and KEY (which is defined as IDREF) The element which must
exist somewhere with a corresponding ID is a <person>; this note
considers how we should record <person> elements within Master
descriptions.

The <person> element as used in the Master dtd appears inside a
<listPerson> element within the header. As such it is (deliberately)
analagous to the <bibl> record appearing inside a <listBibl>, and
referenced by a <ref>: we should be aiming to provide equivalent
facilities for the validation, update, and linkage of both
bibliographic and biographical data. We will need to have a facility
equivalent to the current "reload bibliography" facility which will
reload biographical data to enable validation to take place.

According to the ref manual, the <person> element has the content
model (p+ | (persName*, birth?, death?, (occupation|residence|bibl)*
)) and attributes role, sex and age, with obvious value ranges (tho we
should probably decide on a set of age group labels). As such it is
remarkably tightly structured by comparison with other Master
elements, though still pretty fluid. Each of the sub components
(birth,death, occupation, residence) has the same content model
(#PCDATA|date|placeName|ptr|ref|note)*, which is a restriction on the
normal phrase sequence. Each of them is also a member of the datable
class, and so can carry notBefore, notAfter attributes as well as the
usual set (Matthew has suggested that a third attribute "date" pure
and simple for exact dates should be added to this class, but I'm not
sure.)

So what should Phelix do with this?

1. There should be a default <listPerson> element in the header, and
   any <name>s carrying a KEY attribute should be validated against
   it.

2. The user should be able to update or replace the <listperson>
   element in the same way as they can currently update/replace the
   <listBibl> used to validate <ref> elements.

3. One day we will have a way of dynamically updating <listBibl>s and
   <listPersons>, but not yet.

4. It should be possible to search the <listPerson> element for
   <persons with candidate keys which can then be used to search for
   for <name> elements in the body of the text. For example: one might
   want to find all manuscripts with female authors born in
   Jutland. That would mean :

-- get the keys for all female authors born in Jutland from the
   <listPerson> element

-- use the result set to get all the <name> elements which carry those
   key values

-- make a list of mss in which those name elements appear


5. It should be possible to select just the person record for a given
   key (perhaps by making the name element in the display a hot link),
   so that one could view biographical detail for a referenced person
   from within the ms descripotion.

6. It should be possible to search and browse just the listPerson (or
   listBibl) element, in much the same way as one searches and browses
   the <msDescription>s in the current system.

I think that's it!

Lou