Data Model

1        Introduction

2        History

3        Goals

3.1       Balance between Human versus Machine

3.2       Structured Narrative

3.3       Events

3.4       Places

3.5       Persons

3.6       Evidence and Timelines

3.7       Inheritance

4        Data Model Case Studies

4.1       Evidence and Timelines

4.2       Multi-Source Events

4.3       Personal Events

4.4       Dual Dates

4.5       Multi-Role Event

4.6       Complex Citation

4.7       Multiple Births Spanning Midnight

4.8       Recording Oral History

4.9       Evidence, Reasoning, and Conclusion

4.10         Transcription Anomalies

4.11         Family Units

4.12         Census Roles

4.13         Nature and Nurture

 


 

1      Introduction

This paper discusses the main ideas behind the STEMMA® Data Model. This includes the major influences, why it was structured differently to other models, and the advantages of its approach.

 

Various familiar problems are examined to show how STEMMA copes with them. These are expressed using XML syntax, and sometimes using pictures, in order to give a clear and unambiguous explanation.

 

Note: This text capitalises data entity names like Person and Place to distinguish them from the common English usage of those terms.

2      History

STEMMA was primarily a research project with the intention of creating a data format for the preservation of my own family history data. This data was as much micro-history as family history and so required more than simply Person entities and lineage. I wanted this to accommodate my data in a natural way, without having to bend any rules, and in a format that could easily transport to other locales.

 

My situation was unusual in that I did not use any commercial software products. Although I was aware of GEDCOM and GedXML, I hadn’t read a detailed definition of either. To a large extent, this gave me a free rein to design the data model as I wanted, and to not follow any precedent or industry norm. I believe that has been fruitful in finding some elegant and far-reaching ways of structuring the data, and of solving common genealogical issues.

 

Until this point, my data was actually kept in word-processor documents; one per surname and entries number according to the d'Aboville System. These documents used a semi-formal style to represent biological lineage (using indented headings), source citations, properties derived from sources, events, etc. They also made copious use of narrative for historical and biographical information, as well as for the reasoning when forming conclusions.

 

3      Goals

There were a number of design goals that STEMMA had to achieve. My background as a software architect, and my ground-up participation in software globalisation and the writing of locale systems, meant I already knew a lot of the basic design requirements. Best practices and the relevance of computer standards might have been less obvious to someone with a different background.

 

The desire to embrace multiple cultures through being culturally neutral was more an exercise in good design. My own data did not require this to any great depth.

 

The remainder of this section briefly discusses some of the thoughts and desires influencing my design.

 

3.1    Balance between Human versus Machine

This is a subtle issue, and one that’s hard for some people to accept. It involves the balance between how much is for (and by) the computer, and how much is for (and by) humans. Even computer professionals have been known to get this wrong, and consider things too much from the human perspective.

 

A classic example concerns the data that is stored in a file. If it is to be transportable between people of different locales then it must be expressed in a locale-independent way – one designed for the computer to recognise rather than humans. A good illustration in the field of date values is the ISO 8601 standard. All issues of how data is presented to the user, including the formatting of dates, descriptions of types for persons/places/events, and citation styles, should be under the control of your software product. It has the responsibility for converting its locale-independent computer format into something with the correct cultural and regional formatting for the current end-user.

 

There are related issues beyond this, though. We should recognise that there are other things that will be the responsibility of a software product and that do not need to be accommodated in the data format. As well as formatting according to a user’s regional settings or personal preferences, there is data entry. The way that a date is entered and assimilated, or a personal name, or a place name, is something your software does. What is written to the data file is the computer-readable version, usually supplemented by a transcription of the original data or an image of it.

 

Another issue is the process involved in researching, recording, and analysing micro-history data. There are documented standards such as the Genealogical Proof Standard but they should be the choice of the human, or the software product, and should not be a fundamental part of the data’s representation.

3.2    Structured Narrative

There is a tendency for genealogy to be too formal and data-centric when considering computer representations. For instance, adding specific record types for every conceivable facet, including level-by-level reasoning to represent a proof-argument, or relying on a dictionary of “genealogical variables”. However, much is lost if this approach is followed to its conclusion. Consider a published biography, for instance. This can express all manner of information about a person, their family, and the places where they lived or worked. Most existing data formats would find it virtually impossible to represent such a volume of work in a usable way (TEI being a possible exception). On the other hand, even with an index and full use of citations, a typical biography could not be adequately integrated with your other data.

 

STEMMA must be capable of including copious amounts of narrative but it needs to be ‘structured’. This is far more than a simple NOTE or COMMENT feature. It means having marked-up text segments integrated with, and cross-linked with, the overall data schema. The mark-up has to facilitate semantics, presentation, original emphasis, transcription anomalies, distinguishing evidence from inference, and the generation of reference-note citations and general annotation-style notes. It could be argued that this is essential to make the jump from genealogical data to micro-history data.

 

There are two very important functional categories of text that have to be supported:

 

  • Transcriptions – requires support for anomalies (uncertain characters, marginalia, footnotes, interlinear/intralinear notes), indications of original emphasis (e.g. italics), indications of alternative spellings/meanings, and semantic mark-up for references to persons, places, groups, events, and dates. The latter semantic mark-up also needs to clearly distinguish objective information (e.g. that a reference is to a person) from subjective information (e.g. a conclusion as to whom that person is).
  • Narrative work – requires support for layout and presentational mark-up. It needs to be able to generate references to known persons, places, and dates that result in a similar mark-up to that for transcriptions. The difference here is that a textual reference is being generated from the ID of a Person entity, say, as opposed to marking an existing textual reference and possibly linking it to a Person with a given ID. Also needs to be capable of generating citations and general annotations.

 

Too often, evidence is considered to be something external to your data (e.g. in an external document or online) that needs no representation within your data.

 

Identifying references to people is a good example. If the text contains an element that identifies a reference to a Person entity, defined elsewhere in your data, then:

 

  • Software can decide what name to replace that reference with. Remember that a person may have multiple names, or there may be several people with the same name and so you may want to see it annotated (e.g. with their year of birth).
  • Software can decide on the style of its presentation. I absolutely detest the Stone-Age convention of storing surnames in uppercase, or even between slashes. Uppercasing a surname does not transport well to other cultures, and is effectively a corruption of the name, but it is totally unnecessary at the data level. Once software knows a piece of text is a Person reference then it can be represented in whatever way the current end-user would like.
  • Software can automatically convert such references into hyperlinks.

 

3.3    Events

Events (i.e. something that happened on a particular date) are extremely important in micro-history data. They allow timelines to be created in order to present a chronological history. More than mere dates could alone, Events can provide a single focal point that links multiple Persons/Groups and a Place. They also provide a single point at which the relevant sources can be cited. I therefore wanted to represent Events as top-level entities with their own identifiers.

 

From an historical point of view, events are rarely constrained to a single date. Most have a significant duration, and some can be subdivided into smaller events to give a more detailed depiction. STEMMA therefore had to support lengthy, or protracted, Events as well as hierarchical Events if it was going to model real-life events.

 

3.4    Places

In just the same way that we may have biographical narrative and pictures associated with a person, then we may have historical narrative and pictures associated with a place. Places tend to undervalued in family history but they share many aspects with persons (e.g. variable names, parentage, association with events) so I needed them as top-level entities.

 

Treating Place in an analogous fashion to Person enhances the possibility that STEMMA could be applied to One-Place Studies.

 

I wanted to take full advantage of correlating place references and, for instance, finding ancestors who lived nearby, or even next door. To this end, I needed a scheme that provided unique references to every place, right down to the level of a household, and provided hierarchical information about where every place was located in terms of bigger places.

 

3.5    Persons

I wanted to capitalise on the many similarities between the requirements of place names and personal names. I wanted to generalise the requirements so that a single mechanism could be used.

 

