SSAP V0.95: top/sort/rank

[Markus Dolensky]

Dear Randy and Colleagues,

Randall Thompson wrote:
 >>     TOP - A more straight forward approach, in our opinion, would
 >> be to define a "SORT" parameter to allow the requester to optionally
 >> determine the sort order. This would also allow sorts on parameters
 >> other than those used in the query, and optionally multilevel and
 >> ascending/descending sorts could also be specified. It is unclear to
 >> us how one would "rank" results based on multi-parameter queries and
 >> there is no guarantee that services would rank results in a consistent
 >> manner.

All above is true :)

The reason for omitting an explicit SORT parameter in first place was that a 
client (GUI) may provide superior means of creating specific views (histogram, 
sort orders, etc.) incl. the aggregation of several result sets. Hence, the 
authors did not (have to) start defining sort methods for the various data types 
of an SSA response.

The combination of TOP and score minimizes the required bandwidth on one hand - 
similar to a combination of TOP/SORT would - but on the other hand it also 
allows to inject a priori knowledge of an archive scientist about a specific 
data collection. For instance, computing a score based on spectral resol., 
atmospheric seeing and exposure time could be used to return 'promising' spectra 
for a given position of an extended object (as I was told by my VO project 
scientist). The definition of 'promising' would be much harder based on 
parameter values and sort orders and more so if we had to agree on a set of 
rules constituting 'promising' in each context.

So, again I don't disagree with your reasoning about SORT, but believe it can be 
done elsewhere and that ranking is a largely orthogonal operation offering added 
value.

Cheers,
Markus