Short answer: entity resolution in education must be built around stable identities for institution, campus, school, department, program, course, qualification and person. Good architecture separates these entities, links aliases and version history, keeps the owner of each fact, and prevents the same name from representing different objects. Structured data can reflect relationships, but it does not replace editorial registry and governance.

Precondition 1: institution registry

Define a stable institution ID for the legal or institutional entity that the site represents. Keep current name, historical names, domains, locations and ownership context.

Do not use the short name as the primary key.

Prerequisite 2: campus registry

The campus is an operational entity separate from the institution. Keep campus ID, address, city, status and relationship with programs.

A closed or relocated campus must have a lifecycle, not just a generic redirect.

Precondition 3: registry program

The program has program ID, preferred title, qualification, school/department, campus, modality, academic version and admissions status.

Two programs with similar titles may be different entities.

Precondition 4: course and module registry

Course or module should not be confused with program. Keep relation type, credit context and version where they exist.

Do not use a course page as the owner for facts about the entire qualification.

Precondition 5: person registry

Faculty and staff have person ID, preferred name, aliases, roles, department relations and lifecycle. A teacher can have joint appointments.

Byline and employment are different relationships.

Step 1: Define relationship types

Examples: institution-has-campus',program-offered-at-campus', program-awards-qualification',person-member-of-department', `person-author-of-page'.

Use a controlled vocabulary in the internal system.

Step 2: Normalize aliases without deleting history

A program can have old name, abbreviation and translation. Bind all forms to the appropriate ID and keep effective dates.

Do not convert historical alias to current label if it is no longer active.

Step 3: separate translation from identity

RO and EN can have different labels for the same entity. Identity remains common and local wording is versioned.

For qualifications, keep the official name when the translation would create false equivalence.

Step 4: map source owners

Admissions can own deadline and eligibility, academic catalog can own curriculum and credit requirements, HR can own role status, and finance can own fee schedule.

Entity registry does not have to decide the truth for all fields by itself.

Step 5: Build canonical pages per role

Institution page, campus page, program page, faculty profile and course page have distinct roles. Avoid creating five nearly identical pages competing for the same identity.

Technical canonicalization does not resolve two different legitimate entities.

Step 6: Bind entities contextually

The program page must indicate the campus, qualification and department where relevant. Faculty profile can list programs or courses, but must not become owner for program facts.

Use links that express the user's task.

Step 7: Structured data reflects the registry

Organization and ProfilePage markup may reflect information already published and validated. Do not introduce a name, role, or relationship in the markup that is not visible or supported.

The markup is a projection, not the primary source.

Step 8: academic versioning

Curriculum and requirements change. Keep academic year or version for fields where time changes meaning.

It does not retrospectively rewrite previous cohorts.

Step 9: lifecycle events

It models program launch, suspension, teach-out, retirement, campus move, department merger and staff departure.

Each event can trigger tasks on dependent pages.

Step 10: duplicate detection

Runs rules on stable IDs, normalized names, addresses and relation sets to find candidate duplicates. It does not work automatically on string similarity.

A fuzzy result must be revised.

Step 11: contradiction detection

Compare material facts about the same entity between the owner page and dependent surfaces. Examples: program title, campus, qualification, role, deadline and fee year.

The difference becomes finding with owner.

Step 12: publication gate

A new page about a material entity does not go live without the required ID, type, owner and minimum relations. If the ID cannot be decided, the correct status is needs_resolution.

Don't invent mapping to pass the gate.

Example 1: rebrand program

Master of Data Analytics' becomesMSc Data Analytics'. If it is the same qualification and the same academic line, keep program ID and add alias with effective data.

If the new program has a different curriculum and award, it may require a separate ID.

Example 2: campus relocation

The schedule remains the same, but the campus relationship changes on a specific date. It updates dependent pages and preserves historical context for previous cohorts.

Don't create a new program just for the address.

Example 3: joint appointment

A professor belongs to two departments. The model supports two active relationships, it does not duplicate the person in two unrelated profiles.

Authorship remains tied to the person ID.

Example 4: teach-out

The program no longer accepts new admissions, but exists for active students. The status is not simply `closed'.

Keep teach_out and affected population.

Structural QA

Check uniqueness for IDs, orphan entities, dangling relations, aliases without an owner, lifecycle inconsistencies and candidate duplicates.

Run samples manually on cases with high similarity.

Editorial QA

Check if visible pages express the same identity and version. A perfect internal graph does not make up for a stale public page.

Keep the source owner for each finding.

Rollback

Snapshot registry and relation graph before bulk merge. If two entities have been merged incorrectly, you must be able to separate IDs, aliases, and dependencies without losing history.

Do not use destructive marches without an audit trail.

Acceptance criteria

Architecture passes the gate when:

  1. institution, campus, program, course and person have stable IDs;
  2. aliases have effective dates;
  3. translation is separated from identity;
  4. source owners are mapped;
  5. relations use controlled vocabulary;
  6. academic versioning exists;
  7. lifecycle events trigger tasks;
  8. duplicate and contradiction detection works;
  9. publication gate can stop unsafe mappings;
  10. rollback preserves history.

Claim ledger

  • FACT/EVIDENCE: Google documents Organization and ProfilePage structured data as ways to describe information about organizations and people.
  • FACT/EVIDENCE: Google recommends that structured data reflect visible content and comply with applicable policies.
  • PRACTITIONER GUIDANCE: education entity resolution must separate program, campus, course, qualification and person identity.
  • INFERENCE: stable IDs, versioning and contradiction detection can reduce ambiguity and stale-content recurrence.
  • NOT PROVEN: that a specific internal scheme directly produces AI ranking or citations.

Conclusion

Entity resolution in education is a problem of identity, relationships and time. Stable IDs, versioned aliases, source ownership, and lifecycle events allow the site to keep consistent program, campus, faculty, and qualification facts without deleting history. Structured data can design these relationships, but quality begins in the registry and editorial discipline.

Sources reviewed

Related insights