STEMMA doesn’t provide any specific entity to represent a family, or even a marriage. The only universal concepts for every person are their birth, their two biological parents, and their death. All other aspects are subject to cultural differences (e.g. what constitutes a marriage?) and inference (what constitutes a family unit?). Instead, STEMMA needed a general event concept that, in conjunction with a system of roles, could model any type of union. It also needed a general Group concept that could be used to model any notion of a family.

 

The Group concept should be applicable to simple Sets of Persons, as well as modelling real-world entities such as organisations, regiments, etc. Groups should take advantage of the similar support offered for Person and Place in terms of alternative names, events, evidence, narrative, etc.

 

I wanted the option of having my Person entities disjoint, meaning that they might not constitute a single tree or network. There might be isolated groups or individuals, including non-relatives who happened to play an important part in a family’s history. It also enhances the possibility that STEMMA may be applied to One-Name Studies.

 

3.6    Evidence and Timelines

I needed a way of recording “pockets of evidence” against each Person, Group, or Place. This is not unusual in itself, and is essentially what a persona is in other models. However, over 95% of evidence is of a temporal nature, and related to something that happened on a particular date, or range of dates. Since I wanted to be able to create timelines, I needed to associate the evidential data with an Event rather than directly with the source. The Event is effectively an intermediary to the source of the data.

 

As an example, consider a birth registration. There would be a single Event for the birth, and several Persons would be associated with it – including the child (or children) being born. The evidential properties relating each Person, such as their residence and occupation, would be associated with each Event-to-Person linkage, not directly with either the shared Event or the source description.

 

3.7    Inheritance

In order to avoid duplication, and reduce the risk of errors, I wanted an inheritance mechanism where details of an event, source citation, or a resource could be taken from a prior instance.

 

For example, if several pages of a book were cited then it could factor out all the common details, such as title and author, and then each derived citation need only specify the information that differs, such as a chapter or page. A similar situation occurs with an event such as a census night. Details such as the date, and some parts of the census reference, could be inherited from a single definition.

 

 

4      Data Model Case Studies

This section will take a closer look at some important parts of the STEMMA Data Model. Their importance will be illustrated with specific use cases based on familiar genealogical problems.

4.1    Evidence and Timelines

In this section, I want to illustrate how STEMMA deals with evidence, and how it incorporates that evidence into what is sometimes termed a “conclusion model”.

 

The following diagram shows entities for two people (Person 1 and Person 2). They have distinct parents but have two shared Events that they were both present at (e.g. a census).

 

Every STEMMA Person can have a direct link to their biological parents (if known), and to a single birth Event and possible death Event. In this diagram, the mothers, and probably the fathers, should also have shared the respective birth Events with their children but that was omitted for clarity.

 

The importance of this evidence mechanism concerns the Properties provided for each Person (or other subject entity, such as Place/Group) by the underlying source data (e.g. an age, or occupation). Such Properties are specific to a subject entity and to the supporting source, but are generally specific to a given date too. Rather than associate them directly with the subject entity, or the supporting source, or even the Event, STEMMA associates them with each Event-to-entity link. Since the Event will reference the source already then this is the natural way to attach the Properties. Doing the same for multiple Events provides a valuable timeline for a Person’s life.

 

Note that these Properties are purely the items of evidence gleaned from the supporting source(s). A Person’s full name(s), sex, birth event, death event, and parentage are part of the conclusion model and are represented separately from the items of evidence. If the Properties from those sources include ages, dates of birth, and places of birth then these may be consolidated to form a conclusion birth Event – the Person does not have multiple birth Events (i.e. one for each source).

 

 

 

Let’s examine the syntax used for this mechanism. The following STEMMA fragment indicates that EventA occurred on 1861-04-07 and is supported by one cited source. EventB occurred on 1864-11-17 and is also supported by For the purpose of illustration, only one Property (Age) is derived for each Person from each of the sources, below. Although superfluous to the illustration, we’ve also used custom Event-types in this fragment.

 

<Dataset Name=’Timeline’ xmlns:ev=”http://vocab.company.org/events”>

 

<Person Key=’pPerson1’>

<FatherPersonLnk Key=’pFather1’/>

<MotherPersonLnk Key=’pMother1’/>

 

<Birth><EventLnk Key=’eBirth1’>

… properties ...

</EventLnk></Birth>

<Death><EventLnk Key=’eDeath1’>

… properties ...

</EventLnk></Death>

</Person>

 

<Person Key=’pPerson2’>

<FatherPersonLnk Key=’pFather2’/>

<MotherPersonLnk Key=’pMother2’/>

 

<Birth><EventLnk Key=’eBirth2’>

… properties ...

</EventLnk></Birth>

<Death><EventLnk Key=’eDeath2’>

… properties ...

</EventLnk></Death>

</Person>

 

<Event Key=’eEventA’>

<When Value=’1861-04-07’/>

<Type> ev:FamilyMeeting </Type>

<References>

<PersonRef Key=’pPerson1’>

<Property Name=’Age’>26</Property>

</PersonRef>

<PersonRef Key=’pPerson2’>

<Property Name=’Age’>10</Property>

</PersonRef>

<CitationLnk Key=’cSourceA’/>

</References>

</Event>

 

<Event Key=’eEventB’>

<When Value=’1864-11-17’/>

<Type> ev:FamilyMeeting </Type>

<References>

<PersonRef Key=’pPerson1’>

<Property Name=’Age’>29</Property>

</PersonRef>

<PersonRef Key=’pPerson2’>

<Property Name=’Age’>13</Property>

</PersonRef>

<CitationLnk Key=’cSourceB’/>

</References>

</Event>

 

</Dataset>

 

From this, we might conclude that Person1 was born between 1834-11-18 and 1835-04-07, and Person2 was born between 1850-11-18 and1851-04-07. We can therefore construct a birth Event for each Person and indicate the dates are within those ranges, even without a birth certificate or other birth-related source. Narrative elements can indicate how those figures were derived. Our birth Events, in this case, would then be conclusion entities rather than directly citing a birth-related source. The Person’s biological parentage, birth sex, and even their name(s), are also conclusions. In contrast, the References element provides evidential data from a given source.

 

When a Person entity is loaded, the identification of the birth/death Events, their name, their sex, and the links to biological parents supports the concept of traditional family trees and pedigree charts. However, the collected Events connected to that Person can be used to create a timeline for their life.

 

Relationships between people, and particularly unions such as marriage, may be inferred from shared Events, and the Roles or Relationships those people had in those shared Events.

 

4.2    Multi-Source Events

OK, you might be about to ask ‘what happens if you have multiple sources supporting those Events, and the Properties from each are not identical?’ Considering just EventA, for a second, this situation might be represented as follows:

 

 

 

 

In other words, SourceA1 and SourceA2 both support EventA, and are both cited from EventA using different CitationLnk elements, but they yield slightly different Properties or Property values. A real-life example might be a marriage supported by both a certificate and a newspaper notice. How does the Event reflect this situation for each Person?

 

This is quite easy in STEMMA because each Event can have multiple Reference elements, and these can each cite a different source. Let’s look at a modified version of the above fragment:

 

<Person Key=’pPerson1’>

... etc ...

 

<EventLnk Key=’eEventA’>

<DetailLnk Key=’eEventA-Src1’>

</DetailLnk>

<DetailLnk Key=’eEventA-Src2’>

 

</DetailLnk>

</EventLnk>

</Person>

 

</Person>

 

<Event Key=’eEventA’>

<When Value=’1861-04-07’/>

<Reference Key=’erEventA-Src1’>

<PersonRef Key=’pPerson1’>

<Property Name=’Age’>26</Property>

</PersonRef>

<PersonRef Key=’pPerson2’>

<Property Name=’Age’>10</Property>

</PersonRef>

<CitationLnk Key=’cSourceA1’/>

</Reference>

<Reference Key=’erEventA-Src2’>

<PersonRef Key=’pPerson1’>

