FERIN - Framework for Extensible Registration of Information

Why Semantic Technologies

Semantic web technologies provide a natural fit for FERIN implementation:

Open World Assumption

RDF allows data to exist without complete schema constraints. This aligns perfectly with FERIN's lazy migration model where data at different schema versions coexists.

Multiple Shapes

SHACL allows multiple shapes to apply to the same data. Each shape can represent a schema version, enabling version negotiation at the semantic layer.

Global Identifiers

URIs as identifiers are native to RDF. Every register item has a resolvable, globally unique identifier by design.

Linked Data

Cross-register references are natural in RDF. Link to concepts in external registers without copying or synchronizing.

RDF Mapping

Mapping FERIN concepts to RDF is straightforward. Here's the correspondence between FERIN entities and RDF patterns:

FERIN Entity	RDF Pattern
Register	`reg:Register` with properties for owner, manager, specification
Concept	`skos:Concept` with versions as separate resources
Concept Version	Named graph or reified statement with temporal properties
Register Item	Resource with `reg:status` and content properties
Status	`reg:status` property with values: `valid`, `invalid`, `superseded`
Relation	Typed properties: `reg:supersedes`, `skos:broader`, `dct:hasPart`
Change Record	`prov:Activity` with `prov:generatedAtTime`, `prov:wasAssociatedWith`

Example: Register Item in RDF

@prefix ex: <http://example.org/register/> .
@prefix reg: <http://purl.org/linked-data/registry#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# Register definition
ex:units-register a reg:Register ;
  reg:owner <http://example.org/org/bipm> ;
  dct:title "Register of Units of Measure" ;
  dct:description "SI and commonly used units" .

# Concept with multiple versions
ex:concept-meter a skos:Concept ;
  skos:prefLabel "meter"@en ;
  skos:notation "m" ;
  reg:register ex:units-register ;
  prov:generatedAtTime "1889-01-01T00:00:00Z"^^xsd:dateTime .

# Current version (in named graph for versioning)
ex:concept-meter {
  ex:concept-meter skos:definition
    "The distance travelled by light in vacuum in 1/299,792,458 second"@en ;
  dct:valid "1983-01-01T00:00:00Z"^^xsd:dateTime .
}

# Register item (realisation)
ex:item-meter a reg:RegisterItem ;
  reg:definition ex:concept-meter ;
  reg:status reg:statusValid ;
  reg:register ex:units-register ;
  dct:identifier "urn:iso:std:iso:80000:1:meter" ;
  prov:generatedAtTime "1960-10-14T00:00:00Z"^^xsd:dateTime .

SKOS for Concept Systems

SKOS (Simple Knowledge Organization System) is ideal for modeling FERIN concept systems. It provides standard properties for hierarchical and associative relationships.

SKOS Relationship Mapping

FERIN Relation	SKOS Property	Use Case
Generalization	`skos:broader` / `skos:narrower`	Unit → Length Unit → meter
Related	`skos:related`	meter ↔ foot (conversion)
Part-Whole	`dct:hasPart` / `dct:isPartOf`	Address → Street, City, PostalCode
Supersession	`reg:supersedes` / `reg:supersededBy`	new-meter ← old-meter

Example: Concept System in SKOS

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex: <http://example.org/units/> .

# Concept scheme (the vocabulary)
ex:units-scheme a skos:ConceptScheme ;
  skos:prefLabel "Units of Measure"@en ;
  dct:source <https://www.bipm.org/en/publications/si-brochure> .

# Top concept
ex:unit a skos:Concept ;
  skos:prefLabel "Unit"@en ;
  skos:topConceptOf ex:units-scheme .

# Hierarchical structure
ex:length-unit a skos:Concept ;
  skos:prefLabel "Length Unit"@en ;
  skos:broader ex:unit ;
  skos:narrower ex:meter, ex:foot, ex:inch .

ex:meter a skos:Concept ;
  skos:prefLabel "meter"@en ;
  skos:altLabel "metre"@en-GB ;
  skos:notation "m" ;
  skos:broader ex:length-unit ;
  skos:definition "The SI unit of length"@en ;
  skos:exactMatch <http://qudt.org/vocab/unit/M> .

# Related concepts
ex:foot a skos:Concept ;
  skos:prefLabel "foot"@en ;
  skos:notation "ft" ;
  skos:broader ex:length-unit ;
  skos:related ex:meter ;  # Can be converted
  skos:definition "Imperial unit of length equal to 0.3048 meters"@en .

SHACL for Schema Validation

