SODA-1_0-Next < IVOA

---++ SODA1.0-Next  page.

   * Previous material before May 2020 (most of it common with [[https://wiki.ivoa.net/twiki/bin/view/IVOA/SIAP-2_0-Next][SIA-Next + DAP]])
Old "DAL future" page : https://wiki.ivoa.net/twiki/bin/view/IVOA/DALFuture

IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html

IVOA interop meetings presentation :

Paris : https://wiki.ivoa.net/internal/IVOA/InterOpMay2019DAL/SIA2-SODA-next.pdf

College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/HiPStoFits_Prototype_IVOA.pdf

Victoria : https://wiki.ivoa.net/internal/IVOA/InterOpMayy2018DAL/DAL-Feedback.pdf

   * Additional material since May 2020 (IVOA interop meetings and Running meetings - most of it common with [[https://wiki.ivoa.net/twiki/bin/view/IVOA/SIAP-2_0-Next][SIA-Next + DAP]])
    
We list presentations also look at Notes and discussions.

May 2020 virtual interop : https://wiki.ivoa.net/internal/IVOA/InterOpMay2020DAL/SIA2-SODA-nextPyVO-support.pdf

November 2020 virtual interop : https://wiki.ivoa.net/internal/IVOA/InterOpNov2020DAL/SIA2-SODA-next-status.pdf

January 2021 running meeting #7: https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/IVOA_DAL_RM7_etherpad.txt

February 2021  running meeting #8 : https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/IVOA_DAL_RM8_etherpad.txt

March 2021 running meeting #9 :  https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/IVOA_DAL_RM9_etherpad.txt

May 2021 virtual interop : https://wiki.ivoa.net/internal/IVOA/InterOpMay2021DAL/SIA2-nextDataSetDiscov.pdf

November 2021 virtual interop : https://wiki.ivoa.net/internal/IVOA/InterOpNov2021DAL/minoc-soda-objectstore.pdf

April 2022 virtual interop :  https://wiki.ivoa.net/internal/IVOA/InterOpApr2022DAL/SIA2SODAUpgradesExtendingSIA2toDataSetSAP.pdf

September 2022 running meeting #14 : https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/DAP-SODA-DALRunningmeeting.pdf

October 2022 virtual interop : https://wiki.ivoa.net/internal/IVOA/InterOpApr2022DAL/SIA2SODAUpgradesExtendingSIA2toDataSetSAP.pdf

March 2022 running meeting #15 : https://wiki.ivoa.net/internal/IVOA/IvoaDAL_RunningMeetings/DalRunning10-DL-DAP-SODA.pdf

May 2023 Bologna interop : https://wiki.ivoa.net/internal/IVOA/InterOpMay2023DAL/SIA-DAPSODA.pdf

November 2023 Tucson interop: https://wiki.ivoa.net/internal/IVOA/InterOpNov2023DAL/DAP-SODA-status.pdf 




---+++ SODA-1.0 feedback, issues and proposals

On GitHub: https://github.com/ivoa-std/SODA

   * *ID parameter UCD amendment*

      Point made by IVOA.MarcoMolinaro on 2019-04-18

The [[http://ivoa.net/documents/SODA/20170517/index.html][SODA (version 1.0)]] protocol uses the *ID* parameter to specify opaque identifiers to the dataset or file to be accessed.

Three-factor semantics (Name, UCD, Unit) was mainly thought for interpretation of custom parameters in service descriptors. In the case of a parameter that is part of a standard, like the above !SODA *ID*, the definition of the parameter is unambiguous. However a 3-factor description is still useful for homegeneity and comparison to other parameters.

The UCD specified in the !SODA-embedded 3-factor semantics is reported in the REC text as
<verbatim>meta.ref.url;meta.curation.SODA</verbatim>

This is not a valid UCD both for the, probably, typo of the added *.SODA* part and the fact that meta.curation identifies a *man/organization responsible for the data* as per the UCD vocabulary.

To remedy the situation we propose here to use *meta.id;meta.dataset* instead. This achieves:
   * typo amendment;
   * reference to a dataset rather than an organization;
   * using a UCD referring to an identifier rather than a resource locator;
   * keeping the identifier opaque as required by the specification.

This point has been solved by SODA erratum 1: https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA-1_0-Err-1
   



   * *Wrong VOTAble syntax in polarization example. SODA github issue #1*
ON January the 16th 2020 Alberto Micol discovered :

Page 19 of the SODA standard shows:
<verbatim>

<PARAM name="POL" ucd="meta.code;phys.polarization" datatype="char" arraysize="*" ''value=""> '<DESCRIPTION>Polarization states to be extracted.</DESCRIPTION> <VALUES>

<OPTION>I</OPTION>

<OPTION>V</OPTION> </VALUE>

</PARAM>
</verbatim>

My understanding of the VOTable standard is that the correct way should instead be

(see the sentence

"All three MIN, MAX and OPTION sub-elements store their value corresponding to the minimum, maximum, or ``special value'' in a value attribute."

In the paragraph at: http://www.ivoa.net/documents/VOTable/20191021/REC-VOTable-1.4-20191021.html#sec:values ):
<verbatim>
<PARAM name="POL" ucd="meta.code;phys.polarization" datatype="char" arraysize="*" value=""> <DESCRIPTION>Polarization states to be extracted.</DESCRIPTION> <VALUES>

<OPTION value="I"/>

<OPTION value="V"/>

</VALUE>

</PARAM>
</verbatim>

Alberto was perfectly right !!! This has been fixed with SODA erratum 2 : https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA10Err2

   * *Wrong example for BAND interval MIN and MAX values (github issue  https://github.com/ivoa-std/SODA/issues/2)*

This appeared in a discussion between Alberto Micol and Markus on the dal Mailing list

MIN and MAX cannot be single values as in the example
It should be an array. But an array of what ?

An array of minimal values and an array of maximal values (Markus) ?

An array of minimal length interval and an array of maximal length interval (Alberto) ?

After long discussion (see github issue) this appeared to be an example of MIN/MAX usage for array of values.

By default  the MIN and MAX value will be a single number minimizing or maximizing the whole array values.
 
It will be different foir some xtypes only (for example circle) but not for the xtype=interval we encounter here.

Ths is now explained in SODA erratum 3:  https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA10Err3


   * *pixel cutouts (instead of world coordinates) on all axes are missing (SODA github issue #3)*

Considered for version 1.0 but delayed to stay simple (due to syntax problems)
Asked by CASDA , others
Ranges can be given by SODA service descriptor or computed from ObsCore

Which syntax ?

   * No *possibility to control output WCS by regridding/rebinning exists in SODA. (SODA github issue #4)*

This was possible in SIA1.0 for the spatial axis (only)
could be done by ADDing standard parameters to SODA for
Spatial resolution : SPATRES
Rotation : ROTA
Sky Projection : PROJ
or Alternatively by providing a WCS = (full text of WCS part of FITS header)

Skyview + CDS (SIA on top of Hips2FITS) have this functionality

Should we standardize it ?
And If yes should we extend it to SIA2 in virtual mode (SIA issue #8) ?
Or should we let it as a mixture of SIAP2 and SIAP1 parameters ?

   * *It is not possible to query SODA services by MOC (SODA github issue #5)*

MOC (as well as STMOC, and maybe STEMOC) has proven to be a very efficient way to describe the coverage of data and is used for discovery of data. It has been often discussed and also during last interop that it should be useful to query SODA services by MOC? It should probably be with a new parameter and not via POS considering that it is probably more useful to have STMOC or STEMOC, than spatial MOC alone. This is also valid for SIA of course (SIA Issue #9). Of course, the behaviour for SODA will be very different than the one with SIA. SODA-(ST)MOC will extract a subset matching the (ST)MOC while SIA-MOC will only select datasets intersecting with the MOC. I wonder if this new parameter should not be standardized by DALI

_eventually this has been implemented in the draft with the https://github.com/ivoa-std/SODA/pull/11 PR_

   * *Managing multiple PARAMS queries responses (SODA github issue #6)*

When several of the PARAM queries (POS, BAND, etc...) are multiple we are facing a cartesian product issue: how do we retrieve all these results.
Seems to be easy in async mode which is built to manage multiple results?
But in sync? MEF formats? archive files? VOTable containing pointers?
What about using UPLOAD functionality (DALI, 3.4.5 UPLOAD) for this?

   * *SODA spec doesn't tell us how to provide dataproduct_type transformation (SODA github issue #7)*

First implementations already provide various flavours of cutouts from cubes. Some cutout interface can extract subcubes from a large cube. Some others could create spectra or images (dimension reduction). An idea could be to use the DPTYPE parameter designed for SIAP2 to force this product_type conversion.
This has been discussed for TimeSeries there: http://www.ivoa.net/documents/Notes/TimeSeriesDiscoveryAndAccess/index.html

   * *Format transformation : FITS to png/jpeg, FITS to HiPS, HiPS to FITS etc (SODA github issue #14)*
 
As a server side operation for data access protocol, SODA should provide format transformation :
FITS to png or jpeg looks rather classical.

IVOA.FrancoisBonnarel 2023-11-09

Fits to HiPS (operating HipS generation) or HIPS to fits SHOULD be more and more useful.

   * *Extracting metadata from the dataset (SODA github issue #15)* 

As a first step for access extracting metadata from a dataset such as full fits header or WCS appears to be pretty useful to prepare further more complete access to the data

IVOA.FrancoisBonnarel 2023-11-09

---++++ There are proposed subsections for issues #3, #4, #7, #14, #15 in PR #16



<br /> <!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
pdf	DAP-SODA-status.pdf	r1	manage	479.4 K	2023-11-11 - 22:47	FrancoisBonnarel	DAP and SODA new fatures : why ?
pdf	SODA-20231111.pdf	r1	manage	688.1 K	2023-11-11 - 22:05	FrancoisBonnarel	Proposition of a new version of SODA
pdf	SODA-20240315.pdf	r1	manage	779.3 K	2024-04-17 - 20:53	FrancoisBonnarel	Proposition of a new version of SODA
This topic: IVOA > WebHome > IvoaDAL > SODA-1_0-Next
Topic revision: r4 - 2024-04-17 - FrancoisBonnarel