Ontologies & Data Model

Structured knowledge representation built on FIBO standards with custom ƒxyz extensions for progressive membership, multi-token systems, and AI agent integration. Our ontology-driven approach ensures semantic interoperability with global financial standards.

Foundation: FIBO (Financial Industry Business Ontology)

The Financial Industry Business Ontology provides the standardized foundation for our knowledge graph, ensuring compatibility with global financial systems and regulatory frameworks.

Core FIBO Components

Financial Instruments

Standardized definitions for currencies, derivatives, and financial products:

• Currency classifications and exchange rate models
• Liquidity instruments and risk parameters
• Derivative contracts and structured products
• Credit facilities and lending instruments

Market Infrastructure

Market venues, settlement systems, and market data structures as defined by FIBO:

• Venue definitions and matching protocols
• Settlement mechanisms and clearing systems
• Price discovery structures and market depth
• Market data feeds and reference systems

Regulatory Framework

Compliance standards and regulatory entity relationships:

• KYC/AML standards and verification procedures
• Reporting requirements and regulatory submissions
• Jurisdiction mapping and legal frameworks
• Compliance rules and audit requirements

Legal Entities

Corporate structures and legal relationship definitions:

• Corporate hierarchies and ownership structures
• Legal jurisdictions and regulatory domains
• Contractual relationships and agreements
• Fiduciary responsibilities and obligations

ƒxyz Custom Extensions

Custom ontologies that extend FIBO to support ƒxyz-specific concepts while maintaining interoperability.

Membership Schema

Progressive membership system with rites and validation:

@prefix fxyz: <https://fxyz.network/ontology/> .
@prefix fibo: <https://spec.edmcouncil.org/fibo/ontology/> .

fxyz:Member a owl:Class ;
    rdfs:subClassOf fibo:LegalPerson ;
    rdfs:label "Network Member" ;
    rdfs:comment "Individual or entity participating in the ƒxyz network" .

fxyz:memberLevel a owl:DatatypeProperty ;
    rdfs:domain fxyz:Member ;
    rdfs:range [ owl:oneOf ( "OBSERVER" "INITIATE" "EXPLORER" "NAVIGATOR" "FOUNDER" ) ] .

fxyz:validationScore a owl:DatatypeProperty ;
    rdfs:domain fxyz:Member ;
    rdfs:range xsd:float .

fxyz:ritesCompleted a owl:ObjectProperty ;
    rdfs:domain fxyz:Member ;
    rdfs:range fxyz:Rite .

Token, governance, and agent shapes — implementation, not Turtle

Earlier drafts of this page included fxyz:florinBalance / fxyz:jouleCredits / fxyz:howTokens and similar Turtle classes for governance circles and Fixies. Those names did not match the live schema and have been removed to avoid drift.

The canonical shapes live in code:

