How will the Upload-Match pattern be handled in VOSpace/TAP/VOQL?

Comment from ChristopheArviset
The layers in which a possible service using ADQL can be divided are: 1) The language (ADQL). Defines what the language is. Not how to make use of it. 2) The Protocol (TAP). Defines how to access data making use of the language. Does not define what to use it for. 3) The service (any service). Defines what to use the TAP for. It is intended for specific cases.

The Upload-Match service should be a Service (i.e., 3rd point above) that is declared (and put into the Registry) as being TAP compliant (and ADQL compliant), and possibly making use of specific User defined functions (which can be defined in the ADQL, and used through the TAP) to fulfill certain specific requirements (like in this case, for instance, possible X-Match functions).

The question then is whether the uploaded data are permanent or transitory. If permanent, it doesn't matter if they are put into VOSpace via the VOSpace service itself or via a TAP mechanism. If transitory (and especially if these data are the result of previous querying) then the TAP service needs to manage them. This is borne out by prototyping work Pat Dowler is currently undertaking.

Therefore, this topic is a good Use Case of real usage of a Language and a Protocol to solve an astronomical problem for which the planned IVOA standards (ADQL, TAP, VOSpace) should offer a possible solution.

Taking these into account, I would tend to think that we probably do not need to flag this as a topic for the Roadmap.

A principle justification of the VO itself is to encourage statistical studies of populations of astronomical objects, as well as the more traditional single object study. One very important usage pattern is the matching of archival catalogs with a "personal catalog" supplied by the user, that may have 10, 1000, or more sources. It should be easy for a user to do this, without the need for jumping through hoops of authentication, persistent storage, asynchrony or ADQL. These latter are necesary evils for very large numbers of sources, but should not be necessary for smaller, simpler types of matching.

It seems to me (FrancoisOchsenbein) that this achievement should not be that difficult -- would VOSpace be required as the standard way, or just custom http uploading (POST or PUT) ? The cross-matching operation is a topic for which no agreement could be reached in the past; but if this operation is restricted to a multi-cone-search, i.e. append to each user's row the sources found within a user-specified small circle, I imagine it would be used a lot ! More sophisticated cross-matching could well be applied on these first results by user-controlled procedures.