Revised ImageDM-ObsCore architecture

[Douglas Tody]

Just to amplify on this point: in ObsTAP (ObsCore), it is permitted
for a record to describe either an Observation or a specific dataset
(data product).  So for example the Observation may be described, and a
"package" can be downloaded containing multiple data products.  Or the
individual datasets (data products) may be exposed, linked by a common
obs_id.  Or some combination of the two.  So there is a distinction
between an observation and a dataset.  An observation may have multiple
datasets.  An individual dataset has a type, a subtype, a calibration
level, a size, and so on.  (it is also possible to have datasets that
are not observations).  - Doug


On Wed, 13 Nov 2013, Douglas Tody wrote:

> Hi Mark -
>
> This second version looks like a step backward to me.  It seems clear
> that ObservationDM is the basic general data model.  ObsCore is a
> specialization of Observation defining a "core" subset of attributes,
> plus (in its ObsTAP extension) it defines a specific, restricted mapping
> to a table.  This was the case with your previous version, but this
> latest one has ObsCore as the root data model which seems quite odd
> since ObsCore is a subset of a more general model.  Actually I am not
> sure there really is an "ObsCore" model at all; it seems that what we
> really have is the ObservationDM with ObsCore/ObsTAP defining a specific
> application (like ImageDM, SpectralDM) including a core/mandatory set of
> fields and a specific table mapping.
>
> Within Observation, naming the main class ObservationDataset seems
> arbitrary to me.  Naming this class just "Dataset" would work as well.
> To some extent the choice of name is arbtrary, but there is no reason
> that we could not model an Observation separately from its use within a
> Dataset.  There are use cases for example, where a single Observation
> could result in several Dataset objects (e.g., a cube, a 2D image, and a
> catalog all derived from the same Observation).  In fact, that is the
> whole point of obs_id, which is used to associate multiple datasets
> derived from a single observation.
>
> My suggestion would be to back up to your previous figure, and replace
> ObservationDataset with either "Dataset" (equivalent to what you have
> but semantically better defined), or add Dataset below Observation as I
> had in my version.  Dataset, or ObservationDataset, should have
> attributes such as Type, Subtype, etc.  This would be almost identical
> to what I had earlier, except for adding SpectralDM and ObsCoreDM, and
> breaking Provenance out as a separate model (this last is arbitrary; it
> would work about as well as a submodel like DataID, which is how it is
> currently used).
>
> 	- Doug
>
>
>
> On Wed, 13 Nov 2013, CresitelloDittmar, Mark wrote:
>
>> All,
>> 
>> Sorry for the frequent image updates.. maybe it would be better to post on
>> them on the twiki?
>> I modified the connections to improve the class hierarchy.  I think this
>> resolves the problem
>> I mentioned in the earlier post.  Note. I colored the ObsCore
>> generalization blue because it
>> is not in the ObsCore document.
>> 
>