[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Simple file header
- To: imgcif-l@bnl.gov
- Subject: Re: Simple file header
- From: Andy Hammersley <hammersl@esrf.fr>
- Date: Mon, 17 Nov 97 20:24:57 +0100
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]
- Prev by Date: RE: Simple file header
- Next by Date: Slight change
- Prev by thread: RE: Simple file header
- Next by thread: Correction of typos
- Index(es):