Entity SEO learning
Set relationship counts for the scope they describe
Predicate cardinality rules define how many relationships a subject or object may have within a stated scope. They prevent a local pattern from becoming an unsupported universal limit.
Keep minimum and maximum counts distinct from ordering, exclusivity, effective dates and missing evidence. A useful rulebook explains both valid records and the cases that need repair.
Read the scoped successor examples
Count relationships within an explicit scope
Start with a controlled predicate and its direction. State which subject and object types it permits, including the versions or subtypes that change the rule. A constraint on outgoing successors of one retired product is different from a constraint on the number of predecessors that one new product can have. Do not copy a limit to the inverse direction without checking it.
Then define the population and effective period being counted. A product may have one selected replacement in a particular market at a particular time, yet have different successors across its history or across markets. Counting all historical and regional edges together can make valid records appear contradictory.
Minimum and maximum describe counts. Optional means the relationship may be absent under the chosen rule. Exclusive means particular alternatives cannot coexist in the same scope. Ordered means the sequence carries meaning. Effective dates limit when an edge applies. Record these dimensions separately rather than asking a single count to express all of them.
A successor rule that permits branching without losing meaning
This fictional catalogue uses the predicate “has successor,” directed from a retired product release to a replacement release. Lamp A, Lamp B and Lamp C, their markets and their notices are invented. No manufacturer record has been checked. The examples illustrate an application rule, not a universal rule for product replacements.
For this example, the catalogue permits zero or more confirmed successor edges for each retired release across its full history. A separate current recommendation rule allows at most one selected replacement for a given market and effective period. A missing recommendation is recorded as unresolved or “none confirmed”; it is not silently treated as proof that no replacement exists.
| Record and applicable scope | Count or condition | Interpretation and action |
|---|---|---|
| Lamp A has successor Lamp B in Market North and Lamp C in Market South during the same period. Each edge has its own assumed replacement notice. | Two outgoing successors across the catalogue; one selected replacement in each market. | Permitted by the stated rules. Preserve market qualifiers so neither successor appears to replace Lamp A universally. |
| Lamp B and Lamp C are both marked as the selected replacement for Lamp A in Market North during overlapping periods. | Two selected replacements in the same scope; the local maximum is one. | Violation of this application rule. Check the notices, effective dates and record roles. If the products are alternatives, model that choice explicitly rather than silently keeping two exclusive selections. |
| The catalogue has no confirmed successor edge for Lamp A in Market West. Research remains incomplete. | Zero confirmed edges; completeness is unresolved. | The minimum of zero permits an empty record, but it does not prove that no successor exists. Keep the research state visible before making a public replacement claim. |
| Lamp B was the selected replacement in Market North until Date D; Lamp C becomes selected after Date D. Assumed notices define nonoverlapping periods. | Two historical selections; at most one effective selection at any time. | Permitted if the period boundaries are explicit and consistent. Retain history instead of deleting the earlier valid selection. |
| A proposed successor is a company record rather than a product release. | The count could be one, but the object type is wrong. | Reject or repair the edge. Passing a count check cannot make an invalid entity type or unsupported predicate acceptable. |
These cases separate global branching, a scoped maximum, missing evidence, historical succession and type failure. A different catalogue may support two or more simultaneous alternatives in one market. Its rule must state that meaning and the selection method instead of borrowing this example’s maximum.
Define the rule and the evidence that can justify it
- Predicate identity Keep the stable ID, preferred label, definition, direction and inverse. “Related to” is too vague to support a replacement constraint that readers must act on.
- Subject and object types State the allowed classes, versions and contextual restrictions. Separate a product family from a release, a variant and the organization that makes it.
- Minimum and maximum Give numeric bounds or explicitly state that no fixed maximum is imposed. Identify the endpoint, market, period and other qualifiers within which the count applies. Do not call a rule universal when it was observed only for one subtype.
- Violation and exception Explain how a failed count or condition is detected, what needs repair and who can approve a scoped exception. Keep ordering, exclusivity and historical treatment explicit.
- Evidence and scope Attach sources, observation dates, market and release coverage, uncertainty and the reason for the constraint. Review valid current, historical, versioned cases and cases with exceptions before adopting a limit.
- Owner and review state Name the rule owner, decision state, review date and unresolved dependency. Record the downstream records and next action affected by any rule revision.
Observed records alone can reveal a possible pattern without proving a necessary limit. A business policy, documented technical restriction or deliberately chosen application requirement can justify a constraint within its stated scope. Identify that basis so a reader can distinguish an evidenced domain condition from a local modelling choice.
Separate a valid exception from an unresolved violation
A surprising count is a reason to inspect the record, not a reason to discard it automatically. First check duplicate identities, the predicate direction, object type, overlapping periods and omitted scope. Two apparent successors can be the same release under different labels; two genuinely distinct releases can also be valid alternatives.
If evidence supports an exception, record the rule being overridden, the affected subject and objects, the applicable scope, its reason and source, the approver and an expiry or review trigger. Keep that exception local. Do not broaden every product’s rule because one region has a documented special arrangement.
If the source is missing or contradictory, mark the assertion unresolved and hold dependent claims. Preserve the disputed entries and their evidence in history. An exception label cannot substitute for evidence, and an approved local exception does not repair an incorrect entity identity.
Recheck the rule when releases or policies change
- Select representative cases. Review current, historical and versioned examples, including exceptions, against the proposed predicate and scope. Include permitted and rejected cases so the boundary is visible.
- Check types, counts and qualifiers together. Confirm the correct endpoints, then count only the relationships covered by the rule. Check ordering and exclusivity separately. Treat missing data according to the catalogue’s declared completeness policy.
- Repair the smallest failing unit. Correct a duplicate edge, wrong endpoint, missing market or overlapping period at its source. Revise the rule itself if supported cases expose an unjustified assumption. Do not delete valid history to make a current count pass.
- Follow the dependencies. Identify affected graph records, visible descriptions, comparison tables and schema mappings. Review claims that depended on the former rule before presenting them as current.
- Version the decision. Retain the accepted rule, example checks, exception history, evidence, owner and next review event. Revisit the decision when releases, replacement policies, markets or effective periods change.
A static rulebook explains the intended checks; it does not execute them. Automated checks need an explicit data model and test cases. A general graph representation does not, by itself, certify that an application’s cardinality, completeness or exception requirements have been enforced.
Questions about predicate cardinality
Does one successor in the current data prove a maximum of one?
No. It shows the recorded count for that case. A maximum needs a justified rule and explicit scope; incomplete data can hide other valid relationships.
Does an empty relationship prove that no object exists?
No. Separate “none confirmed,” “not yet researched” and a supported claim that none exists. A minimum count rule is different from evidence about the world.
Can two or more successors be valid?
Yes, when the predicate and scoped rule permit them. Explain alternatives, market variants or sequential releases instead of presenting every successor as a universal replacement.
Does passing the count check make the claim publishable?
No. Identity, allowed types, source evidence, scope and visible wording also need review. Rule conformity does not guarantee indexing, rankings, traffic or external platform behavior.
Related decisions and source reading
Relationship Direction Audit
Set the subject, predicate, object and inverse before imposing relationship counts.
Entity Attribute Inheritance
Decide which family rules can flow to a version or variant and where an override needs evidence.
Entity Predicate Library
Define relationship meaning, type constraints and permitted wording.
Entity Identity Evidence Register
Resolve duplicates and entity boundaries before diagnosing count violations.
RDF 1.1 Concepts
Read the general graph model. This reference does not certify the application constraints used in the fictional catalogue.
Entity SEO library
Continue into identity, relationship and lifecycle decisions.
This rulebook is an editorial method with explicitly fictional application constraints. First party identity and predicate methods support record design; RDF 1.1 Concepts supplies general graph context. The examples do not assert a universal product replacement rule or claim that any live check has run.