International Virtual Observatory Alliance

Difference: DALFuture (4 vs. 5)

Revision 52017-03-07 - FrancoisBonnarel

  META TOPICPARENT 
  name="WebPreferences"  


 <-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

 DAL Future - discussion page 

This 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:
 

 CSP priorities : what is achieved and what is not achieved.
  Feedback from implementation of recently recommended protocols (SIA, DataLink, SODA, TAP new version)
  Multidimensional data access roadmap as established in october 2013 in Hawaï (Fall Interop + ADASS).
 
Properties to consider: 
 Data Type
  Functionalities
  Software Design
  Position in IVOA landscape
 
(see ADASS XXVI DAL poster for reference)

Contribution can take the usual forms: linked pages to topics listed below (or added ones), mailing list follow up from the topics.

(please, when creating a page to link from a topic here, use a DALFutureTopic TWiki name for the new page)

 Data Type 

Add Time Domain ( HIGHEST Scientific priority: see CSP Time Series use cases)
 

 use cases
  ideas for solutions
  attempts and prototypes reports
 

 Functionalities 
 

 Feedback : what is missing/inadequate in current protocols
  Extended metadata (for Cubes and Time Domain)
  Extended server side data services (regridding, deconvolution, etc.)
 

 Software Design 

 Interface design 
 

 Feedback on current interfaces
- META TOPICPARENT
+  name="WebPreferences"
-<
<
+Recently I discovered that  calls to datalink+SODA, outside ObsCore and SIAv2 context are available in VizieR, but also in GAVO. Markus is now using in SIA 1.0 responses (see  http://dc.zah.uni-heidelberg.de/lswscans/res/positions/siap/siap.xml?POS=311.41098458333335,30.723715361111108&SIZE=2.64&FORMAT=image/fits) It sounds reasonable and  I can imagine we wil find more of that in the future. But here there are already fields with  utypes Access.Reference in le SIA mai n part, it is now  difficult/impossible to recognize that a given link will return Datalink or something else.
->
>
+Recently I discovered that  calls to datalink+SODA, outside ObsCore and SIAv2 context are available in VizieR, but also in GAVO. Markus is now using in SIA 1.0 responses (see  http://dc.zah.uni-heidelberg.de/lswscans/res/positions/siap/siap.xml?POS=311.41098458333335,30.723715361111108&SIZE=2.64&FORMAT=image/fits) It sounds reasonable and  I can imagine we wil find more of that in the future. But here there are already fields with  utypes Access.Reference in le SIA mai n part, it is now  difficult/impossible to recognize that a given link will return Datalink or something else.
-<
<
+On the other side, the  Datalink VOTable response doesn't  contain any signature allowing to  recognize a posteriori that it has a  datalink content. That's a pity This would have been harmless and could simplify everything/
->
>
+On the other side, the  Datalink VOTable response doesn't  contain any signature allowing to  recognize a posteriori that it has a  datalink content. That's a pity. This would have been harmless and could simplify everything.
-<
<
+This has direct consequence on  Aladin v10 (or any other cleint), which has the code necessary to perform specific actions for DataLink. , passe à coté de tous ces efforts de standardisation, et se contente d'afficher les résultats, au mieux sous forme d'une VOTable basique (sans coordonnées - donc en fait quasi-inutilisable dans Aladin), ou pire, dans un navigateur Web.
->
>
+This has direct consequence on  Aladin v10 (or any other client), which has the code necessary to perform specific actions for DataLink., cannot benefit from all these standardisation efforts and is limited to display the DataLink result as a simple,VOTable without coordinates , or still worse  in a Web navigator.
-<
<
+Le coté positif, c'est qu'on est proche d'une réelle utilisation et plus uniquement du prototypage, et probablement plus large que ce que vous aviez imaginé à l'origine de datalink (c'est plutôt une bonne chose). Aladin n'est pas loin d'arriver à en faire quelque chose et il y a désormais qq serveurs qui en fournissent. Juste que chacun l'utilise un peu à sa façon et c'est au final galère pour le client de simplement repérer ces liens particuliers. Triste ! Alors qu'il suffirait de presque rien en plus pour s'en sortir.
->
>
+The good point is that we are now close to a real usage and no more in prototyping. THis kind of  usage is probably  wider than what  was imagined initially for datalink  Aladin is close to make something of it there is now a couple of servers which deliver these things. JUST sad that everybody is using it his own way  with the consequency that it remains unusable, while nearly nothing is missing to fix that.
-<
<
+Donc, j'attire l'attention sur ces deux améliorations qui seraient les bienvenues :
->
>
+So, I would recommend two changes:
-<
<
+    Un moyen simple de repérer les liens et surtout de savoir ce qu'il vont retourner
->
>
+   -A simple method to identify the  links and to discover what they are supposed to return
-<
<
+        solution 1: un utype spécifique pour les URL datalink (ex: utype=Access.Reference.Datalink.1.xxx")
        solution 2: un )
    Une signature dans le VOTable, par exemple dans une balise  ou dans un attribut de la ressource
-<
<
+Les solutions que je propose ne sont données qu'à titre d'exemples, il faudrait vérifier que ça colle bien avec les standards existants.
->
>
+        solution 1: a specific utype for datalink URL (ex: utype=Access.Reference.Datalink.1.xxx")
->
>
+        solution 2: an appropriate LINK in the  FIELD definition (ex: LINK content-type="application-stream/votable;datalink" ...)

    -A signature in the VOTable, for example using an INFO tag  or as an attribute of RESOURCE ,  RESOURCE type="result;datalink"...

These "solutions" are just examples to illustrate the idea. WE have to check their validity with regard with the standard evolution. -- PierreFernique - 2017-03-07
  Driving extended functionalities
  Standard definition of custom services
 

 Pushing code to the data 
 

 Science cases
  Attempts and prototypes
 

 Formats and Languages 
 

 Json, PQL, PDL, etc.
  What to use next ?
 

 TAP evolution 
 

 From relational databases to...
  Relaxing ADQL ?
 

 Position in IVOA landscape 

 Merging DAL protocols, HiPS and MOC 
 

 HiPS is also a discovery and access mode: How to marry service approach and HiPS Approach in both ways ?
  Querying services by MOC : is that necessary ?
 

 Data Models 
 

 ObsCore
  DataSet Metadata
  ND-Cube
  SparseCube
  STC
  other...
 

 Updating SCS 

SCS 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

View topic | History: r15 < r14 < r13 < r12 | More topic actions...