[obs-tap] draft summary: topic 1 *Data product type*

[Petr Skoda]

Hi all

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.