DAP protocol news

[BONNAREL FRANCOIS gmail]

Dear DALers,

Recently discussion occured  about DAP protocol which is planned to be 
the next version of  SIA, extending the scope of the protocol beyond 
images and cubes towards all kind of dataproducts.

See https://github.com/ivoa-std/DAP,  Pull request #3

Starting from this pull request there was a big discussion on two points

This occurred both during a special session at May interop 
(https://wiki.ivoa.net/internal/IVOA/InterOpMay2024DAL/DAL-2-notes) and 
on github (issues + PR comments):

       a ) how  can we get a direct link to SODA cutouts as we had with 
SIAV1 instead of going through DataLink + SODA service descriptor?  This 
could be driven by a RETRIEVEMODE parameter with value = cutout versus 
default archival value.

          +  In that case there is a proposal  made by myself to get the 
opaque cutout URL in the access_url FIELD of the ObsCore table.

          + There is another proposal made by Pat to insert directly in 
the DAP response the SODA service descriptor. The default values of the 
parameters  could be inferred from the DAP query but the user is able to 
change that.

         -> After discussion I think we can have both : the opaque 
cutout SODA url in acces_url FIELD and the SODA service descriptor for 
customizing the cutout.

          + Gregory Dubois-Felsmann came with a first issue. In case we 
are using this RETRIEVEMODE=cutout mode and the service answers with a 
DataLink how should #this be interpreted ?

         -> Although I don't think it is a good idea to use this mode 
with Datalink response in access_url, if we were to do it, I think #this 
would refer to the cutout product and the archived dataproduct from 
which it's extracted would wear a #progenitor semantic flag.

          + Gregory also came with another issue : SIA/DAP only works 
with the SIAV1-like OVERLAP intersect mode which means that the common 
part of the ROI and the spatial coverage of the dataset MAY be small and 
marginal. So the cutout driven from the ROI could be not fitting   the 
user need. So the SIAV1-like "COVERS" intersect mode where the dataset 
fully integrates the ROI could be more appropriate.

               ---> then comes the question should we reintroduce the 
SIAV1 INTERSECT parameter with all (some of) its values ? or should we  
decide that implicitely the RETRIEVE = cutout mode is coupled with 
COVERS mode ? Personally I Tend to prefer the first solution.

            Currently the RETRIEVEMODE section has been commented in the 
Spec latex source because some more discussion is needed. But I Think we 
need it in the future when we all agree.

        b ) Other point, not related to the previous one : Gregory also 
made the comment that the FORMAT parameter in the context of the huge 
DataLink success we experimented in Discovery services generates  
strange results :

               Either we get a real format Mime type or every raw 
displays the  DataLink mime type.

                + So Should FORMAT drive the mime type of either the 
direct link in access_url FIELD or the one of the #this item in DataLink 
? (considering that the choice between direct link to the dataset or 
Datalink url in the access_url is only made by  the data provider)

                    --> Personally I think it's still interesting to 
keep that

                 + Or should we simply drop FORMAT from the DAP spec ? 
(mainly because if we really want several    formats of science data 
this will probably be done by several #this items in a DataLink response).

                       --> most of involved people tend to agree with that.

                     What I did is to change the text of the FORMAT 
section according first option, before everybody decides this has to be 
dropped.


I wish you all a good ADASS conference and a useful IVOA meeting in Malta

Cheers

François