This document specifies an abstract model for defining, documenting, and managing concept relationships in terminology resources and knowledge organization systems. It provides a generic mechanism for concept relationships that can be implemented across different standards, frameworks, and applications.
© 2025 Enosema Foundation.
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from the Enosema Foundation.
Enosema Foundation
2885 Sanford Ave Sw Suite 32361
Grandville MI 49418-1342
USA
E-mail: info@enosema.org
Published in the USA
Making meaning meaningful
This document specifies an abstract model for defining, documenting, and managing concept relationships in terminology resources and knowledge organization systems. It provides a generic mechanism for concept relationships that can be implemented across different standards, frameworks, and applications.
The Enosema Foundation (“ES”) is the premier non-profit standardization organization for terminology standardization and terminology related processes such as management. It facilitates the education, standardization, research, promotion, definition, and usage of terminology resources and management practices globally.
ES works with international partners and experts across the globe, reflecting the international nature of its mission. More information about ES is available on the official website ().
The procedures used to develop this document and those intended for its further maintenance are described in the ES Directives.
In particular, the different approval criteria needed for the different types of ES documents should be noted. This document was drafted in accordance with the editorial rules of the ES Directives.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ES shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be provided in the Introduction.
Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
This document was prepared by Technical Committee Terminology.
Concepts form the foundation of human knowledge and understanding. They represent units of thought that allow us to categorize, organize, and communicate about the world around us. However, concepts do not exist in isolation. They derive much of their meaning and utility from the relationships they form with other concepts. These concept relationships are fundamental to terminology management, knowledge organization, and semantic interoperability.
In our increasingly interconnected and information-rich world, the ability to precisely define, document, and exchange concept relationships has become essential. Organizations across domains face challenges in managing terminology consistently, sharing knowledge across boundaries, and ensuring that information systems can interoperate effectively. At the heart of these challenges lies the need for a standardized approach to concept relationships.
While numerous standards and frameworks exist for representing concept
relationships—including UML, OWL, SKOS, and various ISO standards—they often
implement relationships in ways specific to their particular paradigms and
applications. This has led to fragmentation and challenges in cross-system
interoperability. What has been missing is an abstract, generic mechanism for
defining concept relationships that can serve as a foundation for these various
implementations. Concept relationships exist independently of their representations. The same underlying relationship can be expressed through various notations, visualizations, or formalisms without changing its essential nature. This distinction between relationships and their representations is crucial for developing a truly abstract model.
The challenges of managing concept relationships include:
Lack of standardization in relationship types and their semantics
Difficulty in establishing relationships across domain boundaries
Inconsistent implementation of relationships in different systems
Ambiguity in relationship meaning and interpretation
Limited mechanisms for documenting relationship properties and constraints
Challenges in validating relationship assertions
This document addresses these challenges by providing a comprehensive framework for concept relationships that is abstract enough to be realized in various implementation contexts while being specific enough to ensure semantic precision. It establishes a foundation for:
Defining concept relationships in a standardized, implementation-independent manner
Classifying relationship types according to their semantic properties
Documenting relationship characteristics and constraints
Managing relationships within and across domain boundaries
Implementing relationships in various terminology and knowledge systems
The framework presented in this document is designed to support a wide range of applications, including:
Terminology databases and management systems
Knowledge organization systems (taxonomies, thesauri, ontologies)
Semantic networks and knowledge graphs
Information retrieval systems
Natural language processing applications
Data integration and exchange platforms
By providing a generic mechanism for defining concept relationships, this
document aims to enhance semantic interoperability, improve terminology
management practices, and facilitate knowledge exchange across systems, domains,
and languages. While concept relationships can be visualized through concept maps and similar representations, this document focuses on the underlying relationship structures rather than specific visualization techniques. The abstract model presented here can be realized through various visual and non-visual representations.
This standard builds upon the significant contributions of terminology and knowledge organization experts worldwide and the foundational work established in ISO standards. The Enosema Foundation recognizes the critical importance of concept relationships in facilitating mutual understanding across domains and disciplines.
This document specifies an abstract model for defining, documenting, and managing concept relationships in terminology resources and knowledge organization systems. It provides a generic mechanism for concept relationships that can be implemented across different standards, frameworks, and applications.
The abstract model and guidelines specified in this document apply to concept relationships in all subject fields, domains, and disciplines. The standardized approach enhances semantic precision, improves interoperability, and facilitates knowledge exchange across systems and domains.
This document provides:
An abstract model for concept relationships independent of specific implementation technologies
A classification system for relationship types based on their semantic properties
Guidelines for documenting relationship characteristics and constraints
Approaches for managing relationships within and across domain boundaries
Implementation guidance for various terminology and knowledge systems
Examples illustrating the application of the abstract model in different contexts
This document is intended for:
Terminology managers and terminologists responsible for developing and maintaining terminology resources
Knowledge engineers and ontologists designing knowledge organization systems
Standards developers working on terminology and knowledge representation standards
Information architects designing information retrieval systems
Software developers implementing terminology management and knowledge organization systems
Subject matter experts contributing to terminology resources and knowledge bases
Researchers in terminology science, knowledge organization, and semantic technologies
The abstract model specified here complements existing standards for terminology management, knowledge organization, and semantic technologies, providing a foundation that can be realized in various implementation contexts.
This document does not:
Prescribe specific notations or formalisms for representing relationships
Replace existing standards for terminology management or knowledge organization
Specify implementation details for particular systems or applications
Mandate specific visualization techniques for concept relationships
Provide domain-specific relationship taxonomies
Instead, it offers a generic framework that can be adapted and extended to meet the needs of specific domains, applications, and implementation contexts.
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
ISO Online browsing platform: available at
IEC Electropedia: available at
unit of knowledge created by a unique combination of characteristics
semantic connection between two or more concepts
Concept relationships can exist within a single domain or across multiple domains.
category of concept relationship characterized by specific semantic properties
Examples include hierarchical, associative, and equivalence relationship types.
conceptual framework that defines the structure, properties, and behavior of relationships independent of specific implementation technologies
statement that declares the existence of a specific relationship between two or more concepts
characteristic or attribute of a relationship that defines its semantic behavior
Examples include transitivity, symmetry, and reflexivity.
concept relationship where one concept is in a superordinate position to the other concept
hierarchical relationship between two concepts where the intension of the subordinate concept includes the intension of the superordinate concept plus at least one additional delimiting characteristic
hierarchical relationship between two concepts where the superordinate concept represents a whole and the subordinate concept represents a part of that whole
concept relationship that is neither hierarchical nor equivalence-based
Associative relationships include spatial, temporal, causal, and functional connections between concepts.
concept relationship where two or more concepts are considered to have the same or nearly the same meaning
Equivalence relationships can be exact, inexact, or partial, depending on the degree of conceptual overlap.
concept relationship that connects concepts from different subject fields or domains
specification of the number of concept instances that can participate in a relationship
specification of whether a relationship is unidirectional, bidirectional, or non-directional
relationship between relationships
Metarelationships can express dependencies, constraints, or other connections between different relationship assertions.
structured collection of relationship type definitions with their associated properties, constraints, and documentation
ability of different information systems to exchange and use information based on shared understanding of meaning
system for organizing knowledge that supports the description, management, and retrieval of information resources
Examples include taxonomies, thesauri, ontologies, and classification schemes.
field of special knowledge
restriction or condition that must be satisfied by a relationship assertion
Constraints can apply to the concepts involved, the relationship type, or the context in which the relationship is valid.
The abstract model for concept relationships provides a generic framework for defining, documenting, and managing relationships between concepts. This model is independent of specific implementation technologies and can be realized in various representation formats and systems.
The abstract model establishes a foundation for understanding concept relationships at a conceptual level, focusing on their essential structure, properties, and behavior rather than on particular notations or formalisms.
The fundamental structure of a concept relationship consists of:
Source concept(s): The concept(s) from which the relationship originates
Target concept(s): The concept(s) to which the relationship points
Relationship type: The semantic category of the relationship
Relationship properties: Characteristics that define the relationship’s behavior
Relationship metadata: Information about the relationship itself
This structure can be expressed as a triple (source, relationship type, target)
with associated properties and metadata, or in more complex forms for
relationships involving multiple concepts. While the basic structure resembles a triple, the abstract model does not mandate a specific representation format. The same relationship can be represented in various ways, including RDF triples, UML associations, or natural language statements.
A generic relationship between “mammal” and “animal” could be expressed as:
Source concept: mammal
Relationship type: is-a (generic relationship)
Target concept: animal
Properties: transitive, asymmetric
Metadata: asserted by taxonomic classification systems
This same relationship could be realized in different ways: * Natural language: “A mammal is a type of animal” * UML: A generalization relationship from Mammal to Animal * RDF: <mammal> <rdfs:subClassOf> <animal> * TBX: A hierarchical relationship with type=”generic” between the concepts
A relationship assertion is a statement that declares the existence of a specific relationship between two or more concepts. Each assertion includes:
The concepts involved in the relationship
The relationship type
Any qualifiers or parameters specific to this assertion
The context in which the assertion is valid
The authority for the assertion
Relationship assertions can be:
Stated (explicitly declared in a terminology resource)
Inferred (derived from other assertions through logical rules)
Inherited (acquired through hierarchical relationships)
Every relationship exists within a context that influences its interpretation and validity. Context elements include:
Domain context: The subject field(s) in which the relationship is valid
Temporal context: The time period during which the relationship holds
Cultural context: Cultural factors that affect the relationship’s meaning
Application context: The specific use case or application for which the relationship is relevant
The same concepts may have different relationships depending on the context. For example, “water” and “ice” might have a state-of-matter relationship in a physical science context, but a material-product relationship in a manufacturing context.
Logical properties define the mathematical behavior of relationships:
Transitivity: If A relates to B and B relates to C, then A relates to C
Symmetry: If A relates to B, then B relates to A
Reflexivity: A concept relates to itself
Asymmetry: If A relates to B, then B does not relate to A
Irreflexivity: A concept cannot relate to itself
These properties have important implications for relationship inference and validation.
Transitive: If “sparrow” is-a “bird” and “bird” is-a “animal”, then “sparrow” is-a “animal”
Symmetric: If “spouse A” is-married-to “spouse B”, then “spouse B” is-married-to “spouse A”
Reflexive: Every concept is-identical-to itself
Asymmetric: If “child” has-parent “parent”, then “parent” does not has-parent “child”
Irreflexive: A concept cannot be-parent-of itself
Cardinality specifies the number of concept instances that can participate in a relationship:
One-to-one: Each source concept relates to exactly one target concept
One-to-many: Each source concept relates to multiple target concepts
Many-to-one: Multiple source concepts relate to the same target concept
Many-to-many: Multiple source concepts relate to multiple target concepts
Cardinality constraints can be further refined with minimum and maximum values.
Relationships can have different directional characteristics:
Unidirectional: The relationship applies in one direction only
Bidirectional: The relationship applies in both directions
Non-directional: The relationship has no inherent direction
Directionality is distinct from symmetry. A relationship can be bidirectional without being symmetric if the relationship type differs in each direction.
Relationship strength indicates the degree of connection between concepts:
Mandatory: The relationship must exist for the concepts to be valid
Optional: The relationship may or may not exist
Weighted: The relationship has a numerical value indicating its strength or probability
Metarelationships are relationships between relationships. They enable the expression of complex semantic structures and constraints:
Dependency: One relationship depends on the existence of another
Exclusivity: If one relationship exists, another cannot
Composition: A relationship is composed of other relationships
Derivation: A relationship is derived from other relationships
Dependency: The “has-symptom” relationship between “disease” and “symptom” depends on the “affects” relationship between “disease” and “body-part”
Exclusivity: If “concept A” is-synonym-of “concept B”, then “concept A” cannot be-antonym-of “concept B”
Composition: The “is-grandparent-of” relationship is composed of two consecutive “is-parent-of” relationships
Derivation: The “is-sibling-of” relationship is derived from shared “is-child-of” relationships to a common parent
Relationship creation involves:
Identifying the concepts to be related
Determining the appropriate relationship type
Documenting the relationship properties and constraints
Providing supporting evidence or rationale
Recording metadata about the creation process
Documentation should include:
Clear identification of the concepts involved
Precise specification of the relationship type
Explicit statement of properties and constraints
Context information for proper interpretation
Source or authority information
Creation and modification timestamps
Relationship validation ensures that relationships are semantically correct and consistent. Validation checks include:
Type compatibility: Verifying that the concepts are valid for the relationship type
Property compliance: Ensuring the relationship satisfies its declared properties
Constraint satisfaction: Confirming that all constraints are met
Consistency: Checking for conflicts with existing relationships
Context validity: Verifying the relationship is valid in its stated context
Relationships evolve over time due to:
Changes in concept definitions
Advances in domain knowledge
Refinement of relationship types
Expansion to new contexts
Correction of errors or inconsistencies
Effective maintenance requires:
Version control for relationship assertions
Change tracking and history
Impact analysis for relationship changes
Propagation of changes to dependent relationships
Regular review and validation
The abstract model can be implemented in various ways, depending on the specific requirements and constraints of the application context. Implementation considerations include:
Representation format: How relationships are encoded (e.g., RDF, UML, natural language)
Storage mechanism: How relationships are stored and retrieved
Inference capabilities: How implicit relationships are derived from explicit ones
Validation mechanisms: How relationships are checked for correctness
User interface: How relationships are presented to and manipulated by users
The abstract model intentionally separates the conceptual understanding of relationships from their implementation details. This separation allows for flexibility in how relationships are realized in specific systems while maintaining semantic consistency.
Relationship types provide a semantic categorization of the connections between concepts. A well-defined classification of relationship types is essential for ensuring semantic precision, facilitating knowledge organization, and enabling effective information retrieval.
This section presents a classification system for relationship types based on
their semantic properties. The classification is designed to be comprehensive
enough to cover the major categories of relationships while remaining abstract
enough to be applicable across domains and implementation contexts. The classification presented here is not intended to be exhaustive but rather to provide a foundation that can be extended and refined for specific domains and applications. The focus is on establishing clear semantic distinctions between major relationship categories.
Hierarchical relationships establish a superordinate-subordinate structure between concepts. They are characterized by:
Asymmetry: If A is hierarchically related to B, B is not hierarchically related to A in the same way
Transitivity: If A is hierarchically related to B and B is hierarchically related to C, then A is hierarchically related to C
Irreflexivity: A concept cannot be hierarchically related to itself
Hierarchical relationships are fundamental to organizing concepts into structured systems and supporting inheritance of characteristics.
Generic relationships (also called “is-a” or “type-of” relationships) connect a more specific concept (species) to a more general concept (genus). The subordinate concept inherits all characteristics of the superordinate concept and adds at least one delimiting characteristic.
“Oak” has a generic relationship to “tree”
“Laptop” has a generic relationship to “computer”
“Pneumonia” has a generic relationship to “respiratory disease”
In each case, the subordinate concept (oak, laptop, pneumonia) inherits all the characteristics of the superordinate concept (tree, computer, respiratory disease) and adds at least one delimiting characteristic.
Generic relationships support:
Classification of concepts into categories
Inheritance of characteristics from superordinate to subordinate concepts
Reasoning from specific to general and general to specific
Organization of concepts into taxonomies
Partitive relationships (also called “part-of” or “has-part” relationships) connect a part to its whole. The superordinate concept represents the whole, while the subordinate concept represents a component or constituent.
“Wheel” has a partitive relationship to “car”
“Chapter” has a partitive relationship to “book”
“Neuron” has a partitive relationship to “nervous system”
In each case, the subordinate concept (wheel, chapter, neuron) is a component or constituent of the superordinate concept (car, book, nervous system).
Partitive relationships can be further classified based on the nature of the part-whole connection:
Component-object: Physical parts of objects (e.g., wheel-car)
Member-collection: Elements of collections (e.g., tree-forest)
Portion-mass: Portions of masses (e.g., slice-pie)
Material-object: Substances of objects (e.g., steel-car)
Feature-activity: Phases of activities (e.g., payment-purchase)
Place-area: Areas of larger areas (e.g., city-country)
Instance relationships connect an individual instance to its class or category. Unlike generic relationships, which connect classes to more general classes, instance relationships connect specific individuals to their classes.
“Eiffel Tower” has an instance relationship to “tower”
“Albert Einstein” has an instance relationship to “physicist”
“Amazon River” has an instance relationship to “river”
In each case, the subordinate concept represents a specific individual that is an instance of the superordinate concept.
Instance relationships are particularly important in:
Knowledge representation systems that distinguish between classes and instances
Proper name handling in terminology resources
Reference to specific entities in domain models
Associative relationships connect concepts that are semantically related but not in a hierarchical or equivalence manner. They are characterized by:
Semantic relevance: The concepts are meaningfully related
Non-hierarchical nature: Neither concept is superordinate to the other
Domain-specificity: The relationship types often reflect domain-specific connections
Associative relationships capture a wide range of semantic connections and are
essential for expressing the rich network of relationships between concepts in a
domain. Associative relationships are often less formally defined than hierarchical relationships and may have different properties depending on the specific relationship type. Some may be symmetric, others asymmetric; some may be transitive, others non-transitive.
Causal relationships connect concepts where one represents a cause and the other an effect. Subtypes include:
Cause-effect: Direct causal connection (e.g., virus-infection)
Process-result: Outcome of a process (e.g., combustion-ash)
Agent-action: Performer of an action (e.g., teacher-teaching)
Action-recipient: Target of an action (e.g., teaching-student)
In healthcare terminology:
“Smoking” has a causal relationship to “lung cancer”
“Virus” has a causal relationship to “infection”
“Bacteria” has a causal relationship to “inflammation”
These relationships express that one concept (smoking, virus, bacteria) causes or contributes to the other (lung cancer, infection, inflammation).
Temporal relationships connect concepts based on their time sequence. Subtypes include:
Precedence: One concept precedes another (e.g., pregnancy-childbirth)
Succession: One concept follows another (e.g., treatment-recovery)
Simultaneity: Concepts occur at the same time (e.g., fever-chills)
Duration: One concept represents the timespan of another (e.g., childhood-development)
In project management terminology:
“Planning” has a temporal relationship (precedes) to “execution”
“Testing” has a temporal relationship (precedes) to “deployment”
“Maintenance” has a temporal relationship (follows) to “implementation”
These relationships express the sequence in which the activities occur.
Spatial relationships connect concepts based on their physical or conceptual location. Subtypes include:
Containment: One concept contains another (e.g., building-room)
Adjacency: Concepts are next to each other (e.g., neighboring countries)
Orientation: Concepts have a directional relationship (e.g., north-south)
Distance: Concepts are separated by space (e.g., near-far)
Functional relationships connect concepts based on their purpose, role, or function. Subtypes include:
Tool-function: Object and its purpose (e.g., hammer-pounding)
Process-instrument: Activity and its tool (e.g., writing-pen)
Object-application: Item and its use (e.g., medicine-treatment)
Role-activity: Position and its responsibilities (e.g., doctor-diagnosis)
In information technology terminology:
“Firewall” has a functional relationship to “network protection”
“Database” has a functional relationship to “data storage”
“Algorithm” has a functional relationship to “problem solving”
These relationships express the purpose or function of each concept.
Developmental relationships connect concepts representing different stages or states of development. Subtypes include:
Source-product: Raw material and result (e.g., flour-bread)
Immature-mature: Developmental stages (e.g., larva-butterfly)
Natural-processed: Natural and processed forms (e.g., cotton-fabric)
Possessive relationships connect concepts where one possesses or owns the other. Subtypes include:
Owner-possession: Legal ownership (e.g., author-copyright)
Container-contained: Physical containment (e.g., bottle-water)
Attribute-entity: Characteristic and its bearer (e.g., color-object)
Equivalence relationships connect concepts that have the same or similar meaning. They are characterized by:
Semantic similarity: The concepts share significant meaning
Substitutability: One concept can replace another in certain contexts
Varying degrees of equivalence: From exact to partial
Equivalence relationships are crucial for terminology harmonization, cross-domain mapping, and information retrieval.
Exact equivalence connects concepts that are identical in meaning and can be substituted for each other in all contexts. Characteristics include:
Complete conceptual overlap
Same essential and delimiting characteristics
Interchangeability in all contexts
Symmetry: If A is exactly equivalent to B, B is exactly equivalent to A
“Heart attack” and “myocardial infarction” in medical terminology
“Automobile” and “car” in general language
“H₂O” and “water” in chemistry
These pairs represent the same concept and can be used interchangeably in their respective domains.
True exact equivalence is rare outside of synonymy within a single language. Even apparent synonyms often have subtle differences in connotation, register, or usage context.
Inexact equivalence connects concepts that are similar in meaning but not identical. Characteristics include:
Significant conceptual overlap
Minor differences in characteristics or scope
Limited interchangeability (context-dependent)
Symmetry: If A is inexactly equivalent to B, B is inexactly equivalent to A
“Happiness” and “joy” (similar emotions with different intensities)
“Forest” and “woods” (similar but with potential differences in size and density)
“Efficiency” and “effectiveness” (related but distinct performance measures)
These pairs represent similar but not identical concepts, with subtle differences in meaning or application.
Partial equivalence connects concepts where one includes the other but also covers additional meaning. Characteristics include:
Partial conceptual overlap
One concept has broader or narrower scope than the other
Limited interchangeability (direction-dependent)
Asymmetry: If A is partially equivalent to B, the relationship from B to A is different
“Furniture” and “chair” (chair is a type of furniture, but furniture includes more than chairs)
“Disease” and “infection” (all infections are diseases, but not all diseases are infections)
“Vehicle” and “car” (all cars are vehicles, but not all vehicles are cars)
In each case, one concept (furniture, disease, vehicle) is broader than the other (chair, infection, car).
Cross-language equivalence connects concepts expressed in different languages. This type of equivalence is particularly important for translation and multilingual terminology management. Characteristics include:
Consideration of linguistic and cultural differences
Varying degrees of equivalence (from exact to zero)
Context-dependent validity
Potential asymmetry due to linguistic and cultural factors
English “privacy” and French “vie privée” (partial equivalence due to cultural and legal differences)
English “computer” and German “Computer” (near-exact equivalence)
Japanese “wabi-sabi” and English (no direct equivalent — zero equivalence)
These examples illustrate different degrees of cross-language equivalence, from near-exact to zero.
A relationship type registry provides a structured collection of relationship type definitions with their associated properties, constraints, and documentation. The registry serves as a reference for consistent application of relationship types across terminology resources.
A comprehensive relationship type registry should include:
Unique identifier for each relationship type
Name and definition of the relationship type
Category within the classification system
Logical properties (transitivity, symmetry, etc.)
Domain and range constraints
Inverse relationship (if applicable)
Usage examples and notes
References to standards or authorities
The relationship type classification can be extended to meet the needs of specific domains and applications through:
Specialization: Creating subtypes of existing relationship types
Composition: Combining relationship types to create complex relationships
Contextualization: Adapting relationship types for specific contexts
Custom types: Defining domain-specific relationship types
Extension mechanisms should maintain compatibility with the core classification
while allowing for the expression of domain-specific semantics. When extending the relationship type classification, it is important to clearly document the relationship between custom types and the core classification to facilitate interoperability and understanding across systems.
Concept relationships do not exist in isolation but are embedded within specific domain contexts that influence their meaning, validity, and application. This section addresses the management of concept relationships within and across domain boundaries, focusing on the challenges and approaches for establishing semantic connections in different contextual environments.
The domain context of a relationship affects its interpretation, properties, and constraints. Understanding and properly documenting these contextual factors is essential for ensuring semantic precision and facilitating knowledge exchange across domains.
Same-domain relationships connect concepts within a single subject field or domain of knowledge. They are characterized by:
Shared conceptual framework: Concepts exist within the same system of knowledge
Common terminology: Concepts are typically expressed using domain-specific terms
Established relationship patterns: The domain often has conventional ways of relating concepts
Domain-specific relationship types: Specialized relationship types may exist for the domain
Consistent interpretation: Relationships are understood similarly by domain experts
Same-domain relationships benefit from the shared understanding and conventions
of the domain, making them generally easier to establish and validate than
cross-domain relationships. Even within a single domain, sub-domains or schools of thought may have different conceptual frameworks that affect how relationships are understood and applied. These differences should be documented as part of the relationship context.
Each domain tends to develop characteristic patterns of relationships that reflect its conceptual structure and knowledge organization. Examples include:
Healthcare: Emphasis on causal relationships (disease-symptom, treatment-outcome) and hierarchical classifications (taxonomies of diseases, procedures)
Engineering: Focus on functional relationships (component-function, material-property) and structural relationships (system-component)
Law: Prominence of authority relationships (statute-regulation), temporal relationships (precedent-subsequent ruling), and definitional relationships (term-legal definition)
Chemistry: Structured around compositional relationships (compound-element) and transformational relationships (reactant-product)
In the domain of medicine, the relationship between “bacteria” and “infection” is typically causal, while the relationship between “antibiotic” and “bacteria” is functional (treatment-target). These relationship patterns are characteristic of medical knowledge organization and would be understood by domain experts without extensive explanation.
Domains often develop specialized relationship types that capture domain-specific connections between concepts. These relationship types extend the general classification presented in Section 5 with domain-specific semantics.
In pharmacology, specialized relationship types might include:
“has-mechanism-of-action”: Connects a drug to its biochemical mechanism
“has-contraindication”: Links a medication to conditions where it should not be used
“has-adverse-effect”: Associates a drug with potential negative outcomes
These relationship types have specific meaning within pharmacology and may not be directly applicable to other domains.
When documenting domain-specific relationship types, it is important to:
Provide clear definitions that capture the domain-specific semantics
Map to the general relationship classification where possible
Document any special properties or constraints
Include domain-specific usage examples
Reference authoritative domain sources
Cross-domain relationships connect concepts from different subject fields or domains of knowledge. They present several challenges:
Conceptual framework differences: Domains may have different ways of organizing knowledge
Terminological variations: The same term may have different meanings across domains
Relationship interpretation differences: The same relationship type may be understood differently
Validation complexity: Expertise from multiple domains is needed for validation
Documentation requirements: More extensive context information is needed
Despite these challenges, cross-domain relationships are essential for
interdisciplinary work, knowledge integration, and comprehensive information
retrieval. Cross-domain relationships often reveal interesting connections and insights that might not be apparent within a single domain. They can stimulate innovation and new perspectives by bridging different knowledge areas.
Several approaches can be used to establish meaningful cross-domain relationships:
Interface concepts: Identifying concepts that naturally span domain boundaries
Bridging vocabularies: Creating intermediate vocabularies that connect domain terminologies
Upper ontologies: Using high-level conceptual frameworks that transcend specific domains
Mapping patterns: Developing standard patterns for relating concepts across domains
Expert collaboration: Bringing together experts from different domains to establish relationships
The concept “temperature” exists in multiple domains including meteorology, medicine, and physics. It can serve as an interface concept for establishing cross-domain relationships:
In meteorology: “temperature” has-effect-on “weather patterns”
In medicine: “body temperature” indicates “health status”
In physics: “temperature” is-measure-of “molecular kinetic energy”
By using “temperature” as an interface concept, relationships can be established between these domains, such as how “weather patterns” affect “health status.”
Cross-domain relationships require more extensive documentation than same-domain relationships to ensure proper interpretation. Documentation should include:
Clear identification of the source and target domains
Domain-specific definitions of the concepts involved
Explanation of how the relationship bridges the domains
Any constraints or conditions on the cross-domain application
Validation method and authority
Potential interpretation issues or ambiguities
A cross-domain relationship between the medical concept “inflammation” and the economic concept “inflation” might be documented as:
Source concept: “inflammation” (Medicine: A localized physical condition in which part of the body becomes reddened, swollen, hot, and often painful)
Target concept: “inflation” (Economics: A general increase in prices and fall in the purchasing value of money)
Relationship type: metaphorical-similarity
Explanation: Both concepts involve expansion or increase (physical tissues vs. prices) and are often described as harmful when excessive
Constraints: This is an analogical relationship for explanatory purposes, not a causal or definitional relationship
Validation: Linguistic analysis of economic literature showing the metaphorical use of medical terminology
The same relationship type may have different semantic nuances depending on the context. These variations should be documented to ensure proper interpretation.
The “part-of” relationship has different implications in different contexts:
Physical objects: A wheel is part-of a car (physical component that can be separated)
Organizations: A department is part-of a company (administrative division with functional independence)
Processes: Payment is part-of a purchase transaction (temporal phase that cannot exist independently)
Abstract entities: A chapter is part-of a book (content division that has meaning in relation to the whole)
While all these are partitive relationships, their specific semantics vary with the nature of the related concepts.
To fully specify the context of a relationship, several parameters should be documented:
Domain context: The subject field(s) in which the relationship is valid
Temporal context: Time period during which the relationship holds
Cultural context: Cultural factors affecting interpretation
Application context: Specific use case or purpose
Authority context: Source of the relationship assertion
Certainty context: Degree of confidence in the relationship
These parameters help users understand the conditions under which the
relationship is valid and applicable. Context parameters should be documented at an appropriate level of detail for the intended application. Not all parameters are equally relevant for all relationships, and the documentation should focus on those that significantly affect interpretation.
Relationship constraints may vary based on context. These context-dependent constraints should be explicitly documented:
Domain-specific cardinality constraints
Context-dependent property variations
Conditional validity rules
Contextual relationship strength
The relationship “treats” between “medication” and “disease” might have different constraints in different contexts:
Clinical practice context: Many-to-many cardinality (multiple medications may treat multiple diseases)
Regulatory approval context: One-to-many cardinality (a medication is approved for specific diseases only)
Research context: Probabilistic strength (degree of evidence for efficacy)
Historical context: Temporal validity (treatments considered effective change over time)
Clearly identifying domain boundaries is essential for proper relationship management. Approaches include:
Subject field classification: Using established classification systems to delineate domains
Concept clustering: Identifying natural groupings of closely related concepts
Terminology analysis: Examining term usage patterns to identify domain vocabularies
Expert consensus: Relying on expert judgment to define domain boundaries
Hybrid approaches: Combining multiple methods for more robust boundary identification
Domain boundaries should be documented in a way that supports relationship management while recognizing that boundaries may be fluid and overlapping.
Some concepts naturally span domain boundaries and can serve as anchors for cross-domain relationships. Characteristics of boundary-spanning concepts include:
Relevance to multiple domains
Consistent core meaning across domains
Recognition by experts from different fields
Frequent appearance in interdisciplinary contexts
Potential for different specializations in each domain
The concept “risk” spans multiple domains including finance, healthcare, engineering, and environmental science. While its core meaning of “potential for unwanted outcome” remains consistent, each domain has developed specialized aspects:
Finance: Quantified as volatility or probability of loss
Healthcare: Associated with factors that increase disease likelihood
Engineering: Analyzed through failure modes and effects
Environmental science: Assessed through impact and probability matrices
“Risk” can serve as a boundary-spanning concept to establish relationships between these domains, such as how financial risks relate to environmental risks.
Systematic mapping of relationships between domains can facilitate cross-domain knowledge integration. Approaches include:
Domain interface analysis: Identifying areas where domains naturally overlap
Relationship pattern mapping: Documenting how relationship types translate across domains
Concept alignment: Establishing correspondences between domain-specific concepts
Relationship transformation rules: Defining how relationships change when crossing domain boundaries
Domain relationship mapping provides a foundation for more sophisticated
cross-domain knowledge integration and semantic interoperability. Domain relationship mapping is not merely about connecting individual concepts but about understanding how entire conceptual structures relate across domains. This higher-level mapping can reveal structural similarities and differences that affect how relationships should be interpreted.
The abstract model for concept relationships described in this document can be implemented in various terminology systems and knowledge organization frameworks. This section provides guidance on implementing the model in different contexts, focusing on practical considerations while maintaining the abstract nature of the underlying relationships.
Implementation approaches should balance semantic precision with practical
usability, ensuring that the relationship model serves the needs of its intended
users while maintaining conceptual integrity. Implementation details will necessarily vary based on the specific requirements, constraints, and technologies of each system. The guidance provided here focuses on general principles and approaches rather than prescribing specific technical solutions.
Dictionaries and glossaries typically implement concept relationships implicitly through their definitional structure and cross-references. Implementation considerations include:
Definitional relationships: Using definition patterns that consistently express hierarchical and associative relationships
Cross-reference systems: Implementing explicit references to related entries
Usage examples: Illustrating relationships through contextual examples
Semantic indicators: Using typographical or symbolic markers to indicate relationship types
Entry structure: Organizing entry components to reflect conceptual relationships
Dictionary entry implementing concept relationships:
photosynthesis /ˌfoʊtoʊˈsɪnθəsɪs/ n. The process by which green plants and some other organisms use sunlight to synthesize nutrients from carbon dioxide and water. → See also chlorophyll, respiration.
This entry implements: * Generic relationship through the definition pattern “The process by which…” (photosynthesis is-a process) * Functional relationship through “use sunlight to synthesize…” (sunlight has-function-in photosynthesis) * Associative relationships through cross-references to related terms
Thesauri implement concept relationships more explicitly, typically using standardized relationship indicators. Implementation considerations include:
Standard relationship markers: Using consistent abbreviations or symbols for relationship types (BT, NT, RT, UF, etc.)
Hierarchical organization: Implementing generic and partitive relationships through broader/narrower term structures
Equivalence handling: Managing synonyms and near-synonyms through use/used-for relationships
Associative relationship specificity: Determining the appropriate level of detail for associative relationships
Scope notes: Providing context information to clarify relationship meaning
Thesaurus entry implementing concept relationships:
Renewable energy BT: Energy sources NT: Solar energy Wind energy Hydroelectric energy Geothermal energy Biomass energy RT: Sustainability Energy conservation Carbon footprint UF: Green energy Clean energy SN: Energy from sources that are naturally replenishing and virtually inexhaustible
This entry implements: * Generic relationships through broader term (BT) and narrower term (NT) * Associative relationships through related term (RT) * Equivalence relationships through used for (UF) * Context information through scope note (SN)
Taxonomies primarily implement hierarchical relationships in a structured classification system. Implementation considerations include:
Hierarchical structure: Implementing consistent parent-child relationships
Relationship type specification: Distinguishing between generic, partitive, and instance hierarchies
Sibling relationships: Managing concepts at the same hierarchical level
Polyhierarchy: Handling concepts that belong to multiple hierarchical paths
Faceted classification: Implementing multiple classification dimensions
Taxonomy implementation of hierarchical relationships:
` Living organisms ├── Animals │ ├── Vertebrates │ │ ├── Mammals │ │ │ ├── Primates │ │ │ │ └── Humans │ │ │ └── … │ │ ├── Birds │ │ └── … │ └── Invertebrates └── Plants ├── Flowering plants └── … `
This taxonomy implements generic relationships (is-a) between classes of organisms in a hierarchical structure.
Ontologies implement comprehensive relationship models with formal semantics. Implementation considerations include:
Formal relationship definitions: Implementing relationships with precise logical properties
Relationship constraints: Encoding domain, range, and cardinality constraints
Inference rules: Implementing rules for deriving implicit relationships
Relationship hierarchies: Organizing relationship types into their own hierarchical structure
Metarelationships: Implementing relationships between relationships
Ontology implementation of relationships in OWL (Web Ontology Language):
` <!— Define a relationship type -→ <owl:ObjectProperty rdf:about=”#treats”> <rdfs:domain rdf:resource=”#Medication”/> <rdfs:range rdf:resource=”#Disease”/> <rdf:type rdf:resource=”&owl;AsymmetricProperty”/> <rdfs:subPropertyOf rdf:resource=”#hasTherapeuticEffect”/> </owl:ObjectProperty>
<!— Use the relationship in concept definitions -→ <owl:Class rdf:about=”#Antibiotic”> <rdfs:subClassOf rdf:resource=”#Medication”/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource=”#treats”/> <owl:someValuesFrom rdf:resource=”#BacterialInfection”/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> `
This example implements: * A functional relationship type “treats” with domain and range constraints * Logical property (asymmetric) * Relationship hierarchy (subPropertyOf) * Relationship use in concept definition (Antibiotic treats BacterialInfection)
Semantic networks implement concept relationships as a graph of interconnected nodes. Implementation considerations include:
Node-link structure: Implementing concepts as nodes and relationships as links
Relationship labeling: Providing clear labels for relationship types
Directionality: Implementing directional or bidirectional links as appropriate
Weighting: Adding weight or strength indicators to relationships
Clustering: Organizing the network to reveal conceptual structures
TermBase eXchange (TBX) as specified in
Concept-oriented structure: Implementing the concept-based approach through termEntry elements
Relationship categories: Using appropriate data categories for relationship types
Cross-references: Implementing concept relationships through cross-references
Relationship properties: Documenting properties using appropriate data categories
Data category selection: Choosing appropriate data categories from standard registries
TBX implementation of concept relationships:
`xml <termEntry id=”ID67”> <descrip type=”subjectField”>Medicine</descrip> <langSet xml:lang=”en”> <tig> <term>diabetes mellitus</term> </tig> <descrip type=”definition”>Metabolic disease characterized by high blood glucose levels.</descrip> </langSet> <xref type=”broaderConcept” target=”ID42”>metabolic disease</xref> <xref type=”relatedConcept” target=”ID89”>insulin</xref> <xref type=”relatedConcept” target=”ID93”>hyperglycemia</xref> </termEntry> `
This example implements: * Generic relationship through broaderConcept cross-reference * Associative relationships through relatedConcept cross-references
Relational databases can implement concept relationships through various table structures. Implementation considerations include:
Concept-relationship-concept structure: Implementing relationships as associations between concept records
Relationship type tables: Creating tables of standardized relationship types
Relationship properties: Storing properties as attributes of relationship records
Context information: Including contextual parameters in relationship records
Integrity constraints: Implementing validation rules as database constraints
Relational database schema for concept relationships:
`sql CREATE TABLE Concepts ( ConceptID INT PRIMARY KEY, DomainID INT, FOREIGN KEY (DomainID) REFERENCES Domains(DomainID) );
CREATE TABLE RelationshipTypes ( RelationshipTypeID INT PRIMARY KEY, Name VARCHAR(100), Category VARCHAR(50), IsTransitive BOOLEAN, IsSymmetric BOOLEAN );
CREATE TABLE ConceptRelationships ( SourceConceptID INT, TargetConceptID INT, RelationshipTypeID INT, ContextID INT, Strength FLOAT, ValidFrom DATE, ValidTo DATE, PRIMARY KEY (SourceConceptID, TargetConceptID, RelationshipTypeID, ContextID), FOREIGN KEY (SourceConceptID) REFERENCES Concepts(ConceptID), FOREIGN KEY (TargetConceptID) REFERENCES Concepts(ConceptID), FOREIGN KEY (RelationshipTypeID) REFERENCES RelationshipTypes(RelationshipTypeID), FOREIGN KEY (ContextID) REFERENCES Contexts(ContextID) ); `
This schema implements: * Concepts as entities in their own table * Relationship types with their properties * Relationships as associations between concepts with type, context, and temporal validity
User interfaces for concept relationships should provide clear visual representations. Considerations include:
Graphical representations: Using diagrams, graphs, or networks to visualize relationships
Hierarchical displays: Implementing tree or indented list views for hierarchical relationships
Relationship indicators: Using consistent visual cues for different relationship types
Interactive exploration: Allowing users to navigate relationship networks
Filtering and focus: Enabling users to focus on specific relationship types or concepts
Interfaces for creating and editing relationships should support accurate and efficient relationship management. Considerations include:
Guided relationship creation: Providing templates or wizards for common relationship patterns
Validation feedback: Alerting users to potential issues or inconsistencies
Relationship type selection: Offering organized lists of available relationship types
Context specification: Enabling documentation of contextual parameters
Batch operations: Supporting efficient editing of multiple relationships
Search interfaces should leverage relationship information to enhance information retrieval. Considerations include:
Relationship-based queries: Allowing users to search based on relationship types and properties
Semantic expansion: Using relationships to expand search results to related concepts
Faceted search: Implementing relationship-based facets for result filtering
Relevance ranking: Incorporating relationship strength in result ordering
Query visualization: Showing how search results relate to query terms
Large terminology resources may contain millions of concepts and relationships, presenting scalability challenges. Solutions include:
Efficient data structures: Optimizing storage for relationship representation
Indexing strategies: Creating indexes for common relationship queries
Caching mechanisms: Caching frequently accessed relationship patterns
Distributed processing: Implementing distributed approaches for relationship computation
On-demand loading: Loading relationship data only when needed
Maintaining relationship consistency over time presents challenges as concepts and domains evolve. Solutions include:
Change impact analysis: Assessing how concept changes affect relationships
Relationship versioning: Maintaining historical versions of relationships
Automated validation: Implementing regular consistency checks
Deprecation processes: Managing the lifecycle of outdated relationships
User feedback mechanisms: Collecting and processing user input on relationships
Implementing relationships across different systems presents interoperability challenges. Solutions include:
Standard exchange formats: Using TBX and other standards for relationship exchange
Mapping services: Implementing services to translate between relationship models
Shared identifiers: Using common concept and relationship identifiers
API standardization: Developing consistent APIs for relationship access
Federated queries: Implementing distributed query capabilities across systems
Cross-system integration often requires compromise between the ideal abstract model and the practical constraints of existing systems. The goal should be to preserve the essential semantics of relationships while accommodating system-specific limitations.
The Enosema Foundation has developed a comprehensive approach to concept relationships that builds upon the abstract model presented in this document. This approach provides practical guidance for implementing concept relationships in terminology resources while maintaining semantic precision and interoperability.
The Enosema approach is designed to be adaptable to various domains and implementation contexts while ensuring consistency in how relationships are defined, documented, and managed.
The Enosema approach places concepts at the center of terminology work, recognizing that relationships exist between concepts rather than between terms. This principle ensures that:
Relationships are established based on conceptual analysis, not merely linguistic connections
Relationship assertions remain valid across different linguistic expressions of the same concepts
Conceptual structures are maintained independently of specific terminological representations
Relationships can be effectively translated across languages and cultures
Relationships should be explicitly defined and documented rather than left implicit. This principle ensures that:
Relationship semantics are clearly understood by all users
Relationship assertions can be validated against defined criteria
Relationships can be effectively exchanged between systems
Ambiguity in relationship interpretation is minimized
Relationships exist within specific contexts that affect their validity and interpretation. This principle ensures that:
Relationship assertions include appropriate contextual parameters
Domain-specific relationship semantics are properly documented
Relationships are not inappropriately generalized beyond their valid contexts
Users can assess the applicability of relationships to their specific needs
Relationships should be defined with sufficient semantic precision to support their intended applications. This principle ensures that:
Relationship types are clearly distinguished from one another
Relationship properties are explicitly documented
Relationship assertions can be validated against formal criteria
Relationships support accurate inference and reasoning
Relationship models should balance theoretical rigor with practical usability. This principle ensures that:
Relationship frameworks can be implemented in real-world systems
Users can effectively work with relationships without excessive complexity
Relationship documentation is accessible and understandable
Implementation guidance is provided for different contexts
The Enosema Foundation maintains a relationship type registry that provides a standardized collection of relationship types with their associated properties, constraints, and documentation. The registry includes:
Core relationship types applicable across domains
Domain-specific relationship types for selected fields
Mapping to standard relationship types in other systems
Implementation guidance for each relationship type
Examples illustrating proper usage
The registry serves as a reference for consistent application of relationship types across terminology resources and provides a foundation for semantic interoperability.
The core relationship types in the Enosema registry include:
Hierarchical relationships
generic (is-a, type-of)
partitive (part-of, has-part)
instance (instance-of, has-instance)
Associative relationships
causal (causes, caused-by)
temporal (precedes, follows)
functional (has-function, function-of)
spatial (located-in, contains)
Equivalence relationships
exact-equivalence (same-as)
inexact-equivalence (similar-to)
partial-equivalence (broader-than, narrower-than)
Each relationship type is defined with:
Unique identifier
Preferred name and synonyms
Definition and scope
Logical properties (transitivity, symmetry, etc.)
Inverse relationship (if applicable)
Usage notes and examples
Implementation guidance
The Enosema registry provides mechanisms for extending the core relationship types to meet specific domain needs:
Specialization: Creating subtypes of core relationship types
Composition: Combining relationship types to create complex relationships
Contextualization: Adapting relationship types for specific contexts
Custom types: Defining domain-specific relationship types
Extensions should maintain compatibility with the core registry while addressing domain-specific requirements.
Extension of a core relationship type for a specific domain:
Core type: “causes” (causal relationship) Domain: Pharmacology Extension: “has-side-effect”
Definition: A specialized causal relationship between a medication and an unintended physiological response.
Properties: * Inherits asymmetry from “causes” * Domain-specific cardinality: one-to-many (one medication can have many side effects) * Domain-specific constraint: side effects must be unintended effects
This extension maintains compatibility with the core “causes” type while adding domain-specific semantics and constraints.
The Enosema approach includes guidelines for documenting relationship assertions:
Source and target concepts should be clearly identified with unique identifiers
Relationship type should be specified using registry identifiers
Relationship properties should be explicitly stated
Context parameters should be documented as appropriate
Authority information should be included
Creation and modification metadata should be recorded
Documented relationship assertion:
Source concept: C0018681 (Headache)
Target concept: C0038454 (Stress, Psychological)
Relationship type: RT-023 (may-be-caused-by)
Properties: non-transitive, asymmetric
Context: Medical domain, general clinical knowledge
Strength: probable (not definitive)
Authority: Medical Subject Headings (MeSH)
Created: 2024-03-15
Last validated: 2025-01-10
Context documentation should include:
Domain context: Subject field(s) in which the relationship is valid
Temporal context: Time period during which the relationship holds
Cultural context: Cultural factors affecting interpretation
Application context: Specific use case or purpose
Authority context: Source of the relationship assertion
Certainty context: Degree of confidence in the relationship
The level of detail for context documentation should be appropriate for the intended application of the relationship.
Validation documentation should include:
Validation method: How the relationship was validated
Validation criteria: What standards or rules were applied
Validation authority: Who performed or approved the validation
Validation date: When the validation was performed
Validation outcome: Results of the validation process
Validation limitations: Any constraints or caveats
The Enosema approach includes processes for validating relationship assertions:
Formal validation: Checking compliance with logical properties and constraints
Expert validation: Review by domain experts
Consistency validation: Checking for conflicts with existing relationships
Contextual validation: Verifying validity within stated contexts
User validation: Gathering feedback from terminology users
Validation processes should be applied at appropriate stages in the relationship lifecycle, including creation, modification, and periodic review.
Quality criteria for relationship assertions include:
Accuracy: Correctness of the relationship assertion
Precision: Specificity of the relationship type
Completeness: Inclusion of all required information
Consistency: Compatibility with other relationship assertions
Clarity: Understandability of the relationship documentation
Traceability: Ability to track the source and history of the assertion
These criteria should be applied during validation processes and used to guide continuous improvement of relationship resources.
The Enosema governance framework for relationships includes:
Roles and responsibilities for relationship management
Decision-making processes for relationship issues
Change management procedures
Conflict resolution mechanisms
Review and approval workflows
Feedback processing procedures
The governance framework ensures that relationships are managed consistently and that changes are properly controlled and documented.
The Enosema approach includes implementation patterns for different contexts:
Reference work patterns: How to implement relationships in dictionaries, glossaries, and thesauri
Knowledge organization patterns: How to implement relationships in taxonomies, ontologies, and semantic networks
Database patterns: How to implement relationships in terminology databases and other structured repositories
Exchange patterns: How to represent relationships in exchange formats
These patterns provide practical guidance while maintaining compatibility with the abstract model.
The Enosema approach defines conformance levels for relationship implementation:
Level 1: Basic relationship support with minimal documentation
Level 2: Structured relationship types with standard properties
Level 3: Comprehensive relationship model with context documentation
Level 4: Full implementation of the abstract model with all features
These levels allow systems to implement relationships at an appropriate level of sophistication for their needs while providing a path for future enhancement.
For existing terminology resources, the Enosema approach provides migration strategies:
Assessment: Evaluating current relationship implementations
Mapping: Relating existing relationships to the abstract model
Enrichment: Adding missing relationship information
Validation: Checking migrated relationships against quality criteria
Integration: Incorporating relationships into the overall terminology system
Migration strategies recognize that many systems have existing relationship implementations that need to be preserved while enhancing their semantic precision and interoperability.
The Enosema Foundation provides or recommends tools for relationship management:
Relationship registry browser: For exploring standardized relationship types
Relationship validator: For checking relationship assertions against rules
Relationship visualization tools: For exploring relationship networks
Relationship exchange utilities: For converting between formats
Relationship documentation templates: For consistent documentation
These tools support the practical implementation of the abstract model in various contexts.
The Enosema Foundation provides training and guidance materials:
Introductory guides to concept relationships
Best practice documentation
Implementation tutorials
Case studies of successful relationship management
Troubleshooting guides for common issues
These materials help organizations develop the knowledge and skills needed for effective relationship management.
The Enosema Foundation fosters a community of practice around concept relationships:
Forums for discussing relationship issues
Repositories of shared relationship resources
Collaborative development of relationship standards
Expert networks for relationship validation
Events for knowledge exchange and professional development
Community resources leverage collective expertise to advance the state of the art in relationship management and provide mutual support for implementation challenges.
This annex provides a collection of common relationship patterns that can be used as templates for implementing concept relationships in various domains and applications. These patterns represent recurring structures of relationships that have proven useful in terminology management and knowledge organization.
The patterns are presented at an abstract level and can be adapted to specific domains and implementation contexts. Each pattern includes a description, typical applications, implementation considerations, and examples.
The hierarchical classification pattern organizes concepts into a tree or directed acyclic graph structure using generic (is-a) relationships. Each concept (except the root) has one or more superordinate concepts, and concepts inherit characteristics from their superordinates.
Root concept(s) at the top level
Multiple levels of subordinate concepts
Generic relationships connecting levels
Inheritance of characteristics down the hierarchy
Potential for multiple inheritance (polyhierarchy)
Scientific taxonomies (biology, chemistry, etc.)
Product and service classifications
Organizational structures
Document and content categorization
Skill and competency frameworks
Deciding between strict hierarchy (single inheritance) and polyhierarchy (multiple inheritance)
Determining appropriate granularity at each level
Handling cross-classification needs
Managing inheritance exceptions
Versioning and evolution of the classification
Medical disease classification:
` Diseases ├── Infectious diseases │ ├── Bacterial infections │ │ ├── Tuberculosis │ │ └── Pneumococcal pneumonia │ ├── Viral infections │ │ ├── Influenza │ │ └── COVID-19 │ └── … ├── Neoplastic diseases │ ├── Benign neoplasms │ ├── Malignant neoplasms │ │ ├── Carcinomas │ │ ├── Sarcomas │ │ └── … │ └── … └── … `
This pattern uses generic relationships to classify diseases by etiology and pathology, with each level inheriting characteristics from higher levels.
The compositional pattern represents how concepts combine to form more complex structures. It uses partitive relationships to connect components to wholes and can represent multiple levels of composition.
Whole concept at the top level
Component concepts at lower levels
Partitive relationships connecting components to wholes
Potential for multiple levels of decomposition
Optional cardinality constraints on components
Product and system architecture
Document and content structure
Organizational composition
Geographical and administrative divisions
Anatomical structures
Distinguishing between mandatory and optional components
Handling cardinality constraints
Representing ordering of components (if relevant)
Managing shared components
Documenting component roles and functions
Automotive compositional structure:
` Automobile ├── has-part: Powertrain system │ ├── has-part: Engine │ │ ├── has-part: Cylinder block │ │ ├── has-part: Pistons │ │ └── … │ ├── has-part: Transmission │ └── … ├── has-part: Chassis system │ ├── has-part: Frame │ ├── has-part: Suspension │ └── … ├── has-part: Electrical system └── … `
This pattern uses partitive relationships to represent the physical composition of an automobile, with multiple levels of decomposition.
The process flow pattern represents sequences of activities, events, or states using temporal relationships. It captures the order of steps in a process and can include branching, loops, and parallel paths.
Process steps or states as concepts
Temporal relationships connecting steps
Potential branch and merge points
Optional conditions on transitions
Start and end points
Business processes
Clinical pathways
Manufacturing procedures
Project workflows
System behavior models
Representing sequential, parallel, and alternative paths
Handling conditional transitions
Documenting iteration and looping
Managing exceptions and error paths
Connecting to resources and actors
Clinical diagnostic process:
` Patient presentation ├── precedes: Initial assessment │ ├── precedes: Physical examination │ └── precedes: Medical history taking ├── may-precede: Emergency intervention (if critical) └── …
Physical examination + Medical history taking ├── precedes: Differential diagnosis │ ├── precedes: Diagnostic testing │ │ ├── precedes: Test result interpretation │ │ │ ├── precedes: Diagnosis confirmation (if positive) │ │ │ └── precedes: Alternative testing (if negative) │ │ └── … │ └── … └── … `
This pattern uses temporal relationships to represent the clinical process from patient presentation to diagnosis, including alternative paths based on conditions.
The causal network pattern represents cause-effect relationships between concepts. It can capture complex causal chains, multiple causes and effects, and causal strength or probability.
Cause and effect concepts
Causal relationships connecting them
Potential for causal chains (A causes B causes C)
Possible multiple causes for a single effect
Optional causal strength or probability indicators
Risk analysis
Fault diagnosis
Scientific explanations
Medical etiology
Environmental impact assessment
Distinguishing between necessary and sufficient causes
Representing causal strength or probability
Handling complex causal networks
Documenting temporal aspects of causation
Managing uncertainty and conflicting evidence
Environmental causal network:
` Industrial emissions ├── causes: Air pollution │ ├── causes: Respiratory diseases │ │ ├── causes: Increased healthcare costs │ │ └── causes: Reduced quality of life │ └── causes: Acid rain │ ├── causes: Water acidification │ │ └── causes: Aquatic ecosystem damage │ └── causes: Soil degradation │ └── causes: Reduced agricultural productivity └── causes: Greenhouse gas increase └── causes: Climate change ├── causes: Sea level rise ├── causes: Extreme weather events └── … `
This pattern uses causal relationships to represent the environmental impacts of industrial emissions, showing causal chains and multiple effects.
The functional pattern represents the purposes, roles, and functions of concepts and how they relate to activities, goals, and requirements. It connects entities to their functions and functions to their contexts.
Entity concepts (objects, systems, etc.)
Function concepts (purposes, capabilities)
Functional relationships connecting entities to functions
Context concepts (situations, environments)
Context relationships connecting functions to contexts
Product and system design
Requirements engineering
Job and role descriptions
Tool and technology classification
Service descriptions
Distinguishing between primary and secondary functions
Representing functional hierarchies
Connecting functions to performance criteria
Documenting functional dependencies
Handling multi-functional entities
Medical device functional pattern:
` Ventilator ├── has-function: Oxygen delivery │ ├── has-context: Respiratory failure │ └── has-context: Anesthesia ├── has-function: Airway pressure management │ ├── has-context: Acute respiratory distress syndrome │ └── has-context: Chronic obstructive pulmonary disease ├── has-function: Respiratory rate control └── …
Oxygen delivery ├── has-requirement: Oxygen source ├── has-requirement: Delivery mechanism └── has-performance-indicator: Oxygen concentration `
This pattern uses functional relationships to connect a medical device (ventilator) to its functions, contexts, and requirements.
The equivalence mapping pattern represents relationships between equivalent or similar concepts across different systems, domains, languages, or versions. It captures different degrees of equivalence and provides context for the mappings.
Source concepts from one system or domain
Target concepts from another system or domain
Equivalence relationships connecting source and target
Equivalence type indicators (exact, inexact, partial)
Mapping context and metadata
Terminology mapping and alignment
Standard harmonization
Cross-language terminology
System integration
Version migration
Documenting the degree of equivalence
Handling one-to-many and many-to-many mappings
Providing mapping rationale and evidence
Managing mapping versioning
Addressing gaps and untranslatable concepts
Cross-terminology medical mapping:
` SNOMED CT: Myocardial infarction (22298006) ├── exact-equivalent-to ICD-10: Acute myocardial infarction (I21) ├── exact-equivalent-to MeSH: Myocardial Infarction (D009203) └── broader-than ICD-10: Acute transmural myocardial infarction of anterior wall (I21.0)
SNOMED CT: Pneumonia (233604007) ├── exact-equivalent-to ICD-10: Pneumonia, organism unspecified (J18) ├── exact-equivalent-to MeSH: Pneumonia (D011014) ├── narrower-than ICD-10: Pneumonia (J12-J18) └── broader-than ICD-10: Viral pneumonia, not elsewhere classified (J12) `
This pattern uses equivalence relationships to map concepts between different medical terminologies (SNOMED CT, ICD-10, MeSH), indicating the type of equivalence for each mapping.
The semantic field pattern organizes concepts into interconnected networks based on their semantic relationships within a domain. It represents the rich web of associations that give concepts their full meaning in context.
Central concept(s) as focal points
Related concepts connected by various relationship types
Multiple relationship layers (hierarchical, associative, etc.)
Cross-connections between related concepts
Domain context binding the field together
Domain vocabulary development
Semantic analysis
Content organization
Knowledge representation
Educational materials
Balancing comprehensiveness with usability
Selecting appropriate relationship types
Determining field boundaries
Handling overlapping semantic fields
Representing relationship strength or salience
Semantic field for “education”:
` Education ├── is-a: Process ├── has-part: Teaching │ ├── has-agent: Teacher │ │ ├── has-role: Instructor │ │ ├── has-role: Mentor │ │ └── has-role: Facilitator │ └── has-recipient: Student │ ├── has-characteristic: Learning style │ └── has-activity: Studying ├── has-part: Learning │ ├── has-result: Knowledge acquisition │ ├── has-result: Skill development │ └── has-result: Attitude formation ├── has-setting: Educational institution │ ├── has-instance: School │ ├── has-instance: University │ └── has-instance: Training center ├── has-instrument: Curriculum │ ├── has-part: Course │ ├── has-part: Lesson │ └── has-part: Assessment └── … `
This pattern uses multiple relationship types to represent the semantic field of education, showing how concepts are interconnected in this domain.
The cross-domain bridge pattern connects concepts from different domains through interface concepts and specialized cross-domain relationships. It facilitates knowledge integration and interdisciplinary communication.
Source domain concepts
Target domain concepts
Interface concepts that span domains
Cross-domain relationships
Domain context documentation
Interdisciplinary research
Cross-sector collaboration
Integrated information systems
Translational science
Policy development
Identifying appropriate interface concepts
Documenting domain-specific meanings
Establishing clear cross-domain relationship semantics
Handling terminology differences
Managing conceptual misalignments
Bridge between medical and legal domains:
` Medical domain: Patient consent ├── is-a: Medical process ├── has-purpose: Treatment authorization ├── has-agent: Healthcare provider ├── has-recipient: Patient └── cross-domain-relates-to: Informed consent (Legal domain)
Legal domain: Informed consent ├── is-a: Legal doctrine ├── has-purpose: Liability protection ├── has-requirement: Disclosure of risks ├── has-result: Legal authorization └── cross-domain-relates-to: Patient consent (Medical domain)
Interface concept: Capacity to consent ├── medical-aspect: Mental competence assessment ├── legal-aspect: Legal capacity determination ├── bridges: Medical and legal domains `
This pattern uses cross-domain relationships and an interface concept to connect related concepts from the medical and legal domains.
The versioning pattern represents relationships between different versions, editions, or states of concepts over time. It captures the evolution of concepts and maintains connections between successive versions.
Concept versions as separate entities
Temporal relationships between versions
Version metadata (dates, status, etc.)
Change documentation
Optional branching and merging
Standards versioning
Terminology evolution
Content management
Product development
Historical documentation
Determining version granularity
Documenting version differences
Handling backward compatibility
Managing concurrent versions
Implementing version control policies
Standard versioning pattern:
` ISO 9001:2008 ├── has-previous-version: ISO 9001:2000 │ └── has-previous-version: ISO 9001:1994 ├── has-next-version: ISO 9001:2015 ├── has-status: Superseded ├── valid-from: 2008-11-14 ├── valid-to: 2018-09-14 └── has-change: ├── Addition of risk management principles ├── Enhanced focus on process approach └── …
ISO 9001:2015 ├── has-previous-version: ISO 9001:2008 ├── has-status: Current ├── valid-from: 2015-09-15 └── has-change: ├── New high-level structure ├── Explicit risk-based thinking └── … `
This pattern uses temporal relationships and metadata to represent the evolution of the ISO 9001 standard through multiple versions, documenting the changes between versions and their validity periods.
This annex provides mappings between the abstract model for concept relationships presented in this document and various existing standards and frameworks for representing relationships. These mappings demonstrate how the abstract model can be realized in different implementation contexts while maintaining semantic consistency.
The mappings are not intended to be exhaustive but rather to illustrate the correspondence between the abstract model and common implementation approaches. They can serve as a guide for implementing the abstract model in specific technical environments.
ISO 704:2022 (Terminology work — Principles and methods) provides fundamental principles for terminology work, including the representation of concept relationships. The mapping between the abstract model and ISO 704 includes:
| Abstract Model Element | ISO 704 Element | Notes |
|---|---|---|
| Concept | Concept | Direct correspondence |
| Concept relationship | Concept relation | Direct correspondence |
| Hierarchical relationships | Hierarchical relations | Direct correspondence |
| Generic relationship | Generic relation | Direct correspondence |
| Partitive relationship | Partitive relation | Direct correspondence |
| Instance relationship | Instance relation | Direct correspondence |
| Associative relationships | Associative relations | Direct correspondence |
| Equivalence relationships | Not explicitly covered | Can be represented through terminological synonymy |
| Relationship properties | Relation characteristics | Partial correspondence |
| Relationship context | Subject field | Partial correspondence |
ISO 24156-1:2014 (Graphic notations for concept modelling in terminology work and its relationship with UML — Part 1: Guidelines for using UML notation in terminology work) provides guidance on using UML for representing concept relationships. The mapping includes:
| Abstract Model Element | ISO 24156-1 Element | Notes |
|---|---|---|
| Concept | UML Class | Concepts are represented as classes |
| Concept relationship | UML Association | Relationships are represented as associations |
| Hierarchical relationships | UML Generalization | Generic relationships use the generalization relationship |
| Generic relationship | UML Generalization | Direct correspondence |
| Partitive relationship | UML Aggregation/Composition | Partitive relationships use aggregation or composition |
| Instance relationship | UML Instantiation | Instances are represented as objects |
| Associative relationships | UML Association | With appropriate stereotypes |
| Equivalence relationships | UML Dependency | With «equivalent» stereotype |
| Relationship properties | UML Association properties | Properties like transitivity can be represented as constraints |
| Relationship context | UML Package | Contexts can be represented as packages |
ISO 30042:2019 (Management of terminology resources — TermBase eXchange (TBX)) provides a format for exchanging terminology data. The mapping includes:
| Abstract Model Element | TBX Element | Notes |
|---|---|---|
| Concept | <termEntry> | Concepts are represented as term entries |
| Concept relationship | <xref> | Relationships are represented as cross-references |
| Hierarchical relationships | <xref type=”broaderConcept”>, <xref type=”narrowerConcept”> | Using appropriate relationship types |
| Generic relationship | <xref type=”superordinateConcept”>, <xref type=”subordinateConcept”> | Using appropriate relationship types |
| Partitive relationship | <xref type=”wholeConcept”>, <xref type=”partConcept”> | Using appropriate relationship types |
| Instance relationship | <xref type=”instanceConcept”>, <xref type=”generalConcept”> | Using appropriate relationship types |
| Associative relationships | <xref type=”relatedConcept”> | With more specific types as needed |
| Equivalence relationships | <termNote type=”termType”> | Within a concept for same-language equivalence |
| Relationship properties | Custom data categories | Can be represented using custom data categories |
| Relationship context | <descrip type=”subjectField”> | Context represented through subject field |
The Resource Description Framework (RDF) and RDF Schema (RDFS) provide a foundation for representing relationships in the semantic web. The mapping includes:
| Abstract Model Element | RDF/RDFS Element | Notes |
|---|---|---|
| Concept | rdfs:Class | Concepts are represented as classes |
| Concept relationship | rdf:Property | Relationships are represented as properties |
| Hierarchical relationships | rdfs:subClassOf | For generic relationships |
| Generic relationship | rdfs:subClassOf | Direct correspondence |
| Partitive relationship | Custom property | E.g., ex:hasPart, ex:isPartOf |
| Instance relationship | rdf:type | Direct correspondence |
| Associative relationships | Custom properties | With appropriate semantics |
| Equivalence relationships | owl:equivalentClass, owl:sameAs | Using OWL extensions to RDF |
| Relationship properties | rdfs:domain, rdfs:range | Basic properties; others require extensions |
| Relationship context | Named graphs | Contexts can be represented as named graphs |
The Web Ontology Language (OWL) extends RDF with more expressive constructs for representing relationships. The mapping includes:
| Abstract Model Element | OWL Element | Notes |
|---|---|---|
| Concept | owl:Class | Concepts are represented as classes |
| Concept relationship | owl:ObjectProperty | Relationships are represented as object properties |
| Hierarchical relationships | rdfs:subClassOf | For generic relationships |
| Generic relationship | rdfs:subClassOf | Direct correspondence |
| Partitive relationship | Custom object property | With appropriate semantics |
| Instance relationship | rdf:type | Direct correspondence |
| Associative relationships | Custom object properties | With appropriate semantics |
| Equivalence relationships | owl:equivalentClass, owl:sameAs | Direct correspondence |
| Relationship properties | Property characteristics | owl:TransitiveProperty, owl:SymmetricProperty, etc. |
| Relationship context | owl:imports, Named graphs | Contexts can be represented through imports or named graphs |
The Simple Knowledge Organization System (SKOS) provides a model for expressing knowledge organization systems. The mapping includes:
| Abstract Model Element | SKOS Element | Notes |
|---|---|---|
| Concept | skos:Concept | Direct correspondence |
| Concept relationship | skos:semanticRelation | Base class for all relationships |
| Hierarchical relationships | skos:broader, skos:narrower | Direct correspondence |
| Generic relationship | skos:broader, skos:narrower | SKOS doesn’t distinguish between generic and partitive |
| Partitive relationship | skos:broader, skos:narrower | With optional extensions |
| Instance relationship | Not directly supported | Can be represented with extensions |
| Associative relationships | skos:related | Direct correspondence |
| Equivalence relationships | skos:exactMatch, skos:closeMatch | For cross-scheme equivalence |
| Relationship properties | Not directly supported | Requires extensions |
| Relationship context | skos:ConceptScheme | Contexts represented as concept schemes |
Thesaurus standards like ISO 25964 provide models for representing relationships in thesauri. The mapping includes:
| Abstract Model Element | Thesaurus Element | Notes |
|---|---|---|
| Concept | Concept | Direct correspondence |
| Concept relationship | Relationship | Direct correspondence |
| Hierarchical relationships | BT/NT (Broader Term/Narrower Term) | Direct correspondence |
| Generic relationship | BTG/NTG (Broader Term Generic/Narrower Term Generic) | In ISO 25964 |
| Partitive relationship | BTP/NTP (Broader Term Partitive/Narrower Term Partitive) | In ISO 25964 |
| Instance relationship | BTI/NTI (Broader Term Instance/Narrower Term Instance) | In ISO 25964 |
| Associative relationships | RT (Related Term) | Direct correspondence |
| Equivalence relationships | USE/UF (Use/Used For) | For same-language equivalence |
| Relationship properties | Not explicitly represented | Implicit in relationship types |
| Relationship context | Microthesaurus, Facet | Contexts represented through structural elements |
Taxonomies typically focus on hierarchical relationships. The mapping includes:
| Abstract Model Element | Taxonomy Element | Notes |
|---|---|---|
| Concept | Category, Class | Concepts represented as categories or classes |
| Concept relationship | Hierarchical relationship | Primarily hierarchical |
| Hierarchical relationships | Parent-child relationship | Direct correspondence |
| Generic relationship | Is-a relationship | Direct correspondence |
| Partitive relationship | Has-part relationship | When supported |
| Instance relationship | Instance relationship | When supported |
| Associative relationships | See-also relationship | Limited support in most taxonomies |
| Equivalence relationships | Synonym relationship | Limited to same-language synonyms |
| Relationship properties | Not explicitly represented | Implicit in relationship types |
| Relationship context | Facet, Domain | Contexts represented through structural elements |
Relational databases can represent concept relationships through various table structures. The mapping includes:
| Abstract Model Element | Relational DB Element | Notes |
|---|---|---|
| Concept | Entity (table) | Concepts represented as entities |
| Concept relationship | Relationship (foreign key) | Relationships represented through foreign keys |
| Hierarchical relationships | Self-referencing relationship | With type indicators |
| Generic relationship | Self-referencing relationship | With type=”generic” |
| Partitive relationship | Self-referencing relationship | With type=”partitive” |
| Instance relationship | Foreign key relationship | Between instance and class tables |
| Associative relationships | Many-to-many relationship | Through junction tables |
| Equivalence relationships | Synonym table | With equivalence type indicators |
| Relationship properties | Attributes in relationship tables | Properties stored as attributes |
| Relationship context | Context table | With relationships to context entities |
Graph databases are particularly well-suited for representing concept relationships. The mapping includes:
| Abstract Model Element | Graph DB Element | Notes |
|---|---|---|
| Concept | Node | Concepts represented as nodes |
| Concept relationship | Edge | Relationships represented as edges |
| Hierarchical relationships | Typed edge | With hierarchical type label |
| Generic relationship | Edge with “is-a” label | Direct correspondence |
| Partitive relationship | Edge with “part-of” label | Direct correspondence |
| Instance relationship | Edge with “instance-of” label | Direct correspondence |
| Associative relationships | Typed edges | With appropriate type labels |
| Equivalence relationships | Typed edges | With equivalence type labels |
| Relationship properties | Edge properties | Properties stored as edge attributes |
| Relationship context | Context nodes or edge properties | Contexts represented through additional structures |
When mapping the abstract model to specific standards or frameworks, several considerations should be taken into account:
Semantic precision: Ensure that the semantic nuances of the abstract model are preserved in the target representation
Relationship type granularity: Adjust the level of detail in relationship types to match the capabilities of the target system
Property representation: Determine how to represent relationship properties that may not be directly supported
Context handling: Develop appropriate mechanisms for representing relationship contexts
Extension mechanisms: Utilize extension mechanisms in the target system to represent aspects of the abstract model that are not directly supported
Documentation: Clearly document the mapping to ensure consistent implementation and interpretation
No single implementation can perfectly capture all aspects of the abstract model. The goal should be to preserve the essential semantics while adapting to the constraints and capabilities of the target system.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Withdrawn.
Withdrawn.
Withdrawn.