← Case Studies/Case #006/C6-003
C6-003DecidedIdentityFoundational2026-04-05

Canonical Person Entity — One @id Across All Properties

Schema.org Person with @id uniquely identifies the operator across all machine-readable contexts. Without a canonical @id, each property's Person schema is a disconnected assertion — 'Ben Chan' without specifying which Ben Chan. With a canonical @id, all properties point to the same entity and the graph consolidates. The sameAs array extends this by explicitly listing all equivalent URLs. Full coverage across all properties is required; partial coverage produces partial consolidation.

Freshness
Active

Active. Reverify if schema.org Person guidance changes or if major search engines deprecate @id-based entity resolution.

Dependencies
← C6-001: Consolidation Decision — Hub Architecture for Multi-Property Personal Identity

Used by

→ C6-004: @id URI Belongs to the Hub Domain→ C6-005: Identity Decoupled from Infrastructure→ C6-010: Cross-Property sameAs Consistency — The Array Is a Contract
#person-schema#canonical-id#schema-org#entity-graph#sameas#machine-readable

Capture

Schema.org provides a Person type with an @id field — a URI that uniquely identifies the person in any machine-readable context. Without a canonical @id, each property's Person schema is a disconnected assertion: it says "Ben Chan" but does not say which Ben Chan or whether this is the same Ben Chan as on the other properties. With a canonical @id, all properties point to the same entity, and the entity graph consolidates.

The Person schema also carries a sameAs array — a list of URLs that are equivalent representations of the same entity. Together, @id and sameAs form the identity signal.

Why

The @id is the linchpin of entity graph consolidation. Search engines and LLMs use @id URIs to associate schema assertions across domains. If yymethod.com says "Ben Chan" and benchantech.com says "Ben Chan" but they use different @id values — or no @id at all — they may be processed as different entities. A single @id that appears on all properties makes the relationship unambiguous: they all describe the same person.

The sameAs array extends this by explicitly listing all related URLs as equivalent representations. It answers the question "where else can I find this entity?" in a machine-readable way. A complete sameAs array covering all properties in the system is a more complete entity signal than any single property can provide alone.

Without this work, the entity graph is a collection of independently-named individuals with no connection between them. With this work, it is a single individual with multiple known addresses.

Why-Not

Why not use a standard external identifier (ORCID, LinkedIn URL) as the @id? External identifiers are less stable than a self-owned domain. A LinkedIn URL can change format; a platform can go away; an ORCID is authoritative in academic contexts but not in web-native contexts. A personal domain URI is as durable as the domain registration.

Why not rely on the name string alone to link entities? Name strings create ambiguous matches. "Ben Chan" is a common name. An @id URI with a controlled namespace is unique by construction. Name-based entity matching is probabilistic; URI-based matching is deterministic.

Why not implement @id on only the hub? The hub carrying the @id while spokes do not is partial consolidation. A search engine encountering yymethod.com and not seeing an @id pointing to the canonical entity gets a weaker signal than if the same @id appears on both. Full coverage is the goal.

Commit

Decision: Implement a single Person schema with @id set to a URI on the hub domain. Deploy the identical @id on all properties. The sameAs array lists all properties in the system, including the hub itself. See C6-010 for the consistency contract.

Confidence: High. Standard schema.org practice; well-supported by all major search engines.

Timestamp

2026-04-05

← C6-002C6-004 →