Relations
Complete reference for relationship types between concepts and register items.
Relation Types
| Relation | From | To | Required | Description |
|---|---|---|---|---|
hasConcept | Concept | Concept | No | Generalization (parent/child relationship) |
instanceOf | Concept | Concept | No | Membership in a category |
hasDefinition | Concept | Concept | No | Schema or type reference |
supersedes | Concept/Item | Concept/Item | No | Replacement relationship |
inherits | Concept | Concept | No | Property inheritance |
hasPart | Concept | Concept | No | Composition (whole/part) |
Detailed Relation Specifications
hasConcept
Generalization-Specialization
Indicates that one concept is a specialization (subtype) of another. The child concept inherits meaning from the parent but may add specificity.
Example
LengthUnit hasConcept Unit
(LengthUnit is a specialization of Unit)
Meter hasConcept LengthUnit
(Meter is a specialization of LengthUnit)Characteristics
- Transitive: If A hasConcept B and B hasConcept C, then A hasConcept C
- Asymmetric: If A hasConcept B, then not B hasConcept A
- Supports multiple inheritance (with caution)
instanceOf
Type-Instance
Indicates that one concept is an instance of another concept treated as a type or category.
Example
Meter instanceOf UnitType
(Meter is an instance of the UnitType category)
USD instanceOf CurrencyType
(USD is an instance of the CurrencyType category)Characteristics
- Not transitive
- Indicates membership rather than hierarchy
- Often used for classification
hasDefinition
Schema Reference
Indicates that a concept's structure or constraints are defined by another concept acting as a schema.
Example
AddressConcept hasDefinition AddressSchema
(AddressConcept is defined by the AddressSchema)
PersonName hasDefinition TextPattern
(PersonName is defined by a text pattern)Characteristics
- Used for validation and structure
- Schema concepts define required/optional attributes
- Supports type checking
supersedes
Replacement
Indicates that one concept or item replaces another. Used for versioning and content evolution.
Example
MeterDefinition2023 supersedes MeterDefinition1960
(The 2023 definition replaces the 1960 definition)
CountryCodeV2 supersedes CountryCodeV1
(Version 2 replaces version 1)Characteristics
- Creates a chain that can be followed to current
- May be transitive (follow chain to end)
- Used for migration and compatibility
inherits
Property Inheritance
Indicates that a concept inherits specific properties from another concept. Similar to hasConcept but focused on property sharing.
Example
DerivedUnit inherits BaseUnit
(DerivedUnit inherits properties from BaseUnit)
SpecializedAddress inherits GeneralAddress
(Specialized address inherits from general address)Characteristics
- May be partial (inherit some properties)
- Can override inherited properties
- Use for mixins and traits
hasPart
Composition
Indicates that one concept is composed of other concepts. Whole-part relationship.
Example
Address hasPart Street
Address hasPart City
Address hasPart PostalCode
(Address is composed of Street, City, and PostalCode)
FullName hasPart GivenName
FullName hasPart FamilyName
(FullName is composed of GivenName and FamilyName)Characteristics
- Supports cardinality (min/max parts)
- Parts may be optional or required
- Ordering may be significant
When to Use Each Relation
| Situation | Use | Rationale |
|---|---|---|
| Concept is a more specific type of another | hasConcept | Creates type hierarchy |
| Concept is an example of a category | instanceOf | Shows membership |
| Concept follows a schema/pattern | hasDefinition | Links to structure definition |
| Concept replaces an older one | supersedes | Maintains replacement chain |
| Concept shares properties from another | inherits | Enables reuse |
| Concept is composed of others | hasPart | Defines structure |
Relation Constraints
Inheritance Depth
How deep should inheritance chains be?
- Recommended maximum: 5-7 levels
- Deeper hierarchies become hard to understand and query
- Consider composition over deep inheritance
Circular References
Avoid circular relations:
hasConcept: A child cannot be its own ancestorsupersedes: A concept cannot supersede itself (directly or indirectly)hasPart: A part cannot contain its whole