TAP VOSI Information

[Tom McGlynn]

Douglas Tody wrote:
> On Wed, 11 Nov 2009, Tom McGlynn wrote:
>
>> It seems like the first step in specifying the real TAP response to
>> a VOSI capabilities request is understanding what information needs
>> to be there.  Here's a first cut.  I imagine there could be lots
>> of things that go in that don't have to do with TAP itself (e.g.,
>> copyright). I've not said anything about them.  The indentation may
>> not survive mail, but I hope the intent is clear.
>
> This looks like it gets us 90% of the way there.  Minor comments follow
> below.  The main thing I see missing is whether the multi-position
> query is supported in PQL since this would be an advanced capability.
> The default and maximum values for MAXREC need to be specified.
>
>   	- Doug
>
Hi Doug,

I hadn't forgotten multi-position...  At least in the current PQL draft, 
the only place you can use uploaded tables is in the multi-position 
query.  So the service would specify that they supported multi-position 
queries by giving the kinds of tables that a user can upload in PQL.   A 
service which did not support multi-position queries would specify no 
supported sources for table uploads in PQL.

I had overlooked one of the most critical options though, the supported 
Formats.  Presumably the conventions adopted for the other DAL protocols 
can be used here.

I'm not sure that row limits alone are enough.  The database may have 
BLOBs or CLOBs which could be very large. Currently we tend to store 
metadata in the database and data in the file system, but with modern 
database systems, storing the data in the database could make a lot of 
sense. If a user has a 500 MB data file in each row, just a few rows 
might be pretty nasty for a download.

I like your suggestion with regard to providing an indicator for the 
underlying database.  In addition to being useful, it would be 
fascinating just to see what choices our colleagues make.

	Tom


>
>
>> Key       Values   Discussion
>>
>> Language           The languages supported by the TAP service.
>>                     ADQL is required and this can be repeated as
>>                     many times as desired.
>>
>>            ADQL     Required.
>>            PQL
>>            SQL      Pass through of SQL queries.  Reserved but not
>>                     defined.
>>
>> ADQL.Access        Methods through which ADQL can be accessed
>>
>>            Sync     Required.
>>            UWS      Required.
>>
>> PQL.Access         Methods through which PQL can be accessed
>
> Same as for ADQL.

The options are the some, but unlike ADQL they are not required.
>
>> ADQL.TableSource   Sources for tables uploaded in ADQL (none required)
>>
>>            Parameter
>>            URL
>>            VOSpace
>>
>> PQL.TableSource    Sources for tables uploaded in PQL multicone.
>
> Same as for ADQL.
>
>> ADQL.Geometries    Supported geometries.
>>
>>            None     No support for ADQL geometry.
>>            Limited  Default.  Suggests some support but less than Basic.
>>                     Service is allowed to accept or reject any geometry
>>                     construct.
>>            Basic    Basic Geometry support (No intersects and one or
>>                     two other functions as mentioned in TAP)
>>            Full     All atomic geometry objects and functions
>>
>> ADQL.Region        The level of support for REGION in ADQL queries.
>>
>>            None     No query with a REGION parameter will be accepted
>>            Limited  Default value.  Suggests some support but less than
>>                     Simple.  With this value the service is free to
>>                     accept or reject any REGION.
>>            Simple   Regions using accepted coordinate systems and a
>>                     single CIRCLE, BOX or POLYGON are supported.
>>            Composite Regions using composites of the three basic regions
>>                     are accepted (as in latest STC-S note).
>>
>> PQL.Region         Same as for ADQL.Region.
>>
>> ADQL.CoordSys      Coordinate systems supported in ADQL
>>                     Taken from STC table.  This should be repeated for
>>                     each supported coordinate system.
>>
>> PQL.CoordSys       Coordinate systems supported in PQL
>>
>> UWS.DefaultExecutionTime       Default execution time the service will
>>                                 allow in UWS access (seconds?)
>> UWS.MaximumExecutionTime       Maximum allowed execution time
>> UWS.DefaultDestructionTime     Default time before results deleted.
>> UWS.MaximumDestructionTime     Max time before results deleted
>
> These values will depend upon what the user is authorized to do.
> I guess it still works, e.g., if an authenticated connection is opened
> the values may be customized for the particular user.  The values
> cached in the registry would be for the default, non-authenticated
> access.
>
>> VOSI.function      VOSI supported capabilities
>>
>>            Availability    Availability is supported.
>>            Tables          Tables is supported
>>            Capabilities    Required. Capabilities is supported.
>>
>>
>> --- I don't really want version negotiation in V1.0, but if it's there, then
>>
>> Version            1.0     Required. Version of current interface.
>>
>> SupportedVersions  1.0     Required
>>
>>                    Other supported versions.
>
> Ok.  So Version is the default version supported, with the other
> versions as specified in SupportedVersions.  This is essential.

That's probably a better way of saying it.