1. Phase 1
Breakdown of work required to produce an initial ObsTAP service.
An "ObsTAP service" is a TAP service which contains a table or view with the prescribed name "ivoa.ObsCore" and which contains observation metadata in an ObsCore-conformant data model. Note that heterogeneous image data (from multiple sources or of multiple types) is all expected to be in the same table (or view). (However, nothing precludes a data provider from running multiple ObsTAP services – which would mean providing multiple TAP endpoints.)
Relationship with SIAv2
Given the existence of a conformant ObsTAP service, it is relatively straightforward to provide an SIAv2 service layered over it – in general all SIAv2 queries can be mapped to ADQL queries against an ObsTAP service holding the underlying ObsCore data. There is an existing CADC code base to do this. (There are a few specific spherical geometry complications in the mapping that are beyond the scope of this note.)
1.1. Create or Obtain ObsCore observation metadata
A key element of the ObsCore data model (relied on by both ObsTAP and SIAv2) is the mandatory provision of an access_url – a directly usable URL (i.e., in a widely supported scheme - basically https: given other LSST constraints). This URL should be usable in a synchronous operation - essentially, if it's https: it should be usable via GET. The standard allows the URL either to directly return an image, or to return a DataLink "links table".
Since the LSST design and requirements envision the provision of "virtual" (created on-demand) data products, possibly with long latencies, in the long run the links-table approach seems preferable, as it can accommodate signaling to a programmatic or UI client that a particular observation dataset may take a while to return. However, as ObsCore makes it possible to determine row-by-row in a results table whether the access_url is for the image itself or for a links table, our initial ObsTAP implementation, which will deal only with concrete pre-existing datasets, does not require the use of links tables but can grow to accommodate them as virtual data products are introduced.
1.1.1. Obtain ObsCore metadata for external and legacy data
The LSP currently holds several external and legacy datasets – AllWISE, Gaia, LSST-processed SDSS S82. It would be useful to provide image search services for at least some of this data. Most likely of interest would be the AllWISE coadded frames and single-epoch data. For these datasets, in some cases ObsCore metadata tables are already available externally (e.g., from the IRSA SIAv2 service for the AllWISE data) but in other cases deriving ObsCore data might require the development of special tooling.
For the WISE data in particular, LSST has not attempted to serve the image data directly, so the ObsCore table's access_url values should point to IRSA endpoints.
1.1.2. Derive ObsCore metadata from Butler Gen3 repositories
For future LSST use, it's clear that we have to be able to set up an automated pipeline for the derivation of ObsCore (and also CAOM2) metadata for datasets in Butler repositories. It seems wasteful at this point to attempt this for Gen2 repositories given the impending transition to Gen3.