Architettura

Lo stato C in ONTO (decisione 34). ONTO ha tre valori nativi, V, F e N, e per le sue ricerche una proprietà assente vale N. Per questo una parte C non riceve in ONTO alcun valore di verità: lo stato e il motivo sono campi di testo, le dipendenze sono relazioni, ogni valutazione è un elemento con data e modo. Il backend applica la regola delle congetture e chiede a ONTO di calcolare solo sulle parti che hanno un valore.

Come è fatto oggi (tappe dalla 2 alla 6). Le teorie stanno in quattro tabelle di ONTO, create dal backend all'avvio: teorie, proposizioni, proprieta e aggregazioni, legate da riferimenti che ONTO controlla. Ogni teoria porta la sua lingua (oggi solo l'italiano, decisione 39), le sue parti affermate, scritte come formule sulle proposizioni (P0 ^ P1), e la provenienza: scritta a mano, implicita (da «ma», «affinché»), citata (da «Marco dice che…», con a chi è attribuita) o grammaticale (da una forma flessa). Una teoria entra con la chiamata POST /teorie in un'unica transazione, insieme alle teorie che porta con sé: o entra tutto o non entra niente. POST /teorie/anteprima mostra la mappatura senza salvare, con le parole che non è riuscita a usare e le parole nuove, mai viste dal modello: queste vanno confermate o corrette prima di salvare (decisione 41). L'analisi delle frasi usa il modello italiano di TheoryFlow (decisione 40). Dalla tappa 4 i valori stanno nelle tabelle valutazioni e dipendenze: dopo ogni inserimento, cancellazione o conferma di alternative il backend ricalcola tutte le teorie e aggiunge una riga solo dove il valore è cambiato, con motivo, modo, parti mancanti e data. Le teorie di alternative confermate stanno in alternative e membri_alternative. Il valore V, F, C o N è un testo: ONTO calcola con le sue tavole le espressioni che il backend gli manda, uno scenario per riga. Due prove automatiche controllano l'archivio: test/archivio_onto.py avvia un ONTO di prova, inserisce alcune teorie, lo riavvia e controlla che si ritrovino già mappate, identiche; test/analisi_frasi.py segnala se il modello di spaCy legge le frasi di prova in modo diverso da com'è registrato. Dalla tappa 5 l'app usa solo le chiamate della tabella qui sotto e non fa calcoli propri; non ha account (decisione 13). Dalla tappa 14 scrivere richiede il wallet della persona, sbloccato nel backend (decisione 67), e ogni scrittura entra nella tabella registro come voce firmata, nella stessa transazione delle righe (decisione 68). Il circuito arriva già composto da GET /circuito (decisione 43); l'app sceglie solo dove mettere i punti sullo schermo. Dalla tappa 6 una frase scritta nell'app passa prima da POST /richieste/riconosci: le regole della lingua o, se nessuna decide, un classificatore dicono se è una richiesta o un'immissione, e l'utente può cambiare la scelta (decisione 44). Il correttore ortografico usa il vocabolario del modello e, se il sistema lo ha, il dizionario Hunspell della lingua, che TheoryFlow non distribuisce (decisione 45). Backend, app e ONTO stanno come sottomoduli nel repository d'insieme theoryflow: lì ./avvia.sh accende tutto e prepara ciò che manca (ONTO compilato, ambiente Python), chiudendo l'app li ferma, e ./prove.sh esegue tutte le prove del backend e dell'app; con gli hook di git in strumenti/hook le prove girano da sole prima di ogni commit. Prima di salvare, una frase si confronta con le teorie esistenti: ciò che c'è già non si salva una seconda volta, e ogni inserimento entra nello storico (decisione 51). Il circuito è a semivettori (decisione 52) e l'app segue il percorso della teoria (decisione 53).