This reminds me of an old problem I used to run into with duplicate data.

Duplicates are not always what they seem - duplicates have a relative quantity of how duplicate they are, for example - 100% duplicate identical is what it sounds like, but then what is a 50% duplicate? Well.. that could be a duplicate where semantic meaning that only a human is aware of (missing information) could be used to determine that these two datum are in fact duplicates in different forms, where 50% is identical, but the other 50% is semantically identical. Or 50% truly identical could, in some case, be "good enough" to be considered identical. These are just examples.

Why this example is relevant is because, when deduplicating data, we often have to consider which value(s) we keep as the true singular representation.

The problem is, long after the data is created, this may be impossible to do.

The solution? Often times it is no better than flipping a coin and guessing, i.e. randomly keeping one datum and discarding what we consider to be the duplicate. Or you can try to be fancy and merge the data or choose, based on some rule, what you assume is the data with the highest valid signal and discard or ignore the noise.

This happens every day in practical information systems with messy data.

I always come to the conclusion that in the end, one cannot truly replace missing signal precisely - one can only infer the correct signal. If the information was not recorded and or compressed or corrupted beyond recoverability, there is no way to get it back - only to infer or guess with some degree of confidence, and accept or reject the outcome.

This to me actually clarifies something deeply about the conversion between the real world to the digital one as data, and the conversion of data into information- it is a real physical process.

In my mind it makes clear that the recording of data (or generation of data) is a real physical process of transfer, from an instrument making observations to physical bits in a physical system, which become the raw data.

Without the raw, precise, complete data, your observation is lossy, and therefore everything above it is as well- e.g. information/interpretation, etc.

This isn't a negative. If stated correctly, the above just helps to explain how we imperfectly navigate through the real world with our tools.

All the same, we can do some pretty amazing things in the absence of data, even if some of it is "false" or "wrong".

I spent some time working in the data industry and was fascinated with this topic as well

dont forget the data itself is already a compression of reality. text data has lost tone, situational context, emphasis, etc.

then youve also got different data that yields the roughly same information that isnt exact but serves the same purpose. for example, birthday vs age; one can be used to infer the other although it is more accurate moving in one direction than the other.

youve got resolution of data. for example, A specific hexcode value vs "deep navy blue" vs "blue". sometimes the signal is low resolution but the data type is high resolution and you end up with some tells like when a lot of date data is the 1st of the month or 1st day of the year; implying the signal was at the month level or year level, no day signal available. which to call back an earlier example, can be caused by getting a signal for age but storing it in a birthday data type field

to your point, often the "data" signal is not a single field but set, and then youve got your source updating every month or year, and its not always the same format or exact set, maybe it was collected differently or two or more different sources contributed. its hard to apply any rules without assessing the type of data being considered. newer data that is missing older data, sometimes you carry the old pieces forward and sometimes you dont. sometimes you change the shape of the data by inferring events. job title changed? well the old job title isnt wrong data, its just not their current title and now can be moved to a past job titles" field. maybe past job titles arent something that add value to your use case and it can be dropped, etc.