Datalink service descriptor usage

[Marco Molinaro]

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

> 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"/>
>     <PARAM name="accessURL" datatype="char" arraysize="*"
>            value="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?
>
> > 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 +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180206/51b1d93a/attachment-0001.html>