However, users have been recording these relationship in their tree in a variety of ways. So, how do we upgrade the custom methods to the new standard one?
Let’s count the ways that a Godparent might have been recorded:
any of three custom types for Roles for a shared event (Christening, Adult Christening or Baptism) : Godparent, Godfather, Godmother
Associations of Godparent, Godfather, Godmother
inverse Associations of Godchild, Godson, Goddaughter
I used custom Godfather, Godmather, Godson, Goddauther roles and associations earlier. But later I’ve grouped them into Godparent and Godchild in event roles and associations.
Associations have existed at least by Gramps 2.2 in 2006. Yet there still aren’t even tools to find specific Associations.
The features that pertain to associations are:
Rule: Match associations of <person filter> (You have to create an “Everyone” person filter first.)
Rule: People with <count> associations
Utilities Tool:Type Cleanup doesn’t find Association Types. If it did, that tool creates a list of Objects (linked to the Object Editor) referencing any particular type.
Utilities Tool:Sync Associations… only adds missing Associations
Utilities Tool:Check Associations data… lists the Associations of Persons and shows their target person. But it doesn’t allow opening either person.
If there was any way to open both people involved in an Association, then you could see if there was a Christening event that could be shared (or you have to create one). Then you can choose where to move the Source Citations, Notes and Privacy from the Person Reference Editor for the Association: to the Reference information or the Shared information section of the Shared Event. And then delete the Association.
As the Gramps data model evolves, we need a well documented method of recasting legacy workarounds (typically in custom attributes, associations, Event descriptions or Notes) into the newly supported data structures.
The addition of a standardized Godparent role for Events means that workarounds in custom Roles, Associations, and Inverse Associations need to be resolved. Which includes not only conveying the data to the right place but also cleaning out the remnant data.
Likewise, if unsupported import data will fit in a standard Gramps data structure, we need a cross-walking process.
For example, officially unrecognized custom GEDCOM _tags (or ADDR street data that is currently mishandled) creates an import failure Note. If a user has a preferred workaround (like a custom type Attribute for storing a _UUIDs of a specific service) then there should be a documented process for processing the Note content and disposing of the Note. (Or documentation for how to customize the Import & Export plugins to support a “round-trip” for the officially unsupported _tag.)
(Personally, I would prefer to see GEDCOM snippets saved in Custom Type attribute. Having a structured data representation of a custom _tag seems more easily parsed than a less structured Note.)
A crosswalk in the context of data migration refers to a mapping mechanism that translates data values or elements from one system, schema, or format to another. This is essential when migrating data between systems that use different data structures, coding schemes, or business terminologies.
Key Points
Value-to-Value Mapping: A crosswalk is essentially a table or set of rules that matches (maps) values from the source system to their equivalents in the target system. For example, a code or label in the legacy system is mapped to its corresponding code in the new system.
Schema Translation: Crosswalks are often used to map data fields or metadata elements between different schemas, ensuring that information from one system can be accurately transferred and interpreted by another system.
Facilitates Interoperability: By providing clear mappings, crosswalks enable interoperability between systems that otherwise would not be able to directly exchange or understand each other’s data.
One-Way or Bi-Directional: Crosswalks can be designed to support one-way (lateral) mapping or, if needed, bi-directional translation between systems, depending on integration requirements.
Common Use Cases: Crosswalks are frequently used in enterprise resource planning (ERP) migrations, data warehouse integrations, and when legacy systems need to communicate with modern platforms.
Example
If a legacy accounting system uses “Program Index Code 12345” and the new system uses “Cost Center CC12345,” a crosswalk would explicitly map “12345” to “CC12345” so data can be correctly transferred and understood in the new environment.
Summary Table
Source Value/Field
Target Value/Field
Purpose
Legacy Code “12345”
New Code “CC12345”
Maintain data consistency
MARC $260c
Dublin Core Date.Created
Metadata translation
In summary:
A crosswalk in data migration is a structured mapping that ensures data from one system or schema can be correctly interpreted and used in another, supporting smooth and accurate transitions during migrations or integrations
How about making a “mapping” feature, it could be under “preferences” or “tools”.
It could be a relatively simple list editor, where people could map a custom type, custom association etc. to the standard ones if the user want to.
That way we could use custom types, roles and associations etc. for our view or in reports that can support custom entities, while Gramps can utilize the standards for any data processing, and when exporting, there could be a single radio button or similar, asking if the user wants to export the standard values that are mapped or the custom entities, or both if the format support it.
It might be less automatic and it will be the users responsibility that it is correct, Gramps only gives the opportunity to do the mapping.
This should be stored in the database and be exported with any backup…
Moving wedding witnesses (moved from a separate thread)
I’m still trying to create a GEDCOM file to import the wedding witnesses into Gramps.
I’ve now managed to import the people as witnesses. They are always listed under Connections for the groom.
Kari @kku do you think it’s possible to link the witnesses to the wedding event using Supertool?
And can you please help me? I don’t know how else to import the witnesses.
The actual code is in the separate file ‘witnesses.py’:
def move_witness():
husband = self.father
wedding = find_wedding_event(self)
if not wedding:
return
for witnessref in husband.obj.get_person_ref_list():
witness = db.get_person_from_handle(witnessref.ref)
evref = EventRef()
evref.set_role(EventRoleType.WITNESS)
evref.ref = wedding.handle
witness.add_event_ref(evref)
db.commit_person(witness, trans)
husband.obj.set_person_ref_list([]) # delete all associations
db.commit_person(husband.obj, trans)
def find_wedding_event(fam):
for event in fam.events:
if event.type == 'Marriage':
return event
return None
This code will always process ALL associations for the husband/groom (and delete them). So if there are other kinds of associations then the code must be amended.
The code will also do nothing if there is no marriage event.
The script should be run in the Families view. By default it only processes selected families.
Since this is the raw data from my Excel data entry, there are only these connections from the wedding witnesses to the groom.
It’s going great, and your script works exactly as I imagined.
Thank you for your help, Kari.
