Cube/ImageDM - Comments on Observation-Dataset Overview diagram

[CresitelloDittmar, Mark]

Mireille,

Thanks for the great input...

On Mon, May 12, 2014 at 12:28 PM, Louys Mireille
<mireille.louys at unistra.fr>wrote:

>  Hi Mark , hi DMers,
>
> Thanks for the update.
> Here are my comments about the new diagram binding Dataset and Experiment:
>
> - is there any reason why *ObsDataset *is 'slanted' , i.e is considered
> as an abstract class?
>

Because I don't think ObsDataset is something anyone would instantiate..
It must be some "kind" of dataset to be useful,  an ImageDataset,
SpectralDataset, or even for
the DAL services, the particular QueryResponse.



> - relationship between Observation->observationID and ObsDataset->DataID->
> observationID :
> the text should clearly state that various situation may appear:
>

This is a topic still to discuss. As with Target, ObsConfig, Proposal, the
observationID is owned by the Observation, and is limited to an
ObsDataset.. so Dataset.DataID.observationID is probably not proper.
However, this element comes from ObsCore, so is more difficult to simply
re-locate.



> In the CTA project , the DM combines several Observation instances  to
> build up an ObsDataset:
>  these two classes may have a N..M relationship in the IVOA Image DM to
> support the various use-cases.
>

I think we need to make specific definitions for what we mean by
"Observation", "Dataset", and "Data Product".
If I have a software process (experiment) which combines ImageDatasets from
different Observations, is this an ObsDataset? or another type with the
same structure and additional Provenance metadata from the software
Experiment.



> -the *DataModel *Class:
> this class was discussed in order to provide a kind of structured label
> for any document expressing the serialisation
> of some metadata compliant to an IVOA data model.
> I think it should not be hooked to any class , but present as a global
> object in any serialisation of any form
> VOTable or XML or FITS .
>
>
Yeah.. I've had similar discussions with Omar.  I agree that this object
does not belong in the model.
It needs to be replaced by a serialization convention for providing this
information.  I like how you express it here.



> -*Derived* Class
> This is a fuzzy concept that represent the kind of things that can be
> computed from the data,  here SNR, VarAmpl, Redshift.
> I understand we need it but cannot precisely these kinds of interpretation
> results.
> *Derived *could be just a container with a variation of computed
> measures, SNR, VarAmpl, Redshift , etc...
> then this can be re considered after some practical usage.
>
>
I've had similar thoughts.  I was thinking that Derived could be modeled in
a manner similar to ObsConfig, with DerivedElements defined by each type of
dataset as appropriate.  Spectral would define SNR, VarAmpl, Redshift.



> - composition of *Observation *with *BaseTarget*
> I suggest to have two links of composition on AstroTarget and Target ,
> with cardinality 0..1.
>
> why would the observation need 2 targets?


Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140512/0734819a/attachment.html>