Discussion List Archives

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

Re: Revised statement of policy on CIF

  Please note that the discussion has come around to the "IUCr see[ing] its
roles as the *maintainer of the STAR/CIF standard*"  There is a way to do
this so that we are truly supporting software development and do not run
afoul of various anti-trust laws.  Please consider getting involved in the
ISO approach to the development of standards.  This has worked very well
for programming languages.  If we are speaking of a STAR/CIF standard --
then let us create a real STAR/CIF standard.
  In Syd's hierarchy, I would suggest dropping dRel down to the same level
as DDL, and trying for two levels of metalangauge instead of three.  Two
should be enough.
  -- Herbert

At 4:27 AM +0100 3/30/00, Sydney R Hall wrote:
>Brian T's and John's comments are important.
>I do understand Brian's concern but I would worry about John's solution!
>At the risk of sounding like Herbert on the need for precise wording (:>)
>the use of "should be able" gives so much latitude to this statement that
>even I could "sail the Queen Mary" through it!
>I think the Brian's query goes to the heart of what I have been worrying
>about for sometime now... namely "what is a CIF and what isn't". I believe
>that we are lacking careful and well-understood distinctions between the
>various data handling processes (or languages) we have built and are
>building. In my view it is essential that we reach a common understanding
>on what is the difference between, for example, CIF data and a CIF dictionary.
>Specifically, by referring to "CIF conformance" do we expect that a parser
>has to handle save frames because they exist within DDL2 (and future DDL's),
>and, indeed, do we expect all CIF parsers to "understand" dictionaries and
>their attributes (DDL1 and DDL2)? I would say "no" but I am sure there will
>not be universal agreement on that within this group.. and I understand why!
>Here is a rather primitive attempt to make these distinctions.
>What we have in this field may be thought of as "layered concepts"...
>   0    STAR File   fundamental      STAR parser      StarBase
>                    exchange         in StarBase
>                    syntax
>   1    CIF         crystall.        CIF parser       Quasar... many
>                    appl. of
>                    STAR File
>   2    DDL1        dict. def.       DDL1 parser/     Xtal, ciftbx
>                    language 1       interpreter      ... many
>        DDL2        dict. def.       DDL2 parser/     ciflib, ciftbx
>                    language 2       interpreter
>   3    dREL        relational       dREL parser/     IDAS
>                    expression       interpreter
>                    language
>I have used the term "layered" because there are dependencies between
>the more advanced concepts and those in the lower layers. But I emphasise,
>as have others, that we shouldn't get too carried away by this model because
>it would not be difficult to separate the dictionary and dREL concepts from
>the CIF or STAR syntax requirements and still retain the overall
>In other words it would not be difficult to caste the dictionaries and any
>future developments into XML and still be able to process CIFs or any other
>universal files. Indeed, considering the growing commercial support for
>languages such as XML, this is a serious possibility. One, however, that I
>would like to offset, because, in my somewhat biased view, the CIF/STAR
>syntax is more concise and simpler to understand for the average scientist.
>By offset I mean that we strengthen the CIF/STAR role in future developments
>by making it very clear that IUCr sees its roles as the *maintainer of the
>STAR/CIF standard* and the *regulator of crystallographic* dictionaries.
>AND that it will promote, and perhaps even support, developments that will
>extend its capacity in this endeavour. MORE SPECIFICALLY it does not claim
>"ownership" over concepts such as DDL or dREL, or over software that are
>used in their implementation. I believe that it would be hard pressed to
>do otherwise, but it is *clarity* on this issue that is badly needed if
>we are going to entice developers and other disciplines into using this
>If we achieve this clarity developers can go about their business mindful
>of the standards and the regulatory role of COMCIFS for crystallographic
>dictionaries (and therefore the form the future *crystallographic* DDL's may
>take), but not be constrained in the scope of the tools they build for our,
>or any other, discipline.
>How does this sound as an "IUCr vision" for the future of data interchange?
>Cheers, Syd.
> syd@crystal.uwa.edu.au         ,-_|\       Professor Sydney R. Hall
>                               /     \      Director, Crystallography Centre
> Fx:  61(8)9380 1118       --> *_,-._/      Deputy Executive Dean of Science
> Ph:  61(8)9380 2725                v       University of Western Australia
> www.crystal.uwa.edu.au                     Nedlands 6907, AUSTRALIA.

****                BERNSTEIN + SONS
****     P.O. BOX 177, BELLPORT, NY 11713-0177
*   * ***
**** *            Herbert J. Bernstein
  *   ***     yaya@bernstein-plus-sons.com
 ***     *
  *   *** 1-631-286-1339    FAX: 1-631-286-1999

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.