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

[Anita M. S. Richards]

I agree with Mireille ... we cannot define all possible data product types 
a priori, a single model is the only practical solution.  We can have 
detailed examples for the types most in demand at any one time, but 
extensibility is crucial.

best wishes
a

MERLIN/VLBI National Facility, Jodrell Bank Observatory, 
Cheshire SK11 9DL, U.K. +44 (0)1477 571321 (tel) 571618 (fax)

"Socialism or barbarism?" Rosa Luxemburg (1915)

On Thu, 16 Sep 2010, Mireille Louys wrote:

> Dear all,
>
> I am just adding my 2c here about data modeling.
> I think ObsCoreDM already covers the need to describe an image.
> Actually any data set dealing with n dimensions can be described
> with a subset of the Characterisation DM as mentionned by Doug.
>
> For special cases, when one image derives from a set of images(
> coaddition, mosaic, etc) we may need to show this dependancy as
> planned for associations.
>
> Now for data cubes (IFU, etc.) the same combination approach is used
> so association, progenitors of a data product are general concept that
> can be formalised in the Observation data model.
>
> 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.
>
> 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.
>
> Any opinion among DM and DAL working group?
>
> Thanks, Mireille
>
>
>
>
>
> Douglas Tody <dtody at nrao.edu> a écrit :
>
>> On Fri, 10 Sep 2010, Patrick Dowler wrote:
>> 
>>> In the recent past we have had success in bringing more complex standards 
>>> to
>>> completion by breaking them down into manageable pieces and   re-using 
>>> existing
>>> standards wherever possible. I would like to continue with this approach 
>>> and
>>> propose the following as a way forward. Obviously there are many things to
>>> collectively consider and decide
>>> 
>>> 1. remove all query parameters from SIAv2 and actively work on PQL
>> 
>> As has been noted previously, type typed DAL services support actual
>> data access (generation of virtual data), not just discovery (unlike
>> ObsTAP for example which is a pure discovery/description interface).
>> A generic PQL interface cannot support virtual data generation since
>> this requires knowledge of the type of data being access.  Hence,
>> PQL cannot replace the typed parameters in the DAL interfaces - this
>> is fundamental in my opinion.  If all we want to do is data discovery
>> and whole file data retrieval, then ObsTAP can be used instead of
>> the typed data access interfaces.
>> 
>>> 2. extract the "data linking" from SIAv2 and develop it as an independent
>>> standard that can be used in multiple services
>> 
>> I am not sure what this refers to, but I agree that data linking is a
>> broader topic.
>> 
>>> 3. extract non-query parameters, error handling, VOTable usage, etc   from 
>>> SIAv2
>>> and develop it as a base standard for all DAL services; this   standard 
>>> would be
>>> called Data Access Layer Interface, or DALI :-)
>> 
>> Agree that this should be standardized, so far as possible, across
>> all the DAL interfaces.  It could possibly be extracted into a
>> separate document.  The question is whether there is enough here to
>> warrant this, as it would mean that service implementors and client
>> application folks have more documents to read.  I think this needs
>> more careful consideration.
>> 
>>> 4. pass work on the ImageDM to the DM-WG
>> 
>> There is no formal image data model for VO that I am aware of
>> (unlike spectra for example).  At present we use a combination of
>> FITS WCS and the Characterization model from DM.  I agree that if a
>> more formal image data model is needed this should be a DM activity,
>> it is just not clear that we are to that point yet, since FITS + Char
>> (with appropriate application detail in the SIAV2 spec) would appear
>> to provide all we need at present.
>> 
>> 	- Doug
>
>
>
>
>
> ----- Fin du message transféré -----
>
>
>
>