DAL Running Meeting #17 - Datalink

[BONNAREL FRANCOIS]

Le 17/10/2023 à 10:38, Gregory MANTELET a écrit :
> Dear DAL members,
>
> Here is an announcement for an exceptional DAL running meeting, 
> probably the last one before the May Interop.
>
> The goal is to speak about the last on-going issues with the Datalink 
> RFC (mainly, PullRequest #110 
> <https://github.com/ivoa-std/DataLink/pull/110>). Right now, the 
> central question is how to convey the content type of a link document 
> so that it can be easily recognized and used by clients.
>
>     Topic: DAL Running Meeting #17 - Datalink
>
>     Time: Oct 18, 2023 08:00 PM Universal Time UTC
>
>     Join Zoom Meeting
>
>     https://cnrs.zoom.us/j/95304890218?pwd=cFpTM3JZSEZJUktoWUlaM3MzaTl6QT09
>
>     Meeting ID: 953 0489 0218
>
>     Passcode: 63a2d5
>
> Sorry for the last minute organization. We hope that most of 
> interested people can attend anyway. If you can not, but have anyway 
> something to say, do not hesitate to send your comments to James and I 
> so that we can share them with the participants during the meeting. We 
> will also write notes that we will share with all of you after the 
> meeting.
>
> Cheers,
>
> Grégory & James
>
Dear Dalers,

The topic to be discussed is the following (see github PR 
https://github.com/ivoa-std/DataLink/pull/110) :

Should we remove section 3.1.1 or at least change the proposal inside ? 
The subsection in the PR is different from the one in the current draft. 
See attached pdf for the last proposal.

The issue it is supposed to solve (according to me at least) is the 
following :

How do we recognize or build that an URL in VOTable document is pointing 
to a DataLink {links} endpoint or document when we are not in the 
ObsCore context ?

/This issue appeared as early as 2017 (1.5 year after the DataLink1.0 
release) when people started to use DataLink in other contexts (for 
example in catalog of sources) :/

/See for example Shanghai , Santiago and Victoria presentations :/

/https://wiki.ivoa.net/internal/IVOA/InterOpMay2017-DAL/DataLinkDatasetAccessEvolution.pdf 
/

/https://wiki.ivoa.net/internal/IVOA/InterOpOct2017DAL/DataLinkSolution.pdf/

/https://wiki.ivoa.net/internal/IVOA/InterOpMayy2018DAL/dlink-victoria.pdf/

/https://wiki.ivoa.net/internal/IVOA/InterOpMayy2018DAL/DAL-Feedback.pdf/

/In regretted Carlos (RIP) presentation you will find examples of 
DataLink in SCS services/

/I summarized the ideas in one section of an IVOA note in 2018 : 
https://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/20180722/index.html/

/Solutions were also discussed in College Park and Paris meetings as 
well as on github and some DAL running meetings since then /

/https://wiki.ivoa.net/twiki/bin/view/IVOA/DataLink-1_0-Next (Paris 
splinter)/

/https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf/

/https://github.com/ivoa-std/DataLink/issues/29 (and related PRs)/

/Some text was already written in various sections ans appendices of the 
first version of DataLink 1.1 internal draft : 
https://wiki.ivoa.net/internal/IVOA/DataLink-1_0-Next/DataLink.pdf/

//

How can we recognize these URL or DatLink endpoint ?

- If the URL can be built from the content of a column considered as the 
admitted ID value in the DataLink URL then we can use a service descriptor

- If data providers provide a full URL in one of the columns , a LINK 
element can be included in the corresponding FIELD element with 
content_type = "application/x-votable+xml;content=datalink"

// ---> The argument against that is that it is actually not specific to 
DataLink and could be devlopped in VOTable 1.5 or later for all kind of 
content_types.//

I am not against doing that but I think that the mechanism shoud be 
explained in DAataLInk 1.1 anyway in the mean time. If not in main text 
in appendix

- If data providers provide an URL pointing sometimes to DataLink 
{links} sometime to a real dataset or document then we should use a 
second column to provide the format with a ref to the URL column.

The Access.reference and Access.format should be set on the two FIELDS 
as defining the role of these two FIELDS unambiguously.

---> The argument against that is that this could enter in conflict 
other datamodel utypes for the same FIELDS

By looking to current list of utypes in datamodels which provide some I 
don't think such a conflict can happen

(and anyway we still have the GROUP + FIELDREf to duplicate utypes on 
the FIELDS).

Actually the Access class in Obscore with its three attributes 
Reference, format and estimated_size is common with SSA and is 
implicitely there in {links} response itself (FIELDS access_url, 
content_type and content_length)

Access is actually a generic class hich can be imported in several 
datalodels

Cheers

François

//
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20231018/51f87606/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DataLink.pdf
Type: application/pdf
Size: 454033 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20231018/51f87606/attachment-0001.pdf>