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. .

On Thursday, September 29, 2011 4:24 AM, Saulius Grazulis wrote:

> Three approaches seem feasible:
>
> a) Use save frames in DDL1 (a heresy?) and save frame references.
> [...] Would it be beneficial to extend the CIF grammar and
> interpretation to finally to permit save frame references?


Perhaps it would, but I am certain that it isn't going to happen any time soon, and I think it unlikely ever to happen.  Even if COMCIFS were to agree to this, specifications would be a long time coming, and software that leveraged them would take longer still to stabilize.  This isn't a viable alternative for you at this time.


> b) Use an external macro-generator to generate separate data
> blocks.
> Doable but clumsy.


If you want to stick with DDL1 and also to avoid repeating yourself then this is exactly what I would recommend.


> c) I could group the temperature tags into one datablock:

[...]

> This would force the tags to be in the _prop_ category, but as long
> as
> we can put them into separate loops this is fine. The only slight
> concern is that the data block name is no longer a tag name.


It would force virtually ALL tags to be in the _prop category, because in a valid CIF no one loop may contain items from different categories.  There's nothing inherently wrong with having everything in the same category, but you seemed to intend something different.

I think it's a bigger problem that the data block name would not match the defined item names in the specified and conventional way.  Furthermore, the items do not belong to an irreducible set in the way that the term has typically been interpreted: items whose meanings are interdependent, such as the indices of a reflection or the elements of a matrix.  Whether ITG is clear about that is immaterial.


> c) seems the cleanest solution form, but this depends on my
> interpretations of the CIF grammar, semantics and of the ITC vol G.


And that's precisely why (c) is a sub-optimal choice.  You should not be approaching the issue from the perspective of whether your proposed form squeezes within the letter of the specs, or whether you can bend specifications and convention to fit your dictionary.  If you want your dictionary to be friendly to third-party software and easy eventually to convert to DDLm then you should cleave as closely as possible to center of the specifications, as clarified by common and conventional practice.


John


Email Disclaimer:  www.stjude.org/emaildisclaimer

Reply to: [list | sender only]