Observation model feels a bit confused - or perhaps it's just me?

[DJWalker42]

I'm just going to write down some thoughts on the Observation type in the model, some of this may be a stream of consciousness so I apologise in advance.

Currently, the Observation class is abstract and consists of a list of Targets, an ObservationField, a desired TechnicalGoal for the observation, and a list of ObservingConstraints that are generally used to codify TimingWindows. Observations have two concrete types: TargetObservation, and CalibrationObservation. The only difference between these types is that the latter has an additional member representing the intended use of the calibration (pointing, bandpass, ...).

What is the point of ObservationField member given the current makeup of an Observation? Does it represent a "scan" area? Or the patch of sky containing the "main" target or targets and the "calibrator" targets?

The list of Targets in a TargetObservation represent the "scientific" targets, the point of the proposal, whereas the list of Targets in a CalibrationObservation are the the "calibrators" for those "scientific" targets. Correct me if I'm wrong, but in general when observing, you regularly, if not periodically, switch between the scientific-target and a calibrator-target or -targets. Therefore, you want calibrator-targets that are nearby the scientific- target to minimise travel time for the telescope/s. There is nothing in the current model that connects a calibrator-target to a specific scientific-target. The upshot of this is that the observatory would have apply some effort to work-out which calibrator-target or -targets goes with which scientific-target. Not intractable, but it does depend on why an astronomer chose those particular calibrator targets, and proximity may be not have been the primary concern i.e., the best calibrator target may not be the closest.

There is nothing in the model stopping someone from creating a observing proposal that consists solely of CalibrationObservations, is this a valid use-case?

Because TargetObservation and CalibrationObservation types are siblings it makes it difficult in Java, at least, to switch an Observation from one type to the other, if this action is useful at all?

Would it be better to model an Observation as containing a single scientific-target, with an optional list of calibrator-targets for the "main" scientific-target, which also somehow codifies their intended use, along with the TechnicalGoal and ObservingConstraints? This removes the need for two types of Observation, and connects calibrator-targets to the main, scientific target; the calibrator list could even be specified in priority order, maybe.

There may also be a tie-in here with sensitivity calculators to compute an "optimal" ratio of time spent between the main target and the calibrator-target/s.

Additionally, an Observation needs to be connected to an ObservingMode as provided by the observatory. It would be nice to have the "mode" as a member of the Observation type. The ObservingMode type is found in the Proposal Management Data Model, separate to the Proposal Data Model where the Observation resides, so I don't think that is possible. An ObservingMode can only be connected to an Observation during (or after) proposal submission.