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: | ||||||||
> > |
AnitaRichards 09 Mar 2011
p15 3.3.1 Data Product Type Is it worth stating explicitly that visibility data is likely to be in formats such as FITS, Measurement Sets (MS) or Science Data Models (SDM, ASDM etc.) (usually distributed as tar or zip directories) - just so that implementors can recognise the type of the latter, relatively new formats?
Should metadata only (as VOTable?) be included as a data product type, see comment on 4.6
p17 3.3.3
I find that the discussion in paras 3, 4 adds confusion to the nice clear description in 3.3.2 - why are aggregates of multiple files limited to levels 0 or 1 (e.g. MS, CASA-format images are directories but can be completely calibrated and science-ready or even advanced products)? Surely the approaches adopted are up to the provider. Either cut it down or leave it out, or replace it with more fully described examples from specific archives?
p20 4.3 For e.g. MERLIN+VLA images, is 'MERLIN+VLA' acceptable a) logically b) is '+' allowed or should it be and or ...? - guideance on allowed characters?
DougTody 10 Mar 2011
ObsTAP per se does not specify the possible file formats, it just allows
them to be described. The plan is to address this file format issue
mainly in the access_format specification. This is still being
specified, but we are in the process of looking at ALMA, EVLA and others
to see how well they map onto {collection, dataproduct_type/subtype,
calib_level, access_format} which should be sufficient to fully specify
what a data product is.
If the "data product" (tar, directory, etc.) being described is a
collection of instrument-specific files, regardless of their individual
calibration level, it is still an instrument-specific data product.
Hence probably level 1. The instrument signature has to be removed to
get to level 2-3. Level 1 may be calibrated, it is whether it is an
insrument-specific data product which is the issue here.
If instead of a tar or a dir the individual data products are exposed
then they can have separate calibration levels. An image or cube for
example could be level 2-3. But if they are all together as an
instrument "observation" grouping (tar or dir) then they are probably
instrument specific. Of course, it is up to the DP to make the final
decision on the calibration level.
PatrickDowler 09 Mar 2011 to Anita
> p15 3.3.1 Data Product Type > > Is it worth stating explicitly that visibility data is likely to be in > > formats such as FITS, Measurement Sets (MS) or Science Data Models (SDM, > > ASDM etc.) (usually distributed as tar or zip directories) - just so that > > implementors can recognise the type of the latter, relatively new formats? The access_format will say if it is FITS (application/fits is a valid value of that column). -- AnitaRichards 09 Mar 2011 It is not FITS I am worried about, it is the newer formats - but as it list is extensible it is not a big issue. | |||||||
Back to TOP discussion page
<--
|