SHACL (Shapes Constraint Language) provides the schema layer for RDF. Multiple shapes can coexist, making it perfect for FERIN's schema versioning model.

Schema Versioning with SHACL

Each schema version is a separate SHACL shape. Data can be validated against any version, and migration is lazy.

@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <http://example.org/shapes/> .
@prefix unit: <http://example.org/units/> .

# Shape Version 1 - Original schema
ex:UnitShape-v1 a sh:NodeShape ;
  sh:targetClass unit:Unit ;
  sh:property [
    sh:path unit:name ;
    sh:datatype xsd:string ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
  ] , [
    sh:path unit:symbol ;
    sh:datatype xsd:string ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
  ] , [
    sh:path unit:description ;
    sh:datatype xsd:string ;
    sh:minCount 0 ;
  ] ;
  sh:closed false .  # Allow additional properties

# Shape Version 2 - Adds category (required)
ex:UnitShape-v2 a sh:NodeShape ;
  sh:targetClass unit:Unit ;
  sh:property [
    sh:path unit:name ;
    sh:datatype xsd:string ;
    sh:minCount 1 ;
  ] , [
    sh:path unit:symbol ;
    sh:datatype xsd:string ;
    sh:minCount 1 ;
  ] , [
    sh:path unit:category ;  # NEW: Required in v2
    sh:datatype xsd:string ;
    sh:minCount 1 ;
    sh:in ("SI" "Imperial" "US Customary" "Other") ;
  ] ;
  sh:closed false .

# Data can validate against either shape
# (validation is opt-in, not enforced at storage time)
unit:meter a unit:Unit ;
  unit:name "meter" ;
  unit:symbol "m" ;
  unit:description "SI unit of length" ;
  unit:category "SI" .  # Present, so validates against v2

unit:old-unit a unit:Unit ;
  unit:name "legacy unit" ;
  unit:symbol "lu" .
  # No category - validates against v1 only

Validation Strategy

Unlike traditional databases, SHACL validation is typically performed on-demand, not at storage time. This enables lazy migration:

1. Store freely

Data is stored without enforcement of any particular shape

2. Query by shape

Consumers request data validated against specific shape version

3. Validate on demand

SHACL engine validates data against requested shape at query time

4. Migrate lazily

Data is updated to conform to new shapes only when needed

Linked Data and Cross-Register References

RDF enables natural cross-register references. Instead of copying or synchronizing, you link directly to external concepts.

# Local register item referencing external concept
@prefix ex: <http://example.org/my-register/> .
@prefix unit: <http://example.org/my-register/units/> .
@prefix qudt: <http://qudt.org/vocab/unit/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

# Your register item
ex:measurement-service a ex:Service ;
  ex:name "Measurement Service" ;
  ex:usesUnit qudt:M .  # Direct reference to QUDT vocabulary

# Your local unit that extends external definition
unit:local-meter a skos:Concept ;
  skos:exactMatch qudt:M ;  # Same as QUDT meter
  skos:prefLabel "meter (local)"@en ;
  ex:localCode "MTR-001" ;  # Local extension
  ex:internalUseOnly true .

Cross-Register Dependencies

Track dependencies: Know which external concepts you reference
Subscribe to changes: Monitor external register for relevant updates
Version your references: Note which version of external concept you referenced
Handle unavailability: Define fallback behavior when external register is down

Provenance with PROV-O

Use the PROV-O ontology to model change history and governance processes in RDF.

@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix ex: <http://example.org/> .

# A change activity (proposal approval)
ex:change-2024-001 a prov:Activity ;
  prov:type "approval" ;
  prov:startedAtTime "2024-03-15T10:00:00Z"^^xsd:dateTime ;
  prov:endedAtTime "2024-03-15T10:05:00Z"^^xsd:dateTime ;
  prov:wasAssociatedWith <mailto:control-body@example.org> ;
  prov:used ex:proposal-2024-042 ;  # The proposal being reviewed
  prov:generated ex:item-new-unit ;  # The new item created
  prov:wasInformedBy ex:proposal-2024-042 .

# The proposal
ex:proposal-2024-042 a prov:Entity ;
  prov:type "proposal" ;
  prov:wasAttributedTo <mailto:proposer@example.org> ;
  prov:generatedAtTime "2024-03-01T14:30:00Z"^^xsd:dateTime ;
  ex:justification "New unit required for industry standard" .

# The result
ex:item-new-unit a prov:Entity ;
  prov:wasGeneratedBy ex:change-2024-001 ;
  prov:wasDerivedFrom ex:proposal-2024-042 .

Semantic Interoperability