<Property Name=’Age’>27</Property></PersonRef>

<PersonRef Key=’pPerson2’>

<Property Name=’Age’>10</Property>

<Property Name=’Name’>Jack</Property>

</PersonRef>

<CitationLnk Key=’cSourceA2’/>

</Reference>

</Event>

 

4.3    Personal Events

In many cases, an Event in a Person’s timeline will not affect anyone else in the data. We still need to provide a date, event-type, source citations, and other similar information, but it should not be necessary to create a top-level Event entity with a unique name, and give that Person an associated role.

 

Purely for convenience, STEMMA provides a localised Event element called an Eventlet. Note that this only really presents personal events when it is employed in a Person entity, but the Eventlet element is also valid within Place and Group entities.

 

Let’s return to the previous example in Evidence and Timelines. If Person 2 is the only one relevant to Events eEventA and eEventB then they can both be replaced by Eventlets as follows:

 

<Person Key=’pPerson2’>

... etc ...

 

<Eventlet>

<When Value=’1861-04-07’/>

<Type> ev:FamilyMeeting </Type>

<References>

<PersonRef>

<Property Name=’Age’>10</Property>

</PersonRef>

 

<CitationLnk Key=’cSourceA’/>

</References>

</Eventlet>

 

<Eventlet>

<When Value=’1864-11-17’/>

<Type> ev:FamilyMeeting </Type>

<References>

<PersonRef>

<Property Name=’Age’>13</Property>

</PersonRef>

<CitationLnk Key=’cSourceB’/>

</References>

</Eventlet>

</Person>

 

Notice that the PersonRef is not allowed to have an explicit Key in an Eventlet.

 

Moving on to the extended version of this example in Multi-Source Events, Person 2 now has two information sources supporting the first of those events.

 

<Person Key=’pPerson2’>

... etc ...

 

<Eventlet>

<When Value=’1861-04-07’/>

<Type> ev:FamilyMeeting </Type>

<References>

<PersonRef>

<Property Name=’Age’>10</Property>

</PersonRef>

<CitationLnk Key=’cSourceA1’/>

</References>

<References>

<PersonRef>

<Property Name=’Age’>10</Property>

<Property Name=’Name’>Jack</Property>

</PersonRef>

<CitationLnk Key=’cSourceA2’/>

</References>

</Eventlet>

 

... etc ...

</Person>

 

 

4.4    Dual Dates

The concept of Dual Dates (aka Double Dates) is discussed in the research notes under Dates and Calendars. This example will represent the date “12/23 Feb 1750/1751” as a STEMMA Date entity. Note that this example is a full-blown dual date rather than a simple double year. It actually represents 12 February 1750 in the (Old Style) Julian calendar, and 23 February 1751 in the (New Style) Gregorian calendar.

 

<Date>

            <Narrative><Text> Example dual date </Text></Narrative>

<Value Calendar=’Gregorian’> 1751-02-23 </Value>

<Value Calendar=’Julian’> 1750-02-12 </Value>

</Date>

 

In the syntax of the Date element, the date values (i.e. std-date, using the STEMMA terminology) can specify explicit calendar prefixes. In this instance, the calendar indication is not required in the date values since it is provided by the Calendar attribute, although other contexts may not have that available. Unfortunately, there is no available encoding standard for other calendars at the time of writing, and this is discussed further in the aforementioned research notes.

 

On looking at the code sample above, you might be asking where the original transcription of the date is. Well, this date entity could be used in a conclusion context, e.g. as a date in an Event definition, or in an evidence context, e.g. associated with a transcription.

 

The following is an example use within a transcription from some source.

 

<Narrative><Text Transcript=’1’>

The example dual date is <DateRef> 12/23 Feb 1750/1751

<Date>

<Value Calendar=’Gregorian’> 1751-02-23 </Value>

<Value Calendar=’Julian’> 1750-02-12 </Value>

</Date>

</DateRef>

</Text></Narrative>

 

The next example is for the value of a date Property. Remember that a STEMMA Property is just an extracted item of information from a source.

 

<Property Name=’DateOfReg’> 12/23 Feb 1750/1751

<Date>

<Value Calendar=’Gregorian’> 1751-02-23 </Value>

<Value Calendar=’Julian’> 1750-02-12 </Value>

</Date>

</Property>

 

In both cases, the original text is included verbatim, and supplemented by a date entity representing the computer-readable dates. If the computer-readable date were simpler, such as a normal Gregorian date, then the date entity could be replaced with a STEMMA date value string. For instance:

 

<Property Name=’DateOfReg’ Value=’17-03-1903’> St Patrick’s Day, 1903

</Property>

 

Also, any transcription anomalies, such as uncertain characters, struck-out text, or alternative spellings, can be marked-up in the original value. For instance, the following would highlight a typographical error:

 

<Property Name=’DateOfReg’ Value=’17-03-1903’>

St Patrick’s <Alt Value=’Day’>Dat</Alt>, 1903

</Property>

4.5    Multi-Role Event

This example looks at an Event where a Person may have multiple roles. It will use a club social event but to make it more interesting it introduces some custom role types and a custom Property.

 

<Dataset Name=’Multi_Role_Example’

xmlns:roles=’http://mydomain.com/roles’

xmlns:props=’mailto:name@emaildomain.com?subject=properties’>

 

<ExtendedProperties>

<PersonProperties>

<PropertyDef Name=’props:MemberID’  Type=’Integer’/>

</PersonProperties>

</ExtendedProperties>

 

<Event Key=’eClubSocial’>

<When Value=’1960-06-09’/>

<Type> Social </Type>

</Event>

 

<Person Key=’pGordonBennet’>

…details of Gordon Bennet…

</Person>

 

<Event Key=’eClubSocial’>

<References>

<PersonRef Key=’pGordonBennet’>

<Property Name=’Role’>

<Item Value=’roles:Photographer’/>

<Item Value=’roles:Host’/>

</Property>

<Property Name=’props:MemberID’>2314</Property>

</PersonRef>

<CitationLnk Key=’cClubSocial’/>

</References>

</Event>

 

</Dataset>

 

In other words, Gordon Bennet was both the host and the photographer at the club meeting, and his membership ID was 2314.

4.6    Complex Citation

This illustration involves a complex citation, i.e. a reference note that includes multiple simple citations and discursive notes. A reference note normally uses analytical notes to comment on the quality or credibility of the associated source. This example is really commentary since it is making a general point of interest, although this does involve references to specific sources.

 

The scenario is broken down using a general footnote that includes multiple inline simple citations.

 

 

Again, let’s examine this as it might be expressed in STEMMA.

 

<Dataset Name=’Example’ xmlns:DC=’http://purl.org/dc/elements/1.1/’>

 

<Citation Key=’cBookMultiAuthor’ Abstract=’1’>

<Title> Generic citation for published multi-author books </Title>

<URI> http://stemma.parallaxview.co/source-type/book/multiauthor  </URI>

<Params>

<Param Name=’Authors’ SemType=’DC:Creator’ ItemList=’1’/>

<Param Name=’Title’ SemType=’DC:Title’/>

<Param Name=’Publisher’ SemType=’DC:Publisher.CorporateName’/>

<Param name=’PublisherAddr’ SemType=’DC:Publisher.CorporateName.Address’/>

<Param Name=’Date’ Type=’Date’ SemType=’DC:Date’/>

<Param Name=’Pages’  Optional=’1’ ItemList=’1’/>

</Params>

</Citation>

 

<Citation Key=’cTolkiensGedling1914’>

<Title> Tolkien’s Gedling </Title>

<BaseCitationLnk Key=’cBookMultiAuthor’/>

<Params>

<Param Name=’Authors’>

<Item> Andrew H. Morton </Item>

<Item> John Hayes </Item>

</Param>

<Param Name=’Title’> Tolkien's Gedling, 1914: The Birth of a Legend </Param>

