Discussion List Archives

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

Re: Opinions on comments as part of the content

Brian McMahon wrote:
> A lot of good stuff in this discussion. One thing it brings out
> is the dichotomy between the "simple" approach - stick a CIF in vi,
> memorise the CIF dictionaries, stick in a few comments to remind
> other readers why we've done something that way and the "formal"
> approach of mechanise all i/o with reference to dictionaries
> and/or stylesheets. CIF sits astride both camps, albeit somewhat
> awkwardly.  The editorial staff at the IUCr can edit and manipulate
> small-molecule CIFs pretty well, and a generation of Acta C/E
> authors can also do so, with varying levels of proficiency. The
> editorial staff at RCSB can even do it with mmCIFs, but the
> complexity of a full structure description in an mmCIF stretches
> people to the limit, and in collections of data sets, whether
> coreCIF or mmCIF, we really do need formal validation mechanisms.
> 
> There are clear similarities between the hand-edited HTML pages
> of the early web, and the schema-driven content management systems
> of today's big Web applications. And perhaps, as on the Web, one
> needs to be able to support both approaches.
> 
> It may be that the next cycle of major CIF development will
> be able to produce a cleaner implementation that is essentially
> fully dictionary-driven: but there will still need to be legacy
> support for the archival CIFs (or a major effort to remediate
> all existing CIFs to a cleaner form).
My feeling is that the simple approach is important. It is the main
advantage of a plain text format. If you cant hack it with vi, why not
just use a binary format? Even the Web uses JPEG/GIF binary for 'visual
array data'. The point of CIF, I thought, is to keep things human readable.

> 
> Enough philosophy - but it's relevant to my next comment. Joe wrote:
> 
>> I know that global_ is not part of CIF, but neither is this hack for
>> using data_global. CIF says global_ is reserved for possible future use.
>> Obviously people want a global_, so let's include it.
> 
> If you read Chapter 5.2 of International Tables G carefully,
> you will see that the semantics of global_ inheritance in STAR are
> actually rather subtle (especially if you also have save_frames
> in a STAR file). Although one thinks one knows how to use global_,
> I suspect it would be very easy to introduce unexpected inheritances
> or context faults, particularly in typical FORTRAN programs or in
> manual vi editing. Among other things, it breaks the ability to easily
> re-order data blocks. Peter's probably correct that the implied semantics
> of data_global are dangerous (although everything should work OK in
> Acta CIFs, since care is taken to partition the data names between
> blocks in a way that should circumvent collisions of data name). I
> still think it would be better to resolve this dilemma by formally
> relating the purpose of distinct data blocks in an AUDIT_... category,
> rather than by opening the doors to the elegant, but rather dangerous,
> global_ block.

My view is that is is more sensible to redefine GLOBAL_ than to add on a
new hack for data_global. Either way, the rules have to change. I am
assuming that nobody else uses the STAR format, so that redefining
GLOBAL_ does not break anything, but I could be wrong.

If you want to actually define some sort of scope inheritance, why limit
it to a single magic data block? Wouldn't it make more sense to have
some sort of scoping directive within a data block (i.e inherit
data-block XXX). Of course, I am thinking in terms of CIF being mostly
self-described, and not completely dependent on a dictionary.

Joe
_______________________________________________
comcifs mailing list
comcifs@iucr.org
http://scripts.iucr.org/mailman/listinfo/comcifs

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

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

ICSU 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.