FERIN - Framework for Extensible Registration of Information

Critical Migration Area

Status migration is often the most complex part of migrating to 2026. The fundamental model has changed from a single value to multiple independent dimensions. Plan this migration carefully.

Understanding the Change

2015: Single Status

Each register item had exactly one status from a fixed enumeration:

submittedIn review, not yet accepted

validAccepted and recommended

invalidContains substantial error

retiredNo longer recommended

supersededReplaced by newer item

2026: Status Dimensions

Status is now composed of independent dimensions that can be combined:

Validity

valid | invalidIs the content suitable for use?

Publication

published | unpublishedIs the content visible?

Redaction

redacted | not redactedHas content been hidden?

Deletion

deleted | not deletedHas content been removed?

Migration Mapping Table

Use this table to map your existing statuses to the new dimension model:

2015 Status	Validity	Publication	Redaction	Supersession	Notes
submitted	No direct mapping — proposals are separate from register items in 2026
valid	`valid`	`published`	`not redacted`	none	Standard active state
invalid	`invalid`	`published` or `unpublished`	`not redacted`	none	Publication depends on whether errors should be visible
retired	`valid`	`unpublished`	`not redacted`	none	Still valid, just hidden
superseded	`valid`	`published`	`not redacted`	link to successor	Still accessible for historical reference

Handling "submitted" Status

The 2015 submitted status has no equivalent in 2026 because proposals and register items are now separate concepts.

Migration Strategy

Items in "submitted" state

These are proposals under review. Options:

Complete the review process first in your 2015 system, then migrate only decided items
Convert to proposals in your 2026 system and process them through the new proposal workflow
Archive and handle separately from the main migration

Recommended Approach

Before migration, complete or withdraw all pending submissions. Migrate only items with final statuses (valid, invalid, retired, superseded). This simplifies migration and ensures data integrity.

New Combinations Possible

The dimension model enables status combinations that weren't possible in 2015:

Superseded + Invalid

valid: invalidpublication: publishedsuperseded: yes

An item was replaced AND the replacement was found to have errors.

Invalid + Unpublished

valid: invalidpublication: unpublished

Invalid content that should also be hidden from users.

Valid + Redacted

valid: validpublication: publishedredacted: yes

Valid content with some sensitive parts hidden (e.g., legal reasons).

Superseded + Retired

valid: validpublication: unpublishedsuperseded: yes

Replaced AND hidden from normal view.

Implementation Example

Here's how to implement the status dimension transformation:

Conceptual Mapping

// 2015 structure
{
  "itemIdentifier": "EPSG:4326",
  "status": "valid"
}

// 2026 structure (migrated)
{
  "itemIdentifier": "EPSG:4326",
  "status": {
    "validity": "valid",
    "publication": "published",
    "redaction": "not redacted",
    "deletion": "not deleted"
  },
  "supersession": null
}

Superseded Item

// 2015 structure
{
  "itemIdentifier": "EPSG:4322",
  "status": "superseded",
  "successor": "EPSG:4326"
}

// 2026 structure (migrated)
{
  "itemIdentifier": "EPSG:4322",
  "status": {
    "validity": "valid",
    "publication": "published",
    "redaction": "not redacted",
    "deletion": "not deleted"
  },
  "supersession": {
    "supersededBy": ["EPSG:4326"],
    "dateSuperseded": "2024-01-15"
  }
}

Migration Checklist

Inventory current statuses
Count items in each status category to understand scope
Handle "submitted" items
Complete, convert to proposals, or archive pending submissions
Design dimension schema
Define how status dimensions will be stored in your system
Create migration script
Implement the mapping logic with validation
Test with sample data
Verify all status combinations migrate correctly
Update UI components
Modify displays to work with dimension model
Update API responses
Ensure API consumers receive correct status information
Run full migration
Execute migration with rollback capability
Verify counts match
Confirm all items migrated with correct status

Common Pitfalls

Assuming retired = invalid

Wrong: Mapping retired items to validity=invalid

Correct: Retired items are still valid, just unpublished. They're not recommended for new use but aren't erroneous.

Forgetting supersession is now a relation

Wrong: Trying to encode supersession in status dimensions

Correct: Supersession is a separate relation between items, not a status dimension.

Not planning for new combinations

Wrong: Designing only for 2015-equivalent combinations

Correct: Your implementation should support all valid combinations, even if you don't use them initially.