Statement Schema
The universal structure for all FCP assertions
FCP uses a Standardized Graph Structure — we break all data down into simple sentences called Statements. Universally, this follows the pattern: Subject → Predicate (Relationship) → Object.
Statement as an Entity
A Statement is a protocol Entity.
When a Statement Fide ID (did:fide:0x00...) is calculated, its rawIdentifier is derived from the Statement's contents (canonical JSON), then hashed by calculateFideId.
This simple structure, combined with strictly typed entities (see Entities), powers key patterns:
- Attributes: "Alice (Subject) → has name (Relationship) → Alice Smith (Value)"
- Relationships: "Alice → works for → Acme Corp"
- Actions: "Agent → performed → Action"
For specialized patterns involving protocol entities:
- Evaluations: "Entity → EvaluationMethod → Score"
- Signed Statements: "Statement → prov:wasGeneratedBy → Attestation"
The Statement Schema
Every piece of data in FCP starts as an unsigned assertion (a Statement). When signed, it becomes a Signed Statement (linked to an Attestation).
The Structure:
- Subject: Who or What is being described (e.g., "Alice").
- Predicate: The relationship (e.g., "works for").
- Object: The value or target (e.g., "Acme Corp").
Technical Schema: FideStatement
The FideStatement is the base unit. Each Fide ID is calculated using calculateFideId.
Statement Fide IDs (did:fide:0x00...) are derived from the Statement's canonical JSON form — see Statement.
Prop
Type
From Schema to Storage
This structure defines what a statement is. See Indexing - Core Architecture to understand how Statements are materialized and stored for querying.
Anatomy of a Statement
Subject
The Subject is always a valid Fide Entity. It can be:
- Active Entities (Person, Organization)
- Inactive Entities (Place, Product, CreativeWork)
- Protocol Entities (Statement, Attestation)
This recursiveness allows FCP to be powerful—you can make statements about other statements.
Predicate
The Predicate defines the relationship type. Must use 0x65 (CreativeWork+Product) or 0xe5 (EvaluationMethod+Product). FCP uses standard vocabularies (primarily Schema.org).
Shorthand in docs
Docs use shorthand (e.g. owl:sameAs, schema:name) for readability. The SDK expands these to full URLs before hashing via expandPredicateIdentifier. Stored statements use canonical full URLs.
| Pattern | Concept | Example Predicate |
|---|---|---|
| Attributes | Name | schema:name |
| Actions | Status | schema:actionStatus |
| Attributes | Type | schema:type |
Supported Vocabularies
While Schema.org is the default vocabulary for FCP, sophisticated World Models often require higher precision for identity, lineage, and concept mapping. FCP explicitly supports and encourages the following standard namespaces:
1. OWL (Web Ontology Language)
2. SKOS (Simple Knowledge Organization System)
3. PROV-O (Provenance Ontology)
4. W3C Security Vocabulary
Object
The Object completes the sentence and is always an Entity (a Fide ID).
In practice:
- For Relationships, the object is often a non-
CreativeWorkentity (e.g. a Person/Organization/Product). - For Attributes, the object is typically a
CreativeWorkentity whose raw identifier is the value itself (e.g."Alice Smith").
See Attributes for the recommended convention (predicate term + value are both CreativeWork entities).
Where is the Context?
We often need to say when something happened or how long it is true. In FCP, context is simply an Attribute of the statement itself.
Mistakes Happen: The Correction Pattern
To correct a statement, we don't delete it. Instead, we replace it using the prov:wasRevisionOf relationship.