Cube/ImageDM - Comments on Observation-Dataset Overview diagram/ composition , references

[Louys Mireille]

Hi Mark , hi all,

More on the Observation/Dataset Overview diagram.

I noticed that the current version of Observation has a bunch of 
composition relations to
Target, ObsConfig, Proposal.

I think a simple association with Proposal would be better. I guess 
n..m  relationships here too, because one Proposal may need several 
Observations and One Observation may match  the requirements of several 
proposals.
The 3 red arrows on the diagram duplicate the paths between ObsDataset 
and Proposal, Obsconfig, Target .
I think there references are already designed by the Observation--> 
ObsDataset relation .

In the Experiment package: what are DataSource and BandPass?
BandPass is close to the concept of Filter isn't it?

Best wishes , Mireille.




  13/05/2014 04:36, CresitelloDittmar, Mark a écrit :
> Mireille,
>
> Thanks for the great input...
>
> On Mon, May 12, 2014 at 12:28 PM, Louys Mireille 
> <mireille.louys at unistra.fr <mailto: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/20140514/3ef4e808/attachment.html>