*DataLink: work on resolving current issues *(Wednesday May 6 - 4:30 UTC) Participants: 34 GitHub DataLink repo: https://github.com/ivoa-std/DataLink *Closed Issues: 1. DataLink scope DataLink is not only for adding links to datasets but also for recordsets in catalogs, entities in ProvTAP/ProvSAP, Journals, Catalogs Etc… Intro text + use cases to reflect that (issues #6 #7) Simple RECOGNITION mechanism using LINK + special content-type (issue #29) 2. Links « endpoint » changes Change « resource » to « endpoint » (issue #11) Enhance the standardID INFO tag (issue #17) Enhance the need for meaningful « description » FIELD in the response (issue #16) Allow URI fragment in access URL (issue #15) 3. Service descriptors changes Better recognition and organization of service descriptors Nesting of resources (Optional) (issue #20) Name for service descriptor (issue #21) Description TAG (issue #23) Content-type PARAM (issue #24) Changes in examples whick makes more sense (issues #20, #21, #22, #23) Full refurbishing of self-describing service (custom services oriented) (issue #25) 4. Other things Implementation note proposed and drafted (issue #31) 3 errata for version 1.0 fixed but not published. (issues #1, #2, #3) 5. Closed but still discussed : Capabilty/availability issues (TBD?) one PR Approved but sharp discussion on need for registration of services, VOSI endpoints and usage of availability. (issues #13, #14) Text changed from registrable services with VOSI endpoints to a simple « capability ». Still possible to create a « service » with this single capability Availability comes for free (or not) according to DALI (if it is a service) accoding to DALI * Current Issues 1. Incomplete content_type subsection https://github.com/ivoa-std/DataLink/issues/42 Each link has a content_type field. Proposal: parameterise the content_type value to describe the content, e.g. application/fits;dataproduct_type=image where using ObsCore dataproduct_type values as {label} would more or less solve the use cases that were discussed on the mailing list. Note that we already use application/x-votable+xml;content=datalink in several contexts, including as a possible value in a link (recursive datalink) so clients already have to deal with parameterised content_type values. Aside: when the ObsCore dataproduct_type becomes a full-fledged vocabulary, the list of terms to expect would grow to satisfy more use cases. Clients have to know if the « progenitor », « derived » « co-generated » or « conterpart » link is an image, timeseries, spectrum, etc ..http://volute.g-vo.org/svn/trunk/projects/time-domain/time-series/standardized_votables/francois/SDSS_J080434.20+510349.2_VizieR_complete_utypes.xml Reuse ObsCore vocabulary This vocabulary will become soon an IVOA vocabulary. Issue #42 [PD] trying to solve the issue of having content and format together, see also the new link semantic below this solution could go beyond DataLink: move it to another REC? Where? [FB, q: in DALI?] MD: clarify the use of "content", try to be pragmatic solving current issue. FB: agree on stayin on this issue here not to delay spec. Prefer LINKS where possible. PD: should values come from specific vocab or other? IC: concern on HTTP header usage, where we don't have control on protocol and rely on implementation that is external. Prefer using the query response. PD: we can start it here, and if it's taken up it can be moved to DALI later (content-type) 2. Inform client that links require authentication & authorization https://github.com/ivoa-std/DataLink/issues/33 Some links in the response may be to protected resources that require authentication. It would be nice to tell the client this in the response so they don't have to try and fail. 2.1 Simple proposal: define a "requires-auth" field to indicate if authentication is required. 2.2 Deluxe version: also define a "usable" field that indicates that the currently authenticated identity is authorized to access the resource. mandatory or optional field(s)? optional so we can add in 1.1 once concept defined, name(s)? note: CADC has implemented the deluxe version that predicts authorization Avoid error 401 or error 403 when accessing reserved access links Proposal to add one or two fields to give status Issue #33 DataLink 2 ? JD: how to deal with AuthN and AuthZ separately PD: possible depending on fields usage MT: a small vocab in the authN field rather than multiple flags (MD agrees). anyway go optional and try it out first This information will largely be for human consumption, so contrained content is not an overriding consideration FB: work/effort to add optional columns agreed: work on a single field with small vocabulary, with concepts like: anon/public? - must-authenticate? ... authorization-predicted 3. Templated endpoint mechanism in Service Descriptor https://github.com/ivoa-std/DataLink/issues/27 Current DataLink service descriptor describes dynamic param=value invocation of a service endpoint. The proposal here is to enable dynamic elements in the path by some sort of template mechanism. We have various use cases where we want to pick up variables values in the table to fill a template URL (eg : RESTFul URL but not only) Proposal to have a mechanism based on RFC6570 Various flavors discussed : absolute URL : Relative URL : Templated Link inside a PARAM Bibcode retrieval for sources Gregory-DF: use case at Rubin wrt metadata driven service. e.g. build an ADQL query to call a TAP service without putting the full URL call in the response table; or generate SIA out of multiple columns fro RA,Dec, sr... (answer FB): for SIA templating templating would help. Can solve that with additional microservices instead of flexible templating, but it's not ideal PD: value substitution in service-desc is only used for IDs. it would become quickly complicated to work with all parameters from the resource table. MD: related search sounds a lot like a service rather than templating... IC: @Markus: agree MD: Ah, but Gregory was't talking about interactive search, and in that case that's just a link. [MD] service links shouldn't be complex service blocks, subsitute with single DataLink documents. [Tom MG] this exposes the user to a set of services to choose. MT/GD-F: putting all the functionality in a datalink document per row as Markus suggests makes good sense for heterogeneous tables, but significant disadvantages w.r.t. service descriptors for homogeneous tables: it's not clear to the client or the user whether the same options are available for all the rows in the table or if you have a custom set of options per-row. service-desc vs. links (2 different stds?) -> 2.0? Issue #27 DataLink 1.1 or 2 ? 4. New link semantic proposal Link « semantics » made of : (4 attributes/param di identify the record) Relationship Information Dataproduct type Format Ada's proposal : new fields ? → DataLink 2 *Questions: *(write your "Name: my question?" in this list) 1. [Gregory Dubois-Felsmann] Could we get a quick review of the current status of the major community TAP server codes' ability to add DataLink annotations to query results? TMcG: HEASARC uses DataLinks to serve data products associated with observation tables. The products may be recursive in that the initial data link may return subproducts. E.g. Swift Observations -> UVOT observations -> UVOT images SGaudet: The ALMA datalink service in development uses recursive datalink.