Discussion List Archives

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

Re: [Imgcif-l] proposed change in first line of imgcif files

Dear Herbert:

Our bone of contention in a nutshell is that you want the header to take
precedence, and I want the tags to take precedence.   I think that if the
contents of a comment are allowed to override values in the body of the CIF,
we are changing a fundamental aspect of the CIF standard (i.e. that comments
are irrelevant and that all information is contained in tag-value pairs), so
if we do end up wanting priority for the header information, then I think we
should run it by COMCIFS.

You write:

We are _not_ providing just a convenience header.  We are providing
> critical information that major software packages will count on to
> correctly parse certain CIF files.


Just to be clear, by 'parse' I understand 'separate into tags and values'.
I prefer the term 'interpret' i.e. I would say that this is critical
information for *interpretation* of the frame data.  What is your intended
meaning?

The critical information that we are providing in the header is *already
available* within the CIF file, but these major software packages would
prefer not to access that, presumably because it is inefficient to do so
and/or it would imply a more flexible internal representation of the
experimental geometry.  The header is therefore more convenient, and the
critical information is available in a less convenient form even without the
header.  How is this not a convenience header??

No matter what we say, that magic
> number will override any conflicting information deeper into the file
> for those packages.  In an ideal world, the information deeper in
> will not conflict, but when there is a conflict, it is highly unlikely
> that processing will be stopped if the resulting data makes any sense
> at all to the processing software.


But I agree with you.  If software chooses to rely on the header
information, it can do that and ignore the non-frame-data.  It is just that
the guarantee that header and dataframes match is given by the CIF file
provider, not by the (img)CIF standard.  Software using a convenience header
will not interpret the CIF tags so will not be in a position to detect a
mismatch.

We have a better chance of reducing further growth of conflicting
> dialects by being realistic about what people will do than by
> prescribing rules they are not likely to follow.


Which rules are you talking about?  I am saying, use the header information
all you want, but in the unlikely case that it does not match the file
contents the read might fail.


> We would be
> doing a disservice to users if we tell them they can override a
> magic number by changing a tag further into the CIF when it is not
> likely to work.


But if these major software packages state up front that they rely on the
header, so changing certain tags will not work, what is the problem? And why
is a user editing a raw imgCIF anyway?   And under DDLm, if a user edits a
tag, it is possible to pick up that the 'style'/'version' values are no
longer correct, so there is some safety net possible even in this (highly
unusual) use case.

>
>
>  Once we agree on the relevant tags, I will add the necessary checks
> to vcif2, so that people who care can check for such conflicts, and
> give cif2cbf the ability to regenerate files with the conflicts
> resolved, but I think we need to accept the reality that we have
> no real control over what people will do in the field, especially if
> what we specify conflicts with commonly accepted practice.  A standard
> will only be accepted by this community if it grows organically from
> within the community, and we have had a strong, consistent and reasonable
> request for clear specification of the necessary parse in the first
> line of imgCIF files.


I'm *not* saying that we shouldn't have a statement of how the frame data
should be interpreted right there in the first line.  I'm *not* saying that
a program which uses this information must then read the relevant tags as
well to check for conflicts.  I *am* saying that if, somehow, the datablock
tags and the header mismatch, a program which relies on the header might
fail if the header is in error.  Of course, if instead the tags are in
error, then it will not fail.  Where is the issue?  Harry, (if you are still
reading along), is this an acceptable position from your point of view?

>
>
>  I think it would be fine to move CIF in the direction of really being
> a standard.  The ISO rules are given at
>
>
> http://www.iso.org/iso/standards_development/processes_and_procedures/how_are_standards_developed.htm
>
> ANSI has similar guidelines.  The standards process in time-consuming and
> involves a great deal of consensus building.  I think it would be worth
> trying to do.


I do appreciate the need for consensus, but at the moment it seems that you
and I are the only ones searching for consensus. I am also thinking that the
time has come to instigate some sort of standards process.  Are you thinking
of CIF becoming an actual ISO or ANSI standard, or rather of  implementing
similar processes within the auspices of the IUCr?

Best wishes,
James.


-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
imgcif-l mailing list
imgcif-l@iucr.org
http://scripts.iucr.org/mailman/listinfo/imgcif-l

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links