Technology Implementation Guide
FERIN is technology-neutral. ISO 19135 deliberately does not prescribe implementation technology. This guide explains what capabilities matter for compliance, and the gap between basic database technology and a FERIN-compliant register.
The Two-Plane Model and Technology
FERIN's two-plane model separates concerns that technology must support:
Concept Plane
The semantic layer where concepts evolve and relate to each other.
Concepts
Abstract ideas that can exist in any concept system (a graph of concepts)
Concept Versions
Specific realizations of concepts at points in time
Concept Relationships
Connections between concepts (generalization, part-whole, etc.)
Concept Version Relationships
Connections between versions (supersedes, has-part, etc.)
Content Plane
The data layer where concepts are realized as instances.
Register Item Classes
Data schemas defining the structure of register items
Register Items
Data instances - the actual content of the register
Changes
Records of all modifications to register content
Key Relationship
Each concept version is backed by a register item (data instance) in a particular register item class (data schema). This separation enables:
- Concepts to evolve without breaking existing data
- Multiple register item classes for different representations
- Schema evolution independent of concept evolution
The Implementation Gap
There is a significant gap between basic database technology and a FERIN-compliant register. A database provides storage and query capabilities, but FERIN requires:
Database Layer
- CRUD operations
- Query language
- Transaction support
- Indexing
FERIN Layer
- Two-plane model (concept + content)
- Identifier schemes (object + functional)
- Status management (validity, publication, etc.)
- Action semantics (add, invalidate, supersede, etc.)
- Complete change history
- Governance processes
- Commitment fulfillment
This is why implementing FERIN requires more than choosing a database. You need a register system that implements FERIN semantics on top of whatever storage technology you choose.
Capabilities Required for Compliance
Technology choice doesn't determine FERIN compliance. These capabilities do:
Persistent Identifiers
Both object identifiers (non-redirectable) and functional identifiers (redirectable, hierarchical) must be supported. See Identifier Design.
Status Tracking
Must store and query validity (valid/invalid), publication (published/unpublished/draft), and other status dimensions. See Statuses.
Change History
Every change recorded with timestamp, actor, rationale. Must support point-in-time reconstruction. See Temporal Data.
Action Semantics
Must implement FERIN actions: add, add-version, invalidate, supersede, retire, etc. Each action has specific semantics. See Actions Reference.
Relation Support
Must support concept relations, concept version relations, and content relations. See Relations.
Schema Evolution
Register item classes (schemas) must evolve independently of register items (instances). See Schema Evolution.
Temporal Queries
Must answer "what was true at time T?" for any point in the register's history. See Temporal Data.
Commitment Fulfillment
Must meet stated access, persistence, and transparency promises. See Commitments.
FERIN Concept Mapping
When evaluating technology, consider how it maps to FERIN concepts:
| FERIN Concept | What to Evaluate |
|---|---|
| Concept | How will you represent abstract ideas that evolve over time? Can you track concept relationships (generalization, part-whole)? |
| Concept Version | How will you represent specific realizations at points in time? Can you track version relationships (supersedes, has-part)? |
| Register Item Class | How will you define and version data schemas? Can schemas evolve independently of instances? |
| Register Item | How will you store data instances? Can items be linked to concept versions? |
| Relations | Can you represent typed relationships with temporal constraints? Can you traverse relationships efficiently? |
| Change Records | Can you capture complete change history with all required metadata? Can you replay history for point-in-time reconstruction? |
Known FERIN Implementations
Two register systems are known to implement FERIN concepts:
Paneron
Developed by Ribose
A structured data management platform designed for standards organizations and registries. Implements FERIN concepts including the two-plane model, versioning, and governance workflows.
R3gistry
European Commission INSPIRE
The reference registry for the INSPIRE Directive, managing code lists, registers, and spatial data themes. Implements ISO 19135 register concepts for European spatial data infrastructure.
These implementations demonstrate that FERIN compliance is achievable with different technology stacks, provided the fundamental capabilities are implemented correctly.
Build vs Buy
When deciding whether to build a custom register or adopt an existing solution, consider:
Build Custom If...
- You have specific integration requirements
- Your governance model is unique
- You need full control over the technology stack
- You have resources for long-term maintenance
Adopt Existing If...
- Your needs match existing solutions
- You want faster time to deployment
- You prefer supported software
- Your governance model is standard
Important Consideration
Building a FERIN-compliant register requires significant effort to implement all required capabilities correctly. The gap between basic database operations and FERIN semantics should not be underestimated.
What ISO 19135 Does Not Require
ISO 19135 is deliberately technology-neutral. It does not require:
- Any specific database technology (SQL, NoSQL, graph, etc.)
- Any specific query language (SQL, SPARQL, Cypher, etc.)
- Any specific API style (REST, GraphQL, gRPC, etc.)
- Any specific serialization format (JSON, XML, RDF, etc.)
- Any specific hosting model (cloud, on-premise, hybrid)
These are implementation choices that should be made based on your specific requirements, existing infrastructure, and team expertise.