AccessFormat < IVOA

IVOA Web>IvoaDataModel>ObsDMCoreComponents>AccessFormat (2011-03-15, FrancoisBonnarel) (raw view)

   +*Access Format*  

   1.Semantics should probably define those. 
      How is the timescale for a good enough list of values?
   1.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.

-- IVOA.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)

-- IVOA.FrancoisBonnarel- 15 Mar 2011



Back to [[IVOA.ObsTAPdraftDiscussion][TOP discussion page]]













<br/>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Topic revision: r6 - 2011-03-15 - FrancoisBonnarel

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema