[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Please advise regarding a design of CIF dictionaries for materialproperties
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIF Standard (COMCIFS)" <email@example.com>
- Subject: Re: Please advise regarding a design of CIF dictionaries for materialproperties
- From: David Brown <firstname.lastname@example.org>
- Date: Wed, 28 Sep 2011 12:07:30 -0400
- In-Reply-To: <4E832F86.email@example.com>
- References: <4E832F86.firstname.lastname@example.org>
I would echo Herbert's advice. It is important to keep everything in the right place even if it does increase the size of the dictionary. In particular it is important to make sure that the transformation to DDLm will create no problems. DDL1 took some shortcuts before we realized the importance of avoiding them.
I have more comments below.
Saulius Grazulis wrote:
Although temperature is a single property, the temperatures at which different properties are measured are in principle different temperatures. They will appear in different loops, but they are not the same property. The description should be more specific in the example above, e.g.,Dear COMCIFS members, I have a question about the design of domain-specific CIF dictionaries and would like to ask for your advise (and please accept my apologies and let me know if there is a better mailing list to ask for such questions). I am currently participating in the design of CIF dictionary for the Material Properties Open Database (MPOD) that intends to store all published experimentally measured crystal properties, such as elasticity tensors, dielectric permeability and so forth. All in all there should be about 50 different tensors. Each tensor can be measured at different temperatures or pressures. To preset data convenietly, for both humans and computers, we curretnly plan to put each tensors' measurements into a separate loop. Since tag names may not be repeated int the same data block, we will have to define similar measurement condition tags for each tensor: _prop_elastic_stiffness_temperature _prop_piezoelectric_temperature (_prop_ is a prefix registered for MPOD in the IUCr prefix list). Now, although this is only a small overhead in CIFs, it would be an overkill to specify all these tags separately in a dictionary. Thus, I would like to "contract" the definition of all _prop_<property>_temperature tags into one dictionary datablock: data_prop_temperature loop_ _name '_prop_elastic_stiffness_temperature' '_prop_piezoelectric_temperature' # Other names will follow and may be added in the future releases # of the dictionary _type numb _type_conditions esd _category prop # or prop_temperature ? or prop_elastic? _list both _description ; Specifies measurement temperature of a property in Kelvins. ; _example ; Please see below in this mail... ; Now, my questions are -- is there a problem if: a) tags of the same property are split into several loops in data CIFs?
_description ; Specifies temperature in Kelvin at which the peozoelectric tensor was measured. ;
This should be avoided. It has been used in DDL1, but is not allowed in DDLm. Yes, it makes the dictionary larger, but it keeps everything in the right place. In DDLm the duplication is minimized by the ability to insert the same common description of temperature into many different definitions in the dictionary.b) one dictionary data block describes names that are potentially in different categories (but otherwise have the same characteristics)? For example, would the dictionary entry above be considered correct if we declare _prop_elastic_stiffness_temperature to be in 'prop_elastic_stiffness' category, and _prop_piezoelectric_temperature to be in 'prop_piezoelectric' category, and still have one dictionary datablock to specify their properties?
It is not a problem in DDLm, I am not sure about DDL1, but it could be confusing. Best avoided.b') or the category is so inclusive that it describes data spanning several loops (like '_prop_' category in the above example)? c) data_... block name in the dictionary no longer matches tag name. I guess this should not be a problem... Is it?
In DDL1 this sometimes happens. In DDLm the name is constructed out of he category and the item name which might make transformation to DDLm problematic. Best avoided.d) would it break anything if category name is not the prefix of the tag (e.g. declaring _prop_piezoelectric_temperature to have category _prop_temperature, to describe all temperature tags in one data block)?
End of my comments
e) Any other anticipated problems? Sincerely yours, Saulius PS. We have toyed with two other representations, one putting all tensors into one loop, but they seem much worse (would require lots of '.' fields and would result in severely denormalised relational tables). PPS: data examples with the proposed tags:The CIF would look like loop_ _prop_elastic_stiffness_label _prop_elastic_stiffness_temperature _prop_elastic_stiffness_c11 _prop_elastic_stiffness_c12 _prop_elastic_stiffness_c13 _prop_elastic_stiffness_c22 _prop_elastic_stiffness_c23 _prop_elastic_stiffness_c33 _prop_elastic_stiffness_c44 _prop_elastic_stiffness_c55 _prop_elastic_stiffness_c66 Copper 273 375.1 -48.5 -48.5 375.1 -48.5 375.1 101.4 101.4 101.4 Copper 293 375.1 -48.5 -48.5 375.1 -48.5 375.1 101.4 101.4 101.4 Copper 313 375.1 -48.5 -48.5 375.1 -48.5 375.1 101.4 101.4 101.4 loop_ _prop_piezoelectric_label _prop_piezoelectric_temperature _prop_piezoelectric_frequency _prop_piezoelectric_d15 _prop_piezoelectric_d16 _prop_piezoelectric_d21 PIN-PMN-PT 100.0 ? 2190 1022 511 PIN-PMN-PT 100.0 ? 2190 1022 511 PIN-PMN-PT 100.0 ? 2190 1022 511 and so on.S.G.
begin:vcard fn:I.David Brown n:Brown;I.David org:McMaster University;Brockhouse Institute for Materials Research adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada email;internet:email@example.com title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ comcifs mailing list firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/comcifs
Reply to: [list | sender only]
- Please advise regarding a design of CIF dictionaries for materialproperties (Saulius Grazulis)
- Prev by Date: Re: Please advise regarding a design of CIF dictionaries for materialproperties
- Next by Date: RE: Please advise regarding a design of CIF dictionaries formaterialpr operties. .
- Prev by thread: Re: Please advise regarding a design of CIF dictionaries for materialproperties
- Next by thread: Re: Please advise regarding a design of CIF dictionaries for materialproperties