<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Mark, Markus,<br>
    <br>
    Yes, I remember Pierre also requested something similar in
    Strasbourg last year.<br>
    <br>
    It looks to me a very similar discussion to the one we had about the
    SAMP MTypes long ago. <br>
    At that time we faced the need to declare the kind of product behind
    a link so applications can <br>
    subscribe to a certain type of product (like, I -application- am
    able to read generic VOTables, <br>
    or Images or Spectra or SSA responses, etc)<br>
    <br>
    It is true that, as far as I know, internet works in a different way
    (the helper application is decided<br>
    after invocation using the mime-type, so it is a post-declaration
    not a pre-declaration) but, at least, <br>
    to have a vocabulary (as we did for the SAMP MTypes) could be quite
    useful. The use of this vocabulary <br>
    could be decided later,... either by adding this qualifier into the
    content-type mime, e.g.
    "application/x-votable+xml;content=spectrum.load.ssa-generic" or
    inside a UCD for a pre-declaration (or both).<br>
    At the server side, both things are implementable in my view.<br>
    <br>
    Cheers,<br>
    Jesus<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 01/02/18 10:44, Markus Demleitner
      wrote:<br>
    </div>
    <blockquote cite="mid:20180201094429.tm42mct4fjguponl@victor"
      type="cite">
      <pre wrap="">Hi Mark,

On Wed, Jan 31, 2018 at 03:20:42PM +0000, Mark Taylor wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">I've got a question about making sense of URL-bearing columns
in generic tables.  I don't think there is currently a good answer
to it, but I thought it was worth checking with the experts.

The question is, is there any way to determine from a generic
table what kind of resource lurks at the end of URLs in
a given column?

For instance, a number of services return tables with columns
containing DataLink URLs, that is results corresponding to
the {links} response described in section 3 of RED-DataLink-1.0,
and which are properly described by the Content-TypeMIME
"application/x-votable+xml;content=datalink".
If the (human or machine) reader of the table in question knows
that the column is supposed to point to DataLink tables,
then she can open the URL with some kind of DataLink client.
But in general I don't know how to tell that a given column
contains DataLink responses, or images, or spectra, or what.

The same thing applies to other content types as well.
</pre>
      </blockquote>
      <pre wrap="">
This has been discussed to some degree at the 2017 Strasbourg
ASTERICS Tech Forum.  I'm not sure if there's a record of the
discussion, but there is at least Chaitra's slides on her
datalink implementation experience that started the discussion:

<a class="moz-txt-link-freetext" href="https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:datalinkandtapimplinaladin.pdf">https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:datalinkandtapimplinaladin.pdf</a>

Somewhat relatedly at the Banff interop, I had asked for a UCD to
identify columns containing URLs to previews, and in the 1.3 UCD
list, my wish has been granted (it's on page 10 of
<a class="moz-txt-link-freetext" href="http://ivoa.net/documents/UCD1+/20170831/PR-UCDlist-1.3-20170831.pdf">http://ivoa.net/documents/UCD1+/20170831/PR-UCDlist-1.3-20170831.pdf</a>).
The intention is that clients can pull up such previews as (say) an
activation action when rows have a FIELD with a
meta.ref.url;meta.preview UCD.

When I proposed the &lt;something&gt;.preview UCD, I floated the idea of
re-using the datalink vocabulary that already has terms for "what's
behind a link": <a class="moz-txt-link-freetext" href="http://www.ivoa.net/rdf/datalink/core">http://www.ivoa.net/rdf/datalink/core</a> (which, not
coincidentally, already has a term "preview").  Unfortunately, that's
not really a match to your and Chaitra's use cases, as I'm pretty
sure there shouldn't be a #datalink term in the vocabulary.  I
think I'd be much more interested in what *relation* that other
datalink has to the current dataset than that it is a datalink
document as such (which in datalink I can tell from the media type).
Hm.

Back in Banff my suggestion had been to add a, say, "data" branch to
the UCD list and say "for the child terms, check datalink core".
Since it now turns out that even if we had that it probably wouldn't
solve your problem, it's probably just as well that we didn't go down
that road.

So, in a pragmatic spirit, my suggestion would be to add a
"meta.datalink" UCD atom.

Since both Chaitra and you missed a thing like that when implementing
datalink, I'd take it as a fairly solid indicator that the use case
is at least as strong as for the preview, and even if we might wish a
more complete, datalink-style annotation with a separate annotation
for a semantic relationahip and a media type (VO-DML would work great
for that!), the simple UCD would give us something that works
essentially immediately.  Which is kinda nice.

           -- Markus
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Jesus Salgado
ESA Astronomy Archives Technical Lead
QUASAR Science Resources for European Space Agency (ESA)

ESAC Science Data Centre (ESDC), SCI-OPD
Data and Engineering Division, SCI-OP
Operations Department, Directorate of Science
European Space Astronomy Centre (ESAC)
European Space Agency (ESA)

ESAC - ESA Science Astronomy Centre
Camino Bajo del Castillo s/n
Urb. Villafranca del Castillo
28692 Villanueva de la Canada - Madrid        Tel: +34 91 813 12 71
SPAIN                                         Fax: +34 91 813 13 08
------------------------------------------------------------------- </pre>
  <PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

</PRE></body>
</html>