<Param Name=’Publisher’> Brewin Books </Param>

<Param name=’PublisherAddr’> Warwickshire, UK </Param>

<Param Name=’Date’>2008</Param>

</Params>

 

<Narrative><Text Abstract=’1’>

In late September 1914, J.R.R. Tolkien, his life in crisis, visited his Aunt Jane's Phoenix Farm in Gedling near Nottingham. The poem he wrote there on September 24th, "The Voyage of Earendel the Evening Star", was the spark that ignited the whole of his later mythology. Focusing on this single event, the authors set out to discover more about Phoenix Farm, Jane Neave and the poem. (information from www.nottinghambooks.co.uk)

</Text></Narrative>

</Citation>

 

<Citation Key=’cJRRTolkienGuide’>

<Title> Tolkien Companion Guide </Title>

<BaseCitationLnk Key=’cBookMultiAuthor’/>

<Params>

<Param Name=’Authors’>

<Item> Christina Scull </Item>

<Item> Wayne G. Hammond </Item>

</Param>

<Param Name=’Title’> JRR Tolkien companion & guide </Param>

<Param Name=’Publisher’> Houghton Mifflin </Param>

<Param name=’PublisherAddr’> Boston, MA </Param>

<Param Name=’Date’>2006</Param>

<Param Name=’Pages’>334</Param>

</Params>

</Citation>

 

<Place Key=’wNotts’>

<Title> Nottinghamshire </Title>

<Type> County </Type>

<PlaceName> Nottinghamshire </PlaceName>

</Place>

 

<Place Key=’wGedling’>

<Title> Gedling </Title>

<Type> Village </Type>

<PlaceName> Gedling </PlaceName>

<ParentPlaceLnk Key=’wNotts’/>

</Place>

 

<Place Key=’wPhoenixFarm’>

<Title> Phoenix Farm </Title>

<Type> Building </Type>

<PlaceName> Phoenix Farm </PlaceName>

<ParentPlaceLnk Key=’wGedling’/>

 

<CitationLnk Key=’cTolkiensGedling1914’/>

</Place>

 

<Place Key=’wGrangeCrescent’>

<Title> Grange Crescent </Title>

<Type> Street </Type>

<PlaceName> Grange Crescent </PlaceName>

<ParentPlaceLnk Key=’wGedling’/>

 

<Narrative Key=’nPhoenixFarm’>

<Text>

According to <CitationRef Key=’cTolkiensGedling1914’ Mode=’RefInline’/>, nearby <PlaceRef Key=’wPhoenixFarm’/> was the inspiration for Tolkien’s stories of Middle Earth. This is also confirmed in <CitationRef Key=’cJRRTolkienGuide’ Mode=’RefInline’/>.

</Text>

</Narrative>

 

<!-- A reference to this note could be generated as a footnote as follows -->

 

<Narrative><Text>

Example narrative text.<NoteRef NoteKey=’nPhoenixFarm’ Mode=’Footnote’/>

</Text></Narrative>

</Place>

 

This example illustrates the inheritance mechanism by having both book citations derive common details from a base-citation, analogous to a base class in software programming. Although both the book citations are self-contained, it is possible to specify explicit parameter values in the respective CitationRef elements. A good example of this feature is for specifying alternative page references from the same book.

 

The importance of this example is not so much in that it references two books in some commentary, but that there is sufficient flexibility in the mechanisms to achieve this. STEMMA handles the more conventional issues, such as adding analytical notes or having real multi-source citations, using this same capability of allowing inline citation strings embedded in a general footnote/endnote. A more readable introduction to this feature may be found at: Cite seeing.

 

4.7    Multiple Births Spanning Midnight

There are few real-life instances of this scenario but it is often wheeled out as a difficult problem: how do you represent two twins who are born either side of midnight in their local time?

 

The essence of the problem is that they have different dates of birth, and yet they are twins and effectively share the same birth event. If you try to ignore that sharing, and treat each birth independently, then you lose the fact that they are twins.

 

STEMMA has a couple of possible ways of representing this. The easiest way is to simply treat the Event as having a duration so it begins before midnight and ends after midnight. This is not really satisfactory, though, because you cannot give distinct birth dates to each twin, and you do not know which was born first.

 

The recommended way is to use a hierarchical Event. Each twin would have their own distinct birth Event, but there would be a higher-level Event representing the ‘birth experience’, for want of another term, that would span the two births. That higher-level Event would nominate each of the separate birth Events as its start and end as appropriate. The roles of the parents would be associated with the shared Event whereas those of the children would be in their respective birth Events.

 

A real-life case may be found at: Twins born in different years. We’ll use these details as reported in the newspapers as the basis for a local example, and we’ll assume that relevant birth certificates would not substantially disagree if we had them.

 

<Person Key=’pFather’>

<Sex> 1 </Sex>

<PersonName> Thomas Rosputni </PersonName>

</Person>

 

<Person Key=’pMother’>

<Sex> 0 </Sex>

<PersonName> Brighid Maura O’Brien Rosputni </PersonName>

</Person>

 

<Person Key=’pRonan’>

<Sex> 1 </Sex>

<FatherPersonLnk Key=’pFather’/>

<MotherPersonLnk Key=’pMother’/>

 

<Birth><EventLnk Key=’eRonanBirth’/></Birth>

</Person>

 

<Person Key=’pRory’>

<Sex> 1 </Sex>

<FatherPersonLnk Key=’pFather’/>

<MotherPersonLnk Key=’pMother’/>

 

<Birth><EventLnk Key=’eRoryBirth’/></Birth>

</Person>

 

<Event Key=’eBirthExperience’>

<Type> Birth </Event>

<References>

<PersonRef Key=’pMother’>

<Property Name=’Name’> Brighid Maura O’Brien Rosputni </Property>

<Property Name=’Role’> Mother </Property>

</PersonRef>

<PersonRef Key=’pFather’>

<Property Name=’Name’> Thomas Rosputni </Property>

<Property Name=’Role’> Father </Property>

</PersonRef>

<CitationLnk Key=’cIrishCentral’/>

</References>

</Event>

 

<Event Key=’eBirthRonan’>

<Type> Birth </Event>

<When Value=’2011-12-31’/>

<ParentEvent Key=’eBirthExperience’/>

<PlaceLnk Key=’wBuffalo’/>

<References>

<PersonRef Key=’pRonan’>

<Property Name=’Name’> Ronan Rosputni </Property>

<Property Name=’Role’> Child </Property>

</PersonRef>

<CitationLnk Key=’cIrishCentral’/>

</References>

</Event>

 

<Event Key=’eBirthRory’>

<Type> Birth </Event>

<When Value=’2012-01-01’/>

<ParentEvent Key=’eBirthExperience’/>

<PlaceLnk Key=’wBuffalo’/>

<References>

<PersonRef Key=’pRory’>

<Property Name=’Name’> Rory Rosputni </Property>

<Property Name=’Role’> Child </Property>

</PersonRef>

<CitationLnk Key=’cIrishCentral’/>

</References>

</Event>

 

<Citation Key=’cIrishCentral’>

<URI> http://stemma.parallaxview.co/source-type/web-media </URI>

<Params>

<Param Name=’Author’> Bernie Malone </Param>

<Param Name=’Title’> Irish American twins born in different years in historic first </Param>

<Param Name=’Publisher’> Irish Central </Param>

<Param name=’PublisherAddr’> New York, NY </Param>

<Param Name=’Date’> 2012-01-03 </Param>

<Param Name=’URL’> http://www.irishcentral.com/news/Irish-American-twins-born-in-different-years-in-historic-first-136582258.html </Param>

<Param Name=’Accessed’> 2012-07-09 </Param>

</Params>

</Citation>

 

There’s obviously more information that we could have represented here, such as Brighid’s maiden name, her father’s details, and her grandparent’s details, but this was skipped for clarity.

 

