I understand that there's some thinking going on about possible rearrangement of the components of the prototype TAP browser UI, and in this context I heard a remark that the upper-left pane, that is, the schema-and-table selection pane, has some blank space that we could think about reclaiming.
This is to point out that at some point we'll want to facilitate joins in the UI, based on the foreign-key information in TAP_SCHEMA.
The currently empty space below the "Tables" pull-down would be exactly the place for this. I imagine that below that pull-down there would be UI elements for selecting a table to join to and the keys to use for the join.
I've started a sketch for that which I'll upload as an image.
Once the join is defined, Firefly would have to determine what the joined tables' effective schema would be, either by analyzing the schemas of the two tables and computing the combination itself, or by issuing a MAXREC=0 query for the join against the TAP service. With that in hand, the UI's table-of-columns-and-constraints (the current bottom half) could be populated with the joined schema, and then all its other features (e.g., column selection, constraint definition) would proceed as usual. The spatial-constraint and temporal-constraint search helpers (upper right pane) should also be able to work against the joined schema. This is all pretty well-defined and users would have very natural expectations.
Getting the joined-table schema itself defined may be the hardest part of this whole task.
Implementing this is NOT an LSST close-out task (sadly). But we should not give the UI space away without at least taking this into account.