content, format, ctype, or xtype ?

[Patrick Dowler]

On Monday 04 May 2009 10:41:31 Roy Williams wrote:
> With a relational database, there is none of this complexity. Values can
> be floats or strings or a handful of other simple primitive types.
> Nothing else. Can't we bring TAP back to its original limited purpose as
> an interface to a database?

I wish it was that simple, but you are ignoring all the knowledge of how to 
use the database that is buried in the documentation or, more typically, the 
heads of a small number of people that developed it. 

Without that knowledge a DB is almost unusable. We don't need to provide the 
knowledge, just provide a mechansim, or in the case of TAP_SCHEMA + VOTable + 
VODataService, know that there is a mechanism that service providers can use 
to transmit some of that knowledge.

> Surely it is over complicated to try and bring all this semantics into
> it? RA and Dec (within TAP) should not be complex semantic entities with
> coordinate frames, they should be SIMPLY floating point numbers!. If you
> want to know what equinox/observer/format/data model/width/precision,
> then look somewhere else, because TAP should not know this! The proposed

The fine line we are trying to tread is for TAP to "not know" this but still 
enable... utype and ucd capture the semantics so TAP does not have to say any 
more. With respect to a format/content attribute, there is some important 
practical metadata (not semantics: just how to parse a value) and we are 
trying to ascertain if this can be conveyed or if there is in fact a (small) 
gap.

> standard can never be robust (or event understandable) with all this
> semantic complexity mixed in there, all these overlapping and undefined
> attributes.

If the mechanisms are available in other related specs (in this case VOTable) 
then I don't think the TAP standard itself will seem all that complex. Sure, 
the discussion is here because TAP Is driving some additions elsewhere, but 
that is a good thing: TAP is using other standards everywhere it can and some 
of these small but important issues will end up as small, understandable 
additions to other standards and change the complexity minimally if at all. 

Please keep reminding us to keep it simple... as simple as possible anyway :-)

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090504/dfb5d55c/attachment-0003.html>