Datalink service descriptor usage

[François Bonnarel]

Hi, Mark, Marco, Markus, DAL

I think Mark is right : managing service descriptors in Simple services 
or TAP responses and in {links} response is nowadays different, as also 
confirmed by Markus.

Another solution which  was considered and pushed by some of the authors 
and eventually not retained in the first version, would have been to let 
"dynamical links" (--> services) autodescribe in the context of a 
dataset.  IN these conditions {links} responses rows would look all the 
same (URLs) and services root URL invocation will return the appropriate 
service descriptor prefilled for a given data set.

This would make structure and  interpretation of {links} resources simpler.


More below.


Le 06/02/2018 à 11:11, Marco Molinaro a écrit :
> Hi Mark, all,
> you may be right, and I may be confused by my
> biased idea that datalink is meant to having
> proper ID's in the originating discovery response
> data table to attach to.
>
> Thus, that would really mean two separate
> datalink consumers for a client app, one for
> services described directly in the discovery
> response (your case 2) and one for the
> links-response solutions (case 1).
>
> I'm wondering, however, if also in case 1
> there's a way to allow the adhoc:service
> on a  per row basis.
>
> Cheers,
>      Marco
>
> 2018-02-05 11:48 GMT+01:00 Mark Taylor <m.b.taylor at bristol.ac.uk 
> <mailto:m.b.taylor at bristol.ac.uk>>:
>
>     Marco,
>
>     thanks for your response.
>
>     On Sun, 4 Feb 2018, Marco Molinaro wrote:
>
>     > > Section 4 of the DataLink document describes Service Descriptors.
>     > > These are RESOURCE elements in VOTable documents containing
>     > > information about external services that can be invoked in
>     > > a way that is relevant to the data in a results table contained
>     > > within the same VOTable document.
>     > >
>     > > As I understand it, there are two separate ways these service
>     > > descriptors can be used.
>     > >
>     > >   1. A {links}-response table (as described in DataLink section 3)
>     > >      may refer to a specific Service Descriptor by giving its ID
>     > >      in the service_def column.
>     > >
>     > >   2. Any VOTable is allowed to include Service Descriptor
>     resources,
>     > >      as made explicit in paragraphs 2 and 3 of DataLink section 4.
>     > >      Such service descriptors will presumably have at least some
>     > >      input parameters that take their values from the results
>     table.
>     > >
>     > > In case 2, the service descriptor effectively defines a different
>     > > (full or partial) service invocation for every row of the
>     results table.
>     > > In case 1 however, such invocations are only defined for those
>     rows
>     > > in which the service_def column names the descriptor in question.
>     > >
>     >
>     > I agree, but I would say that your description of case 2
>     > may fail if no DatasetID is set in a row. But that's probably
>     > a borderline case.
>
>     Is that right?  Section 4 says this:
>
>        "Here we describe how to construct a resource that describes a
>         service and add it to a VOTable document. The mechanism is
>         general and can be used wherever a VOTable document is created."
>
>     From that I take that this mechanism is not tied to the
>     {links}-response
>     format or to provision of a DatasetID.  So for instance you could
>     write a VOTable that defines a Cone Search invocation for each row,
>     like this:
>
>       <VOTABLE>
>       <RESOURCE type="results">
>         <TABLE>
>           <FIELD name="RAJ2000" datatype="double" ID="col_ra"/>
>           <FIELD name="DEJ2000" datatype="double" ID="col_dec"/>
>           <DATA>
>             <TABLEDATA>
>     <TR><TD>83.50</TD><TD>22.01</TD></TR>
>     <TR><TD>323.25</TD><TD>-0.81</TD></TR>
>             </TABLEDATA>
>           </DATA>
>         </TABLE>
>       </RESOURCE>
>       <RESOURCE type="meta" utype="adhoc:service">
>         <PARAM name="standardID" datatype="char" arraysize="*"
>                value="ivo://ivoa.net/std/ConeSearch
>     <http://ivoa.net/std/ConeSearch>"/>
>         <PARAM name="accessURL" datatype="char" arraysize="*"
>                value="http://cda.harvard.edu/cxcscs/coneSearch
>     <http://cda.harvard.edu/cxcscs/coneSearch>"/>
>         <GROUP name="inputParams">
>           <PARAM name="RA"  datatype="char" arraysize="*" value=""
>     ref="col_ra"/>
>           <PARAM name="DEC" datatype="char" arraysize="*" value=""
>     ref="col_dec"/>
>           <PARAM name="SR"  datatype="char" arraysize="1" value="1"/>
>         </GROUP>
>       </RESOURCE>
>       </VOTABLE>
>
>     Or is that not the intention?
>

Mark , this example is perfectly right and was the intention of all the 
authors.

Cheers
François
>
>
>     > The distinction between 1 and 2 being only on where the
>     > service descriptor adhoc:service sits: directly on the
>     > results of discovery, in a further (multi)-access enabling
>     > document.
>
>     If the example above is correct use of the Service Descriptor
>     construct, then the difference is greater: in case 2 the service
>     descriptor(s) can be applied to all rows of the results table,
>     but in case 1 only those rows with an appropriate service_def
>     value define such invocations.
>
>     > * - happy you sent this email 'cause you forced him
>     > into a deeper look in Datalnk
>
>     I'm pleased that I could bring a little joy into your life!
>
>     Mark
>
>     --
>     Mark Taylor   Astronomical Programmer   Physics, Bristol
>     University, UK
>     m.b.taylor at bris.ac.uk <mailto:m.b.taylor at bris.ac.uk>
>     +44-117-9288776 <tel:%2B44-117-9288776>
>     http://www.star.bris.ac.uk/~mbt/ <http://www.star.bris.ac.uk/%7Embt/>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180207/102474b5/attachment-0001.html>