Concepts / Introduction to gmodel.py and Data Processing

Introduction to gmodel.py and Data Processing

Email addresses and domain names change over time as people move between organizations, requiring a mapping system to consolidate multiple variants into single canonical addresses

  • Programming

One Person, Several Addresses

A person's email address can change when they move between organizations. If an archive treats every historical address as unrelated, one contributor may appear to be several different people. gmodel.py addresses this problem through mappings stored in mapping.sqlite. The Mapping table handles individual email addresses, while the DNSMapping table handles domain-name changes.

maps tomaps toNorthwesternaddressswgithen@mtu.educanonical destinationCambridge address
How do several historical email addresses map to one canonical address?

The goal is not to erase historical addresses. The goal is to make them equivalent during processing by directing them to one chosen destination address.

Following a Career Across Addresses

Consider the source example of Steve Githens. His archive contains three email addresses associated with different stages of his career. The mapping design chooses swgithen@mtu.edu, his most recent address, as the canonical destination. The other two addresses point toward it.

maps tomaps tois already the destinationNorthwesternaddressearlier addresscanonical addressshared destinationCambridge addresslater addressswgithen@mtu.edumost recent address
What changes over time, and how are addresses from different organizations connected to the same person?

Steve Githens' Three Addresses

Consolidate three historical email addresses into the canonical address swgithen@mtu.edu.

Choose the destination: Use swgithen@mtu.edu as the canonical destination because it is the most recent address in the source example.

Add the first mapping: Create an entry directing the Northwestern address to swgithen@mtu.edu.

Add the second mapping: Create an entry directing the Cambridge address to swgithen@mtu.edu.

Leave the destination unmapped: Do not add an entry directing swgithen@mtu.edu to itself. It is already in its final form.

Two Mapping table entries consolidate the three addresses. Whenever gmodel.py encounters either historical address, it uses swgithen@mtu.edu instead; an occurrence of the canonical address is already usable as-is.

Mapping Table Rules

The Mapping table stores individual email mappings using arrow notation: source address to destination address. The source is the address that may appear in historical data. The destination is the canonical address that gmodel.py should use when it encounters that source. Multiple source addresses can point to one destination.

maps tomaps toNorthwesternaddresssourceCambridge addresssourceswgithen@mtu.edudestinationswgithen@mtu.edudestination
How do source addresses become equivalent to one canonical destination?
  • Adding a mapping entry for the canonical address pointing to itself.

    The canonical address is already in its final form and does not require a mapping entry.

    Fix: Add entries only for the historical source addresses that should point to the canonical destination.

  • Adding only one historical address when two historical addresses must be consolidated.

    The omitted address will not match a Mapping table entry and will be used as-is.

    Fix: Create one entry for each noncanonical address that should be consolidated.

Processing Order

gmodel.py applies mappings while processing the archive. It reads each message, extracts sender and recipient addresses, and checks each address against the Mapping table. When a mapping exists, it uses the destination address. When no mapping exists, it keeps the address as-is. A single mapping can therefore affect many messages if the address appears repeatedly.

readcheckyesnoemail messagearchive inputsender or recipientaddress extractedMapping table checkmapping exists?destination addressmapped resultoriginal addressused as-is
How does an archive record move from a historical address to a normalized value?

The mapping is a transformation rule, not an edit to each stored message. The same rule is checked each time the relevant address is encountered during processing.

Domain-Level Normalization

The DNSMapping table works at the domain level rather than the individual-address level. For example, when gmodel.py processes someone@iupui.edu, it can first check whether iupui.edu maps to indiana.edu. If that DNS mapping exists, the address becomes someone@indiana.edu before individual email address mappings are checked.

check domainiupui.edu to indiana.eduthen check addressuse mapped resultsomeone@iupui.eduincoming addressDNSMapping tabledomain-level checksomeone@indiana.eduDNS-normalized addressMapping tableindividual-address checkcanonical addressprocessing result
How do domain variants resolve to one canonical DNS entry before individual address mappings are applied?
Mapping systemWhat it handlesWhen it operates
DNSMappingDomain-name variationsFirst
MappingIndividual email-address variationsAfter DNS mapping

Persisting a Mapping Entry

A mapping entry moves through three related places: the mapping decision is defined for the application, it is stored in mapping.sqlite, and gmodel.py consults it during archive processing. The important distinction is that storage of the rule and transformation of archive values occur during data processing; the original archive remains unchanged.

stores mapping entrymapping is consultedmessages are readapplies transformationarchive maintainermapping.sqliteMapping tablegmodel.pydata processingemail archiveoriginal datacanonical resultprocessed view
How does a mapping entry get created, persist in mapping.sqlite, and affect processing?

Treat mappings as adjustable transformation rules. If later review shows that a source address was assigned to the wrong destination, change or remove the mapping rather than altering the original archive.

Archive Cleanup Practice

EASY

An archive contains three addresses for one contributor: a Northwestern address, a Cambridge address, and swgithen@mtu.edu. The goal is to treat all three as one canonical address. Decide which address should be the destination and determine how many Mapping table entries are needed.

Hints
  • Use the most recent address named in the source example as the destination.
  • Count the historical addresses that are not already the destination.
  • The destination does not need a self-mapping.
MEDIUM

An address appears as someone@iupui.edu, and the DNSMapping table contains a rule mapping iupui.edu to indiana.edu. Describe the processing order, including when an individual Mapping table lookup occurs.

Hints
  • Start with the domain portion of the address.
  • DNSMapping operates before individual email-address mappings.
  • After the domain is normalized, gmodel.py can check the resulting address against Mapping.

Key Takeaways

  1. The Mapping table connects historical individual email addresses to one canonical destination.
  2. For three addresses consolidated into one destination, only the two noncanonical addresses need mapping entries.
  3. DNSMapping handles domain-level normalization before individual email-address mappings are applied.
  4. gmodel.py applies mappings during processing and leaves the original archive unchanged.
  5. Together, email and DNS mappings create a more unified view of contributors across organizational and career changes.

Key Takeaways

  • Use the Mapping table to direct multiple historical email addresses to one canonical address.
  • Do not create a self-mapping for the canonical address.
  • Use DNSMapping first when the inconsistency is at the domain level.
  • Mappings are non-destructive rules applied by gmodel.py during data processing.
  • Reviewing and adjusting mappings improves the consistency of large email archives without changing their original data.