Obstap / about optional fields

Mireille Louys mireille.louys at unistra.fr
Thu Mar 17 09:58:27 PDT 2011


Hi François, all

In the current version of the document the content of  
TAP_SCHEMA.columns is described in table 6 for the mandatory  
column_names and in table 7 for the optional ones.
I suggest adding a paragraph that states :
TAP_SCHEMA.columns must contain all mandatory fields of table 6 and  
may contain an extra list of columns as described in Table 7 and  
possibly some additional fields defined by the data provider.

is it correct?
understandable?

thanks, mireille

  Bonnarel <francois.bonnarel at astro.unistra.fr> a écrit :

> Hi JuanDe
> I think the simplest for version 1.0 is solution 1 with a minor
> modification. A standard error message is enough
> for services not supporting the non mandatory fields.
> The idea is to ALLOW the discovery of datasets which will stay headen
> otherwise....
> The idea is also to minimize the extra work for this version ...
> Cheers
> François
> Le 17/03/2011 10:05, Juande Santander Vela a écrit :
>> Perhaps it has eluded me and is already discussed in the ObsCore   
>> document, but I cannot recall having read it.
>>
>> I have the following problem with optional fields: when we say that  
>>  a given ObsTAP field is optional, what does exactly mean:
>>
>> a) The field is not mandatory in the ivoa.ObsCore table,  and
>>    therefore no entries exist in TAP_SCHEMA.columns with
>>    table_name = "ivoa.ObsCore".
>>
>> b) The field is mandatory in the ivoa.ObsCore table, but the
>>    content for all rows is NULL.
>>
>> The problem with approach a) is that we are defeating the ability   
>> of sending the same ADQL query in all ObsTAP compliant services,   
>> unless the ObsTAP implementations return NULL by default to columns  
>>  they do not know about in a given schema.
>>
>> So, for solving that issue, I see three approaches:
>>
>> 1) TAP services return NULL for columns they know nothing about.
>>    This seems like a hack, and an extra burden for TAP
>>    implementations.
>>
>> 2) Take approach b) above. But then we would have to check
>>    that the semantics for NULL do not interfere with anything
>>    we have already in place.
>>
>> 3) Group optional fields, so that they exist or not together
>>   (even if some of them need to be NULL), and the first discovery
>>    of relevant ObsTAP services is made through capabilities search
>>    in the registry.
>>
>> I think 3) is more natural: we have more information in the   
>> registry for service discovery, and we ensure that the fields exist  
>>  for the use case we are interested about.
>>
>> What do you think?
>>
>> Am 17/03/2011 um 00:14 schrieb François Bonnarel:
>>
>>> It was admitted a long time ago that the obstap parameters should   
>>> alllow the same ADQL
>>> query to be performed on all Obstap/compliant services. Therefore   
>>> a limited set of mandatory
>>> parameters has been defined covering most of the Initially   
>>> proposed use cases.
>>>
>>> However a few of them (polarization data, Cubes with Radial   
>>> Velocity, specific dataproduct subtypes, etc...) were missing.
>>> A small set of additional optional parameters have been defined in  
>>>  the document. (Some new ones have been proposed
>>> in the current discussion)
>>>
>>> I see two interests in these optional fields:
>>>     * complete the description and help the data discovery phase   
>>> by displaying more complete descriptions of the data sets
>>>
>>>     * extend the Obstap Query mechanism for the benefit of small   
>>> specialized communities...
>>> ADQL query on optional field will make no harm to "minimal" Obstap  
>>>  services and will return no
>>> data from them. But data providers of these kind of data will   
>>> probably fill these optional
>>> fields for a better exposition of them, and data consumers may use  
>>>  them in their queries if they are interested  and get a chance to  
>>>  discover some .....
>>>
>> --
>> Juande Santander Vela
>> Software Engineer, ALMA Archive Subsystem
>> Data Flow Infrastructure Department, Software Development Division
>> European Southern Observatory (Germany)
>>
>> George Carlin: Si es cierto que la Humanidad está sola en el   
>> Universo, habría que decir que el Universo no tenía miras muy   
>> altas, y se conformó con bastante poco.
>>
>>






More information about the dal mailing list