Querying

Querying is the Read Path of the Fide Context Protocol. This page covers how applications retrieve, resolve, and score graph data.

Because FCP is distributed, querying is not just SELECT *. It follows a three-step flow:

1. Retrieve & Resolve: Fetching statements and merging multiple IDs into one entity.
2. Consensus: Aggregating trust signals to decide what is "true".
3. Traverse: Following relationships to discover connected context.

1. Retrieve & Resolve

In FCP, an entity resolves to one Primary Fide ID under a chosen trust policy, while multiple external identifiers are linked as aliases through Alias Clustering (owl:sameAs).

Primary + Aliases Pattern

To make sense of the chaos, FCP relies on two concepts:

1. Primary Fide ID: A stable, protocol-native identifier (e.g. did:fide:0x10...) derived from a Genesis Statement.
2. Aliases: Other IDs (LinkedIn, X) linked via owl:sameAs.

2. Consensus (Scoring Trust)

Once you have the data, how do you know what is true?

FCP uses a Subjective Trust Model. The protocol provides the votes (Evaluations); YOU decide the count.

The Ground Truth Formula

Ground Truth = Σ (Evaluator Verdict × Evaluator Weight)

Weighting Strategies

Evaluator weights are application-side logic. You choose who to trust:

3. API Patterns

FCP supports standard patterns for accessing the resolved graph.

JSON-LD Response

All responses use JSON-LD with standard vocabulary prefixes (schema:, prov:, owl:, sec:) to ensure interoperability.

{
  "@id": "did:fide:0x10...",
  "schema:name": "Alice Johnson"
}

Next Steps

• Evaluating — Learn how to create the trust signals used in Consensus.
• Schema — Deep dive into the data patterns (Attributes vs Relationships).