_symmetry_equiv.id and symops.

• Messages sorted by: [ date ][ subject ][ author ]
• Next message: herbert_bernstein: "segment identifiers"
• Previous message: Nancy O. Manning: "Protein Data Bank Contents Guide"

Hi all,

In the description of _symmetry_equiv.id, we have:

;              The value of _symmetry_equiv.id must uniquely identify
               a record in the SYMMETRY_EQUIV category.

               Note that this item need not be a number;  it can be any unique
               identifier.
;

But, the ITEM_TYPE_LIST defintion for a symop item says:

               symop    char
               '([1-9]|[1-9][0-9]|1[0-8][0-9]|19[0-2])(_[1-9][1-9][1-9])?'
;              symop item types takes the form n_mmm, where 'n' is the value of
               _symmetry_equiv.id that corresponds to the relevant value of
               _symmetry_equiv.pos_as_xyz and 'mmm' are the concatenated cell
               translations along x, y, z with respect to the base number 555.
[snip...]
;

The problem is that the 'n' part of a symop is restrained by the regular
expression to be an integer from 1 to 192 inclusive, so it cannot be used
as a pointer to a symmetry operation if values of _symmetry_equiv.id are
outside this range, or contain non-numeric characters. 

I think that the definition of _symmetry_equiv.id needs to be tightened up:

save__symmetry_equiv.id
    _item_description.description
;              The value of _symmetry_equiv.id must uniquely identify
               a record in the SYMMETRY_EQUIV category.
;
    _item.name                  '_symmetry_equiv.id'
    _item.category_id             symmetry_equiv
    _item.mandatory_code          yes
    _item_type.code               int
    _item_range.minimum           0
    _item_range.maximum           193
     save_

Regards,
Peter.

P.S. Apologies to all for my last mail, suggesting that the dictionary on the 
Rutgers web site had been corrupted. This happened because I followed a 
suggestion from our computer centre here, on retrieving Web files overnight, 
rather than using my usual method to do this. Personally, I'm starting to get 
fed up with this http nonsense - life is just too short!

---Here follows a plea not to abandon ftp in favour of http, for distributing 
information:

With a decent ftp server (i.e. one which understands the REST command) it is 
possible to restart a binary ftp transfer of a file from where the previous one 
left off, so a long file can be retrieved in chunks over several sessions.
Modern Unix ftp clients implement this with the 'reget' command, although you 
can always do it manually by using 'quote' or whatever to send the 'REST' and 
'RETR' commands to the remote server.

If http allows this at all (which I don't think it does), the commonly used 
clients don't implement it, which forces people to restart an aborted transfer 
from the beginning of the file. (Caching makes the problem worse, since Web 
caches generally assume that a stored file is complete, even when it has been 
truncated due to a dropped connection.)

Pretty clients (browsers) make the Web look superficially attractive, but when 
the technology connecting the client and server is inadequate to meet the 
demands being made on it, the best solution is to support a more mature 
protocol, such as ftp.

My 2p worth.
Peter.

• Next message: herbert_bernstein: "segment identifiers"
• Previous message: Nancy O. Manning: "Protein Data Bank Contents Guide"