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

[Doug Tody]

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.

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.

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.

 	- 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...
>
>
>
>