[obs-tap]access_format

[Douglas Tody]

Hi Mark -

This is addressed in the next version of this section which will be in
the updated ObsTAP draft (out soon).

 	- Doug


On Tue, 26 Apr 2011, Mark Taylor wrote:

> If Doug's assertion and Laurent's opinion (mine also) that filename
> and format are decoupled are in fact the case, then the text from
> Mireille's message is confusing and needs to be changed.  It currently
> says:
>
>   In this case extension file name convey the information directly
>   on the file content.
>
> Mark
>
> On Thu, 21 Apr 2011, Douglas Tody wrote:
>
>> The access_format attribute has nothing to do with filenames, rather
>> it describes the format of the file which would be returned from the
>> remote archive.  This is also distinct from whether or not compression
>> is used in the transport protocol; it refers only to the file which
>> the client ultimately sees.  Rob - this does try to include support
>> for things like tile compression, which is just another variation on
>> the FITS file format.
>>
>> 	- Doug
>>
>>
>>
>> On Wed, 20 Apr 2011, Laurent Michel wrote:
>>
>>> 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
>>>
>>> NOTE: I apologize if this message arrive twice on the list. I've some
>>> trouble with it since I changed my Email address.
>>>
>>> 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
>>> ---
>>>
>>
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>