The parent Event automatically spans the discrete birth dates — which effectively define its start and end dates — and automatically uses the common wBuffalo Place of its child Events as its own effective Place.

 

The same principle can be used to model the births of triplets, etc., since the span of the parent Event will be from the earliest to the latest. Each discrete birth could even have a different PlaceLnk associated with it (see Twins Born in Different Countries), and the effective Place of the parent Event will be the largest common Place of the birth Events. Although less useful for a birth Event, this feature can be more useful for an emigration Event where embarkation and disembarkation occur in different places and on different dates. By contrast, Twins Born to Different Fathers is actually an easier variation to represent in most models, although software designers must be careful to avoid any presumption about the legality of such data.

 

 

4.8    Recording Oral History

For this example, we consider a number of conversations with a given family member, each recounting family events, and which were recorded over a period of time.

 

Let’s assume that three conversations took place on the 1st June, 12th July, and 5th August 2008. These were recorded electronically but notes were also taken.

 

<Person Key=’pGenghis’>

<Sex> 1 </Sex>

<Names>

<Sequences>

<Canonical> Genghis Khan </Canonical>

<Sequence>

<Tokens>

<Token> Genghis </Token>

<Token> Chinghiz </Token>

<Token> Chinghis </Token>

<Token> Chingiz </Token>

<Token> Temujin </Token>

</Tokens>

<Tokens>

<Token> Khan </Token>

</Tokens>

</Sequence>

</Sequences>

</Names>

 

<Eventlet>

<PlaceLnk Key=’wHospital’/>

<When Value=’2008-06-01’/>

<CitationLnk Key=’cConv1’/>

</Eventlet>

 

<Eventlet>

<PlaceLnk Key=’wHospital’/>

<When Value=’2008-07-12’/>

<CitationLnk Key=’cConv2’/>

</Eventlet>

 

<Eventlet>

<PlaceLnk Key=’wHospital’/>

<When Value=’2008-08-05’/>

<CitationLnk Key=’cConv3’/>

</Eventlet>

</Person>

 

<Place Key=’wHospital’>

<PlaceName> Home for the Terminally Bewildered </PlaceName>

</Place>

 

<Citation Key=’cConv1’>

<BaseCitationLnk Key=’cConversation’/>

<Params>

<Param Name=’Source’ Key=’pGenghis’/>

<Param Name=’Date’> 2008-06-01 </Param>

</Params>

<ResourceLnk Key=’rConv1’/>

</Citation>

 

<Citation Key=’cConv2’>

<BaseCitationLnk Key=’cConversation’/>

<Params>

<Param Name=’Source’ Key=’pGenghis’/>

<Param Name=’Date’> 2008-07-12 </Param>

</Params>

<ResourceLnk Key=’rConv2’/>

</Citation>

 

<Citation Key=’cConv3’>

<BaseCitationLnk Key=’cConversation’/>

<Params>

<Param Name=’Source’ Key=’pGenghis’/>

<Param Name=’Date’> 2008-08-05 </Param>

</Params>

<ResourceLnk Key=’rConv3’/>

</Citation>

 

<Resource Key=’rConv1’>

<BaseResourceLnk Key=’rRecordings’/>

<Params>

<Param Name=’File’> Conv_2008_06_01 </Param>

</Params>

<Narrative>

<Text Transcript=’1’ Abstract=’1’>

My ally Jamukha also wants to be a ruler of Mongol tribes.

</Text>

</Narrative>

</Resource>

 

<Resource Key=’rConv2’>

<BaseResourceLnk Key=’rRecordings’/>

<Params>

<Param Name=’File’> Conv_2008_07_12 </Param>

</Params>

<Narrative>

<Text Transcript=’1’ Abstract=’1’>

The shaman is trying to drive a wedge between me and my loyal brother, Khasar.

</Text>

</Narrative>

</Resource>

 

<Resource Key=’rConv3’>

<BaseResourceLnk Key=’rRecordings’/>

<Params>

<Param Name=’File’> Conv_2008_08_05 </Param>

</Params>

<Narrative>

<Text Transcript=’1’ Abstract=’1’>

A council of Mongol chiefs at Khuruldai acknowledged me as "Khan" of the consolidated tribes and gave me the new title Genghis Khan.

</Text>

</Narrative>

</Resource>

 

<!-- Base Entities -->

 

<Citation Key=’cConversation’ Abstract=’1’>

<URI> http://stemma.parallaxview.co/source-type/testimony-1 </URI>

<Credibility> Questionable </Credibility>

<Params>

<Param Name=’Source’ Type=’PersonRef’/>

<Param Name=’Date’ Type=’Date’/>

</Params>

</Citation>

 

<Resource Key=’rRecordings’ Abstract=’1’>

<Title> Voice recording: ${File} </Title>

<Type> Recording </Type>

<URL> file:myrecordings/sound/{$File}.mp3 </URL>

<Params>

<Param Name=’File’/>

</Params>

</Resource>

 

 

So, we have a Person entity that references three events; one for each conversation. Since these are non-shared events, and so only appear in the one person entity, their details are embedded using Eventlet elements rather than being linked using EventLnk elements. Although the events all took place at the same Hospital, the use of Eventlet precludes the example from using inheritance to take a Place reference from a generic base-Event.

 

We have three separate Citations (cConv1-3) but these inherit data such as the URI, source parameters, and information credibility, from a generic base-Citation.

 

We have three separate recordings (rConv1-3) and these inherit data such as the base URL, parameter names & types, and resource-type, from a generic base-Resource. Each Resource also includes a transcribed abstract of the associated recording.

 

The example illustrates how reuse can be achieved through inheritance and parameterisation.

4.9    Evidence, Reasoning, and Conclusion

The research notes under Evidence and Conclusion make a case for not only distinguishing evidence and conclusion (which most people would expect), but also reasoning. The rationale partly being that the level of sharing expected in collaborative trees will differ for each. BMD information is expected for constructing family trees and pedigree charts but this data is effectively part of a conclusion model. Someone will have had to research the available evidence and infer such things as lineage. The more effort goes into that research then the less inclined the researcher will be to give it away freely.

 

This tiny example focuses on the birth of a particular person and suggests how STEMMA might represent conflicting evidence, the reasoning, and the associated conclusion. The idea is that this approach can be extrapolated to more complex cases.

 

The example is actually a cut-down version of the data presented for William Elliott in the STEMMA Example section. The birth event for William is a conclusion as it is not directly backed by any citations. Although we have no birth certificate for William, we have an indication of his age from four census returns and one marriage certificate. Unfortunately, those ages are not all in agreement.

 

<Person Key=’pWilliamElliott’>

<PersonName> William Elliott </PersonName>

<Sex> 1 </Sex>

 

<Birth><EventLnk Key=’eBirthWilliamElliott’/></Birth>

</Person>

 

<Event Key=’eBirthWilliamElliott’>

<Title>Birth of William Elliott </Title>

<When><Date NoteKey=’nWilliamBirthDate’><Value> 1841 </Value></Date></When>

<Type> Birth </Type> <SubType> Birth </SubType>

<PlaceLnk Key=’wUttoxeter’/>

 

<Narrative Key=’nWilliamBirthDate’><Text Inference=’1’>

William’s date of birth here is derived from his age using:</br>

<ul>

<li><EventRef Key=’eCensusElliott1851’/> (10 => 1841)</li>

<li><EventRef Key=’eCensusElliott1861’/> (20 => 1841)</li>

<li><EventRef Key=’eMarriageElliott1862’/> (21 => 1841)</li>

<li><EventRef Key=’eCensusElliott1871’/> (31 => 1840)</li>

<li><EventRef Key=’eCensusElliott1881’/> (35 => 1846)</li>

</ul>

The 1881 census result is probably an outlier due to his age being estimated at 35 by the proprietor of <PlaceRef Key=’wCarringtonSq14’/> where he and his wife were lodging on <DateRef Value=’1881-04-03’/>.

