Characterising URL columns

[Jesus Salgado]

Hi Mark, Markus,

Yes, I remember Pierre also requested something similar in Strasbourg 
last year.

It looks to me a very similar discussion to the one we had about the 
SAMP MTypes long ago.
At that time we faced the need to declare the kind of product behind a 
link so applications can
subscribe to a certain type of product (like, I -application- am able to 
read generic VOTables,
or Images or Spectra or SSA responses, etc)

It is true that, as far as I know, internet works in a different way 
(the helper application is decided
after invocation using the mime-type, so it is a post-declaration not a 
pre-declaration) but, at least,
to have a vocabulary (as we did for the SAMP MTypes) could be quite 
useful. The use of this vocabulary
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).
At the server side, both things are implementable in my view.

Cheers,
Jesus



On 01/02/18 10:44, Markus Demleitner wrote:
> 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

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


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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20180201/5224affd/attachment-0001.html>