[ImageDM ] dataset datatype diagram comments

[CresitelloDittmar, Mark]

Mireille,

Thank you for taking such a close look at the definitions..


On Wed, May 7, 2014 at 12:39 PM, Louys Mireille
<mireille.louys at unistra.fr>wrote:

>  Hi again,
>
> here are my following comments :
>
> * Dataproduct type :
> I think the list defined in Obscore can be reused here :
> LightCurve is missing
>
> * I do not understand "Mixed" .
> We discussed this concerning files distributed as tarballs with an
> heterogeneous content.
> In this case , the content requires multiples DataID classes , so is
> actually a composed DataSet.
>
> * Does "Photometry" actually stand for "SED"?
>
>
The content of the DataProductType enumeration is from:
   ObsCore-1.0 Rec.: section 3.3.1
      image, cube, spectrum, sed, timeseries, visibility, event

    Spectrum-1.1 Rec.: section 5.7
       TimeSeries, Photometry, Spectrum, Mixed

    CADC Observation model (which came up during the discussions)
       which are based in the ObsCore list..
       IMAGE, SPECTRUM, TIMESERIES, VISIBILITY, EVENTLIST, CUBE, CATALOG
(custom data product type)

  + I'm not sure why SED got dropped... I can add that back
  + Photometry is described as "varying in spectral coordinate with
irregular gaps", so could be SED or PhotometryPoint.
     I have generally interpreted it as applying to PhotometryPoint
  + Mixed is described as a mixture of the others.. not sure this belongs
in the list.
  ** I haven't see any case including "LightCurve".. can you point that
out?  It would be covered under TimeSeries, so just
     depends on how specific this is supposed to be.  **



> * *Quantity *vs RealQuantity
> In the Position class, only derived classed can be used as attributes , I
> guess.
> so we would probably define all the PositionN to have RealQuantity
> attribute(s).
> More generally , do we really need Position , while we have precise STC
> Space Time Coordinates?
> Or are we dealing with indices in an ND array??? so why not PositionIndex
> or the like ?
>

The Position type is a question of mine too.  It seems that since Target is
such a high-level object, the Target.position
should be a fairly light weight location.. in a specified (or implied)
coordinate system.  In the spectral model(s) to date,
this has only been defined as a pair of doubles.

Using the STCMod:Space2DCoordinate would also allow for the same value
pair, but since it includes the complexity
of the associated errors and reference to a Frame.  That seems too much,
and can lead to questions about whether a
user can (or should) include those details.

I used Quantity vs RealQuantity mainly because I didn't see a reason to
limit the base type to 'real'.  I was
thinking of perhaps other types of Target.positions.. like a calibration
source, which may be given as 'n' (integer) meters
along the pointing axis.

I think Target.position is the only usage for the Position type, so is
certainly flexible.



> *datetime
> after the discussion in DAL during the DALI RFC period about the Time
> format one should use, ISO , etc...
> it seems to me that we should rely on precise time formats, ISO, MJD , etc
> ....
> I do not understand the purpose of 'datetime' here.
>
>
I won't say too much about datetime here.. there is a thread for that.
Deciding on what the 'base' time types should be
is an important topic.



> *RightsType
> Public/Secure/Proprietary  are the value we adopted for Obscore.
>
> Ahh.. reviewing this again, I see what happened here.
  + ObsCore-1.0 specifies these values, and references the "VODataservice"
recommendation
     "VODataService: a VOResource Schema Extension for Describing
Collections and Services: December 2010"
  + Spectrum indicates that most of the Dataset level metadata is taken
from "Resource Metadata"
     "Resource Metadata for the Virtual Observatory:March 2007"

Resource Metadata defines Collection.Rights in section 3.4 with the values
"public, proprietary, mixed"
Since that seemed to be the source for the Curation metadata class, I
stayed with this.
We can stick to the ObsCore set.. but will need to be sure to make the
appropriate reference in the doc.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140508/3d6095e4/attachment-0001.html>