[obs-tap]access_format

[Laurent Michel]

Dear all,


I do not agree with the idea that compression must be infered from the filename suffix for data files compressed after 
construction. The filename can be, for instance, a service URL which has no reason to ends with a compression suffix (e.g. 
http://service.my.domain/getfile?compressed=yes&filname=mydata.fits).
I'm not sure that the after-built compression must be notified in the access_format column considering that this issue has been
solved by all clients. Can't we simply consider that file.fits and file.fits.gz are both fits file?

Regards
LM

On 19/04/2011 17:10, Mireille Louys wrote:
> Dear all,
>
> Here is the short text I suggest to have for access_format.
>
> 4.7. Access Format (access_format)
> The access_format column emphasizes information about the format of the data product if downloaded as a file. The values should
> describe (in increasing detail) the overall file format as well as the structure of the data within the file.
> This data model fields is important to evaluate for data discovery and data retrieval.
> MIME types can be used for that in existing protocols ( like http). However, when dealing with observations as in ObsTAP
> service, more information about the astronomical arrangement of data into predefined formats is very useful . For instance we
> want to distinguish between various formats like aedm (ALMA) , evla, MUSE multi-extension fits files( IFU) etc?
> Providing this information speeds up the interpretation step for client application consuming these files on one hand , and
> improves data selection in the discovery step on the other hand.
> Some data collection offer data sets are as multi-files and distribute them as as directory or tar format
> Here we consider a list of possible MIME-type strings for various types of observational datasets
> This could be extended or modified after implementation experience.
>
> MIME-type Shortname Definition
> application/fits fits
> application/xml xml
> application/x-votable+xml votable
> image/fits fits.image any multidimensional
> regularly sampled data cube, etc?
> image/jpeg jpeg
> application/x-aedm aedm ALMA Export Data Model
> application/x-ms ms Radio measurement set
> application/x-euro3D euro3D imaging spectroscopy
> application/pdf pdf graphs stored as document: filter curve,
> footprint, spectrum profile, etc.
> application/dvi dvi graph
> text/csv csv comma separated value
> text/tsv tsv tab separate value
> text/html html texte in HTML format
> application/x-tar tar multiple files archive in tar format
> application/x-directory+text dir multiple files set as text list
>
> Compression may be applied at different levels:
> ? after the data file is built
> ? after binding a bunch of files into an archive file (like in .gzip,
> .7zip, .gz, .tar.gz, etc.)
> ? directly on the file content (jpeg, hcompress in fits images, multi-resolution compression (.MRC files as in MR/1 application)
> In this case extension file name conveys the information directly on the file content.
> No suffix means there is no compression applied.
> Example of combined access format could be a concatenation of mime short name , with compression suffix.
>
>
>
>

-- 

---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurent_michel.vcf
Type: text/x-vcard
Size: 357 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20110420/864a9b4f/attachment.vcf>