Discussion List Archives

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

Re: Revised statement of policy on CIF

  • To: Multiple recipients of list <[email protected]>
  • Subject: Re: Revised statement of policy on CIF
  • From: Sydney R Hall <[email protected]>
  • Date: Thu, 30 Mar 2000 04:27:33 +0100 (BST)
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"...


 LAYER  LANGUAGE    PURPOSE          PROCESSOR       "PRODUCTS"

------------------------------------------------------------------------------

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

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

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.

------
 [email protected]         ,-_|\       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.