Semantic Relations

Semantic Relations

Concept of the skill

Semantic relations are the typed connections between concepts in a meaning structure -- the edges in a knowledge graph, concept map, taxonomy, ontology sketch, or hierarchy, each of a named kind rather than a generic association. Drawn from lexical semantics, Princeton WordNet, W3C SKOS, W3C OWL property semantics, and FrameNet-style semantic roles, this skill treats every edge as a claim about traversal, inference, substitution, or role assignment.

Replace generic related-to edges and untyped associations with named relation types that enable meaningful traversal, reasoning, retrieval, and disambiguation. Most knowledge-system failures are not failures to name nodes; they are failures to type the connections between nodes. A graph with only related-to edges cannot support reliable path reasoning. A naming audit that cannot separate synonymy from polysemy suggests the wrong fix. A skill system that cannot tell adjacency from boundary loads the wrong context.

This skill owns pre-formal relation typing: choosing whether a connection is IS-A, PART-OF, synonymy, polysemy, causal, thematic, associative, or property-constrained. It does not own word morphology or audience register (linguistics), the meaning encoded by a single identifier or signal (semantics), full domain structure discovery (conceptual-modeling), representation-paradigm choice (knowledge-modeling), formal class/property axioms and reasoning constraints (ontology-modeling), taxonomy/facet governance (taxonomy-design), database relationship implementation (entity-relationship-modeling), operational cross-system ID correspondence (relational mapping), or visual sign systems (semiotics). Semantic-relations is to a knowledge graph what road-type labels are to a transit map: motorway, slip road, roundabout, bridge, tunnel, and one-way street are each typed connections with their own traversal rules. A map that labels every road connector is nearly useless for navigation; precise relation vocabulary makes the map a tool rather than an illustration. The wrong mental model is that relation typing is academic overhead and that related-to plus context is sufficient. It is not. Adjacent misconceptions: that PART-OF and IS-A are interchangeable; that synonymy means duplicate concepts; that polysemy is the same as homonymy; that all PART-OF relations are transitive; that thematic roles are just labels; and that relation properties can be omitted until implementation. Each shortcut changes the inferences readers and tools make.

Coverage

Semantic relation analysis as a typed-connection discipline. Covers four families of relations and their properties:

• Taxonomic relations — hypernymy / hyponymy (IS-A) with the substitution test, transitivity, asymmetry, and inheritance; holonymy / meronymy (PART-OF) with six part-whole types (component-integral, member-collection, portion-mass, stuff-object, feature-activity, place-area)
• Associative relations — synonymy, near-synonymy, antonymy (complementary, gradable, relational), polysemy, homonymy, metonymy
• Thematic relations (role-based) — agent, patient, instrument, location, source, goal, cause, result, temporal, beneficiary
• Relation properties — symmetry, asymmetry, transitivity, reflexivity, irreflexivity

Application surfaces include knowledge-graph edge typing, naming disambiguation (synonymy vs polysemy vs homonymy), skill / module boundary analysis (adjacent vs boundary vs verify-with), category / hierarchy sanity checks, and relation-aware explanation of how concepts connect. Includes a six-item anti-pattern catalog (generic related_to edges, circular IS-A, conflated PART-OF and IS-A, synonym sprawl, untyped polysemy, property-free relation definitions) and a six-item verification checklist.

Philosophy of the skill

Every complex system depends on relation quality, not just node quality. Most knowledge-system failures are not failures to name the things; they are failures to type the connection between things. A graph with only related_to edges is nearly useless for reasoning. A naming audit that cannot separate synonymy from polysemy suggests the wrong fix. A skill system that cannot tell adjacency from boundary loads the wrong context.

The discipline is: name the relation, then test whether the name is the right kind of relation. If "A is B" fails the substitution test, it is not hypernymy. If a part-whole relation changes lifecycle semantics, it is not just loose association. If two words share one form but multiple related meanings, that is polysemy, not synonymy. Precision here compounds into every other knowledge and modeling skill — the quality of every downstream representation depends on whether the relations were typed correctly upstream.

This skill is the vocabulary layer. It does not own the formal axioms (an ontology skill), the storage shape (an ER-modeling skill), the cross-system data correspondence (a relational-mapping skill), or the broader knowledge-representation paradigm (a knowledge-modeling skill). It owns the question: what kind of relation is this?

Boundary Routing

1. Taxonomic Relations (Hierarchical)

Hypernymy / Hyponymy (IS-A)

Properties:

• Transitive — if A is-a B and B is-a C, then A is-a C
• Asymmetric — if A is-a B, then B is NOT a A
• Inheritance — hyponyms inherit properties of hypernyms

Rules:

• Every IS-A claim must pass the substitution test: "Every [hyponym] is a [hypernym]." If that sentence sounds wrong, it is probably not hypernymy.
• Distinguish IS-A from role labels. A buyer is not a type of order; a buyer is an actor related to an order.
• Co-hyponyms should be mutually exclusive unless the model explicitly allows overlap.

Holonymy / Meronymy (PART-OF)

Types of part-whole:

Rules:

• PART-OF is not the same as IS-A. "Every line item is an order" fails; "a line item is part of an order" passes.
• Part-whole relations carry lifecycle implications that influence later ER modeling and API design, but those implementation choices belong to the downstream implementation skills.
• Do not assume every part-of relation is fully transitive in practical reasoning.

2. Associative Relations (Non-Hierarchical)

Synonymy and Antonymy

Rules:

