Characterising URL columns

[Markus Demleitner]

Hi Mark,

On Wed, Jan 31, 2018 at 03:20:42PM +0000, Mark Taylor wrote:
> 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.

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:

https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:datalinkandtapimplinaladin.pdf

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
http://ivoa.net/documents/UCD1+/20170831/PR-UCDlist-1.3-20170831.pdf).
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 <something>.preview UCD, I floated the idea of
re-using the datalink vocabulary that already has terms for "what's
behind a link": http://www.ivoa.net/rdf/datalink/core (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