Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CIF formal specification

At 20:50 03/03/2005 -0500, Herbert J. Bernstein wrote:
><snip/>



>   The proposed new wording is not accurate.  There is significance to
>the ordering of data names, but certain reorderings do not change
>the meaning of the CIF. I would suggest the following combined rewrite
>of 7:

The following is very helpful. In essence it formalises the strategy that I 
have employed in CIFDOM - the contents of a CIF may be re-ordered in 
various ways without affecting any meaning. Of course this may surprise, 
and even upset, some humans and it may be important to provide tools that 
can reassure them - e.g. to display their tables in a favorite internal order

>7. A given data name (tag) (see 2.4 and 2.7) may appear no more than
>    once in a given data block or save frame.  A tag may be followed
>    by a single value, or a list of one or more tags may be marked by
>    the preceding reserved case-insensitive word loop_ as the headings
>    of the columns of a table of values.  White space is used to
>    separate a data block or save frame header from the contents of
>    the data block or save frame, and to separate tags, values and
>    the reserved word loop_.  Data items (tags along with their
>    associated values) that are not presented in a table of values
>    may be relocated along with their values within the same data
>    block or save frame without changing the meaning of the data block
>    or save frame.  Complete tables of values (the table column headings
>    along with all columns of data) may be relocated within the same
>    data block or save frame without changing the meaning of the data
>    block or save frame.  Within a table of values, each tag may be
>    relocated along with its associated column of values within the
>    same table of values without changing the meaning of the table of
>    values.  In general each row of a table of values may also be
>    relocated within the same table of values without changing the
>    meaning of the table of values.

I am not sure what "in general" means. It suggest that there could be some 
implied semantics (e.g. who is first author, that the symmetry operations 
are in a known order (- this is indeed the case). I would like to remove 
all such implied semantics with explicit tags (although there are clearly 
some current instances where it is a problem).

>  Combining tables of values
>    or breaking up tables of values would change the meanings,

This is certainly true

>and
>    is likely to violate the rules for constructing such tables
>    of values.

I can see that this might violate some higher level semantics (e.g. 
references to components of tables) but I don't see that it violates 
anything in CIF or DDL1.

>I apologize for the complexity of this, but it is actually harder to
>specify the meaning of an unordered set than it is to specify the
>meaning of an ordered tuple, since the former requires specification
>of equivalence classes, while the latter does not.

I agree that something of this formality is what is required.

P.


Peter Murray-Rust
Unilever Centre for Molecular Informatics
Chemistry Department, Cambridge University
Lensfield Road, CAMBRIDGE, CB2 1EW, UK
Tel: +44-1223-763069

Reply to: [list | sender only]