Properties are items of data extracted and summarised from a given data source, such as name, age, or occupation. As extracted forms of information they therefore share the same requirements as marked-up references in terms of supporting transcription issues (e.g. uncertain characters, strikethrough) and separating the interpretation from the original value.


The value of virtually all Properties, whether they’re applicable to a Person, Animal, Place, or Group, will be relevant to a given date. When these subject entities are associated with an Event then it will provide that date context, in addition to other context such as a Place and supporting sources. See Time-dependent Attributes for further discussion.


Static Property values may be associated directly with a subject entity, but these are rarer. An example for a Person entity might be their blood group.


The full syntax for defining Properties, and for providing values, may be found at: Extended Properties. This scheme is fully open to custom properties. The ones presented below are the predefined ones associated with the namespace.




<PropertyDef Name=’Name’  Type=’PersonRef’/>

The personal name of the person, as recorded in the supporting source. On a birth certificate, this would also be used for the mother’s maiden name(s).


<PropertyDef Name=’Age’ Units=’y,m,w,d’ Type=’Measure’/>

The age of the person, usually at the start of the current event. Default unit is ‘y’ (years) but also valid are ‘m’ (months), ‘w’ (weeks), and ‘d’ (days). The value may be fractional, e.g. 6.5 years, in which case the decimal point character is strictly prescribed under Locale-independence. Currently, no multi-unit ages are allowed, e.g. 3y 2m.


Note that the recorded age may follow different conventions in different sources and some narrative comment would be well placed. For instance, in the 1841 census of England and Wales, the age was rounded down to the nearest multiple of 5 for over fifteens. In the Canadian census, the requested age was at “next birthday” before 1881 and at “last birthday” from 1881,


<PropertyDef Name=’Occupation’ Type=’Text’/>

The occupation, profession, or rank of the person.


<PropertyDef Name=’Employer’ Type=’Text’/>

The name of the person, organisation, or institution employing the person.


<PropertyDef Name=’WorkPlace’ Type=’PlaceRef’/>

Place of work or employment.


<PropertyDef Name=’Role’ ItemList=’1’ Type=’EnumList’/>

The role(s) of a person in a multi-subject Event. Role values depend on the context but include Head, Visitor, Inmate, Boarder, Lodger, Servant, Child, Bride, Groom, Witness, and Informant from the namespace. See Event Types and Roles for more details, and see Extended Vocabularies for custom roles.


<PropertyDef Name=’Status’ ItemList=’1’  Type=’Enum’/>

Status values depend on the context but includes the predefined values: Married, Unmarried, Divorced, Widow(er), Stillborn, Deceased, Absent (crossed-out), and Implied (i.e. mentioned but not present) from the namespace. The default is blank, i.e. none. See Extended Vocabularies for custom status values.


<PropertyDef Name=’Relationship’ ItemList=’1’  Type=’PersonEL’/>

The relationship of a person to another subject in a multi-subject Event. Relationships are always relative to a specific person (e.g. Wife, Brother, Son-in-law) and contrast with Roles which are relevant to the Event itself. See Relationships for details of the namespace, and see Extended Vocabularies for custom relationships.


<PropertyDef Name=’ResidencePlace’ Type=’PlaceRef’/>

Residential address. This is not the same as the Place that the Event occurred at.


<PropertyDef Name=’BirthPlace’ Type=’PlaceRef’/>

Place of birth.


<PropertyDef Name=’CauseOfDeath’ Type=’Text’/>

A description of the cause of death.


<PropertyDef Name=’Disability’ Type=’Text’/>

A description of some debility, infirmity, or disability.


<PropertyDef Name=’GroupEnter’ Type=’GroupRef’/>

<PropertyDef Name=’GroupLeave’ Type=’GroupRef’/>

Indicates that the person was becoming a member of the indicated group, or leaving it. Although this information will eventually contribute to the Person’s <MemberOf> element, note that these Property values are evidence rather than conclusion, and so may differ in different sources.


<PropertyDef Name=’DateOfReg’ Type=’Date’/>

Date of registration or recording of the information source. This is not the same as the Event date derived from that source. For instance, date of birth registration as opposed to date of birth itself. NB: This generic Property should be used sparingly as using an equivalent Event provides more options, e.g. using Constraints to sequence, say, a birth event before the civil registration of that birth.


<PropertyDef Name=’RegPlace’ Type=’PlaceRef’/>

Place of registration or recording of the information source. This is not the same as the Event location derived from that source. For instance, place of marriage registration as opposed to place of the wedding itself.



Any custom Person properties can also be used in the context of PERSON_PROPERTY. See Extended Properties.


Note that property names such as ‘FathersName’, ‘MothersAge’, etc., are strongly discouraged. Properties should be associated directly with a relevant Person entity, not indirectly.


Q: How should the living/non-living status of a Person best be represented? It's obviously problematic since the absence of a death date may just mean you don't know rather than the person is living. Adding a simple "is-living" flag would not work because it could never be kept up-to-date, especially if copies of the data are persisted (in STEMMA) or exchanged with other products.