Characterising URL columns

[François Bonnarel]

Dear all,

I gave talks on this topic both in ShanhaI and Santiago meetings, 
following the ASTERICS discussion.

     See 
http://wiki.ivoa.net/internal/IVOA/InterOpOct2017DAL/DataLinkSolution.pdf

for example.

     THe ucd solution has been considered , but it's not really adapeted 
because it's supposed to qualify the content of the FIELD (url) and not 
what is coming out.



     We prefer either the LINK solution exposed in the talk or if there 
is variation of the output the ObsCore-like solution with two Fields and 
utypes.


     I am writing an IVOA note on this and hope to have a decision taken 
for Victoria interop

Cheers
François
Le 01/02/2018 à 11:53, Jesus Salgado a écrit :
> 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.
>