</Text></Narrative>

</Event>

 

<Event Key=’eCensusElliott1851’>

<When Value=’1851-03-30’/>

<Title>1851 census for William Elliott</Title>

<Type> Survey </Type> <SubType> Census </SubType>

<PlaceLnk Key=’wTinkersLane’/>

<References>

<PersonRef Key='pWilliamElliott'>

<Property Name=’Age’> 10 </Property>

<Property Name=’Occupation’> Scholar </Property>

</PersonRef>

<CitationLnk Key=’cCensusElliott1851’/>

</References>

</Event>

 

<Event Key=’eCensusElliott1861’>

<When Value=’1861-04-07’/>

<Title>1861 census for William Elliott</Title>

<Type> Survey </Type> <SubType> Census </SubType>

<PlaceLnk Key=’wRussellStreet’/>

<References>

<PersonRef Key='pWilliamElliott'>

<Property Name=’Age’> 20 </Property>

<Property Name=’Occupation’> Labourer </Property>

</PersonRef>

<CitationLnk Key=’cCensusElliott1861’/>

</References>

</Event>

 

<Event Key=’eCensusElliott1871’>

<When Value=’1871-04-02’/>

<Title>1871 census for William Elliott</Title>

<Type> Survey </Type> <SubType> Census </SubType>

<PlaceLnk Key=’wSiddalsLane62’/>

<References>

<PersonRef Key='pWilliamElliott'>

<Property Name=’Age’> 31 </Property>

<Property Name=’Occupation’> Labourer in Iron works </Property>

</PersonRef>

<CitationLnk Key=’cCensusElliott1871’/>

</References>

</Event>

 

<Event Key=’eCensusElliott1881’>

<When Value=’1881-04-03’/>

<Title>1881 census for William Elliott</Title>

<Type> Survey </Type> <SubType> Census </SubType>

<PlaceLnk Key=’wCarringtonSq14’/>

<References>

<PersonRef Key='pWilliamElliott'>

<Property Name=’Age’ Surety=’10%’> 35 </Property>

<Property Name=’Occupation’> Striker Iron Foundry </Property>

</PersonRef>

<CitationLnk Key=’cCensusElliott1881’/>

</References>

</Event>

 

<Event Key=’eMarriageElliott1862’>

<When Value=’1862-03-12’/>

<Title>Marriage of William Elliott and Sarah Wildgoose</Title>

<Type> Union </Type> <SubType> Marriage </SubType>

<PlaceLnk Key=’wDerbyRegOffice’/>

<References>

<PersonRef Key='pWilliamElliott'>

<Property Name=’Age’> 21 </Property>

<Property Name=’Occupation’> Hammersman </Property>

</PersonRef>

<CitationLnk Key=’cMarriageElliott1862’/>

</References>

</Event>

 

 

What this is showing is a range of age values for William that are derived from the census returns and the marriage. The date recorded in his birth Event is therefore a conclusion formed from correlating the conflicting ages. The date of birth is annotated with a reference note indicating how the value was arrived at. A software product would indicate the presence of that reference note (for instance, with a superscript or hyperlink) whenever the date of birth is presented to the user.

 

An example of the rendered narrative text might be:

 

William’s date of birth here is derived from his age using:

  • Census of England & Wales, 1851 (10 => 1841)
  • Census of England & Wales, 1861 (20 => 1841)
  • Civil Marriage Reg. of England & Wales, 1862 (21 => 1841)
  • Census of England & Wales, 1871 (31 => 1840)
  • Census of England & Wales, 1881 (35 => 1846)

The 1881 census result is probably an outlier due to his age being estimated at 35 by the proprietor of 14 Carrington Square, Litchurch, Derbyshire where he and his wife were lodging on 3rd April 1881.

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 


Selecting any of these enumerated Events would take you to the associated details. Those details would include date and place references which would also be selectable, and the associated citations that would be formatted according to the preferred style and regional settings of the current end-user.

 

4.10Transcription Anomalies

The STEMMA model strives to represent evidence, including transcription anomalies such as uncertain characters or annotation, in conjunction with other data. It is insufficient for any data model to only focus on conclusions and the reasoning used to achieve them – evidence is part of a data collection rather than simply being something in an external document or online.

 

The image below shows the birth place for an Alfred Campbell in the 1851 census of England and Wales. This particular entry had a correction applied by the enumerator since it originally said “Chester Nantwich” but Nantwich was crossed-out and replaced with something similar to “Manchester”.

 

 

This introduces a few issues: Chester is a city rather than a county, but it is the “county town” of Cheshire. The original town of Nantwich is within Cheshire, but the new town of Manchester is not.

 

<Person Key='pAlfredCampbell'>

<Title> Alfred Campbell </Title>

<Sex> 1 </Sex>

</Person>

 

<Event Key='eCensusCampbell1851'>

<References>

<PersonRef Key=’pAlfredCampbell’>

<Property Name='Name'> Alfred Campbell </Property>

<Property Name='Age'> 11 </Property>

<Property Name='Occupation'> Calico Printer (Journeyman) Child </Property>

<Property Name='BirthPlace' Key='wManchester'> Chester <Hi S=’1’>Nantwich</Hi> <Alt Value=’Manchester’>Manchest</Alt>

</Property>

<Property Name='Role'> Lodger </Property>

<Property Name='Status'> Unmarried </Property>

</PersonRef>

<CitationLnk Key='cCensusCampbell1851'/>

</References>

</Event>

 

<Place Key=’wManchester’>

<Title> Manchester </Title>

<Type> Town </Type>

<PlaceName> Manchester </PlaceName>

<ParentPlaceLnk Key=’wLancs’/>

</Place>

 

<Place Key=’wLancs’>

<Title> Lancashire </Title>

<Type> County </Type>

<PlaceName> Lancashire </PlaceName>

</Place>

 

What this STEMMA transcription has done is to record each of the three visible words: “Chester”, “Nantwich”, and “Manchest” for the Property called ‘BirthPlace’. It records that “Nantwich” was struck-out, and it also associates an alternative spelling with “Manchest” to equate it with Manchester. However, the Key attribute on the Property is a conclusion that Alfred’s birthplace was, indeed, Manchester in the county of Lancashire.

4.11Family Units

STEMMA doesn’t include a specific Family element because the concept of a family-unit is too subjective. See under Family Units. However, its generic Group element does have some predefined types that can model most types of family unit.

 

The following illustration uses an example of a John Smith who marries a Jane Doe. They and their unmarried children constitute a traditional Nuclear family (also called a Conjugal family) from the time of their marriage. Their children are part of this unit from their birth and until their own marriages.

 

<Person Key=’pJohnSmith’>

<Title> John Smith </Title>

<Sex> 1 </Sex>

<MemberOf Key=’gJohnJaneSmith’

FromEvent=’eMarriageJohnJane’/>

</Person>

 

<Person Key=’pJaneDoe’>

<Title> Jane Smith née Doe </Title>

<Sex> 0 </Sex>

<MemberOf Key=’gJohnJaneSmith’

FromEvent=’eMarriageJohnJane’/>

 

<Names>

<Sequences BeforeEvent=’eMarriageJohnJane’>

<Canonical> Jane Doe </Canonical>

<Sequence>

<Tokens>

<Token> Jane </Token>

</Tokens>

<Tokens>

<Token> Doe </Token>

</Tokens>

</Sequence>

</Sequences>

<Sequences FromEvent=’eMarriageJohnJane’ Type=’Married’>

<Canonical> Jane Smith </Canonical>

<Sequence>

<Tokens>

<Token> Jane </Token>

</Tokens>

<Tokens>

<Token> Smith </Token>

</Tokens>

</Sequence>

</Sequences>

</Names>

</Person>

 

<Person Key=’pTomSmith’>

<Title> Thomas Smith </Title>

<Sex> 1 </Sex>

<FatherPersonLnk Key=’pJohnSmith’/>

