Filenames in accref

[Laurent Michel]

Hello,

The naming rule of the XMM pipeline files shows a good balance between metadata contained in these names and their robustness in 
any context. There is no risk of character escape issue in URLs e.g.

File names match
     P[A_Za_z0-0]{26}.extension

Meta data are encoded as follow:
     P[observation id][intrument][exposure][product identifier][energy band][source number]

Example: A master source list of a given observation P0132520301EPX000OBSMLI0000.FIT
   Observation id: 0132520301
   instrument: EP (merge of the 3 EPIC cameras)
   exposure: X000
   Product OBSMLI (Observation master source list)
   Energy band: not set
   Source number: not relevant for this porduct

This information is quite simple to extract from the file name and it is sufficient to set up relevant queries in any XMM 
archive or TAP service.

Cheers
Laurent

Le 12/06/2012 15:00, Markus Demleitner a écrit :
> Hi Petr, hi list,
>
> On Mon, Jun 11, 2012 at 01:01:34PM +0200, Petr Skoda wrote:
>> We are going to change our format for spectra filenames as the
>> current format was intented many years ago as DOS (8.3) compatible
>> and now we are facing problem similar to Y2K ;-) in our case Y2016.
>> To keep name short but verbose we have used format YMddnnnn.fit
>> where Y was year as letter after 1990 (a=1990, b=1991 ...) and M
>> letter of index of month (a=Jan, 2=Feb ....)  dd - night of
>> observatiton and nnnn index of exposure that night (since first).
>> [...]
>> Even if everything could be escaped in principle, I guess there might
>> be some sound rule how to create such a names to be easily reused in
>> VO databases, Votables, accref fields etc and probably it is better
>> to avaid some delimiters.
>>
>> Could you comment on this - and help us to avoid surprizes or weird bugs ?
>
> Well, the one thing I'd recommend is to steer clear of everything
> that needs to be escaped in URLs, in particular with a view to
> TAP-based services, where clients will/might see more or less "raw"
> data and keeping track of what's encoded and what's not yet is just
> another complication that's easily avoided.
>
> A particularly insidious character that unfortunately is quite luring
> in astronomy is the plus ("+") -- it may be "unescaped" to a blank by
> various server software, and contrariwise, blanks may get "escaped"
> to plusses by client software.
>
> For simplicity, I always recommend the following rule: Keep it
> matching to [A-Za-z0-9_.-]+  And don't try to stuff too much metadata
> into the file name: that's what the metadata tables and file headers
> are for.  So long as you know it's going to be unique to a dataset,
> you should be fine.
>
> Cheers,
>
>            Markus
>

-- 

---- 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: 391 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dal/attachments/20120613/1214b22f/attachment.vcf>