ext-rep file naming

[Leonard Soicher]

Dear Peter,

I like your well-thought-out suggestions. 

Presumably the t parameter should occur in a file name iff the L
parameter does.

Now I shall see how far I can get in generating all binary block
designs (up to isomorphism) with given (v,b,k).  Thus, my
file names will look like, for example, v6-b6-k3.icgra.xml.gz .

Regards,  Leonard

On Fri, May 07, 2004 at 02:49:47PM +0100, Peter Dobcsanyi wrote:
> Dear All,
> 
> We are going to have hundreds of ext-rep files floating around in our
> system. To make this situation manageable I recommend the introduction
> of an "ext-rep file naming convention". The purpose of such a scheme is
> twofold. On one hand, it makes the system administration and the
> organization of data processing (including external contributions) much
> easier. On the other hand, it can serve as a base for a simple but
> nevertheless useful web presentation method. This means that we can put
> our design collections online within a few days and long before the
> "real" design database actually comes alive.
> 
> My proposal for ext-rep file naming follows. Before the details, let's
> start with an example. An ext-rep file file which contains the Fano
> plane can be named:
> 
>    t2-v7-b7-r3-k3-L1.icga.xml.gz 
> 
> An ext-rep file's name has the following structure:
> 
>     parameter_section[.content_indicators].type[.compression_type]
> 
>     parameter_section:
> 
>         Describe the parameters of the designs in the given file over
>         the parameter domain of t,v,b,r,k,L, where L stands for lambda.
>         The format is xN-...  where x is one of the parameter's symbol
>         and N is the constant value of the parameter within the file. If
>         some of the parameters are not relevant to the given list of
>         designs and/or are not constant then they are left out.
> 
>     content_indicators:         (optional)
> 
>         One letter symbols to indicate which of the subtrees of a
>         <block_design> tree are present for each block design in the
>         file. The possible values:
> 
>             i   <indicators>
>             c   <combinatorial_properties>
>             g   <automorphism_group>
>             r   <resolutions>
>             s   <statistical_properties>
> 
>         It is not required that any of the indicated subtrees is fully
>         expanded.
> 
>         Finally there is a special indicator:
> 
>             a   indicates that all pairwise non-isomorphic designs
>                 of the given parameters are present in the file.
> 
>     type:
> 
>         xml     for XML ext-rep
>         sex     for Lisp S-expressions
> 
>     compression_type:           (optional)
> 
>         gz      gzipped file
>         bz2    
> 
> As you know each design should have a ID. This ID is created from the
> "parameter_section" of the file name by appending '-N' where N is a
> serial number within the file starting 0. (Note, we use 0-based indexing
> elsewhere in the ext-rep.)
> 
> For the time being, we should arrange our design collection (i.e.
> ext-rep files) in a simple and logical directory structure, like:
> 
>     designs/
>         t-designs/
>         ...
> 
> Some remarks are due to place the proposed naming into the correct
> perspective:
> 
>     - This naming scheme is not a replacement for the database and it
>       cannot (should not) provide the same level of consistency. In
>       particular, the IDs won't be necessarily unique.
> 
>     - There can be overlaps between files, that is OK.
> 
>     - Although it is human readable, the more important design aim
>       behind it was to be able to parse/process/search this system by
>       simple automatic tools.
> 
> 
> Please comment,
> 
> --             ,
>     Peter Dobcsanyi
> 
> _______________________________________________
> Developers mailing list
> Developers at designtheory.org
> http://designtheory.org/cgi-bin/mailman/listinfo/developers