<--
DAL Future - discussion pageThis page is meant to gather opinions, feedback and proposals for DAL future (see Trieste 2016 Fall Interop presentation). The underlying question is what will be the main evolution of the DAL protocols in a near future (SIA, SODA, TAP, ADQL, DataLink, etc.). The main drivers are:
Data TypeAdd Time Domain ( HIGHEST Scientific priority: see CSP Time Series use cases)
Functionalities
Software DesignInterface design
| ||||||||
Added: | ||||||||
> > | Current DAL situation for dataset discovery and access We have a core of 4 protocols SIAV2, ObsTAP, DataLink and SODA ? ObsTAP is controled via ADQL and its response is an Obszcore table. SIAV2 is a parameter driven service, doesn't requite TAP infrastructure . In some respects it is a PQL ObsTAP (actually parameter language allows more evolution towards virtual data) DataSets can be searched by any of the Spatial, time, band and polarization criteria. Access is managed by SODA / currently only doing cutouts on ND cubes. DataLink provides gluing facility between all these protocols responses and with other services Older protocol "lost "functionalities SSA allows to discover spectra by Spatial and BAND positions / response in discovery mo de standardized with SSA response (some kind of pre-Obscore) SIAV1.0 allows to discover anything with a 2D signature on space, but only Spatial axes are standardized. SSA and mostly SIAV1 have a "virtual data discovery mode" IN that case the retrieval is performing "Server side operations for data access" Possible evolution to extend the functionalities of the new protocol and tackle the TimeSeries CSP priority SIAV2 interface could allow discovery of TimeSeries and Spectra with little extensions (time frequencies characterisation for example) Some functionalities available in SSA/SIAV1.0 have to be added to SIAV2 Virtual data discovery : Basically the service arbitrates the discovery query parameters and propose a matching SODA URL. Specially usefull for TimeSeries where many time the TimeSeries is built from the data content. We could extend the parameters in ObsCore to tackle TimeSeries and spectra, add input paramaters to constrain that and add virtual data functionality This will be both an extension of SIAV2.0 and a new overall "DataSet SODA = add spectra and Time Series functionalities Provide Extended metadata consistent with NDcube DM : is this a work for SIAV2 or for SODA 1.1 -- FrancoisBonnarel - 2017-05-15 | |||||||
Pushing code to the data
Formats and Languages
TAP evolution
Position in IVOA landscapeMerging DAL protocols, HiPS and MOC
Data Models
Updating SCSSCS still requires VOTable 1.1 and has some other quirks that makes it needlessly incompatible with the rest of the DAL landscape (in particular, it's totally DALI-incompatible). We should figure out how we can evolve it to be less odd with minimal disruption to existing services and clients (e.g., relaxing VOTable requirements, support for DALI MAXREC, RESPONSEFORMAT, metadata discovery). -- MarkusDemleitner - 2017-03-01 | ||||||||
Added: | ||||||||
> > | In SCS there are three things which are causing problems for me: 1) The UCD's that are required by the spec are rather outdated. 2) VOTable is required to be 1.0 or 1.1, which is far behind the current 1.3. 3) It requires a column with ucd="ID_MAIN". In UCD1+, this would be meta.id. We do not always have a column with that ucd, but we do have one with ucd=meta.record. So I would propose that the table must have one of meta.id or meta.record. -- WalterLandry - 2017-04-15 |