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

[Mireille Louys]

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