Difference: DataProduct (5 vs. 6)

1. Should we specify all possible values ? There is the suggestion in the current document to allow the value 'other' when no available category fits to describe a possible science data product.
2. If we allow other , how do we specify more information ? In free format, in Subtype, but then no interoperability is granted.
3. How could we suggest a possible set of pairs (type, subtype) for a data product and provide examples

Comments

In my opinion, in an ideal world this would be something like a set of tags (e.g., it's easy to imagine spectrum-image, or spectrum-timeseries, or image-timeseries). A taxonomy of such classes (the "tree") could then be used for query expansion by clients. However, there are no set-valued columns in ADQL, and faking them using, e.g., strings and SQL patterns ("=AND producttype like '%/spectrum/%'=") would defeat indexing and simply be ugly. So, I'd say make a catalog, ideally using the StandardKeyEnumeration from StandardsRegExt, and "other" is simply the SQL NULL. Tell both data providers and consumers not to fill in the type if there's not a good match. Ideally, the StandardKeyEnumeration would in the descriptions try to cover as many real data products as possible ("This category covers objective prism exposures"). My feeling is that that's the Pareto-correct way of doing things, actually covering probably around 98% of the actual queries rather than just 80%.

-- MarkusDemleitner - 04 Mar 2011

I second this way of working. NULL should be the other, and the enumeration should be registered as a StandardRegExt. Among the datatypes I would propose:

• image
• spectrum
• image-spectrum (for series of images ordered in a frequency/velocity range, i.e. radio data cube)
• spectrum-timeseries
• image-spectrum-timeseries (for a 4D datacube consisting of image-spectrum cubes at different times)
• image-timeseries
• spectrum-spatialseries (for spectra on arbitrary positions, such as IFUs, OTFs, MOS)
• image-mef (for multi-exposure frame images)
• spectrum-mef (for multi-exposure frame images or _spectra_?)
• visibilities (for radio visibilities)
• timeseries (for arbitrary data, specified by o_obs, changing with time; similar to event data)
• map (for a 2D data product with spatial indexes, and arbitrary observable)
• map-timeseries (for a time-varying 2D data product with spatial indexes, and arbitrary observable)
• datacube (for a 3D data product with spatial indexes, and arbitrary (non-time) 3rd dimension axis and observable)

Things like a image of a given polarization, or a polarization map, should be indicated by using the o_ucd.

-- JuanDeDiosSantanderVela - 07 Mar 2011

Comments on Juande's suggestion -- MireilleLouys - 09 Mar 2011

What would be the difference between image and map? image has flux as observable?

I like this kind of classification with only one field and no subtype needed.

Notice that dataproduct_type is not nillable, and should be filled by the data provider.

For instance:

• I do not find a category for my data set : I choose "other"
• I forgot to fill in dataproduct_type and leave it to NULL: it is not a valid implementation of Obstap

In this case I guess 'other' helps to distinguish missing entries.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->