1. Semantics should probably define those. How is the timescale for a good enough list of values?
2. Call to the community for contribution to build up examples

This field is still being defined (some discussion is given in the document text). A draft specification will appear in a future version of the document. The intention is to specify both the basic file format as well as the astronomy-specific format, and details such as whether compression is used. This is required, for example, to tell the user what software will be required to do anything useful with the data product. While we can specify how to compose this field, and supply some standard values, it will really be up to the broader community and data providers to define specific values to represent all their data products.

-- DougTody 2 March 2011

If the standardisation of the access_format field is not ready for this version, I would propose to leave it out completely to avoid people (mis)using it now, and to avoid non-compliant services polluting the vosphere after the access_format is formalised.

-- AlbertoMicol 4 March 2011

access_format in the draft refers to MIME types, but no real mime types are provided. Real MIME types for FITS files are application/fits for non-imaging, or multi-extension FITS files, and image/fits for FITS files which can be directly interpreted as images. Following IETF RFC4047, image/fits can be generalized for data cubes, as long as the corresponding WCS information is present, and software such as fv can interpret it as a 3D data cube. Even if all of the enumerated values shown in 4.7 and B5.2 (which by the way, are the same) were valid as MIME types, there would be a need to register all of those MIME types, and I think we are served with both image/fits and application/fits.

So, for the whole access_format section, I would use an approach similar to UCD specialization, where we have a vocabulary composed of data formats, dimensionality, and compression.

• Data formats: fits, class, ms, aedm (corresponding to FITS, CLASS, Measurement Set, and ALMA Export Data Model).
• Compression: z, gz, zip, none, embedded (meaning tile compression in FITS, for instance)
• Dimensionality: image, datacube (regular mesh data cube from radio interferometry, or regridded radio OTF, for instance), spatial.spectral (irregular spatial mesh, with possibly irregular spectral binning, such as those from non-regridded radio OTF, IFU, or MOS instruments).

This last field (or subfield) also is interrelated with dataproduct_type and dataproduct_subtype.

If there is no agreement, I think it is easier to remove the field, than to have it without really knowing what to put there, and have it changed anytime later.

-- JuanDeDiosSantanderVela - 07 Mar 2011

I think using mime types from start is required and will be very usefull. Complements (starting by a dot or whatever) may be defined later and keep consistent with previous version (use of wild cards)

-- FrancoisBonnarel- 15 Mar 2011

Back to TOP discussion page