CCR Deep Dive
The Complete Concept Register is FERIN's most capable register type. Learn when to use it and how to implement its advanced features.
What Makes CCR Special
The Complete Concept Register (CCR) combines all FERIN capabilities: content management, concept modeling, formal governance, and full commitments. It's designed for registers that serve as authoritative sources for communities, industries, or nations.
Content Management
Store, version, and status track register items
Concept Modeling
Define, relate, and evolve concepts independently
Formal Governance
Proposals, approvals, appeals, and audit trails
Full Commitments
Access, persistence, and transparency guarantees
When to Choose CCR
CCR is powerful but requires significant investment. Choose CCR when:
Use CCR
- External communities depend on your register
- Definitions evolve and version history matters
- Regulatory or legal requirements apply
- Long-term persistence is critical
- You need to demonstrate transparent governance
- The register serves as a citable standard
Consider Alternatives
- Internal use only with no external users
- Content is static or rarely changes
- No governance requirements
- Short-term or project-specific needs
- Resource constraints limit investment
- Simpler register types meet requirements
CCR in the Wild
CCR is typically used for:
- National and international standards registries
- Scientific terminology registries
- Industry code lists with legal standing
- Government reference data
- Academic discipline taxonomies
CCR-Specific Capabilities
Concept Inheritance (Is-A)
Define hierarchical relationships where concepts specialize parent concepts.
// Concept hierarchy example
Concept: "SI Unit of Length"
└── is-a: "SI Base Unit"
└── is-a: "Unit of Measure"
// Inheritance allows:
- Meter inherits properties from SI Base Unit
- Changes to parent propagate appropriately
- Queries can traverse hierarchiesConcept Composition (Has-Part)
Define part-whole relationships between concepts.
// Composition example
Concept: "Address"
├── has-part: "Street Address"
├── has-part: "City"
├── has-part: "Postal Code"
└── has-part: "Country"
// Composition enables:
- Complex concept construction
- Validation of component requirements
- Dependency trackingConcept Domains
Define constrained value sets that concepts can reference.
// Domain definition
Domain: "Unit Status"
Values: ["current", "deprecated", "historical"]
// Usage in concept
Concept: "Meter"
Status: constrained by "Unit Status" domain
// Domain benefits:
- Centralized value management
- Consistency across concepts
- Easy domain updatesCodeset Incorporation
Incorporate external code sets as concepts while maintaining linkage to the source.
// Codeset incorporation
Incorporated Codeset: "ISO 3166-1 Country Codes"
Source: https://iso.org/3166-1
Incorporation Date: 2025-01-15
// Each country code becomes a concept:
Concept: "United States Country Code"
Source: ISO 3166-1
Code: "US"
Incorporated: true
Local Extensions: allowedImplementation Checklist
Key implementation requirements for CCR:
1. Foundation
- ☐ Register specification published
- ☐ Identifier scheme designed for persistence
- ☐ Namespace strategy defined
- ☐ Versioning policy documented
2. Content Management
- ☐ Item CRUD operations implemented
- ☐ Status tracking (valid/invalid, published/unpublished)
- ☐ Version history maintained
- ☐ Supersession relationships tracked
3. Concept Modeling
- ☐ Concept definition and versioning
- ☐ Concept-item linking
- ☐ Inheritance relationships
- ☐ Composition relationships
- ☐ Domain definitions and enforcement
4. Governance
- ☐ Roles assigned (Owner, Manager, Control Body)
- ☐ Proposal workflow implemented
- ☐ Decision recording with rationale
- ☐ Appeal process defined
- ☐ Complete audit trail
5. Commitments
- ☐ Access commitments documented and implemented
- ☐ Persistence guarantees stated
- ☐ Succession plan (if applicable)
- ☐ Transparency mechanisms in place
6. Operations
- ☐ Public API or interface available
- ☐ Documentation for users
- ☐ Change notification mechanism
- ☐ Support channels defined
Performance Considerations
CCR's comprehensive capabilities have performance implications:
Concept Queries
- Hierarchy traversal: Inheritance queries may require multiple database lookups. Consider caching hierarchies.
- Composition resolution: Assembling composite concepts can be expensive. Pre-compute when possible.
- Version navigation: Concept version history can grow large. Implement pagination and archiving.
Governance Overhead
- Audit trails: Every action generates audit records. Plan storage accordingly.
- Proposal processing: Complex proposals may require significant review time. Set expectations.
Optimization Strategies
- Cache frequently accessed concept hierarchies
- Implement lazy loading for deep compositions
- Archive old versions to separate storage
- Use read replicas for query-heavy workloads
- Index frequently queried concept attributes
Migration to CCR
If you're upgrading an existing register to CCR, consider:
From Content Register
Add concept modeling + governance + commitments
- Create concept layer for existing items
- Establish governance processes
- Document and implement commitments
From Concept Register
Add governance + commitments
- Add governance layer around existing concepts
- Retroactively document existing changes
- Implement commitment guarantees
From Governed Register
Add concept modeling + commitments
- Add concept modeling to governed content
- Extend governance to cover concepts
- Implement full commitments
CCR Example: RUM
The Register of Units of Measure (RUM) is the canonical CCR example:
| Register Type | Complete Concept Register (CCR) |
|---|---|
| Content | SI units, derived units, prefixes, traditional units |
| Concept Features | Inheritance (is-a), composition, domains |
| Governance | ISO/TC 211 with formal proposal process |
| Commitments | Full access, persistence, and transparency |
See the complete RUM specification for details.