TAP information schema

[Tony Linde]

Makes sense, Pat.

T.

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Patrick
> Dowler
> Sent: 12 October 2007 18:03
> To: Undisclosed.Recipients :
> Cc: dal at ivoa.net
> Subject: Re: TAP information schema
> 
> 
> It isn't really all that dire :)
> 
> The crux is that to use TAP the user needs to know the table name
> unambiguously; in the db this is the fully qualified table name (FQTN
> for
> short), which is $catalog.$schema.$table
> 
> For the purposes of TAP 1.0, it would be sufficient to say that the
> VOResource
> metadata about tables an columns (which is what one needs for discovery
> anyway) has to specify unique, unambiguous table names.
> 
> What we should be careful about is to make sure that we do not include
> any
> semantic meaning in such FQTNs - just say they have to be unique within
> the
> service and leave it at that. In MySQL there is one catalog, so FQTNs
> can be
> reduced to $schema.$table in that case. In general one always has a
> default
> catalog they are connected to, so any TAP service which keeps all the
> content
> in one catalog could do the same... others that expose multiple
> catalogs via
> a single TAP (eg upload VOTables to a VOSpace and they are available in
> the
> service) might want to do that or they might want to use a separate
> catalog;
> that is defintely what I would do. Still others might have historically
> used
> the catalog as the namespace (we do that in our sybase servers, eg), so
> there
> we would use FQTNs like $catalog..$table or $catalog.dbo.$table.
> 
> Summary: I think we could get away with just having 1+ opaque unique
> table
> names in the VOResource metadata and TAP implementors can decide if
> they want
> to put something arbitrary and map it to their DB or they can just put
> their
> real FQTN in there and not have to process the ADQL at all. We just
> have to
> make sure this thing has no specific meaning (well, people will see and
> parse
> it and make assumptions anyway, that's unavoidable) that ties us down
> later.
> 
> my 2c,
> 
> Pat
> 
> On 2007-10-12 01:08, Tony Linde wrote:
> > I thought TAP was a mechanism for sending ADQL through to registered
> > services. The various posts here sound like trying to solve perceived
> > problems with ADQL and Registry in TAP: that IMHO is the wrong way
> round.
> > TAP spec should simply be used to push ADQL to a service then you get
> the
> > changes you want into ADQL and the Registry and TAP still works. If
> ADQL is
> > changed so that it supports qualified table names then, and only
> then,
> > should you update TAP to support the new spec, not try to predict
> what ADQL
> > might look like in the future. If OTOH you are saying no-one can
> possibly
> > use ADQL as it stands and there is no point producing TAP based on
> the
> > current ADQL spec then you should get ADQL changed first, but I
> really do
> > not think that is the case.
> 
> --
> 
> Patrick Dowler
> Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-
> 0045
> Canadian Astronomy Data Centre   | Centre canadien de donnees
> astronomiques
> National Research Council Canada | Conseil national de recherches
> Canada
> Government of Canada                  | Gouvernement du Canada
> 5071 West Saanich Road               | 5071, chemin West Saanich
> Victoria, BC                                  | Victoria (C.-B.)