[obs-tap] draft summary: topic 1 *Data product type*
skoda at sunstel.asu.cas.cz
Mon Mar 28 02:23:25 PDT 2011
as I have explained earlier, I am against the fixed enumerated tree
so from the practical point of view the proposal of the original 7 types
AND "other" seems to be reasonable for now.
The understanding what is "other" should be left to the user using some
free-form description - (I think it may be partially answered by
the nature of "observable" axis (o_ucd) which should already come from
controllable vocabulary of UCDs
AND the "dataproduct_subtype" should allow to describe the real nature of
published data in free text or (if not) there should be another field
allowing this. As a data provider I have to describe the nature of my
data even if I cannot find proper o_ucd or subtype from given list (if
required by standard).
Take an example of series of so called line profile periodograms - i.e
on x axis is a wavelength in a line profile on the y axis the frequency
and the various levels of gray mark the regions in line profile where the
changes have given frequency. This is quite common in asteroseismology
publications and people provide this for many lines (and stars).
The problem is with time coverages (as it is a combination of many
observations taken in given times .....) - It has a nature of timeseries.
Before going to other "wanted" tables in VO may be the list of emission
strenghts, equivalent width, radial velocities etc ...
Thinking in a practical terms when astronomer wants to search something,
the discovery process has 2 phases:
first he asks the question IF there is observation of (CLASSES of) OBJECTS
of given TYPE (e.g does it exist the spectrum of this beast ?).
So the search goes using very rough criteria.
My personal experience from searching stars with emission lines in VO has
reduced my enthusiasm in "fully queryable interface". Its difficult find
(even in surveys like SDSS, 2MASS) enough data corresponding your wishes
and so you have to do only very basic pre-selection and then go to refine
queries on given sets. But in practice you want to get first some samples
of ANY data from the service to get some idea abut its quality, structure
etc .. and DESCRIPTION (you have to go to web page of the project or to
published article to understand what is the data characterization etc ...)
So having TAP to return from many servers some basic data and some kind of
README (in free text ) in a first moment would be enough for phase 1.
Then you may be interested in real queryies using ADQL do "data mine" what
you want - but I suppose the number of servers asked will be already
limited and so mor specific parameters may be used.
Maybe the idea of force all servers to understand the same query fields
may really be limited to few mandatory parameters - in this context the
"other" + free form subtype should be sufficient.
>> topic 1 *Data product type*
>> For the moment, I keep prefering the current list of simple values
>> proposed in the draft.
>> I would accept 'other' as a valid value to cover outliers cases ,
>> should be described better in a future revision of the Observation Core
>> components data model.
More information about the dal