Report on XML mark-up of biographical and prosopographical data

Archival and Library Systems

Historical Projects

Genealogists

The website Cover Pages mention GedML: Genealogical Data in XML, GEDCOM XML (Genealogical Data Communication), XGenML, gdmxml, Genealogical Information Markup Language (GeniML™), GENTECH Genealogical Data Model, Genealogical Data Models in the Unified Modelling Language (GDMUML), GenXML, the GRAMPS Project and FamilyML. Due to time restrictions, many broken links and the lack of well structured presentations for a number of these systems, we will concentrate on GEDCOM XML, developed by the Family and Church History Department of The Church of Jesus Christ of Latter-day Saints, and gdmxml, the XML version of GENTECH, the National Genealogical Society's Genealogical Data Model, which seem to be the two most widely used systems.

Names for business purposes

<person>

In TEI P5, information about the person's sex, role and age can be given as attributes on the first wrapper element for the person described:

The attribute @xml:id seems to be contained in most systems' wrapper element for the individual; the other attributes, sex, age and role — if they are registered — are dealt with in separate elements.

Four of the other systems (EAC, GEDCOM XML, GENTECH XML and HR-XML) have a separate element named <sex> or <gender> (GEDCOM XML). In gdxml all personal characteristics, including sex, are registered as characteristics, cf. Appendix 1. Table 3 shows how these systems register a person's sex/gender:

A means for indicating a person's role are only found in half the systems. In HEML, GEDCOM XML and gdmxml the role of a person seems to be registered as part of the event in which the person is a participant. As in TEI P5, METS @role is independent of the description of an event. MODS, however, has a special element for <role> with a subelement <roleTerm> .

The optional value age is only found in TEI P5 and GEDCOM XML. For the latter, the age is registered in connection with an event; i.e. the age of a participant at the time of the event.

Points for discussion All other systems working with the categories sex, role and age have separate elements for these, and it can be discussed whether TEI wants to split this information up into separate elements or to retain them as attributes on <person> . @age is obviously left over from the time when <person> was only used for participants in a language interaction, and its relevance in other contexts may be questioned, given that age is clearly not static, like gender (although here too there are obvious exceptions). It is also important to note the a person's role can vary considerably according to the circumstances. It seems reasonable therefore to argue for adding some sort of event-list, e.g. as <eventList> <event> , or <life> <lifeEvent> , to which such information could be tied.

The authorised form of a name (ISAAR(CPF)2: 5.1.2)

As the authorised name of a person is the core of every personal description, all the schemes discussed here have elements for this. Comparing these is complicated by the fact that the different systems operate with different taxonomies or approaches as to which level a name should be grouped and categorised.

