https://jeswr.org/fedcon#⚠️ 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 |
|---|---|---|
Admission | Concept Admission | A registry authority's signed decision on a concept hash — the sibling of fedreg:Membership, and like it a fedreg:RegistryAssertion (so it reuses the fedreg:assertedBy authority and fedreg:asserted timestamp spine; RegistryAssertion is itself a dcat:CatalogRecord, inherited transitively). It carries the concept (fedcon:concept), the fedcon:conceptStatus lifecycle value, the fedcon:proposal it decides (full provenance: evidence + thread), the fedcon:reviewWindow (machine-checkable against the policy minimum), the governing fedcon:underPolicy, the MANDATORY dissent annex (fedcon:dissent / fedcon:noDissentRecorded) and a fedcon:decisionRationale. Admission is per-registry: the same hash may be Admitted in one registry and UnderReview in another, simultaneously — there is no global state, and rejection removes nothing (the hash still works locally and can be admitted elsewhere). |
AdmissionPolicy | Admission Policy | A registry's governance-as-data document: who the admission authorities are (WebIDs, checked against fedreg:assertedBy on admissions), the minimum comment window (the design default is 7 days, the Wikidata floor), the evidence expectation for promotions (e.g. '>=3 independent member attestations'), and the comment-write gate (open vs member-only). Every fedcon:Admission links its governing policy via fedcon:underPolicy, so a decision is auditable against the rules in force when it was made. Thresholds are registry POLICY, never protocol constants — different federations legitimately differ. |
Admitted | Admitted | The registry authority has admitted the concept hash. Admission adds discoverability, endorsement, codegen eligibility and migration coordination; it never adds permission to EXIST — an unadmitted concept was never broken. An Admitted status is what makes a concept eligible as a codegen publish-plane input. |
Announcement | Concept Announcement | A first-come-first-served, review-free notice that makes a concept DISCOVERABLE without seeking endorsement: { fedcon:concept <hash> ; fedcon:definition <ref> }, LDN-POSTed to any registry's inbox and indexed in a 'seen concepts' listing (schema.org-pending-like: visible, usable, explicitly UNENDORSED). It has no review path and no lifecycle status — auto-accepted subject only to the syntactic caps. This is what lets other agents FIND concepts to share an understanding of, before any governance happens; an announced concept is never 'admitted' by being announced. |
closed | closed | The instant (xsd:dateTime) a fedcon:ReviewWindow's comment window closed — the point from which the authority may decide. |
concept | concept | The content hash that IS the concept's identity — an opaque, content-addressed IRI (e.g. urn:concept:<multibase-hash>) from the content-addressed-concepts design. Used by fedcon:Proposal, by fedcon:UsageAttestation AND by fedcon:Announcement, so NO rdfs:domain is asserted (multiple rdfs:domain triples would be an RDFS conjunction, wrongly forcing a subject to be all three classes at once). NO rdfs:range either: the hash IRIs are opaque and external to this vocabulary — a consumer validates them by scheme + determinism (recompute-and-compare against the supplied definition), not by an RDFS range. |
conceptDereferenceTemplate | concept dereference template | The canonical hydra:IriTemplate for a fedcon:conceptStore's dereference route: GET <base>/i/{multibaseMultihash}, where the single required variable is the multibase-encoded multihash (the content address) of the urn:concept: record being fetched (federation-on-hashes design §2.2). A concept-store dcat:DataService advertises this via dcat:endpointDescription so the route is discoverable as Linked Data; the served record is verified by recompute-and-compare against that content address, so the transport is untrusted by construction. |
conceptStatus | concept status | The lifecycle status of the admitted concept hash — one of the fedcon:ConceptStatus coded values (Proposed / UnderReview / Admitted / Rejected / Superseded / Deprecated / Withdrawn). This is the concept's own state machine on a fedcon:Admission, distinct from the membership-shaped fedreg:status. |
ConceptStatus | Concept Status | The lifecycle state of a concept hash WITHIN one registry, on a fedcon:Admission. The seven coded values fedcon:Proposed, fedcon:UnderReview, fedcon:Admitted, fedcon:Rejected, fedcon:Superseded, fedcon:Deprecated and fedcon:Withdrawn are instances of this class. Distinct from fedreg:MembershipStatus (which is the membership lifecycle) — a concept admission has its own state machine (proposed → under-review → admitted / rejected, then superseded / deprecated). |
conceptStore | concept store | Links a fedreg:Registry (a dcat:Catalog) to its CONCEPT STORE — the dcat:DataService that SERVES the ownerless urn:concept: definition records the registry has admitted, at GET <base>/i/{multibase-multihash} (federation-on-hashes design §2.2). The store returns direct 200s only (no redirects — a client fetches redirect:manual and treats any redirect as a protocol failure), content-negotiated across text/turtle, application/ld+json and application/n-quads, immutably cacheable, and verifiable by recompute (a client hashes the served bytes and byte-compares, so a hostile mirror can only WITHHOLD, never alter). The linked dcat:DataService SHOULD advertise its dereference template as a dcat:endpointDescription pointing at a hydra:IriTemplate (the canonical one is fedcon:conceptDereferenceTemplate) so discovery is Linked-Data-native. A registry MAY list several concept stores (mirrors); a pod-hosted mirror needs zero server changes since a Solid pod already serves immutable resources with content negotiation. |
Concern | Concern | An assessing stance raising a concern short of outright opposition — a reservation the authority should weigh and, where unresolved, acknowledge in its rationale. |
context | context | The OPTIONAL context in which the user uses the concept — a sector or app IRI. NO rdfs:range is asserted (a sector marker or an app client_id are both valid, from other vocabularies); the value discloses only the using context, never the counterparties or content of exchanges. |
currentSnapshot | current snapshot | Links a fedreg:Registry to its CURRENT fedcon:Snapshot — the content-addressed release a client should adopt now (federation-on-hashes design §2.3). A registry advertises at most one current snapshot; a client follows fedcon:previousSnapshot back along the chain to verify the sequence it is offered is not a downgrade of, or a fork away from, one it has already seen. |
decisionRationale | decision rationale | The authority's reasoned (xsd:string) justification for a fedcon:Admission — it MUST respond to every unresolved Oppose in the thread. Consensus is never COMPUTED: the rationale is the accountable human/authority judgment, with the objections carried alongside it via fedcon:dissent. |
Define | Define | Intent: register a concept that has no prior standing in this registry. Expected to be rare in practice — the fast path (define, hash, serve, use, with zero registry involvement) makes local definition strictly easier — but supported so an agent that WANTS immediate review can have it. |
definition | definition | The concept's full definition — INLINE preferred (a graph node in the same document, which minimises by-reference SSRF surface), or a content-addressed URL that dereferences to bytes the receiver hash-verifies against fedcon:concept. Used by both fedcon:Proposal and fedcon:Announcement, so NO rdfs:domain is asserted; NO rdfs:range either (an inline graph node or a content-addressed URL are both valid values, distinguished at ingest, not by an RDFS range). |
Deprecated | Deprecated | The authority discourages the concept with NO successor (rare). A reasoned record, dissent-annexed like any decision. Distinct from Superseded (which names a successor via fedcon:supersededBy). |
dissent | dissent | The MANDATORY dissent annex of a fedcon:Admission: each unresolved Oppose stance from the proposal thread, carried as an oa:Annotation (the Web Annotation model is REUSED — no comment/annotation class is minted here). An admission whose thread contains unresolved Oppose stances but which records no fedcon:dissent is INVALID per the SHACL profile (unless it explicitly asserts fedcon:noDissentRecorded true) — the record format itself refuses manufactured consensus. A direct port of the unite fut:SharedFuture dissent annex into registry governance. |
evidence | evidence | On a Promote fedcon:Proposal: the usage attestations (fedcon:UsageAttestation), inline or by reference, that evidence cross-agent adoption — the forcing function for promotion. Presented to the authority and the public; never auto-scored into a verdict. |
Extend | Extend | Intent: register a NEW concept whose definition graph references parent hashes (subclass / subproperty / refinement edges via fedcon:extends). Extending never mutates a parent — hashes are immutable and concepts are ownerless, so no permission is ever needed to extend. The intent exists so a registry can INDEX the extension graph (who builds on what — itself promotion-relevant evidence for the parent), not to gate anything. |
extends | extends | On an Extend fedcon:Proposal: the parent concept hash(es) the new concept's definition builds on (subclass / subproperty / refinement edges). NO rdfs:range is asserted — the values are opaque content-addressed concept hashes, external to this vocabulary, exactly like fedcon:concept. Extending never mutates a parent (hashes are immutable) and never needs permission. |
intent | intent | The intent of a fedcon:Proposal — one of the fedcon:Intent coded values (Define / Extend / Promote). Selects the record's semantics on a single validation path. |
Intent | Proposal Intent | The intent of a fedcon:Proposal. The three coded values fedcon:Define, fedcon:Extend and fedcon:Promote are instances of this class. The intent selects the record's semantics without needing three endpoints: Define registers a concept with no prior standing, Extend indexes a new concept whose definition references parent hashes (it never mutates a parent — hashes are immutable), Promote seeks admission of an already-used hash into a wider registry. |
motivationText | motivation text | A free-text (xsd:string) explanation of why this concept and what gap it fills, on a fedcon:Proposal — read by the commenting public and the authority. |
noDissentRecorded | no dissent recorded | The EXPLICIT (xsd:boolean) assertion that a fedcon:Admission's review recorded no dissent to admit. Required (true) whenever an admission carries no fedcon:dissent — silence is never treated as consensus. Mirrors fut:noDissentRecorded from the unite futures sector, minted here so the mandatory-annex rule (>=1 fedcon:dissent OR fedcon:noDissentRecorded true) is structurally enforceable in SHACL. |
opened | opened | The instant (xsd:dateTime) a fedcon:ReviewWindow's comment window opened. |
Oppose | Oppose | An assessing stance opposing the proposal. It MUST carry a non-empty rationale body (an unsupported Oppose is rejected at POST and carries no weight). Every unresolved Oppose must be RESPONDED TO in the admission's fedcon:decisionRationale and listed in its mandatory dissent annex — objections travel with the outcome rather than being averaged away. |
previousSnapshot | previous snapshot | The prev-hash CHAIN link: the immediately-prior fedcon:Snapshot a non-genesis snapshot extends (federation-on-hashes design §2.3, CAC §11 downgrade protection). Because a Snapshot is content-addressed, this link IS the prior release's content hash, so the chain is tamper-evident: a client recomputes and byte-compares each hop. The genesis snapshot (fedcon:sequence 0) carries NO fedcon:previousSnapshot; every other snapshot carries exactly one. The value may be cross-resource (the prior snapshot lives in another document), so it is validated as a node reference, never by requiring the prior snapshot's type in the same graph. |
primeSet | prime set | The content-addressed PRIME-LEXICON SET of a fedcon:Snapshot — the opaque content-addressed resource pinning the release's prime lexicon (the primitive concept set the admitted concepts are expressed against). NO rdfs:range is asserted: the value is an opaque content-addressed IRI external to this vocabulary, like fedcon:concept / fedcon:profileBundle, verified by recompute-and-compare rather than by an RDFS range. |
priorAdmission | prior admission | On a Promote fedcon:Proposal: a fedcon:Admission in a narrower registry where the concept already stands, cited as evidence of existing endorsement. |
profileBundle | profile bundle | The content-addressed PROFILE-1 BUNDLE of a fedcon:Snapshot — the opaque content-addressed resource (e.g. a urn:concept:<hash> / a multibase multihash IRI) the codegen projector lowers into the release's shapes, labels and manifest. NO rdfs:range is asserted: the value is an opaque content-addressed IRI external to this vocabulary, exactly like fedcon:concept — a consumer validates it by recompute-and-compare, not by an RDFS range. |
Promote | Promote | Intent: seek admission of an already-used, byte-identical concept hash into a wider registry. Nothing is re-minted, re-namespaced or transferred — the concept definition does not change when it is promoted, which is precisely why apps that adopted it pre-promotion need no migration. Promotion changes only WHERE endorsement records exist; it carries the usage attestations (fedcon:evidence) and any prior standing (fedcon:priorAdmission) as the forcing-function evidence. |
proposal | proposal | Links a fedcon:Admission to the fedcon:Proposal it decides — the full provenance trail (the proposal's evidence and its comment thread). |
Proposal | Proposal | A contribution proposal filed against a registry (LDN-POSTed as RDF). One record type carries all three intents (fedcon:intent — Define / Extend / Promote) so there is a single validation path. It ALWAYS references the concept by its content hash (fedcon:concept), carries the definition graph (fedcon:definition, inline preferred), the proposer (prov:wasAttributedTo, which MUST match the DPoP-verified WebID), and — for a Promote — the usage attestations (fedcon:evidence) and prior standing (fedcon:priorAdmission). A proposal accretes mutable discussion state, so unlike the ownerless concept it gets a stable minted registry URL. |
Proposed | Proposed | A proposal has been filed but the registry has not yet opened the comment window (e.g. pending the synchronous syntactic + structural checks). |
Rejected | Rejected | The authority declined admission (reasoned, dissent-annexed). Rejection is per-registry and NON-terminal for the concept: the hash still exists, still works locally, can be re-proposed with new evidence, and can be admitted elsewhere. Rejection only withholds THIS registry's endorsement. |
reviewWindow | review window | The fedcon:ReviewWindow (opened / closed timestamps) of a fedcon:Admission — machine-checkable against the governing policy's minimum comment window. |
ReviewWindow | Review Window | The public-comment window of a fedcon:Admission: a small structured node carrying fedcon:opened and fedcon:closed timestamps. Its span is machine-checkable against the governing policy's minimum (the design default is 7 days) so a decision can be audited for having given the required comment time before the authority acted. |
sequence | sequence | The MONOTONIC generation counter (xsd:nonNegativeInteger) of a fedcon:Snapshot: the genesis release is fedcon:sequence 0 (and carries no fedcon:previousSnapshot); each successor increments it and links its predecessor. Together with the prev-hash chain it is the downgrade-protection substrate — a client that has adopted sequence k treats a snapshot offered as 'current' whose sequence is < k (or whose chain does not extend the one it holds) as a downgrade and rejects it. |
since | since | The date (xsd:date) from which the signing user has been using the attested concept. |
Snapshot | Snapshot | A content-addressed sector RELEASE — the atomic adoption unit of a federation's admitted concepts at one generation (federation-on-hashes design §2.3). It gathers, at sequence k: the admitted concept set (0..* fedcon:concept, the SAME opaque urn:concept: hashes the admission/proposal records carry — REUSED, not re-minted), the content-addressed profile-1 bundle (fedcon:profileBundle) the codegen projector lowers to shapes/labels, the prime-lexicon set (fedcon:primeSet), a monotonic generation counter (fedcon:sequence) and the prev-hash chain link to the prior release (fedcon:previousSnapshot). A Snapshot is ITSELF content-addressed — its own multihash is the value a fedreg:StorageDescription MAY pin via fedreg:acceptsSpec — so a client verifies it by recompute-and-compare, never by trusting a mutable pointer. A Snapshot is SIGNED: it is bound to a W3C Verifiable Credential per @jeswr/federation-trust (which composes solid-vc + federation-registry) — the credential's credentialSubject references the snapshot; that credential SHAPE is referenced here, never redefined (rdfs:seeAlso). Snapshots + the sequence/previous chain give downgrade protection: a client that has seen sequence k rejects an older or fork-of-a-different-previous snapshot offered as 'current'. |
stance | stance | The structured review stance an assessing comment carries — one of the fedcon:Stance coded values (Support / Oppose / Concern). It DECORATES a Web Annotation (rdfs:domain oa:Annotation, oa:motivatedBy oa:assessing); it does not replace the free-text body. An Oppose stance without a non-empty rationale body is rejected at POST (SHACL fcsh:OpposeStanceShape). |
Stance | Review Stance | A structured review stance a commenter attaches to an assessing Web Annotation via fedcon:stance. The three coded values fedcon:Support, fedcon:Oppose and fedcon:Concern are instances of this class. A stance rides on an oa:Annotation (oa:motivatedBy oa:assessing); it does not replace the free-text comment body. An Oppose stance MUST carry a non-empty rationale body (SHACL-checked / rejected at POST) — an unsupported Oppose carries no weight, so it is not accepted as a stance record. |
Superseded | Superseded | The registry admitted a successor hash and endorsed the upgrade edge; this admission is flipped to Superseded with fedcon:supersededBy pointing at the successor's admission, and the fedreg:acceptsSpec dual-read migration window takes over. A superseded concept keeps verifying and keeps working — supersession is a signpost, not a kill switch. |
supersededBy | superseded by | On a Superseded fedcon:Admission: the successor concept's fedcon:Admission (in the same registry) that the authority admitted and whose upgrade edge it endorsed. The governance half of supersession; the CLAIM half (fedcon:upgrades) is carried in the successor's own definition graph. |
Support | Support | An assessing stance endorsing the proposal. Numbers inform the authority's judgment; they never mechanically drive the transition. |
underPolicy | under policy | Links a fedcon:Admission to the fedcon:AdmissionPolicy it was made under, so the decision is auditable against the rules in force at the time. |
UnderReview | Under Review | The public comment window is open (minimum per the governing policy — the design default is 7 days). Anyone may comment; the authority weighs the thread and the executable structural-gate report before deciding. |
upgrades | upgrades | The AUTHOR's claim of succession, asserted WITHIN a successor concept's OWN (hash-covered) definition graph: the prior concept hash this one supersedes. NO rdfs:domain (it is asserted on an external, hash-identified concept resource, not on any class of THIS vocabulary) and NO rdfs:range (the value is an opaque content-addressed concept hash, like fedcon:concept). The claim alone moves nothing — a registry endorses it via fedcon:supersededBy on the prior admission. |
UsageAttestation | Usage Attestation | A single using agent's SIGNED statement that IT uses a concept: { fedcon:concept <hash> ; fedcon:user <WebID> ; fedcon:since <date> ; fedcon:context? <sector/app IRI> }. The promotion evidence, gathered by the users, never ABOUT them: nobody attests about anybody else — each peer that consents signs its OWN attestation, so consent to disclosure is by construction. An attestation names only its signer and the concept hash, never the counterparties or content of exchanges. Presented to the authority and the public as evidence; never auto-scored into a verdict. |
user | user | The USING agent that signs a fedcon:UsageAttestation — a WebID. NO rdfs:range is asserted (a WebID is any IRI naming an agent, from any WebID vocabulary; pinning an RDFS range here would wrongly constrain it). The attestation names only its signer and the concept hash — never the counterparties of any exchange. |
Withdrawn | Withdrawn | The proposer withdrew the proposal before a decision — the one proposer-privileged lifecycle act (an authenticated POST referencing the proposal). No endorsement was ever granted or refused. |