[Image Data Model]was Re: roadmap 2010-2011

[François Bonnarel]

  Le 16/09/2010 21:29, Doug Tody a écrit :
> On Thu, 16 Sep 2010, Patrick Dowler wrote:
>
>> On Thursday 16 September 2010 09:31:27 Mireille Louys wrote:
>>> I think ObsCoreDM already covers the need to describe an image.
>>
>>> I do not see the point in developing one DM for each kind of data 
>>> product.
>>> Lightcurves description can benefit of the description of the
>>> Characterisation axes, and this the same for TimeSeries, from my point
>>> of view.
>>
>> That sounds great and should promote the kind of consistency and 
>> re-use that
>> we need. I mentioned ImageDM but hoped this would be the answer.
>>
>> Do you envision that the SpectrumDM will be superceded by the more 
>> general
>> ObservationDM (at some point)?
>
> The ObservationDM (generic Dataset) is the base model for *describing*
> astronomical datasets - it applies to any type of data.  However, when
> it comes to an actual dataset instance we are not merely describing the
> data, we have an actual dataset with data samples/vectors.  Spectrum
> defines a standard for an actual dataset containing 1D spectral data.
> It is a special case since astronomy does not have such a standard -
> spectra are stored in archives in many different ways, but we needed
> some way to get spectral data back to client analysis applications
> without having them have to know about every spectral data format
> out there.  We do not need something comparable for image data since
> we use FITS in this case.
Yes SSA model is ObservationDM for spectra , while SpectrumDM is comparable
to ObservationDM + some DATA ORGANISATION Model - like is FITS -)
>
> Now it is true that much of what is in SSA and Spectrum is actually
> just the generic dataset/observation model, so having a comprehensive
> definition of the generic model will be useful, and this could help
> streamline a future update to the SSA and Spectrum specifications.
> We still need to define how such a generic data model is used in a
> particular application (such as SSA) however; it may be necessary to
> extend the generic model, specify what is mandatory for the particular
> application (such as a DAL query), define unit contraints for the
> particular application, and so forth.
>
> SIAV2 has some special needs which are not adequately covered by
> the generic models - in particular it relies heavily on FITS WCS
> for much of its function.  The image geometry and WCS is different
> than characterizing the data (WCS is a spatial calibration not a
> characterization, and we need both).  We do not need to respecify
> FITS WCS since this is already done by the FITS standards, but we do
> need to specify precisely how WCS is used by SIA.  This is a central
> part of the access protocol, especially the accessData method.
There is some proposal for WCS in SIA2 in the internal draft from 
November 2009(see in the DAL pages)
>
> Characterization is also essential for SIAV2.  In particular we will
> need to do some more work to adequately characterize radio data cubes.
> Anita covers this well in her Note on radio data which can be found on
> the SIAV2 twiki page.
>
      As Anita worked as a coauthor of characterization 1 we long time 
checked that
this model was working for radio cubes. Within the frame of 
Characterization 2
the draft of which will be posted end of October whe have introduced 
possibilities
for description of polarimetry and visibility data, working also with Anita.

>     - Doug
>
>>> Each model can be reused partly, not all axes are mandatory, and so
>>> derived representations can be defined and serialised either in XML or
>>> in VOTable.
>>
>> At some point, someone has to define this derived model. Is that then 
>> the
>> responsibility of the application? For example, following the thread 
>> above,
>> would a future SSA 2.0 refer to the ObservationDM and SSA would specify
>> requirements and restrictions that capture the "use of the model"? 
>> That seems
>> consistent with current use of data models in DAL.
>>
>> If a specific application needed some additional detail that was not 
>> covered in
>> the model, could it extend the model somehow? should it? or should these
>> things always be folded back into the main Observation DM? I don't 
>> have any
>> specific examples for such a scenario, but it seems bound to happen 
>> due to us
>> all not being 100% precogniscient or simply because a very specific 
>> part has no
>> general use and never makes it into the general model (which is 
>> tougher). More
>> curious how you see this being handled...
>>
>>
>>
>>