Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Labels:
-
Team:Science User Interface
Description
The Firefly TAP query interface should be accessible via a URL interface.
- The URL interface SHALL be IVOA "DALI-style", and in particular compatible with use with DataLink. This means that all parametrizable components of the interface must be URL query parameters (e.g., (instance)/portal/tap-search?service=...&table=...) ), and the parameter values should be chosen with a view to being values that could be found directly via other queries, so that they they can be used via DataLink "service descriptors".
- Where this makes sense, parameter values SHOULD have DALI types.
- When deployed in the LSST Science Platform context, the URL SHALL fit in the pathname space under (LSP-instance-FQDN) / portal/. The implementation SHOULD provide the flexibility to allow it to be deployed in a variety of ways in IPAC's own archives.
- The interface SHALL have a service_uri=(URI) parameter to allow the specification of a TAP service to be used.
- The interface SHALL be designed to accommodate a service_id=(IVOAiid) parameter to allow the specification of a TAP service to be used, via Registry query to translate the name to a physical service endpoint. It SHOULD be an error to specify both service_id and service_uri. The interface MAY be released without an implementation of service_id.
- When deployed in the LSST Science Platform context, when neither service_uri or service_id is specified, the interface SHALL default to the instance-local TAP service under (LSP-instance-FQDN) / api/tap/. The interface SHALL provide for an application-level configuration parameter override to this default. (This would be used, e.g., if a new TAP service is being tested, or a fallback to an old one is needed during integration tests.)
- The interface SHOULD permit a non-LSST-LSP deployment to set a default service. If provided, the configuration mechanism for this SHALL permit the use of a URI to set the default. In addition, if this mechanism is provided AND the service_id parameter is implemented, the mechanism SHALL allow an IVOA-id to be used to set the default (with registry lookup performed at run time).
- The interface SHALL have a table=(table-name) parameter which specifies a fully qualified ADQL table name. Invocation with table and the specification of a service (possibly defaulted) SHALL be sufficient to bring up the query UI for the named table.
- The interface SHALL permit invocation without a table specification. In the absence of any other (optional) parameters, this SHALL bring up the standard "top level" schema-and-table-selection view of the UI.
- The interface SHOULD have a means of initializing the target-selection field of the Spatial Search component of the UI. It SHOULD support specification by name and by astronomical coordinates, but the latter are a slightly higher priority. Please consult Gregory Dubois-Felsmann for more discussion of an appropriate parameter interface for this capability. The spirit of this, at least, would be to use DALI parameters drawn from those in the SIAv2 specification. This capability is specifically intended for use with DataLink, to permit a search to be launched with ease from a row in a previous search result.
The "SHALL" specifications above are sufficient for the initial release of this capability.
Attachments
Issue Links
- mentioned in
-
Page Loading...
Activity
The second key motivation - and the reason for the focus on a DALI-friendly interface - is to support launching Firefly via DataLink. This opens a huge range of possibilities for enhanced user interfaces in the future.
To clarify what I mean by "DALI-like": It is not a requirement for the initial release that things like the VOSI-availability and VOSI-capabilities resources from the DALI spec be implemented. However, I would like the URL design to provide a place for them to go at a later date if we decide that there's value in implementing them.
Fundamentally we can't provide a true DALI service, anyway, because people aren't going to be able to call it programmatically and usefully parse the result.
The important points are the form of the URL and the datatypes of the query parameters.
Once we have something nice to demonstrate here, I intend to go to the IVOA with a talk/demo and explore with other groups whether we might seek standardization of this "DALI-like" way of bringing up an interactive web application.
It was pointed out in the Firefly group standup on Monday of this week that this should be thought through in the context of other long-standing desires for a URL API for Firefly, and that the complexity of the issues involved mean that this can't be acted on on any sort of short time frame.
I will try to start collecting some thoughts on the issues on a Confluence page.
| Field | Original Value | New Value |
|---|---|---|
| Sprint | SUIT Sprint 2019-05 [ 874 ] |
| Sprint | SUIT Sprint 2019-05 [ 874 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 35586 ] |
Gregory Dubois-Felsmann do you have a status update on this functionality?
One key motivation for this interface is to allow a very limited version of the originally designed (pre-descope) "user-friendly Portal" capability to be provided through simple static Web pages that can be written by a non-expert developer (e.g., me) to guide them to searches of interesting tables.