Datalink vs link - open discussion
Laurent Michel
laurent.michel at astro.unistra.fr
Wed Nov 20 18:16:16 CET 2019
Le 19/11/2019 à 16:57, Patrick Dowler a écrit :
>
> Thanks Pierre - this has a lot of great analysis and use cases that DataLink can/should address. I think we will need to come up
> with a coherent design to add support for fragments and RESTful path elements to the current query param support - especially
> since they can in principle all play together (eg in VOSpace one uses both path and query params and that is a common pattern,
> you showed using query params and fragment, and I can easily see using path, query, and fragment making sense in some context).
>
> I will try to condense this into a single github issue with reference to this mail thread. We can continue broad discussion here.
This tighly related to the "enpoint URL templating" issue.
Both dataLink and LINKS have to be able to build URLs from data read in the result document they belong to.
<LINKS> proposes a syntax that is rather classical, I proposed to make something derived from RFC6570, mainly to be in the main
stream (e.g. json schema), but the choice of the syntax is not critical to me as long as it covers what we need without
introducing useless complexity. I follow MD on this point.
On the other hand, I'm conveinced that such a feature will be very valuable for DataLink .
Cheers
LM
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>
>
> On Fri, 15 Nov 2019 at 03:04, Pierre Fernique <Pierre.Fernique at astro.unistra.fr <mailto:Pierre.Fernique at astro.unistra.fr>> wrote:
>
> Dear Datalink contributors and Apps members
>
> /This is an open discussion concerning DATALINK vs LINK usage.//
> /
>
> I looked in detail at the new Datalink document <https://wiki.ivoa.net/internal/IVOA/DataLink-1_0-Next/DataLink.pdf> and I
> tried to evaluate the potential impact on the current use of the classic VOTable LINK. Specifically, I tried to write the
> VOTable corresponding to a basic Simbad result, containing two direct links, one to get the basic Simbad result page, the
> other to list the associated bib references (this is a real/live example since 18 years - the expected result in Aladin is
> provided at the end of this mail).
>
> Currently, I have to admit that I remain a little bit dubious about the complexity of the Datalink solution to implement one
> or more direct simple links.
> In any case, here are the results of my effort:
>
> *1) Method using VOTable LINK (available from v1.0 and following), using templating convention ($ {columnName} ... described
> in VOTable appendices)**
> **
> */We can easily describe in one XML line the 4 essential elements of a link: 1-how is built the link, 2-where it must be
> placed, 3-what is its associated text, 4-what it will return.////The knowledge of the links is placed at the beginning of
> the VOTable stream which will simplify the life of the clients/
>
> <VOTABLE><RESOURCE><TABLE>
> <FIELD ID="MAIN_ID" name="MAIN_ID" ucd="meta.id <http://meta.id>;meta.main" datatype="char" arraysize="*" width="22">
> <DESCRIPTION>Main identifier for an object</DESCRIPTION>
> * <LINK contentType="text/html" href="http://simbad.u-strasbg.fr/simbad/sim-id?Ident=${MAIN_ID}&NbIdent=1"
> <http://simbad.u-strasbg.fr/simbad/sim-id?Ident=$%7BMAIN_ID%7D&NbIdent=1>/>**
> * </FIELD>
> ...
> <FIELD ID="BIBLIST" name="BIBLIST" ucd="meta.bib" datatype="short" width="4">
> <DESCRIPTION>List of Bibcodes</DESCRIPTION>
> * <LINK ***contentType="text/html" title*****="${BIBLIST} references for ${MAIN_ID}"
> * *href="http://simbad.u-strasbg.fr/simbad/sim-id?bibdisplay=refsum&Ident=${MAIN_ID}#lab_bib"
> <http://simbad.u-strasbg.fr/simbad/sim-id?bibdisplay=refsum&Ident=$%7BMAIN_ID%7D#lab_bib>/>
> * </FIELD>
> ...
> <DATA><TABLEDATA>
> <TR>
> <TD>[VV98] J084822.3+274553</TD>
> ...
> <<TD>19</TD>
> </TR>
> ...
> </TABLEDATA></DATA></RESOURCE></VOTABLE>
>
>
> *2) The same thing expressed in Datalink 1.1*(templating alternative discussed in Datalink author groups (see Datalink
> github <https://github.com/ivoa-std/datalink/>) is presented below)***
> *
>
> **/We can describe via additional RESOURCES one or more links: 1-we know how to build it but with limitations (everything
> before the ? is constant and only key=value parameters are possible), 2- wedo not know where the link should be placed (on
> which column), 3- we can describe the associated text, 4- we can describe the type of data returned. The knowledge of the
> links is given at the end of the stream which can/will force the client to buffer. Finally the client must check that these
> services descriptors do not use a VO standardID or multiple choice parameters (OPTION).///
>
> //
>
> <VOTABLE>*<RESOURCE>*<RESOURCE *type="result"*><TABLE>
> <FIELD ID="MAIN_ID" name="MAIN_ID" ucd="meta.id <http://meta.id>;meta.main" datatype="char" arraysize="*" width="22">
> <DESCRIPTION>Main identifier for an object</DESCRIPTION>
> </FIELD>
> ...
> <FIELD ID="BIBLIST" name="BIBLIST" ucd="meta.bib" datatype="short" width="4">
> <DESCRIPTION>List of Bibcodes</DESCRIPTION>
> </FIELD>
> ...
> <DATA><TABLEDATA>
> <TR>
> <TD>[VV98] J084822.3+274553</TD>
> ...
> <<TD>19</TD>
> </TR>
> ...
> </TABLEDATA></DATA></RESOURCE>
>
> <RESOURCE type="meta" utype="adhoc:service" name="SimbadMainPage">
> <DESCRIPTION>Link to Simbad main page</DESCRIPTION>
> <PARAM name="accessURL" datatype="char" arraysize="*" value="http://simbad.u-strasbg.fr/simbad/sim-id"
> <http://simbad.u-strasbg.fr/simbad/sim-id>/>
> <PARAM name="contentType" datatype="char" arraysize="*" value="text/html"/>
> <GROUP name="inputParams">
> <PARAM name="Ident" datatype="char" arraysize="*" ref="MAIN_ID"/>
> <PARAM name="NbIdent" datatype="char" arraysize="*" value="1"/>
> </GROUP>
> </RESOURCE>
>
> <RESOURCE type="meta" utype="adhoc:service" name="SimbadBiblio">
> <DESCRIPTION>Link to Simbad biblio</DESCRIPTION>
> <PARAM name="accessURL" datatype="char" arraysize="*" value="http://simbad.u-strasbg.fr/simbad/sim-id"
> <http://simbad.u-strasbg.fr/simbad/sim-id>/>
> <PARAM name="contentType" datatype="char" arraysize="*" value="text/html"/>
> <GROUP name="inputParams">
> <PARAM name="*bibdisplay*" datatype="char" arraysize="*" value="*refsum*"/>
> <PARAM name="Ident" datatype="char" arraysize="*" ref="MAIN_ID"/>
> <!-- Not possible to describe the end of the URL : *#lab_bib* -->
> </GROUP>
> </RESOURCE>
>
> </RESOURCE>
> </VOTABLE>
>
>
> Or via the alternative templating possibility proposed in 1.1 datalink discussion (only the last link description is
> provided - thanks to François Bonnarel for his help)*
> *
>
> ...
> <RESOURCE type="meta" utype="adhoc:service" name="SimbadBiblio">
> <DESCRIPTION>Link to Simbad biblio</DESCRIPTION>
> <PARAM name="accessURL" datatype="char" arraysize="*" value="http://simbad.u-strasbg.fr/simbad/sim-id"
> <http://simbad.u-strasbg.fr/simbad/sim-id>/>
> <PARAM name="contentType" datatype="char" arraysize="*" value="text/html"/>
> <GROUP name="inputParams">
> <PARAM name="*bibdisplay*" datatype="char" arraysize="*" value="*refsum*"/>
> </GROUP>
> <GROUP name="endpoints" >
> <PARAM name="identifier" utype="template" datatype="char" arraysize="*" ucd="meta.code" value=
> "Ident={?MAIN_ID*}#lab_bib />
> </GROUP>
> </RESOURCE>
> ...
>
>
> At the end, and in the context of basic direct links, from a LINK solution in one code line without using any additional
> dedicated structure, we had to deploy a solution with additional RESOURCES, nested, structured, 10 to 15 times more
> verbose, but who can not do the job completely. There are two main issues in addition of the complexity :
>
> * There is no possibility in Datalink to say that this link in associated to this value of this row, on this other link to
> this other value. Datalink is only row oriented.
> * Datalink can only describe key=value parameters URL implying constant values for the root URL (no REST URLs for instance)
>
> My reaction is it will not be easy to sell this Datalink alternative, and the risk of writing/parsing errors will be
> proportionate to this complexity.
>
> As far as I understood and after my exercise, *I would tend to think that Datalink can not/should not replace the use of
> basic LINK - with or without templating - and probably each method will keep its niche:****the basic LINK for direct links
> associated with the values of a column, the Datalink for lists of links with descriptions, SODA and more for each line
> result.* I'm afraid that if we do not keep the classic LINK usage, we'll just see Aladin Desktop's links disappear (as it
> was occured for the NED results for example).
>
> Feel free to react to this open discussion, maybe only is the DAL mailing list for avoiding dupplications.
>
> Best regards
> Pierre Fernique
>
> ---
>
> PS. FYI, here is the list of clients and data providers who currently use - to my knowledge - the LINK (with or without
> templating). To my knowledge, none of them has had any inclination in these last 4 years to move to Datalink1.0 alternative
> for basic direct links (except Aladin Desktop).
>
> *Clients *(clearly CDS oriented)*:**
> *
>
> 1. Aladin Desktop (Java)
> 2. CDS portal (JS)
> 3. Simbad Simplay (Flash)
>
> *Data base services using VOTable LINK facility with templating (${columnName} variables in the LINK URL template)**
> *
>
> 1. CDS Simbad
> 2. CDS VizieR
> 3. CDS photometric service (VizieR SED)
> 4. IMCCE Skybot
> 5. LEDA Hypercat
> 6. All HiPS providers using progenitor facility (for accessing to the original images)
>
> *Some examples (in use):*
>
> 1) Simbad:
> http://alasky.u-strasbg.fr/cgi/simbad-flat/simbad-cs.py?target=08+47+18.60770+%2B26+53+20.1212&SR=54.63&format=votable-tsv&SRUNIT=arcmin&SORTBY=nbref
>
> <FIELD ID="BIBLIST" name="BIBLIST" ucd="meta.bib" datatype="short" width="4"><DESCRIPTION>List of
> Bibcodes</DESCRIPTION><LINK value="ref (${BIBLIST})"
> href="http://simbad.u-strasbg.fr/simbad/sim-id?bibdisplay=refsum&Ident=${MAIN_ID}#lab_bib"
> <http://simbad.u-strasbg.fr/simbad/sim-id?bibdisplay=refsum&Ident=$%7BMAIN_ID%7D#lab_bib>/></FIELD>
>
> 2) VizieR SED: http://vizier.u-strasbg.fr/viz-bin/sed?-c=04+59+02.70698+%2B21+44+11.2538&-c.rs=5.0
>
> <FIELD name="_tabname" ucd="meta.table" datatype="char" arraysize="32*">
> <DESCRIPTION>Table name</DESCRIPTION>
> <LINK href="http://vizier.u-strasbg.fr/viz-bin/VizieR-5?-info=XML&-out.add=.&-source=${_tabname}&${_ID}"
> <http://vizier.u-strasbg.fr/viz-bin/VizieR-5?-info=XML&-out.add=.&-source=$%7B_tabname%7D&$%7B_ID%7D>/>
> </FIELD>
> ...
> <FIELD ID="sed_filter" name="_sed_filter" ucd="meta.id <http://meta.id>;instr.filter" unit="" datatype="char"
> width="32" arraysize="32*">
> <DESCRIPTION>Filter designation, in the form photoSystem:filterName; a designation starting by ':=' is an assumed
> monochromatic point; this column is empty when the frequency is specified for each data point.</DESCRIPTION>
> <LINK href="http://cdsarc.u-strasbg.fr/viz-bin/metafilter?${_sed_filter}"
> <http://cdsarc.u-strasbg.fr/viz-bin/metafilter?$%7B_sed_filter%7D>/>
> </FIELD>
>
>
> 3) VizieR:
> vizier.u-strasbg.fr/viz-bin/votable?-source=I%2F284%2Fout&-c=05+34+31.93920+%2B22+00+52.2000&-out.add=_RAJ,_DEJ&-oc.form=dm&-out.meta=DhuL&-out.max=999999&-c.rm=23.82&-out=_VizieR,*Mime(image/fits),*&-mime=TSV
> <http://vizier.u-strasbg.fr/viz-bin/votable?-source=I%2F284%2Fout&-c=05+34+31.93920+%2B22+00+52.2000&-out.add=_RAJ,_DEJ&-oc.form=dm&-out.meta=DhuL&-out.max=999999&-c.rm=23.82&-out=_VizieR,*Mime(image/fits),*&-mime=TSV>
>
> <FIELD name="_V" ucd="meta.ref" datatype="char" arraysize="6">
> <DESCRIPTION>Link to the VizieR record with all details</DESCRIPTION>
> <LINK
> href="http://vizier.u-strasbg.fr/viz-bin/VizieR-5?-info=XML&-out.add=.&-source=I/284/out&-c=${RAJ2000}${DEJ2000}&-c.eq=J2000.000&-c.rs=0.5"
> <http://vizier.u-strasbg.fr/viz-bin/VizieR-5?-info=XML&-out.add=.&-source=I/284/out&-c=$%7BRAJ2000%7D$%7BDEJ2000%7D&-c.eq=J2000.000&-c.rs=0.5>/>
> </FIELD>
>
> 4) HiPS - HST B example: http://alasky.u-strasbg.fr/HST-hips/filter_B_hips/HpxFinder/metadata.xml
>
> <FIELD name="DATASET" datatype="char" arraysize="*"><LINK
> href="http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/AdvancedSearch/?Observation.observationID=${DATASET}"
> <http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/AdvancedSearch/?Observation.observationID=$%7BDATASET%7D> title="Full
> metainfo"/></FIELD>
>
> 5) IMCCE:
> http://vo.imcce.fr/webservices/skybot/skybotconesearch_query.php?-ep=2019-11-11&-ra=131.82753208333332&-dec=26.888922555555556&-size=109.26,109.26&-mime=votable&-out=basic&-loc=500&-search=Asteroids+and+Planets&-filter=120+arcsec&-from=Aladin
>
> <vot:FIELD ID="name" name="Name" ucd="meta.id <http://meta.id>;meta.main" datatype="char"
> arraysize="32"><vot:DESCRIPTION>Solar system object name</vot:DESCRIPTION><vot:LINK href="${ExternalLink}"/></vot:FIELD>
>
> 6) LEDA: http://leda.univ-lyon1.fr/leda/leda-aladin.cgi?type=astrores&ra=210.80242917&de=54.34875&width=1.4&height=1.4
>
> <FIELD name="Designation" ucd="IDENT" datatype="A" width="21">
> <DESCRIPTION>LEDA designation</DESCRIPTION>
> <LINK
> href="http://leda.univ-lyon1.fr/leda/querybyname.cgi?objname=${Designation}&donnee=mean&Submit=Submit"
> <http://leda.univ-lyon1.fr/leda/querybyname.cgi?objname=$%7BDesignation%7D&donnee=mean&Submit=Submit>>${Designation}</LINK>
> </FIELD>
>
>
> *Résultats à obtenir dans Aladin Desktop pour les deux liens directs Simbad**
> *
>
>
--
jesuischarlie/Tunis/Paris/Bruxelles/Berlin
Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
More information about the dal
mailing list