Discussion List Archives

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

Re: Please advise regarding a design of CIF dictionaries for materialproperties

Dear Colleagues,

   The example CIF itself looks intutive and clear, so
the difficuly, if any, seems to lie in expressing this
structure in the dictionary.  As a DDL2 dictionary,
it would be easy, just change the last underscore
in each tag to a period, define a category for
the part to the left of the period, and the
part to the right is a column name.  There would
be one data block, a lot of save frames, and
there is a past practice in DDL2 dictionaries of
gathering information about a lot or related tags
into a common save frame for some master parent
tag and just putting minimal information on the
individual tags in their own save frames.

   I highly recommend taking a look at the mmCIF
dictionary or the pdbx dictionary.  If that is
followed as a model, then when we do the move of
those to DDLm this new dictionary should move forward
with minimal fuss.  If we start retooling DDL1 for
what is really a DDL2 issue, I fear we would be
borrowing trouble.

   Regards,
     Herbert

=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================

On Wed, 28 Sep 2011, Saulius Grazulis wrote:

> 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?
>
> 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?
>
> 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?
>
> 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)?
>
> 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.
>
> -- 
> Dr. Saulius Gra?ulis
> Institute of Biotechnology, Graiciuno 8
> LT-02241 Vilnius, Lietuva (Lithuania)
> fax: (+370-5)-2602116 / phone (office): (+370-5)-2602556
> mobile: (+370-684)-49802, (+370-614)-36366
> _______________________________________________
> comcifs mailing list
> comcifs@iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>

Reply to: [list | sender only]