La diversità esiste e non è eliminabile: luoghi, persone e dati sono diversi per natura (la stazione di Trento è diversa da un'altra stazione, ecc.). Tuttavia, se riusciamo a rendere trasparente il processo che ci porta a dimenticare i dettagli non rilevanti, allora possiamo costruire un modello MMM per il quale riusciamo a ottenere proprietà desiderabili come correttezza e completezza.
In altre parole: la correttezza si può impostare e costruire formalmente, ma per farlo è necessario aver prima formalizzato il modello. Solo dopo aver fissato la formalizzazione possiamo costruire il mapping (la funzione di interpretazione) in modo tale da poter --- quando serve --- "buttare via" (o dimenticare) il modello originario senza perdere informazioni rilevanti per le inferenze che vogliamo fare.
Nel corso è stato detto che la competenza (cioè la proprietà secondo cui ogni elemento del dominio è denotato da qualche formula del linguaggio) non è sempre necessaria per usare la semantica. Però, nella pratica:
-
Prima si costruisce la rappresentazione formale (e quindi si può non richiedere competenza completa).
-
Poi si può "buttare via" il modello originario purché la costruzione sia fatta in modo tale che non si perda nulla dell'informazione necessaria.
Quindi la competenza non serve necessariamente per utilizzare la semantica, ma serve per costruirla in modo robusto, così che la si possa poi scartare senza danni.
Una teoria può essere incompleta rispetto a un modello MMM, ma al contempo essere teoria anche di modelli più grandi M′M'M′ che estendono MMM. Questo è importante perché, se non stiamo attenti, la nostra teoria potrebbe includere o escludere cose che non vogliamo: dobbiamo poter definire formalmente la massimalità di una teoria rispetto a un modello.
-
Teoria massimale rispetto a MMM: è completa rispetto a MMM (non si può aggiungere una formula vera in MMM rimanendo all'interno della teoria senza contraddizione).
-
La massimalità non è sempre obbligatoria, ma diventa critica quando vogliamo gestire sistematicamente l'incompletezza in un sistema.
Se il database di un'università contiene solo le persone registrate ma manca una persona realmente presente in aula, una query al database restituirà "non c'è" mentre nel mondo reale quella persona esiste. Questo disallineamento tra rappresentazione del database e rappresentazione del mondo richiede attività aggiuntive di gestione (controlli, verifiche, procedura per aggiornare i dati). In alcune applicazioni (dove un errore è tollerabile) questo costo extra è accettabile; in applicazioni critiche (es. esami, controllo accessi, sicurezza) non lo è.
Molte rappresentazioni pratiche (ER model, tabelle, archivi, ecc.) sono intrinsecamente incomplete: certi ruoli o relazioni non sono esplicitati. Per esempio nel database S3 (o in altri sistemi di gestione studenti) non è detto che "un professore possa essere anche un assistente" sia scritto esplicitamente: può risultare implicito o non modellato. Queste lacune sono la ragione per cui i sistemi reali non sono logiche complete e perfette.
Per questo motivo esistono convenzioni pratiche (come la unique name assumption nei database) e meccanismi di engineering (identificatori univoci, matricole) che cercano di ridurre ambiguità e confusione.
Quando parliamo di modellazione vogliamo spesso arrivare a una rappresentazione canonica: una forma in cui la teoria è massimale e corretta rispetto a un modello "inteso" (intended model). In breve:
-
La teoria massimale è costruita in modo da non dimenticare niente di ciò che è rilevante per il modello canonico.
-
Il modello canonico è la rappresentazione del modello "inteso" che guida la costruzione della funzione di interpretazione.
Se abbiamo fissato il modello canonico e la funzione di interpretazione, possiamo ricavare una teoria T che è corretta e --- se vogliamo --- massimale rispetto a quel modello. L'obiettivo è far sì che la teoria T rappresenti completamente MMM nel modo canonico deciso.
Nella pratica della realizzazione di un sistema, spesso si arriva a "trascrivere" il dominio nei termini del linguaggio; il dominio finisce per diventare una collezione di simboli o record. Questo è ciò che accade quando:
-
si progetta una specifica e si decide quali entità modellare;
-
si definisce la sintassi e il vocabolario (nomi, attributi, relazioni).
Tuttavia, nel mondo reale questo processo può diventare impossibile da compiere in modo esauriente (es. il dominio dei numeri naturali è infinito; modellare tutto "ciò che è vero nel mondo" alla lettera è impraticabile). Perciò la modellazione richiede scelte: cosa includere, cosa escludere e quale livello di dettaglio adottare.
La logica nasce perché, anche senza conoscere tutto in maniera esplicita, possiamo definire regole che ci permettono di calcolare conseguenze e ragionare. La logica dà strumenti per essere resilienti: sapere regole generali che permettono di ricostruire informazioni implicite e per derivare ciò che non è stato esplicitato.
Detto più pragmaticamente: nella modellazione e nello sviluppo software, non è realistico codificare tutto. La logica serve a definire gli schemi, le ipotesi e le regole sotto cui possiamo lavorare in sicurezza.
Nei sistemi reali la funzione di interpretazione spesso è implementata tramite identificatori concreti:
-
Matricola (numero identificativo dell'università) → puntatore a una scheda studente;
-
Codice fiscale → identifica una persona in modo (quasi) univoco;
-
Altri identificatori (passaporto, patente) usati in sistemi diversi.
Questi identificatori hanno pregi e limiti: a volte funzionano bene, altre volte introducono problemi (ad esempio la gestione di cambi di nome, stranieri, errori di trascrizione). La realtà mostra che la costruzione di mapping "puliti" è costosa e tutt'altro che banale: richiede pratiche amministrative, procedure e (spesso) un lavoro manuale di pulizia dei dati.
Le scelte che si fanno nel rappresentare il mondo --- quali entità modellare, quali attributi includere, quale livello di completezza perseguire --- sono decisioni di costo. Ottenere completezza e competenza totale costa (in progettazione, calcolo, memoria, manutenzione), quindi spesso si accettano compromessi:
-
applicazioni dove un errore è tollerabile: si accettano rappresentazioni parziali e procedure ad hoc;
-
applicazioni critiche (es. controllo treni, sicurezza, esami): si richiedono investimenti maggiori per garantire correttezza e completezza dove necessario.
È utile distinguere più livelli:
-
Livello del linguaggio: gli strumenti sintattici che usiamo (nomi, verbi, strutture).
-
Livello della conoscenza: la teoria che esprime la nostra conoscenza (le asserzioni che formiamo).
-
Livello del mondo: il dominio inteso e i fatti oggettivi.
La progettazione logica e informatica consiste nel decidere quale livello enfatizzare e come far corrispondere i tre livelli attraverso mapping e procedure di costruzione.
La lezione introduce l'idea di Entity Graph come una delle rappresentazioni principali (quelle "di base" utilizzate più frequentemente) che poi possono essere composte per ottenere modelli più complessi. Le rappresentazioni di base (es. modelli relazionali, knowledge graph) permettono di tracciare entità, attributi e relazioni e si mappano naturalmente sulle istanze concrete (es. gli studenti di S3).
Quando si vogliono evitare problemi di sinonimia o polisemia (parole con più significati) o si vuole parlare a diversi livelli (persone vs. insiemi), si usano modelli composti che definiscono con più cura il vocabolario, i tipi e le relazioni.
Ogni analisi seria inizia con definizioni chiare: definire che cosa è un intero, un reale, cosa intendiamo per "studente", "professore", ecc. Questo vocabolario consente la costruzione di teorie con ipotesi chiare. Se il linguaggio di specifica è canonico e la conoscenza è coerente, allora le istanze (es. gli oltre 17.000 studenti in S3) si applicheranno correttamente alle regole della teoria.
Questa è la ragione per cui, prima di scrivere regole e algoritmi, si dedica tempo a definire il dominio e la sintassi: la qualità della modellazione dipende da lì.
Nel mondo reale non si codifica tutto; si definiscono ipotesi e regole che consentono di inferire ciò che non è esplicitato. Questo è il lavoro della logica applicata: usare regole di comportamento (e regole di inferenza) che permettono agli umani e ai sistemi di essere resilienti anche con informazioni parziali.
Questa è la ragione per cui i sistemi operativi reali, i database e molte applicazioni pratiche adottano convenzioni (unique identifiers, regole di inferenza, strategie di fallback) per gestire ambiguità e mancanze.
In sintesi:
-
La diversità e l'incompletezza sono problemi reali ma gestibili con progettazione e formalizzazione.
-
La canonicalità (teorie massimali, modelli canonici) è un ideale utile per capire come costruire rappresentazioni robuste, ma spesso impraticabile da realizzare pienamente nel mondo reale (per motivi di costo e scala).
-
Le applicazioni pratiche richiedono compromessi: spesso si sceglie la soluzione che minimizza i costi pur garantendo le proprietà essenziali (correttezza laddove critica, procedure di fallback dove possibile).
-
Nella prossima lezione si partirà dai modelli canonici di base e si vedrà come costruire i modelli composti e come queste scelte impattano l'ingegneria del software e il ragionamento automatico.