CommentsIn 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 2011I 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:
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:
| ||||||||
Added: | ||||||||
> > | -- IgorChilingarian 08 Mar 2011 What data product type will be appropriate to describe multi-object spectroscopy? Presently, a large fraction of all spectra provided by modern facilities come as multi-object (or multi-slit). Well, when the calib_level=2, normally one would expect the spectra to be extracted from the dataset and published one-by-one, then the "spectrum" is fine (we have to think what Observation ID to attach). But in case of lower calib_level values, the reduced spectra obtained during the same exposure are often presented in some specific formats (e.g. Euro3D, ESO FLAMES) just like "all in one". I would definitely disagree to call it "other". Juan De is proposing to use a fine-grained data product type, but this we have to discuss in more detail | |||||||
Back to TOP discussion page
<--
|