Data Model Migration

Migrating identifiers, versions, relations, and change tracking to the FERIN framework.

Identifier Migration

The 2026 edition introduces two types of identifiers while maintaining backward compatibility with existing identifier patterns.

Object Identifier

Required

A non-redirectable identifier permanently assigned to a specific object. This is what your existing identifiers become.

  • Never changes once assigned
  • Directly maps to your current identifiers
  • Example: urn:ogc:def:crs:EPSG::4326

Functional Identifier

Optional

A redirectable identifier that always reflects the original intent. Useful for stable external references.

  • Can be redirected to different targets
  • Enables semantic stability across changes
  • Example: /crs/wgs84 → redirects to current version

Migration Strategy

  1. Preserve existing identifiers as object identifiers

    Your current identifier scheme works as-is for object identifiers.

  2. Evaluate functional identifier need

    Consider adding functional identifiers if you need stable external references that survive content changes.

  3. Update documentation

    Document your identifier scheme clearly in the register specification.

Version Model Migration

The 2026 edition requires minimum two-layer versioning (major/minor). Your existing version model may need adaptation.

2015 Version Model

versionCharacterString0..1
dateOfLastChangeDate0..1

2026 Version Model

majorVersionCharacterString1
minorVersionCharacterString0..1
patchVersionCharacterString0..1
dateOfLastChangeDateTime1

Migration Strategies

Semantic Versioning

1.2.3

Use major.minor.patch for fine-grained version tracking.

Date-Based Versioning

2026.02.15

Use year.month for temporal version identification.

Sequential Versioning

1.0 → 2.0

Simple sequential major versions with optional minor.

Version Migration Steps

  1. Parse existing version strings to determine structure
  2. Define mapping rules (e.g., "v1" → major=1, minor=null)
  3. Apply mapping consistently across all items
  4. Ensure dateOfLastChange is populated for all items

Relations Migration

The 2026 edition significantly expands the relations model. Your existing predecessor/successor relationships map to the new model.

2015 Relation2026 RelationTypeNotes
predecessorsupersedesConcept version → Concept versionCurrent item supersedes the predecessor
successorsuperseded byConcept version → Concept versionCurrent item is superseded by the successor
newinheritsConcept → ConceptProperty inheritance between concepts
newhas partConcept → ConceptPartitive relationship
newhas versionConcept → Concept versionLinks concept to its versions

Relation Migration Checklist

  • ☐ Inventory all existing predecessor/successor links
  • ☐ Map to supersedes/superseded-by relations
  • ☐ Evaluate need for new relation types (inheritance, partitive)
  • ☐ Update relation storage schema
  • ☐ Test relation queries work correctly

Change Tracking Migration

The 2026 edition formalizes change tracking with explicit Change objects. Your existing change history can be migrated to this model.

2026 Change Object

{
  "changeId": "chg-001",
  "changeType": "substantive",
  "dateTime": "2025-01-15T10:30:00Z",
  "description": "Updated definition to clarify scope",
  "affectedItems": ["EPSG:4326"],
  "proposal": {
    "proposalId": "prop-2024-42",
    "proposer": "OGC"
  }
}

Change History Migration

If your 2015 system tracked changes (from Extended conformance):

  1. Extract all change records with timestamps
  2. Create Change objects linking to affected items
  3. Link changes to proposals if available
  4. Preserve chronological ordering

If you didn't track changes formally:

  1. Create a single "migration" change record
  2. Document that pre-migration history is not available
  3. Begin tracking changes going forward