Discussion List Archives

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

Re: CIF formal specification

The "in general" on the row ordering means "in general".  A careful
reading of the semantics of most CIF loops shows that they follow
SQL-like rules on row ordering -- the rows can be presented
in any order without changing the meaning of the table.  However,
that is not an explicit rule of CIF syntax (as opposed to the
semantics constraining the way it is used).   When possible,
I think it would be desirable to provide columns which allow
any and all order dependencies to be resolved from the content
of the rows, rather than from context (e.g. atom serial numbers
in atom lists), but I, for one, would be opposed to making
that a syntactic requirement, especially in view of the man
existing CIFs that do not comply.

The table merge/split rules are a difference in semantics between
DDL1 and DDL2.   Again, in most cases, SQL-like rules are followed,
so this is an infrequent problem.  I think the current proposed
wording is a fair representation of facts on the ground.

I understand the desire to have a parser that will be aware of
all the equivalences and symmetry violations, but as will any
powerful and evolving language (including XML for that matter),
some things need to be left to the applications.

Regards,
  Herbert
=====================================================
 Herbert J. Bernstein, Professor of Computer Science
   Dowling College, Kramer Science Center, KSC 121
        Idle Hour Blvd, Oakdale, NY, 11769

                 +1-631-244-3035
                 yaya@dowling.edu
=====================================================

On Mon, 7 Mar 2005, Peter Murray-Rust wrote:

> 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
>
> _______________________________________________
> comcifs mailing list
> comcifs@iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>

Reply to: [list | sender only]