<MotherPersonLnk Key=’pJaneDoe’/>

<MemberOf Key=’gJohnJaneSmith’

UntilEvent=’eMarriageTom’/>

</Person>

 

<Person Key=’pSarahSmith’>

<Title> Sarah Smith </Title>

<Sex> 0 </Sex>

<FatherPersonLnk Key=’pJohnSmith’/>

<MotherPersonLnk Key=’pJaneDoe’/>

<MemberOf Key=’gJohnJaneSmith’

UntilEvent=’eMarriageSarah’/>

</Person>

 

<Event Key=’eMarriageJohnJane’>

<When Value=’1920-01-30’/>

<Type> Union </Type> <SubType> Marriage </SubType>

<PlaceLnk Key=’wStElsewhere’/>

</Event>

 

<Event Key=’eMarriageSarah’>

<When Value=’1946-08-20’/>

<Type> Union </Type> <SubType> Marriage </SubType>

<PlaceLnk Key=’wStElsewhere’/>

</Event>

 

<Event Key=’eMarriageTom’>

<When Value=’1942-05-20’/>

<Type> Union </Type> <SubType> Marriage </SubType>

<PlaceLnk Key=’wStElsewhere’/>

</Event>

 

<Group Key=’gJohnJaneSmith’>

<Title> John and Jane Smith’s family </Title>

<Type> Family </Type> <SubType> Nuclear </SubType>

</Group>

 

This example also shows how dates implied by Events, as opposed to explicit dates, can be used to control both Group association and alternative personal names.

 

The example is idealised insomuch as it assumes marriage always precedes childbirth but the general approach should be clear.

4.12Census Roles

This next example picks a page from the 1861 census of England & Wales (Piece: 2560, Folio: 23, Page: 6). It contains a household for the following family of five residing at 8 Homleys Court, Heaton Norris, Stockport, Cheshire.

 

 

Many census returns have inaccuracies. However, this one is interesting because the recorded relationships are incorrect and can result in the wrong associations being recorded. In the census column headed ‘Relation to Head of Family’ there are two women with a relationship of ‘Wife’. For products that insist on recording – and indexing on – the data verbatim, this results in illegal spousal relationships and misdirected searches.

 

The details of this family should have been:

 

Name

Relation

Condition

Sex

Age

Birth Year

Occupation

Birth Place

Samuel Bradley

Head

Married

M

30

1831

Nail Maker

Belper, Derbyshire

Mary Bradley

Wife

Married

F

24

1837

Cotton Weaver

Lougborough, Leicestershire

John Bradley

Boarder

Married

M

26

1835

Slater

Belper, Derbyshire

Selina Bradley

Boarder’s Wife

Married

F

22

1839

Doubler (Cotton)

Belper, Derbyshire

George Bradley

Boarder’s Son

-

M

3

1858

-

Heaton Norris, Lancashire

 

There were several problems here though:

 

  • The relationship of Selina should have been wife to John (the boarder), not wife to Samuel (the head).
  • The surname appears to be recorded as ‘Brady’ but the family can be identified as ‘Bradley’ using other data.
  • Selina’s age was initially recorded as 26, but then corrected to 22.
  • Mary’s birth place was recorded as either ‘Longhbro’ or ‘Loughbro’ which caused some transcribers to interpret it as ‘Longborough’.

 

So how do we record the evidence and the conclusions, and justify how one relates to the other?

 

<Person Key=’pSamuelBradley’>

<PersonName> Samuel Bradley </PersonName>

<Sex> 1 </Sex>

</Person>

 

<Person Key=’pMaryBradley’>

<PersonName> Mary Bradley </PersonName>

<Sex> 0 </Sex>

</Person>

 

<Person Key=’pJohnBradley’>

<PersonName> John Bradley </PersonName>

<Sex> 1 </Sex>

</Person>

 

<Person Key=’pSelinaBradley’>

<PersonName> Selina Bradley </PersonName>

<Sex> 0 </Sex>

</Person>

 

<Person Key=’pGeorge Bradley’>

<PersonName> George Bradley </PersonName>

<Sex> 1 </Sex>

</Person>

 

<Event Key=’eCensusBradley1861’>

<When Value=’1861-04-07’/>

<Title> 1861 census for Bradley family </Title>

<Type> Survey </Type>

<SubType> Census </SubType>

<PlaceLnk Key=’w8HomleysCourt’/>

 

<Narrative>

<Text Key=’nBradySurname’ Inference=’1’>

<Title> Analysis of recorded surname </Title>

The enumerator recorded the family surname as Brady rather than Bradley. However, John and Selina can easily be identified since John married Selena Shepherd (b. c1835 in Belper, Derbys) on 16/12/1855 at Duffield, Derbys [1855/Q4/7b/764]. Their son, George, was b. 1858 in Stockport, Lancs. Registered in Heaton Norris sub-district. Local ref: [HEA/25/83];

</Text>

 

<Text>

<Title> Who is Samuel Bradley? </Title>

John Bradley had a half-brother called Samuel who was born in Belper in c1825 and was a ‘Nailer’. The birth year doesn’t quite match though. In 1851, this Samuel was unmarried and in Melton Mowbray, Leicestershire (Piece: 2091, Folio: 184, Page: 8), and this may further support the Loughborough interpretation for his wife’s birthplace.

</Text>

</Narrative>

 

<References>

<PersonRef Key=‘pSamuelBradley’ ID=’Samuel’>

<Property Name=’Name’ NoteKey=’nBradySurname’>

Samuel Brady

</Property>

<Property Name=’ResidencePlace ID=’HomleysCourt’/>

<Property Name=’Age’> 30 </Property>

<Property Name=’Occupation’>

Nail maker

</Property>

<Property Name=’BirthPlace‘ ID='Belper'/>

<Property Name=’Role’> Head </Property>

<Property Name=’Status’> Married </Status>

</PersonRef>

 

<PersonRef Key=‘pMaryBradley’>

<Property Name=’Name’ NoteKey=’nBradySurname’>

Mary Brady

</Property>

<Property Name=’ResidencePlace ID=’HomleysCourt’/>

<Property Name=’Age’> 24 </Property>

<Property Name=’Occupation’> Cotton Weaver </Property>

<Property Name=’BirthPlace‘ ID='Loughborough'/>

<Property Name=’Relationship’ ID=’Samuel’>

Wife

</Property>

<Property Name=’Status’> Married </Status>

</PersonRef>

 

<PersonRef Key=‘pJohnBradley’  ID=’John’>

<Property Name=’Name’ NoteKey=’nBradySurname’>

John Brady

</Property>

<Property Name=’ResidencePlace ID=’HomleysCourt’/>

<Property Name=’Age’> 26 </Property>

<Property Name=’Occupation’> Slater </Property>

<Property Name=’BirthPlace‘ ID='Belper'/>

<Property Name=’Role’> Boarder </Property>

<Property Name=’Status’> Married </Status>

</PersonRef>

 

<PersonRef Key=‘pSelinaBradley’>

<Property Name=’Name’ NoteKey=’nBradySurname’>

Selina Brady

</Property>

<Property Name=’ResidencePlace ID=’HomleysCourt’/>

<Property Name=’Age’ Value=’22’>

<Hi S=’1’>26</Hi> 22

</Property>

<Property Name=’Occupation’>

Doubler (Cotton)

</Property>

<Property Name=’BirthPlace‘ ID='Belper'/>

<Property Name=’Relationship’ ID=’John’>

<Alt>Wife

<Narrative><Text>

The enumerator meant that Selina was the wife of the person above (John), not of the Head of the household

</Text></Narrative>

</Alt>

</Property>

<Property Name=’Status’> Married </Status>

</PersonRef>

 

<PersonRef Key=‘pGeorgeBradley’>

<Property Name=’Name’ NoteKey=’nBradySurname’>

George Brady

</Property>

