La mia opinione è che piuttosto che avere un'entità mancante rappresentata come un tipo alternativo, sarebbe meglio descrivere la provenienza dei dati che abbiamo in tutte le entità in qualche modo - come tagging con attributi o relazioni, qualcosa di semplice come come: conosciuto / dato, vs derivato / calcolato / dedotto contro assunto, o qualcosa di più complesso che cattura chi / cosa / quando.
In un modello relazionale, diversi tipi di entità significheranno tabelle separate, che impongono oneri sulle query. In OOP, diversi tipi imporranno oneri analoghi a meno che non si utilizzi l'ereditarietà per unificare i concetti - e per questo direi composizione sull'ereditarietà: in questo caso la composizione delle informazioni di provenienza sull'ereditarietà dei tipi (di provenienza).
is there a common term that is already established to represent this kind of known missing data?
Non che io sia a conoscenza del modo in cui lo descrivi, ma ci sono nozioni di provenienza di informazioni e queste nozioni possono variare da semplici a complesse.
Altrimenti, nel modello relazionale, NULL viene utilizzato per rappresentare due nozioni conflazionate: (1) mancante e non applicabile, e (2) mancante ma applicabile (o semplicemente dati mancanti). La tua descrizione va al secondo utilizzo di NULL in SQL.
(Il primo, mancante e non applicabile, significa che ci sono tipi veramente diversi nella stessa tabella, come quando un CEO non riferisce a nessuno (e mai lo farà: i dati non sono mancanti o sconosciuti, la colonna "non applicabile" a questa riga) così ha la colonna reports to come nulla, a differenza di tutto il resto dei dipendenti che fanno e devono riferire a qualcuno.)
Per vostra informazione, ci sono altri concetti come futures o promesse, che sono in effetti proxy per informazioni non ancora disponibili, sebbene questi siano profondamente correlati ai modelli di programmazione (thread, attività asincrona, altri comportamenti) e meno alla memorizzazione di informazioni del dominio oggetti.