Discussion List Archives

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

Re: Simple file header


Here I'm responding to the points raised by Herb:

> There is an audit.creation_date which has a yyyy-mm-dd type code.  I would
> suggest adding a new audit.creation_time tag for the time.  I think it
> would be easier for people to read than the composite format in an
> audit.creation_datetime.

I seem to remember a *_datetime data item was previously mentioned.
I'd prefer to see both date and time together in a single item.

PowderCIF defines a date item '_pd_meas_datetime_initiated' as (here I quote):

"The date and time of the dataset measurement. Entries follow the standard
CIF format 'yyyy-mm-ddThh:mm:ss+zz'. Use of seconds and a time zone is 
optional, but use of hours and minutes is strongly encouraged. Where 
possible give the time when the measurement was started rather than 
when completed."

(This comes from version 0.99 of the dictionary, so may be slightly out of
date.) I think the time format comes from an ISO standard, but I don't know
the number associated with the standard.

Perhaps we should be thinking of creating a new data item within the
_diffrn_measurement category. e.g.

_diffrn_measurement.creation_datetime

which could be defined as the time file was created, which is realistically
the information which a program could most easily and reliably obtain. 

> I would suggest that categories not be mixed in loops in the header.  While
> we could straighten this out in translating to a "real" DDL2 CIF, it really
> is worth the trouble to define all the necessary parent/child relationships
> and pointers to keep each loop cleanly representing a single category.
> This makes mapping into databases much simpler and makes some common errors
> in loop structuring easier for people to find.

I appreciate Herb's desire to keep things simple, although there is still
the basic question of what is a very perverse CIF writer allowed to do and
still be technically correct ?

So to keep things simple I would prefer all the items describing aspects
of the different dimensions of an array to be part of the same loop 
structure, and therefore part of the same category. In the present proposal
'_array_element_size.size' is in a category "by itself" (together with
'_array_element_size.array_id' to relate to items in other categories).

I would prefer to see it included in the same overall category e.g
(Maybe '_array_structure' should be '_array_structure_list' instead ? see 
final paragraph.)

# Define dimensionality and element rastering
loop_
_array_structure.array_id
_array_structure.index
_array_structure.dimension
_array_structure.precedence
_array_structure.direction
_array_structure.element_size
image_1    1      768    1    increasing    100.5e-6
image_1    2      512    2    decreasing     99.5e-6

Arguably the element size is a different sort of information to the
rest of the items in this category, so I can see the reason for defining
a different category, but I think that practically the above category 
structuring would be easier to work with.


> In DDL2 it is legal to have one data block in which tags with a single
> value appear without a loop_ and another data block in which the same tags
> are used in a loop_, but you might find it easier to create your software
> if you always use those tags in a loop_.  This will also avoid some
> problems if a DDL1.4 version to use with powder data should be needed.
> More a question of style than anything else.

So reading software should really be able to cope with these items appearing
within a loop_ and appearing separately. However, my example should arguably
encourage potential writers to put the items in a loop_. I'll change it,
although perhaps in a later, as yet unwritten, section I'll try to cover
technically correct but not encouraged possibilities, which an ideal
input program would nevertheless be able to cope with.

Again the question of how many categories arises, although here there are
more items in each of the proposed categories:


(Something I should have asked about before, which may just be my lack
of understanding of DDL2. John defines an '_ARRAY_STRUCTURE' category
and an '_ARRAY_STRUCTURE_LIST' category. However when the 
'_ARRAY_STRUCTURE_LIST' are defined the '_list' is dropped from their names.
Is this normal ?)


   Andy





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.