Progress

[glemson]

Dear Francois 

In my comments on TAP (see http://www.ivoa.net/forum/dal/0902/0992.htm) I 
have also discuss the metadata specification part. I tried there to reflect 
the discussions we ave had about indexes, foreign keys etc in previous 
emails.
Could you have a look there and see whether you agree with my 
characterisation of our discussion? 

Thanks
Gerard 

Francois Ochsenbein writes: 

>  
> 
> Hi, 
> 
> I'm really happy to see that there is now some convergence in
> the way of finalizing the TAP standard (I feel very uncomfortable
> when the discussion is lead by psychological reactions, so I
> apologize for taking time to react) 
> 
> I like Pat's new document, and hope the route to the final version
> is now not far ahead. I enclose comments about this new version,
> in a more or less order of importance (from my point of view :-) 
> 
> 1. About VOTable INFO (section 2.9.1) as mentionned before (end
>    of last year), plain text will not be allowed directly within
>    the INFO tag in VOTable1.2, but within a DESCRIPTION sub-element
>    e.g.
>    <INFO name="QUERY_STATUS" value="OK">
>     <DESCRIPTION>Successful query</DESCRIPTION>
>    </INFO>
>    (the textual comment is not essential in this example anyway :-) 
> 
> 2. The TAP_SCHEMA: I still feel it's incomplete and could be improved: 
> 
>    a) in TAP_SCHEMA.tables: 
>       * what is 'output' table_type is not obvious (table created 
>         on the fly e.g. by running a model ? )
>       * some kind of standardized description seems to be missing:
>         with 20,000 tables the selection of the interesting tables
> 	does not look obvious on the basis of this schema. In the 
> 	case of vizier we have keywords, wavelength domain (exists
> 	in VOResource), usual abbreviations (exists in VOResource),
> 	relations between tables (tables belonging to the same 
> 	'astronomical catalog')
>       * some statistical properties are quite important
>         for applications (number of tuples at least approximative,
> 	sky coverage if relevant, to quote those existing in
> 	VOResource) 
> 
>    b) in TAP_SCHEMA.columns: 
>       * "primary" and "std" : I'm not sure to understand what it
>          means. I guess they have to do with the 'importance' of
> 	 a column ? In this case, these attributes are similar
> 	 to the 'VERB' option of the ConeSearch, and these two
> 	 attributes could be replaced by a single one ('visibility'
> 	 or 'importance').
> 	 Unless 'std' stands for 'non-virtual' (i.e. actual columns
> 	 in database, vs columns computed before delivering the output)?
>       * "indexed" does not always apply to a single column --
>          indexes may be built on a set of columns (e.g.
> 	 index on (dec, ra))
>       * domains are missing (domains describe the possible
>         values of a column, as a range or a list of values, 
> 	and the existence of null/blank in columns). Quite
> 	useful for applications, too. 
> 
>    -- important properties of the relational tables are missing
>       from the TAP_SCHEMA, especially the properties of unicity
>       (keys of the relational schema). As in the case of indexes,
>       keys are defined as a combination of columns in a table,
>       and therefore can't just be an extra attribute of 
>       TAP_SCHEMA.columns 
> 
> 3. Following Bob's comments, I would also prefer another word
>    than 'LANG' to specify the way the query is coded. QUERYMETHOD
>    looks pretty clear, even though it seems somewhat long... 
> 
> 4. For the output format (section 2.3.6) I'm wondering why 
>    tab-separated-values is not included -- generally easier
>    to deal with, as many columns do include commas in their
>    contents, while control characters like tab are (generally)
>    not existing in table columns. In the final document,
>    it would be useful to write down the mime type corresponding
>    to each format.
>    
> 5. Finally, I feel there should be some words about TAP and
>    ConeSearch -- after all ConeSearch is doing a fraction of
>    what is described in the TAP document. 
> 
> Thanks to all contributors !
> Francois
> =======================================================================
> Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
>    11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
> =======================================================================