The simplest system is that of METS, which does not have any division of names into subelements. In HEML, all subelements of a name are repetitive name elements: <NameElement ordinal="1|2|3|[etc.]"> . The MODS design is a little more elaborate, as it also has the element <namePart> on which there is a @type attribute with the possible values date, family, given and termsOfAddress, to categorise more precisely the various parts of a name. The value termsOfAddress is used for additional names, titles etc., and date indicates dates of birth and death of the person. In gmxml ( http://gdmxml.fugal.net/fugl.xml ) the name is part of a characteristic of a person, and the name elements are defined in @charateristics-part-type-ref.

NOMEN and EAC distinguish between authorised names and other names; in NOMEN it is done by the element <Authorized> , whereas in EAC an @authorized attribute is available on <pershead> . Unlike the other systems, HR-XML operates with formatted names, which are names written exactly as they would appear on a purchase order, an envelope, etc. (presentation), as in ordered lists (sortOrder) and on legal documents (legal); in HR-XML a person's initials are also marked separately from the name. To treat the initials as a single unit seems logical — in these cases where all the name consists of initials — and could be integrated in TEI's name tagging as an alternative to the division of initials on forename and surname-tags.

Where TEI P5 has <forename type="first|middle"> the NOMEN system does not make the division, as it only has the element <Given> ; EAC works with a <part> for all types of names, except for additional names, with the type identified by the attribute @type. Both xNL and HR-XML, on the other hand, work with a division of the forenames this into <FirstName> and <MiddleName> (xNL) and <GivenName> <PreferredGivenName> and <MiddleName> (HR-XML); the division of <GivenName> and <PreferredGivenName> seems to correspond with TEI P5's tagging <forename type="unused"> and <forename> , and GEDCOM XML's division between level 3 and level 4 in <NamePart Type="" Level=""> . GEDCOM XML has a division of names into <IndivName> and <NamePart> , the part of the name categorized by the @Type — seemingly with an overlap — and the <NamePart> -names are divided into four levels, 1 = surname, 2 = maiden name and 3 = given name (4 can be added for the most important name).

All the systems have an element for surname, but xNL is the only system working formally with additional surnames distinguishing between <LastName> and <OtherName> (the maiden name can also be included in <OtherName> . As an example The xNL Standard Description Document use the name of a man normally known as Yousuf Khan but with the patronymic names of his father and grand father he is called Yousuf Khan al Hatab al Sayad (Hatab is Yousouf's father's name and Sayad is Yousuf's grandfather's name) al Hatab al Sayad is then his <OtherName> .

xNL also works with values OldName, Official and UnOfficial, the first, apart from being a value to e.g. <FirstName> is found in the element <FormerName> with the attributes @ValidFrom and @ValidTo. OldName/ <FormerName> could be an equivalent to TEI P5's <forename type="unused"> , however, more elaborated. Note also that for all name-parts EAC has the optional subelements <existdate> and <usedate> to indicate the dates of the validity of the names.

xNL's division between an official and unofficial name seems to be the equivalent to the tagging of normal names and nicknames in the other systems. Nevertheless, the more unspecific values Official and UnOfficial are not limited to a division between the nickname and the more official names, but are applicable to other forms of official and unofficial representation of names; furthermore, the <Alias> -tag can also be used for registering nicknames. HR-XML works with a system, corresponding to TEI P5's @sort, in which the primary surname is distinguished from other surnames, if any.

TEI P5's <nameLink> corresponds easily to xNL's <LastNamePrefix> and HR-XML's <FamilyName prefix="de|von|da|[etc.]"> , GEDCOM XML's <NamePart Type="surname prefix"> and EAC's <part type="prefix"> , and perhaps also in gdmxml's @characteristic-part-type-ref; the only difference is that in HR-XML @prefix is an attribute. Double-barrelled names do not seem to be categorised separately in any systems other than TEI P5.

TEI P5's <addName> covers a wide range of additional names, determined by the value of @type;

• METS and MODS and HEML have no equivalents
• Gdmxml's attribute @characteristic-part-type-ref in <characteristic-part-type> seemingly covers all sorts of values for a name.
• xNL has <Alias> and <Title> ; a nickname can be listed both as an <Alias> or by using the value UnOfficial in <FirstName> .
• NOMEN also has both <Title> and <Additional> , the latter separated into smaller components <Add1> <Add2> and <Add3> ; however, the <Additional> <add> elements look as if they cover a larger range of names than TEI P5's <addName> .
• HR-XML does not an equivalent category, but some of <addName> 's values can be found in the elements <formatted name> and <affix> , and, according to the manual (p. 8), nicknames are tagged by <PreferredGivenName> .
• EAC's <nameadd> covers both <addName> and TEI P5's <roleName> and <genName> ; the validity of the name is marked with either <existdate> or <usedate> .
• GEDCOM XML only have <NamePart Type=""> to catalogue additional names.

<roleName> with its various values corresponds to xNL's <Title> , <PrecedingTitle> , for outdated titles, and <Suffix> , and to HR-XML's <Affix> ; xNL has <title type="sex"> , a further division which is not found elsewhere. Uniquely, xNL also has a <GeneralSuffix> which is used to indicate that the person is pensioned or deceased.

<genName> corresponds with xNL's <GenerationIdentifier> and HR-XML's <Affix> , as can be seen from table 2 above; because of all the various options for the attribute @type <Affix> covers both TEI P5's <roleName> and <genName> .

Points for discussion: Compared to other systems, TEI P5 encompasses many details of a person's name, but it can be discussed whether TEI also should:

• have a mechanism for distinguishing between an authorised name and other names, as in EAC and NOMEN
• use a separate element for middle name or maintain the system where the division between middle and first names are indicated by the @type.
• add dates to the names, either parallel to EAC's <existdate> and <usedate> , or with attributes similar to @ValidFrom and @ValidTo
• add equivalents to EAC's values translations and transliterations, the latter for names from other writing systems.
• deal with initials as a separate single unit.

Parallel Forms of a Name (ISAAR(CPF)2: 5.1.3-5.1.5)

In most of the schemes, parallel forms of a name, if they occur, are dealt with by repeating the name element and changing the language, as in the TEI example shown above, and also in HEML, where the various forms of the name are wrapped in a <NameSet> element; see table 7 below.

In EAD and NOMEN, parallel names are marked formally, in EAD by @authorized in <pershead> , although an element <persgrp> (Personal Name Heading Group) exists ‘to associate parallel personal names in various languages or script forms’. (Encoded Archival Context Tag Library, <persgrp> http://www.iath.virginia.edu/saxon/servlet/SaxonServlet?source=/eac/documents/tl_beta.xml&style=/eac/shared/styles/tl.xsl#e.langmaterial ) Translations and transliterations of names are marked by @translations and @transliterations in <part> . As seen above, NOMEN also marks the distinction between the authorised name and the variant name but has no translation system.

GEDCOM XML has the element <IndivNameVariation> , and parallel to EAC's @translations and @transliterations, GEDCOM XML has the attributes @TranslationType and @Method for names in other alphabets. The names, however, exists parallel to each other in the same personal name content model. In xNL <FormerName> and <KnownAs> are available as subelements of <PersonName> .

Dates of existence

All systems, with the exception of xNL and HR-XML (both of which record systems of names for business purposes) have means of indicating the dates of a person's existence, but there are different ways of approaching the matter.

• The first approach is to record the known dates of a person's existence as a part of the person's name, as in MODS, where date is available along with family, given and termsOfAddress as a possible value of the @type attribute on <namePart> .
• The second is to interpret birth and/or death as ‘events’. This is the case for the genealogists, GEDCOM and gdmxml (in Hans Fugal's family gdxml file he has not noted birth or death of the persons involved, but inferring from the internal logic of the system these dates must be connected to an ‘event’ designated by the attribute; in the DTD, the element <date> exists as a sub-element for characteristics, event and group) and, arguably, HEML (and has also been suggested for TEI, see below).
• The third option is to record the date and place of birth and death as separate from other ‘events’, as in TEI P5, EAC, NOMEN and HR-XML. CIDOC also seems to belong to this group, but with a distinction not known elsewhere, as CIDOC distinguishes between a birth by mother, a birth by father and a more impersonal birth. Furthermore, the system distinguishes between the natural death of a person and death by other causes, such as murder (note that the persons here are not viewed as actors or persistent items); see table 9 below.

As seen above, GEDCOM XML singles itself out from the other systems by operating with two rather existential categories for the person involved: <DeathStatus> with the content dead, stillborn, infant and child, as well as with an element for the participants of an event called <living> , which, not surprisingly, has the two options Y (yes) or N (no). By using the elements <participant> and <role> it is also possible, as in CIDOC, to distinguish between a person's mother and father and between death by natural causes and murder.

History/Event (ISAAR(CPF)2: 5.2.2. History)

TEI P5 has an <event> element, but it is used in transcriptions of speech to mark ‘any phenomenon or occurrence, not necessarily vocalized or communicative, for example incidental noises or other events affecting communication’ (Sperberg-McQueen, C.M. and Lou Burnard (eds.): TEI P5: Guidelines for Electronic Text Encoding and Interchange, Oxford — Providence — Charlottesville — Nancy 2005 http://www.tei-c.org/release/doc/tei-p5-doc/html/ ) and so there is at present no means of combining persons and historical events within the <person> element. There is, however, the option of recording a person's residual history with the use of place and date elements, as has been done for persons mentioned in descriptions of manuscripts in the Arnamagnæan collection, cf. below in the next section, Places.

As seen in the table below, EAC and HEML, as well as the genealogical systems GEDCOM XML and gmlxml, all have means for record a person's history. There is, however, a qualitative difference between EAC and mglxml and the two other systems, as the events of both HEML and GEDCOM XML are documented in separate event records.

To describe a person's history, EAC works with something called <bioghist> , which contains ‘text within Paragraphs <p> and/or a chronology list <chronlist> that matches dates and date ranges with associated events’ (Robertson 2001-2005 http://www.iath.virginia.edu/saxon/servlet/SaxonServlet?source=/eac/documents/tl_beta.xml&style=/eac/shared/styles/tl.xsl#e.langmaterial ). To these events persons <persname> corporal names <corpname> , <titles> etc. can be added. An event group element <eventgrp> also exists for bundling multiple <event> s assiociated with a single <date> ; <chronitem> can also be repeated ‘for each set of associated date, place name, and event or group of events’.

In the XML Schema for Heml, version 2003-09-17 ( http://heml.mta.ca/Schemas/2003-09-17/heml.xsd an ‘event’ is defined as ‘what is known about an historical event. It comprises, in order, Labels, Date, Location, Participants and References elements’ (my italics). The label contains ‘a description of the historical event in a brief headline-style entry suitable for inclusion in a table or printing on a map.’ The participants as well as the locations are linked to the records of the personal names and locations by the attribute @uriRef. As the HEML descriptions aim at being multi-lingual and multi-calendrical, the label should be rendered in various languages and put inside the wrapper element <EventLabelSet> (‘Heml elements whose names ending in ‘Set’ contain multiple instances of an element which describe the same thing, each in a different language’ (Robertson 2001-2005)). The bundling of events in HEML is not defined by their date, but by their conceptual similarity. This is done by the element <Classification> and with the reference elements <KeywordClassificationSetRef uriRef=""/> referring to the events, cf. table 10 above.

GEDCOM XML does not work with groupings of events, as the other two systems do. As in HEML, a participant in an event can contain a link to a record containing information on the person, if such information exists. In addition the <Participant> 's age is recorded, and whether he or she was dead or alive at the time of the event ( <Living> Y|N </Living> ). GEDCOM XML is also the only system working with a set of given values to an event, by means of which, for example, the sponsoring religion of an event can be recorded.

gmlxml also has an <event> element, with attributes @id, @event-type-ref and @place-ref to indicate type and place (these references are defined in <event-type id=""> and <name> ). The participants are first treated according to their role ( <event-type-role id=""> ), then as part of a group ( <group id="" group-type-ref="" place-ref=""> , the values here are also defined elsewhere in e.g. <group-type id=""> <name> and <group-type-role id=""> <name> ) and only then as individuals ( <persona id=""> <name> ).

Table 11 compares the aspects of elements for each system:

Points for discussion This section has been concerned with an aspect of personal description not found in TEI P5, the focus on events in a person's life, which raises the questions whether the TEI wants to be able to treat such events as a part of the personography (as in EAC) or as an individual event record in which participants are linked to personography files (as in HEML and GEDCOM XML). If choosing the first option, it has been suggested that a <life> element containing one or more <lifeEvent> elements could be added to the personal description. However, the design of EAC with a grouping of events according to the date could also be transferred to TEI (the grouping of events according to their conceptual content seems more appropriate for records in which the event is the pivotal point).

Places/Location (ISAAR(CFP)2: 5.2.3: Places)

The <location> element is described in the Encoded Archival Context Tag Library as ‘An element used to contain information on the place [...] where the entity was based, lived or resided or had some other connection.’ Only half the systems, TEI P5, EAC, GEDCOM XML, HEML and glmxml, have an element in keeping with this definition; NOMEN only deals with places in connection with the person's birth or death.

Table 13 illustrates the different ways of treating geographical data. Text in brackets is used when a term is only partly equivalent.

EAC divides the notion of places into geographical and jurisdictional areas; this division seems to be most relevant in connection with places in the United States, however. Something corresponding to HEML's elements for latitude and longitude might be added to the TEI, but as these seem to be used when displaying the locations on a map, an aspect not found in TEI, they are perhaps not relevant.

GEDCOM XML and NOMEN both have special elements for postal code, and NOMEN even for the street name and street number. TEI P5 and EAC both distinguish between <PlaceName> / <location> on one hand and <address> on the other. Here, the tagging of street names, street numbers and postal codes are only connected with the <address> (TEI is the only one of these systems which has an element <postCode> and <street> ; however, both EAC and TEI P5 have the option address line <addressline> (EAC) and <addrLine> ), while <placeName> / <location> treats geographical data on a more macro-oriented level.

Legal status

As the definition is a very broad one (cf. The EAC Tag Library), ‘legal status’ has here been interpreted as all information endorsed by a legal (institutional or governmental) authority, including such things as nationality and marriage. Only EAC has elements for a person's legal status; TEI P5 has a <nationality> element, which has its counterpart in GEDCOM XML's <PersInfo type="nationality"> . In addition, GEDCOM XML has elements for a person's marriage(s) (encompassing ‘information about and number of marriages’ (GEDCOM XML Specification, Release 6.0.: 45); further details on a person's marriages are found in the Family Record), property and social security number.

Functions, Occupations and Activities

EAC has a category called Functions, occupations and activities adopted from ISAAR(CPF)2's category 5.2.5. All other systems, apart from gdmxml and HR-XML (on which more later), only have elements for a person's occupation, which can be considered a subelement to Functions etc., cf. table 15. In EAC and GEDCOM XML, relevant date(s) and place(s) are connected with this element, a feature lacking in all other systems.

In gdmxml, there are no restriction on values, as long as they are interpreted as personal characteristics (cf. also next section); and in HR-XML the names can be restricted to match the context (Bartktus et al (eds.): Person Name 1.2. Recommendations 2001-Oct-11, p. 22) the <PersonName> wrapper element can then be changed to e.g. <EmployeeName> , <TaxFiler> or <SuperVisor> . Furthermore, <PersonName> can be wrapped inside another element, e.g. <Employee> with details as <OfficeLocation> and <WorkSchedule> added to the personal information.

Personal characteristics

EAC has an element called <character> for ‘distinguishing characteristics of a person, such as sex, hair color, height, and so on’. In the genealogical data bases, this element, though more broadly defined, theoretically plays an important role in the personal characterisation and overlaps some of the other elements described here.

General Context/Environment (ISAAR(CPF)2: 5.2.8. General context)

The EAC element <env> (‘environment’) is defined as ‘Information on the social, cultural, economic, and political context in which the person operated.’ (The EAC Tag Library <env> ) As with ‘Legal Status’, this is a broad definition, and it has no equivalents in the other systems.

Descriptive Entry and Other Context Data (ISAAR(CPF)2: 5.2.9. ‘Other significant information’

The EAC element <ocd> (‘Other Context Data’) and its child <descentry> (‘Descriptive Entry’) are containers for data not fitting in elsewhere. ‘Other context data’ is described as intended: ‘For textually complex information about the described entity that is not easily incorporated into one of the other named elements within <condesc> , i.e. Context Description, a container element for e.g. <eacrels> . When converting authority records to an EAC compliant format, the <ocd> element helps to minimize conversion difficulties by designating as "OCD" information that does not fit easily into one of EAC's more distinct categories. The element should be used with restraint and only after carefully considering the consequences that unspecified content designation poses for searching, retrieving, and displaying information in a networked environment.’ A ‘descriptive entry’, related to character description, is defined thus: ‘ <descentry> provides a means to extend the available descriptive categories. Its meaning will be dependent of the context in which it occurs, and the specifications entered in the TYPE attribute.’

For EAC elements, cf. Appendix 1.

Points for discussion The former six categories Legal Status, Functions, Occupations and Activities, Characteristics and Environment, Other Context Data and Description Entry have no counterparts in TEI.

RELATIONSHIPS

In ISAAR(CPF)2 there are two ways of defining relationships: with 5.2.7 Internal structures/Genealogy, a category restricted to descriptions of corporate bodies and families, and within the Relationships Area 5.3. with a specification of Name/identifier of related corporate bodies, persons or families 5.3.1, the Category of relationship 5.3.2., the Description of relationship 5.3.3., and the Dates of relationship 5.3.4.

The systems investigated which operate with relationships are TEI P5, EAC, NOMEN, GEDCOM XML, gdmxml, and — to some extent — xNL. In table 17 all these are treated, apart from gdmxml, which cannot be easily compared with the other systems and is therefore described separately. The table below is classified according to ISAAR(CPF)2's categories, as described above.

In xNL, when two names are treated together they are linked in something called a <JointPersonName> . <DependencyName> , a sub element of <PersonName> , can be used in those cases when a dependency relationship is present. The type of relationship is identified by the attribute @PartyType, and the category of the relationship by the attribute @DependencyType.

In GEDCOM XML, lineage relations are dealt with in the Family Record, which will not be treated here. The identity of any other associated is created by the element <AssocIndiv> and a <Link> to the person's Individual Record. The way in which the associated individuals are connected is marked by <Association> , the association linked to the referencing individual. Description and dates can be added in <Note> .

In NOMEN, the name of the related and the category of the relation — personal as well as social — is expressed in the @relationship of <Affiliatio> .

gdmxml works with the broad category group. According to the documentation (Fugal 2002: gdmxml - an XML schema for the GENTECH Genealogical Data Model and fugl.xml), the elements of the group are only internally linked, and not as in GEDCOM XML, linked to independent biographies. The type of the group is determined by its @id and by the <name> . As in NOMEN the relation can be located, if needed, by the attribute @place-ref. The persons in the group are given some roles, by the @id, in <group-type-role> , and the individual persons are referred to with a <persona> -tag.