DataLink-1.0 NextThis topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification. Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.Possible ErrataThe following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.
Implementation feedback from TOPCATThese points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.
Proposed FeaturesSuggestion for revision of DataLink-1.0, in terms of new features. Notes by MarcoMolinaro and FrancoisBonnarel from a splinter session held during Paris Interop meeting on May the 16th, 5-30:7 PM Around 15 IVOA partners discussed DataLink evolution proposals Among those people were Pat Dowler, Markus Demleitner, Laurent Michel, Mark Taylor, Tom McGlynn, Alberto Micol, Marco Molinaro, Anais Oberto, Gregory Mantelet, François Bonnarel Sorry for people we forgot. Please add your name above. The starting points were the feedback discussions we had during the last years in the DAL working group. The main issues have been summarized in this IVOA note : http://www.ivoa.net/documents/Notes/RecentDALProtocolsFeedback/index.html A proposal for changes has been presented at College Park : https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/DataLink-next.pdf | ||||||||
Changed: | ||||||||
< < | An attempt for a new draft is now available here | |||||||
> > | An attempt for a new draft is now available here | |||||||
These are the changes which have been discussed (the items numbers are those used in the College Park presentation):
1 and 2) - Extension of the scope of DataLink {links} response to items which are different from datasets discovered in whatever way.
This point comes from data providers willing to use DataLink for attaching datasets or additional information to sources in catalogues or other items in service responses. This new usage has to be reflected in introduction and use cases.
3 ) - The extension of the scope makes the linkage to {links} response occur in contexts not planned by original spec. Beside the acces.format/access.refrence couple of FIELDS/PARAMs which can be used in bsCore-ike contexts, the only previous propsoed genreic solution to adress this response in a VOTable was to use a service descriptor RESOURCE to define the url to the {links} service with a refrence for the ID param. there is a proposal to also use the LINK element inside a FIELD with a new content-type = "" where the FIEL directly contains the url to the {links} endpoint/. A new section for taht seems too much. This will come in an appendix
4 ) - The dataLink {links} response can be discovered and used outside a service query. IT can be useful to recognize its nature of {links} response by an INFO tag.
5 ) - Allowing fragments in the access_url seems to be a sensible thing to do
considering multi-extension FITS, tar files, HDF5 and other structured data
available. Issues to be solved are however related to providing the client
enough information to consume this solution. Prototyping on direct use cases
could help. It is questionable if The links response is used to get one raw with a specific semantics, description for each subpart but only retrievable or if each subpart can be retrieved via an extension of SODA. (See SODA 1.1)
6 ) - The "description" column in the {links} response needs to be a SHOULD to properly label the various links made available, specially when they share the same semantics. Pretty useful for the end user of a {links} response table.
7 ) - There is an obvious need for new vocabulary. See: https://wiki.ivoa.net/twiki/bin/view/IVOA/UpdateDatalinkTerms
But the semantics/vocabulary discussion is detached from the DataLink specification revision. I.e. it's fine to discuss it, but not within the scope of the document revision.
8 ) - In order to connect resource table to resource service descriptor, Mark Taylor proposed to adopt a nested resource schema. Considering we're currently mainly in the situation of one table response per query, it doesn't seem critical at this stage, but it needs more discussion and testing. Tom Mac Glynn proposed another solution which not well catched by the editor. Please Tom can you add your proposal here.
9 ) - We propose to add a free-text name of the service descriptor resource to help identify the offered services. With a SHOULD requirement.
10 ) - We propose to Add an optional "content-type" resource descriptor PARAMETER to identify the expected media type of the offered linked dataset/resource. This can also be considered as a SODA-1.1 new input parameter for driving format conversion.
11 ) - It SOULD be useful to provide a human readable description of a service descriptor. This wil be done by using a | ||||||||
Added: | ||||||||
> > | Extra#0 : Should we suppress the availabilty endpoint in Section 2 (which according to Markus nether works)? Should we focus on {links} capabilities attached to other services only (and not as standalone DataLink services). This point is still controversy. | |||||||
Added: | ||||||||
> > | ||||||||
Extra#1 : from A. Micol. Addition of a "category" column to identify diffrent offered datasets. Isn't that tackled by new semantics terms ? Reluctance to add too much columns belonging to other protocols (Obscore data_product_type). Alberto should add his proposal to the -Next page. Discussion to follow.
Extra#2 : use case for an additional boolean column to quickly identify link elements that require authorization (see below, PatrickDowler) .
-- FrancoisBonnarel - 2019-07-20
Links and AuthorizationWe could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied. -- PatrickDowler - 2019-05-16<--
| ||||||||
Added: | ||||||||
> > |
| |||||||