Advanced Concept Management

Concept Plane Overview

FERIN's concept plane separates meaning from representation. Concepts define what things mean, while register items represent concrete instances with specific content.

┌─────────────────────────────────────────────────────────┐
│                     Concept Plane                        │
│                                                          │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐         │
│   │ Concept  │───▶│ Concept  │───▶│ Concept  │         │
│   │ Version 1│    │ Version 2│    │ Version 3│         │
│   └──────────┘    └──────────┘    └──────────┘         │
│         │              │              │                 │
│         ▼              ▼              ▼                 │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐         │
│   │  Item    │    │  Item    │    │  Item    │         │
│   │ Version 1│    │ Version 2│    │ Version 3│         │
│   └──────────┘    └──────────┘    └──────────┘         │
│                                                          │
└─────────────────────────────────────────────────────────┘

This separation enables:

• Definitions to evolve without changing item identifiers
• Items to be linked to stable concepts
• Concept relationships independent of item content
• Richer semantic modeling than simple key-value pairs

Concept Definition Lifecycle

Concepts have their own lifecycle, parallel to but distinct from register items.

Creating Concepts

// Concept definition
{
  "conceptId": "urn:example:concept:meter",
  "currentDefinition": "The metre is the length of the path travelled by light in vacuum during a time interval of 1/299 792 458 of a second.",
  "versions": [
    {
      "version": 1,
      "definition": "The metre is the length equal to 1,650,763.73 wavelengths...",
      "date": "1960-10-14",
      "changeReason": "Initial definition based on krypton-86"
    },
    {
      "version": 2,
      "definition": "The metre is the length of the path travelled by light...",
      "date": "1983-10-20",
      "changeReason": "Refined definition based on speed of light"
    }
  ]
}

When to Version Concepts

Create a new concept version when:

• The definition changes in a way that affects meaning
• Clarifications significantly alter interpretation
• Scientific understanding evolves
• Regulatory requirements change the definition

Concept Inheritance (Is-A)

Inheritance defines "is-a" relationships where a concept specializes its parent.

Inheritance Semantics

// Inheritance hierarchy
SI Base Unit
  └── is-a ──▶ Unit of Measure

Length Unit
  ├── is-a ──▶ SI Base Unit
  └── is-a ──▶ Unit of Measure

Meter
  └── is-a ──▶ Length Unit

// What this means:
// - Meter IS A Length Unit
// - Length Unit IS A Unit of Measure
// - Properties flow down the hierarchy
// - Queries can traverse up or down

Implementation Considerations

• Single vs Multiple Inheritance: FERIN supports multiple inheritance (a concept can have multiple parents)
• Depth: Limit hierarchy depth for performance (recommend max 5-7 levels)
• Cycles: Detect and prevent circular inheritance
• Versioning: Inheritance relationships can change over time; track when relationships were added/removed

Querying Hierarchies

GET /api/v1/concepts/{id}/descendants

GET /api/v1/concepts/{id}/ancestors

GET /api/v1/concepts/{id}/siblings

Concept Composition (Has-Part)

Composition defines "has-part" relationships for complex concepts.

Composition Semantics

// Composition structure
Address
  ├── has-part ──▶ Street Address (required, 1)
  ├── has-part ──▶ City (required, 1)
  ├── has-part ──▶ State (optional, 0..1)
  ├── has-part ──▶ Postal Code (required, 1)
  └── has-part ──▶ Country (required, 1)

// What this means:
// - An Address IS COMPOSED OF these parts
// - Parts have cardinality (required/optional, min/max)
// - Parts can themselves be composed of parts

Cardinality

Specify how many of each part are allowed:

Composition Validation

Use composition definitions to validate data:

• Check that all required parts are present
• Verify part count is within cardinality bounds
• Validate part types match composition definition
• Navigate composition for queries and display

Concept Domains

Domains define constrained value sets that concepts can reference.

Domain Definition

// Define a domain
{
  "domainId": "unit-status",
  "name": "Unit Status",
  "description": "Valid status values for units of measure",
  "values": [
    { "code": "current", "definition": "Currently valid for use" },
    { "code": "deprecated", "definition": "No longer recommended" },
    { "code": "historical", "definition": "Of historical interest only" }
  ],
  "governance": {
    "changePolicy": "Changes require Control Body approval"
  }
}

Using Domains in Concepts

// Concept referencing a domain
{
  "conceptId": "meter",
  "definition": "...",
  "attributes": {
    "status": {
      "type": "domain",
      "domain": "unit-status",
      "value": "current"
    },
    "quantity": {
      "type": "domain",
      "domain": "physical-quantities",
      "value": "length"
    }
  }
}

Domain Benefits

• Centralized management: Change values in one place
• Validation: Ensure concepts use only valid values
• Consistency: Same value set used across concepts
• Governance: Control domain changes independently

Extensible Domains

Some domains allow local extensions:

// Base domain
Country Codes (ISO 3166-1)
  - US, GB, FR, DE, ...

// Extended domain (local additions)
Country Codes (Extended)
  - extends: Country Codes (ISO 3166-1)
  - additions:
    - XX (Unknown)
    - ZZ (Not Applicable)

Codeset Incorporation

Incorporate external code sets as concepts while maintaining linkage to source authority.

Incorporation Process

1. Identify source codeset and licensing terms
2. Define incorporation scope (full, partial, with extensions)
3. Create concepts for each code
4. Link concepts to source codeset
5. Define synchronization strategy

Incorporation Metadata

// Incorporated codeset reference
{
  "codesetId": "iso-3166-1",
  "source": {
    "name": "ISO 3166-1",
    "url": "https://www.iso.org/iso-3166-country-codes.html",
    "version": "2024-01",
    "license": "ISO copyright, requires license"
  },
  "incorporationDate": "2024-03-15",
  "scope": "alpha-2 codes only",
  "extensions": [
    { "code": "XX", "reason": "Internal: Unknown country" }
  ],
  "syncStrategy": "manual review on update"
}

Incorporated Concept Example

{
  "conceptId": "country-US",
  "source": {
    "codeset": "iso-3166-1",
    "code": "US",
    "officialName": "United States of America"
  },
  "localDefinition": "United States of America including territories",
  "extensions": {
    "region": "North America"
  },
  "incorporated": true,
  "lastSync": "2024-03-15"
}

Synchronization Strategies

Concept Relationships Summary

Implementation Checklist

Related Topics

• CCR Deep Dive - Complete Concept Register implementation
• Register Types - Concept Register and Governed Concept Register
• Conceptual Model - Formal model definition
• Versioning - Managing versions in registers