Identifier Design
Identifiers must be unique and persistent. The standard leaves the scheme design to implementers—here's practical guidance.
ISO 19135 Requirements for Identifiers
ISO 19135:2026 requires that every concept, concept version, register item, register item class, and change must have both types of identifiers:
Object Identifier
Non-Redirectable
An identifier that is permanently assigned to a specific object. The association never changes—once an object identifier points to an object, it always points to that same object.
Characteristics:
- Non-redirectable (cannot point to a different object)
- Permanent (does not change over time)
- Only concerned with uniqueness, not meaning
- Assigned at creation
550e8400-e29b-41d4-a716-446655440000 (UUID)This UUID will forever identify this specific concept version.
Functional Identifier
Redirectable
An identifier that reflects semantic intent and can be redirected to point to different objects over time while maintaining the original meaning of the identifier.
Characteristics:
- Redirectable (can point to different objects over time)
- Persistent in semantics (meaning persists even if target changes)
- MUST support hierarchical specification
- Enables semantic addressing
/concepts/crs/wgs-84/currentThis functional identifier means "the current version of WGS 84 CRS". As new versions are created, this identifier redirects to the latest.
Why Both Are Required
Object Identifiers
Provide permanent reference for citations and history
Functional Identifiers
Provide semantic access for current usage
Together
Enable both stability and flexibility
Hierarchical Identifier Requirement
ISO 19135:2026 requires that functional identifiers must support hierarchical specification. This means the identifier scheme must allow representation of multiple components.
What Hierarchy Means
A hierarchical identifier can represent:
- The nature of the identified item
- Parameters such as version
- Parent/child relationships
Example Hierarchical Schemes
URI
https://example.org/register/concepts/meter/v2.0URN
urn:example:register:meter:2.0What Needs Both Types of Identifiers
| Entity | Object Identifier | Functional Identifier |
|---|---|---|
| The Register itself | — | Required |
| Concepts | Required | Required |
| Concept Versions | Required | Required |
| Register Item Classes | Required | Required |
| Register Items | Required | Required |
| Changes | Required | Required |
What Makes a Good Identifier?
FERIN requires identifiers to be:
- Unique: No two items share the same identifier
- Persistent: The identifier remains valid indefinitely
- Consistent: Assigned using documented rules
The Persistence Challenge
"Persistent" is harder than it seems. An identifier is only as persistent as:
- The organization that maintains it
- The infrastructure that resolves it
- The policies governing its use
Identifier Schemes Compared
| Scheme | Pros | Cons | Best For |
|---|---|---|---|
| UUID |
|
| Object identifiers |
| URN |
|
| Functional identifiers, long-term references |
| URL/URI |
|
| Functional identifiers, web-accessible registers |
| DOI |
|
| Academic, published content |
| Custom |
|
| Organization-specific registers |
Namespace Design
Namespaces prevent identifier collisions across registers:
Namespace Patterns
Hierarchical
org.example.register.itemOrganized by ownership/domain
Date-Based
2024.item.001Organized by time of creation
Type-Based
country.US, currency.USDOrganized by content type
Best Practices
- Include organization identifier in namespace
- Document namespace rules clearly
- Plan for future registers in same namespace
- Avoid characters that cause problems in URLs
Persistence Strategies
How do you ensure identifiers remain valid over time?
Technical Strategies
- Use stable domains: Register a dedicated domain for your identifiers, separate from your main website
- Implement redirects: If infrastructure changes, maintain redirects from old URLs
- Use resolution services: DOI, URN resolvers, or handle systems provide persistence infrastructure
- Document fallbacks: If primary resolution fails, where can users look up the identifier?
Organizational Strategies
- Identifier policy: Document the commitment to persistence in your register specification
- Succession planning: What happens if your organization dissolves?
- Escrow arrangements: For critical registers, consider third-party escrow of identifier mappings
Identifier Anti-Patterns
Semantic Identifiers
/users/john-smith - What happens when John Smith changes his name?
Better: /users/12345 with name as attribute
Database IDs
row-42 - Tied to specific database implementation
Better: Generate identifiers independently of storage
URLs That Change
https://app-v1.example.com/item/123 - What about v2?
Better: https://data.example.org/item/123
Reusing Identifiers
Reusing US when United States is deleted and later someone wants it for "Uruguay"
Better: Never reuse identifiers, mark as retired
Example Identifier Policies
Simple Policy (Internal Register)
Format: UUID
Generation: Automatic on creation
Resolution: API lookup only
Persistence: Guaranteed for register lifetime
Reuse: NeverComprehensive Policy (Public Register)
Object ID Format: urn:{org}:{register}:{uuid}
Functional ID Format: {register}:{semantic-code}
Generation: Object automatic, Functional manual
Resolution: HTTP redirect to current content
Persistence: Guaranteed indefinitely
Succession: Escrow with [designated organization]
Reuse: Never; retired codes marked unavailable