SCS2

[Markus Demleitner]

Dear Gilles,

On Thu, Sep 18, 2025 at 11:13:34AM +0200, gilles landais via dal wrote:
> First because implementing capabilities such as UPLOAD and asynchronous
> queries may become complex. Complex for users and complex for implementers.
>
> For instance the Upload is a nice feature with possible optimization in case
> of multiples queries.
> In an other hand, UPLOAD impacts the server architecture. It's an option in
> DALI : do we have to encourage this option ?

No.  I'm happy to purge it again if there are no champions arguing
for it.  I don't like optional features anyway, and certainly UPLOAD
as proposed is too complex to *require* it in *S*CS.

I put it in to illustrate what I think is sane way to support
multicone searches.  I don't think we have an overriding use case for
these, but it would certainly be a nice touch if we had them in SCS.
On the other hand, TAP provides a very natural way to do multicones,
and so it's not as if SCS2 *had* to offer them to enable that feature
in general.

> I am skeptical about using the asynchronous query for SCS. Indeed, cannot we
> expect for this kind of requests to be executed fast? Is async mandatory in
> DALI?

It's not, and we should very definitely not require (or even
encourage) async in *S*CS.  If you need async, you probably need TAP as
well.

> I would like also to ask for a bit of provenance in the output as specified
> in the DataOrigin Note. This feature is not currently in DALI - may be it
> should ?

I will require a few things that are optional in more general
standards later, in particular tableset and input parameters in the
interface declaration for the Registry.  So, I'd say we *can* require
things that are in some sense "optional" somewhere else.

But then data origin doesn't have many must-s to begin with, and thus
takeup would probably just mean "encouraging" some of the INFOs.  We
could do that even when data origin is just a note, I think.  Then
again, DALI would probably be the more natural place to have
normative text distilled from data origin.

> Finally, position search is sometimes frustrating because the epoch. I
> suggest to find a way to provide the epoch (when applicable) of the datasets
> in output but also in the capabilities metadata (for instance in /tables).

Ok, that's fair, I think.  I'd like to see a use case amended to
motivate that, though.  It's obvious that on output, you want COOSYS
(or, sigh, something better) with epoch (and the current draft tries
to require it when applicable).

At discovery time it's harder to motivate that, because you can't
normally epoch-propagate your cone (unless it happens to be "vicinity
of <star>").  But you *can* expand the cone based on the epoch
difference, so that may be the use case to derive that requirement
from.

What I think we should not do is offer epoch propagation on the
server side.  That's not "simple" any more and could be fairly
time-consuming when you SCS2-query tables with millions or billions
of sources (and you'd have to explain what should happen for
catalogues without PMs).

> use case: get a position from outside (for instance 2MASS in J2000) and then
> reuse position for gaia (in 2015.5). The information allows the user to make
> the change of coordinate system.

Hm... not trivially, I think, in particular because 2MASS doesn't
have proper motions.  My suspicion is that in most cases it's really
just the "errors" (or search radii) that you can use to react to
known epoch differences.

Thanks,

            Markus