Canonical identity: one person, several public records

Ownership changes the next action

Ownership determines the available correction. I can edit a controlled page, update an account through its publisher, or ask a university to change a biography. An event program may need no correction if it accurately describes that date. Calling every difference “inconsistent” hides the choice.

For the records a reviewer is likely to encounter, compare role dates, project ownership and the preferred homepage against the underlying work and dated biography. Record why a statement is accepted before distributing it to templates. An approved fact set is a publishing input, not independent corroboration: copying it onto several pages does not create several sources.

Classify each destination as current, supporting, historical, stale or unresolved, then name its owner and the action available. A private or weakly matching profile stays unresolved until its identity can be inspected. A correction request stays a dependency until the other owner changes the page. The inventory should show the limit of control as clearly as the desired repair.

History should remain dated history

A résumé can say a role ended while an event biography says it was current when the event took place. Both statements can be true. The historical record needs the date and context that make its claim intelligible. The defect is an undated page that leaves a past role looking current.

For retired controlled routes with clear equivalents, redirects and canonical signals can lead to the maintained document. Google’s duplicate-content scope makes equivalence the first decision: a historical biography can remain a valid document even when a current page describes the same person.

A short introduction, a project account and an application résumé each give the reader a different amount of detail. Their claims should agree where their periods and subjects overlap. Forcing identical copy would obscure those purposes, while forcing every old account into the newest one would erase useful history. The current record needs a clear route from the past, rather than exclusive possession of it.

Compare host consistency in the wider canonicalization graph with the paired social and HTML identity example, where og:url can keep a stale preview host.

A mention is a different relationship

Schema.org defines sameAs through unambiguous identity. A genuine old profile can identify the right person while needing a job-title update. Stale employment text is a maintenance defect, not automatically evidence of another person.

The document relationship is narrower still. Google’s ProfilePage guidance requires the page’s primary focus to be one affiliated person or organization. An author page can fit that use; an article that merely mentions the author has another purpose. Before generating a relationship, ask whether the destination identifies the person, profiles the person, documents their work or only mentions them. Those are meaningful distinctions for the reader as well as the serializer. ProfilePage requirements.

My preference for an inspectable profile with accurate current facts goes beyond sameAs, giving the maintenance queue a standard for links that the shared identity record will distribute across the site while leaving the vocabulary’s narrower identity definition intact. I would still inspect username changes and account transfers before trusting the old string.

The portable copy needs a publication policy

The HTML résumé is the maintainable web record. The current PDF serves applications and offline sharing. A stable public PDF address helps people locate the intended current edition. It also makes a wrong file at that address consequential: the URL can remain correct while the document changes underneath it.

Before release, reconcile visible dates and ownership claims, then inspect the linked file. Keep private application variants outside the public site. Redirect a retired filename when the new document preserves what that link promised. A newer file can still omit the detail its reader needs.

RFC 6596 permits a canonical target containing duplicate content or a superset. A shared name and subject aren’t enough. If one résumé omits a project or drops a dated claim, assess the material before declaring equivalence. The RFC’s warning against pointing later paginated content at an incomplete first page makes the loss concrete.

Where the representations qualify, an HTTP Link canonical can nominate the preferred version for the PDF, subject to server support and review. A dated application snapshot can instead keep its purpose and link to the current résumé. The date may be part of the document’s value.

Roles, graduation, domain moves and major résumé revisions should trigger reconciliation; a quarterly review can catch quieter drift. I would judge the system by whether a reviewer can identify the person, distinguish the current claim from an earlier one and reach the work supporting it. Centralized metadata helps distribute that judgment. The evidence and dates are what make it worth distributing.