The Observation Locator Table Access Protocol (ObsLocTAP) specification describes the necessary data model elements and the access protocol to discover metadata about observations for a given Astronomical Observatory through a uniform interface within the VO framework. The used data model makes reference to IVOA Observation Data Model elements (Mireille, et al., 2017), removing the ones associated to datasets access, as these elements are not available yet for future observations that are planned, scheduled, performed but not archived. In this way, present standard is focused on the access to metadata related to the planning of a certain observatory, more than in the access to the scientific data products of a certain observation. Also, the data model described in the present standard will be focused on metadata discovery, useful for multiwavelength coordination observations. However, and in order to prevent coupling between ObsCore and ObsLocTAP standards, ObsLocTAP defines its own data model.The access protocol will be expressed by the implementation of an IVOA Table Access Protocol (TAP) (Patrick, Guy, & Doug, 2010), that, as described in the use cases, allows a powerful discovery process and, also, the implementation of the use cases proposed in the present specification. ObsLocTAPservices could be registered using a TAP VOResource Extension (Demleitner, Dowler, Plante, Rixon, & Taylor, 2015) providing the relevant ObsLocTAP capability. Exact details of the VOResource Extension will be defined in another appropriate standard definition.In the case of a simple use case, planned observations of a certain target can be discovered via a TAP and ADQL (Iñaki, et al., 2008) query that searches for sky regions (or FOV) that overlap a certain sky coordinate. Adding a certain radius to the sky coordinates and/or filtering by instrument identifier could expand this simple use case. As described in TAP, the service will return a list of performed observations of the given target and also the future planned and/or scheduled observations in VOTable format or, optionally, in other tabular serialization format, e.g. JSON. The information about the planned observation, in the near future, will be subject to changes due to any operational issue (re-planning, ToO alerts, etc...). Thus, an implementation of the service may support additional search parameters (some of which may be custom to that particular service) to more finely control the selection of the observation information.

ObsLocTAP Datamodel

Possible prototypes

Some observatories have offered the possibility to collaborate on this standard by the creation of prototypes

• XMM-Newton and Integral future observations publication
• Chandra
• nuStar

Comments