Discussion Page for Datalink Update

Note: this is deprecated in favour of Vocabularies in the VO version 2. See IvoaSemantics for details.

The following is just for documentation of previous efforts, and to preserve the comments for when the terms will be discussed in the new format.

Here are the new terms proposed to enrich the datalink. They should be discussed within the DAL WG. Feel free to suggest your terms here and provide feedback after usage , as data providers and client users.

Here below is a template for suggesting new terms .

you can copy this part and add your new requirement for terms .

Discussion paragraph :

-- MireilleLouys - 2018-05-31

For example 2: GAIA DR2 source : links to associated TimeSeries with semantics field "associated_data:timeseries" -- I don't think this reflects enough the type of data, it is timeseries, but of what? photometry (light-curves), but can also be a time series of spectra or timeseries of radial velocities in the case of Gaia DR3. This means that there is a need of specialisation of the term timeseries. Same case is true for the case of missions providing timeseries of images -- AdaNebot - 2019-10-08.

If the type of the pointed dataset is expressed this way, this semantics field will help the client designer to send the link for the target dataset to an appropriate tool , via samp for instance.

All links in DataLink that are not #this are implicitly "associated". The proposed structure here seems to be drifting away from vocabulary into something else. Finally, the idea seems to sanction using terms from the ObsCore standard but not very explicitly or in any machine-readable way (that could be partially improved by defining an ObsCore/dataproduct_type vocabulary). There is a lot here that needs discussion. -- PatrickDowler - 2019-05-08

Discussion paragraph :

-- CarlosRodrigo (2019-02-25)

I think this would be nice and useful to link one (or several) bibliografic reference(s) to the data.

In CAOM we have a way to flag artifacts that become links in DataLink and we use "info" for this kind of thing. There is a fair bit of commonality between DataLink and the CAOM vocabulary (historical reasons) and I'd be happy to see them come closer together if possible. See http://www.opencadc.org/caom2/ProductType/ -- PatrickDowler - 2019-05-08

Discussion paragraph :

This seems useful and I could easily use this in the CADC DataLink service. -- PatrickDowler - 2019-05-08

Discussion paragraph :

Replacing the semantics of the link that was to be generated by "fault" duplicates the fact that an error was already signalled by the presence of an error_message (instead of an access_url or service_def). There are numerous scenarios where the result would be ambiguous and hard for clients to use. For example, if the client wants to download data files "this" and there is a link marked "fault" the client cannot tell if they care about that failure. It could be a failure to find a preview or a service and have nothing to do with the data files. So, DataLink-1.0 design already covers the signalling of failure to create a link and this will break things. -- PatrickDowler - 2019-05-08

Discussion paragraph : -- FrancoisBonnarel - 2019-02-06 We may wonder if this is not redondant (or partially redondant) with #derivation.

Agree that this sounds like #derivation. -- PatrickDowler - 2019-05-08

Discussion paragraph :

This is something I have also run into but never solved because it is really a relation between a link and another link and not the link to the "identified thing" (with the ID). For example, say you have a DataLink output for one ID with two #this links and a #preview link and then you add a #alt link. Is it an alternative to the preview? One of the #this links? Both of the #this links? The possibly different content_type values might help or might not and I agree they don't say enough on their own (e.g. two #preview with different content_type are not obviously alternatives). So, I like this idea and there are use cases but it is too complex for #alt by itself. -- PatrickDowler - 2019-05-08