What is a Knowledge Space? Qu'est-ce qu'un Knowledge Space ?
A Knowledge Space is bra0's fundamental unit of organization. Not a folder. Not a database. A living continuum of knowledge — structured, governed, and sovereign by construction; evolvable, modular, and reliable under evolution by design. Un Knowledge Space est l'unité fondamentale d'organisation de bra0. Pas un dossier. Pas une base de données. Un continuum vivant de savoir — structuré, gouverné et souverain par construction ; évolutif, modulaire et fiable sous évolution par dessein.
A Knowledge Space lets you onboard a new expert in days, not weeks — prove an audit in queries, not reconstruction — and converge multiple actors on one testable representation of a complex domain. Un Knowledge Space vous permet d'onboarder un expert en jours, pas en semaines — de prouver un audit en requêtes, pas en reconstitution — et de faire converger plusieurs acteurs sur une seule représentation testable d'un domaine complexe.
A different mental model Un modèle mental différent
Formal definition Définition formelle
A Knowledge Space maps to a NextGraph Store. Personal Knowledge Spaces use one of the 3 default Stores (Private, Protected, Public). Collaborative Knowledge Spaces use Group Stores — one per team or project, with no limit. It is the governance boundary: permissions, curation scope, and collaboration rules are defined at this level. Un Knowledge Space correspond à un NextGraph Store. Les Knowledge Spaces personnels utilisent l'un des 3 Stores par défaut (Privé, Protégé, Public). Les Knowledge Spaces collaboratifs utilisent des Group Stores — un par équipe ou projet, sans limite. C'est la frontière de gouvernance : permissions, périmètre de curation et règles de collaboration sont définies à ce niveau.
Inside a Knowledge Space, knowledge is organized as N living documents, each containing one entity. Every document is a CRDT with its own history, its own permissions, and its own rich-text note. À l'intérieur d'un Knowledge Space, le savoir est organisé en N documents vivants, chacun contenant une entité. Chaque document est un CRDT avec son propre historique, ses propres permissions et sa propre note rich-text.
Three constitutive properties Trois propriétés constitutives
Beyond its mapping to a NextGraph Store, three properties define what a Knowledge Space is — not optional features, but the reasons a KS exceeds an « RDF dataset ». Together they form the contract any software implementation must honour to host one — engines are swappable, the contract is not. Au-delà de sa correspondance avec un Store NextGraph, trois propriétés définissent ce qu'un Knowledge Space est — non des fonctionnalités optionnelles, mais les raisons pour lesquelles un KS dépasse un « jeu de données RDF ». Ensemble, elles constituent le contrat que toute implémentation logicielle doit honorer pour en héberger un — les moteurs sont interchangeables, le contrat ne l'est pas.
A KS evolves through a four-operation refinement lattice algebra — Add / Specialize / Lift / Demote-Merge, each modelled as a sub-class of prov:Activity. Authoring follows a SKOS-first bottom-up doctrine with explicit triggers for promotion to OWL. The full lifecycle — creation, curation, drift detection, migration, retirement — is a first-class capability domain (KSLM).
Un KS évolue par une algèbre de treillis de raffinement à quatre opérations — Add / Specialize / Lift / Demote-Merge, chacune modélisée comme sous-classe de prov:Activity. L'authoring suit une doctrine SKOS-first bottom-up avec déclencheurs explicites de promotion vers OWL. Le cycle de vie complet — création, curation, détection de dérive, migration, retrait — est un domaine de capacité de première classe (KSLM).
Ontologies inside a KS are organised in named strata (L0 / L0.5 / L1 / L2 / L3 + demo / domain / use-case / methodology / governance). Each module is sealed by closed-namespace containment with single-parent binding: nothing leaks across namespaces unless an alignment file declares it. Foundational grounding (BFO 2020) is carried by a separate alignment file rather than colonising the TBox — the TBox stays implementation-agnostic. Multi-source modules merge into one canonical rendering. Les ontologies à l'intérieur d'un KS sont organisées en strates nommées (L0 / L0.5 / L1 / L2 / L3 + demo / domain / use-case / méthodologie / gouvernance). Chaque module est scellé par un containment de namespace closed-children avec single-parent binding : rien ne fuit entre namespaces sauf déclaration explicite par fichier d'alignement. L'ancrage fondationnel (BFO 2020) est porté par un fichier d'alignement séparé sans coloniser la TBox — la TBox reste agnostique de l'implémentation. Les modules multi-sources fusionnent en un rendu canonique unique.
Every change inside a KS passes a stack of falsifiable gates: tiered ShEx contracts per stratum, SHACL NodeShape per lattice operation, bilingual coverage parity at PR, epistemic admonitions PROVEN / UNVERIFIED / GAP on every load-bearing claim, a reproducible six-dimension ontology quality audit (each dimension bound to a Competency Question + SPARQL test + SHACL gate), and rudof shacl-validate mandatory on LLM contributions. Reliability is engineered, not asserted.
Chaque changement à l'intérieur d'un KS passe une pile de portes falsifiables : contrats ShEx tiered par strate, NodeShape SHACL par opération du treillis, parité bilingue à la PR, admonitions épistémiques PROVEN / UNVERIFIED / GAP sur toute affirmation porteuse, audit qualité ontologique à six dimensions reproductible (chaque dimension liée à une Competency Question + un test SPARQL + une porte SHACL), et rudof shacl-validate obligatoire sur les contributions LLM. La fiabilité est ingéniée, non assertée.
owl:Class subClassOf prov:Activity — every change is provenance-traceable.
Chaque opération est un owl:Class subClassOf prov:Activity — toute modification est traçable par provenance.
Epistemic-discipline tags Marqueurs de discipline épistémique
Every load-bearing claim inside a KS carries one of three tags — an audit script gates the build. Toute affirmation porteuse dans un KS porte l'un des trois marqueurs — un script d'audit verrouille le build.
ADR-063ShEx tiered mandate per stratumMandat ShEx tieré par strateADR-064BFO 2020 grounding via alignment fileAncrage BFO 2020 par fichier d'alignementADR-065Lattice-op event-class doctrineDoctrine treillis op-classe-d'événementADR-066Multi-canonical fragment resolutionRésolution multi-canonique de fragmentsADR-067Closed-children namespace containmentContainment namespace closed-childrenADR-068Epistemic-admonition disciplineDiscipline d'admonition épistémique
Inside a document À l'intérieur d'un document
Each entity occupies one NamedGraph. The document bundles an RDF graph (structured triples) with a Y.js discrete (rich-text note), both synchronized via CRDTs. Chaque entité occupe un NamedGraph. Le document regroupe un graphe RDF (triplets structurés) avec un Y.js discrete (note rich-text), les deux synchronisés via CRDTs.
Two complementary serialisations Deux sérialisations complémentaires
The Knowledge Space, as an abstract object (living continuum), admits two serialisation forms, each addressed by a normative format : Le Knowledge Space, en tant qu'objet abstrait (continuum vivant), admet deux formes de sérialisation, chacune adressée par un format normatif :
- NG Store package (ADR-045) — multi-file, live, CRDT, synchronizable. Suited to authoring and collaboration. multi-fichiers, vivant, CRDT, synchronisable. Adapté à l'authoring et à la collaboration.
-
Turtle snapshot (ADR-035,
spec/knowledge-space/v0.1) — single.ttlfile, frozen at a moment, transmittable. Suited to delivery to a third party and to auditable conformance. fichier.ttlunique, gelé à un instant, transmissible. Adapté à la diffusion vers un tiers et à la conformance auditable.
The snapshot is the normative export of a package : every conformant package must be able to produce a conformant snapshot. The reverse is not required (a snapshot may be edited directly without going through a package). Le snapshot est l'export normatif d'un package : tout package conformant doit pouvoir produire un snapshot conformant. L'inverse n'est pas requis (un snapshot peut être édité directement sans passer par un package).
« Conformance » here is the snapshot-level axis (SHACL gates on export). It is distinct from the Keet 6-dim quality axis applied to the underlying TBox. Both axes are formalised in spec §7.5.1 — Two orthogonal axes. « Conformance » désigne ici l'axe au niveau snapshot (gates SHACL sur l'export). Il est distinct de l'axe qualité Keet 6-dim appliqué à la TBox sous-jacente. Les deux axes sont formalisés à spec §7.5.1 — Two orthogonal axes.
The 11 entity types Les 11 types d'entités
Every node in a Knowledge Space is one of 11 types. Each type maps to a W3C or domain standard — no proprietary types. Chaque nœud dans un Knowledge Space est l'un des 11 types. Chaque type correspond à un standard W3C ou métier — aucun type propriétaire.
| # | Type | RDF | Role |
|---|---|---|---|
| 1 | Class | owl:Class |
Concepts — the building blocks of your ontologyConcepts — les briques de votre ontologie |
| 2 | ObjectProperty | owl:ObjectProperty |
Relationships between conceptsRelations entre concepts |
| 3 | Attribute | owl:DatatypeProperty |
Data fields (strings, numbers, dates)Champs de données (chaînes, nombres, dates) |
| 4 | AnnotationProperty | owl:AnnotationProperty |
Metadata (labels, definitions, comments)Métadonnées (labels, définitions, commentaires) |
| 5 | ConstraintShape | sh:NodeShape |
Validation rules (SHACL / ShEx)Règles de validation (SHACL / ShEx) |
| 6 | Instance | owl:NamedIndividual |
Concrete data pointsPoints de données concrets |
| 7 | Assertion | rdf:Statement |
Reified statements (provenance, confidence)Énoncés réifiés (provenance, confiance) |
| 8 | Mapping | rml:TriplesMap |
Data source transformations (CSV, JSON, SQL)Transformations de sources (CSV, JSON, SQL) |
| 9 | ExternalSource | dcat:Distribution |
Cataloged external datasetsJeux de données externes catalogués |
| 10 | Rule | bra0:Rule |
Business or inference rulesRègles métier ou d'inférence |
| 11 | ConceptScheme | skos:ConceptScheme |
Taxonomies and controlled vocabulariesTaxonomies et vocabulaires contrôlés |
The eight facets Les huit facettes
A Knowledge Space is not a flat collection of entities. It is a multi-faceted structure where eight complementary dimensions coexist. Each facet answers a different question about your domain. The same eight facets appear in the Knowledge Space narrative view under operational labels (Sources, Vocabularies, Rules, Questions, Narrative, Evidence, Governance, Mapping) — this page gives the formal names. Two mappings make the correspondence tight: Vocabulary absorbs the structural skeleton (OWL 2, RDFS) that would otherwise be a separate "Structure" card, and the Narrative facet materializes formally on the LFS-MD ↔ Provenance bridge. Un Knowledge Space n'est pas une collection plate d'entités. C'est une structure multi-facettes où huit dimensions complémentaires coexistent. Chaque facette répond à une question différente sur votre domaine. Les mêmes huit facettes figurent dans la vue narrative Knowledge Space sous des libellés opérationnels (Sources, Vocabulaires, Règles, Questions, Narration, Preuves, Gouvernance, Mapping) — cette page donne les noms formels. Deux correspondances rendent l'alignement strict : Vocabulary absorbe le squelette structurel (OWL 2, RDFS) qui aurait sinon fait l'objet d'une carte « Structure » séparée, et la facette Narration se matérialise formellement sur le pont LFS-MD ↔ Provenance.
Together, the eight facets produce answers that are traceable, contestable, and portable — expressed in open W3C standards, not in a vendor's format. Ensemble, les huit facettes produisent des réponses traçables, opposables et portables — exprimées dans les standards ouverts du W3C, pas dans le format d'un éditeur.
Instances, assertions, concrete facts grounded in the structure. Instances, assertions, faits concrets ancrés dans la structure.
Taxonomies and concept schemes (SKOS), plus classes, hierarchies and relationships (OWL 2, RDFS). The shared languages and the skeleton of your domain. Taxonomies et schémas de concepts (SKOS), ainsi que classes, hiérarchies et relations (OWL 2, RDFS). Les langues partagées et le squelette de votre domaine.
Constraint shapes that enforce data quality at the boundary. Shapes de contraintes qui assurent la qualité des données à la frontière.
Competency questions the KS must answer, executed as SPARQL against the graph. The acceptance test of the structure. Questions de compétence auxquelles le KS doit répondre, exécutées en SPARQL sur le graphe. Le test d'acceptation de la structure.
Who changed what, when, under whose authority. Append-only chain carrying the narrative bridge (LFS-MD bidirectional annotations link rich text back to graph nodes). Qui a changé quoi, quand, sous quelle autorité. Chaîne append-only qui porte le pont narratif (les annotations bidirectionnelles LFS-MD relient le texte aux nœuds du graphe).
Bridges to external systems: CSV, JSON, SQL, APIs. Declarative rules, reified as first-class KS entities. Ponts vers les systèmes externes : CSV, JSON, SQL, APIs. Règles déclaratives, réifiées comme entités de première classe du KS.
Access policies, consent, catalog metadata. Politiques d'accès, consentement, métadonnées catalogue.
How a Knowledge Space maps to the three layers Comment un Knowledge Space se projette sur les trois couches
Every Knowledge Space is organized internally according to the 3-layer architecture. The facets distribute naturally across the three layers: Chaque Knowledge Space est organisé en interne selon l'architecture 3 couches. Les facettes se distribuent naturellement entre les trois couches :
| Layer | Facets | Standards |
|---|---|---|
| Control Plane | Governance, ProvenanceGouvernance, Provenance | ODRL DCAT PROV-O SHACL DID |
| Semantic Layer | Vocabulary, Validation, Queries, MappingVocabulaire, Validation, Requêtes, Mapping | OWL 2 RDFS SKOS SHACL ShEx SPARQL RML |
| Data Plane | Data (instances, assertions, external sources)Données (instances, assertions, sources externes) | Oxigraph NextGraph CRDT |
Sovereignty by construction Souveraineté par construction
A Knowledge Space is local-first (P2, P5). All computation — SPARQL queries, OWL reasoning, SHACL validation — runs in the browser via Rust/WASM. NextGraph provides peer-to-peer synchronization with end-to-end encryption. No server sees your data. Un Knowledge Space est local-first (P2, P5). Toute la computation — requêtes SPARQL, raisonnement OWL, validation SHACL — s'exécute dans le navigateur via Rust/WASM. NextGraph fournit la synchronisation pair-à-pair avec chiffrement de bout en bout. Aucun serveur ne voit vos données.
Every Knowledge Space exports to W3C standard formats (Turtle, JSON-LD, PROV-O). If bra0 disappears, your knowledge persists — readable by any compliant tool. This is the Ink & Switch litmus test: "Do all your customers' apps continue working in perpetuity, even if all servers are shut down?" Chaque Knowledge Space s'exporte en formats standards W3C (Turtle, JSON-LD, PROV-O). Si bra0 disparaît, votre savoir persiste — lisible par tout outil conforme. C'est le test d'Ink & Switch : « Toutes les apps de vos utilisateurs continuent-elles à fonctionner perpétuellement, même si tous les serveurs sont éteints ? »
How it compares Ce qui le différencie
| Capability | Wiki / Notion | Obsidian / Logseq | RDF in-house | Knowledge Space |
|---|---|---|---|---|
| Schema enforcementApplication du schéma | — | — | ✓ | ✓ SHACL + ShEx |
| Governance as dataGouvernance comme donnée | ACL | — | custom | ✓ ODRL |
| Audit trailPiste d'audit | page history | git | custom | ✓ PROV-O |
| W3C portabilityPortabilité W3C | export MD | export MD | ✓ | ✓ Turtle, JSON-LD |
Self-documenting shapes Shapes auto-documentées
Write a SHACL shape describing your domain constraints. bra0 generates the reference documentation automatically — classes, properties, validation rules, SPARQL examples. No manual documentation, no drift between schema and docs. This is the evidence-first principle applied to documentation itself. Écrivez une shape SHACL décrivant vos contraintes métier. bra0 génère la documentation de référence automatiquement — classes, propriétés, règles de validation, exemples SPARQL. Pas de documentation manuelle, pas de dérive entre schéma et docs. C'est le principe evidence-first appliqué à la documentation elle-même.
Engine: rudof query (SPARQL) extracts shapes, target classes, property constraints and cardinality from .shapes.ttl files, then generates static HTML pages in the bra0 design system. The ontology quality gate controls publication: only ontologies with a PASS verdict across 6 quality dimensions produce a page. Pattern inspired by SHACL Play (Sparna.fr).
Moteur : rudof query (SPARQL) extrait les shapes, classes cibles, contraintes de propriétés et cardinalités depuis les fichiers .shapes.ttl, puis génère des pages HTML statiques dans le design system bra0. Le gate qualité d’ontologie contrôle la publication : seules les ontologies avec un verdict PASS sur 6 dimensions de qualité produisent une page. Pattern inspiré par SHACL Play (Sparna.fr).
Knowledge persists without agents (P3). An AI agent can read, enrich, or validate a Knowledge Space — but the Knowledge Space exists and is meaningful independently. Agent contracts contain zero domain facts. Remove every agent, and every triple, every provenance record, every policy remains intact. Le savoir persiste sans agents (P3). Un agent IA peut lire, enrichir ou valider un Knowledge Space — mais le Knowledge Space existe et a du sens indépendamment. Les contrats d'agents ne contiennent aucun fait métier. Supprimez tous les agents, et chaque triplet, chaque enregistrement de provenance, chaque politique reste intact.
Grounding Ancrage
The Knowledge Space maps one NamedGraph per entity onto a NextGraph Store (or Group Store). It implements P2 (Sovereignty), P3 (Knowledge Persists Without Agents), and P5 (Local-First). The entity types align with BFO categories (Vogt 2024, "Semantic Units"). Le Knowledge Space place un NamedGraph par entité sur un NextGraph Store (ou Group Store). Il implémente P2 (Souveraineté), P3 (Le Savoir Persiste Sans Agents) et P5 (Local-First). Les types d'entités s'alignent sur les catégories BFO (Vogt 2024, « Semantic Units »).
Interactive guide — a deeper visual walkthrough of Knowledge Spaces on the main site.
3-Layer Architecture — how Control Plane, Semantic Layer, and Data Plane interact.
Principles (P1-P10) — the foundational constraints a Knowledge Space implements.
Ontology Catalog — the ontologies available for use in a Knowledge Space.
SHACL Shapes Catalog — validation shapes and their auto-generated documentation.
Guide interactif — une exploration visuelle plus approfondie des Knowledge Spaces sur le site principal.
Architecture 3 couches — comment le Control Plane, la Semantic Layer et le Data Plane interagissent.
Principes (P1-P10) — les contraintes fondatrices qu'un Knowledge Space implémente.
Catalogue d'ontologies — les ontologies disponibles dans un Knowledge Space.
Catalogue SHACL Shapes — shapes de validation et leur documentation auto-générée.