This document is a draft (v0.4) and has not yet been finalized. Feedback and contributions from the community are welcome. Please refer to the latest version of this document for the most up-to-date information.
Feedback and comments on this specification are welcomed at any time. However, readers should note that the comment period for this specific version of the document has concluded, and the Working Group will not be making substantive modifications to this version of the specification at this stage.
Any issues or concerns can be reported directly on GitHub, for more information visit fact.claims.
The Working Group has received valuable implementation feedback, demonstrating that there are at least two implementations for each normative feature outlined in the specification.
To delve into further details, please consult the code, test suite and use case reports.
In a decentralized, AI-first environment, maintaining trustworthy and immutable data is essential for ensuring transparency, auditability, and reliability.
This paper proposes a methodology for leveraging the InterPlanetary File System (IPFS), Linked Data (JSON-LD), and Smart Contracts to construct a trusted decentralized network of fact webs.
By utilizing the distributed, immutable, and censorship-resistant IPFS, we address the challenges associated with decentralized trust and enhance the integrity and auditability of diverse fact claims.
We outline the technical architecture, design considerations, and implementation strategies for integrating IPFS into existing systems to establish a reliable and tamper-resistant repository for storing and accessing fact claims.
Given rapidly evolving artificial intelligence (AI), the need for trustworthy and immutable data has become paramount.
Decentralized ecosystems, built upon principles of transparency, auditability, and reliability, require robust mechanisms for managing and verifying information exchange. In this context, the establishment of fact claims - assertions of truth or validity regarding specific entities, relationships, or events - plays a crucial role in facilitating trustful collaboration across autonomous decentralized ecosystems.
It encompasses a wide range of activities, from asserting research findings and coordinating project activities to managing legal contracts and tracking supply chain transactions.
However, ensuring transparency, accountability, and interoperability within such a trustful ecosystem requires a standardized approach for representing facts - a knowledge graph.
The fact claims ecosystem serves as the backbone for managing trusted collaborations and value exchange in diverse domains, including research, innovation, curation, collaboration, and creativity.
graph TB;
Organization["schema:Organization"] -->|schema:offers| Services["schema:Service"]
Organization2 -->|my:supplier| Organization["schema:Organization"]
Products["schema:Product"] -->|schema:hasPart| Outcomes["my:Outcomes"]
Services -->|schema:hasPart| Outcomes
Products -->|my:supplier| SupplyChain["schema:Product"]
Services -->|my:provider| Organization2
Organization -->|my:partners| Organization2["schema:Organization"]
By adopting standard ontologies such as PROV-O, SKOS, and VOID, we enhance interoperability and facilitate knowledge organization within the ecosystem.
Facts from multiple sources can be crawled, combined and curated into a custom fact web, rich in contextual understanding for each use case.
graph TD;
Account["fib-sec:Account"] -- owns --> Customer["fib-crm:Customer"];
Account -- holds --> Asset["fib-sec:FinancialAsset"];
Account -- has --> Balance["fib:Balance"];
Account -- refersTo --> Currency["fib-fbc:Currency"];
Account -- relatedTo --> Institution["fib-crm:Institution"];
PartyA["fib-crm:LegalEntity"] -- initiates --> Transaction["fib-tran:Transaction"];
PartyB["fib-crm:LegalEntity"] -- receives --> Transaction;
Transaction -- involves --> Contract["fib-tran:Contract"];
Contract -- specifies --> Terms["fib-tran:ContractTerms"];
Transaction -- has --> Amount["fib-tran:MonetaryAmount"];
Transaction -- has --> Date["fib-tran:Date"];
Transaction -- has --> Status["fib-tran:TransactionStatus"];
Through this RFC, we aim to lay the groundwork for a future where collaboration thrives securely and reliably, fostering innovation, transparency, and trust among participants.
This section defines the objectives of the proposal, including the goals, scope, and intended outcomes. It outlines the need for a standardized approach to representing fact claims and identifies the key technologies and standards utilized.
2.1. Ensure Trustworthiness: Ensure that the facts are trustworthy and immutable - fostering trust among stakeholders.
2.2. Semantic Interoperability: Incorporating standards such as PROV-O, SKOS, and VOID annotations facilitates semantic interoperability. Enable seamless information exchange and collaboration across diverse domains and platforms.
2.3. Knowledge Curation: The fact web should serve as a structured repository for organizing and discovering relevant facts by adhering to standards, ontologies and vocabularies, such as PROV-O, SKOS, and VOID.
2.4. Transparent and Reproducible: By capturing provenance information using PROV-O, the fact web enables transparent and reproducible research. Auditors can trace the lineage of data and assertions, understand how they were derived or obtained, and verify their authenticity.
2.5. Reasoning and Analysis: The fact web facilitates automated reasoning and analysis. By representing data and relationships using standardized RDF, tools can infer new knowledge, detect patterns, and derive insights.
2.6. Privacy and Security: While promoting openness and transparency maintain privacy and security of sensitive information. Access control is part of the graph, identifying confidential data, authorized agents, privacy regulations and ethical standards.
2.7. Collaboration and Sharing: By providing APIs, query interfaces, and visualization tools, the graph enables seamless collaboration and communication, accelerating the pace of discovery and innovation.
The fact web describes how fact claims are represented as linked data serialized in JSON-LD format.
JSON-LD provides a lightweight and flexible means to express semantic information in a structured and easily understandable manner.
This RFC proposes a methodology for leveraging the InterPlanetary File System (IPFS), Linked Data (JSON-LD), and Smart Contracts to construct a trusted network of fact webs.
Through the use of JSON-LD, we ensure semantic interoperability and compatibility, enabling machine-readable representation and interpretation of fact claims. Additionally, Smart Contracts provide governance mechanisms for managing the lifecycle of fact claims, ensuring transparency, and enforcing trust among participants.
The distributed, immutable, and censorship-resistant nature of IPFS, we aim to address the challenges associated with decentralized trust and establish a reliable repository for storing and accessing fact claims.
The technical architecture outlined in this RFC provides a blueprint for integrating IPFS into existing systems to establish a tamper-resistant repository for storing and accessing fact claims.
Furthermore, the validation mechanisms outlined in this RFC ensure compliance with predefined constraints and rules, ensuring data integrity and consistency across fact webs.
sequenceDiagram
participant Client
participant SmartContract
participant IPFS
participant Ethereum
participant Oracle
Client->>Client: Create RDF Claims
Client->>IPFS: Publish (JSON-LD) Claims
IPFS-->>Client: Return IPFS URL
Client->>SmartContract: Claim Facts
SmartContract->>Oracle: FactClaims Event
Oracle->>IPFS: Retrieve Claims
IPFS-->>Oracle: Return IPFS Claims (JSON-LD)
Oracle-->>Oracle: Validate Claims
Oracle-->>Client: Notarized Claims
@prefix prov: <http://www.w3.org/ns/prov#> .
<https://fact.claims/> prov:generated <https://fact.claims/example#claim1>.
<https://fact.claims/example#claim1> prov:wasAttributedTo <ethereum://0x123abc...> .
<https://fact.claims/example#claim1>
rdf:label 'fact claim #1';
rdf:comment 'Trusted Facts for Autonomous Agents'.
prov:wasAttributedTo within the RDF claims to the Ethereum smart contract address (ethereum://0x123abc...) serving as the originating entity.Example URL format: ipfs://QmXqPj9sk...
ipfs:// URL within its own document, however one can and should reference URLs of previously published IPFS claims.ipfs://... URL of the published claims.pragma solidity ^0.8.0;
interface IFactClaims {
event FactClaims(string ipfsURL);
function claim(string memory ipfsURL) external {
emit FactClaims(ipfsURL);
}
}
ipfs://... provided in the event to retrieve the published claims from the IPFS network.prov:wasAttributedTo property to the expected ethereum:// address.This section introduces standard semantic ontologies used in the proposal, such as PROV-O, SKOS, and VOID. It outlines the role of these ontologies in enhancing interoperability and compatibility.
By adhering to these standard ontologies and vocabulary definitions, the fact web ensures consistency, compatibility, and seamless integration.
The fact web relies on standard semantic ontologies to ensure interoperability and compatibility across diverse ecosystems
PROV-O furnishes a standardized vocabulary for representing provenance information, facilitating the documentation and tracking of entities, activities, and their relationships. By incorporating PROV-O, the fact web can effectively capture the lineage and historical context of data, decisions, and actions within the ecosystem.
This vocabulary defines the only mandatory fact (prov:wasAttributedTo) needed to define a fact claim .
SKOS presents a standard framework for representing controlled vocabularies and organizing knowledge systems. By utilizing SKOS, the fact web can establish and manage hierarchical and associative relationships among concepts, thereby enhancing semantic enrichment and knowledge organization within the ecosystem.
VOID provides metadata specifications for describing RDF datasets, including details concerning the dataset's structure, accessibility, and usage. Integration of VOID into the fact web facilitates comprehensive documentation of dataset characteristics and attributes, thereby improving dataset discoverability, accessibility, and interoperability within the ecosystem.
Additionally, integration with Schema.org, OpenGraph, and similar standards significantly enhances search engine results (SERPs) and addresses the evolving landscape of "answer engines." Considering the importance of trust and relevance in the post-search era, further exploration of these standards is warranted.
{
"@context": {
"prov": "http://www.w3.org/ns/prov#"
},
"@graph": [
{
"@id": "ipfs://QmXqPj9sk...",
"prov:wasAttributedTo": {
"@id": "ethereum://0x123abc..."
}
},
{
"@id": "ethereum://0x123abc...",
"prov:generated": {
"@id": "ipfs://QmXqPj9sk..."
},
"prov:used": {
"@id": "https://fact.claims/example#claim1"
}
},
{
"@id": "https://fact.claims/example#claim1",
"prov:hadPrimarySource": {
"@id": "ipfs://QmXqPj9sk..."
}
},
{
"@id": "https://fact.claims/example#claim1",
"prov:wasDerivedFrom": {
"@id": "ethereum://0x123abc..."
}
}
]
}
At runtime, URLs referenced within the JSON-LD, especially those residing outside the IPFS subgraph, may be dereferenced at the agent's discretion. This dereferencing process involves retrieving the content associated with a URL from the web and incorporating it into the fact web. It's crucial to ensure that data referenced on the public internet is permalinked, consistently and reliably accessible.
Unlike fact claims stored within the IPFS subgraph, Internet-sourced facts need not be immutable. Dynamic observations and updates from external sources may be ingested and inferred by the agent at its discretion. This approach enables the fact web to incorporate real-time data and adapt to evolving information landscapes while maintaining the integrity of internally stored immutable fact claims.
This section outlines the validation process, including SHACL (Shapes Constraint Language) validation, and emphasizes conformance with VOID and PROV-O standards to maintain interoperability and data quality.
| Requirement | Community Contributions |
|---|---|
| IPFS Integration | js-ipfs for JavaScript or py-ipfs for Python or Java IPFS API for Java |
| RDF Representation | Apache Jena for Java or RDFLib for Python |
| Smart Contract Integration | Web3.js for JavaScript or Web3.py for Python |
| SHACL Validation | TopQuadrant SHACL or Eclipse RDF4J SHACL |
The validation uses SHACL to ensure compliance with the protocol's simplest semantics, your use case likely includes additional steps.
As a minimum, a fact web should conform to the following SHACL
fact:FactClaims
a sh:NodeShape ;
sh:targetClass prov:Entity ;
sh:property [
sh:path prov:generated ;
sh:minCount 1 ;
sh:nodeKind sh:IRI ;
] ;
sh:property [
sh:path prov:wasAttributedTo ;
sh:minCount 1 ;
sh:nodeKind sh:IRI ;
] .
In fact claims ecosystems, establishing the immutability of data is crucial for building trust and reliability. The integration of IPFS (InterPlanetary File System) and RDF not only ensures immutability but also provides cryptographic proof of ownership.
5.2.1. Unique Identification IPFS assigns a unique cryptographic hash to each piece of content, including fact claims. This hash, derived from the content itself, serves as the content's address on the IPFS network, securely linking the content's identity to its actual data.
5.2.2. immutable Nature Utilizing cryptographic hashing algorithms like SHA-256, IPFS ensures that any modification to the content results in a completely different hash. Thus, even the slightest alteration to the content produces a distinct address, rendering the original content immutable.
5.2.3. Decentralized Distribution IPFS content is distributed across multiple nodes. When a fact claim is added to IPFS, it gets replicated across numerous nodes, ensuring redundancy and resilience. This further strengthens the immutability of the content.
5.3.1. Semantic Interoperability RDF provides a standardized framework for representing data in a semantic format. Fact claims, along with their associated metadata and relationships, can be represented using RDF vocabularies such as PROV-O and VOID (Vocabulary of Interlinked Datasets). This semantic representation enhances interoperability and machine readability.
5.3.2. Provenance and Attribution RDF enables the representation of provenance information, including attribution, sources, and lineage of fact claims. By incorporating PROV-O, fact claims can include metadata describing their origins, transformations, and ownership. This provenance information enhances transparency and trust in the data.
5.4.1. Verification Mechanisms IPFS enables verification mechanisms that allow users to verify the integrity of fact claims by recalculating their content hashes and comparing them with the expected addresses. This process ensures that the content remains unchanged and authentic, enhancing trust and reliability.
5.4.2. Semantic Integrity By crawling the fact web, the trustworthiness and provenance of fact claims can be inspected.
This section explores various use cases for fact claims, including regulatory compliance, financial auditing, supply chain management, healthcare data management, and more. It discusses the standards and technologies relevant to each use case.
This section addresses key concerns, focusing on best practices for mitigating risks and safeguarding trust.
Fact webs should conform to standard semantic ontologies like VOID and PROV-O.
Adhering to these standards ensures semantic interoperability, facilitating seamless integration and exchange of fact claims across diverse platforms.
Ensuring the immutability of data is crucial for establishing trust. Integration of IPFS and RDF not only ensures immutability but also provides cryptographic proof of ownership provenance protocol.
We acknowledge contributions from many individuals or organizations who shared expertise, feedback, review, or other assistance during the development of the proposal.
As applicable, this section summarizes the changes made in the current version compared to earlier versions of the proposal.
fact flaims contract, laying the foundation for the proposed Ethereum smart contract.claim function to emit the FactClaim event with the provided ipfsURL, enabling the publication of fact claims with corresponding IPFS URLs.