https://w3id.org/jeswr/fedreg#⚠️ Experimental — AI-agent-generated (Claude Opus 4.8, @jeswr PSS agent); under active development, not production-hardened.
Other representations: Turtle · JSON-LD context · index
| Term | Label | Comment |
|---|---|---|
acceptsSpec | accepts spec | A client-client spec-VERSION IRI that this fedreg:StorageDescription's storage currently accepts writes against — a persistent, immutable version IRI from the Vocabulary/Spec Hub (e.g. a canonical model version). During a dual-read migration window a storage advertises BOTH the old and new version, so independent participants migrate asynchronously. An app MUST discover acceptable versions here, not assume them. The value MAY ALTERNATIVELY be a content-addressed SNAPSHOT HASH — the content address of a fedcon:Snapshot (https://jeswr.org/fedcon#Snapshot), e.g. a urn:concept: / multibase-multihash IRI — instead of a living version IRI (federation-on-hashes design §2.3). Pinning a snapshot hash advertises acceptance of one IMMUTABLE, byte-identical release rather than a mutable spec-version pointer, so 'which spec does this store accept' is answered by content address and verified by recompute-and-compare. This is purely additive: no rdfs:range is (or was) asserted on fedreg:acceptsSpec, so both the living-version-IRI and the snapshot-hash forms are valid values, distinguished by IRI scheme; the existing spec-version usage is unchanged. |
Active | Active | A current, ratified membership — the app is a recognised member of the federation and its self-asserted fedapp: footprint has been accepted. |
app | app | Links a fedreg:Membership to the app it concerns — the app's client_id IRI (the subject of the corresponding fedapp:App self-description). |
asserted | asserted | The timestamp (xsd:dateTime) at which the registry made this assertion — used to reason about staleness / ordering of status changes on a fedreg:RegistryAssertion (a fedreg:Membership or a fedcon:Admission). |
assertedBy | asserted by | The authority that asserts a fedreg:RegistryAssertion (a fedreg:Membership or a fedcon:Admission) — a WebID (or key IRI) of the Scheme Authority / registry operator vouching for it. This is what makes the record a REGISTRY claim rather than a self-asserted one: a verifier checks fedreg:assertedBy against the set of authorities it trusts. (The cryptographic signature binding the assertion to that authority is layered above this vocabulary.) |
member | member | Links a fedreg:Registry to one of its fedreg:Membership records. (A specialisation of dcat:record for the federation registry; a consumer may also reach the records via dcat:record.) |
Membership | Federation Membership | A registry's signed assertion (a fedreg:RegistryAssertion) that a particular app (its client_id, linked via fedreg:app) is a member of the federation, carrying a lifecycle fedreg:status, the fedreg:assertedBy authority (a WebID / key that vouches for it) and fedreg:asserted timestamp. This is the REGISTRY-ASSERTED counterpart to the app's self-asserted fedapp:App: a verifier treats a Membership as a membership claim only when it is asserted by a recognised authority — never the app's own fedapp: document. |
MembershipStatus | Membership Status | The lifecycle state of a fedreg:Membership. The four coded values fedreg:Proposed, fedreg:Active, fedreg:Suspended, fedreg:Revoked are instances of this class. Suspended/Revoked are the federation's recovery lever (brief 07 'recovery'): a misbehaving app is suspended or revoked at the registry without touching the app's own self-asserted document. |
Proposed | Proposed | A membership proposed but not yet ratified by the federation's Scheme Authority — the app appears in the registry pending review. |
Registry | Federation Registry | A federation registry: the catalogue of apps that a Scheme Authority has admitted to a data federation. A dcat:Catalog whose records are fedreg:Membership assertions (linked via fedreg:member). The subject is the registry's own IRI. Unlike a bag of self-asserted fedapp:App documents, a Registry's entries carry the registry's OWN membership assertion — so a consumer can trust the listing as a membership claim, not merely an app's self-description. |
RegistryAssertion | Registry Assertion | The common superclass of any record a registry authority SIGNS as its own claim — a dcat:CatalogRecord carrying the fedreg:assertedBy authority, the fedreg:asserted timestamp and (where a lifecycle applies) a status. It generalises the assertedBy / asserted / status spine that fedreg:Membership introduced, so OTHER registry-asserted record kinds can reuse it: a fedreg:Membership (an app's membership in a federation) and a fedcon:Admission (a concept hash admitted into a registry — https://jeswr.org/fedcon#) are both fedreg:RegistryAssertions. What makes any of them a REGISTRY claim, rather than a self-asserted one, is the fedreg:assertedBy authority a verifier checks against its trust set. (The cryptographic signature binding the assertion to that authority is layered above this vocabulary.) |
Revoked | Revoked | A membership permanently withdrawn — the app is no longer a member. A consumer MUST treat a revoked member as untrusted regardless of the app's own self-asserted fedapp: claims. |
status | status | The lifecycle status of a fedreg:RegistryAssertion — one of the fedreg:MembershipStatus coded values (Proposed / Active / Suspended / Revoked). Domained on fedreg:RegistryAssertion so any registry-asserted record MAY carry it; fedreg:Membership uses it for the membership lifecycle. (A fedcon:Admission carries its OWN fedcon:conceptStatus lifecycle instead of this membership-shaped status.) |
storage | storage | Links a fedreg:StorageDescription to the storage (resource server / pod root) it describes — typically the same IRI as the description's subject, but explicit when a registry collates many storage descriptions in one document. |
StorageDescription | Storage Description | A resource server's (storage's) federation catalogue entry: which client-client spec-VERSIONS it currently accepts (fedreg:acceptsSpec) and which data sectors it supports (fedreg:supportsSector). Realises the federation's 'decoupling' principle — each storage independently decides which specs it supports — and is the substrate for asynchronous schema migration: during a dual-read window the storage advertises both versions, so participants upgrade on their own clock. The subject is typically the storage root IRI. |
supportsSector | supports sector | A data sector IRI (a https://w3id.org/jeswr/sectors/<sector> marker) that this fedreg:StorageDescription's storage supports. Lets an app discover which storages can hold its sector's data before attempting a write. |
Suspended | Suspended | A membership temporarily withdrawn (e.g. pending investigation of a data-integrity issue). Reversible — distinct from fedreg:Revoked. The recovery lever for a misbehaving member. |