data.is_prediction and data.is_observation not valid for all datatypes

[perolavsvendsen]

https://github.com/equinor/fmu-dataio/blob/264ae9b8f8353f7714082e28a404d9d2752ab30d/schema/definitions/0.8.0/schema/fmu_results.json#L161

is_prediction and is_observation are currently required. However, they do not make sense for all data types, and some data types (e.g. SMRY) have both predictions/observations in the same file.

[perolavsvendsen]

Clarification on is_prediction: This tag is introduced to flag what data coming out of a model run is to be considered a prediction by that model. E.g. if a depth surface is exported on multiple steps along the model workflow, it is likely that it is only the last one which is representing the actual prediction. The others are intermediate steps for QC purposes. For consumers outside the FMU ecosystem, this differentiation is important. Non-predictions should not be used.

This may, however, cause confusion inside the FMU ecosystem, as the term "prediction" has multiple meanings, e.g. "prediction runs", "prediction" in HUM, etc.

@rnyb

[perolavsvendsen]

Clarification on is_observation: This tag is introduced related to seismic, where it is important that e.g. surfaces based on observed seismic is differentiated from simulated surfaces. The tag itself has no direct relationship to "is_prediction".

When content is seismic we have the option of introducing a data.seismic-tag. However, this is not included for e.g. surfaces. However, perhaps we should consider introducing/allowing data.seismic.is_prediction for any data type - not knowing the full consequences wrt materializing this in fmu-dataio.