Core Concepts
Understanding the fundamental concepts of FERIN: the concept plane, content plane, and how they work together.
The Two Planes
FERIN separates information into two distinct planes of existence:
Concept Plane
Where meaning lives
- Concepts — abstract ideas in concept systems
- Concept versions — specific realizations over time
- Concept relationships — connections between concepts
- Concept version relationships — connections between versions
Content Plane
Where data persists
- Register item classes — data schemas
- Register items — data instances
- Changes — records of modifications
Elements on Both Planes
Both object and functional identifiers apply to entities on both planes.
Typed connections exist as concept relationships, concept version relationships, and content relationships.
Key Relationship
Each concept version is backed by a register item (data instance) in a particular register item class (data schema). This separation enables concepts to evolve while preserving the integrity of the data that represents them.
This separation enables concepts to evolve (e.g., refining what "meter" means) while preserving the integrity of content that references them (e.g., measurements using "m").
Key Entities
Concept
An abstract idea or category that can be defined. A concept represents "what something means" rather than how it's represented.
Concept Version
A specific version of a concept's definition at a point in time. When a definition changes significantly, a new version is created.
Register Item Class
A data schema that defines the structure of register items. Each register item class specifies what fields and data types are valid for items in that class. Register item classes can evolve independently of the concepts they represent.
Register Item
A concrete piece of content in a register—an instance of a register item class. Register items have identifiers, status, and are managed through governance processes. Each concept version is backed by a register item.
urn:iso:std:iso:19135:meter, status "valid", added on 1960-10-14 by the BIPM, in the "Unit of Measure" register item class.Register
A managed collection of register items. A register has an owner, follows a register specification, and implements the FERIN framework.
Identifier
A unique label that distinguishes one entity from another. Identifiers exist on both the concept plane and content plane. FERIN requires two types of identifiers for each entity: an object identifier (non-redirectable, permanent) and a functional identifier (redirectable, supports hierarchy). This dual approach enables both stable citation and semantic addressing.
uuid:550e8400-... (permanent) and a functional identifier /concepts/units/length/meter (hierarchical, semantic).Relationship
A typed connection between entities. Relationships exist on both planes: concept relationships and concept version relationships on the concept plane, and content relationships on the content plane. Relationships enable lineage tracking, semantic navigation, and temporal reconstruction.
Change
A record of a modification to register content. Every action (add, modify, invalidate, supersede, etc.) creates a change record with complete information about what was modified, when, by whom, and why. Change records enable point-in-time reconstruction and complete audit trails.
Identifiers
Every entity in FERIN requires two types of identifiers:
Object Identifier
Non-redirectable, permanently assigned to a specific object. Provides permanent reference for citations.
550e8400-e29b-41d4-a716-446655440000 (UUID)Functional Identifier
Redirectable, reflects semantic intent. Must support hierarchical specification.
/concepts/meter/v2.0 (URI)What Needs Both Types
| Entity | Object ID | Functional ID |
|---|---|---|
| The Register | — | Required |
| Concepts | Required | Required |
| Concept Versions | Required | Required |
| Register Item Classes | Required | Required |
| Register Items | Required | Required |
| Changes | Required | Required |
See Identifier Design for implementation guidance.
Concept Granularity
The Challenge
One of the most common questions in FERIN implementation is: "When should I create a new concept vs. a new version of an existing concept?"
This isn't explicitly defined in the standard, so here's practical guidance:
Decision Framework
| Scenario | Action | Rationale |
|---|---|---|
| Definition clarified but meaning unchanged | New version | The concept's identity remains the same |
| Definition refined with additional precision | New version | Concept is the same, just better understood |
| Definition changed to mean something different | New concept | Identity has fundamentally changed |
| Scope or domain of application changed | New concept | Context has shifted |
| Same term, different meaning in different contexts | Multiple concepts | Homonyms require distinct concepts |
The "Would It Confuse Users?" Test
A practical heuristic: if existing references to the concept would become confusing or misleading after a change, create a new concept. If references would still be accurate (just less precise), create a new version.
Example: Defining "meter"
When the definition of meter changed from a physical bar (1889) to a wavelength (1960) to the speed of light (1983), these were new versions because the concept "meter" remained fundamentally the same unit of length—the precision just improved.
However, if meter had been redefined as "1/10 of a nautical mile," that would require a new concept because the fundamental meaning changed.
Concept Systems
Concepts are organized into concept systems—structured sets of related concepts. Common patterns include:
Generalization-Specialization
Broader concepts (general) relate to narrower concepts (specific).
Unit → Length Unit → meterWhole-Part
Concepts that are composed of other concepts.
Address → Street, City, PostalCodeSequential
Concepts that follow each other in a sequence.
Draft → Review → Approved → PublishedConcept Lifecycle
Concepts progress through a lifecycle as they are defined, refined, and potentially superseded:
Proposed
A new concept is submitted for consideration
Under Review
The concept definition is being evaluated
Valid
The concept is approved and available for use
Superseded
A newer version or replacement concept exists
Invalid/Retired
The concept is no longer valid for use