Creare un Open Knowledge Format con Draft_: la guida pratica
Un bundle OKF non è altro che una directory di file Markdown ben ordinati: esattamente ciò che Draft_ produce, senza configurare nulla. Perché scrivere la tua base di conoscenza in un elaboratore di testi Markdown, per poi consegnarla così com'è a un agente IA. Tre casi in cui cambia tutto.
L’Open Knowledge Format di Google (OKF) non richiede alcuno strumento proprietario. Un bundle è una directory di file Markdown, un po’ di frontmatter YAML, link tra i concetti, e nient’altro. In altre parole, il formato è già il tuo editor di testo.
Detto questo, «possibile» e «piacevole» non sono sinonimi. Scrivere una base di conoscenza è un lavoro di scrittura: vuoi un posto tranquillo per farlo, non un terminale. È qui che Draft_ calza a pennello, non grazie a una funzione «OKF» dedicata, ma perché il suo formato nativo è già quello dell’OKF. Vediamo perché, e poi tre casi concreti in cui conta.
Perché un elaboratore di testi Markdown per l’OKF?
L’OKF separa due ruoli: chi produce la conoscenza e chi la consuma. Il consumatore è un agente IA. Il produttore è un umano che scrive, e che merita di meglio di un campo di inserimento per farlo.
Questo ribaltamento è la linea di Draft_: sei tu a nutrire l’IA, non l’IA a creare al posto tuo. Per quanto l’OKF si rivolga alle macchine, tutto ciò che contiene nasce da un pensiero umano: scritto, strutturato, assunto. E chi tiene la tastiera non è una scelta neutra: delegare la scrittura a un assistente ha un costo cognitivo ormai misurato, dal sovraccarico mentale alla dipendenza dall’IA, mentre la gerarchia neuroscientifica mano > tastiera > IA mostra che è il coinvolgimento di chi scrive a dare valore a ciò che viene prodotto. Una base di conoscenza vale solo per ciò che ci metti dentro. Meglio scriverla tu stesso, in uno strumento costruito per questo.
E infatti i mattoni dell’OKF sono, uno per uno, quelli di Draft_:
| Convenzione OKF | Draft_, così com’è |
|---|---|
| Directory di file Markdown | Formato di archiviazione nativo |
| Frontmatter YAML | Zona metadati in testa al documento |
| Link incrociati tra concetti | Link interni relativi ([testo](../cartella/doc.md)) |
| Albero di concetti | Spazi e cartelle |
| Bundle versionato | Sincronizzazione GitHub integrata |
| Leggibile da un umano | Editor Markdown senza distrazioni |
Niente da installare, niente da collegare. La corrispondenza non è un caso: l’OKF ha semplicemente formalizzato ciò che i buoni editor Markdown fanno da tempo.
Il flusso di lavoro concreto
Crei uno spazio: è la radice del tuo bundle. Al suo interno disponi delle cartelle (personaggi/, tabelle/, luoghi/…) che diventano le famiglie di concetti. Ogni documento si apre con una zona metadati dove scrivi il frontmatter in chiaro (type: Personaggio, title, tags), senza nemmeno i delimitatori ---, che Draft_ aggiunge all’export. Il nome del documento diventa il nome del file (orders → orders.md), così controlli il percorso di ogni concetto; i tuoi link interni diventano gli archi del grafo che l’agente seguirà; e la sincronizzazione con GitHub trasforma il tutto in un repository versionato. Un bundle OKF valido, uscito da un editor dove soprattutto hai scritto.
Tre casi concreti
Caso 1: la bibbia di un universo di finzione
Stai scrivendo un romanzo, una serie, un gioco. Tieni uno spazio bibbia/:
personaggi/
└── elena.md (type: Personaggio)
luoghi/
└── valdris.md (type: Luogo)
fazioni/
└── patto-di-ferro.md (type: Fazione)La scheda di Elena cita Valdris e il Patto di Ferro tramite semplici link. Più tardi, consegni il repository a un LLM: «Ecco la mia bibbia. Scrivi una scena in cui Elena torna a Valdris, fedele alla sua storia e all’atmosfera del luogo.» L’agente recupera le schede pertinenti seguendo i link e scrive dentro il tuo universo, senza che tu debba rispiegarlo a ogni sessione. La tua coerenza diventa un capitale, non un peso mentale.
Caso 2: una documentazione tecnica viva
Documenti un’API o un prodotto, per tipo: endpoints/, concetti/, runbooks/, ciascuno con il suo type. Il repository vive accanto al codice, nello stesso GitHub, versionato dagli stessi commit. La documentazione smette di essere un wiki parallelo che invecchia: è leggibile da un agente di CI, dall’assistente che risponde alle domande del team, o dalla sviluppatrice che arriva lunedì. Una sola fonte, e tutti, umani e macchine allo stesso modo, ci si abbeverano.
Caso 3: note di ricerca interrogabili
Accumuli note su un argomento: concorrenti, letture, idee. Ogni nota è un concetto, collegato agli altri. Il bundle sincronizzato diventa una memoria esterna che interroghi: «Quali tensioni attraversano questi due approcci nelle mie note?» L’LLM percorre il grafo del tuo pensiero per rispondere: non Wikipedia, il tuo ragionamento, strutturato e citato.
Il perimetro, in una riga
Draft_ copre l’anello umano della catena OKF: scrivere, nominare, collegare, versionare. Il consumo avviene poi con qualsiasi LLM, ed è tutto il bello di un formato portabile. Scrivi il frontmatter e mantieni il controllo della coerenza, esattamente il livello di controllo che ci si aspetta da un lavoro di scrittura curato.
In breve
- Un bundle OKF è una directory di Markdown + frontmatter YAML; Draft_ lo produce nativamente.
- Spazio = radice, cartelle = concetti, zona metadati = frontmatter, nome del documento = nome del file, link interni = grafo, sincronizzazione GitHub = bundle versionato.
- Scrivi in un vero elaboratore di testi, per poi consegnare la conoscenza così com’è a un agente.
- Tre terreni di gioco: bibbia di finzione, documentazione tecnica viva, note di ricerca interrogabili.
Per iniziare a costruire la tua base di conoscenza OKF, hai già tutto il necessario in Draft_: scrivi, nomini, sincronizzi. Il resto è Markdown, ed è già nelle tue mani.