Datalink service descriptor usage

[Mark Taylor]

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/