[ImageDM]: Provenance

[Gerard Lemson]

Dear all
> Doug wrote:
> I merely based this upon the Provenance Utypes we defined in ObsCore
(Table
> 5).  Ultimately we probably want a separate Provenance submodel (like
Char)
> but so far as I know this is not finalized yet, so I went with what we
currently
> have.
> 
It would be good for the current effort not to presume too much about a
Provenance model that is still under construction.
For that model may well have a very different relation to the current models
than one might presume right now.

As example I mention the pattern used in the simulation data model, which
itself is based on the older domain model, which was based on the
measurement pattern in the book "Analysis Patterns" by Martin Fowler. In
these models the provenance can be seen as an emergent property within a
more comprehensive modeling of scientific experiments (e.g. Observation,
Imaging, Spectroscopy) and their results (e.g. ObservationDataset-s, Image,
Spectrum ). This pattern also allows for describing post-processing simply
as another experiment, which might combine multiple ObservationDataset-s
into a new result, something Doug suggested may need to be covered by the
current efforts.
And it shows how a more complex provenance may naturally emerge. For example
the provenance of a source catalogue can be seen as a source extraction
(experiment) applied to the result of a calibration (experiment) applied to
the (raw) result of an observation (experiment). I.e. the full "provenance"
is a whole workflow/pipeline if you wish, consisting of a number of
experiments with results, which is most naturally modeled using a
composition relationship from parent Experiment to child DataSet; not by
some abstract Provenance class that is referenced by a dataset.
In particular these models are not sub models of the ones currently
considered, which focus on ObservationDataset-s; in fact one can argue the
relation is quite the reverse. The description of a dataset is merely a part
of the larger model describing the complete experiment.
I am not claiming that the goals of the ImageDM effort, which may be usage
in some specific protocol, require such a larger model as a *logical* model.
But it would be good to analyse (standard first step in data modeling
efforts leading to a domain or analysis model) this larger world with some
care before deciding on the logical model supporting your use cases.

(Please pardon my plug for some efforts that already addressed these issues
a long time ago.)

Cheers
Gerard


>  	- Doug
> 
> 
> > I'd like to make sure this is modeled the way we want it, and then
> > fold that into the migration plan if needed.
> >
> > The options I see:
> >  a) state that there is a mistake in ObsCore, there should be a
> > Provenance class and single association to that.
> >       * my diagram would then add Provenance to the Provenance Package
> > (colored to indicate not in ObsCore doc), with an association from
> > ObservationDataset.
> >       NOTE: This would mean a change to the class hierarchy in
> > ObsCore, so would be a compatibility issue.
> >
> >  b) state that there is no container class "Provenance"
> >       * my diagram could move the associations to ObsConfig and
> > Proposal to "_ObsCore"
> >       * ImageDM would remove that class and inherit the associations
> >
> >
> > Opinions?
> >
> > Mark
> >