Log in

HCMC Journal

MAJW 2023-08-25: rethinking encoding structures

: Martin Holmes
Minutes: 130

With the results of some investigations by AB of the some of the mysterious relationship inconsistencies, I started to look at the implications of collapsing multiple instances of the same event into one. After some discussion, we’ve settled on moving from the current scenario, in which an event has a single <linkGrp> element containing one primary and her relatives, to a system adapted from that used on <person> elements, where we use <relation> elements.

The target output inside an <event> element will look like this:

<note type="attestedRelationships">
 <listRelation>
  <relation name="husband" passive="pros:bela3" active="pros:leos3"/>
  <relation name="son" passive="pros:prec2" active="pros:leos3"/>
  <relation name="son" passive="pros:gent3" active="pros:cres3"/>
 </listRelation>
 <listPerson>
  <person corresp="pros:gent3" ana="trait:relational"/>
  <person corresp="pros:prec2" ana="trait:relational"/>
 </listPerson>
</note>

This captures all the key information in portable <relation> elements, and the source in all cases can be inferred to be the containing <event>. This seems elegant to me. Traits/states are detached from individual relationships and associated directly with the <event>; entries would only need to be added for individuals to whom these traits/states apply, and everyone else linked in the relation elements would be assumed to be a) directly involved in the business, and b) alive.

Implementing this will require several stages:

  1. First, we need an identity transform to generate all the required relationships from the existing <linkGrp> elements.
  2. Once the new structures are confirmed as equivalent to the old, the XSLT that generates the site from the old <linkGrp>s will be rewritten to work from the new structures instead.
  3. Once this is working, we can delete the old <linkGrp> elements.
  4. The diagnostic which is finding the weird relationship entries on <person> elements will need to be updated to take account of the change, along with any other diagnostics expecting the old structure.
  5. Documentation will have to be rewritten.

Once all the remaining issues from <relation> elements on <person> elements have been resolved, we can finally get rid of those, leaving only the relationships captured on <event>s (although in future we will allow <relation> elements in the personography to express relationships whose source is not the <event> records).