<Property Name=’ResidencePlace ID=’HomleysCourt’/>

<Property Name=’Age’> 3 </Property>

<Property Name=’BirthPlace‘ Key='wHeatonNorris'>

Lancashire Heaton Norris

</Property>

<Property Name=’Relationship’ ID=’John’>

<Alt>Son

<Narrative><Text>

The enumerator meant that George was the son of the couple above, not of the Head of the household

</Text></Narrative>

</Alt>

</Property>

</PersonRef>

 

<PlaceRef Key='wBelper' ID=’Belper’>

<Property Name=’Name’> Belper </Property>

</PlaceRef>

 

<PlaceRef Key='wLoughborough' ID=’Loughborough’>

<Property Name=’Name‘  NoteKey=’nLonghbro’>

Lo<Ucf>[nu]</Ucf>ghbro

</Property>

<Narrative Key=’nLonghbro’><Text>

The enumerator wrote either ‘Longhbro’ or ‘Loughbro’. Although some content providers have interpreted this as Longborough (a town in Gloucestershire) this means ignoring the ‘h’. If the ‘n’ is actually a ‘u’, though, then it becomes an abbreviation for Loughborough (a town in Leicestershire) which is closer.

</Text></Narrative>

</PlaceRef>

 

<PlaceRef Key=’w8HomleysCourt’ ID=’HomleysCourt’>

<Property Name=’Name’>

8 Homleys Court

</Property>

</Property>

 

<CitationLnk Key=’cCensusEngWales’>

<Param Name=’Series’>RG09</Param>

<Param Name=’Piece’>2560</Param>

<Param Name=’Folio’>23</Param>

<Param Name=’Page’>6</Param>

<Property Name=’Where’ ID=’HomleysCourt’/>

</CitationLnk>

</References>

</Event>

 

This STEMMA sample indicates how the extracted Properties from the census can be supplemented with transcriptions of the original values, and annotated with notes explaining what was recorded. In the case of the Property called ‘Relationship’, note that STEMMA allows the conclusion terms to be specific to another named individual, and so resolve the difficulties in this census.

 

  • Selina’s Relationship is corrected to ‘(John).Wife’, and George’s Relationship to ‘(John).Son’. The original written data suggested that they’re relative to the Head, i.e. Samuel.
  • The shared Event entity for this 1861 census household has a reference note providing evidence that this family is actually Bradley rather than Brady. This note is shared on the Name Property of each person is the household.
  • An indication of the struck-out age (26) for Selina is recorded, even though the interpreted value is still 22.
  • A reference note is attached to Mary’s birth place that examines the possibilities before identifying it with ‘Loughborough’.
  • References to shared places, such as the Belper birth-place and the Homley’s Court census household, are assembled once before being associated with multiple person references.

 

4.13Nature and Nurture

STEMMA emphasises that biological lineage is different to the concept of a family-unit, and that union-type Events may not be involved in either. There are still prevailing views, though, that may confuse these issues, or even maintain that they’re directly related. See Happy Families for discussion.

 

This illustration uses an example of a John Smith who conceives children with two women: Jane Doe and Ann Other. He subsequently marries the second partner after a short period of living with her and her child. His first child is part of an independent family unit despite there being no registered union.

 

<Person Key=’pJohnSmith’>

<Title> John Smith </Title>

<Sex> 1 </Sex>

<MemberOf Key=’gJohnAnnOther’

FromEvent=’eBirthSarahOther’/>

</Person>

 

<Person Key=’pJaneDoe’>

<Title> Jane Doe </Title>

<Sex> 0 </Sex>

<MemberOf Key=’gJaneDoe’

FromEvent=’eBirthTomDoe’/>

</Person>

 

<Person Key=’pAnnOther’>

<Title> Ann Smith née Other </Title>

<Sex> 0 </Sex>

<MemberOf Key=’gJohnAnnOther’

FromEvent=’eBirthSarahOther’/>

<Names>

<Sequences BeforeEvent=’eMarriageAnnOther’>

<Canonical> Ann Other </Canonical>

</Sequences>

<Sequences FromEvent=’eMarriageAnnOther’

Type=’Married’>

<Canonical> Ann Smith </Canonical>

</Sequences>

</Names>

</Person>

 

<Person Key=’pTomDoe’>

<Title> Thomas Doe </Title>

<Sex> 1 </Sex>

<MemberOf Key=’gJaneDoe’

FromEvent=’eBirthTomDoe’/>

 

<FatherPersonLnk Key=’pJohnSmith’/>

<MotherPersonLnk Key=’pJaneDoe’/>

<Birth><EventLnk Key=’eBirthTomDoe’/></Birth>

</Person>

 

<Person Key=’pSarahOther’>

<Title> Sarah Other </Title>

<Sex> 0 </Sex>

<MemberOf Key=’gJohnAnnOther’

FromEvent=’eBirthSarahOther’/>

 

<Names>

<Sequences BeforeEvent=’eMarriageAnnOther’>

<Canonical> Sarah Other </Canonical>

</Sequences>

<Sequences FromEvent=’eMarriageAnnOther’

Type=’Married’>

<Canonical> Sarah Smith </Canonical>

</Sequences>

</Names>

<FatherPersonLnk Key=’pJohnSmith’/>

<MotherPersonLnk Key=’pAnnOther’/>

<Birth><EventLnk Key=’eBirthSarahOther’/></Birth>

</Person>

 

<Event Key=’eBirthTomDoe’>

<When Value=’1919-12-25’/>

<Type> Birth </Type>

<SubType> Birth </SubType>

<PlaceLnk Key=’wSmallVille’/>

<References>

<PersonRef Key=’pJaneDoe’>

<Property Name=’Role’> Mother </Property>

</PersonRef>

<PersonRef Key=’pJohnSmith’>

<Property Name=’Role’> Father </Property>

</PersonRef>

<PersonRef Key=’pTomDoe’>

<Property Name=’Role’> Child </Property>

</PersonRef>

<CitationLnk Key=’ cBirthTomDoe’/>

</References>

</Event>

 

<Event Key=’eBirthSarahOther’>

<When Value=’1920-01-07’/>

<Type> Birth </Type>

<SubType> Birth </SubType>

<PlaceLnk Key=’wSmallVille’/>

<References>

<PersonRef Key=’pAnnOther’>

<Property Name=’Role’> Mother </Property>

</PersonRef>

<PersonRef Key=’pJohnSmith’>

<Property Name=’Role’> Father </Property>

</PersonRef>

<PersonRef Key=’pSarahOther’>

<Property Name=’Role’> Child </Property>

</PersonRef>

<CitationLnk Key=’ c BirthSarahOther’/>

</References>

</Event>

 

<Event Key=’eMarriageAnnOther’>

<When Value=’1920-01-30’/>

<Type> Union </Type>

<SubType> Marriage </SubType>

<PlaceLnk Key=’wStElsewhere’/>

<References>

<PersonRef Key=’pAnnOther’>

<Property Name=’Role’> Bride </Property>

</PersonRef>

<PersonRef Key=’pJohnSmith’>

<Property Name=’Role’> Groom </Property>

</PersonRef>

<CitationLnk Key=’ cMarriageAnnOther’/>

</References>

</Event>

 

<Group Key=’gJaneDoe’>

<Title> Jane Doe’s family </Title>

<Type> Family </Type> <SubType> Matrilocal </subType>

</Group>

 

<Group Key=’gJohnAnnOther’>

<Title> John and Ann Other’s family </Title>

<Type> Family </Type> <SubType> Nuclear </SubType>

</Group>

 

 

The most important part of this illustration is that it demonstrates how STEMMA has independent mechanisms for representing biological lineage, events & roles, and family units.



® STEMMA is a registered trademark of Tony Proctor.

Subpages (1): More Case Studies
ċ
Tony Proctor,
27 May 2013, 09:52
ċ
Tony Proctor,
27 May 2013, 09:53