[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Absence of _item.category_id or _item_linked.parent_name in somemmcif definitions
- Subject: Re: Absence of _item.category_id or _item_linked.parent_name in somemmcif definitions
- From: yayahjb <yayahjb@xxxxxxxxx>
- Date: Fri, 21 Dec 2012 07:35:42 -0500
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;h=x-received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;bh=mFhHUmkMcBg9SfYYOpKkYc7I+G+W8lahx5SyH7TT+bU=;b=nUIKydKpwBPGddpjTm7VC+UzfgDRfmbDBTUYMOtBBCqo+drmBuFz1pHUchOeeHhwL8NCOuzMQmvIfHGiTrsd9MFi5SQkUspWGUOJxn0VwctNx+DK5nVRuczySBOaNe9amtVP5pCbxBaR+wB5yWvLd/Q5eLovcKMaNfnUyopKYZsWpzZfYnMFaKte6Bvc48ADSQ+Jx9F+LskLF3uhRVNG56/1hFOuNk28dcBSmUXs3IRbT4zVrmPyrZF1DWeW0x+73+n9kYRqKker3imDyP7cQotsz/TMDljGu1DfKmKNN811WGQ/UvThJOWKf6L1WKgdiFsCAiPWX/Csz3N1MFiHxA==
- In-Reply-To: <CAM+dB2dv9=xQPBok-hKEMFNVck+_0L6PK2xmc6qzJuy-uyjWYQ@mail.gmail.com>
- References: <CACCG97GtT4pdy+2NwmDrwPqCcLzhQMMqQaQuD2-uLggKDi-P-A@mail.gmail.com><CAM+dB2dv9=xQPBok-hKEMFNVck+_0L6PK2xmc6qzJuy-uyjWYQ@mail.gmail.com>
Dear Colleagues, This is not a matter of something being missing from the mmCIF dictionary. John W. tried explaining this a few years ago. I'll give it a shot this time, but in view of the continuing problems in reading the DDL2 dictionaries, I will also suggest a change. In this case, even though as a technical matter it ain't broke, as a practical human engineering matter, something is broke so we _should_ fix it. In the mmcif dictionary, the definitions of individual tags are _not_ in general completely contained in a single save frame. For example, as James notes, the category and parent name for _atom_site_anisotrop.id are explicitlygiven in a loops in the _atom_site.id save frame: loop_ _item.name _item.category_id _item.mandatory_code '_atom_site.id' atom_site yes '_atom_site_anisotrop.id' atom_site_anisotrop yes '_geom_angle.atom_site_id_1' geom_angle yes ... loop_ _item_linked.child_name _item_linked.parent_name '_atom_site_anisotrop.id' '_atom_site.id' '_geom_angle.atom_site_id_1' '_atom_site.id' ... The two alternatives to this approach would be ether to move the information from the parent save frames to the children, or to duplicate the information. Duplication may help in readability, but it is a maintenance headache. The DDLm solution of only requiring/allowing specification of parents, rather than children would be similar to moving this linking information from loops in the parents into the children in DDL2. My suggestion would be to move to the DDLm approach in the DDL2 dictionaries, of putting the parent information with the children, rather than the children information with the parents in the formal dictionary, without duplication to minimize maintenance problems, but that Brian's nice formatting program be modified to gather the child information so that it is printed with the parent information as well as with each child to help people in reading these dictionaries. I would suggest doing the same for the DDLm dictionaires: provide print formatting tools to gather child information relating to a parent to put with the parent as a useful index. Regards, Herbert On 12/21/12 1:26 AM, James Hester wrote: > I will have a stab at this, although somebody with more experience of > the mmCIF development process may wish to comment further. > > As far as I can tell, programmatically the only way to fix the > 'missing parent' problem you identify is indeed to go through the > entire dictionary processing 'item_linked.parent_name' and > '_item_linked.child_name' loops, which are usually found at the top of > the pointer tree (in this case in the _atom_site save frame). This > same save frame also contains a list of category ids for each of the > 'id' values. My approach in PyCIFRW is to repopulate the individual > definitions when ingesting the dictionary, to save time later. The > PyCIFRW code and comments for this can be found at > https://bitbucket.org/jamesrhester/pycifrw/src/78576030f75bb4f8cb52d84a60e603815ad38afb/pycifrw/CifFile.nw?at=stable > starting at line 839, with lines 854-862 describing and discussing > your issue. Note also subsequent lines discussing PDBX. > > There is a school of thought that the category name is 'implicit' in a > DDL2 dataname or save frame name, however IT Vol G states that this is > conventional rather than required so I prefer (like you it seems) > never to assume this unless given no alternative. > > An mmCIF/PDB person may wish to comment on the philosophical reasons > behind these decisions, which I gather have something to do with > taking a relational database view of a CIF file. > > all the best, > James. > > On Thu, Dec 20, 2012 at 1:32 PM, Richard Gildea <rgildea@gmail.com > <mailto:rgildea@gmail.com>> wrote: > > Dear All, > > Certain definitions in the mmcif dictionary (e.g. > _atom_site_anisotrop.id <http://atom_site_anisotrop.id>) do not > contain the items _item.category_id or _item_linked.parent_name. > Without these data items, how is it possible to identify > programmatically that _atom_site_anisotrop.id > <http://atom_site_anisotrop.id> belongs to the > _atom_site_anisotrop category and that it is a pointer to > _atom_site.id <http://atom_site.id> (without examining every save > frame? > > For quick reference here is the definition in question: > > save__atom_site_anisotrop.id <http://save__atom_site_anisotrop.id> > _item_description.description > ; This data item is a pointer to _atom_site.id <http://atom_site.id> in the ATOM_SITE > category. > ; > _item.name <http://item.name> '_atom_site_anisotrop.id <http://atom_site_anisotrop.id>' > _item.mandatory_code yes > _item_aliases.alias_name '_atom_site_aniso_label' > _item_aliases.dictionary cif_core.dic > _item_aliases.version 2.0.1 > save_ > > > Cheers, > > Richard > > _______________________________________________ > cif-developers mailing list > cif-developers@iucr.org <mailto:cif-developers@iucr.org> > http://mailman.iucr.org/mailman/listinfo/cif-developers > > > > > -- > T +61 (02) 9717 9907 > F +61 (02) 9717 3145 > M +61 (04) 0249 4148 > > > _______________________________________________ > cif-developers mailing list > cif-developers@iucr.org > http://mailman.iucr.org/mailman/listinfo/cif-developers > _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://mailman.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- Follow-Ups:
- References:
- Prev by Date: Re: Absence of _item.category_id or _item_linked.parent_name in somemmcif definitions
- Next by Date: Re: Absence of _item.category_id or _item_linked.parent_name in somemmcif definitions
- Prev by thread: Re: Absence of _item.category_id or _item_linked.parent_name in somemmcif definitions
- Next by thread: Re: Absence of _item.category_id or _item_linked.parent_name in somemmcif definitions
- Index(es):