• Tokens — Florin / Joule / HoW are SPL mints (Solana Token-2022 program); on-chain state is the source of truth, not RDF. See packages/solana/ for the program clients and packages/economics/ for the issuance / decay / redemption math (CES kernel, Boltzmann decay, ConVo planned). Member balances are not stored as a fxyz:florinBalance property on a Neo4j node — they are read live from chain via the Solana client and joined to a Member { did } node by wallet linkage.
• Governance circles — Circle nodes are shaped by packages/types/src/circle.ts and grown through migrations under packages/neo4j/migrations/. Hierarchy is a (:Circle)-[:PARENT_OF]->(:Circle) edge anchored at circle-anchor. Role definitions live as Role nodes with (:Member)-[:FILLS_ROLE]->(:Role) edges; see canon §13 + apps/docs/content/docs/architecture/holacracy.mdx.
• Fixies — agent definitions are managed via the Letta backend and surfaced through packages/fixie/ + packages/ai/. There is no fxyz:agentType enum carved into the graph; agent kind is configuration on the Letta side. The trinity vocabulary (All-Knowing / All-Seeing / All-Doing) is canonical in docs/canon/multiplex-ontology.md §13.5; binding to named TypeScript types is roadmapped (deferred-set #110).

For Cypher patterns covering these node and edge types, see Cypher Examples.

Temporal Schema

Time-based relationships integrated with Solana Proof-of-History for immutable event ordering and temporal querying capabilities.

Temporal Properties

• PoH Integration: Solana slot numbers for cryptographic event ordering
• Block Timestamps: Immutable time anchoring to blockchain
• Relationship Evolution: How connections change over time
• State Transitions: Member progression and status changes
• Event Causality: Cause-effect relationship mapping

Query Capabilities

• Historical Queries: Graph state at any point in time
• Trend Analysis: Relationship evolution patterns
• Causal Inference: Event impact analysis
• Predictive Modeling: Future state projections
• Audit Trails: Complete change history with verification

Temporal modeling in practice

Time is captured by per-relationship timestamp properties on relevant edges (e.g., :TRANSFER { createdAt }, :VOUCHED_AT, :ALLOCATED_AT) plus a Slot reference where on-chain anchoring matters. There is no fxyz-namespaced JSON-LD wire format for transactions; canonical transaction state is on Solana, and the Neo4j projection mirrors it via the indexer pipeline. See packages/neo4j/migrations/ for the actual property names and packages/solana/ for the chain-side encoding.

RDF & Neo4j Integration

RDF Standards

Our ontologies follow W3C standards for maximum interoperability:

• rdflib-neo4j: Direct RDF to Neo4j graph mapping
• SPARQL Queries: Standard semantic web query language
• Linked Data: URIs for global resource identification
• Schema Validation: SHACL constraint checking and validation

Neo4j Enhancement

While maintaining RDF compatibility, the system uses Neo4j's native capabilities:

• Cypher Queries: Graph-native query language for performance
• Performance Optimization: Native graph algorithms and indexing
• Real-time Updates: Live data synchronization and streaming
• Vector Embeddings: AI/ML integration for semantic search

Schema Evolution

Versioning Strategy

Ontologies evolve with the network while maintaining backward compatibility:

• Semantic Versioning: Major.minor.patch version control
• Migration Scripts: Automated data transformation tools
• Deprecation Paths: Graceful transition for obsolete concepts
• Extension Points: Designed flexibility for future concepts

Community Governance

Schema changes follow the same governance process as network decisions:

• Proposal Process: RFC-style documentation and review
• Expert Review: Technical validation by ontology experts
• Community Consensus: Member voting on significant changes
• Implementation Timeline: Coordinated rollout across applications

Validation & Quality Assurance

Automated Validation

• SHACL Constraints: Automated constraint checking
• Consistency Rules: Logical consistency validation
• Performance Testing: Query performance benchmarks
• Integration Tests: Cross-system compatibility verification

Manual Review Process

• Expert Review: Domain expert validation
• Use Case Testing: Real-world scenario validation
• Documentation Review: Clarity and completeness checks
• Community Feedback: Member input and suggestions

Implementation Guidelines

Best Practices

• URI Design: Consistent, resolvable URI patterns
• Documentation: Comprehensive annotation and examples
• Testing: Thorough validation before deployment
• Performance: Optimized for common query patterns

Development Workflow

1. Concept Identification: New concept requirements
2. Ontology Design: RDF/OWL modeling and documentation
3. Validation: Automated and manual testing
4. Integration: Neo4j mapping and performance optimization
5. Deployment: Staged rollout with monitoring

URI Scheme & Linked Data

Every ƒxyz entity is assigned a stable, resolvable URI following the pattern:

https://fxyz.network/entity/{type}/{id}

Schema definitions (classes and properties) live under a separate path:

https://fxyz.network/ontology/{Class}
https://fxyz.network/ontology/{property}

Both paths are registered as the fxyz namespace prefix in the n10s namespace registry. All Turtle examples in this document use @prefix fxyz: <https://fxyz.network/ontology/> consistently with that registry entry.

JSON-LD Export for DKG Publishing

Concept and member nodes can be serialised as JSON-LD for publishing to the Decentralised Knowledge Graph. The export uses the n10s.rdf.export.cypher() procedure with "JSON-LD" format.

A typical exported record looks like:

{
  "@context": {
    "fxyz": "https://fxyz.network/ontology/",
    "fibo": "https://spec.edmcouncil.org/fibo/ontology/",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#"
  },
  "@id": "https://fxyz.network/entity/concept/fx-spot",
  "@type": "fxyz:Concept",
  "rdfs:label": "FX Spot",
  "fxyz:domain": "https://fxyz.network/entity/circle/trading-ops",
  "fxyz:relatedPapers": [
    "https://fxyz.network/entity/paper/arxiv-2301.00001"
  ]
}

Only public-assertion nodes are included in DKG exports. Private assertions remain in the graph but are excluded from export queries (see below).

Public/Private Assertion Split

The graph partitions knowledge into two assertion layers:

Public assertions — facts safe for external disclosure and DKG publishing:

• Concept definitions and inter-concept relationships
• Published research paper metadata and citations
• Circle descriptions and governance structure
• Ontology class and property definitions

Private assertions — internal facts excluded from any export:

• Member activity and contribution scores
• Allocation amounts and token balances
• Compliance status and KYC/KYB results
• Internal audit trails and vote records

The split is enforced at export time by labelling nodes. Public nodes carry a :Public label; private nodes carry :Private. Export queries filter on label:

-- Export only public knowledge for DKG
CALL n10s.rdf.export.cypher(
  "MATCH (n:Public)-[r]->(m) RETURN n, r, m",
  "JSON-LD"
)
YIELD payload
RETURN payload

Private nodes are never included even if reachable from a public node — the Cypher match pattern stops at the label boundary.

References

• FIBO - Financial Industry Business Ontology (EDM Council) - Official FIBO specification in OWL/RDF
• FIBO OWL Ontology Browser - Browse FIBO modules and classes
• W3C RDF 1.1 Specification - Resource Description Framework standard
• W3C OWL 2 Web Ontology Language - Ontology language for semantic web
• W3C SPARQL 1.1 Query Language - Semantic web query standard
• W3C SHACL - Shapes Constraint Language - RDF graph validation standard
• rdflib-neo4j (GitHub) - RDF to Neo4j integration library

The FIBO-aligned ontology ensures interoperability with global financial standards while supporting the network's membership, governance, and token systems.