For the RSP image metadata services, based on the IVOA ObsCore model (initially ObsTAP and later also SIAv2) we have adopted the "CADC model" where the access_url
in the ObsCore data model is a link, not directly to the image, but to a DataLink "links service" which provides access to the image and (extensibly, over time) to a variety of related information.
IVOA Documentation:
- ObsCore v1.1: abstract, PDF
- Definition of
access_format
when using a links service foraccess_url
: end of section 4.7
- Definition of
- DataLink v1.0: abstract, HTML
- Definition of a "links service": section 2.1 (API), section 3 (response format)
Most immediately we need to decide on what the URL TO the links service will be, for each image, e.g., something of the form:
- https://data.lsst.cloud/api/XXXXX?ID=YYYYY - what is the (static) URL XXXXX, and what is the per-image key YYYYY (perhaps the UUID?)
... and on what the links service itself will return as a URL, which must be directly usable via GET, for the underlying image file itself.
Update from meeting:
- The links service will live at https://data.lsst.cloud/api/datalink/links .
- The ID parameter's value will have the format
butler://dp02/{uuid}
, whereuuid
is the standard Gen3 Butler UUID string. - Escaping for the ID parameter's value will be a matter for SQuaRE to work out. It's possible only the ":" will need to be escaped.
- Tim Jenness , what if we need/want to use this, beyond DP0.2, for a Butler repo that doesn't have a "short name" yet?
- The "links service" itself will be responsible for creating a Butler based on the "dp02" part of the string, then using that Butler to translate the UUID into a Google Cloud S3 URI for the underlying file artifact, and then finally for obtaining a signed URL for that artifact that is usable externally for a limited time.