You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assume that the content identifier $\mathsf{body}(B) \in \mathcal{C}$ references a concrete RDF graph: $\mathsf{G}(B) \subseteq \mathcal{T}$ where $\mathcal{T}$ is the set of RDF triples of the form $(s, p, o)$.
We interpret $\mathsf{G}(B)$ as the payload graph authored by $\mathsf{issuer}(B)$.
Reification
We define a reification function $\mathsf{reify}(B)$ that maps the signed graph to a named graph or quads with provenance.
For each triple $t \in \mathsf{G}(B)$, define the reified form:
That is, the total RDF graph is the union of all reified block payloads visible under $u$'s trust and traversal policy.
If RDF-star is used, this could equivalently be:
$$
\mathsf{S}_u := \bigcup_{B \in \mathcal{V}_u} \left\{ \ll t \gg \ \mathsf{prov:wasAttributedTo} \ \mathsf{issuer}(B) \right\}
\quad \text{for each } t \in \mathsf{G}(B)
$$
Conflict handling
If blocks in $\mathcal{V}_u$ make conflicting assertions (e.g., two blocks claim different values for the same triple), this is not a protocol error — the provenance-aware model allows:
Leaving conflicting assertions coexisting with different graph names
Using downstream logic to resolve (e.g., trust-weighted resolution, query filtering)
Thus, state is:
Provenance-rich: all facts have authorship
Non-authoritative: clients determine what to trust or prioritize
Summary
Concept
Description
$\mathsf{G}(B)$
RDF graph payload of block $B$
$\mathsf{reify}(B)$
Provenance-aware named graph or RDF-star reification
$\mathsf{S}_u$
State for participant $u$: union of all reified payloads of visible blocks