DAP protocol news

[BONNAREL FRANCOIS gmail]

Le 08/11/2024 à 22:26, BONNAREL FRANCOIS gmail a écrit :
> 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
>
>
>