[TAP] data type for column metadata

[Arnold Rots]

Roy,

Referring to your one but last paragraph:
The point is: what if you don't find out that the data are not what
you expect them to be? That's where the trouble starts. And going to
the library to figure out whether the stuff you just pulled from the
VO is any good for your purposes is not realistic - not to say:
ludicrous.

There needs to be a way to find out whether the data from a particular
service is going to be potentially useful.
And the solution is actually pretty simple.
It all comes down to accuracy/precision/resolution/error.

Resources should provide in their profiles the time resolution that
they provide and the possible errors.

So, if on the one hand a resource doesn't want to do any work on this,
it can simply quote an absolute time error of half an hour and a
resolution that is at least that.
Then, on the other hand, a client who wants high timing accuracy won't
touch it with a ten-foot pole, but anyone who doesn't care about time
better than a day will be happy with it.

Conversely, the high timing accuracy user will look for services that
can provide the necessary information (and if they are quoting
absolute time errors of, say, 1 ms and similar resolution, then they'd
better be prepared to provide that). However, your undiscriminating
user will take the data without even asking.

My point:

Clients need to be able to distinguish services that are useful to them.
And that means that there needs to be a mechanism.
The Resource Profile will provide that mechanism, if it is properly
filled out.
Then, for appropriate cases there needs to be a mechanism to get the
necessary metadata (like Time Scale, etc.). But only services that
pass the first test need to be prepared to provide that.

Does that do it for you?

  - Arnold


Roy Williams wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> 
> Ninety-nine percent of functionality at five percent of cost YES PLEASE. 
> For example multicone is simple, inclusive, and rough -- then you do the 
> thoughtful crossmatch at home.  I would like to echo that argument but 
> for time.
> 
> If you make a query that involves astronomical epoch, the query engine 
> doesn't need to get all the leap seconds right. You just widen the query 
> by a couple of minutes, and when you get the results home, figure out 
> the precision part of the timescales. That may involve reading a 
> published paper to find out the metadata you need, because whoever 
> filled in the registry form for the TAP service might have failed to 
> define timescale metadata properly.
> 
> If you do a query involving dates, and discover that the timezones are 
> wrong, then you can work around it, or you can find out the timezone the 
> server is expecting, and do the query again.
> 
> It is impossible to be perfect. Let's spend out time on Common Use 
> Cases, Robustness, and Helpful Error Reporting instead of trying to get 
> computers to make subtle and complex judgement calls.
> 
> Just my $0.02
> Roy
> 
> -- 
> 
> California Institute of Technology
> 626 395 3670
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------