• Synonymy is usually a naming-governance problem: pick one canonical label and route aliases to it.
• Near-synonyms must not be flattened if the codebase or domain uses them differently.
• Antonym pairs should be consistent within one domain surface; avoid mixing inactive, disabled, and off unless the distinctions are real.

Polysemy and Homonymy

Rules:

• Polysemy is common in code and product language. Qualify the meaning with context when one bare term can mislead.
• Homonymy usually requires stronger renaming than polysemy because the meanings are unrelated.
• If two meanings are related and historically or structurally connected, treat it as polysemy, not accidental duplication.

Metonymy

Rules:

• Metonymic shortcuts are acceptable only when the intended meaning remains obvious in context.
• Audit status labels and event names for places where a metonym has become more confusing than helpful.

3. Thematic Relations (Role-Based)

Rules:

• Use thematic roles when an action or event relation is more precise than simple association.
• Distinguish the actor from the instrument and from the cause; they are often conflated in loose architecture explanations.
• Event naming and API design improve when the thematic role is clear.

4. Relation Properties

Rules:

• Relation names are incomplete without relation properties.
• If the relation direction matters, state it explicitly instead of assuming readers infer it.
• Keep direct links and inferred links separate. SKOS, for example, distinguishes immediate broader / narrower assertions from transitive closure relations.
• Property mismatches are a common source of bad graph or hierarchy design.

5. Application

Knowledge-Graph Edge Typing

Skill-Boundary Analysis

Naming Disambiguation

When two names conflict:

1. Identify the relation: synonymy, near-synonymy, polysemy, homonymy, or antonym mismatch.
2. If synonymy: pick one canonical label and redirect aliases.
3. If polysemy: qualify with context.
4. If homonymy: rename one of the terms outright.

6. Anti-Patterns

Verification

After applying this skill, verify:

• Every conceptual or graph edge has a typed relation rather than a vague generic link
• IS-A relationships pass the substitution test
• PART-OF relationships are not being mistaken for type hierarchy
• Synonymy, polysemy, and homonymy are distinguished before renaming
• Relation properties (symmetry, asymmetry, transitivity, reflexivity) are explicit when they matter
• Boundary claims with neighboring skills or modules still hold under the substitution / governance test

Do NOT Use When

Grounding Notes

• Use Princeton WordNet for lexical sense relations such as synonymy, hypernymy, hyponymy, meronymy, antonymy, and role-style cross-POS links.
• Use W3C SKOS for lightweight knowledge-organization links such as broader, narrower, related, preferred labels, and alternate labels.
• Use W3C OWL property semantics only to check relation-property vocabulary; move to ontology-modeling before making formal reasoning commitments.
• Use FrameNet for event/frame roles when generic thematic labels such as agent, patient, instrument, source, and goal are too coarse.

Key Sources

• Princeton University. WordNet: A Lexical Database for English. Official public description of WordNet synsets and semantic relations including hypernymy, hyponymy, meronymy, antonymy, and role links.
• ICSI/Berkeley FrameNet. What is FrameNet?. Official introduction to frames, frame elements, lexical units, and frame-to-frame relation work.
• Cruse, D. A. (1986). Lexical Semantics. Cambridge University Press. The canonical treatment of word-meaning relationships: synonymy, antonymy, hyponymy, meronymy, and the substitution-test discipline that grounds taxonomic-claim validation.
• Lyons, J. (1977). Semantics (2 vols.). Cambridge University Press. Comprehensive structural-semantics textbook covering sense relations, lexical fields, and the relational view of meaning.
• Miller, G. A. (1995). "WordNet: A Lexical Database for English." Communications of the ACM, 38(11), 39-41. The reference paper for Princeton WordNet — the largest empirically-grounded catalog of semantic relations between English lexemes; the working model for any taxonomic / mereological / antonymy relation system at scale.
• Fellbaum, C. (Ed.). (1998). WordNet: An Electronic Lexical Database. MIT Press. The collected technical account of WordNet's relation set, design decisions, and applications.
• Winston, M. E., Chaffin, R., & Herrmann, D. (1987). "A Taxonomy of Part-Whole Relations." Cognitive Science, 11(4), 417-444. The reference paper for the six PART-OF subtypes (component-integral, member-collection, portion-mass, stuff-object, feature-activity, place-area). Foundation for any mereological analysis.
• Fillmore, C. J. (1968). "The Case for Case." In E. Bach & R. T. Harms (Eds.), Universals in Linguistic Theory. Holt, Rinehart and Winston. The foundational paper for thematic / case roles (agent, patient, instrument, location, source, goal); the linguistics origin of the role catalog still used in event modeling.
• Jackendoff, R. (1990). Semantic Structures. MIT Press. Modern cognitive-semantics treatment of thematic roles, conceptual structure, and the relationship between semantic and syntactic categories.
• W3C. SKOS Simple Knowledge Organization System Reference (2009). The lightweight RDF vocabulary for broader/narrower/related and prefLabel/altLabel; the minimum-viable formalism for transmissible semantic relations.
• W3C. OWL 2 Web Ontology Language: Primer (Second Edition) (2012). Object properties and their characteristics — functional, inverse-functional, transitive, symmetric, asymmetric, reflexive, irreflexive — for the formal end of the relation-typing spectrum.
• Storey, V. C. (1993). "Understanding Semantic Relationships." VLDB Journal, 2(4), 455-488. Survey of semantic relations in entity-relationship-modeling contexts; the bridge from linguistic relation analysis to information-systems design.