roadmap 2010-2011

[Francois Bonnarel]

Hi all,
   let me comment briefly two other points in Pat's proposal.
Regards
François
Patrick Dowler a écrit :
> 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
>
> 2. extract the "data linking" from SIAv2 and develop it as an independent 
> standard that can be used in multiple services
>   
I think DataLink and AccessData have to be distinguished.
  * Assume we have "discovered" a dataset in the query phase of whatever 
protocol SIA, SSA or ObsTap. The simplet version of "Accessing Data" 
from this dataset is indeed full retrieval. Additional parameters can 
allow the tuning of the Data Access. BUt they will not be the same in 
General for the different DAL protocols.
It is true that some features may be common to all kind of services, 
like full retrieval of course, access to metadata in IVOA formats, or 
Definition of file internal parameters such as extension number, table 
name , table row, pixel cutout in an array, for a FITS extension, or a 
VOTABLE. But many features we need in accessing data will be specific to 
a given data category, such as cutout based on WCS which cannot be the 
same for an image and for a spectrum. Resampling images and cubes cannot 
be driven with methods common to light curves or event lists. Hence Each 
dedicated protocol will have a specific profile of DataAccess 
capabilities. Each specific service will implement all the mandatory and 
some optional features of the capabilities of this profile.

  * Data link will be different, because it will DESCRIBE the 
relationship between a Dataset and an  "AccessData reference" in 
general. In the case of Obstap , where the DataSet
may be a complex structure made of different types of specific DataSets, 
accessible via various specific services, the datalink  query  response 
will be  a VOTABLE containing various access references  for a single 
dataset referred by its ObsId. The nature of these links have to be 
described in the response (Are they metadata/discovery links from any of 
the DAL protocol types? Or AccessData methods retrieving actual 
scientific data? What kind of output is it giving ? metadata ? images ? 
spectra ? what is the format of the output ? ) probably requiring 
several fields (with their own utypes, UCDS, names) in the VOTABLE, thus 
making DataLink a specific service... By the way "DataLinkinks" provided 
for datasets discovered via SIA or SSA services may allow to link them 
to their parent complex dataset described in an ObsTap service. Thus, 
this closes the loop.

    So while AccessData must be somewhat specific to each specialized 
protocol, DataLink (not yet developped) can indeed be
a commonality to all protocols.
> 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 :-)
>
> 4. pass work on the ImageDM to the DM-WG
>   
    Spectrum data model and full Observation model/Characterisation 
Datamodel
have been developped in parallel for historical reasons. There was a 
hurry to get
a full service for spectra. Now the full model has made progress and his 
consistent
with what is needed in ObsTap (so called OBsData model core components)
If an image DM effort is to be done it should be to extract a subset of 
the full datamodel
utypes valid for Images and cubes (see a prelimlinary version in SIA2 draft)
> With this sort of approach, the SIAV2 specification will be the glue that pulls 
> the required elements together: DALI-sync, ImageDM, PQL, and DataLink.
>
> Likewise, SSAv2 would require at least DALI-sync, SpecDM, PQL, and DataLink. 
> When we get to making an update to TAP, it would also slim down and refer to 
> these and other standards. Other standards (SimDAP, for example) could be 
> defined to require DALI-sync, SimulationDM, and ADQL.
>
> * overly ambitious roadmap
>
> TAP (or DAL) extension schema (RFC Q4-2010): DAL+Registry need to begin work 
> on this immediately and finalise at Nara 2010.
>
> PQL (design/proto Q4-2010, RFC Q1-2011): work must start now, looking for 
> editor, author list will emerge during discussions
>
> DALI (design/proto Q4-2010, RFC Q1-2011): work must start now, looking for 
> editor, author list will emerge during discussions
>
> DataLink (design/proto Q4-2010, RFC Q1-2011): work must start now with mailing 
> list discussion of plausibility, use cases, and scope
>
> SIAv2 (prototypes and WD by Q2-2011): depends on ImageDM and above standards
>
> SSAv1.x (TBD): depends on whether fixes to SpecDM require it and on urgency 
> SSAv2 (TBD): depends on SpecDM, PhotDM, above standards, and requirements
>
>   


-- 
=====================================================================
François   Bonnarel           Observatoire Astronomique de Strasbourg
CDS (Centre de données        11, rue de l'Université
astronomiques de Strasbourg)  F--67000 Strasbourg (France)

Tel: +33-(0)3 68 85 24 11     WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 68 85 24 25     E-mail: francois.bonnarel at astro.unistra.fr
---------------------------------------------------------------------