Schema Graph Discipline

Schema.org structured data is not simply a formatting layer for search engines. It is a machine-readable graph declaration. Every schema block published on a page contributes nodes and relationships to a knowledge graph that AI systems and search parsers use to construct entity representations. The quality of those representations depends entirely on the consistency of the declarations that produce them.

Inconsistent schema — @id values that vary, types that drift between declarations, author and publisher references declared inline rather than by @id — produces a fragmented graph. Fragments of the same entity appear as separate nodes. Relationship declarations point to nodes that do not connect to the canonical entity. The result is a set of weak, unlinked representations rather than a coherent, reinforcing graph.

Schema Graph discipline is the practice of preventing this fragmentation before it enters the system — by establishing governance rules for every structural decision in schema and applying them consistently across every declaration.

The @id field in a Schema.org declaration is the graph node identifier. Two schema declarations that use different @id values for the same entity produce two separate, unconnected nodes — regardless of how similar the other fields are. A single character difference in the @id string is sufficient to prevent the parsers from merging the declarations into a single entity representation.

Stable @id discipline means that every schema declaration referencing a given entity uses the exact same canonical @id — no variation in protocol, domain, path, or fragment. The canonical @id is assigned once, stored in the entity registry, and applied without modification to every declaration across every page and domain.

Type discipline means that the Schema.org @type assigned to each entity is locked to a single value and applied consistently. An entity whose type varies between declarations — appearing as Organization in one context and LocalBusiness in another — produces type-ambiguous nodes that cannot accumulate classification signal in a single direction. The result is an entity that is weakly associated with multiple categories rather than strongly associated with one.

Author and publisher fields in article and publication schema serve two functions: they attribute the content to a person entity, and they establish a relationship between the content and an organization entity. Both functions depend on the relationship being expressed as a reference to a canonical @id — not as an inline name declaration.

An inline author declaration such as "author": {"@type": "Person", "name": "Ali Morgan"} creates an anonymous Person node with the name "Ali Morgan." It does not connect to the canonical Ali Morgan entity node in the knowledge graph. The relationship is declared but not linked.

An @id reference such as "author": {"@id": "https://jonomor.com/ali-morgan#person"} creates a graph edge from the article node to the canonical Ali Morgan entity node. Every article on every domain that uses this same @id reference contributes to the same relationship edge — progressively strengthening Ali Morgan's association with the authorship of content in this domain.

The discipline is consistent: author and publisher fields in all article-level schema must use @id references to canonical entity nodes — never inline declarations.

The sameAs property in Schema.org is intended to link an entity's @id to other established identity profiles for the same entity — typically on external authority surfaces such as Wikidata, established professional directories, or major platforms. It is not a general-purpose relationship field.

For Person entities, sameAs must point only to real, verifiable identity profiles where the person is present — not to product domains they own, not to organisational domains they founded, and not to placeholder URLs. A Person entity's sameAs pointing to a product domain conflates the person with the product in the knowledge graph — an identity claim that is incorrect and difficult to reverse once it enters training data.

For Organization and product entities, sameAs may reference established external directory entries if they exist and are confirmed accurate. If no such profiles exist for an entity, sameAs must be omitted entirely — an absent sameAs is significantly less damaging than an incorrect one.

The sameAs constraint applies across all declarations for an entity, on all domains. A sameAs value added on one domain that contradicts the sameAs governance rule cannot be isolated — it affects the entity's global representation.

Each page type in an entity authority system requires a specific schema pattern — a defined combination of @type, required fields, and relationship references that is applied consistently across all pages of that type.

Page-level schema extension discipline means that when a new page is added to the system, its schema follows the established pattern for its type without variation. A TechArticle page always declares the same field set in the same structure. A CollectionPage always includes an ItemList as mainEntity. A DefinedTerm always references its parent collection via inDefinedTermSet. The pattern is established once and applied without editorial judgement.

Extensions — adding fields beyond the established pattern — require a governance decision. Adding a new field to one page of a given type but not to others introduces inconsistency in the schema pattern, which produces inconsistency in how the page's content is classified relative to other pages of the same type.

The Schema Graph layer functions as a coherent machine-readable system only when the pattern discipline is applied consistently enough that every page of a given type looks the same to a parser. Inconsistency at the page level compounds across a large site into significant graph fragmentation.