Entity SEO learning
Check who acts on whom in an entity relationship
A relationship direction audit checks the roles at both ends of an assertion. It keeps “owns,” “produces,” “replaces” and similar terms consistent with their evidence instead of letting natural language reverse the meaning.
Use it when a relationship appears in different records, pages or data mappings. Keep the inverse, tense and scope attached to the original claim.
Read the directional assertion ledger
Write the assertion before polishing the sentence
Normalize the claim into subject, predicate and object. The subject is the entity from which the relationship is stated; the object is the entity at the other end. Resolve each identity, type and relevant version before choosing the relationship. A person, company, product and place can appear together without sharing the same role.
Then define the predicate’s meaning, its permitted entity types and its reverse wording. “Organization A produces Product B” can be expressed from the other end as “Product B is produced by Organization A.” Keeping “produces” and swapping A and B changes the assertion instead of restating it.
Some relationships can be symmetric within a defined model. Others have a distinct inverse or no approved inverse wording. Words such as “partner,” “works with” and “connected” need explicit scope; a reciprocal sounding phrase does not prove that both ends can perform the same functions, depend on one another or support a reverse operation.
Tense is part of the claim too. A former owner is not automatically the current owner. Keep the effective period, market and lifecycle state with the assertion when those conditions change its truth.
Compare the forward claim, inverse and rejected reversal
The following relationship ledger is hypothetical. Workshop A, Lamp B and Adapter C are invented entities. The stated source descriptions are teaching assumptions, not observed documents or test findings. Each row shows how to preserve meaning and where evidence must stop.
| Forward assertion and assumed evidence | Approved inverse or limit | Rejected inference and reason |
|---|---|---|
| Workshop A produces Lamp B. An assumed manufacturer record names A as the producer of that exact lamp version. | Lamp B is produced by Workshop A. This changes the wording and swaps the endpoints while preserving the manufacturing claim. | Lamp B produces Workshop A. Swapping endpoints without changing the predicate reverses the meaning and assigns an unsupported role to the lamp. |
| Lamp B replaces Lamp A in Market M after Date D. An assumed replacement notice states that scope. | Lamp A is replaced by Lamp B in Market M after Date D. Keep the same market and effective period. | Lamp B replaces Lamp A everywhere and at all times. The source does not establish a universal replacement. |
| Adapter C sends readings to Lamp B. An assumed technical note covers this outbound operation only. | A passive restatement can say that Lamp B receives readings from Adapter C. This does not establish a reverse sending operation. | Lamp B sends readings to Adapter C. Reversing an operation requires its own evidence; the outbound note does not supply it. |
| Workshop A formerly owned Brand D. An assumed historical record establishes a period that has ended. | Brand D was owned by Workshop A during that period. Preserve the historical qualifier. | Workshop A owns Brand D today. Historical ownership does not establish current ownership. |
The check asks two different questions: does the forward assertion have evidence, and does the proposed inverse preserve that assertion? A neat grammatical reversal cannot repair an unsupported forward claim. A relationship that can be expressed from either endpoint is not automatically symmetric.
Record what proves the direction
- Subject and object Keep the accepted IDs, types, versions and roles at both ends. Use the source’s named entities rather than inferring identity from similar names or shared branding.
- Predicate and inverse Record the preferred directional label, its defined meaning, the allowed inverse and any explicit symmetry rule. Keep business language distinct from the exact properties used by a chosen data vocabulary.
- Evidence and scope Attach the source URL and observation date. Explain how the source establishes who owns, produces, replaces, checks or depends on whom. Add market, effective period, lifecycle, version and any uncertainty that limits the claim.
- Propagation List the visible descriptions, graph records, internal links, schema mappings and page roles that depend on this relationship. A correction is incomplete if one surviving representation still says the reverse.
- Owner and review state Name the responsible reviewer, decision state, next review date and unresolved dependency. Specify the event that should reopen the decision before that date.
Mentioning two entities together does not establish ownership, manufacture, replacement or another stronger relationship. Likewise, one source can support the existence of a link without supporting the exact predicate or direction proposed for it. Hold that stronger assertion until the missing evidence is available.
Correct every affected expression without merging the entities
Consider a hypothetical page that says “MIRENA owns Semantec SEO.” Before accepting that direction, check the identities and evidence at both ends. If the accepted identity model defines MIRENA as a brand of Semantec SEO, paired wording could be “Semantec SEO has brand MIRENA” and “MIRENA is a brand of Semantec SEO.” Those phrases are conditional examples, not a verified ownership or legal classification.
Before using that wording, confirm the current entity types and the specific relationship supported by the controlling source. If the accepted model describes MIRENA as a product, use the evidenced product relationship instead of forcing the brand label. Preserve the distinct organization and product identities. This page supplies a direction check; it does not settle an unresolved classification.
- Locate the original assertion. Find the source statement and write the normalized subject, predicate and object. Confirm the tense, scope and evidence before adjusting downstream language.
- Test the proposed inverse. Check that the inverse preserves the defined relationship. If a reverse operation or reciprocal claim is proposed instead, treat it as a separate assertion with its own evidence.
- Repair dependent representations. Update the affected prose, graph edges, relationship labels, internal link descriptions and schema mappings. A hyperlink by itself does not express every relationship claimed in surrounding text.
- Review the emitted result. Compare the final visible copy and any emitted data with the approved assertion. Keep the entities separate, preserve qualifiers and check that obsolete reversed statements have been removed.
- Retain the rationale and revisit changes. Store the accepted assertion, inverse rule, sources, affected records, reviewer and unresolved work. Recheck after ownership, release, lifecycle or source changes; hold dependent unsupported claims until repaired.
Questions about relationship direction
Is an inverse the same as a symmetric relationship?
No. An inverse changes the predicate as the endpoints swap, such as produces and is produced by. A symmetric predicate keeps its defined meaning with the endpoints swapped. Declare symmetry only when the relationship model and evidence support it.
Does a claim that systems work together apply in both directions?
Do not assume so. Identify the operation, release, permissions and environment. Evidence for one direction or operation does not establish a reverse operation, the same functions at both ends or mutual dependency.
What if the entity type is unresolved?
Return to identity and type research. Do not use polished inverse wording to conceal an ambiguous company, person, brand or product record.
Does this check also settle cardinality?
No. Direction identifies the roles at each end. Cardinality sets the permitted counts within a stated scope. Review those counts after the predicate and direction are clear.
What does the completed review establish?
It documents a supported directional assertion, its permitted inverse and the affected corrections. It does not guarantee indexing, rankings, traffic, rich results or a consuming system’s interpretation.
Related decisions and source reading
Entity Type Conflict Resolution
Resolve incompatible endpoint types before accepting a directional relationship.
Predicate Cardinality Rules
Define the permitted counts once the predicate and direction are settled.
Entity Predicate Library
Maintain preferred relationship labels, inverses, type constraints and prohibited wording.
Entity Identity Evidence Register
Keep identifiers, source conflicts and accepted entity identities available for the audit.
RDF 1.1 Concepts
Read the subject, predicate and object model. This general reference does not establish an application’s inverse or symmetry rules.
Entity SEO library
Find related methods for entity identity, attributes and lifecycle changes.
The source reading distinguishes graph structure from evidence about a particular relationship. The first party predicate method supplies editorial vocabulary decisions; RDF 1.1 Concepts supplies general graph context. Check the chosen data vocabulary for its defined properties before emitting data. Hypothetical examples are not verified business or product claims.